SAA-1.3適切なデータセキュリティ管理を判断する。

ヒントボタン

パブリック CA から 90 日ごとに届く PEM 形式のサーバー証明書を扱うなら、Application Load Balancer の HTTPS リスナーに直接アップロードしてしまうと次回更新時に手動でリスナーを差し替えるスクリプトやメンテナンス時間が生じます。AWS Certificate Manager にインポートしておけば更新後の証明書を同じ ARN で置換でき、ALB 側では無停止で配信を続けられる点が運用面で大きなメリットになります。

さらに ACM はインポート証明書に対し 45、30、15、7、1 日前に Certificate-expiration という EventBridge ルール対象のイベントを自動発行します。EventBridge から Amazon SNS へ転送してメール通知し、同時に AWS Lambda で Slack Webhook を呼び出すだけで、期限 30 日前のリマインダー要件をコードレスに満たせるため、CloudWatch Synthetics や Config のカスタムルールを組むよりもシンプルでコストも無料枠の範囲に収まりやすくなります。

公開サイトである以上パブリック PKI に信頼される必要があり、ACM Private CA ではブラウザ警告、CloudFront では専用リージョン制約、ALB 直接アップロードでは手作業とダウンタイムが懸念となります。更新通知の自動化、ゼロダウンタイム交代、料金の低さという三つの要件を同時に満たせる組み合わせを俯瞰し、ACM と EventBridge と SNS がどこまで自動機能を提供しているかを見極めると最適解に自然と絞り込めるはずです。

ヒントボタン

Amazon RDS はインスタンス生成時にしかストレージ暗号化フラグを設定できず、後から on-the-fly で CMK を当てる機能はありません。そこで PCI-DSS に間に合わせる王道は、現行 PostgreSQL のマルチ AZ 本番から手動スナップショットを作成し、その Snapshot を AWS KMS で顧客管理キーを指定して暗号化コピーし、コピーを用いて暗号化済みの新規データベースを起動する手順です。
新 DB へのカットオーバー時にアプリ側の jdbcURL や Lambda 環境変数を修正しなくて済むよう、RDS の DB インスタンス識別子を付け替えるテクニックが役立ちます。旧 DB を一時名へ変更後、同じ識別子を新 DB に割り当てればエンドポイント DNS が維持され、Elastic Beanstalk や ECS のタスクはいったん再接続するだけでよいため、計画停止 30 分の枠に十分収められます。
暗号化 Snapshot から作成した新 RDS は自動バックアップと将来のスナップショットも同じ顧客管理 CMK で暗号化されるので要件②を網羅できます。さらにマルチ AZ セットがデフォルトで引き継がれ可用性も損なわず、旧環境を残して並行検証ができるため安全です。可用性・暗号化・エンドポイント維持・短縮ダウンタイムという複数条件を総合的に俯瞰すると、このアプローチが最も現実的と言えるでしょう。

ヒントボタン

金融業界の法規制で求められる WORM 保持は「社内統制で許可された人だけが削除できる」レベルではなく「AWS ルートアカウントでも削除できない」レベルの不可変性が必要です。Amazon S3 の Object Lock には Governance と Compliance の 2 段階がありますが、Compliance モードは保持期限前の DeleteObject や RetainUntilDate 短縮をすべて技術的にブロックし、s3:BypassGovernanceRetention の効果も及ばないため、規制要件を最もシンプルに満たせます。

開発者が取引ログのメタデータを更新したい場合は、S3 バージョニングで新しいバージョンを追加すれば過去バージョンは残り続けます。Object Lock はバージョン単位で WORM 保護を掛ける仕組みなので、PutObjectVersion が許可されていても DeleteObjectVersion や Retention 短縮が不可なら改ざんリスクはゼロです。したがってバージョニング済みバケットに Compliance モードを有効化し、ポリシーで s3:BypassGovernanceRetention を明示的に拒否する構成が、開発者の柔軟性と 7 年間の保護を両立させます。

