SAP-1.2セキュリティコントロールを規定する。

ヒントボタン

ヒント1
S3 の BucketOwnerEnforced を選ぶと ACL による WRITE や READ 設定は無効化され、アクセス制御はバケットポリシーか IAM ポリシーだけで行います。したがってクロスアカウントでアップロード権限を渡す場合、バケット側では Principal を相手ロールに限定し s3:PutObject を必要なプレフィックスだけに許可するのが最小特権の基本となります。

ヒント2
SSE-KMS で暗号化しながら PutObject する際、アップロード側 IAM ロールには s3:PutObject に加えて KMS の kms:Encrypt と kms:GenerateDataKey が必須です。kms:Decrypt はダウンロード時にだけ必要なので付けなくても書き込みは成功します。KMS キーの ARN を IAM またはバケットポリシーで明示し、他キーを使えないよう StringEquals 条件を入れると要件を満たしやすくなります。

ヒント3
IAM ロール・バケットポリシー・KMS という三層で考えると、①バケットポリシーでロールとプレフィックスを限定し SSE-KMS とキー ID を強制、②ロール側では PutObject と Encrypt 系の最小セットだけ許可、③Decrypt は与えない――という組み合わせが全要件（ACL 不使用、1000 オブジェクトの継続書き込み、暗号化統制、読み取り禁止）を同時に満たす総合的に最小の構成です。

ヒントボタン

動画を CloudFront だけで提供するには、S3 をパブリックにせず Origin Access Control を紐付け、バケットポリシーの Condition で aws:SourceArn を対応するディストリビューションに限定し、S3 Block Public Access を四項目すべて有効にして ACL を private のまま保つことで外部からの直接 URL を遮断しつつキャッシュ経由の常時配信が実現できます。
制作会社へ 2 時間だけ直接 HTTPS GET を許可する場合、バケットポリシーに aws:SourceIp で 203.0.113.0/24 と 198.51.100.0/24 を列挙し、SigV4 署名付き URL の aws:TokenIssueTime／Expiration を 120 分に設定すればタイムアウト後は自動拒否となり、同じ仕組みを既存モバイルアプリの署名付き URL にも適用できるため ACL を一切変更せず CIDR と時間制限の両要件を満たせます。
静的ウェブサイトホスティングは Block Public Access を解除してしまい、S3 アクセスポイントや STS 一時資格情報を使う案は ACL 変更やアプリ改修が伴うため運用が複雑になりますので、バケットポリシーだけで OAC 経由・CIDR 制限・署名有効期限を統合管理する方式が最小構成であり五つの要件を総合的にバランス良く達成できます。

ヒントボタン

NACL は Security Group と異なりステートレスですので、リクエストとレスポンスの両方向を個別に許可することが前提になります。パブリックサブネットに置いた Application Load Balancer が 0.0.0.0/0 から TCP 443 を受け取り、同時にインターネット側クライアントへ 1024-65535 のエフェメラルポートで返す流れ、さらに ALB からプライベートサブネットの EC2 へ TCP 8443 を転送し逆方向の 1024-65535 も通す流れを全部書き出してみると、NACL で必要な許可ルールが自然に整理できます。

プライベート側では EC2 が外部決済 API に TCP 443 でアウトバウンドし、その返答を 1024-65535 で受け取る経路と、ALB との間の 8443／エフェメラルポートの往復を許可すれば十分です。デフォルト全許可のままでは「不要トラフィックを拒否」の要件に合わず、一方で 443 だけを開放するとレスポンスが遮断されます。CIDR 10.0.0.0/16 に限定し、それ以外を明示的に DENY とすることで最少ルールを実現できます。

以上を踏まえ、ステートレスの特性、エフェメラルポート 1024-65535 の双方向許可、CIDR ごとの送信元・宛先の切り分け、ALB→EC2 の TCP 8443 専用通信の確保、そして 0.0.0.0/0 に対する必要最小限の開放という複数要件を同時に満たすネットワークACL を選択することが、AWS VPC での金融系ワークロードにおける最適な総合判断となります。

ヒントボタン

