クラウドセキュリティの基礎

なぜ「基礎」から始める必要があるのか

クラウド侵害インシデントの多くは、ゼロデイ脆弱性ではなく「設定ミス」と「責任範囲の誤解」から発生します。「クラウドプロバイダーがセキュリティを担保してくれる」という誤った前提のまま、暗号化やロギング、アクセス制御といった顧客側の責任を放置してしまうケースが典型です。この誤解を解消しないまま個々のサービス(IAM、ネットワーク、データストアなど)を深掘りしても、対策が場当たり的になり抜け漏れが生まれます。

Shared Responsibility Model: 責任境界の移動

サービスモデル(IaaS / PaaS / SaaS)によって、顧客とプロバイダーの責任範囲の境界線は大きく変わります。IaaSでは顧客がOSより上位のレイヤーを管理する一方、SaaSに近づくほど責任はプロバイダー側に移っていきます。ただし、どのモデルでも「データ」と「アクセス制御」の責任だけは常に顧客側に残り続けます。

中央の「OS・ミドルウェア・アプリ設定」レイヤーがゲート(Security Gate)です。ここの責任者がIaaSとPaaSで入れ替わるため、契約中のサービスモデルごとに「誰が何を守るのか」を明文化しておかないと、責任の空白地帯が生まれます。

サービスモデル別の責任範囲

よくある設定ミス

• 「プロバイダーが全部守ってくれる」という誤解 High Risk

  Security OF the CloudとSecurity IN the Cloudの境界を理解しないまま、暗号化・ロギング・アクセス制御などの顧客責任を放置する。

• デフォルト設定の放置 Medium Risk

  ストレージの公開設定、デフォルトVPC、デフォルトのセキュリティグループなど、初期状態が最も安全とは限らない設定をそのまま使い続ける。

• リソースのタグ付け・所有者管理の欠如 Medium Risk

  誰がどのリソースを作成・管理しているか追跡できず、シャドーITや放置リソースが攻撃対象領域として蓄積する。

• アカウント作成時点でのログ有効化の欠如 High Risk

  CloudTrail/Activity Log/Audit Logsが最初から有効化・一元集約されておらず、インシデント発生時に調査可能な証跡が残っていない。

• 組織レベルのガードレール未整備 High Risk

  AWS Organizations SCP / Azure Policy / GCP Organization Policyなど、個々のアカウントの設定ミスを構造的に防ぐ仕組みがなく、すべてを人手のレビューに依存している。

攻撃シナリオ: 公開情報からの偵察と初期侵入

攻撃者は必ずしも高度なゼロデイを使いません。多くの場合、公開範囲の設定ミスや漏洩した認証情報を起点に、地道な偵察から攻撃を組み立てます。ここでは、クラウド環境に対する典型的な初期偵察のパターンを示します。

1. 企業のドメインやGitHubリポジトリから、クラウドリソースのエンドポイントや命名規則を収集する。
2. 公開スキャンツールで、意図せず外部公開されているストレージやAPIエンドポイントを発見する。
3. コードやCI設定に混入した認証情報(アクセスキー等)がないか探索する。
4. 発見した認証情報が有効かどうかを確認し、有効であればそこを起点にアカウント内部を列挙する。

# 1. 公開エンドポイントの存在確認(例: 意図せず公開されたAPI)
$ curl -s -o /dev/null -w "%{http_code}\n" https://api.example-target.com/health

# 2. GitHubの公開リポジトリやコミット履歴から漏洩キーを探索(概念例)
$ git log -p | grep -E "AKIA[0-9A-Z]{16}"

# 3. 発見した認証情報が有効かどうかを確認
$ aws sts get-caller-identity

# 4. 有効であれば、そのアイデンティティで到達可能なリソースを列挙
$ aws s3 ls
$ aws ec2 describe-instances --query "Reservations[].Instances[].InstanceId"

この段階では被害はまだ「偵察」に留まっていますが、有効な認証情報や公開リソースが1つでも見つかれば、攻撃者はそこを足がかりに権限昇格や横展開に移ります。個々の手口の詳細は、IAM・ネットワーク・データセキュリティの各ページで扱います。

検知

あらゆる検知の前提となるのが「ログが有効になっていること」です。CloudTrail、Azure Activity Log、GCP Audit Logsは、アカウント作成時点で有効化し、単一リージョン・単一アカウントに閉じず組織全体で一元的に集約・長期保持する必要があります。

• CloudTrailの組織証跡(Organization Trail)がすべてのメンバーアカウントで有効になっているか。
• Azure Activity LogがLog Analytics workspaceやストレージアカウントへ一元転送されているか。
• GCP Audit Logs(Admin Activity / Data Access)が該当プロジェクト・フォルダ・組織全体で有効か。
• ログの保持期間が、インシデント調査に十分な期間(最低90日以上を目安)確保されているか。

これらのログ基盤が整って初めて、後続のページで扱う「異常なAPIコール」「不審なネットワークトラフィック」「データアクセスの異常」といった具体的な検知ルールが機能します。

是正

基礎レベルの是正は、個別のインシデント対応ではなく「構造的なガードレール」を敷くことです。アカウント作成時点で以下を標準化しておくことで、個々のサービスの設定ミスが致命的な侵害に発展する前に食い止められます。

# アカウント全体でCloudTrailの組織証跡を有効化
$ aws cloudtrail create-trail --name org-trail --s3-bucket-name org-cloudtrail-logs --is-organization-trail --is-multi-region-trail

# SCPでルートユーザーの利用や重要サービスの無効化操作を禁止(例)
$ aws organizations create-policy --name deny-root-user --type SERVICE_CONTROL_POLICY --content file://deny-root-user-scp.json

# リソースへの所有者タグ付けを必須化(Config Rule等と組み合わせる)
$ aws resourcegroupstaggingapi tag-resources --resource-arn-list arn:aws:s3:::example-bucket --tags Owner=platform-team,Environment=prod

実際に手を動かす

ここで整理した基礎知識は、実際の設定ミスと攻撃シナリオを通して体験することで初めて身につきます。IAM、ネットワーク、データ、コンテナなど各領域のシナリオ形式ハンズオンラボを用意しているので、気になるテーマから試してみてください。

実装チェックリスト

• Shared Responsibility Modelにおける自組織の責任範囲を、利用中の各サービス(IaaS/PaaS/SaaS)ごとに明文化している
• CloudTrail / Activity Log / Audit Logsがアカウント全体・組織全体で有効化され、一元的に集約されている
• AWS Organizations SCP / Azure Policy / GCP Organization Policyなどの組織レベルのガードレールが設定されている
• すべての特権アカウントでMFAがベースラインとして強制されている
• すべてのリソースに所有者・環境を示すタグ付けルールが運用されている
• デフォルト設定(デフォルトVPC、公開ストレージ設定等)を本番環境でそのまま使っていない
• 最小権限・多層防御・ゼロトラストの3原則が、新規サービス導入時の設計レビュー基準に組み込まれている
• ログの保持期間がインシデント調査に十分な長さ(90日以上目安)で確保されている