面倒くさいけど対策を 46％の企業が主要クラウドで“有効期限が長い認証情報”を放置
Datadogは、数千の同社顧客から得た実データを分析した最新レポート「2024年クラウドセキュリティの現状」を公開している。調査では、AWSやAzure、Google Cloudを使用する顧客（グローバル）の2024年9月におけるデータを用いている。 【もっと写真を見る】
Datadogは、数千の顧客データを分析したレポート「2024年クラウドセキュリティの現状（2024 State of Cloud Security）」を公開した。調査では、AWSやAzure、Google Cloudを使用する顧客（グローバル）の2024年9月における実データを用いている。 Datadog Japanのシニアデベロッパーアドボケイトである萩野たいじ氏は、「レポートでは、“長期間有効な認証情報”が主要なリスク要因であることに加えて、クラウドセキュリティにおけるほとんどのインシデントは侵害された認証情報によって引き起こされていることが判明した」と説明する。 ここからは、同レポートが取り上げている「7つのファクト」について紹介する。 46%の企業が、クラウドセキュリティ侵害の最も一般的な入口である「有効期間の長い認証情報」を放置 ひとつ目のファクトは、「有効期間の長い認証情報は依然大きなリスク」だ。認証情報を長期間変更しないことは、ソースコードやコンテナイメージ、ビルドログ、アプリケーションから情報が漏えいする危険性を抱える。過去の調査でも、クラウドセキュリティの侵害における最も一般的な要因であることが判明している。 調査では、AWSコンソールへの認証方法として、54%の企業がAWS IAM Identity CenterやOktaといった集中管理された「フェデレーション認証」を用いていた。一方で、46%が長期間有効な認証情報である「IAMユーザー」を使用しており、IAMユーザーのみの企業も24%だった。 また、有効期間の長い認証情報は、「使用されないまま放置されていることが多々ある」（萩野氏）という。1年以上前からアクティブな認証情報を持つユーザーの割合は、AWSのIAMユーザーでは60%、Google Cloudのサービスアカウントでは62%、MicrosoftのEntraIDアプリケーションでは46%を占め、IAMユーザーの内、6割が90日以上認証情報を使用していないという。 対策としては、期限付きの一時的な認証情報を付与する仕組みが必要となり、ワークロードの認証の場合は、AWSでは「IAM roles for EC2 instances」や「EKS Pod Identity」、Azureでは「マネージドID」、Google Cloudでは「サービスアカウント」が、人の認証の場合は、AWSの「IAM Identity Center」や 「Okta」、「Microsoft Entra ID」などを使用してIDを一元管理することが有効になる。 萩野氏は、「有効期間の短い認証情報は、侵害時に迅速に無効化できる一方で、運用負荷がかかる。リスクがあると何となく分かりつつも有効期間が長い認証情報がまんえんしているのは、メンテナンスなどが“面倒くさい”から。解決策としては、認証情報の自動ローテーションの仕組みや更新対応の自動化を実装することなどがある」と補足した。 2つ目のファクトは、「クラウドストレージで急速に採用が進むパブリックアクセスブロック機能」だ。 これまでデータ侵害の原因となってきたパブリックストレージバケットに焦点をあてると、AWS S3バケットの1.48%が実質的にパブリックであり、2023年レポートの1.5%とほぼ変わらない数値となっている。 一方で、S3バケットの79%は「パブリックアクセスブロック機能」で守られており、2023年レポートの73%から増加している。「これは、問題に対する認識が浸透したこと、AWSが2023年4月の時点から新しく作成されたS3バケットのパブリックアクセスを積極的にブロックしていることが要因」と萩野氏。 Azureにおいては、「Blob Storage」コンテナーの2.6%が実質的にパブリックであり、2023年レポートの5%から減少している。また、Blob Storageの42%が、パブリックアクセスをブロックするストレージアカウント内にある。これも、Microsoftが2023年11月以降に作成されたストレージへのパブリックアクセスを積極的にブロックしているからだ。 3つ目のファクトは、「急速に進むIMDSv2の導入」だ。IMDSv2（Instance Metadata Service v2）とは、EC2インスタンスにおける認証情報の盗難をブロックするAWSのセキュリティサービスである。 IMDSv2の導入は、ここ1年間で25%から47%へと拡大している。その要因は、問題意識の向上、「Amazon Linux 2023」でAMI（Amazon Machine Image、起動テンプレート）単体でIMDSv2をデフォルトで有効する仕組みになったことだ。加えて、2024年3月にリージョン全体の設定において、特定リージョンで将来作成されるインスタンスにIMDSv2を強制適用できるようになっている。 一方で、「いまだに多くのインスタンスが脆弱である」（萩野氏）といい、リージョンレベルのIMDSv2の強制制御は、再作成されない寿命の長いインスタンスなどには効果がない。AMIの「enforce IMDSv2フラグ」といったsecure-by-defaultの仕組みなどを利用して、すべてのインスタンスにIMDSv2を適用すべきだという。 4つ目のファクトは、「マネージドKubernetesクラスターには、デフォルト以外のセキュリティ設定が必要」だ。「人気の高いAmazon EKS（EKS）やGoogle Kubernetes Engine（GKE）のようなマネージドKubernetesサービスでは、デフォルトの設定でセキュリティが確保されていないことが多い」と萩野氏。 調査では、EKSでは48%、GKEでは66%、Azure Kubernetes Service（AKS）では41%と、多くのクラスターでAPIサーバーがインターネットに公開されている。また、EKSの4分の1が、監査ログが有効にされておらず、同じくEKSの10%が、完全な管理者権限や特権の昇格、過度なデータアクセスといった危険なノードロールを含んでいる。 サードパーティとの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権限を管理するのは容易ではないが、管理者権限だけではなく、機密データにアクセスしたり、特権をエスカレートできるような権限にも注意を払う必要がある」と強調した。 文● 福澤陽介／TECH.ASCII.jp
