実データを分析したDatadogの「クラウドセキュリティ調査」より
面倒くさいけど対策を 46%の企業が主要クラウドで“有効期限が長い認証情報”を放置
2024年11月26日 15時30分更新
サードパーティとのSaaS統合におけるIAMロールの特権に注意を
5つ目のファクトは、「サードパーティ統合のIAMロールが攻撃の標的に」だ。
パブリッククラウドの利用が拡大するにつれて、クラウドインフラの監視やログの収集など、ユーザーのAWSアカウントと連携するサービスが増えてきている。一方で、連携するIAMロールがAWSアカウントを危険にさらす可能性がある。
調査では、サードパーティ統合における、IAMロールの10%が、アカウント内ですべてのデータにアクセスできたり、過剰な権限を付与されており、同じく2%が、外部のID利用を強制していないことが分かっている。
「これは俗にいう、“混乱した代理問題”を引き起こす。クラウドアカウントで信頼しているサードパーティの統合インベントリを作成して、インテグレーションを停止する際には必ずロールを削除することを推奨する」(萩野氏)
6つ目のファクトは、「多くのクラウドインシデントが、認証情報の漏えいで引き起こされる」だ。「人とアプリケーション両方のアイデンティティを侵害することで、ほとんどのクラウドインシデントが発生する」と萩野氏。
AWSでは、流出したアクセスキーが最初の攻撃ベクトルになることが一般的で、攻撃者は「Trufflehog」のような認証情報スキャナーを利用して、ソースコードリポジトリやバージョン管理システム(VCS)の履歴から認証情報を特定していく。
一旦足がかりができると、攻撃者の行動は予測可能なパターンに従うことが分かっており、例えばAWSでは、アクセスキーからAWSコンソールへのサインインリンクを生成して、コアサービスを列挙し、特定サービスのアクセス権を転売して、クリプト(暗号)マイニングするというのがパターンのひとつとなる。
最後、7つ目のファクトは、「多くのクラウドワークロードが、過度に特権化され、不適切な場所で実行されている」だ。
クラウド環境で実行されるワークロードは、一般的にクラウドリソースにアクセスする必要があるため、AWSのIAMロールだったり、Google Cloudのサービスアカウントといった、ワークロードにプラットフォームIDを割り当てる仕組みを利用する。そのため、クラウドワークロードに過剰な権限を割り当ててしまうと大きなリスクが生じる可能性がある。
AWSでは、EC2インスタンスの18%以上が過剰な権限が与えられ、この内4.3%は、Sessions Managerを使用してアカウント内での横移動を許可する権限を持っている。さらに2.8%は権限昇格ができ、17.6%は過剰なデータアクセスの権限を持つ。
また、Google Cloudでは、13%のVMが「デフォルトサービスアカウント」によって管理者アクセスの権限を、別の20%のVMは、同じ仕組みでストレージ(GCS)への完全なアクセス権限を持っている。つまり、33%のVMが実行中のプロジェクトに対する機密アクセス権を所持していることになる。
萩野氏は、「クラウドワークロードも攻撃の入り口になり得る。IAM権限を管理するのは容易ではないが、管理者権限だけではなく、機密データにアクセスしたり、特権をエスカレートできるような権限にも注意を払う必要がある」と強調した。