クラウドでは、アイデンティティの安全確保とワークロードは最優先事項であり、複雑な問題です。AWSの顧客セキュリティ侵害ポートフォリオから、私たちは公的に開示されているインシデントについて学ぶことはできますが、このようなインシデントを防ぐために利用できる安全性のメカニズムに関する具体的なデータは、今日まであまり共有されていません。本レポートでは、Datadogのクラウドセキュリティ管理を使用する600以上のオーガニゼーションおよび数1000にのぼるAWSアカウントの実際のデータを調査しました。
2022年のAWSのセキュリティ状況について明らかにするため、私たちはセキュリティに関するベストプラクティスの実践傾向を分析し、最もよくあるセキュリティ侵害の原因となる構成ミスのさまざまな種類について調べました。特に、静的で寿命の長い認証情報の管理、安全性の低い規定値の早期特定および修正の重要性、そして複雑なAWS Identity and Access Management (IAM) によりオーガニゼーションが意図せず機密リソースを公開してしまう原因となり得る問題など、重要な課題について述べています。AWSクラウドセキュリティの現実環境における状況について、以下で詳しくご説明します。
IAMユーザーの安全な大規模管理という課題

AWS Identity and Access Management (IAM) ユーザーは、AWSコンソールへのアクセスを許可するパスワードまたはAWS APIへの認証を与える寿命の長いアクセスキーを設定することで、人間の認証に使用されています。アクセスキーは、ワークロードの認証にも使用されます。
アクセスキーは、有効期限のない静的な認証情報であるため、大変機密性が高く、AWSセキュリティ侵害の主な原因として広く知られています。GitGuardianの2022年の研究では、平均で10,000 Gitごとに84個のAWSアクセスキーがリークしていることが分かりました。アクセスキーは頻繁に流出(ログ内、ビルド出力、スタックトレースなど)し、TeamTNTなどのサイバー犯罪グループのターゲットとなっています。
特に、以下が明らかになりました。
- IAMユーザーの40%は過去90日間に認証情報を使用していなかった(アクセスキーまたはコンソールパスワード)ため、オーガニゼーションの70%に影響が出た。
- 全オーガニゼーションの40%に、AWSコンソールへのアクセスを持つが多要素認証(MFA)を使用していないIAMユーザーが少なくとも1つあり、それはすべてのIAMユーザーの10%を占めている。MFAという追加的保護機能を使用しない、これらのユーザーは、特にクレデンシャルスタッフィング攻撃や総当たり攻撃に対して脆弱となる。
さらに、アクティブなアクセスキーを持つIAMユーザーにおいて:
- IAMユーザーの25%が1年以上経っていて、過去30日間使用していないアクティブなアクセスキーを所有している。この両方の特徴を持つユーザーは、通常、未使用または削除されるべきIAMユーザーに一致する。
- IAMユーザーの75%が90日以上経ったアクティブなアクセスキーを所有している。IAMアクセスキーのローテーションは、特に大規模環境で大変困難である。
このデータは、例えば従業員が退職する際やアプリケーションが使用停止になった時のIAM認証情報の適切な管理の難しさを物語っています。さらに、人間またはワークロードの認証に、より安全な選択肢が他にある(人間にはAWS IAM Identity Center(旧AWS SSO)、アプリケーションにはEC2インスタンスロールまたはLambda実行ロール)にもかかわらず、IAMユーザーを使用しないことの重大さを再確認させてくれます。
IAMルートユーザーの認証情報使用率は低いが、依然としてリスクである

ルートユーザーは、AWSアカウントが作成されると自動的にプロビジョニングされます。このユーザーには無制限の管理者権限があります。具体的には、機密データのダウンロードやAWSアカウント全体の完全削除などが可能です。リスクを軽減するためのベストプラクティスは、まず、ルートユーザーにはアクセスキーを作成しないことです
しかしながら、以下の事実が判明しました。
- およそ10%のオーガニゼーションに、アクティブなルートユーザーアクセスキーがある。これは、全AWSアカウントの3%に当たります。このキーの中には、13年も経っているものがある。
- この調査の実施前の30日間に、オーガニゼーションの25%がルートユーザー認証情報を使用していた。
ルートユーザー認証情報の使用が、自動的に必ず危険であるというわけではありません。この認証情報は、AWSアカウント設定の変更など非常に特殊な状況で必要になります。しかし、アクティブなルートユーザーアクセスキーの管理に付随する諸経費は、十分なリスクとなります。なぜなら、寿命の長い静的な認証情報は、しばしばソースコード、コンフィギュレーションファイル、ログ、またはスタックトレースで流出し、多くのAWSの公式顧客セキュリティ侵害の要因となっているからです。危害を受けたルートユーザー認証情報は、アカウント全体に無制限アクセスを付与してしまうため、特に厄介です。
AWS IAMの複雑性が一般開示されたリソースにつながる