最小限の構成変更を重視するなら、既存 S3 バケットに設定を追加するだけで済む案が望ましく、Glacier Vault Lock への移行や MFA Delete の導入は取り出し遅延・運用複雑化を招きます。また Governance モードを選んで特定ロールに s3:BypassGovernanceRetention を許可すると保持短縮の経路が残り、CloudTrail 監査負荷も増えがちです。ルートユーザさえ操作不能にし、証跡も AWS Config と連携しやすいネイティブ WORM 機能を採用するのが、複数要件を俯瞰した総合判断として最適です。

ヒントボタン

Amazon MacieはS3バケットを自動スキャンしてクレジットカード番号などの機密データを正規表現や機械学習で検出し、findingを数分で発行できる唯一のマネージドサービスであり、Athenaは分析、GuardDutyは不審操作の検知、AWS Configは設定監査と役割が異なるため、10MBのCSVが1日200件届くワークロードを運用負荷なく守るにはまずMacieの採用を軸に考えると解決の方向性が見えてきます。
検出後15分以内に隔離と通知というSLAを満たすにはイベント駆動アーキテクチャが鍵であり、MacieのfindingをAmazon EventBridgeで受け取り即時にAWS Lambdaを呼び出せば秒単位で処理を開始でき、LambdaでS3のcopy_objectを実行してKMS暗号化された隔離バケットへコピー後に元を削除しつつ、同一フローでAmazon SNS Publishを行えば担当者への通知もほぼ同時に完了するため、スピード要件を余裕を持って充足できます。
オンプレミスのスクリプトやEC2インスタンス、S3 Lifecycleの24時間単位処理などは運用手間や遅延が生じて「AWSマネージドのみ」「15分以内」「暗号化隔離」という複数要件にそぐわないため、Macie＋EventBridge＋Lambda＋SNS＋SSE-KMSという完全マネージド構成で即時検知・自動隔離・迅速通知を同時に実現できる設計が総合的に最も合理的と判断できます。

ヒントボタン

監査ログを誰も削除できない WORM として保管するには、Amazon S3 の Object Lock で Compliance モードを選ぶことが肝心です。バケットでバージョニングを有効化しデフォルト保持期間を 30 日に設定すれば、複数アカウントが普通に PUT しても自動で 30 日間ロックされ、特別なヘッダー指定や追加ツールは一切不要です。リテンション期間中は IAM 管理者やルートユーザでも削除や短縮ができず、規制の「いかなる権限者でも不可」をネイティブに担保できます。

保持が解除されたあとコストを抑えるには、同じ Amazon S3 バケットでライフサイクルポリシーを設定し Expiration を 1 日にする方法が便利です。Object Lock の 30 日が切れた瞬間にオブジェクトは通常状態へ戻り、翌日に自動削除されます。Glacier への移行や Lambda バッチを挟まなくても、バージョン管理とライフサイクルだけで完全自動化が可能です。

まとめると、WORM の絶対保持、31 日目の自動削除、マルチアカウントからの PUT、追加スクリプト不要という複数要件を俯瞰すると、Amazon S3 の Versioning を前提とした Object Lock Compliance とライフサイクルポリシーの組み合わせが、MFA Delete、Legal Hold、クロスリージョンレプリケーションよりも単機能で全条件を網羅し、運用負荷とコストの両面で最も合理的と判断できます。

ヒントボタン

証券取引法の WORM 要件を本当に満たせるのは、S3 Object Lock（コンプライアンスモード）か Glacier Vault Lock の二択です。1 日 20 万件・平均 5 MB という小オブジェクトを連続 PUT するワークロードでは S3 が高スループットで扱いやすく、バージョニングや MFA Delete、SSE-KMS では管理者が消せてしまう点との違いも整理してみてください。

