MENU
会員登録（無料）
  1. ホーム
  2. 【DEA-C01】WEB問題集：データセキュリティとガバナンス編

【DEA-C01】WEB問題集：データセキュリティとガバナンス編

WEB問題集

DEA-C01#1(data-security)

AWS のセキュリティ基本原則である最小権限の原則 (Principle of Least Privilege) を実現するための、最も適切な実装方法はどれですか。

ディスカッション 0

正解：C

正解の根拠

最小権限の原則 (Principle of Least Privilege) は、各 IAM プリンシパルに対し業務遂行に必要な最小限の権限のみを付与する設計方針です。AWS では IAM Policy をジョブ機能 (Read-Only / Power-User / 特定サービス操作) 単位で作成し、Role や User に明示的に紐付けて運用します。Access Analyzer や IAM Access Advisor で実使用権限を継続的に見直し、不要な権限を削減していくのがベストプラクティスとなります。

最小権限実装の主要ツール

ツール役割用途
IAM Managed PolicyAWS 提供の標準権限セット初期テンプレート
カスタム IAM Policy業務単位の権限定義ジョブ機能別
IAM Access Advisor実使用サービスの可視化権限縮小の根拠
IAM Access Analyzer未使用 Role / 外部公開検出定期見直し
Permissions Boundary権限の上限境界移譲時の安全網

最小権限 IAM Policy 例

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::data-lake-prod",
      "arn:aws:s3:::data-lake-prod/raw/*"
    ]
  }]
}

不正解の理由

  • A: 全管理者権限の事前付与は最小権限原則の真逆であり、誤操作や侵害時の影響が極大化してしまいます。
  • B: 全権 Role の共有 AssumeRole は監査が困難となり、最小権限の趣旨にも反する設計です。
  • D: 暗黙拒否のみでは業務に必要なアクセスもすべて拒否されてしまうため、現実的に運用できません。

参考：IAM ベストプラクティス

DEA-C01#2(data-security)

ある企業のデータエンジニアは、AWS Glue ETL ジョブから特定の S3 バケットへアクセスする権限を設定する必要があります。最もセキュアで適切な方法はどれですか。

ディスカッション 0

正解：D

正解の根拠

Glue ETL ジョブには IAM Role を割当てる仕組みがあり、ジョブ実行中は割当てた Role の一時クレデンシャルで AWS サービスにアクセスします。この Role に対象 S3 バケットへの最小限のアクセスポリシー (s3:GetObject / s3:PutObject など) を付与する方式が、長期キー管理が不要かつ最小権限原則を満たす最適解となります。さらに Trust Policy で glue.amazonaws.com を信頼することで、Glue サービスからのみ AssumeRole 可能な状態に制限できます。

Glue Job IAM Role 構成

要素設定内容
Trust Policyglue.amazonaws.com からの sts:AssumeRole を許可
Permissions Policy必要な S3 / Glue Catalog / KMS 権限のみ付与
Permissions Boundary移譲時の権限上限を制御 (任意)
マネージドポリシーAWSGlueServiceRole (基本権限)

Trust Policy サンプル

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "glue.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}

不正解の理由

  • A: 長期 Access Key の埋込みは漏洩リスクが極大であり、AWS のベストプラクティスに完全に反する設計です。
  • B: Public Read 化は意図しない第三者アクセスを許してしまうため、重大なセキュリティ事故の原因となります。
  • C: EC2 中継は不要な経由構成であり、運用複雑化と障害点増加を招くアンチパターンです。

参考：Glue 用 IAM Role の設定

DEA-C01#3(data-security)

AWS IAM Identity Center (旧 AWS SSO) の主な役割について、正しい説明はどれですか。

ディスカッション 0

正解：B

正解の根拠

AWS IAM Identity Center (旧 AWS SSO) は、複数の AWS Account や SAML / OIDC ベースのビジネスアプリ (Salesforce / Microsoft 365 等) に対する統合シングルサインオンを提供するマネージドサービスです。AWS Organizations と連携した Account 横断のアクセス制御を Permission Set 単位で集中管理でき、ID ソースとして AD / 外部 IdP / Identity Center 内蔵ストアを選択できます。

関連 AWS アイデンティティサービス

サービス主用途本問の正誤
IAM Identity Centerマルチアカウント SSO / ビジネスアプリ SSO正解
IAM Access Analyzer外部公開・未使用権限の分析誤り
AWS Directory Serviceマネージド AD / AD Connector誤り
Cognito User Poolsアプリのエンドユーザー認証誤り

