クラウドデータ侵害の80%以上は、ゼロデイ脆弱性ではなく設定ミスに起因します。このガイドでは最も一般的なクラウド設定ミスを分析し、共有責任モデルの誤解を解消し、継続的なクラウドセキュリティガバナンスの構築方法を解説します。
Gartnerは「2025年まで、クラウドセキュリティ障害の99%は顧客の責任であり、クラウドプロバイダーの責任ではない」と予測しています。この衝撃的な数字の背後には広く蔓延した誤解があります：多くの企業が「AWSやAzureに移行すれば安全だ」と考え、クラウドが共有責任モデルで運営されていることを無視しています — クラウドプロバイダーはクラウドインフラのセキュリティを担当し、顧客はクラウド上で実行するものを保護する責任を負います。
2024年に発生した台湾企業の大規模データ漏洩事件の多くは、同じ根本原因に行き着きました：公開アクセス設定されたS3バケット、GitHubへ流出したAPIキー、または過剰に許可されたIAMポリシー。これらはすべてゼロデイ脆弱性ではなく、防止可能な設定ミスでした。
S3バケットまたはAzure Blobをパブリック読み取りアクセスに設定すると、誰でもデータに匿名アクセスできます。よくある原因：開発者がテストの利便性のために開放し、本番移行前に閉じることを忘れるケースです。AWSはアカウントレベルの「パブリックアクセスブロック」スイッチを提供しており、すべての本番アカウントで有効化する必要があります。
利便性のためにAdministrator権限を付与したり、ワイルドカード *:* IAMポリシーを使用したりするケースです。このような権限を持つIAMキーが漏洩すると、攻撃者はクラウドアカウント全体を完全に乗っ取ることができます。AWS IAM Access Analyzerを使用して未使用の権限を定期的に確認・削除してください。
開発者がAWS アクセスキー、データベースパスワード、またはAPIトークンをソースコードに直接ハードコーディングし、パブリックまたはプライベートのGitHubリポジトリにプッシュするケースです。GitGuardianの統計によると、年間1000万件以上の秘密情報がGitHub上で検出されています。環境変数、AWS Secrets Manager、またはAzure Key Vaultを使用して秘密情報を管理してください。
データベースセキュリティグループがポート3306・5432またはSSH（22）・RDP（3389）への0.0.0.0/0（全IPアドレス）アクセスを許可し、インターネットに直接公開されているケースです。データベースアクセスはアプリケーションサーバーのIPのみに制限してください。管理者アクセスは必ずBastionホストまたはVPNを経由させてください。
AWS CloudTrail、Azure Monitor Logs、またはGCP Cloud Audit Logsを有効化していない場合、インシデント発生後に攻撃経路や影響範囲を追跡する手段がありません。また、侵害後に攻撃者が証跡を消去するのを防ぐため、監査ログは書き込み保護された別のストレージに保存する必要があります。
データベースディスク（EBS、RDS）、オブジェクトストレージ（S3）、バックアップが暗号化されていない場合、クラウドプロバイダー内部者や物理アクセスシナリオからの漏洩リスクが生じます。現代のクラウド暗号化はほぼ無償かつ透過的です — デフォルトで有効化すべきです。
クラウドセキュリティポスチャ管理（CSPM）ツールは、クラウド環境の設定を継続的にスキャンし、セキュリティのベストプラクティスおよびコンプライアンスベンチマーク（CIS Benchmark、ISO 27001、個人情報保護法）と比較して、自動的に修正推奨事項を生成します。
多くのクラウドプロバイダーはネイティブの無償CSPMツールを提供しています — AWS Security Hub（GuardDuty連携）、Azure Security Center、GCP Security Command Center — これらはクラウドセキュリティガバナンスの最低限のベースラインであり、インシデント発生後ではなく初日から有効化すべきです。
アカウント作成時にセキュリティを組み込む方が、後からパッチを当てるより遥かに効率的です。クラウドランディングゾーンのセキュリティ設計原則は以下の通りです：