Amazon Simple Queue Service (SQS)、Amazon Simple Notification Service (SNS)、Amazon S3などのサービスを使用する際、オーガニゼーションは通常、リソースベースのIAMポリシーをリソース自体に付随して使用し、クロスアカウントアクセスを構成します。
所見:
- SQSを使用するオーガニゼーションの18%に、一般に開示されたキューが少なくとも1つあり、誰でもこのキューへのメッセージを受信または発行することができる。
- SNSを使用するオーガニゼーションの15%に、一般に開示されたトピックが少なくとも1つあり、誰でもこのトピックに対する機密性の高いアクションを実行できる(通知の取得や公開など)。
- S3を使用するオーガニゼーションの36%に、一般に開示されたバケットが少なくとも1つあり、全S3バケットの2%を占めている。
私たちは、これは必要な権限のみを付与するAWS IAMポリシーの作成の複雑さに起因していると考えます。多くのチーム、アプリケーション、そして一時的なリソースが関わる複雑な環境では、最小限の権限ときめ細かい許可を付与する安全なIAMポリシーを作成することは、かなり困難です。「アクセス拒否」エラーが多発したら、チームはワークフローのボトルネックにならないよう、制限の少ないIAMポリシーを作成する方が便利だと感じるかもしれません。
この問題がすっかり蔓延したため、コミュニティのメンバーはRepokidやPolicy Sentryなどのツールを開発し、さまざまなIAM関連の問題に対処しています。これらのツールは有用ですが、ワークフローの邪魔をせずに必要な許可を与えるIAMポリシーを作成し、さらにその要件の変更に応じて最新の状態に維持する、という継続的な課題も浮き彫りになっています。
Instance Metadata Service V2 (IMDSv2) がデフォルトで強制されていないため、EC2インスタンスが危険

Server-side request forgery (SSRF) は、長年にわたり頻繁に、定期的に攻撃者の標的となってきたアプリケーションレベルの脆弱性です。AWSでは、この種の脆弱性により、攻撃者がアプリケーションからEC2 Instance Metadata Service (IMDS) を呼び出し、インスタンスロールに紐づく認証情報を取得することができてしまうのです。攻撃者は、この認証情報を使ってAWS APIに対する認証やAWSコンソールへのアクセスを行います。
この手法は、Capital Oneのデータ漏えいなど、いくつかの有名な事件で使用され、ロン・ワイデン上院議員により、AWS宛ての通信で名指しされるまでとなりました。「多くのサイバーセキュリティ専門家が、Capital OneのハッカーはServer-Side Request Forgery (SSRF) の脆弱性を利用したとの推測を公にしています。この欠陥については、専門家たちにより何年も前から警告されていました。Amazonの知る限り、SSRF攻撃はCapital Oneの顧客データへのアクセスに使用されたのでしょうか?」
2019年、AWSはEC2 IMDS (IMDSv2) のバージョン2を発表し、この脆弱性の改善を試みました。が、EC2インスタンスの大半(93%)がIMDSv2の使用を強制していないことが分かっています。全体で、EC2を使用するオーガニゼーションの95%に少なくとも1件の脆弱性インスタンスがあります。
これは安全なデフォルトの欠落によるものであると考えられます。明示的にバージョン2の強制が構成されない限り、新しく作成されたEC2インスタンスは依然としてIMDSのバージョン1の使用が許可されているので、SSRF攻撃に脆弱なままとなるのです。
オーガニゼーションの少なくとも40%が複数のAWSアカウントを使用

