実データを分析したDatadogの「クラウドセキュリティ調査」より

面倒くさいけど対策を　46％の企業が主要クラウドで“有効期限が長い認証情報”を放置

　Datadogは、数千の顧客データを分析したレポート「2024年クラウドセキュリティの現状（2024 State of Cloud Security）」を公開した。調査では、AWSやAzure、Google Cloudを使用する顧客（グローバル）の2024年9月における実データを用いている。

　Datadog Japanのシニアデベロッパーアドボケイトである萩野たいじ氏は、「レポートでは、“長期間有効な認証情報”が主要なリスク要因であることに加えて、クラウドセキュリティにおけるほとんどのインシデントは侵害された認証情報によって引き起こされていることが判明した」と説明する。

Datadog Japan シニアデベロッパーアドボケイト 萩野たいじ氏

　ここからは、同レポートが取り上げている「7つのファクト」について紹介する。

46%の企業が、クラウドセキュリティ侵害の最も一般的な入口である「有効期間の長い認証情報」を放置

　ひとつ目のファクトは、「有効期間の長い認証情報は依然大きなリスク」だ。認証情報を長期間変更しないことは、ソースコードやコンテナイメージ、ビルドログ、アプリケーションから情報が漏えいする危険性を抱える。過去の調査でも、クラウドセキュリティの侵害における最も一般的な要因であることが判明している。

　調査では、AWSコンソールへの認証方法として、54%の企業がAWS IAM Identity CenterやOktaといった集中管理された「フェデレーション認証」を用いていた。一方で、46%が長期間有効な認証情報である「IAMユーザー」を使用しており、IAMユーザーのみの企業も24%だった。

AWSコンソールへの認証方法の割合

　また、有効期間の長い認証情報は、「使用されないまま放置されていることが多々ある」（萩野氏）という。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バケットのパブリックアクセスを積極的にブロックしていることが要因」と萩野氏。

パブリックアクセスブロック機能でカバーされている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を強制適用できるようになっている。

EC2インスタンスで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%が、完全な管理者権限や特権の昇格、過度なデータアクセスといった危険なノードロールを含んでいる。

マネージドKubernetesクラスターがAPIをインターネットに公開している割合