Permission Set 構成例

aws sso-admin create-permission-set   --instance-arn arn:aws:sso:::instance/ssoins-xxxx   --name DataEngineerReadOnly   --session-duration PT8H   --description "Data Lake read access for engineers"

不正解の理由

  • A: VPC 間通信暗号化は VPC Peering / Transit Gateway / Site-to-Site VPN の領域となります。
  • C: IAM Policy の最適化や未使用権限の検出は IAM Access Analyzer が担当する別サービスです。
  • D: AD 移行は AWS Directory Service / AD Connector など別サービスが担う領域となります。

参考：AWS IAM Identity Center

DEA-C01#4(data-security)

AWS KMS で管理する暗号化キーについて、Customer Managed Key (CMK) と AWS Managed Key の違いに関する正しい説明はどれですか。

ディスカッション 0

正解：A

正解の根拠

Customer Managed Key (CMK) は顧客が自分で作成・管理する KMS キーで、キーポリシーの編集・自動ローテーション設定 (年 1 回など)・有効化/無効化・削除待機期間などを自由に制御できます。一方 AWS Managed Key (例: aws/s3, aws/rds) は AWS 各サービスが自動作成し、AWS が完全に管理するため、顧客側でポリシー編集や手動ローテーションはできません。料金面では CMK が月額 $1 / キー、AWS Managed Key は無料となります。

KMS キー種別比較

種別管理者キーポリシー編集手動ローテーション料金
Customer Managed Key (CMK)顧客可可$1 / キー / 月
AWS Managed KeyAWS不可不可 (年 1 回自動)無料
AWS Owned KeyAWS (非表示)不可不可無料

CMK 作成 CLI

aws kms create-key   --description "Data Lake CMK"   --key-usage ENCRYPT_DECRYPT   --key-spec SYMMETRIC_DEFAULT
aws kms enable-key-rotation --key-id <KEY_ID>

不正解の理由

  • B: 説明が逆転しており、CMK が顧客管理、AWS Managed Key が AWS 管理が正しい関係です。
  • C: AWS Managed Key はキーポリシーを直接編集できないため、機能的な違いは明確に存在します。
  • D: 料金体系が逆であり、CMK が課金対象、AWS Managed Key が無料となります。

参考：AWS KMS の概念

DEA-C01#5(data-security)

AWS KMS の Envelope Encryption (エンベロープ暗号化) の仕組みについて、正しい説明はどれですか。

ディスカッション 0

正解：A

正解の根拠

Envelope Encryption は、平文データを Data Key で暗号化し、その Data Key を Master Key (CMK) で暗号化して暗号化済 Data Key として一緒に保存する 2 段階の方式です。Master Key は KMS 内に閉じ込められたまま外に出ず、Data Key だけがアプリケーション側で利用される設計となるため、性能 (大量データの暗号化/復号は Data Key で AES-GCM 等で実施) とセキュリティ (Master Key の保護) を両立できます。S3 SSE-KMS や DynamoDB 暗号化など、AWS の標準暗号化はすべてこの方式を採用しています。

Envelope Encryption の流れ

ステップ動作API
1. Data Key 生成KMS が平文 + 暗号化済 Data Key を返却GenerateDataKey
2. データ暗号化平文 Data Key で AES 暗号化クライアント側
3. 平文 Data Key 破棄メモリから消去クライアント側
4. 暗号化済 Data Key を保存暗号文と一緒に永続化S3 / DynamoDB 等
5. 復号時KMS Decrypt で Data Key を復元Decrypt

boto3 での Envelope 暗号化例

kms = boto3.client('kms')
resp = kms.generate_data_key(KeyId='alias/my-cmk', KeySpec='AES_256')
plaintext_dk = resp['Plaintext']
encrypted_dk = resp['CiphertextBlob']
# plaintext_dk で大量データを暗号化し、encrypted_dk と一緒に保存

不正解の理由

  • B: KMS Master Key は 4KB までしか直接暗号化できないため、大量データには Envelope 方式が必須です。
  • C: KMS は AWS マネージドキー管理サービスであり、クライアント側完結の手法ではありません。
  • D: パスワードベースのキー導出は別の暗号化アプローチであり、KMS の Envelope Encryption とは異なる設計です。

参考：KMS Envelope Encryption

前のページ
次のページ