AWS 環境で注意すべき５種類の脆弱性：利用者側の責任範囲とは？

5 Impactful AWS Vulnerabilities You’re Responsible For

2025/03/31 TheHackerNews — AWS を利用していると、自分のクラウドのセキュリティは対処済みだと考えがちだが、それは危険な誤解である。AWS は、自社インフラのセキュリティは確保しているが、クラウド環境内のセキュリティは、利用者自身の手に委ねられている。AWS のセキュリティ体制を建物の保護に例えてみよう。AWS は、強固な壁と頑丈な屋根を提供してくれる。しかし、鍵の管理／警報システムの設置／貴重品の管理などは、顧客の責任となるというわけだ。

この記事では、AWS が保護してくれない範囲と、実際に起こりうる脆弱性の例を紹介する。そして、Intruder のようなクラウドセキュリティ・スキャナーが、どのように役立つのかを解説する。

AWS の Shared Responsibility Model を理解する

AWS は、”Shared Responsibility Model” に基づいて運用されている。平たく言えば、次のように整理できる：

• AWS は、基盤となるインフラ (ハードウェア／ネットワーク／データセンターなど) の、セキュリティを確保する責任を負う。これは、「壁や屋根」に相当する。
• ユーザーは、AWS 内のデータ／アプリケーション／コンフィグのセキュリティを確保する責任を負う。これは、「鍵や警報装置」に相当する。

この違いを正しく理解することが、AWS 環境のセキュリティを維持する上で重要な鍵となる。

AWS における、実際に発生し得る５つの脆弱性

ユーザー側の責任となる実際の脆弱性と、それに対する緩和策について見てみよう。

１：サーバーサイド・リクエスト・フォージェリ (SSRF)

AWS 上でホストされているアプリケーションであっても、依然として SSRF のような攻撃に対して脆弱である。SSRF 攻撃とは、攻撃者がサーバを操作し、自分の代わりに別の内部リソースにリクエストを送信させる攻撃手法である。これにより、データへの不正アクセスや、さらなる悪用につながる可能性がある。

SSRF 攻撃を防ぐには：

• アプリケーションの脆弱性の定期的なスキャンおよび修正を行う。
• AWS IMDSv2 を有効化する。これにより、SSRF 攻撃に対する追加のセキュリティ・レイヤーが提供される。この保護機能は AWS から提供されているが、有効化などの設定は設定はユーザー側で行う必要がある。

２：アクセス制御の脆弱性

AWS IAM (Identify and Access Management) は、それぞれのリソースにアクセスできるユーザーを管理する仕組みを提供している。しかし、そのアクセス制御の強度は、実装に依存する。AWS 利用者の責任により、ユーザーやシステムに対して、本当に必要なリソースだけを許可する必要がある。

よくある設定不備の例：

• 権限が過剰に付与されたロールやアクセス
• セキュリティ制御の欠如
• 意図せず公開されてしまった S3 バケット

３：データ漏えい

クラウドに保存されたデータのセキュリティと、それらのデータへのアプリケーションによるアクセスの方式は、すべてが AWS 利用者の責任となる。

たとえば、アプリケーションが AWS RDS (Relational Database Service) に接続している場合に、そのアプリケーションが機密データを露出しないようにするのは、利用者側の責任となる。また、IDOR (Insecure Direct Object Reference) のような単純な脆弱性が存在すると、ユーザー・アカウントを持つ攻撃者が、他のユーザー・データにアクセスする可能性が生じる。

４：パッチ管理

言うまでもないことだが、AWS は、サーバへのパッチ適用まではやってくれない！EC2 インスタンスを使用している場合に、OS とソフトウェアを最新の状態に保つ責任は、利用者側にある。

たとえば Ubuntu 24.04 上に Redis を導入している場合に、ソフトウェア (Redis) と OS (Ubuntu) の脆弱性に対するパッチ適用は、利用者側の責任となる。AWS が管理するのは、基盤となるハードウェアに関連する、ファームウェアなどの脆弱性のみである。

AWS が提供する Lambda のようなサービスを使用することで、パッチ適用の一部は軽減されるが、サポートされるランタイムの使用や、最新の状態を維持する責任は、依然として利用者側にある。

５：ファイアウォールと攻撃対象領域 (アタック・サーフェス)

AWS は、攻撃対象領域の管理権限を利用者に委ねているが、利用者が何を公開するかについては責任を負わない。

たとえば、GitLab サーバを AWS 上にデプロイする場合に、VPN の背後へのレイヤー配置／ファイアウォールの使用／VPC (Virtual Private Cloud) 内への配置などにより、安全なアクセスをチームとして確保するのは、利用者側の責任となる。適切な対策を講じなければ、ゼロデイ脆弱性によりデータが漏洩する恐れがあるが、その場合でも AWS が責任を負うことはない。

重要なポイント

以上の例から明らかなことは、クラウドのセキュリティは、最初から完全な状態で備わっていないことだ。AWS は、基盤となるインフラのセキュリティは担保しているが、その上に構築されるセキュリティは、すべてが利用者の責任となる。それを見落とすと、組織は深刻なリスクにさらされることになる。しかし、適切なツールを使用すれば、セキュリティを維持することは十分に可能だ。

Intruder でクラウドのセキュリティを強化

Intruder は、エージェントレスのクラウド・セキュリティ・スキャン／脆弱性スキャン／アタック・サーフェス管理を１つにまとめた、強力なプラットフォームである。こういったツールによって、前述の脆弱性などの問題に先手を打つことができる。

Intruder には、以下のような特徴がある：

• 他のツールが見逃しやすいリスクも発見する：Intruder は、外部脆弱性スキャンと AWS アカウントからの情報を組み合わせることで、他のソリューションでは見逃される可能性のあるリスクを発見する。
• 誤警報なし：CSPM (Cloud Security Posture Management) ツールは、深刻度を誇張しすぎる可能性がある。その一方で、Intruder は真のリスクを優先表示するので、本当に重要なものだけに集中できる。
• わかりやすい解説と具体的な対処法： 問題点は平易な言葉で説明され、段階的な修正ガイダンスも提供される。
• 継続的な保護：新たなリスクが発生した場合には、監視とアラートが提供される。これにより、常に先手を打つことができる。
• 明確な価格設定：予測不可能でコストが膨らむ可能性のある他のツールとは異なり、Intruder が想定外の請求を発生することはない。

数分でセットアップが完了し、クラウドセキュリティに関する即時の洞察が得られる。今すぐ 14日間の無料トライアルを開始しよう。

Intruder の広告記事ではありますが、AWS 側とユーザー側の、セキュリティの責任分担について、丁寧に説明してくれるのは有り難いことです。だいぶ昔のことですが、NIST の “Guidelines on Security and Privacy in Public Cloud Computing (800-144)” を訳していますので、よろしければ AWS で検索と併せて、ご参照ください。