長期認証情報は継続的なリスクとなりうる
長期認証情報 (静的で期限のない認証情報) はクラウドセキュリティ侵害の主な原因としてよく知られており、クラウド環境において広範な問題であり続けています。この種の認証情報は、有効期限がないだけでなく、ソースコード、コンテナイメージ、またはコンフィギュレーションファイルから容易に漏えいする可能性があるため、安全でないと広く認識されています。実際に、長期認証情報のリークはクラウドにおけるセキュリティ侵害の最も一般的な原因のひとつです。
この攻撃ベクトルに関してこうした一般認識はあるものの、Datadog は ID の一元管理と短期的な認証情報を使用するより安全なソリューションに長期認証情報を置き換えることで、組織にはまだ改善の余地があることを確認しました。弊社では AWS、Azure、Google Cloud の各プラットフォームにおける長期認証情報の使用状況を分析し、3つのプラットフォームすべてのアカウントに共通する傾向を発見しました。AWS では、IAM ユーザーの 76% がアクティブなアクセスキーを有しています。Azure AD では、アプリケーションの 50% がアクティブな認証情報を、Google Cloud サービスアカウントの 27% がアクティブなアクセスキーを有しています。Google Cloud の数字が低いのは、Googleによって作成・管理されているサービスアカウントが存在するためだと考えられます。
AWS、Azure、Google Cloud 全体で、アクセスキーの約半数が 1 年以上、これら 10 件に 1 件以上が 3 年以上経過しています。これは、アクセスキーが必要以上に長期的に利用される傾向があることを示しています。
AWS については、弊社が 2022 年のレポートのためにまとめた過去データとこれらの数字を比較することができました。それ以来、AWS の認証情報に関する状況は残念ながら改善されていません。アクセスキーを持っている IAM ユーザーの 76% は、1 年前の 72% から増加しているものの、積極的に使用している人は多くありません。これらのユーザーに関する統計は次の通りです:
- 半数近く (49％) が、アクセスキーを過去 90 日間に一度も使用していません。この割合は 1 年前の 40% から増加しています。
- 3 人に 1 人が、1 年以上経過し、過去 30 日間に使用されていない有効な認証情報を有しており、この割合は 1 年前の 25％ から増加しています。
一般的に、人とワークロードの両方に対して、長期認証情報を避け、代わりに ID フェデレーションとプラットフォーム認証を使用することが推奨されます。AWS の場合、これは中央 ID プロバイダーとフェデレートされた IAM Identity Center (旧 AWS SSO) を使用し、IAM ユーザーを避けることを意味します。Google Cloud では、サービスアカウントはアクセスキーを持つべきでなく、組織は代わりにサービスアカウントの権限借用、インスタンスロール、Workload Identity などの時間的制約のある認証情報を作成する安全な認証メカニズムを使用すべきだとされます。Azure では、組織は可能な限り Azure AD アプリケーション認証情報の使用を避け、代わりに マネージド ID および ワークロード ID を選択すると良いでしょう。
“2023 年のクラウド界では、ほとんどすべてのユースケースで長期認証情報を避けることができます。クラウドプロバイダーがフェデレーションを利用できるシナリオの数を増やしているのはすばらしいことだといえます。さらに、一時的な認証情報の最大の利点の 1 つは、豊富な属性情報をサポートしていることです。クラウドで実行されたアクションは CI ジョブの特定の実行や自動スケールされたアプリケーションのインスタンスに帰属させることが可能で、これはセキュリティだけでなく、トラブルシューティングにおいても非常に貴重なものとなります。また、一時的な認証情報には時間的な制約があるため、侵害の帰属も容易になります。数か月、数年という単位ではなく、数時間のログを照会するだけで済むからです。”
Senior Engineer and AWS Serverless Hero
クラウドアクセスの MFA が十分に実施されていない
オンプレミス環境とは異なり、クラウドプロバイダーの管理インターフェースは API であり、設計上インターネットに公開されています。このため、クラウドでは ID が新たな境界となり、ID のセキュリティ確保は最重要事項です。多要素認証 (MFA) の使用と実施は、その取り組みにおける最も基本的で効果的なステップの 1 つです。Microsoft と Google 両社のデータによると、MFA を使用することでアカウントの乗っ取りの大部分を防ぐことができます。MFA はアカウントまたはテナントレベルで実施でき、組織はその使用、特に FIDO2 セキュリティキーのようなフィッシングに耐性のある方法を、健全なクラウドセキュリティポスチャの不可欠な一部として検討する必要があります。
Datadog の調査では、AWS と Azure AD での MFA の使用状況を分析しました。Google Workspace Audit のログにはいくつかの制限がある (例えば、パスキーを使用したログインは MFA イベントとして表示されないなど) ため、Google Cloud での MFA の使用状況を確実に報告することは現時点では不可能です。そこで、各組織について 2023 年 10 月に MFA なしで認証に成功したユーザーの割合を分析しました。
AWS では、コンソールにアクセスする IAM ユーザーのほぼ 3 分の 1 (31%) が MFA を使用していないことが確認され、5 組織中 2 組織が影響を受けています。また、AWS 組織の 45% は 1 人以上の IAM ユーザーが MFA を使用せずに AWS コンソールを認証しており、Azure 組織の 20% のみですべての Azure AD ユーザーが MFA を使用して認証していることが分かりました。
これらの調査結果は、業界の統計によると MFA の導入は増加しているが、組織の大部分では MFA を積極的に実施しておらず、認証情報の盗難やパスワードの盗用攻撃のリスクが高まっていることを示しています。
AWS では IAM ユーザーの使用は避け、代わりに MFA を実施できるサードパーティの ID プロバイダーを導入することを推奨しています。AWS で IAM ユーザーを使用する場合、aws:MultiFactorAuthPresent 条件キーを使用することで MFA を実施できます。Azure ADでは通常、条件付きアクセスポリシーを使用し、レガシー認証が無効になっていることを確認することで MFA を必須にする必要があります。Google Workspace では、組織または組織単位で MFA を導入することができます。
AWS では IMDSv2 はまだ広く実施されていないが、採用は増加
AWSでは、サーバーサイドリクエストフォージェリ (SSRF) 攻撃から保護するために、インスタンスメタデータサービスバージョン 2 (IMDSv2) を導入することが重要です。IMDSv2 では追加の HTTP ヘッダーが必須となるため、攻撃者は EC2 インスタンスから認証情報を盗みづらくなります。
IMDSv2 は 2019 年にリリースされましたが、Datadog の 2022 年の調査によると、当時、IMDSv2 の利用を強制していた EC2 インスタンスはわずか 7% でした。現在では、EC2 インスタンスの 21% が IMDSv2 を必須としています。組織は**平均で EC2 インスタンスの 25%**に IMDSv2 を適用しており、2022 年 9 月の 11% から増加しています。現在の採用率はまだ不十分ですが、組織が IMDSv2 の実施を増やし始めているのは喜ばしいことだといえます。
しかし、導入年数によって実施状況は異なります。1 年以上前の EC2 インスタンスで IMDSv2 が適用されているのはわずか 13% であるのに対し、過去数週間に起動されたインスタンスでは 31% でした。このことは、組織が IMDSv2 をますます認識するようになっていること、そして、簡単に停止または再デプロイできるように設計されている耐用年数の短い EC2 インスタンスが、最近のセキュリティ改善の恩恵をより多く受けていることを裏付けています。
インスタンスが安全に設定されておらず、IMDSv2 を強制していない場合、(攻撃者はおそらく安全でない IMDSv1 を使用することを選ぶでしょうが) それでも IMDSv2 を使用することは可能です。10 月 12 日から 10 月 26 日までの 14 日間で、EC2 インスタンス 4 台のうちほぼ 3 台 (73%) で IMDSv2 しか使用されていないことが確認され、強制されているものと実際に使用されているものとの間の乖離が明らかになりました。つまり、大半の EC2 インスタンスが、機能的な影響や中断なしに IMDSv2 を利用できていることになります。そのため、すべての EC2 インスタンスで IMDSv2 を強制することを推奨します (AWS のガイドもあわせてご覧ください)。
サービスコントロールポリシー (SCP) を使用することで、インスタンスに IMDSv2 を強制することができます。AWS はまた、Amazon Machine Instance (AMI) レベルで、その AMI から起動されるすべての EC2 インスタンスに対してデフォルトで IMDSv2 を強制する設定を最近リリースしています。AWS のドキュメントで、IMDSv2 への移行に関する専用ガイドも参照いただけます。
“2023 年に IMDSv2 の施行が改善された一件は、AWS が AMI とコンピューティングサービスにおいてより安全なデフォルトを導入したのが最もインパクトのある変化であったことを示しています。また、多くの企業が自社環境のインターネットで IMDSv2 の利用を必須化することの重要性を認識しています。しかし、SSRF とプロキシ攻撃は、クラウドを構築する多くの企業にとってまだほとんど知られていない概念であるため、前途は多難だといえるでしょう。クラウドプロバイダーは、いくつかのサービスで安全性の低いオプションを許可する際により詳細な警告やクリックスルー勧告通知を提供し始めています。コンピューティングサービスや、特に IMDS はそのような警告に値します。 さらに、IMDSv2 をサポートしていない商用製品に対しては引き続きフィードバックを提供し、積極的にプッシュすべきだと考えます。”
Senior Security Engineering Manager, Cloud Security at Robinhood
クラウドストレージサービスにおけるパブリックアクセスブロックの採用が増加
パブリックストレージバケットは、今やクラウド環境におけるデータ漏洩の原因としてよく知られています。クラウドストレージから機密データを盗む攻撃者は、2023 年を含め、数え切れないほど文書化されています。これらの侵害は、ストレージバケットを安全に設定することの複雑さが原因であることが多く、バケットはデフォルトでは非公開ですが不注意によって一般公開されてしまうメカニズムが数多く存在しています。加えて、ストレージバケットの中にはかなり昔に作られたものもあります。例えば、Amazon S3 が公開されたのは 2006 年で、最新の安全対策が一般的になる 17 年以上も前のことです。
今日、クラウドプロバイダーは、誤った設定のバケットであっても、クラウドストレージへのパブリックアクセスをプロアクティブにブロックし、バケットが誤ってパブリックに利用可能になるのを防ぐメカニズムを実装しています。これらにより、自身の AWS アカウント、Azure ストレージアカウント、Google Cloud プロジェクト全体を一度に保護し、人為的ミスがデータ漏洩に発展しないようにすることができます (Google クラウドにおけるパブリックアクセスは組織ポリシーの制約によってプロジェクト、フォルダ、組織レベルで通常ブロックされるため、Google クラウドストレージは分析に含めていません)。
AWS では、S3 バケットのほぼ 4 分の 3 (72%) が、バケットまたはアカウントレベルで パブリック S3 アクセスブロックによってカバーされており、2022 年 10 月の半分 (52%) から増加していることを確認しました。これは、2018 年に導入されたこのメカニズムについて、組織がますます認識するようになっていることを示しています。
Azure では、blob ストレージコンテナの 5 つのうち 2 つ (21%) が、プロアクティブにパブリックアクセスをブロックするストレージアカウント内にあり、危険な構成の blob ストレージが効果的に公開されないようにしています。
総合的に見て、Amazon S3 バケットのごく一部 (1.5%) は公開されています (公開バケットポリシーを持っており、アカウントまたはバケットレベルで公開アクセスブロックが適用されていません)。同様に、少数の Azure ストレージの blob コンテナ (5%) はパブリックアクセスが可能であり、パブリックアクセスをブロックしていないストレージアカウントにあります。これらのバケットには必ずしも機密データが含まれているわけではありませんが、将来的に機密情報の保管場所になる可能性があります。
この慣行に対する認識が広まったこと、パブリックアクセスに関連するセキュリティ侵害が数多く文書化されていること、そして AWS が 2018 年に S3 パブリックアクセスブロックを導入したことから、より多くの組織が S3 パブリックアクセスを積極的にブロックしていると考えられます。Microsoft も同等の Azure 機能を 2020 年にリリースしました。さらに、2023 年 4 月以降、AWS はすべてのバケットでパブリックアクセスをデフォルトでブロックしていますが、Azure の場合はこの限りではありません (近い将来に予定されています)。組織は引き続きストレージバケットの設定を監査し、パブリックアクセスが正当化されるか必要な特定のユースケースを除いて、パブリックアクセスブロックが必須化されていることを確認すべきです。そのようなケースの多くでは、Amazon CloudFront や Azure CDN のようなコンテンツデリバリネットワーク (CDN) サービスを活用する方が、バケットを直接公開するよりもパフォーマンス、コスト効率、安全性が向上します。
クラウドのワークロードの大部分は過度に特権化されている
クラウド環境では、権限の設定が面倒な作業となり、ワークロードに必要以上の権限を与えてしまうことがよくあります。多くの場合、一見何の問題もないように見える一連の権限によって、攻撃者が権限をエスカレートさせる可能性も否めません。完全な管理者アクセス権を特定するのは比較的簡単ですが、「シャドー管理者」アクセス権は、間接的に特権をエスカレートさせ、機密データにアクセスすることを可能にするものであり、通常、発見するのは困難です。
AWS では、Amazon EC2 インスタンスのごく少数 (1.5%) だけが完全な管理者権限を有しています。そのようなインスタンスを侵害する攻撃者 (例えば、そのインスタンス上で実行されるウェブアプリケーションを悪用することによって) は、インスタンスメタデータサービスを通じて利用可能になる認証情報を取得し、それによってアカウント内の機密データにアクセスすることができます。
しかし、このデータが全容を語っているわけではありません。攻撃者が大きな影響を与えるためには、完全な管理者権限が必要なわけではないからです。彼らが活用できる、より一般的かつ隠蔽が困難なタイプのアクセス許可は他にも存在します。今回の調査では以下のような発見がありました:
- EC2 インスタンスの 5.4% に、アカウント内でのラテラルムーブメントを許可する危険なアクセス許可 (SSM セッションマネージャーを使用して他のインスタンスに接続するなど) が存在します。
- 7.2% は、権限の昇格によってアカウントへの完全な管理者アクセス権を得る (攻撃者が管理者権限を持つ新しい IAM ユーザーを作成する権限など) ことを可能にします。
- 20% は過剰なデータアクセス (アカウント内のすべての S3 バケットからデータをリストアップしてアクセスするなど) を行っています。
(これらの条件は相互に排他的ではないことにご注意ください。特定のインスタンスがこれらのカテゴリのいくつかに分類されることもあります)
全体として、EC2 インスタンスの 4 台に 1 台 (23%) が、実行する AWS アカウントに管理者または高度に機密性の高い権限 を持っています。
Google Cloud では、無制限のクラウドプラットフォームスコープを持つデフォルトのコンピューティングサービスアカウントを使用することで、20% の仮想マシン (VM) が実行中のプロジェクトに対して特権的な「editor」権限を保持しています。さらに、17% が同じメカニズムで Google Cloud Storage (GCS) のバケットと BigQuery のデータセットへの完全な読み取りアクセス権を持っているため、総じて Google Cloud の VM の 3 人に 1 人以上 (37%) がプロジェクトに対する機密権限を持っていることになります。
Google Cloud を使用している組織は、「デフォルトのサービス アカウントへの自動的な IAM 付与を無効にする」組織ポリシーを有効にして、仮想マシンがデフォルトではないサービスアカウントを使用するようにしてください。
クラウドワークロードの IAM 権限を管理するのは容易なことではありません。監視すべきリスクは管理者アクセスだけでははないからです。ユーザーが機密データにアクセスしたり、特権をエスカレートしたりできるような機密性の高い権限にも注意することが重要です。クラウドワークロードは攻撃者にとって一般的なエントリポイントであるため、これらのリソースに対する権限を可能な限り制限することが重要です。
“クラウドプロバイダーが提供する安全でないデフォルト設定は、初期導入が容易なように最適化されていますが、多くの場合、本番環境での導入に必要なハードニングのレベルとは相容れません。過剰に特権化された IAM ロールや寛容なファイアウォールルールなどの初期構成は惰性を持つ傾向があり、一度導入され動作すると、事後にロックダウンすることが難しくなります。そのため、デプロイライフサイクルの早い段階で初期構成のセキュリティを強化するという規律を設けることが、成熟したクラウドネイティブ組織の文化にとっては極めて効果的です。”
Staff Security Engineering, Ghost Security
多くの仮想マシンはインターネットに公開されたまま
仮想マシン (VM) を公共インターネットに公開することは、クラウド環境における重大なリスクです。攻撃者は、ブルートフォース攻撃を実行したり、BlueKeep のような既知のプロトコルレベルの脆弱性を悪用することで、公開されたサービスを頻繁に狙います。アメリカ合衆国サイバーセキュリティ・社会基盤安全保障庁 (CISA) は、2022 年に最もよく悪用された脆弱性の 1 つとして現在もこれを報告しています。
Datadog は EC2 インスタンスの 7％、Azure VM の 3％、Google Cloud VM の 13％ がインターネットに公開されていることを確認しました。例えば、これらはインターネットからのトラフィックを許可するポートが少なくとも 1 つ有しています。
一般に公開されているインスタンスの中では、HTTP と HTTPS が最も一般的に公開されているポートであり、一般に危険とは考えられていません。これらに続いて、SSH と RDP リモートアクセスプロトコルが一般的です。最も一般的に公開されているデータベース技術は MongoDB、Redis、MSSQL、Elasticsearchです。
Datadog は、Google Cloud で SSH と RDP ポートが公開され、広く普及しているのは、デフォルトネットワーク既定のファイアウォールの事前設定ルールがインターネットからの SSH と RDP を許可しているためであると仮説を立てています。開発者は、「デフォルトネットワークの作成をスキップする」組織ポリシー制約によって、新しいプロジェクトでこのネットワークのプロビジョニングを無効にできますが、既存のプロジェクトには適用されません。その結果、インターネットに公開された VM の割合に違いが生じ、安全でないデフォルトが組織のセキュリティポスチャに与える現実的な影響が改めて示される結果となりました。
すべてのクラウドプラットフォームにおいて、組織は VM をパブリックインターネットに公開することを避け、代わりに AWS SSM Sessions Manager、Amazon EC2 Instance Connect、Google Cloud Identity-Aware Proxy (IAP)、Google Cloud OS Login、Azure Bastion などの IAM ベースのセキュアアクセスメカニズムを使用すべきです。なぜなら、データベースには一般的に機密データが含まれており、攻撃者はこれを容易に発見できるためです。例えば、Shodan や Censys のようなパッシブネットワークスキャン検索エンジンを使って発見が可能です。データベースは内部ネットワーク上に保管し、前述のメカニズムのいずれかを介してアクセスする必要があります。