ABAC で部門分離を徹底するには、Active Directory が持つ department 属性を AWS STS のセッションタグに載せることが近道です。IAM ロールの信頼ポリシーで sts:TagSession を許可すれば、IAM Identity Center を経由した SSO でも自動的に Department タグが引き継がれ、ECS on Fargate へ渡る認証情報はロール 1 つで済みます。

S3 の権限ポリシーでは Condition 句で aws:PrincipalTag/Department と s3:ExistingObjectTag/Department を StringEquals で比較する記述がポイントです。この組み合わせは List/Get/Put など実行時に評価され、research-data バケット内のオブジェクトタグとセッションタグが一致した時だけ操作を許可し、他部門のオブジェクトは一覧さえできません。

タグをセッションで動的に受け渡す方式は、部門が増減しても IAM ロールやポリシーの追加・修正が不要なため運用負荷を最小化できます。バケットポリシーに複雑な条件を散在させたり、部門別にロールを複製した場合のメンテナンスコストと比較し、要件の網羅性・拡張性・保守性を俯瞰するとこの設計が最も合理的と判断できます。

ヒントボタン

12 個の VPC から出る 0.0.0.0/0 をまとめてマルウェア検査したい場合、AWS Transit Gateway の別ルートテーブルにデフォルトルートを載せ、共有サービスアカウント側の検査 VPC へサービスインサーションすると、AWS Network Firewall を 1 か所でマルチ AZ 配置するだけで全 VPC をカバーでき、NAT Gateway も集約され運用とコストが大幅に最適化されます。

Network Firewall のログ出力は S3 直接書き込みと KMS 暗号化にネイティブ対応しており、VPC Flow Logs も同じバケットに統合しライフサイクルポリシーで 90 日後に削除設定すれば内部監査の保管要件を自動達成できます。CloudWatch Logs だけに頼ると転送や再暗号化が追加作業になる点を整理してみてください。

EC2 アプライアンスを置く Gateway Load Balancer 方式や Direct Connect でオンプレミス装置に迂回させる方式は、可用性や帯域、保守工数とライセンスコストの観点で懸念が残ります。Transit Gateway と AWS Network Firewall の集中配置、KMS 付き S3 保存、単一点の NAT Gateway という組み合わせが複数要件を最もバランス良く満たすかを総合的に比較すると最適解が導きやすくなります。

ヒントボタン

未承認製品の新規購読だけを止め、既存契約の更新は許可したい場合、aws-marketplace:Subscribe を SCP で一律 Deny すると更新時にも同じ API が呼ばれ要件を阻害します。Organizations の Private Marketplace を有効化すれば、承認済みカタログ外への Subscribe だけがブロックされ Renew や Upgrade は継続可能です。カタログ変更が組織全体に即時反映されるため運用作業も減ります。

監査部門が求める中央集権管理は、Organizations の委任管理者設定で Security アカウントを AWS Marketplace の管理アカウントに指定すると実現できます。Private Marketplace なら製品の承認・取り消し操作をこの 1 アカウントから行え、Dev・Test・Prod に散在する 150 アカウントへ別途 IAM ユーザやクロスアカウントロールを配布する必要がなく統制が保たれます。

Dev OU の cicd-role に iam:PassRole を追加するだけの要件は単純ですから、設計の比較では「今後 OU に追加されるアカウントが自動で制御対象になるか」「設定箇所が少なく保守が楽か」が重要です。Service Catalog を各アカウントへ共有したり Permission Boundary を毎回張る方法は手数が多く拡張性が低い一方、Private Marketplace は Organizations 直結で自動適用されるので将来拡張と運用負荷のバランスを総合的に満たします。

ヒントボタン

30 アカウントの CloudTrail を 1 年保管しつつ低運用を目指すなら、AWS Organizations で「組織の証跡」を 1 つだけ有効化し、全イベントを共通 S3 バケットへ集約する方法が最もシンプルです。個別証跡や Kinesis 連携を多重化すると設定・請求・監視ポイントが散らばり、Athena で横断検索する際にリージョンやアカウントごとのプレフィックスを逐次管理する運用負荷が増大します。組織証跡なら新規アカウント追加も自動でカバーでき、Glue Data Catalog も一元化できるため、研究部門とコンプライアンス部門の双方が扱いやすい環境を維持できます。