生成 30 日後にコストを抑えつつ保持ポリシーを継続するには、Lifecycle と互換性があるかが鍵になります。S3 なら Object Lock と Lifecycle を併用して Glacier Instant Retrieval や Glacier Deep Archive へ自動移行しても 7 年ロックが維持されますが、Glacier Vault Lock にはこうした階層移行がないため運用と料金を比較することで判断がしやすくなります。

監査チームや分析基盤には GetObject のみを許可し、DeleteObject はバケットポリシーで全面拒否、全操作は CloudTrail で証跡取得という IAM と S3 ポリシーの設計をイメージしてください。不可変性・自動階層化・読取専用・監査ログという複数要件を同時に満たせる構成を総合的に選ぶ視点が合格のポイントです。

ヒントボタン

規制で求められる書換・削除不可をネイティブに担保できるのは S3 Object Lock のコンプライアンスモードです。バージョニングと組み合わせれば過去バージョンも保持期限の対象となり、root ユーザーでも変更できない WORM を実現できます。DeleteMarker が残るため RPO=0 を維持しつつ、SSE-KMS で暗号化した取引ログを安全に保管できます。

アクセスが最初の60日間に集中し、その後は監査時のみという使い方なら、S3 ライフサイクルで 90 日目に Glacier Deep Archive へ自動移行させるのが低コストです。Intelligent-Tiering は長期低頻度では手数料が割高になりがちですし、Deep Archive でも標準リストアは 12 時間以内なので RTO4時間に合わせた計画リストアで対応できます。

書換防止・7年保持・暗号化・RPOゼロ・RTO4時間以内・コスト最適化という複数条件を俯瞰すると、S3 バケットで Object Lock とバージョニングを有効にし、ライフサイクルで Standard から Glacier Deep Archive へ階層化する単一ストレージ設計が最も運用負荷が低く要件を網羅できると判断できます。

ヒントボタン

新規の取引ログを自社管理のキーで確実に暗号化しつつアプリケーション側のコードや URL を変えないためには、Amazon S3 バケットに SSE-KMS と独自 CMK をデフォルト暗号化として設定するのが最もシンプルです。PUT された瞬間から保存中データは規制を満たし、IAM ポリシーで鍵アクセスを細かく統制できるので運用も安定します。

既にある 2 億オブジェクトを 4 時間で再暗号化するには高並列処理が不可欠です。S3 Batch Operations の PUT Copy を用いればサーバレスで数千万並列コピーが走り、オブジェクトのキーを変えずに SSE-KMS 付きで上書きできます。追加転送やアプリ停止が不要なため、短時間のメンテナンス枠内に収めやすい現実的な手段になります。

監査要件を満たすには S3 Inventory を日次で有効化し EncryptionStatus 列付き CSV を生成すれば、Amazon Athena や AWS Glue で容易にレポート化できます。Inventory 出力とバッチコピー分だけのコストで済み、SRR の遅延や Glue クラスタ常時起動、Glacier 取出し料金といった余分な支出を避けられます。

保存中暗号化方式の適合、既存データの高速再暗号化、継続的な監査とコスト最小化という複数要件を俯瞰し、Amazon S3 のネイティブ機能であるデフォルト SSE-KMS・Batch Operations・Inventory を組み合わせる解決策を検討しましょう。

ヒントボタン

監査で重視される保存データ暗号化は Amazon S3 の SSE-KMS を使うと AWS KMS が鍵を管理し、CloudTrail に CMK 使用履歴が残ります。SSE-S3 でも暗号化はできますが鍵操作の記録や厳格なアクセス制御が弱めです。BYOK 対応や細粒度な IAM ポリシー運用を考慮すると、デフォルト暗号化に SSE-KMS を選ぶ利点をしっかり把握してください。

誤削除・上書きから７日以内に復旧する方法を比べてみましょう。Object Lock の Compliance モードは期間内に削除も訂正もできず要件②には過剰ですし、CloudTrail＋Lambda でバックアップし直す案はイベント遅延が怖く追加運用も発生します。Amazon S3 のバージョニングを有効化すれば DeleteMarker が付くだけで旧バージョンは残り、ListObjectVersions から即座に取り消しやリストアができるため最小構成でリカバリを実現できます。

