5問中 0問が回答されています
質問:
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
You must sign in or sign up to start the テスト.
まず、次の操作を完了する必要があります:
正解数 0/問題数5
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
【DEA-78】金融サービス企業 A 社 (アカウント 111111111111) は Amazon QuickSight Enterprise で S3 バケット fin-bucket-prod の data/qs/ 以下の CSV を分析している。
オブジェクトはすべて CMK alias/fin-cmk で SSE-KMS 暗号化されている。
要件:
1) QuickSight のみが当該プレフィックスを読み取れる
2) CMK は QuickSight からの Decrypt のみ許可し他 IAM ユーザーは不可
3) IAM グループ DEUploader には同プレフィックスへの PutObject のみ付与
4) 最小権限で実装する
最適な権限制御設計はどれか。
Amazon QuickSight が SSE-KMS で暗号化された CSV を読むときは、まず quicksight.amazonaws.com を信頼する専用 IAM ロールを作ります。このロールに s3:GetObject と s3:ListBucket を付け、リソースを fin-bucket-prod の data/qs/* とバケットルートに限定すると、他の場所や操作へは広がらず最小権限を維持できます。ロール名を QuickSightAccess などとし、コンソールでデータソースのアクセスロールに登録してください。
CMK alias/fin-cmk のキーポリシーでは kms:Decrypt を先ほどの IAM ロールの ARN のみに許可し、IAM ユーザーや別ロールは Statement から外します。加えて S3 バケットポリシーでも Principal をそのロールと DEUploader グループに絞り、条件キー aws:SourceArn や aws:SourceAccount を併用すれば、KMS と S3 の両方でロールベースの復号と読み取りだけを通し、アップロード専用の主体には鍵が開かない構成になります。
DEUploader グループには PutObject を data/qs/* に絞って IAM ポリシーをアタッチし、バケットポリシー側でも同 ARN へ s3:PutObject のみを明示すると、誤って GetObject や DeleteObject が使える道が閉じられます。最終的に「QuickSight 専用ロール+バケットポリシー+キーポリシー」の三層で要件1〜4を同時に満たせるかを俯瞰し、各権限が過不足なく連携している案を選ぶ視点が大切です。
【DEA-79】金融SaaS企業は顧客取引ログを ap-northeast-1 の Amazon S3 バケットに保存し、SSE-KMS で暗号化する CMK (alias/txn-log-key) を使用している。
監査要件は次のとおり:
①キーは年1回ローテーションする
②復号は別アカウントの IAM ロール arn:aws:iam::222222222222:role/AnalyticsRole だけに許可する
③他バケット用 CMK には影響を与えない。
運用負荷を最小化しつつ AnalyticsRole が当該バケットのオブジェクトを読めるようにする最適な実装はどれか。
クロスアカウントで S3 の SSE-KMS オブジェクトを復号する場合、AWS KMS のカスタマー管理キーはリソースベースポリシーであるキーポリシーに対象 IAM ロールの ARN を Principal として明示的に登録することが必須で、ロール側 IAM ポリシーだけでは権限が成立しません。加えて kms:Decrypt と kms:GenerateDataKey を許可し、Condition で “kms:ViaService”:“s3.ap-northeast-1.amazonaws.com” を指定すれば KMS への API 呼び出しが S3 経由に限定され、監査で求められる最小権限かつソース制限を満たせます。
運用負荷を抑えながら年 1 回のキー更新を担保するには、alias 付きの CMK で AWS KMS の自動キー ローテーションを有効化するのが最もシンプルです。新旧キーは同じキー ID ファミリー内で管理されるため暗号化済みオブジェクトの再暗号化や S3 側の設定変更は不要で、Analytics 用アカウントは継続して kms:Decrypt を利用できます。復号後のオブジェクト取得では S3 バケットポリシーで s3:GetObject を付与するだけで ACL を触らずに済み、ガバナンスと運用保守の両立が図れます。
要件を俯瞰すると、①ローテーションは KMS の自動機能で無人化、②復号は別アカウントの単一 IAM ロールだけに限定、③他バケット用キーへ波及しない、の三点を同時に満たす必要があります。そのためには alias/txn-log-key のキーポリシーをピンポイントで更新し、S3 バケットポリシーでデータプレーン権限を与える構成が IAM ポリシー単独や ACL 変更、暗号化方式の変更より安全かつ低運用コストであるという総合判断になります。
【DEA-80】金融サービス企業はPIIを含む月次CSV(平均5 MB、10万オブジェクト)をSSE-KMSで暗号化したままAmazon S3に保管している。
監査部門は列「ssn」を「***-****」にマスキングしたファイルのみをHTTP(S)経由でダウンロードしたいが、ETLジョブは元データを変更せず参照する必要がある。
追加レイテンシは99パーセンタイルで100 ms以内、ストレージ二重化によるコスト増と運用負荷は最小限とする。
AuditRoleにはマスク済みデータのみ、ETLRoleには完全データを許可する設計を選びなさい。
毎月10万件・平均5MBのCSVをそのまま保存しながら、HTTP(S)取得時だけssn列を伏せ字にしたい場合、オブジェクトを複製せずオンザフライで変換できるAmazon S3 Object Lambdaが最もシンプルです。アクセスポイント経由のGetObject時にLambda関数がCSVをストリーム処理するため追加遅延は数十ミリ秒に抑えやすく、SSE-KMS暗号化されたままでも透過的に利用できます。関数内では1行ごとにカンマ区切りを解析してssnフィールドを***-****に置換し残り文字列をそのまま返すだけなので、メモリ消費もごく小さく済みます。
ストレージコストと運用負荷を最小化という要件は、データを別バケットへ書き出したりCloudFrontのキャッシュレイヤを追加したりクロスリージョンレプリケーションを構成したりすると途端に膨らみます。S3 Object Lambdaなら既存バケットのオブジェクトを1つだけ保持すればよく、動作は完全にリクエスト側で完結するため毎月のバッチジョブやGlue ETLのスケジューリング、CRRの転送料金、署名付きURLの無効化管理などの運用タスクを省けます。
IAMポリシーではAuditRoleにObjectLambdaアクセスポイントARNを、ETLRoleには従来のバケットARNを許可するだけで、同じ物理オブジェクトに対しマスク済みビューとフルビューをきれいに分離できます。アクセスポイントは各ロールやVPCエンドポイントと紐付けられるためネットワーク制御も容易で、サーバーサイド暗号化やストレージクラスの選択といった他要件にも影響せずに拡張できる点を含め、総合的に最も要件をバランス良く満たす選択肢となります。
【DEA-81】医療系 SaaS 企業は PHI を格納する S3 バケット patient-records(月間 PUT/DELETE 合計 2,000 万回)について、オブジェクトレベル操作を 7 年(2,556 日)保持し SQL で即時検索できる監査基盤を構築したい。
運用者は 3 名と少なく追加サーバー管理は不可。
既存の組織単位マルチリージョン CloudTrail では管理イベントのみを収集済みである。
低コストかつ改ざん耐性を確保しながら要件を最も効率的に満たす構成はどれか。
PHI を扱う以上ログ自体の改ざん耐性と暗号化が必須です。CloudTrail のデータイベントは S3 の PUT や DELETE などオブジェクト API を捕捉でき、CloudTrail Lake に送ればフルマネージドで SHA-256 チェーン検証と暗号化、最大 2,556 日の保持、組み込み SQL で即時検索という三つの要件を一気に満たせます。さらに Write のみに絞れば 2,000 万回/月でも課金を抑えられ、追加サーバーや Glue カタログの運用も不要です。組織単位の既存トレイルに設定を足すだけなので運用者 3 名でも負荷は最小です。
同じ S3 の操作ログでもサーバーアクセスログや CloudWatch Events を経由し Athena や OpenSearch Service で分析する構成は、パーティション管理やクラスターサイズ調整、インデックス維持など日常的なチューニングが発生し、さらにログを削除できてしまうため HIPAA 監査で求められる改ざん耐性が弱いです。Glacier Deep Archive へ送れば保管料は安いものの取り出しに数時間かかりリアルタイム性が損なわれます。「低運用かつ即時検索」というキーワードからはやや離れる点を整理しましょう。
オブジェクトレベルの追跡、7 年保持、SQL で即時検索、改ざん耐性、追加サーバーレス、そして大量 PUT/DELETE に対するコスト最適化という複数条件を横断的に比較すると、CloudTrail データイベントを既存組織トレイルに追加し CloudTrail Lake へ保存するアプローチが最も整合的で効率的という総合判断に至ります。
【DEA-82】金融サービス企業は、PII を含む取引ログ (平均 15 TB/日) を Amazon S3 に ORC 形式で蓄積している。
データアナリストは Amazon Athena で当日分のみを照会するが、規制により「customer_ssn」列と VIP 顧客 (vip_flag = 1) 行へのアクセスが厳格に制限されている。
監査部門は誰がどの列・行にアクセス権を変更したかを 7 年間保持する必要がある。
最小作業で要件を満たす設計はどれか。
Amazon Athena で当日分の ORC ファイルだけを速やかに分析するなら、S3 内でデータをそのまま保ちつつ customer_ssn 列と vip_flag=1 の行を制御する仕組みが鍵です。Glue Data Catalog の権限制御はデータベース/テーブル粒度止まりですが、Lake Formation なら LF-Tag と Data Filter を数クリックで設定し、列レベルと行レベルのアクセスを同時にポリシーベースで施行できます。Athena 側はカタログを参照するだけなので追加のクエリ変更や ETL が不要です。
監査チームが求める「誰がどの列・行への権限を変更したかを 7 年残す」という要件は、管理プレーンイベントを確実に記録する AWS CloudTrail と長期保管できる S3 ライフサイクルを組み合わせるのが定番です。Lake Formation のタグ付けやフィルタ定義、さらには Grant/Revoke までが CloudTrail で自動捕捉されるため、追加のカスタムロギングや Lambda を書かなくてもポリシー変更の証跡が残せます。Config は IAM 変更は追えるものの列・行粒度までは対象外である点を整理しておきましょう。
取引ログは 1 日 15 TB と巨大なため、Amazon Macie で検出後にマスク済みデータをコピーしたり、Redshift Spectrum でビューを毎日作り直す方法は転送量や DDL 保守が膨大になります。S3 上の同一データに対し Lake Formation ポリシーを適用すれば、書き換えや再配置を伴わずに Athena から直接アクセス制御が可能です。運用担当が行うのは初回のタグ・フィルタ設定と CloudTrail 保存期間の指定程度で済み、「最小作業で全要件を満たす」という問いに自然に合致します。
列・行レベルの遮断、Athena とのシームレス連携、大容量データのコピー不要、CloudTrail による 7 年監査という複数条件を総合的に眺めると、Lake Formation を活用したポリシーベース制御が最もシンプルでコスト効率の高い設計といえるでしょう。
この教材の改善リクエストがある場合は、お気軽にご報告ください。
カテゴリを選択のうえ、詳細をご記入いただけますと幸いです。
CloudTech(クラウドテック)は多くのユーザーの皆様から改善リクエストをご協力いただき運営できております。
あなたの視点での気づきは他の学習者の迷いを解決する手助けとなります。
運営側でもチェックをしておりますが限界があるため、誠に恐縮ではございますが細かい点でもご遠慮なくご指摘をお願いいたします。
※ 匿名での報告となり、内容は一般公開されません。
※ 技術的なご質問への回答を行うフォームではございませんのでご注意ください。
