最初からセキュアにつくる：クラウドセキュリティ設計の基本原則

概要

SecHack365（情報通信研究機構のセキュリティイノベーター育成プログラム）向けに作成されたクラウドセキュリティ設計のスライド資料への言及。「最初からセキュアにつくる」という設計思想の重要性を主張している。

スライド: https://docswell.com/s/nekoruri/5N138W-2024-07-20-SecHack365-cloud

詳細

「最初からセキュアにつくる」とはどういうことか

セキュリティは後付けにすると極めてコストが高くなる。設計段階から組み込む Security by Design の考え方：

1. 脅威モデリングを最初に行う: 何を守るか、誰から守るかを明確にする（STRIDE モデルなど）
2. 最小権限の原則: IAM ロールはサービスが必要とする権限のみを付与
3. 多層防御（Defense in Depth）: ネットワーク・アプリ・データ層それぞれでセキュリティ制御を設ける
4. デフォルトセキュア: セキュアな設定をデフォルトにし、必要な場合だけ緩める

クラウド特有のセキュリティ考慮点

ネットワーク層
  VPC / セキュリティグループ / NACLs
  プライベートサブネットにDBを配置

IAM 層
  ロールベースアクセス制御（RBAC）
  最小権限 + 短期クレデンシャル（AssumeRole）

データ層
  保存時暗号化（S3 SSE, RDS暗号化）
  転送時暗号化（TLS必須）

監査層
  CloudTrail（APIコールの全記録）
  GuardDuty（異常検知）
  Config（設定変更の追跡）

よくある「後から直すのが大変」なミス

• S3 バケットの Public Access を後から塞ぐ: 既存のアプリが壊れる可能性
• RDS をパブリックサブネットに置く: 最初から VPC 設計を正しくしないと移行コストが高い
• ルートアカウントを日常使い: MFA + 個人 IAM ユーザーを最初から設定する
• シークレットをコードに埋め込む: Secrets Manager / Parameter Store への移行は後からでは大変

なぜ重要か / いつ使うか

• 新規サービス設計時: アーキテクチャレビューにセキュリティ観点を最初から含める
• コストの非対称性: セキュリティ侵害後の対応コストは、最初から設計するコストの 10〜100 倍以上
• コンプライアンス要件: SOC2 / ISO27001 / PCI DSS などの認証取得時に設計レベルの証跡が必要