恒久削除を多要素・二名承認で制御するには S3 の MFA Delete が有効です。ルートユーザで設定すると MFA トークンを入力しなければオブジェクト削除やバージョニング変更ができず、IAM ロール運用と組み合わせて二人で作業確認するフローも作れます。追加サーバや Lambda を置かずに SSE-KMS、Versioning、MFA Delete を併用すれば、暗号化・誤削除復旧・MFA承認・サーバレスという複数要件をサービス機能のみで同時に満たせることを総合的に判断できます。

ヒントボタン

20アカウント全体でEBS暗号化違反を1分以内に把握したい場合、イベント発生と同時に評価できるAWS Configのmanaged rule「encrypted-volumes」をOrganizationsで一括適用し、NON_COMPLIANTイベントをAmazon EventBridge組織ルールが受信、中央監査アカウントのAmazon SNSからSlackへ送る流れを思い描くと、独自コードなしで数十秒通知が実現でき運用保守も最小化できます。

20アカウント個別にCreateVolumeをCloudTrail→CloudWatch Logs→Metric Filter→Alarmで追跡したり、EventBridgeスケジュールでLambdaがDescribeVolumesをポーリングする設計も可能ですが、ログ配信遅延やポーリング間隔が数分単位となり、Lambda実行やログ保存コスト・アラーム管理工数が増えやすく、AWS ConfigとEventBridge＋SNSのリアルタイムかつシンプルな特性と比べてコスト効率と運用性で差が生じます。

監査要件の厳格さ、1分以内通知というリアルタイム性、20アカウント横断の統合運用、コスト最小化という複数要件を俯瞰すると、組織レベルでネイティブにコンプライアンス評価を行い即時イベントを発火できるAWS ConfigとEventBridgeに、通知基盤としてSNSを組み合わせる設計が総合的に最も合理的だと判断しやすくなります。

ヒントボタン

PCI DSS では暗号鍵を年1回以上更新し、更新履歴を監査できることが求められます。S3 の SSE-S3 や aws/s3 など AWS マネージドキーはローテーション周期を利用者が変更できず、CloudTrail での証跡も限定的です。対して AWS Key Management Service のカスタマー管理型 CMK は「1 年ごとの自動ローテーション」をスイッチ一つで有効化でき、更新イベントが完全に記録されます。まずはこの CMK の特性を理解し、SSE-KMS を使う設計が要件を最短で満たせるかを考えてみてください。

監査部門が別アカウントから安全にログを読むには、S3 バケット権限だけでなく KMS キーポリシーにもクロスアカウントの decrypt 権限を付与する必要があります。SSE-KMS で暗号化されたオブジェクトは IAM ポリシーだけでは複合化できないため、AWS Key Management Service で監査アカウントのプリンシパルを明示的に許可することが不可欠です。さらに Amazon S3 クロスアカウントレプリケーションを組み合わせれば、コピー先でも同じ CMK で暗号化された状態を維持でき、監査用アカウントは自分のバケットから読み取り専用でアクセスできます。

運用負荷を抑える観点では、アップロード前に KMS Encrypt API でクライアント側暗号化を行い Secrets Manager で鍵を手動ローテーションする方法はスクリプトやライブラリ保守が重く、大容量 20 TB/日のスループットにも追加コストが生じます。SSE-KMS と CMK の組み合わせならアプリケーション改修が不要で、鍵のローテーションも AWS が自動実行します。PCI DSS の更新要件、クロスアカウントでの読み取り、CloudTrail での証跡保管、そして日次大容量処理という複数条件を総合的に満たせる構成を選択してください。

ヒントボタン