AWSのマルチアカウント戦略を採用することは、侵害されたアプリケーションやユーザーアカウントの被害範囲を制限するために不可欠なうえ、他にも利点があります。しかし、若いオーガニゼーションの場合、複数のアカウントの作成や管理に係る諸経費を削減するため、AWSの単一アカウントの使用を選択することがあります。AWS Organizationsのようなサービスは、アカウントガバナンスを一元化し、AWSの新規アカウントの作成を自動化する(インフラストラクチャをコードとして使用するなど)ことで、この懸念に対応できるよう設計されています。
当社のデータによると、オーガニゼーションの少なくとも41%がAWSのマルチアカウント戦略を採用しています。
オーガニゼーションの6%が、10個以上のAWSアカウントを使用しており、マルチアカウント戦略を大々的に実装しています。さらに、ロングテールの0.6%は100個以上のAWSアカウントを使用し、その一部はなんと数千ものアカウントを使用しています。
Datadogを使用するオーガニゼーションはすべてのAWSアカウントを監視していない場合がある(テスト用または開発目的のアカウントなど)ため、以上の数字は下限と解釈する必要があります。
Datadog のエンジニアにパーソナライズされたデモをリクエスト
方法
調査結果は、2022年9月に収集されたデータに基づいています。
調査対象
本レポートは、Datadogのクラウドセキュリティ管理およびAWSインテグレーションを使用して環境を監視する600以上のオーガニゼーションサンプルのAWSセキュリティに関する姿勢を分析したものです。研究結果は、当社の顧客ベースのデータであるという点で偏りがあるものの、地理、産業、規模、そしてクラウド使用歴という点において十分に多様なオーガニゼーションを対象としました。世界中でAWSを使用するオーガニゼーションを正確に代表するものであると考えられます。
データセット
この調査は、個人を特定できる情報や、リソース名やタグなどの機密情報を含まない匿名化されたデータセットに対して行われました。
SQSキューおよびSNSトピック
主要な “*” のアクションを許可するリソースベースのポリシーを持ち、アクションが許可されるコンテキストをさらに制限する条件文を持たないキューまたはトピックを、一般にアクセス可能なSQSキューまたはSNSトピックと定義します。
S3バケット
以下の基準のいずれかに一致するバケットを、一般にアクセス可能なS3バケットと定義します。
- バケットポリシーに、条件なしでバケット上のアクションを許可する文が1つ以上ある
- Bucket ACLが「認証済みユーザー」に全制御を付与している
- Bucket ACLが、すべてのユーザーに全制御を付与している
IAMユーザーと多要素認証 (MFA)
(a) AWSコンソールのパスワードを作成し (b) MFAデバイスに登録していないIAMユーザーを「MFAが有効になっていないAWSコンソールにアクセス可能なIAMユーザー」と定義します。
説明
説明 | メトリクス値 | 計算対象 |
---|---|---|
AWSアカウントを1つ以上持つオーガニゼーション | 41 % | 全オーガニゼーション |
AWSアカウントを10個以上持つオーガニゼーション | 5 % | 全オーガニゼーション |
非アクティブな認証情報を持つIAMユーザー(コンソールのパスワードまたはアクセスキーはアクティブ、過去90日間非使用) | 39 % | 全オーガニゼーション |
非アクティブな認証情報を持つIAMユーザーが少なくとも1つあるオーガニゼーション | 70 % | 全オーガニゼーション |
1年以上経っていて、過去30日間使用されていないアクセスキーを持つIAMユーザー | 25 % | 全てのIAMユーザー |
90日以上経っているアクティブなアクセスキーをも少なくとも1つ持つIAMユーザー | 60 % | 全てのIAMユーザー |
90日以上経っているアクティブなアクセスキーを少なくとも1つ持つIAMユーザー | 76 % | アクティブなアクセスキーを少なくとも1つ持つIAMユーザー |
コンソールアクセスがありデバイスにMFAを登録していないIAMユーザーが少なくとも1つあるオーガニゼーション | 40 % | 全オーガニゼーション |
コンソールアクセスがありデバイスにMFAを登録していないIAMユーザー | 11 % | 全てのIAMユーザー |
アクティブなルートユーザーアクセスキーを少なくとも1つ持つオーガニゼーション | 9 % | 全オーガニゼーション |
アクティブなルートユーザーアクセスキーを少なくとも1つ持つAWSアカウント | 3 % | 全てのAWSアカウント |
過去30日間にルートユーザー認証情報を使用したオーガニゼーション(アクセスキーまたはコンソールパスワード) | 23 % | 全オーガニゼーション |
IMDSv2の使用を強制していないEC2インスタンス | 93 % | 全てのEC2インスタンス |
IMDSv2の使用を強制していないEC2インスタンスを少なくとも1つ持つオーガニゼーション | 95 % | EC2インスタンスを少なくとも1つ持つオーガニゼーション |
一般に読み取り可能なS3バケットを少なくとも1つ持つオーガニゼーション | 36 % | S3バケットを少なくとも1つ持つオーガニゼーション |
一般にアクセス可能なS3バケット | 36 % | S3バケットを少なくとも1つ持つオーガニゼーション |
一般に開示されたSNSトピックを持つオーガニゼーション | 15 % | SNSトピックを少なくとも1つ持つオーガニゼーション |
一般に開示されたSQSキューを持つオーガニゼーション | 18 % | SQSキューを少なくとも1つ持つオーガニゼーション |