「必ず CMK を指定した SSE-KMS だけで書き込む」「違反操作は即時失敗させる」という強い統制は、S3 のデフォルト暗号化設定だけでは不十分です。PutObject に aws:KmsKeyArn 条件を付けた SCP やバケットポリシーを組み合わせれば、ユーザが SSE-S3 や別キーを指定した瞬間に 4xx が返り、CloudTrail に失敗イベントも残るため迅速な検知と抑止が成立します。CMK を CloudTrail ログにも適用すればキー管理を一元化しつつログの機密性と完全性を確保でき、監査証跡の信頼性を高められます。

日次 1,000 万レコードを翌営業日までに調査する要件には、S3 に置かれた圧縮ログを Athena で直接クエリし、Glue Data Catalog にパーティション投影を設定する構成が最適です。投影を使えば新しい日付パーティションを手動登録する必要がなく、ETL やマニフェスト生成の待ち時間も排除できます。Redshift Spectrum 経由や Glue ETL バッチを挟むとスキーマ管理、ロード時間、VACUUM などの運用タスクが増え遅延も発生するため、即時検索という目的と相反します。暗号化強制・統制ポリシー・リアルタイム分析の三要素を同時に満たせるシンプルな全体設計を選ぶ視点が鍵となります。

ヒントボタン

世界中に 50 以上の PoP を持つ CloudFront を前段に置くと、ALB をオリジンにしたまま静的・動的コンテンツを高速配信できます。HTTP/2 はエッジで終端し、CloudFront からオリジンへの接続もデフォルトで TLS1.2 なので追加設定なしで暗号化要件を満たせます。ACM 証明書も自動更新されるため 8 万 rps 規模でも運用負荷が増えにくい点が強みです。

ALB への直接アクセスを防ぐには、CloudFront が付与する乱数入りカスタム HTTP ヘッダーを ALB リスナールールで必須条件にする方法が簡潔です。Security Group を 0.0.0.0/0 で開けてもヘッダーが無いリクエストは遮断でき、IP 制御やプライベートサブネット化は不要になります。referer 検証や Lambda@Edge での署名生成は運用が重く、OAI や OAC は S3 専用で ALB では使えない点も思い出してください。

OWASP Top-10 の検査は AWS WAF を CloudFront にだけ紐付ければエッジで完結し、ALB 側の二重課金を避けつつトラフィック量とレイテンシも削減できます。Lambda@Edge や複数層 WAF を併用するとコストと保守が増えるため、マネージド機能のみでヘッダー検証・TLS 暗号化・グローバル配信を同時に実現できる構成が、全要件を俯瞰したとき最も合理的かを考えてみてください。

ヒントボタン

EC2 に鍵を渡さずに運用したいときは、Auto Scaling の Launch Template で KeyName を空欄にし、SSM Agent と Session Manager 経由で操作するのが推奨です。Security Group や NACL で 22 番ポートを閉じてもキーペアが残っていれば要件は満たせず、EC2IAMRole に AmazonSSMManagedInstanceCore を付与して無鍵アクセスを徹底することが重要です。

API コールを 60 秒以内に検知して通知したい場合、Organizations で統合した CloudTrail を CloudWatch Logs に同時配信し、Metric Filter で CreateKeyPair と ModifyLaunchTemplate を捕捉、Alarm を 1 分間隔で評価して SNS に送る構成が最もシンプルで低レイテンシです。Athena や Lambda でのバッチ解析よりも即時性が高く、メンテナンス工数も抑えられます。

全アカウントの監査ログを集中管理し 7 年保持するには、統合 CloudTrail から暗号化された一元 S3 バケットへ配送し、S3 ライフサイクルとバージョニングで保持ポリシーを設定する方法が標準です。この仕組みと無鍵 EC2、CloudWatch Logs のリアルタイム検知を組み合わせることで、SSH 禁止・即時通知・長期保管という複数要件を運用負荷とコストを抑えながら同時に満たせます。

ヒントボタン

オンプレミスの Windows Server Active Directory に変更を加えずに 5 分以内で権限情報を AWS 側へ反映させるには、LDAP をコピーせずリアルタイム中継する AD Connector が最もシンプルです。AD Connector は IAM Identity Center と連携して都度クエリをオンプレに流すためレプリケーション遅延がなく、スキーマ変更や追加ドメインコントローラが不要で 1 か月という短期導入にも適しています。Direct Connect や VPN で往復 20ms 程度ならユーザー操作の体感遅延も問題になりません。