顧客が管理するKMSキーを年１回ローテーションしながら2 TBのEBS汎用SSDボリュームを自動で暗号化する最も簡潔な方法は、まずCMKを作成してローテーションを有効化し、続いてEBSデフォルト暗号化にそのCMKを関連付けることです。これによりAuto Scalingで動的に起動する全インスタンスの新規ボリュームとスナップショットが同一キーで保護され、追加スクリプトや手動作業を挟まずに要件①を満たせます。

開発者のアクセスを遮断しつつAuto Scaling用IAMロールだけに暗号化・復号化を許可したい場合、IAMポリシーよりもKMSキーポリシーでプリンシパルをそのロールに限定する方が確実です。EC2起動テンプレートに対象CMKを指定してもキーポリシーがガードを掛けるため、開発者がCLIやSDKでカスタム操作を試みても拒否され、すべてのKMSイベントはCloudTrailに記録されるので監査要件②にも適合します。

運用負荷とコストを最小化する観点では、EBSデフォルト暗号化の自動適用と増分スナップショット課金を活用し、暗号化済みスナップショットをCMKのResource-based policyでDRアカウントへ直接共有するのが効率的です。再コピー時の再暗号化や平文変換は不要で、Auto Scaling・KMS・EBSが連携するため運用者の手間もコストも抑えられます。複数要件を総合的に眺めると、キーライフサイクルを自動化しキーポリシーで権限制御する設計が最もバランスよく目的を達成できます。

ヒントボタン

S3 に置く取引明細を確実に SSE-KMS で守るには、バケットのデフォルト暗号化に KMS のカスタマーマネージドキーを指定する方法が有効です。独自キーにすると別途 IAM ポリシーでアクセス権を細かく制御でき、kms:Encrypt や kms:Decrypt が CloudTrail で明確に残ります。alias/aws/s3 のような管理キーでも暗号化自体はできますが、キーが共通で追跡粒度が粗くなるため、内部監査で「どの鍵で暗号化されたか」を示す証跡を充実させたい場合は専用キーを持つ意義が大きいです。

KMS で作成したカスタマーマネージドキーは、設定画面で自動ローテーションを有効にするだけで 365 日ごとに新しいバックエンドキーが生成され、アプリケーションや S3 側の設定変更は不要のまま要件 2 を満たせます。ローテーション対象外の AWS 管理キー alias/aws/s3 ではこの機能が働かないため、毎年手動のキー切り替えや再暗号化を計画する手間が発生しがちです。自動ローテーションを前提にした設計は、セキュリティ水準を保ちながらオペレーションを極小化できる点がメリットとなります。

CloudTrail を組織単位で有効にし、管理イベントを含むログを S3 Standard-IA などに 90 日保持すれば kms:Decrypt や PutObject などのアクティビティを Athena で即時検索できます。Data Events だけを取っても鍵操作は記録されないため、監査要件 3 を考慮するなら管理イベントの出力が不可欠です。S3・KMS・CloudTrail をフルマネージドで組み合わせることで、暗号化強度・鍵ローテーション・証跡保管という複数要件を最小コストかつ低運用負荷で一括達成できる構成になると整理できます。

ヒントボタン

監査項目では「保存データはカスタマー管理キーで暗号化し、鍵は1年ごとに自動ローテーション」と定められていますので、AWS KMS で CMK を作成して rotation を有効化するのが最も自然です。さらに Amazon S3 バケットのデフォルト暗号化を SSE-KMS に設定すれば、毎分2000回の PutObject をコード変更なしで保護できます。CMK の自動ローテーションは追加料金なく完全マネージドで実行され、運用負荷とコストを最小限に抑えられます。

既に格納されている約20 TB はバケット設定を変えるだけでは暗号化方式が書き換わらないため、Amazon S3 Batch Operations を「コピー元＝コピー先」で実行し SSE-KMS へ置換するのが効率的です。この方法はネットワーク転送料が発生せず、大量オブジェクトを並列処理で短時間に再暗号化し、PUT API を自作する手間も課金も回避できます。ジョブレポートが監査証跡となる点も金融業界要件に適合します。

