はじめに
この記事は、AWS Certified Data Engineer - Associate（DEA-C01）の学習ノートです。
Domain 4「Data Security and Governance（データセキュリティとガバナンス）」は、試験全体の18% を占める重要な分野です。データエンジニアが構築・維持するシステムのセキュリティについて学びます。
データパイプラインを構築する際、データが「誰に」「どのように」アクセスされるかを適切に制御することは、ビジネスの継続性とコンプライアンス遵守のために不可欠です。
自分の学習用にまとめたものですが、同じくDEAを目指す方の参考になれば幸いです。
このドメインで学ぶこと
+----------------------------------------------------------+
| Domain 4: Data Security and Governance |
+----------------------------------------------------------+
| |
| +------------------+ +------------------+ |
| | Task 4.1 | | Task 4.2 | |
| | 認証メカニズム | | 認可メカニズム | |
| | (Authentication) | | (Authorization) | |
| +------------------+ +------------------+ |
| | | |
| v v |
| +------------------+ +------------------+ |
| | Task 4.3 | | Task 4.4 | |
| | データ暗号化 | | 監査ログ | |
| | マスキング | | (Audit Logs) | |
| +------------------+ +------------------+ |
| | | |
| +----------+-----------+ |
| | |
| v |
| +------------------+ |
| | Task 4.5 | |
| | データプライバシー | |
| | ガバナンス | |
| +------------------+ |
+----------------------------------------------------------+
認証と認可の基礎概念
認証（Authentication）と認可（Authorization）の違い
セキュリティを理解する上で最も重要な基礎概念です。
| 概念 | 英語 | 意味 | 例え | 確認すること |
|---|---|---|---|---|
| 認証 | Authentication | ユーザーの本人確認 | 「あなたは誰？」 | IDとパスワード、証明書 |
| 認可 | Authorization | アクセス許可の制御 | 「何ができる？」 | 権限、ポリシー |
認証と認可の流れ
なぜこの区別が重要なのか？
認証が成功しても、認可がなければリソースにアクセスできません。逆に言えば、正しいユーザーであることが確認できても（認証）、そのユーザーに必要な権限がなければ（認可）、操作は拒否されます。これにより、最小権限の原則を実現できます。
Task 4.1: 認証メカニズムの適用
1 AWSにおける認証方法
AWSでは複数の認証方法がサポートされています。
| 認証方法 | 説明 | ユースケース | セキュリティレベル |
|---|---|---|---|
| パスワードベース | ID/パスワードによる認証 | AWSコンソールログイン | 中（MFA推奨） |
| 証明書ベース | SSL/TLS証明書による認証 | IoTデバイス、API通信 | 高 |
| ロールベース | IAMロールを引き受けて認証 | サービス間連携、クロスアカウント | 高 |
2 AWS Identity and Access Management（IAM）
IAMは、AWSリソースへのアクセスを安全にコントロールするための中心的なサービスです。
IAMの主要コンポーネント
+-------------------------------------------------------------------+
| AWS IAM |
+-------------------------------------------------------------------+
| |
| +--------------+ +--------------+ +------------------+ |
| | IAMユーザー | | IAMグループ | | IAMロール | |
| | (User) | | (Group) | | (Role) | |
| +--------------+ +--------------+ +------------------+ |
| | ・1人/1アプリ | | ・複数ユーザー | | ・誰でも引受可能 | |
| | ・永続的認証情報| | をまとめる | | ・一時的認証情報 | |
| +--------------+ +--------------+ +------------------+ |
| | | | |
| +------------------+--------------------+ |
| | |
| v |
| +------------------+ |
| | IAMポリシー | |
| | (Policy) | |
| +------------------+ |
| | 誰が何をできるかを | |
| | JSON形式で定義 | |
| +------------------+ |
+-------------------------------------------------------------------+
IAMユーザーとIAMロールの違い
| 項目 | IAMユーザー | IAMロール |
|---|---|---|
| 対象 | 1人の特定人物/アプリ | 必要な人なら誰でも |
| 認証情報 | 永続的（長期） | 一時的（短期） |
| 用途 | 日常的なアクセス | 一時的なアクセス、サービス間連携 |
| クロスアカウント | 不向き | 最適 |
なぜIAMロールを使うのか？
IAMロールは一時的な認証情報を提供するため、認証情報が漏洩した場合のリスクを軽減できます。また、AWSサービス間の連携では、IAMロールを使うことでサービスに適切な権限を付与できます。
3 IAMポリシーの種類
ポリシーの種類と適用範囲
+------------------+ +------------------+ +------------------+
| AWS管理ポリシー | | カスタマー管理 | | インラインポリシー |
| (AWS Managed) | | ポリシー | | (Inline) |
+------------------+ +------------------+ +------------------+
| ・AWSが作成/管理 | | ・お客様が作成 | | ・1つのエンティティ|
| ・変更不可 | | ・再利用可能 | | 専用 |
| ・汎用的な権限 | | ・カスタマイズ可 | | ・削除時に消える |
+------------------+ +------------------+ +------------------+
| | |
v v v
ReadOnlyAccess等 独自の要件に対応 厳密な1対1の関係
| ポリシー種類 | 作成者 | 変更可否 | 再利用 | 推奨ユースケース |
|---|---|---|---|---|
| AWS管理ポリシー | AWS | 不可 | 可 | 一般的な権限付与 |
| カスタマー管理ポリシー | お客様 | 可 | 可 | 組織固有の要件 |
| インラインポリシー | お客様 | 可 | 不可 | 特定エンティティ専用 |
4 IAMロールの信頼ポリシーとアクセス許可ポリシー
IAMロールには2種類のポリシーが必要です。これを理解することは試験で非常に重要です。
IAMロールに必要な2つのポリシー
+------------------------------------------------------------------+
| IAMロール |
+------------------------------------------------------------------+
| |
| +-------------------------+ +---------------------------+ |
| | 信頼ポリシー | | アクセス許可ポリシー | |
| | (Trust Policy) | | (Permission Policy) | |
| +-------------------------+ +---------------------------+ |
| | 「誰がこのロールを | | 「このロールを引き受けた | |
| | 引き受けられるか」 | | 人が何をできるか」 | |
| +-------------------------+ +---------------------------+ |
| | | |
| v v |
| EC2, Lambda, S3へのアクセス, |
| 他アカウントのIAMユーザー等 DynamoDBへの読み書き等 |
+------------------------------------------------------------------+
試験対策ポイント：ロールを使用するには、信頼ポリシーで「誰が」、アクセス許可ポリシーで「何を」を両方定義する必要があります。
5 サービスロールとサービスにリンクされたロール
| ロール種類 | 説明 | 例 |
|---|---|---|
| サービスロール | AWSサービスがユーザーに代わってアクションを実行するためのロール | Lambda実行ロール |
| サービスにリンクされたロール | 特定のAWSサービスに直接リンクされた事前定義ロール | Organizations用ロール |
6 フェデレーション（ID連携）
社内のActive DirectoryやOktaなどの外部IDプロバイダーを使って、AWSにログインする仕組みです。
なぜフェデレーションが必要なのか？
- 社員ごとにIAMユーザーを作成・管理する手間を削減
- 社内の既存認証基盤を活用できる
- 退職時に社内アカウントを無効化すれば、AWSアクセスも自動的に停止
7 AWS Certificate Manager（ACM）
ACMは、SSL/TLS証明書を作成・管理するサービスです。
| 機能 | 説明 |
|---|---|
| 証明書発行 | パブリック/プライベート証明書を発行 |
| 自動更新 | 有効期限前に自動更新 |
| AWS統合 | ELB、CloudFront、API Gatewayと統合 |
8 AWS Secrets Manager
アプリケーションがデータベースや他のサービスにアクセスする際に必要な認証情報（パスワード、APIキーなど）を安全に管理します。
Secrets Managerの主要機能
+--------------------------------------------------------------------+
| AWS Secrets Manager |
+--------------------------------------------------------------------+
| |
| +------------------+ +------------------+ +------------------+ |
| | シークレット保存 | | 自動ローテーション | | IAM統合 | |
| +------------------+ +------------------+ +------------------+ |
| | ・パスワード | | ・RDS | | ・細かいアクセス | |
| | ・APIキー | | ・Redshift | | 制御 | |
| | ・接続文字列 | | ・DocumentDB | | ・KMS暗号化 | |
| +------------------+ +------------------+ +------------------+ |
+--------------------------------------------------------------------+
| 機能 | 説明 | メリット |
|---|---|---|
| シークレット保存 | 認証情報を暗号化して保存 | コード内にパスワードを書かない |
| 自動ローテーション | 定期的にパスワードを自動変更 | セキュリティ強化、運用負荷軽減 |
| IAM/KMS統合 | アクセス制御と暗号化 | きめ細かい権限管理 |
Secrets Manager vs Parameter Store
| 項目 | Secrets Manager | Parameter Store |
|---|---|---|
| 自動ローテーション | あり | なし |
| 料金 | 有料 | 無料枠あり |
| 用途 | 機密情報専用 | 設定値全般 |
試験対策ポイント：認証情報の自動ローテーションが必要な場合はSecrets Managerを選択します。
9 マネージドサービスとアンマネージドサービスの違い
AWSサービスを選択する際、セキュリティの観点から「誰が何を管理するか」を理解することが重要です。
| 項目 | マネージドサービス | アンマネージドサービス |
|---|---|---|
| インフラ管理 | AWSが管理 | お客様が管理 |
| パッチ適用 | AWSが自動適用 | お客様が手動適用 |
| スケーリング | 自動または簡単に設定 | 手動で設定 |
| セキュリティ責任 | 共有（AWS側の責任大） | 共有（お客様側の責任大） |
| 例 | RDS, Redshift, Glue | EC2上のDB, EMRクラスター |
責任共有モデル
+------------------------------------------------------------------+
| セキュリティの責任 |
+------------------------------------------------------------------+
| |
| マネージドサービス（例：RDS） |
| +---------------------------+---------------------------+ |
| | AWS の責任 | お客様の責任 | |
| +---------------------------+---------------------------+ |
| | ・OS パッチ適用 | ・IAM 設定 | |
| | ・DB エンジンのパッチ | ・セキュリティグループ | |
| | ・ハードウェア管理 | ・暗号化の有効化 | |
| | ・物理セキュリティ | ・バックアップ設定 | |
| +---------------------------+---------------------------+ |
| |
| アンマネージドサービス（例：EC2上のDB） |
| +---------------------------+---------------------------+ |
| | AWS の責任 | お客様の責任 | |
| +---------------------------+---------------------------+ |
| | ・ハードウェア管理 | ・OS パッチ適用 | |
| | ・物理セキュリティ | ・DB インストール/設定 | |
| | ・ネットワークインフラ | ・セキュリティグループ | |
| | | ・暗号化設定 | |
| | | ・バックアップ管理 | |
| +---------------------------+---------------------------+ |
+------------------------------------------------------------------+
なぜこの違いが重要なのか？
- マネージドサービスを選択すると、セキュリティの運用負荷を軽減できる
- ただし、IAM設定やネットワーク設定はお客様の責任のまま
- 試験では、適切なサービス選択とセキュリティ責任の理解が問われる
10 VPCセキュリティの基礎
データパイプラインをサポートするVPC内のネットワークトラフィックを制御する方法を理解することも重要です。
| コンポーネント | 機能 | レベル |
|---|---|---|
| セキュリティグループ | ステートフルなファイアウォール | インスタンスレベル |
| ネットワークACL | ステートレスなファイアウォール | サブネットレベル |
| VPCエンドポイント | プライベート接続 | サービスレベル |
セキュリティグループとネットワークACLの比較
| 項目 | セキュリティグループ | ネットワークACL |
|---|---|---|
| 適用レベル | インスタンス（ENI） | サブネット |
| ステート | ステートフル（戻りトラフィック自動許可） | ステートレス（明示的なルール必要） |
| ルール | 許可ルールのみ | 許可・拒否ルール |
| 評価順序 | すべてのルールを評価 | 番号順に評価 |
| デフォルト | すべてのアウトバウンド許可 | すべて許可 |
11 S3 Access PointsへのIAMポリシー適用
S3 Access Pointsは、S3バケットへのアクセスを簡素化・制御するための機能です。大規模な共有データセットに対して、アプリケーションごとに異なるアクセス許可を設定できます。
S3 Access Pointsの仕組み
+------------------------------------------------------------------+
| |
| アプリA アプリB アプリC |
| | | | |
| v v v |
| +--------+ +--------+ +--------+ |
| | Access | | Access | | Access | ← アプリごとに異なる |
| | Point | | Point | | Point | アクセス許可を設定 |
| | A | | B | | C | |
| +--------+ +--------+ +--------+ |
| | | | |
| +-----+-----+-----+-----+ |
| | |
| v |
| +------------+ |
| | S3 バケット | |
| +------------+ |
+------------------------------------------------------------------+
Access Pointポリシーの重要なポイント
アクセスを許可するには、Access Pointポリシーとバケットポリシーの両方で許可が必要です。
Access Pointとバケットポリシーの関係
+------------------+ +------------------+
| Access Point | | バケットポリシー |
| ポリシー | AND | |
| （アクセス許可） | | （アクセス許可） |
+------------------+ +------------------+
| |
+------------+-------------+
|
v
アクセス許可が有効
バケットポリシーでAccess Pointに委任する例
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": "*"},
"Action": "s3:*",
"Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
"Condition": {
"StringEquals": {
"s3:DataAccessPointAccount": "123456789012"
}
}
}]
}
この設定により、指定したアカウントのAccess Pointにアクセス制御を委任できます。
12 AWS PrivateLinkへのIAMポリシー適用
AWS PrivateLinkは、VPCとAWSサービス（またはVPCエンドポイントサービス）間のプライベート接続を提供します。
AWS PrivateLinkの仕組み
+-------------------------------------------------------------------+
| お客様VPC |
| +---------------------------+ |
| | | |
| | +-------------------+ | |
| | | EC2 / Lambda | | |
| | +-------------------+ | |
| | | | |
| | v | |
| | +-------------------+ | +-------------------+ |
| | | VPC Endpoint |----+----->| AWS サービス | |
| | | (Interface) | | | (S3, KMS等) | |
| | +-------------------+ | +-------------------+ |
| | | |
| +---------------------------+ |
| |
| ※ トラフィックはAWSネットワーク内を通過 |
| ※ インターネットを経由しない |
+-------------------------------------------------------------------+
VPCエンドポイントポリシー
VPCエンドポイントには、エンドポイント経由のアクセスを制御するポリシーをアタッチできます。
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": [
"ec2:CreateVpcEndpoint",
"ec2:ModifyVpcEndpoint",
"ec2:DescribeVpcEndpoints",
"ec2:DeleteVpcEndpoints"
],
"Resource": "*"
}]
}
プライベートDNS名の条件キー
特定のプライベートDNS名を持つVPCエンドポイントのみ作成を許可する場合：
{
"Condition": {
"StringEquals": {
"ec2:VpceServicePrivateDnsName": "my-service.example.com"
}
}
}
なぜPrivateLinkが重要なのか？
- データがインターネットを経由しないため、セキュリティが向上
- NATゲートウェイやインターネットゲートウェイが不要
- データエンジニアリングでは、S3やKMSへのプライベートアクセスに使用
Task 4.2: 認可メカニズムの適用
1 認可の目的
認可の目的は、認証済みプリンシパルが最小権限で対象リソースにアクセスできるようにすることです。
2 最小権限の原則（Principle of Least Privilege）
定義：ユーザーやサービスに対して、タスクを実行するために必要な最小限の権限のみを付与する原則。
最小権限の原則
悪い例（過剰な権限）:
+--------------------------------------------------+
| { |
| "Effect": "Allow", |
| "Action": "s3:*", ← すべての操作を許可 |
| "Resource": "*" ← すべてのリソース |
| } |
+--------------------------------------------------+
良い例（最小権限）:
+--------------------------------------------------+
| { |
| "Effect": "Allow", |
| "Action": "s3:GetObject", ← 必要な操作のみ |
| "Resource": "arn:aws:s3:::my-bucket/data/*" |
| ↑ 特定リソースのみ |
| } |
+--------------------------------------------------+
なぜ最小権限が重要なのか？
- セキュリティ侵害時の被害を最小限に抑える
- 誤操作によるデータ損失を防ぐ
- コンプライアンス要件を満たす
3 RBAC（ロールベースアクセスコントロール）とABAC（属性ベースアクセスコントロール）
| 方式 | 説明 | メリット | デメリット |
|---|---|---|---|
| RBAC | ロール（役割）に基づいてアクセスを制御 | 管理が容易 | 複雑なビジネスロジックに不向き |
| ABAC | 属性（タグ）に基づいてアクセスを制御 | 柔軟で動的 | 初期設定が複雑 |
RBACの例:
+----------------+ +------------------+ +----------------+
| デベロッパー | --> | DevRole | --> | 開発環境のみ |
| ロール | | | | アクセス可能 |
+----------------+ +------------------+ +----------------+
ABACの例:
+----------------+ +------------------+ +----------------+
| ユーザーA | --> | access-project | --> | project=Heart |
| (タグ: Heart) | | = Heart | | のリソースのみ |
+----------------+ +------------------+ +----------------+
試験対策ポイント：大量のリソースを少数のポリシーで管理したい場合はABACが有効です。
4 AWS Lake Formationによるアクセス制御
Lake Formationは、データレイク内のデータに対するきめ細かいアクセス制御を一元管理します。
Lake Formationのアクセス制御レベル
| レベル | 説明 | ユースケース |
|---|---|---|
| データベースレベル | データベース全体へのアクセス | 部門別のデータベース分離 |
| テーブルレベル | テーブル単位のアクセス | テーブル別の権限管理 |
| 列レベル | 特定列へのアクセス制限 | 機密情報の列を非表示 |
| 行レベル | 特定行へのアクセス制限 | ユーザー別データフィルタ |
| セルレベル | 行×列の組み合わせ | 最も細かい制御 |
Lake Formationのデータフィルター
+------------------------------------------------------------------+
| 顧客テーブル |
+------------------------------------------------------------------+
| ID | 名前 | メール | 電話番号 | 地域 |
+------------------------------------------------------------------+
| 001 | 田中 | tanaka@example.com | 03-xxxx-xxxx | 東京 |
| 002 | 鈴木 | suzuki@example.com | 06-xxxx-xxxx | 大阪 |
| 003 | 佐藤 | sato@example.com | 052-xxx-xxxx | 名古屋 |
+------------------------------------------------------------------+
行フィルター（地域='東京'）適用後:
+------------------------------------------------------------------+
| ID | 名前 | メール | 電話番号 | 地域 |
+------------------------------------------------------------------+
| 001 | 田中 | tanaka@example.com | 03-xxxx-xxxx | 東京 |
+------------------------------------------------------------------+
列フィルター（電話番号を除外）適用後:
+------------------------------------------------------------------+
| ID | 名前 | メール | 地域 |
+------------------------------------------------------------------+
| 001 | 田中 | tanaka@example.com | 東京 |
+------------------------------------------------------------------+
LF-TBAC（タグベースアクセスコントロール）
Lake FormationのLFタグを使用すると、数百・数千のデータベースアクセス許可を効率的に管理できます。
| 特徴 | 説明 |
|---|---|
| スケーラブル | 数千のリソースを少数のタグで管理 |
| 柔軟 | タグをデータベース、テーブル、列に添付可能 |
| 統合 | Athena、EMR、Glue ETL、Redshift Spectrumと連携 |
注意：LFタグは行には直接添付できません。行レベルの制御にはデータフィルターを使用します。
5 Amazon Redshiftのアクセス制御
Redshiftのユーザー階層
+------------------------------------------------------------------+
| Redshiftクラスター |
+------------------------------------------------------------------+
| |
| +------------------+ |
| | スーパーユーザー | ← すべてのDBの所有者権限 |
| +------------------+ |
| | |
| v |
| +------------------+ +------------------+ |
| | 一般ユーザー | | 一般ユーザー | |
| +------------------+ +------------------+ |
| | | |
| v v |
| +------------------+ +------------------+ |
| | ロール（権限） | | グループ（権限） | |
| +------------------+ +------------------+ |
+------------------------------------------------------------------+
Redshiftでの権限管理コマンド
| コマンド | 説明 |
|---|---|
CREATE USER |
ユーザー作成 |
CREATE ROLE |
ロール作成 |
GRANT |
権限付与 |
REVOKE |
権限取り消し |
Task 4.3: データ暗号化とマスキング
1 暗号化の基礎
保管中の暗号化（Encryption at Rest）と転送中の暗号化（Encryption in Transit）
| 種類 | 対象 | 方法 |
|---|---|---|
| 保管中の暗号化 | ストレージに保存されたデータ | KMS、SSE |
| 転送中の暗号化 | ネットワーク上を移動するデータ | TLS/SSL |
データのライフサイクルと暗号化
+----------+ +------------+ +----------+
| データ | -----> | ネットワーク| -----> | ストレージ |
| (送信元) | | (転送中) | | (保管中) |
+----------+ +------------+ +----------+
| |
v v
TLS/SSL暗号化 KMS/SSE暗号化
2 AWS Key Management Service（KMS）
KMSは、データを暗号化するための暗号化キーを作成・管理するサービスです。
KMSキーの種類
| キー種類 | 管理者 | ユースケース | コスト |
|---|---|---|---|
| AWS管理キー | AWS | デフォルト暗号化 | 無料 |
| カスタマー管理キー（CMK） | お客様 | カスタム要件 | 有料 |
| カスタマー提供キー | お客様 | 独自キー使用 | 有料 |
KMSの主要機能
| 機能 | 説明 |
|---|---|
| キー作成 | 対称/非対称キーの作成 |
| 自動ローテーション | 年1回の自動キーローテーション |
| CloudTrail統合 | キー使用状況の監査ログ |
| クロスアカウント | 他アカウントとのキー共有 |
試験対策ポイント：AWS Glue Data Catalogの暗号化には対称キーのみ対応しています。非対称キーは使用できません。
クロスアカウント境界での暗号化設定
複数のAWSアカウント間でデータを共有する場合、暗号化キーのアクセス許可も適切に設定する必要があります。
クロスアカウント暗号化の仕組み
+------------------------------------------------------------------+
| |
| アカウントA（データ所有者） アカウントB（データ利用者） |
| +------------------+ +------------------+ |
| | S3バケット | | アプリケーション | |
| | (暗号化データ) |<-------------| (データ読み取り) | |
| +------------------+ +------------------+ |
| | | |
| v v |
| +------------------+ +------------------+ |
| | KMS キー |<------------- | IAMロール | |
| | (キーポリシー) | キー使用許可 | (アカウントB) | |
| +------------------+ +------------------+ |
| |
+------------------------------------------------------------------+
クロスアカウントKMSキー使用に必要な設定
| 設定場所 | 必要な設定 |
|---|---|
| KMSキーポリシー（アカウントA） | アカウントBのIAMロールにkms:Decrypt等を許可 |
| IAMポリシー（アカウントB） | アカウントAのKMSキーへのアクセスを許可 |
| S3バケットポリシー（アカウントA） | アカウントBからのGetObject等を許可 |
KMSキーポリシーの例（クロスアカウント許可）
{
"Sid": "Allow use of the key from Account B",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT-B-ID:role/DataAccessRole"
},
"Action": [
"kms:Decrypt",
"kms:DescribeKey"
],
"Resource": "*"
}
なぜクロスアカウント設定が重要なのか？
- 組織内の複数チーム/部門がデータを共有する場合に必要
- データレイクアーキテクチャでは、中央のデータアカウントから各分析アカウントへのアクセスを許可
- Lake Formationと組み合わせて、きめ細かいクロスアカウントアクセス制御が可能
3 S3の暗号化オプション
S3には複数の暗号化方式があり、要件に応じて選択します。
| 暗号化方式 | キー管理 | 特徴 | ユースケース |
|---|---|---|---|
| SSE-S3 | AWS | 最も簡単、追加料金なし | デフォルト暗号化 |
| SSE-KMS | AWS/お客様 | 監査、アクセス制御が可能 | コンプライアンス要件 |
| SSE-C | お客様 | 独自キーを使用 | 独自キー管理が必須の場合 |
| DSSE-KMS | AWS/お客様 | 2層の暗号化 | 高度なコンプライアンス |
| クライアント側暗号化 | お客様 | クライアントで暗号化 | エンドツーエンド暗号化 |
暗号化方式の選択フローチャート
暗号化が必要？
|
+------------+------------+
| |
Yes No
| |
キー管理が必要？ SSE-S3
|
+--------+--------+
| |
Yes No
| |
独自キー？ SSE-KMS
|
+---+-----+
| |
Yes No
| |
SSE-C SSE-KMS
※2層暗号化が必要な場合 → DSSE-KMS
重要な制限事項
| 制限事項 | 説明 |
|---|---|
| SSE-C + Redshift COPY | Redshift COPYコマンドはSSE-Cをサポートしない |
| DSSE-KMS | 2層暗号化が必要なコンプライアンス要件向け |
4 AWS CloudHSM
CloudHSMは、専用のハードウェアセキュリティモジュール（HSM）を提供するサービスです。
| 項目 | KMS | CloudHSM |
|---|---|---|
| 管理 | AWS管理 | お客様管理 |
| ハードウェア | 共有 | 専用 |
| コンプライアンス | FIPS 140-2 Level 2 | FIPS 140-2 Level 3 |
| 用途 | 一般的な暗号化 | 厳格な規制要件 |
5 データマスキングとトークナイゼーション
用語の整理
| 技術 | 説明 | 可逆性 | ユースケース |
|---|---|---|---|
| 暗号化 | アルゴリズムでデータを変換 | 可逆（キーあり） | データ保護全般 |
| トークナイゼーション | ランダムなトークンに置換 | 可逆（ボールト参照） | クレジットカード番号 |
| データマスキング | 値を変更して難読化 | 不可逆 | テスト環境、レポート |
| データ匿名化 | 個人識別情報を削除 | 不可逆 | 統計分析 |
| キーソルティング | ハッシュにランダムデータを追加 | 不可逆 | パスワード保護 |
トークナイゼーションの仕組み
+------------------+ +------------------+ +------------------+
| アプリケーション | -----> | トークンボールト | -----> | 暗号化データベース |
| | | (トークン化) | | (実データ保存) |
+------------------+ +------------------+ +------------------+
| | |
v v v
4532-xxxx-1234 TKN_ABC123 暗号化された
(クレジットカード) (トークン) 実際のカード番号
Amazon Redshiftの動的データマスキング（DDM）
Redshiftでは、クエリ時にデータを動的にマスキングできます。
| 特徴 | 説明 |
|---|---|
| クエリ時マスキング | 元データを変更せずにマスク |
| ロール別設定 | ロールごとに異なるマスクを適用 |
| 列レベル | 特定の列にマスキングを適用 |
| セルレベル | 条件付きでセルレベルのマスキング |
6 各サービスの暗号化対応
| サービス | 保管中の暗号化 | 転送中の暗号化 | 備考 |
|---|---|---|---|
| S3 | SSE-S3/KMS/C, DSSE-KMS | HTTPS | デフォルト暗号化推奨 |
| Redshift | KMS/CloudHSM | SSL | クラスターレベル |
| DynamoDB | KMS | HTTPS | テーブルレベル |
| EMR | EBS暗号化、LUKS | TLS | セキュリティ設定で管理 |
| Glue | KMS | TLS | Data Catalog暗号化 |
| RDS | KMS | SSL/TLS | インスタンスレベル |
Task 4.4: 監査用ログの準備
1 ログの重要性
ログは以下の目的で必要です：
- コンプライアンス：HIPAA、PCIなどの規制要件
- セキュリティ監査：不正アクセスの検出
- トラブルシューティング：問題の原因特定
- 運用改善：パフォーマンス分析
2 AWS CloudTrail
CloudTrailは、AWSアカウント内のすべてのAPI呼び出しを記録するサービスです。
CloudTrailの仕組み
+------------------+ +------------------+ +------------------+
| ユーザー/サービス | -----> | AWS API | -----> | CloudTrail |
| (API呼び出し) | | | | (ログ記録) |
+------------------+ +------------------+ +------------------+
|
+-----------------------------------+
| | |
v v v
+----------+ +-----------+ +------------------+
| S3 | | CloudWatch| | CloudTrail Lake |
| バケット | | Logs | | (SQLクエリ) |
+----------+ +-----------+ +------------------+
CloudTrailのイベントタイプ
| イベント種類 | 説明 | 例 |
|---|---|---|
| 管理イベント | リソースに対する管理操作 | CreateBucket, DeleteTable |
| データイベント | データに対する操作 | GetObject, PutItem |
| インサイトイベント | 異常なAPI活動を検出 | 急激なAPI呼び出し増加 |
CloudTrail Lake
CloudTrail Lakeは、CloudTrailイベントをSQLでクエリできる機能です。
| 特徴 | 説明 |
|---|---|
| SQLクエリ | 標準SQLでイベントを分析 |
| クロスアカウント | 複数アカウントのイベントを一元管理 |
| JOIN対応 | 複数のイベントデータストアをJOIN |
| 長期保存 | 最大7年間のデータ保持 |
試験対策ポイント：CloudTrail LakeはQuickSightのデータソースとして直接使用できません。QuickSightでレポートを作成する場合は、CloudTrail→S3→Athena→QuickSightの構成が必要です。
3 Amazon CloudWatch Logs
CloudWatch Logsは、アプリケーションやAWSサービスのログを収集・保存・分析するサービスです。
CloudWatch Logsの構造
+------------------------------------------------------------------+
| CloudWatch Logs |
+------------------------------------------------------------------+
| |
| +---------------------------+ |
| | ロググループ | ← ログの論理的なコンテナ |
| | (Log Group) | |
| +---------------------------+ |
| | |
| v |
| +-------------+ +-------------+ +-------------+ |
| | ログストリーム| | ログストリーム | | ログストリーム| |
| | (Stream 1) | | (Stream 2) | | (Stream 3) | |
| +-------------+ +-------------+ +-------------+ |
| | | | |
| v v v |
| ログイベント ログイベント ログイベント |
+------------------------------------------------------------------+
ログ保持ポリシー
| 設定 | 説明 |
|---|---|
| デフォルト | 無期限保持 |
| カスタム | 1日〜10年の保持期間を設定可能 |
| コスト最適化 | 古いログをS3に移動 |
4 CloudWatch Logs Insights
CloudWatch Logs Insightsは、ログデータをインタラクティブに検索・分析する機能です。
| 特徴 | 説明 |
|---|---|
| クエリ言語 | 専用のクエリ言語を使用 |
| 自動フィールド検出 | JSONログのフィールドを自動認識 |
| 可視化 | クエリ結果をグラフ化 |
試験対策ポイント：AWS WAFログの分析にはCloudWatch Logs Insightsが最適です。
5 Amazon Athena CloudWatchコネクタ
AthenaからCloudWatch Logsに対してSQLクエリを実行できます。
Athena CloudWatchコネクタのマッピング
CloudWatch Athena
+--------------+ +--------------+
| Log Group | ---> | Schema |
+--------------+ +--------------+
| Log Stream | ---> | Table |
+--------------+ +--------------+
| all_log_ | ---> | View |
| streams | | (全ストリーム) |
+--------------+ +--------------+
6 Amazon EMRのログ管理
| ログの種類 | 保存場所 | 用途 |
|---|---|---|
| ステップログ | S3（設定時） | ジョブのデバッグ |
| アプリケーションログ | プライマリノード | 詳細なデバッグ |
| CloudTrailログ | S3 | API呼び出しの監査 |
7 Amazon OpenSearch Serviceでのログ分析
大量のログデータを分析する場合、Amazon OpenSearch Service（旧Amazon Elasticsearch Service）が有効です。
OpenSearch Serviceを使用したログ分析アーキテクチャ
+------------------+ +------------------+ +------------------+
| ログソース | -----> | Kinesis Data | -----> | OpenSearch |
| (CloudWatch, | | Firehose | | Service |
| アプリログ等) | | | | |
+------------------+ +------------------+ +------------------+
|
v
+------------------+
| OpenSearch |
| Dashboards |
| (可視化) |
+------------------+
| 特徴 | 説明 |
|---|---|
| 全文検索 | ログメッセージ内のキーワード検索 |
| リアルタイム分析 | ストリーミングデータの即座の分析 |
| 可視化 | OpenSearch Dashboardsでダッシュボード作成 |
| スケーラビリティ | 大量のログデータに対応 |
ログ分析ツールの使い分け
| シナリオ | 推奨ツール | 理由 |
|---|---|---|
| CloudWatch Logsの簡単なクエリ | CloudWatch Logs Insights | 設定不要、即座に使用可能 |
| CloudTrailイベントのSQL分析 | CloudTrail Lake | ネイティブ統合、運用オーバーヘッド最小 |
| S3に保存されたログのアドホッククエリ | Athena | サーバーレス、従量課金 |
| 大量ログのリアルタイム分析と可視化 | OpenSearch Service | 全文検索、ダッシュボード |
| 大量ログのバッチ分析 | EMR | 大規模データ処理に最適 |
Task 4.5: データプライバシーとガバナンス
1 個人識別情報（PII）の保護
PII（Personally Identifiable Information）は、個人を特定できる情報です。
| PIIの例 | 説明 |
|---|---|
| 氏名 | 個人を直接特定 |
| メールアドレス | 連絡先情報 |
| 電話番号 | 連絡先情報 |
| 住所 | 所在地情報 |
| 社会保障番号 | 政府発行ID |
| クレジットカード番号 | 金融情報 |
2 Amazon Macie
MacieはS3バケット内の機密データを自動検出するサービスです。
| 検出可能なデータ | 例 |
|---|---|
| PII | 氏名、住所、電話番号 |
| 金融データ | クレジットカード番号 |
| 認証情報 | APIキー、パスワード |
| カスタムデータ | 独自のパターン定義可能 |
3 AWS Glue Detect PII変換
AWS Glueには、ETL処理中にPIIを検出・処理する組み込み機能があります。
| 機能 | 説明 |
|---|---|
| PII検出 | 組み込みのPIIパターンで検出 |
| マスキング | 検出したPIIをマスク |
| リダクション | 検出したPIIを削除 |
試験対策ポイント：PII検出には、カスタムLambdaよりもAWS Glue Detect PII変換を使用する方が、運用オーバーヘッドが少なくなります。
4 データ主権（Data Sovereignty）
データ主権とは、データが保存されている国や地域の法律に従う必要があるという概念です。
データ主権の考慮事項
+------------------------------------------------------------------+
| データ主権 |
+------------------------------------------------------------------+
| |
| +------------------+ +------------------+ |
| | リージョン制限 | | バックアップ制限 | |
| +------------------+ +------------------+ |
| | 特定リージョンのみ | | 許可されたリージョン| |
| | でのデータ保存 | | のみへのバックアップ| |
| +------------------+ +------------------+ |
| |
| +------------------+ +------------------+ |
| | レプリケーション | | データ転送 | |
| | 制限 | | 制限 | |
| +------------------+ +------------------+ |
| | クロスリージョン | | 国境を越えた | |
| | レプリケーション | | データ移動の制限 | |
| | の禁止/許可 | | | |
| +------------------+ +------------------+ |
+------------------------------------------------------------------+
実装方法
| 方法 | 説明 |
|---|---|
| S3バケットポリシー | 特定リージョンのみへのアクセス制限 |
| SCP（サービスコントロールポリシー） | 組織レベルでのリージョン制限 |
| AWS Config | 設定変更の監視 |
| AWS Backup | バックアップ先リージョンの制御 |
5 AWS Config
AWS Configは、AWSリソースの設定変更を追跡するサービスです。
AWS Configの動作
+------------------+ +------------------+ +------------------+
| リソース設定変更 | -----> | AWS Config | -----> | 設定項目 |
| (VPC, S3等) | | (変更検出) | | (Configuration |
+------------------+ +------------------+ | Item) |
| +------------------+
v
+------------------+
| Configルール |
| (評価・準拠チェック)|
+------------------+
|
v
+------------------+
| 通知/修復アクション |
+------------------+
| 機能 | 説明 |
|---|---|
| 設定履歴 | リソースの設定変更履歴を記録 |
| 設定スナップショット | 特定時点の設定状態を保存 |
| Configルール | 設定のコンプライアンスをチェック |
| 修復アクション | 非準拠リソースの自動修復 |
6 AWS Backup
AWS Backupは、複数のAWSサービスにわたるバックアップを一元管理します。
| 機能 | 説明 |
|---|---|
| バックアッププラン | バックアップの頻度と保持期間を定義 |
| バックアップボールト | バックアップの保存先（独自の暗号化キー） |
| クロスリージョン | 別リージョンへのバックアップコピー |
| クロスアカウント | 別アカウントへのバックアップコピー |
| Audit Manager | バックアップコンプライアンスの監査 |
7 データ共有とガバナンス
Amazon Redshiftデータ共有
Redshiftでは、クラスター間でデータを共有できます。
| 考慮事項 | 説明 |
|---|---|
| ユーザー削除制限 | データ共有オブジェクトを所有/権限を持つユーザーは削除不可 |
| Lake Formation統合 | データ共有へのアクセス許可を一元管理 |
| 列レベルアクセス | GRANTステートメントで列レベル制御 |
試験対策：サービス比較と選択基準
1 認証情報管理の選択
| シナリオ | 推奨サービス | 理由 |
|---|---|---|
| DBパスワードの自動ローテーション | Secrets Manager | 自動ローテーション機能あり |
| 設定値の保存（機密性低） | Parameter Store | 無料、シンプル |
| Lambda環境変数に保存 | 非推奨 | 機密情報の保存には不適切 |
2 暗号化方式の選択
| シナリオ | 推奨方式 | 理由 |
|---|---|---|
| 基本的なS3暗号化 | SSE-S3 | 最も簡単 |
| 監査・アクセス制御が必要 | SSE-KMS | CloudTrail統合 |
| 2層暗号化が必要 | DSSE-KMS | コンプライアンス要件 |
| Redshift COPYコマンド | SSE-KMS | SSE-Cは非対応 |
3 アクセス制御の選択
| シナリオ | 推奨方法 | 理由 |
|---|---|---|
| S3バケット全体のアクセス制御 | IAMポリシー、バケットポリシー | 標準的な方法 |
| テーブルの行/列レベル制御 | Lake Formationデータフィルター | きめ細かい制御 |
| 大量リソースの管理 | ABAC（タグベース） | スケーラブル |
4 監査ログ分析の選択
| シナリオ | 推奨方法 | 理由 |
|---|---|---|
| CloudTrailイベントのSQLクエリ | CloudTrail Lake | 運用オーバーヘッド最小 |
| QuickSightでのレポート作成 | CloudTrail→S3→Athena | CloudTrail LakeはQuickSight非対応 |
| AWS WAFログの分析 | CloudWatch Logs Insights | 最適化された分析機能 |
5 PII検出の選択
| シナリオ | 推奨方法 | 理由 |
|---|---|---|
| S3バケットの機密データ検出 | Amazon Macie | 自動検出機能 |
| ETL処理中のPII検出 | AWS Glue Detect PII変換 | 組み込み機能 |
| カスタムLambda | 非推奨 | 運用オーバーヘッドが大きい |
6 ネットワークセキュリティの選択
| シナリオ | 推奨方法 | 理由 |
|---|---|---|
| VPC内からAWSサービスへのプライベートアクセス | VPCエンドポイント（PrivateLink） | インターネットを経由しない |
| 複数アプリからS3バケットへの異なるアクセス権限 | S3 Access Points | アプリごとのポリシー管理が容易 |
| インスタンスレベルのトラフィック制御 | セキュリティグループ | ステートフル、許可ルールのみ |
| サブネットレベルのトラフィック制御 | ネットワークACL | ステートレス、拒否ルールも可能 |
7 ログ分析ツールの選択
| シナリオ | 推奨方法 | 理由 |
|---|---|---|
| CloudWatch Logsの簡単なクエリ | CloudWatch Logs Insights | 設定不要、即座に使用可能 |
| CloudTrailイベントのSQL分析 | CloudTrail Lake | ネイティブ統合 |
| S3のログデータに対するアドホッククエリ | Athena | サーバーレス、従量課金 |
| 大量ログのリアルタイム分析・可視化 | OpenSearch Service | 全文検索、ダッシュボード |
| 大規模ログのバッチ処理 | EMR | 大規模データ処理に最適 |
よくある誤答パターンと正しい理解
| 誤答パターン | 正しい理解 |
|---|---|
| Lambda環境変数に認証情報保存 | Secrets Managerを使用する |
| IAM DB認証 + SQL Server | IAM DB認証はMySQL/PostgreSQL/MariaDBのみ |
| SSE-C + Redshift COPY | Redshift COPYはSSE-KMSのみ対応 |
| S3バケットポリシーで行レベル制御 | Lake Formationデータフィルターを使用 |
| CloudTrail Lake + QuickSight | CloudTrail Lakeは直接接続不可 |
| Glue Data Catalog + 非対称キー | Glue Data Catalogは対称キーのみ |
| Lambda関数で週次キーローテーション | KMSの自動ローテーション機能を使用 |
| Access Pointポリシーだけでアクセス許可 | バケットポリシーとAccess Pointポリシーの両方で許可が必要 |
| クロスアカウントでKMSキーのIAMポリシーのみ設定 | KMSキーポリシーとIAMポリシーの両方で許可が必要 |
| インターネット経由でS3にアクセス（セキュリティ要件あり） | VPCエンドポイント（PrivateLink）を使用 |
まとめ
Domain4はDEA試験の18%を占める重要なドメインです。データパイプラインのセキュリティとガバナンスについて包括的に学びました。
特に押さえておきたいポイントは以下の5つです。
- 認証と認可 - IAMの正しい使い方、最小権限の原則
- 暗号化 - KMSの各暗号化オプションの使い分け、クロスアカウント設定
- アクセス制御 - Lake Formationによるきめ細かい制御、RBAC vs ABAC
- 監査 - CloudTrailとCloudWatch Logsの活用、ログ分析ツールの選択
- プライバシー - PII検出とデータ主権への対応
この記事が、DEA試験を目指す方の参考になれば幸いです！