可用性では RTO15 分・RPO0 分が求められていますが、状態を保持しない Small サイズの AD Connector を２つの Availability Zone にデプロイすると、片系障害時も DNS で自動切替でき復旧は数分、保持データがないので損失もゼロです。Direct Connect の専用回線でレイテンシを抑えつつ、IAM Identity Center でセッション上限を 60 分に設定すれば最小権限の権限セット運用とユーザー利便性を両立できます。Amazon Route 53 を併用するとフェイルオーバー監視も容易です。

セキュリティアカウントへのログ集約は CloudTrail と IAM Identity Center 専用ログを統合して Amazon S3 に書き出し、Amazon Athena でクエリを実行する運用が AWS Organizations 全体で一貫性を保ちます。マネージド AD や外部 IdP のみで完結させる案ではログが分散して検索性が落ちるため、AD Connector＋ネイティブログ統合の方が構築期間内にコンプライアンス要件を満たしやすいです。複数の可用性・同期・統制要件を俯瞰して最短で実現できる構成を選びましょう。

ヒントボタン

オンプレ AD FS と AWS IAM を直接フェデレーションする場合、まず IAM で SAML プロバイダを作成し、信頼ポリシーに Federated principal を設定したロールを用意すると sts:AssumeRoleWithSAML で一時クレデンシャルが払い出されます。MaxSessionDuration を 12h に設定すれば組織基準の「最長 12 時間」を厳格に担保でき、固定の IAM ユーザーやアクセスキーを持たずに済むためコンプライアンス面でも安心です。加えて roles 属性にロール ARN を書き込めば AD グループ単位で権限配布を自動化できます。

CloudTrail の userIdentity には SAML アサーション内の NameID や SessionContext が記録されるため、ブラウザでサインインした監査担当者個人を特定できます。ロールに付与する AWS managed policy「AmazonS3ReadOnlyAccess」やカスタムバケットポリシーを最小限に抑えれば、50 GB レポート取得に必要な GetObject 権限のみを与えられ、アクセスログも S3 サーバーアクセスログや AWS CloudTrail で二重に追跡できます。こうしたきめ細かな可視化は金融監査の要件(2)を満たす鍵となります。

将来複数アカウントへ拡張する際は、AWS Organizations 配下の各アカウントに同一の S3 ReadOnly ロールを複製し、AD FS の roles 属性に追加 ARN を列挙するだけで展開できます。IAM アイデンティティセンターや OIDC Web Identity を採用すると簡便に見えますが、設問が求める「SAML フェデレーション」と個人監査ログ、期限 12h、永続ユーザー禁止という複数条件を総合すると、SAML プロバイダ＋AssumeRoleWithSAML＋MaxSessionDuration 12h のクラシックな構成が最も要件適合度の高い解となります。

ヒントボタン

RunInstances のパラメータを起動前に縛るには IAM ポリシーの Condition で ec2:Owner や ec2:ResourceTag/Environment、ForAnyValue:StringEquals ec2:InstanceType、Bool ec2:Encrypted、StringEquals ec2:VolumeKmsKey を組み合わせる方法が最も直接的です。KMS CMK やタグ、インスタンスタイプを同時に強制でき、PassRole も iam:PassRole 条件で制限すれば、その他のリソース操作を許可しなくても AppDeveloper は EC2 を安全に自己調達できます。ブルー/グリーン展開で 1 日 500 台という速度でも、条件を満たさない起動要求そのものを即座に拒否できるため、事後修復のラグを心配する必要がありません。

組織の SCP や AWS Config でも制御は可能に見えますが、SCP は ec2:ResourceTag などの EC2 特有の条件キーを使えず、Allow/Deny の大枠しか設定できません。Config ルールは違反を検出後に AWS Systems Manager や Lambda で修復するため、数百台が短時間でスケールするブルー/グリーン運用では「違反インスタンスが一時的に走る」リスクを排除できません。Launch Template や Auto Scaling に頼る設計も、開発者が新バージョンに誤ったインスタンスタイプや KMS キーを入れてしまえばブロックできず、結果として要件 1〜4 を同時に保証できる仕組みとは言えない点に注意しましょう。

