🔒 STEP 23: セキュリティとコンプライアンス
データを守る！暗号化・アクセス制御・監査ログの基礎
📋 このステップで学ぶこと
- クラウドセキュリティの基本原則
- データ暗号化（転送時・保存時）
- VPC（仮想プライベートクラウド）の基礎
- IAM（アイデンティティとアクセス管理）のベストプラクティス
- 監査ログの管理（CloudTrail、Cloud Audit Logs）
- GDPR・SOC2対応の基礎
- 実践演習：セキュアなデータ基盤設計
🎯 このステップのゴール
このステップを終えると、セキュアなデータ基盤を設計・構築できるようになります。暗号化、アクセス制御、監査ログの設定を理解し、コンプライアンス要件を満たす設計ができるようになりましょう！
🎯 1. クラウドセキュリティの基本原則
責任共有モデル
💡 例え話：マンションのセキュリティ
【責任共有モデル = マンションのセキュリティ】
マンションを借りて住む場合のセキュリティ：
🏢 マンション管理会社（= AWS/GCP）の責任
・建物の構造（耐震、防火）
・共用部のセキュリティ（オートロック、防犯カメラ）
・エレベーター、配管の保守
→ 建物自体を安全に保つ
🏠 住人（= あなた）の責任
・玄関の鍵をかける
・窓を閉める
・貴重品を金庫に入れる
・不審者を部屋に入れない
→ 自分の部屋（データ）を守る
【クラウドも同じ！】
AWSやGCPは「建物」を守る
あなたは「中身」（データ、アクセス）を守る
📝 責任共有モデルの詳細
【責任の分担】
┌─────────────────────────────────────────────────────────┐
│ クラウド事業者（AWS/GCP）の責任 │
├─────────────────────────────────────────────────────────┤
│ ✅ 物理的なデータセンターのセキュリティ │
│ ・入退室管理、監視カメラ、警備員 │
│ ✅ ハードウェアの管理 │
│ ・サーバー、ストレージ、ネットワーク機器 │
│ ✅ 基盤となるサービスの保護 │
│ ・仮想化基盤、OS、ネットワークインフラ │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ ユーザー（あなた）の責任 │
├─────────────────────────────────────────────────────────┤
│ ✅ データの暗号化 │
│ ・S3、GCSの暗号化設定 │
│ ✅ アクセス制御（IAM） │
│ ・誰が何にアクセスできるか │
│ ✅ ネットワーク設定（VPC、ファイアウォール） │
│ ・どこからアクセスを許可するか │
│ ✅ アプリケーションのセキュリティ │
│ ・脆弱性対策、セキュアコーディング │
│ ✅ データのバックアップ │
│ ・定期バックアップ、復旧テスト │
└─────────────────────────────────────────────────────────┘
セキュリティの5つの柱
1️⃣ 機密性（Confidentiality）
データを権限のない人に見られないようにする。暗号化、アクセス制御で実現。
2️⃣ 完全性（Integrity）
データが改ざんされないようにする。ハッシュ値検証、バージョン管理で実現。
3️⃣ 可用性（Availability）
必要な時に必ずアクセスできるようにする。冗長化、バックアップで実現。
4️⃣ 真正性（Authenticity）
なりすましを防ぎ、本人確認を徹底する。MFA、認証で実現。
5️⃣ 説明責任（Accountability）
誰が何をしたか記録し、追跡可能にする。監査ログで実現。
🔐 2. データ暗号化
暗号化の2つのタイミング
💡 例え話：手紙と金庫
【暗号化 = 手紙を守る方法】
① 転送時の暗号化（In Transit）
= 手紙を封筒に入れて郵送する
・配達中に中身を見られないように
・途中で盗まれても読めない
・例：HTTPS、TLS、SSL
② 保存時の暗号化（At Rest）
= 手紙を金庫に入れて保管する
・盗まれても鍵がないと開けられない
・例：S3暗号化、EBS暗号化、GCS暗号化
【両方必要！】
転送時だけ暗号化しても、保存場所が無防備なら意味がない
保存時だけ暗号化しても、転送中に盗まれたら意味がない
| 種類 | 説明 | 実装例 |
|---|---|---|
| 転送時の暗号化 （In Transit） |
データが移動中に暗号化 | HTTPS、TLS 1.2/1.3、SSL |
| 保存時の暗号化 （At Rest） |
データが保存中に暗号化 | SSE-S3、SSE-KMS、GCS暗号化 |
AWS：S3の暗号化
📝 S3暗号化の3つの選択肢
【S3暗号化の選び方フローチャート】
Q1: 暗号化の鍵を自分で管理したい？
├─ NO → SSE-S3（AWSが鍵を管理）【おすすめ】
└─ YES ↓
Q2: 鍵の使用履歴を監査したい？
├─ YES → SSE-KMS（AWS KMSで鍵を管理）
└─ NO ↓
Q3: 鍵を完全に自分で管理したい？
└─ YES → SSE-C（自分で鍵を用意）
【各方式の比較】
┌─────────────────────────────────────────────────────────┐
│ SSE-S3（Server-Side Encryption with S3 Keys） │
├─────────────────────────────────────────────────────────┤
│ ・AWSが鍵を自動管理 │
│ ・追加設定不要、追加料金なし │
│ ・最も簡単！デフォルト推奨 │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ SSE-KMS（Server-Side Encryption with KMS Keys） │
├─────────────────────────────────────────────────────────┤
│ ・AWS KMSで鍵を管理 │
│ ・鍵の使用履歴を監査できる │
│ ・鍵のローテーションを自動化できる │
│ ・KMSの料金がかかる │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ SSE-C（Server-Side Encryption with Customer Keys） │
├─────────────────────────────────────────────────────────┤
│ ・自分で用意した鍵を使う │
│ ・鍵の管理責任は完全に自分 │
│ ・高度なセキュリティ要件がある場合のみ │
└─────────────────────────────────────────────────────────┘
✅ S3バケットでデフォルト暗号化を有効化
# AWS CLIでSSE-S3（デフォルト暗号化）を有効化
aws s3api put-bucket-encryption \
–bucket my-bucket \
–server-side-encryption-configuration ‘{
“Rules”: [{
“ApplyServerSideEncryptionByDefault”: {
“SSEAlgorithm”: “AES256”
}
}]
}’
# 確認
aws s3api get-bucket-encryption –bucket my-bucket
GCP：GCSの暗号化
✅ GCSの暗号化（デフォルトで自動暗号化！）
【GCSの暗号化オプション】
① デフォルト暗号化（Google管理の鍵）
・何も設定しなくても自動で暗号化される
・追加料金なし
・ほとんどのケースでこれで十分
② CMEK（Customer-Managed Encryption Keys）
・Cloud KMSで鍵を管理
・鍵の監査、ローテーションが可能
・KMSの料金がかかる
③ CSEK（Customer-Supplied Encryption Keys）
・自分で用意した鍵を使う
・鍵の管理責任は完全に自分
【ポイント】
GCSはデフォルトで暗号化されるので、
特別な理由がなければ追加設定は不要！
転送時の暗号化（HTTPS/TLS）
⚠️ HTTPアクセスを拒否する設定
S3バケットでHTTP（暗号化なし）アクセスを拒否するポリシーを設定しましょう。
# S3バケットポリシー：HTTPアクセスを拒否
{
“Version”: “2012-10-17”,
“Statement”: [{
“Sid”: “DenyInsecureTransport”,
“Effect”: “Deny”,
“Principal”: “*”,
“Action”: “s3:*”,
“Resource”: [
“arn:aws:s3:::my-bucket”,
“arn:aws:s3:::my-bucket/*”
],
“Condition”: {
“Bool”: {
“aws:SecureTransport”: “false”
}
}
}]
}
🌐 3. VPC（仮想プライベートクラウド）
VPCとは？
💡 例え話：会社のオフィスビル
【VPC = 会社のオフィスビル】
一般的な会社のオフィスビル：
🏢 オフィスビル全体（VPC）
├── 1階：受付・来客スペース（パブリックサブネット）
│ ・誰でも入れる
│ ・インターネットから直接アクセス可能
│
└── 2階〜：社員専用オフィス（プライベートサブネット）
・セキュリティゲートで入室管理
・外部から直接入れない
・重要な仕事はここで行う
【クラウドでは】
VPC = 仮想的なオフィスビル
パブリックサブネット = 受付（ロードバランサー）
プライベートサブネット = 社員専用エリア（DB、アプリ）
💡 重要なデータは必ずプライベートサブネットに配置！
📝 VPCの構造詳細解説
【VPCの基本構成】
┌─────────────────────────────────────────────────────────┐
│ VPC: 10.0.0.0/16（IPアドレス範囲: 10.0.0.0 〜 10.0.255.255）│
│ │
│ ┌─── アベイラビリティゾーン A ───┐ │
│ │ │ │
│ │ パブリックサブネット │ │
│ │ 10.0.1.0/24 │ │
│ │ ・インターネットGW接続 │ │
│ │ ・ロードバランサー配置 │ │
│ │ ・踏み台サーバー（Bastion） │ │
│ │ │ │
│ │ プライベートサブネット │ │
│ │ 10.0.2.0/24 │ │
│ │ ・Redshift / BigQuery │ │
│ │ ・RDS / Cloud SQL │ │
│ │ ・アプリケーションサーバー │ │
│ │ │ │
│ └─────────────────────────────────┘ │
│ │
│ ┌─── アベイラビリティゾーン B ───┐ (冗長化) │
│ │ …（同様の構成） │ │
│ └─────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
【CIDR表記の読み方】
10.0.0.0/16 の「/16」= 上位16ビットがネットワーク部
→ 10.0.xxx.xxx の範囲（約65,000個のIPアドレス）
10.0.1.0/24 の「/24」= 上位24ビットがネットワーク部
→ 10.0.1.xxx の範囲（約250個のIPアドレス）
セキュリティグループとネットワークACL
📊 セキュリティグループ vs ネットワークACL
【2つの防御壁】
┌─────────────────────────────────────────────────────────┐
│ セキュリティグループ（インスタンスレベル） │
├─────────────────────────────────────────────────────────┤
│ ・EC2やRDSなど、各インスタンスに適用 │
│ ・許可ルールのみ（拒否は書けない） │
│ ・ステートフル（戻りの通信は自動許可） │
│ │
│ 例：このEC2は、ポート22（SSH）を社内IPからのみ許可 │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ ネットワークACL（サブネットレベル） │
├─────────────────────────────────────────────────────────┤
│ ・サブネット全体に適用 │
│ ・許可・拒否の両方を記述可能 │
│ ・ステートレス（戻りの通信も明示的に許可必要） │
│ ・番号順に評価（小さい番号が優先） │
│ │
│ 例：このサブネットは、特定IPからのアクセスを全面拒否 │
└─────────────────────────────────────────────────────────┘
【使い分け】
・基本はセキュリティグループで制御（簡単で柔軟）
・特定IPをブロックしたい場合はネットワークACLを追加
✅ セキュリティグループの設定例
# Redshiftクラスタ用セキュリティグループ
インバウンドルール（入ってくる通信）:
┌────────────────────────────────────────────────────┐
│ タイプ │ プロトコル │ ポート │ 送信元 │
├───────────────┼────────────┼─────────┼────────────┤
│ PostgreSQL │ TCP │ 5439 │ 10.0.0.0/16│
│ （Redshift） │ │ │ (VPC内) │
└───────────────┴────────────┴─────────┴────────────┘
アウトバウンドルール（出ていく通信）:
┌────────────────────────────────────────────────────┐
│ タイプ │ プロトコル │ ポート │ 送信先 │
├───────────────┼────────────┼─────────┼────────────┤
│ すべて │ すべて │ すべて │ 0.0.0.0/0 │
└───────────────┴────────────┴─────────┴────────────┘
💡 ポイント：VPC内からのみアクセス許可（最小権限の原則）
VPCエンドポイント
💡 VPCエンドポイントのメリット
【VPCエンドポイント = 専用通路】
通常のS3アクセス:
EC2 → NAT Gateway → インターネット → S3
・NATの料金がかかる
・インターネットを経由するので遅い
・セキュリティリスク
VPCエンドポイント経由:
EC2 → VPCエンドポイント → S3
・AWSの内部ネットワークで完結
・高速、低コスト
・インターネットに出ないので安全
【メリット】
✅ セキュリティ向上：インターネットを経由しない
✅ コスト削減：NATゲートウェイの料金が不要
✅ 高速化：AWS内部ネットワークで通信
👤 4. IAM（アイデンティティとアクセス管理）
IAMのベストプラクティス
💡 IAMの黄金ルール5つ
- 最小権限の原則：必要最小限の権限だけ付与
- ルートユーザーを使わない：日常業務ではIAMユーザーを使う
- MFA（多要素認証）を有効化：パスワード＋スマホアプリで2段階認証
- ロールを活用：長期的なアクセスキーを避ける
- 定期的な権限レビュー：不要な権限を削除
IAMポリシーの構造詳細解説
📝 IAMポリシーの各要素を理解しよう
【IAMポリシーの構造】
{
“Version”: “2012-10-17”,
“Statement”: [{
“Effect”: “Allow”,
“Action”: [
“s3:GetObject”,
“s3:ListBucket”
],
“Resource”: [
“arn:aws:s3:::my-data-bucket”,
“arn:aws:s3:::my-data-bucket/*”
]
}]
}
【各要素の意味】
┌─────────────────────────────────────────────────────────┐
│ “Version”: “2012-10-17” │
├─────────────────────────────────────────────────────────┤
│ ポリシー言語のバージョン │
│ 常にこの値を使う（おまじない） │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ “Effect”: “Allow” または “Deny” │
├─────────────────────────────────────────────────────────┤
│ 許可するか拒否するか │
│ ・Allow = この操作を許可する │
│ ・Deny = この操作を拒否する（Allowより優先） │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ “Action”: [“s3:GetObject”, “s3:ListBucket”] │
├─────────────────────────────────────────────────────────┤
│ どの操作を対象にするか │
│ ・サービス名:アクション名 の形式 │
│ ・s3:GetObject = S3からファイルをダウンロード │
│ ・s3:ListBucket = バケット内のファイル一覧を取得 │
│ ・s3:* = S3のすべての操作（危険！避けるべき） │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ “Resource”: [“arn:aws:s3:::my-data-bucket/*”] │
├─────────────────────────────────────────────────────────┤
│ どのリソースに対して適用するか │
│ ・ARN（Amazon Resource Name）で指定 │
│ ・arn:aws:s3:::my-data-bucket = バケット自体 │
│ ・arn:aws:s3:::my-data-bucket/* = バケット内の全オブジェクト │
│ ・* = すべてのリソース（危険！避けるべき） │
└─────────────────────────────────────────────────────────┘
【実践例：データアナリスト用の読み取り専用ポリシー】
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “AllowS3ReadOnly”, ← この文の識別名（任意）
“Effect”: “Allow”,
“Action”: [
“s3:GetObject”, ← ファイルをダウンロード
“s3:ListBucket” ← ファイル一覧を表示
],
“Resource”: [
“arn:aws:s3:::analytics-data-bucket”,
“arn:aws:s3:::analytics-data-bucket/*”
]
},
{
“Sid”: “AllowRedshiftReadOnly”,
“Effect”: “Allow”,
“Action”: [
“redshift:GetClusterCredentials”,
“redshift:DescribeClusters”
],
“Resource”: “*”
}
]
}
💡 複数のStatementで、異なるサービスの権限をまとめて定義
⚠️ アクセスキーの管理
- アクセスキーをコードに書かない：GitHubに誤ってpushしてしまうリスク
- 環境変数で管理：
AWS_ACCESS_KEY_ID、GOOGLE_APPLICATION_CREDENTIALS - 定期的にローテーション：90日ごとに新しいキーに更新
- 使わないキーは削除：不要になったら即座に削除
- IAMロールを使う：EC2やLambdaではロールを使い、アクセスキーを不要に
📝 5. 監査ログの管理
なぜ監査ログが必要か？
💡 例え話：防犯カメラの記録
【監査ログ = 防犯カメラの記録】
オフィスの防犯カメラ：
・誰が入室したか
・いつ入室したか
・何をしていたか
→ すべて記録
問題が起きたときに：
・「誰が」「いつ」「何をした」かを確認
・犯人を特定、原因を究明
【クラウドの監査ログ】
・誰がS3にファイルをアップロードしたか
・誰がBigQueryでクエリを実行したか
・誰がIAMの権限を変更したか
→ すべて記録
セキュリティインシデントが起きたときに追跡可能！
📊 監査ログの3つの目的
- セキュリティインシデント対応：不正アクセスがあったときに追跡
- コンプライアンス：法律や規制の要件を満たす（GDPR、SOC2など）
- トラブルシューティング：問題発生時の原因究明
AWS：CloudTrail
📝 CloudTrailが記録する内容
【CloudTrailのログ例】
{
“eventTime”: “2024-01-15T14:30:00Z”,
“eventSource”: “s3.amazonaws.com”,
“eventName”: “PutObject”,
“awsRegion”: “ap-northeast-1”,
“sourceIPAddress”: “203.0.113.25”,
“userIdentity”: {
“type”: “IAMUser”,
“userName”: “[email protected]”
},
“requestParameters”: {
“bucketName”: “my-data-bucket”,
“key”: “sales/2024/01/data.csv”
},
“responseElements”: null,
“errorCode”: null
}
【記録される情報】
・誰が（userIdentity）: [email protected]
・いつ（eventTime）: 2024-01-15 14:30:00
・何を（eventName）: PutObject（ファイルアップロード）
・どこに（requestParameters）: my-data-bucket/sales/…
・どこから（sourceIPAddress）: 203.0.113.25
・結果（errorCode）: null = 成功
GCP：Cloud Audit Logs
📝 Cloud Audit Logsの種類
【4種類のAudit Logs】
┌─────────────────────────────────────────────────────────┐
│ 管理アクティビティログ（Admin Activity） │
├─────────────────────────────────────────────────────────┤
│ ・リソースの作成・削除・変更 │
│ ・例：VM作成、IAM権限変更、バケット作成 │
│ ・デフォルトで有効、無料 │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ データアクセスログ（Data Access） │
├─────────────────────────────────────────────────────────┤
│ ・データの読み取り・書き込み │
│ ・例：BigQueryクエリ、GCSファイル読み込み │
│ ・デフォルトで無効（有効化が必要） │
│ ・ログ量が多くなる → 課金に注意 │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ システムイベントログ（System Event） │
├─────────────────────────────────────────────────────────┤
│ ・GCP内部の自動操作 │
│ ・例：ライブマイグレーション │
│ ・デフォルトで有効、無料 │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ ポリシー拒否ログ（Policy Denied） │
├─────────────────────────────────────────────────────────┤
│ ・権限不足で拒否された操作 │
│ ・不正アクセスの試行を検知 │
│ ・デフォルトで有効、無料 │
└─────────────────────────────────────────────────────────┘
💡 データアクセスログの有効化
BigQueryやGCSへのアクセスを記録するには、データアクセスログを有効化する必要があります。GCPコンソール → 「IAMと管理」 → 「監査ログ」で設定できます。
注意：データアクセスログはログ量が多くなるため、コストが増加します。必要なサービスのみ有効化することを推奨します。
⚖️ 6. GDPR・SOC2対応の基礎
GDPR（EU一般データ保護規則）
📋 GDPRの主要な要件
【GDPR対応チェックリスト】
□ データ最小化
・必要最小限のデータだけ収集
・不要なデータは収集しない
□ 保存期間の制限
・目的を達成したら削除
・明確な保存期間を設定
□ 暗号化
・個人データは転送時・保存時の両方で暗号化
・暗号化キーを適切に管理
□ アクセス権（本人がデータにアクセスできる）
・自分のデータをダウンロードできる機能
・データポータビリティ
□ 削除権（忘れられる権利）
・本人から削除要求があれば対応
・72時間以内に処理
□ データ侵害の通知
・データ漏洩が発生したら72時間以内に当局へ報告
・影響を受けた本人にも通知
□ データ保存場所
・EUリージョンに保存、または適切な移転措置
・europe-west1（ベルギー）など
SOC2（Service Organization Control 2）
📊 SOC2の5つの信頼サービス原則
【SOC2の5原則】
┌─────────────────────────────────────────────────────────┐
│ 1. セキュリティ（Security） │
├─────────────────────────────────────────────────────────┤
│ 不正アクセスを防ぐ │
│ ・ファイアウォール、IDS/IPS │
│ ・アクセス制御、暗号化 │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ 2. 可用性（Availability） │
├─────────────────────────────────────────────────────────┤
│ システムが常に利用可能 │
│ ・SLA（サービスレベル契約） │
│ ・冗長化、バックアップ │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ 3. 処理の完全性（Processing Integrity） │
├─────────────────────────────────────────────────────────┤
│ データ処理が正確で完全 │
│ ・入力検証、エラー処理 │
│ ・品質管理 │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ 4. 機密性（Confidentiality） │
├─────────────────────────────────────────────────────────┤
│ 機密情報を保護 │
│ ・データ分類、暗号化 │
│ ・アクセス制限 │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ 5. プライバシー（Privacy） │
├─────────────────────────────────────────────────────────┤
│ 個人情報を適切に管理 │
│ ・プライバシーポリシー │
│ ・同意管理、削除対応 │
└─────────────────────────────────────────────────────────┘
🛠️ 7. 実践演習：セキュアなデータ基盤設計
シナリオ
ECサイトのデータ基盤を、セキュアに設計します。
📋 要件
- 顧客の個人情報（氏名、メールアドレス、購入履歴）を扱う
- GDPR対応が必要（EU在住者のデータあり）
- データアナリストがBigQueryでクエリ実行
- 夜間にDataflowでETL処理
セキュリティ設計
1️⃣ ネットワーク設計
【VPC構成】
VPC（10.0.0.0/16）
│
├── パブリックサブネット（10.0.1.0/24）
│ └── ロードバランサー（HTTPS のみ）
│
└── プライベートサブネット（10.0.2.0/24）
├── Dataflow ワーカー
├── Cloud SQL（メタデータDB）
└── 踏み台サーバー（Bastion）
【ファイアウォールルール】
・インターネット → LB：443（HTTPS）のみ
・LB → アプリ：8080（HTTP）
・VPC内部 → BigQuery：VPCエンドポイント経由
💡 個人データはプライベートサブネットに配置！
2️⃣ 暗号化設定
- GCS：デフォルト暗号化（Google管理の鍵）
- BigQuery：デフォルト暗号化
- Cloud SQL：SSL接続を必須化
- 転送時：すべてHTTPS/TLS 1.2以上
- 個人情報のマスキング：分析用テーブルでは仮名化
3️⃣ アクセス制御（IAM）
【ロールの設定】
データアナリスト:
├── roles/bigquery.dataViewer（読み取り専用）
├── 特定のデータセットのみアクセス可能
└── 個人情報カラムへのアクセスは禁止
データエンジニア:
├── roles/bigquery.dataEditor（読み書き可能）
├── roles/storage.objectAdmin（GCS管理）
└── 本番環境の変更は承認フロー必須
Dataflow サービスアカウント:
├── roles/bigquery.dataEditor
├── roles/storage.objectViewer
└── 最小権限の原則を徹底
4️⃣ 監査ログ
- Cloud Audit Logs：すべての操作を記録
- データアクセスログ：BigQueryクエリを記録（有効化が必要）
- 保存期間：3年（GDPR要件）
- アラート：不審なアクセスをCloud Monitoringで検知
5️⃣ GDPR対応
- データ保存場所：EUリージョン（europe-west1）
- 削除機能：顧客が削除要求したら72時間以内に対応
- データエクスポート：顧客が自分のデータをダウンロード可能
- プライバシーポリシー：データの利用目的を明記
セキュリティチェックリスト
✅ デプロイ前のチェックリスト
【セキュリティチェックリスト】
□ 暗号化
□ すべてのストレージで暗号化が有効
□ 転送時の暗号化（HTTPS/TLS）が必須
□ 暗号化キーの管理方法が明確
□ アクセス制御
□ IAMで最小権限の原則が守られている
□ ルートユーザーを使っていない
□ MFA（多要素認証）が有効
□ 不要な権限がない
□ ネットワーク
□ VPCで適切にネットワークが分離されている
□ セキュリティグループで必要な通信のみ許可
□ VPCエンドポイントで内部通信化
□ 監査
□ CloudTrail / Cloud Audit Logsが有効
□ データアクセスログが必要なサービスで有効
□ ログの保存期間が適切
□ その他
□ アクセスキーがコードに含まれていない
□ 定期的なバックアップが設定されている
□ インシデント対応手順が文書化されている
□ コンプライアンス要件を満たしている
📝 8. STEP 23 のまとめ
✅ このステップで学んだこと
- 責任共有モデル：クラウド事業者とユーザーで責任を分担
- データ暗号化：転送時と保存時の両方で暗号化
- VPC：仮想プライベートクラウドでネットワークを隔離
- IAM：最小権限の原則でアクセス制御
- 監査ログ：CloudTrail、Cloud Audit Logsですべての操作を記録
- GDPR・SOC2：コンプライアンス要件を満たす設計
💡 次のステップへ
セキュリティは「後から追加する」ものではなく、「最初から設計する」ものです。
データ基盤を構築する際は、必ずセキュリティを考慮しましょう。
次のSTEP 24では、モニタリングとロギングを学びます。
システムの健全性を監視する方法を身につけましょう！
📝 練習問題
問題 1
基礎
責任共有モデルにおいて、クラウド事業者とユーザーの責任範囲を簡潔に説明してください。
【解答】
クラウド事業者の責任：
- 物理的なデータセンターのセキュリティ
- ハードウェアとネットワークインフラの管理
- 基盤サービスの保護
ユーザーの責任：
- データの暗号化
- アクセス制御（IAM）
- ネットワーク設定（VPC、ファイアウォール）
- アプリケーションのセキュリティ
問題 2
基礎
「転送時の暗号化」と「保存時の暗号化」の違いを説明してください。
【解答】
- 転送時の暗号化（In Transit）：データが移動中（ネットワーク経由）に暗号化されること。例：HTTPS、TLS
- 保存時の暗号化（At Rest）：データが保存されているとき（ディスク上）に暗号化されること。例：S3暗号化、EBS暗号化
問題 3
応用
IAMの「最小権限の原則」とは何ですか？具体例を挙げて説明してください。
【解答】
最小権限の原則：ユーザーやサービスに対して、業務を遂行するために必要な最小限の権限だけを付与すること。
具体例：
- ❌ NG：データアナリストに「管理者権限」を付与
- ✅ OK：データアナリストには「BigQueryの読み取り専用権限」のみを付与
問題 4
発展
GDPR対応のデータ基盤を構築する際、最低限必要な対策を5つ挙げてください。
【解答例】
- データの暗号化：個人データを転送時・保存時の両方で暗号化
- データ保存場所：EUリージョンに保存（またはデータ移転の仕組み整備）
- 削除機能：本人から削除要求があったら72時間以内に対応
- アクセス制御：IAMで最小権限の原則を徹底
- 監査ログ：すべての操作を記録し、3年間保存
その他、データ最小化、保存期間の制限、データエクスポート機能なども重要です。
❓ よくある質問
Q1: 暗号化するとパフォーマンスが落ちませんか？
ほとんど影響ありません。現代のCPUは暗号化処理が高速化されており、AWSやGCPの暗号化は自動的に行われるため、パフォーマンスへの影響はごくわずかです。セキュリティのメリットの方がはるかに大きいので、必ず暗号化を有効にしましょう。
Q2: MFA（多要素認証）は本当に必要ですか？
はい、絶対に必要です。パスワードだけでは、フィッシングや漏洩のリスクがあります。MFAを有効にすれば、パスワードが漏れても、スマホアプリの認証コードがないとログインできないので、セキュリティが大幅に向上します。特にルートアカウントやAdminユーザーには必須です。
Q3: 監査ログは本当に全部保存する必要がありますか？コストが心配です。
重要なログは必ず保存しましょう。コンプライアンス要件（GDPR、SOC2など）で監査ログの保存が義務付けられている場合があります。コスト削減のためには、古いログをGlacier/Archiveストレージに移行したり、不要なログレベル（DEBUG）を無効化するなどの工夫が有効です。
Q4: VPCは必ず使わないといけませんか？
本番環境では強く推奨されます。特に、個人情報や機密データを扱う場合は、VPCでネットワークを隔離することがセキュリティのベストプラクティスです。開発環境や小規模なプロジェクトでは、デフォルトVPCでも問題ありませんが、本番環境では専用のVPCを設計しましょう。
Q5: セキュリティの勉強はどこから始めればいいですか？
AWS/GCPの公式ドキュメントがおすすめです。また、以下の認定資格も学習に役立ちます：
・AWS Certified Security – Specialty
・Google Cloud Professional Security Engineer
基礎から体系的に学べるので、資格取得を目指すのも良いでしょう。
・AWS Certified Security – Specialty
・Google Cloud Professional Security Engineer
基礎から体系的に学べるので、資格取得を目指すのも良いでしょう。
Q6: IAMポリシーのActionを調べるには？
AWS/GCPの公式ドキュメントで確認できます。AWSの場合は「IAM Actions Reference」、GCPの場合は「IAM permissions reference」で検索してください。また、AWS Policy Generatorというツールを使うと、GUIでポリシーを作成できます。