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アカウントを監視していない場合がある（テスト用または開発目的のアカウントなど）ため、以上の数字は下限と解釈する必要があります。