最小権限の原則を満たす鍵は、AppDeveloper が必要とする ec2:RunInstances と iam:PassRole 以外の操作を与えず、それらの API に対してタグ、所有者、インスタンスタイプ、暗号化キー、ロールの 5 つの条件を粒度細かく課すことです。これにより EC2、EBS、KMS、IAM を横断した複合ポリシーが 1 枚で完結し、権限制御は予防的でシンプル、ブルー/グリーンの迅速な自己調達も阻害しません。複数要件を俯瞰し「実行前に全部縛れる場所はどこか」を見極める視点が最終判断の助けになります。

ヒントボタン

ヒント1
SSE-KMS で暗号化された S3 オブジェクトを別アカウントの Athena や Glue から読み取るときは、呼び出し元の IAM ロールに kms:Decrypt と kms:GenerateDataKey を許可するだけでは足りません。KMS の CMK そのものが持つ key policy 側でも、そのロール（あるいはロールを含むアカウント）を Principal に追加し、同じアクションを許可する必要があります。KMS は「IAM ポリシー」と「key policy」の両方を肯定にしないとアクセスを通さない二重チェックを行うため、この点を見落とすと AccessDeniedException が発生しやすいです。

ヒント2
S3 バケットポリシーは GetObject や PutObject などの s3: プレフィックスを持つ API に対する許可・拒否を制御する場所であり、kms:Decrypt や kms:GenerateDataKey といった KMS API には適用されません。Athena がオブジェクトを読み込む際は、まず S3 がデータキーを取り出すために KMS を呼び出す流れになるため、アクセス判定は KMS 側で行われます。したがって「KMS の権限をどこに書くか」を意識すると、バケットポリシーより key policy を調整するほうが運用箇所を増やさずに済みます。

ヒント3
毎日 1 TB ものログを保管している状況で暗号化方式を SSE-S3 や SSE-C に変更すると、既存オブジェクトの再暗号化やライフサイクル設定変更など大量の S3 PUT が発生し、コストと運用負荷が跳ね上がります。一方、CMK の key policy に行を一つ追加し、呼び出し元ロールの IAM ポリシーに最小限の KMS 権限を付ける方法なら、一度の設定で済みデータ移動も不要です。AssumeRole の仕組みは既に機能しているため、この差分だけで要件を満たせます。

最終的には「SSE-KMS を維持」「クロスアカウント」「最小権限」「追加運用負荷ゼロ」の四点を同時に満たす策を俯瞰し、KMS key policy と IAM ポリシーの両面から権限を整える構成が唯一無理のない選択肢であると判断できます。

ヒントボタン

子会社の Athena から S3 上の CloudTrail ログを「読むだけ」にするには、S3 バケットポリシーで s3:GetObject と s3:ListBucket のみ許可し、Condition で aws:SourceVpce に vpce-abc123 を指定して VPC エンドポイント経由に限定する方法が定番です。PutObject や DeleteObject をそもそも入れなければ書き込みは不可能になり、ACL やアクセスポイントよりもポリシー単体で要件をシンプルに満たせます。SSE-KMS の暗号化でも閲覧専用権限は変わりません。

SSE-KMS を使う場合、kms:Decrypt と DescribeKey を CMK のキーポリシーで対象ロールだけに付与すれば、復号 API が CloudTrail に必ず記録される仕組みを保持したまま、鍵の所有権は親会社側に残せます。加えて子会社の IAM ロールに Permission Boundary を設定し s3:DeleteObject と s3:PutObject を明示的に拒否しておくと、後日インラインポリシーを強化しても削除や上書きは防げ、最小権限の原則を堅持できます。

クロスアカウント共有では「経路制御を担う VPCエンドポイント」「監査を担う CloudTrail」「権限を絞る IAM／バケットポリシー／キーポリシー」の三層を組み合わせ、SSE-S3 ではなく SSE-KMS を用いて Decrypt の監査を残すことが重要です。ワイルドカードの Principal や s3:* といった過剰権限を避け、Get/List と Decrypt のみに絞り SourceVpce で通信元を固定し Permission Boundary で上書きを防ぐ構成が、全要件をバランス良く充足する総合的な最適解と言えます。