CloudHSM を使ったクライアント側暗号化や Deep Archive への移行は鍵管理と復旧時間を自己責任で担う必要があり、RTO30分・RPO4時間の指標を満たしにくく運用コストも高くなります。AWS 管理キーは顧客管理キーの定義に合致せず自動ローテーションも非対応です。結果として CMK と S3 デフォルト暗号化、そして Batch Operations を組み合わせる案が複数要件をバランス良く充足する総合解と言えます。

ヒントボタン

Amazon RDS for MySQL は Secrets Manager とネイティブ統合しており、数クリックでシークレットと Lambda ローテーション関数を自動デプロイできます。テンプレートは OLD・PENDING・CURRENT のステージを切り替えつつ 12 時間ごとに資格情報を更新し、旧パスワードを短時間温存するため更新中でも接続が途切れません。GetSecretValue API で動的取得すれば 70 名の開発者が CodePipeline 経由で毎時 60 回行うテストも安定します。

Systems Manager Parameter Store スタンダードにはローテーション機能がなく EventBridge＋Lambda を自作するとタイミングずれで接続失敗や再起動が発生しがちです。IAM データベース認証は 15 分有効のトークン生成が前提で 12 時間サイクルとは整合せず、EC2 上の cron はシングルポイントになります。CloudTrail に履歴は残せても Secrets Manager が持つ二重ユーザ切替や自動ロールバックを補うには追加実装が必要となり運用負荷が増大します。

要件は「安全保管」「12 時間自動ローテーション」「無停止」「監査」「低運用コスト」の五つです。Secrets Manager と CloudTrail を組み合わせればワンストップで満たせる一方、Parameter Store や S3、IAM 認証を寄せ集める案は追加コードやインフラを複数維持する必要があり費用とリスクが増えます。複数サービスを俯瞰し、ネイティブ連携とマネージド自動化の有無を軸に総合判断しましょう。

ヒントボタン

Secrets Manager のマルチリージョンレプリケートシークレット機能は、東京などのプライマリで値やメタデータが更新されると約 1 分で大阪などのレプリカにも同期されるため、追加の EventBridge やクロスリージョン Lambda を書かなくても RPO 10 分未満という可用性をネイティブに実現でき、同一 ARN 構造が保たれるのでアプリ側の接続先変更も不要です。
Secrets Manager ではウィザードから 30 日間隔を選ぶだけで Lambda ローテーション関数（create・set・test・finish の 4 ステップ）が生成され、生成されたスケジュール設定はレプリケート先リージョンにもそのままコピーされるため、Cron や Step Functions を別に構築せずとも両サイトで自動ローテーションが回り続けます。
RPO、ローテーション、追加コード最小化、暗号鍵を AWS 管理キーに固定という 4 つの要件を俯瞰し、Secrets Manager が標準で持つ複製と暗号化の合わせ技を活かす設計と、Systems Manager パラメータストアや CloudFormation など複数サービスを組み合わせて運用負荷を背負う設計を比較すると、どちらが本質的にシンプルかが見えてきます。

ヒントボタン

クライアントから 20 リージョンの CloudFront エッジを通して機密フィールドだけを暗号化状態で運ぶには、TLS だけだと途中で平文になる瞬間があります。CloudFront フィールドレベル暗号化なら公開鍵で指定フィールドを暗号化したままエッジを通過でき、オリジン直前の Lambda@Edge で復号することで経路要件と性能を両立できます。

鍵を年 1 回自動ローテーションする条件では、AWS KMS のカスタマー管理型キーを使い自動ローテーションを有効にすると API の呼び出しが透過的に新キーへ切り替わります。Secrets Manager や Parameter Store に独自鍵を置いて手動や自作 Lambda で更新する方式は実装と監視の負荷が増えるため、「運用負荷を最小化」という制約と比較すると適合度が下がります。

