AWS・Azure・GCP のクラウドセキュリティ

クラウド環境全体を一元的に可視化し、アイデンティティアクセス管理 (IAM) の設定ミスを早期に検出することで、分断したツールを行き来せずに、クラウドリスクの管理やコンプライアンス維持をより簡単に実施できます。

このページでは、主要な CSP 3 社すべてのセキュリティモデルを解説し、各モデルのセキュリティを確保するために、追加の文脈、可視性、またはツールが必要となる可能性のある領域を示しています。

単一クラウド環境で作業している場合でも、マルチクラウド環境を管理している場合でも、ネイティブな制御の範囲とクラウド責任共有モデルとの境界線を把握することが、設定ミスやアイデンティティエクスポージャーを防ぐために不可欠です。

Amazon Web Services (AWS) は、責任共有モデルに基づいて運用されています。 AWS がインフラのセキュリティを確保し、ユーザーが設定、アクセス管理、データ保護の責任を負います。

AWS は、脅威検出のためのネイティブツール、アクセス管理のための IAM、一元的な可視性を提供します。 ただし、公開された S3 バケットやワイルドカード IAM ロールなどのクラウドの設定ミスは、引き続き一般的なリスクとして存在しています。

Tenable のようなクラウドセキュリティプラットフォームは、ネイティブ API と統合し、アイデンティティエクスポージャーや資産のミス設定を可視化することで、AWS のセキュリティを強化します。 アイドル状態のアクセスキーと公開エンドポイントを関連付けて、エクスポージャーを誘発する資産 (EIA) を特定し、コンピューティングサービスとデータサービスの間のリスクの高い経路にフラグを立てます。

Microsoft Azure の責任共有モデルでは、設定とアイデンティティセキュリティがユーザーの責任として委ねられます。

一方で、過度に広範なロールベースのアクセス制御 (RBAC) のロール、脅威にさらされたエンドポイント、監視されていないリソースが引き続きリスクの要因となっています。

Azure のツールでは、多くの場合、複数のサブスクリプションの関係性や、アイデンティティとワークロードの間の文脈を明らかにする機能が欠如しています。

Tenable は、CIEM データを分析して Entra ID 全体のアイデンティティの設定ミスを検出することで、こうしたギャップを埋めることができます。

たとえば、設定ミスによって機密ストレージに対して不要な権限を持つサービスプリンシパルが、有害な組み合わせの一部としてフラグ付けされた場合、それは実際の脅威を優先的に対処するための手がかりとなります。

このプラットフォームは Azure Policy との統合により、設定のベースラインを適用し、ポリシーのコード化によって修正を効率化します。

Google Cloud の責任共有モデルでは、アイデンティティ、リソース、データの制御がユーザーに委ねられます。 その際、Security Command Center、VPC Service Controls、IAM が防御の第一線となります。

それでもなお、デフォルトのサービスアカウント、過剰に権限付与された IAM バインディング、ログ記録の無効化が原因となり、頻繁にクラウドのセキュリティインシデントが発生します。

さらに、GCP のリソース階層 (プロジェクト、フォルダー、組織) が、クラウドワークロードの保護をより複雑なものにしています。

Tenable は GCP API と統合し、アイデンティティリスクをワークロードのエクスポージャーに結び付けます。

たとえば、公開された機能に関連付けられた、昇格された権限を持つアイドル状態のサービスアカウントを検出してフラグを立てます。 これによって、アイデンティティとデータの関連付けが可能になります。これは、権限昇格やラテラルムーブメントを阻止する上で重要な役割を果たします。

さらに、このプラットフォームは、Google Cloud Policy Intelligence によるポリシー適用をサポートし、検出結果を CIS ベンチマークなどのフレームワークと整合させます。

AWS、Azure、GCP はいずれも IAM、ログ記録、暗号化、モニタリングをサポートしているものの、実装の詳細は、以下のように大きく異なります。

• AWS はポリシーと信頼関係を利用している
  • Azure は RBAC ロールと Entra ID に依存している
  • GCP では、サービスアカウントとプロジェクトごとに適用されるロールを使用している
• ログ記録、暗号化、ファイヤーウォールの設定はプロバイダーごとに大きく異なる
  • プロバイダーによっては、手動で制限しない限り、デフォルトでアクセスを許可することもある
• ネイティブツールが提供する文脈のレベルはそれぞれ異なる
  • Azure Defender は Microsoft 365 とより緊密に統合されている
  • GCP はプロジェクト分離を重視している

以上の理由から、マルチクラウドの可視化戦略が不可欠になります。 ネイティブツールだけに頼っていると、アイデンティティ、ワークロード、データリスクの間に盲点や連携不足が生じてしまいます。

クラウドプロバイダーは、組み込みツールを提供しているものの、多くの場合サービスまたはアカウントごとにサイロ化されています。

Tenable のようなクラウドネイティブアプリケーション保護プラットフォーム (CNAPP) は、ネイティブのインサイトとアイデンティティ、ワークロード、データの文脈を組み合わせるため、部分的な情報ではなく全体像を把握することができます。

ネイティブツールはポイントソリューションを提供しますが、CNAPP はすべてを 1 つにまとめるので、設定ミスのあるものではなく、リスクの高いものを優先できるようになります。

• Tenable Cloud Security などの CNAPP ソリューションを導入し、各プロバイダーにまたがるアイデンティティ、設定ミス、データリスクを統合すること
• ベストプラクティスの違反だけでなく、機密資産を脅威にさらす設定ミスを優先して対処すること
• ポリシーのコード化とシフトレフトのアプローチを適用し、パイプラインの早期段階で問題を検出すること

クラウド固有の脅威検出、修正、ポリシー統合について詳しくは、Tenable クラウドセキュリティハブをご覧ください。