第9章 クラウド & コンテナセキュリティ

9.1 責任共有モデル

クラウドセキュリティの出発点は責任共有モデル(Shared Responsibility Model)です。どこまでがクラウド事業者の責任で、どこからが利用者の責任かを線引きします。合言葉は"of the cloud" は事業者、"in the cloud" は利用者です。

境界はサービス形態で動きます。IaaSでは利用者の責任が広く、SaaSでは事業者の責任が広くなります。危険なのは、境界を誤解して「クラウドだから勝手に安全なはず」と、利用者側の責任を放置することです。IAMもネットワーク設定も暗号化も、利用者が正しく設計しなければ守られません。

9.2 IAMが最重要

クラウドにおいて、ネットワークの壁より重要なのがIAM(Identity and Access Management)です。誰が(どのユーザー・サービスが)何にアクセスできるか——これがクラウドの実質的な境界だからです。IAMの設計を誤ると、他の対策をどれだけ積んでも崩れます。

• 最小権限(least privilege) — 各ユーザー・ロールに、必要な操作だけを許可します。「とりあえず管理者権限」は最悪の習慣です。実際に使う権限だけに絞り、定期的に棚卸しします。
• ルートアカウントを日常使いしない — 全権を持つルート(最上位)アカウントは、初期設定とMFA有効化を済ませたら封印し、日常はより権限を絞った個別アカウント/ロールで作業します。
• 一時認証情報を使う — 長期の固定アクセスキーは漏えいリスクが高く、漏れれば長期間悪用されます。可能な限り、有効期限の短い一時認証情報(短命トークン)やロールの引き受けを使います。
• アクセスキー漏えい対策 — アクセスキーをソースコードやリポジトリに埋め込まない。漏れた前提でローテーションし、監視で異常な利用を検知します(第7章、シークレットスキャンは第10章)。

9.3 コンテナの基礎リスク

コンテナ(Dockerなど)は便利ですが、「軽量な仮想マシン」と誤解すると危険です。コンテナはホストのカーネルを共有しており、分離は仮想マシンより弱いことを前提に守ります。

• イメージの脆弱性 — ベースイメージや同梱ライブラリに既知の脆弱性が潜みます。イメージスキャン(第10章のSCAと関連)で継続的に検査します。
• 最小イメージ — 不要なパッケージやシェルを含む肥大なイメージは攻撃面が広がります。必要最小限のイメージ(distroless等)を使います。
• rootで動かさない — 既定のままだとコンテナ内プロセスがroot権限で動きがちです。コンテナ脱出と組み合わさると危険なので、非rootユーザーで実行します。
• シークレットをイメージに埋め込まない — APIキーやパスワードをDockerfileやイメージに焼き込むと、イメージを取得した誰もが読めます。実行時に環境変数やシークレット管理から注入します。

これらを踏まえたDockerfileの一例です。

# 最小のベースイメージを使う
FROM python:3.12-slim

# 依存だけ先に入れてキャッシュを効かせる
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# アプリ本体をコピー
COPY . .

# 非rootユーザーを作成して切り替える(rootで動かさない)
RUN useradd --create-home appuser
USER appuser

# 注意: ここに ENV API_KEY=... のように秘密を書かない
#       秘密は実行時に注入する
CMD ["python", "app.py"]

9.4 Kubernetesの要点

Kubernetes(k8s)は大規模なコンテナ運用を担いますが、設定項目が多く、既定のままでは緩いことがあります。中級者として押さえる4点です。

• RBAC — 誰が(どのサービスアカウントが)どのリソースに何をできるかを、最小権限で定義します。全namespaceのcluster-admin乱発は禁物です。
• NetworkPolicy — Pod間の通信を既定拒否にし、必要な経路だけ許可します(第6章のマイクロセグメンテーションのk8s版)。設定しないとPod同士が自由に通信できてしまいます。
• Pod Security — 特権コンテナの禁止、rootでの実行禁止、ホストパスのマウント制限などをポリシーで強制します。
• Secretの暗号化 — k8sのSecretはBase64エンコードされているだけで暗号化ではありません。etcdに平文相当で保存されるため、保存時暗号化(encryption at rest)や外部のシークレット管理と連携し、SecretへのRBACも絞ります。

NetworkPolicyで「既定拒否」を敷く例です。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}          # namespace 内の全 Pod に適用
  policyTypes:
    - Ingress
    - Egress               # 受信・送信の両方を対象に
  # ingress / egress を書かない = すべて拒否
  # 必要な通信だけ、別の NetworkPolicy で明示的に許可する

9.5 IaCとポリシー・アズ・コード

クラウド構成を画面から手作業で設定すると、ミスが起き、再現もできません。IaC(Infrastructure as Code、Terraform等)で構成をコード化すれば、レビューでき、バージョン管理でき、同じ構成を再現できます。設定ミスをレビュー段階で捕まえられるのが大きな利点です。

さらにポリシー・アズ・コードで「守るべきルール」自体をコード化します。「公開バケットは禁止」「暗号化されていないボリュームは作らせない」といった規則を機械的にチェックし、違反する構成の適用を止められます。

そしてCSPM(Cloud Security Posture Management)は、稼働中のクラウド環境を継続的にスキャンし、公開設定・過剰権限・暗号化漏れなどの設定ミスを自動検知します。IaCが「作る前の予防」、CSPMが「作った後の点検」と考えると役割が整理できます。

9.6 クラウドの監査ログと監視

クラウドでは、誰がいつどのAPIを呼んだかを記録する監査ログ(AWSのCloudTrail、GCPのCloud Audit Logs、AzureのActivity Log等)が提供されます。これが検知(第7章)とフォレンジック(第8章)の一次資料になります。

• 監査ログを有効化し、削除・改ざんされにくい別アカウント/バケットへ集約する(第7章の保全と同じ発想)。
• 「ルートアカウントの利用」「IAMポリシーの大幅変更」「監査ログ自体の無効化」など、危険な操作をアラート化する。
• SIEMへ取り込み、オンプレのログと相関させて横断的に監視する。

まとめ

• 責任共有モデルの境界を理解する。"of the cloud" は事業者、"in the cloud" は利用者
• IAMがクラウドの実質的な境界。最小権限・ルート封印・一時認証情報・キー漏えい対策が要
• コンテナは最小イメージ・非root実行・シークレット非埋め込み・イメージスキャンで守る
• k8sはRBAC・NetworkPolicy・Pod Securityを効かせ、SecretはBase64なので暗号化する
• IaCとポリシー・アズ・コードで予防、CSPMと監査ログで点検。事故の大半は設定ミス

練習問題