1 秒あたり 5 万リクエストを全球で処理する環境では、復号と再暗号化をエッジに近い層で行い保存時だけ KMS で暗号化する設計が待ち時間を抑えつつスケールに強いです。TLS 専用伝送やブラウザ側 AES、API Gateway の平文処理などは「経路中暗号化」「自動ローテーション」「低レイテンシ」の複数条件を同時に満たしにくい点を俯瞰し、要件を網羅的に満たす組み合わせを選択しましょう。

ヒントボタン

ヒント1
EC2 の暗号化 AMI を別アカウントへ共有してコピー・起動する場合、根本的に必要なのは EBS スナップショットを暗号化している KMS の CMK への使用権限です。IAM ロールにポリシーを付けるだけでは足りず、キー側のキーポリシーまたは Grant に kms:Encrypt、kms:Decrypt、kms:ReEncrypt* などのアクションを許可する必要があります。Beta には ScheduleKeyDeletion や PutKeyPolicy などの管理操作を持たせず、最低限の「使用権限」だけを渡す設計がポイントです。

ヒント2
AMI 共有は modify-image-attribute と snapshot の modify-permission を組み合わせるだけで完了し、追加の Systems Manager Automation や VPC ピアリングは不要です。暗号化されたままコピーしたいなら、コピー処理中に AWS が自動で kms:CreateGrant を発行できるようにしておくと運用が楽になります。いったん EBS を復号化して再暗号化すると未暗号化データが存在し、時間もコストも増えるため「運用負荷最小化」「暗号化状態維持」という要件と相反します。

ヒント3
alias/aws/ebs は AWS managed key を示す予約済みエイリアスであって、ユーザーの CMK を指し示すために変更できるものではありません。したがってエイリアス変更だけで Beta が復号できるようにはならず、結局 CMK への使用権限付与は避けて通れません。複数の要件――子会社には管理権限を持たせないこと、暗号化を保ったままコピー・起動できること、追加オペレーションを最小にすること――を総合すると、キーポリシーで最低限の使用権限を与えつつ AMI をネイティブ機能で共有する方法が最適解となります。

ヒントボタン

Lake Formation の LF-Tag を列やテーブルに付与してタグベースアクセス制御(TBAC)を使うと、DataScientist ロールに「NonPII」だけの SELECT を与えるだけで済み、毎週 Glue クローラが取り込む新規 Parquet テーブルもタグが自動継承されるため個別権限設定を追加せずに列レベル遮断が続きます。さらにタグはデータカタログ上の RDS スキーマにも付けられるので、S3 由来でも MySQL 由来でも同一のルールで統一管理され、Athena や Redshift Spectrum といったクエリエンジン側はタグ評価後の結果しか見えます。これにより社内 BI の増設時もセキュリティポリシーを改修する作業が不要となります。

RDS for MySQL の GRANT、S3 バケットポリシー、Athena WorkGroup などサービス毎にばらばらの制御を組み合わせると、DataEngineer がスキーマを変更した時に毎回二重三重に権限を揃える運用が発生しがちです。Lake Formation カタログを単一の信頼ソースにし、ALTER や INSERT などの権限だけをロール単位で分離する設計の方が運用負荷と漏えいリスクを同時に削減できます。

要件は「PII を含む列の恒久的遮断」「書込み可能なエンジニアと参照専用のサイエンティストの分離」「毎週増えるテーブルへの権限自動反映」の三つです。Lake Formation のタグベース制御で DataScientist に NonPII だけ SELECT、DataEngineer にデータベース全体の ALTER･INSERT･SELECT を与えれば追加作業なくこの三条件を長期で満たせます。

ヒントボタン

