4.3標準
決済カード番号を分析に使うが、分析環境へ原番号を置けない。
認可された決済サービスだけが元値へ戻せるようにする。
最も適切な保護方法はどれか。
× 不正解
トークン化・暗号化・ハッシュの用途を比較し、対応表・復元API・監査・削除要求を設計する。
詳細解説
正しいトークン化サービスで置換し、対応表と復元権限を分離する
分析側はトークンだけを扱い、原値の復元を決済サービスと限定主体に閉じ込められる。
分析側はトークンだけを扱い、原値の復元を決済サービスと限定主体に閉じ込められる。
誤りカード番号を単純なBase64へ変換する
Base64は可逆エンコードであり、秘密保護にならない。
Base64は可逆エンコードであり、秘密保護にならない。
誤りS3ファイル名へカード番号を入れる
ログや一覧へ機密情報が漏れる。
ログや一覧へ機密情報が漏れる。
誤りCloudTrailのイベントIDをカード番号にする
監査IDは決済識別子の保護や一貫性を提供しない。
監査IDは決済識別子の保護や一貫性を提供しない。
実際に確かめる
一時的な検証環境で実行できる例です。
AWS tokenization、Amazon Macie sensitive data、KMS encryptionの公式説明を確認する。期待される結果
Base64・ハッシュと、復元主体を限定するトークン化の違いを説明できる。理解のポイント
- Tokenization
- 対応表
- PCI DSS
- 復元権限
確認時の注意
- 確認環境: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- AWS公式DEA-C01 Domain 4・Task 4.3と各サービスの公式ドキュメントを確認する。
基礎のおさらい
再識別管理
トークンから原値へ戻す経路・主体・ログを限定し、分析側へキーを渡さない。
保持と削除
原値・対応表・バックアップの削除期限を法的要件と連動させる。
問題IDAWS-DEA-275
確認環境AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告