監査チームが求める KMS での暗号化と 30 日ごとの自動ローテーションを一括で叶えたい場合、Secrets Manager が持つ CMK 指定機能と RDS MySQL 用組み込み Lambda テンプレートが強力です。Create secret 画面で CMK を選択しローテーションを有効化するだけで、パスワード生成・更新・検証まで自動化され、CloudTrail に操作履歴も残るため証跡管理もシンプルになります。

Parameter Store（Advanced）や EventBridge＋Lambda でも暗号化とローテーションは構築できますが、スクリプトでの失敗時リトライ・ロールバックや世代管理、さらに ECS タスクへの反映処理を自前で保守する必要があります。運用負荷を最小化したい要件では、マネージドでローテーションを提供する Secrets Manager と比較して作業範囲が広がることを忘れないでください。

ECS Fargate からの動的取得は、タスク実行ロールに SecretsManager:GetSecretValue だけを許可し SDK 呼び出しに置き換えるだけで実現できます。アプリのソースやタスク定義に静的値を埋め込む方法だと再デプロイや人手による更新が発生し、最小権限や継続的デリバリの観点で不利です。AWS Config でのコンプライアンスチェックも意識し、実行時取得＋ポリシー最小化がベストプラクティスになります。

複数の要件を俯瞰すると、Secrets Manager の CMK 暗号化・自動ローテーションを中心に、ECS Fargate・IAM・RDS を連携させる構成が KMS、監査ログ、運用負荷のすべてを最も自然に満たしていることが見えてきます。

ヒントボタン

毎週 3 TB のオブジェクトを扱い 15 分以内に別リージョンへ同期する SLA が必須なら、S3 クロスリージョンレプリケーションに Replication Time Control を付与する構成が、ジョブや Lambda を書かずに設定だけで済み、AWS が 15 分を契約上保証してくれるため RTO 4 時間を大きく下回る転送を自動で実現でき、追加費用もオブジェクト容量と RTC サーチャージ程度に抑えられます。
監査で「両リージョンとも同一キー ID の CMK で暗号化されていること」を示すには、KMS のマルチリージョン CMK を東京で作成してレプリカをオレゴンに生成する方法が適しており、このキーは論理的に同一のキー ID を共有し CloudTrail の証跡にも同じキーとして記録されるので、リージョナル CMK を別々に用意して ID の不一致をログで補完する方式より遥かに手間とリスクを減らせます。
最小限の運用で災害対策と暗号鍵要件を同時に満たしたい場合は、S3 バケットを SSE-KMS で保護しつつバージョニングを有効化し、先述の CRR + RTC とマルチリージョン CMK を組み合わせれば、鍵管理の自動同期・レプリケーション SLA・監査証跡の三拍子が揃い、スクリプトや AWS Backup で手動コピーしたりリージョナル CMK を別管理する案よりも、設計の一貫性と復旧信頼性の両面で総合的に優位と判断できます。

ヒントボタン

50 ものアカウントをまとめて監査しつつ中央のセキュリティチームが一画面で状況を把握したいなら、Organizations で全アカウントに AWS Config を統合有効化し、委任アカウントに Config Aggregator を作成する方法が最適です。Aggregator は各リソースのコンプライアンス変化を即時に収集し、単一ダッシュボードで横断的な可視化を実現できます。
暗号化逸脱を 5 分以内に検出して自己修復させる仕組みには、Config のマネージドルール「s3-bucket-server-side-encryption-enabled」を連続評価に設定し、評価通知を EventBridge で受けて SSM Automation を起動するパターンが定番です。Automation で PutBucketEncryption を呼び出せば SSE-KMS が自動で適用され、運用者が介在せず SLA を守れます。
監査証跡を 7 年保持し重複保存を避ける観点では、AWS Config の履歴と評価結果を直接 S3 に書き出し、ライフサイクルポリシーで Glacier へアーカイブするだけで要件を満たします。設定評価・自動修復・集中可視化・長期保管の四つを一つのサービス群で完結できる構成が、総合的に最も運用負荷とコストを抑えられる選択肢となります。