MLS-4.3機械学習ソリューションへの基本的な AWS のセキュリティプラクティスの適用。

ヒントボタン

ヒント1
プライベートサブネットから Amazon S3 へアクセスする際に NAT Gateway を使うと、実際の宛先が S3 のパブリックエンドポイントであってもトラフィックはインターネットゲートウェイ側にルーティングされます。VPC Flow Logs を有効化すれば 0.0.0.0/0 に出て行くパケットが確認できるはずです。組織が HIPAA 要件や PHI を理由に「VPC 外へのアウトバウンド通信を許可しない」という制約を設けている場合、この通信経路はリスク評価で早い段階に除外されやすい点を思い出してください。

ヒント2
S3 へのプライベート接続には Interface Endpoint と Gateway Endpoint の二種類があります。Interface 型は ENI ごとに利用料金が発生し、データプレーンは PrivateLink の帯域に乗るため 50 TB といった大容量を処理するとコストとスループットの両面で注意が必要です。一方 Gateway 型はルートテーブルでプレフィックスリストを指すだけで、IP の管理や追加料金がなく運用も軽量です。バケットまたはエンドポイントポリシーで GetObject/PutObject のみを許可し、リソースや VPCE ID を条件にすれば、SageMaker や ECS が意図しない外部と通信せずに済むことを比較してみてください。

ヒント3
PHI を含むファイルを安全に扱うには、S3 側の Block Public Access、バケットポリシーの aws:SourceVpce 条件、VPC側のエンドポイントポリシーという多層ガードを同時に成立させることが重要です。さらに NAT や IGW を置かずともルートテーブルを書き換えるだけで透過的に動作し、SageMaker ノートブックや ECS バッチのコード変更も不要なアーキテクチャであれば、機密性・可用性・運用コストの三要件をバランスよく満たせることを総合的に判断してください。

ヒントボタン

金融データを扱う環境では、SageMaker ノートブックをインターネットが届くパブリックサブネットに置いたままでは、どんなに IAM 制御や VPC フローログを入れても「経路自体」を閉じ切れません。Direct Connect でつながるプライベート経路だけに限定したい場合、S3 にはパブリックエンドポイントではなく Gateway VPC エンドポイントを採用し、ノートブックをプライベートサブネットへ移動して Internet Gateway を経由しないルートを構成する発想が第一歩になります。

既存の IAM ロール ml-researcher を一切変更できない制約下では、アクセス元の絞り込みを IAM ポリシーではなく S3 側で行うのが鍵です。バケットポリシーに aws:SourceVpce 条件を加えれば、指定した Gateway VPC エンドポイント経由のリクエストだけを許可でき、NACL や NAT Gateway を変更しなくても社外 IP アドレス経由の試行を構造的に排除できます。

ネットワーク設計・権限制御・運用負荷の三点を俯瞰すると、ノートブックをプライベートサブネットに置き、S3 へは Gateway VPC エンドポイント経由で到達させ、バケットポリシーでエンドポイント ID を条件にし、それ以外の経路を遮断する構成が、Direct Connect の私設経路を活かしつつ追加設定やコストも最小で済み、提示された複数要件を最もバランス良く満たします。

ヒントボタン

まず保存データの暗号化には SSE-KMS を指定し、Amazon S3 と Amazon SageMaker の双方で同一のカスタマーマネージドキーを使う設計が軸になります。対称 CMK なら 365 日周期の自動ローテーションをオンにするだけで 12 か月毎の更新要件をクリアできます。さらにキー-ポリシーで ML エンジニア用 IAM ロールに kms:Encrypt/kms:Decrypt だけを許可すれば余計なエンティティがキーを操作できず要件④も達成、FIPS 140-2 準拠の面でも安心です。

キーやデータに関する操作を 90 日間検索可能な形で残すには AWS CloudTrail が最適です。CloudTrail は KMS の Encrypt、Decrypt、GenerateDataKey など全 API コールをログに書き、Amazon CloudWatch Logs の保持期間を 90 日に設定すれば即座にクエリが可能です。S3 サーバーアクセスログや AWS Config は KMS API を収集しないため、要件③における監査対象の網羅性という点で検討から外れやすいことも押さえておきましょう。

まとめると、SSE-KMS で暗号化される 50 TB の PHI を扱う Amazon SageMaker ワークロードでは、1) 自動ローテーション可能なカスタマーマネージド対称 CMK を一つ用意し、2) そのキーを S3 バケットと SageMaker の暗号化キーに共通指定、3) CloudTrail を全リージョンで有効化し CloudWatch Logs に 90 日保持、4) キー-ポリシーで ML エンジニアロールのみを許可、という構成が運用負荷を減らしながら四つの要件を同時に満たす最小構成となります。

ヒントボタン

Amazon SageMaker ノートブックインスタンスは Start／Restart 時に Lifecycle Configuration スクリプトを順番に実行する仕組みがあり、ここに yum update -y を記述しておけば OS パッチが起動のたびに自動適用されるため、CVE 公開後 24 時間以内というセキュリティ部門の要求を台数に関係なく機械的かつ確実に満たせます。スクリプトは Git リポジトリや Amazon S3 に保存しておくことでバージョン管理もでき、複数環境へ横展開する際の統一性と追跡性が確保できる点も運用上大きなメリットになります。

EventBridge のスケジュールルールを利用すると、cron 表記で深夜 2 時など利用者が不在の時間帯に自動で Stop API と Start API を連続で呼び出せるため、Lifecycle Configuration に書かれた yum update を夜間にだけ走らせられますし、ml.t3.medium の再起動が数分で完了するので各インスタンスの停止許容時間 15 分以内にも十分余裕があります。さらにルールは台数と無関係に働くため、将来 50 台 100 台へ増えても設定を追加せずに同一ポリシーを維持できます。

SSH や SSM Run Command による手動更新は人手と IAM 権限に依存して工数や誤操作リスクが増え、ネットワーク閉域化だけでは脆弱性自体が残るため要件未達となる一方、SageMaker Lifecycle と EventBridge を組み合わせた夜間自動再起動方式は可用性・セキュリティ・運用負荷という複数要件を総合的にバランスさせた最適解と判断できます。

ヒントボタン

PCI DSS ではカード会員データが公共ネットワークを経由しないことが強調されています。SageMaker ノートブックを置くサブネットに Internet Gateway が関連付けられていたり、NAT ゲートウェイで 0.0.0.0/0 を外に出す経路があると要件違反になるため、VPC ルートテーブルからインターネット宛てのエントリを無くす構成をまず考えましょう。
ただしノートブックは S3 バケットや SageMaker API に接続しなければ開発ができません。インターネットを使わずに AWS バックボーン内で完結させるには、S3 用の Gateway VPC エンドポイントと、SageMaker の Runtime・API 用に Interface VPC エンドポイント（AWS PrivateLink）をプライベートサブネットに作成するのが定番です。
オンプレミス 10.1.0.0/16 とは Direct Connect で閉域接続済みなので、Security Group で当該 CIDR の HTTPS のみを許可すれば開発者 10 名がアクセスできます。IGW や NAT ゲートウェイが不要なぶんコストも抑えられ、プライベートサブネット＋二種の VPC エンドポイントという最小構成が複数要件を総合的に満たします。

ヒントボタン

監査要件である「インターネット経路の完全遮断」を真に実現するには、Amazon SageMaker のネットワーク分離を有効化し、プライベートサブネットに配置した Interface VPC Endpoint（com.amazonaws.ap-northeast-1.sagemaker と .s3）だけを経由させる方法が有効です。ここに aws:SourceVpce 条件付きの S3 バケットポリシーを組み合わせれば、学習コンテナは社内 VPC エンドポイント以外へ物理的・論理的に到達できず、Internet Gateway や NAT Gateway が残っていてもデータ流出リスクを極小化できます。

復旧時間 15 分以内と I/O 1 Gbit/s 以上という性能条件は、m5.2xlarge×32 台でもスループットが自動スケールする Interface VPC Endpoint が鍵になります。NAT Gateway 経由の HTTPS や S3 Gateway Endpoint は帯域共有によるスロットルや転送コストが大きく、週次バッチではボトルネックになりがちです。Interface Endpoint は AZ 内で冗長化される ENI を自動切り替えできるため障害時も復旧が速く、追加運用なく RTO を満たしやすい点が強みとなります。

三つの要求を俯瞰すると、SageMaker の network isolation・Interface VPC Endpoint・S3 バケットポリシーで構成し、NAT Gateway を撤廃する案が最小の運用負荷で監査、性能、コストのバランスを同時に満たします。Endpoint はメンテナンスフリーで IaC にも記述しやすく、将来的なリージョン DR へも転用できるため、長期運用まで見据えた総合判断として最適と言えるでしょう。

ヒントボタン

1
医療データを格納する Amazon S3 は HIPAA の暗号化規定を満たすため、SSE-KMS を強制するバケットポリシーと Block Public Access を併用し、キーの誤用を防ぐためカスタマー管理 KMS キーを指定します。さらに VPC エンドポイントポリシーで s3:PutObject・s3:GetObject を VPC 内の Amazon SageMaker のみ許可することで、VPC 外からの不正アクセス経路を根本的に排除できます。

2
学習や推論を走らせる SageMaker Training、Processing、Batch Transform は VPC のプライベートサブネットに配置し、NAT Gateway を置かずに Interface VPC Endpoint を S3・ECR・STS・CloudWatch Logs 分用意すると、コンテナはインターネットへ出て行けません。加えて EnableNetworkIsolation を true にすると ECS タスク同等のローカル制限が掛かり、HTTP/S で外部サイトへ到達する道が物理的に閉ざされるため、要件②③の「送信禁止」を自然にクリアできます。

3
SageMaker Studio も同じプライベートサブネットに置けば一貫したネットワーク境界が形成され、可視化だけを内部リソースで完結できます。VPC エンドポイントは時間当たり従量課金で NAT より安価なうえ、ログが CloudWatch Logs に集中するので監査も簡単です。暗号化・隔離・コストの三拍子を同時にかなえる構成を選ぶ、という総合的な視点で答えを整理すると迷わなくなります。

ヒントボタン

金融データの暗号化要件として「カスタマー管理型 KMS キーで年次ローテーション」がある場合、S3 では SSE-KMS を選択すると CMK のローテーション設定だけで運用が完了し、CloudTrail で鍵使用も追跡できるためガバナンスが容易になりますが、クライアントサイド暗号化や SSE-S3 では鍵管理が分散したり制御できなかったりして運用負荷が増える点を思い出してください。

機械学習前の PII マスキングには AWS Glue ETL の PySpark で DynamicFrame を使い SHA-256 などのハッシュへ置換する方法が不可逆で安全かつスキーマ変更にも強く、Parquet 圧縮を保ったまま処理できますが、Base64 は可逆であり DataBrew の単純アスタリスク置換は解析精度が落ち、Lambda の文字列操作はコード保守負担が高まることを考慮しましょう。

マスク後のデータを S3 の別プレフィックスへ保存し Glue Data Catalog に独立テーブルとして登録し、SageMaker 実行ロールにそのプレフィックスのみの IAM 権限を付与すればデータサイエンティストは生データに触れずに済み、Athena や Redshift を追加せずとも最小権限とコスト削減が両立できます。

暗号化管理、不可逆マスキング、IAM 最小権限、運用コストの四要件を総合的に眺めると、S3＋SSE-KMS と Glue ETL を中心に据えたシンプルな分離構成が最もバランスよく適合するはずです。

ヒントボタン

学習データとモデル成果物を同じ鍵で保護するには、S3 の SSE-KMS と Amazon SageMaker の OutputEncryptionKey の両方に Customer Managed Key を指定するのが基本です。KMS で CMK を作成してバケットのデフォルト暗号化に紐付け、ジョブ起動時に KeyId を渡せばサービス間で透過的に暗号化され、クライアント側暗号化の追加処理も不要です。CMK は月額数ドル程度で、呼び出し課金も少量なので p3 インスタンス費用と比べれば誤差範囲に収まります。

「SageMaker 以外の IAM ユーザに複合化させない」条件は、KMS の鍵ポリシーで SageMaker 実行ロールにのみ kms:Decrypt を許可し、そのほかのプリンシパルを明示的に除外して実装します。S3 バケットポリシーだけを厳しくしても KMS レイヤで許可が残っていれば復号できるため、データレイヤと鍵レイヤの両方を意識した最小権限設計が不可欠です。

複数の要件を俯瞰すると、サーバーサイド暗号化で「自社管理キー」「年 1 回の自動ローテーション」「最小運用コスト」をすべて満たせるのは、S3 と SageMaker の双方で SSE-KMS を用い同一の Customer Managed Key を設定し、自動ローテーションを有効化しつつ鍵ポリシーで実行ロール専用にする構成だけです。KMS がキー更新と復号制御を担うため運用負荷が小さく、追加コストも CMK 月額と API 呼び出し課金のみで済みます。

ヒントボタン

画像ファイルと推論結果をGDPRに沿って暗号化保管するには、Amazon S3 のデフォルト暗号化に Customer-Managed Key を指定して SSE-KMS を使うと、鍵のライフサイクルを AWS KMS で一元管理でき、クライアント側の手動暗号化や鍵配布が不要になり運用負荷も最小化できます。SSE-S3 は AWS 管理キーで自動暗号化され便利ですが顧客が鍵をコントロールできないため要件を満たさず、クライアント側暗号化はライブラリ実装と復号コードの維持が必要で大規模処理では保守コストが大きくなる点と比較してもこの構成が適切です。さらにオブジェクトロックやバージョニングと組み合わせることで、データレイクの完全性も確保でき、ガバナンス報告の簡素化にも寄与します。

インターネット経路を避けるには NAT Gateway ではなく、Amazon Rekognition の Interface VPC エンドポイントを作成しプライベートサブネットから AWS PrivateLink で DetectLabels API へ直接接続することで、通信が AWS ネットワーク内に閉じ IGW やパブリック IP の管理が不要となりセキュリティグループだけで細粒度制御できます。この方式は VPC Flow Logs で監査も容易なため GDPR のアクセス証跡要件にも対応しやすく、帯域や可用性は AWS インフラにより冗長化されている点も運用担当者にとって安心材料になります。

Amazon Rekognition の DetectLabels は処理後にイメージを保持しないためサービス側永続保存を回避できますが、IndexFaces や CreateStreamProcessor は特徴量や映像をコレクション・Kinesis Video Streams に保存する点が GDPR 上のリスクとなるので注意が必要です。S3 イベントで DetectLabels を呼び出し、結果 JSON を同一バケットに書き戻す流れにし、VPC エンドポイントと CMK を組み合わせることで①顧客管理キーによる暗号化②プライベート経路③サービス側非保持を同時に満たせる構成かを総合的に比較すると最適案が見えてきます。

ヒントボタン

金融データを扱うSageMaker Processingでは、IAMロールに付与するs3:GetObjectやs3:PutObjectなどの権限をencrypted-dataとml-outputの各バケットARNに限定し、ECRもGetAuthorizationToken・BatchGetImage・GetDownloadUrlForLayerのみ許可しつつ、s3:*やAmazonS3FullAccessのようなワイルドカードやマネージドポリシーを避けることで、ネットワーク経路とは独立した厳密な最小権限が実現でき、監査レポートで求められるPII保護要件を満たせます。
KMSのカスタマー管理キーを誤用から守るには、kms:Decryptとkms:GenerateDataKeyだけをキーのリソースポリシーでSageMaker実行ロールのPrincipalに絞り、そのロール側でも同じ二つのアクションに限定する二重フェンスを構成し、さらにkms:Replicateやkms:CreateGrantといった広域操作を拒否することで、他サービスによる鍵流用やリージョン跨ぎコピーのリスクを防ぎ、金融規制が求めるPII暗号化の厳格性を担保できます。
問題文の要望はIAMでの最小権限、S3バケット外部遮断、KMS誤用防止、ECRプル限定、プライベートサブネットでの実行という複数の条件が重なっており、SageMaker専用のカスタムロールとS3・KMS両リソースポリシーを相互に紐づけてスコープを明示的に狭める設計が、ネットワーク側のVPCエンドポイントやセキュリティグループだけに頼る案よりも整合的に全要件を同時充足できることを俯瞰的に確認すると答えに確信が持てます。

ヒントボタン

3 リージョンに散らばる SageMaker InvokeEndpoint などの API イベントを漏れなく収集しつつ運用負荷を抑えるには、アカウント単位ではなく AWS Organizations の統合ビューを活かしてマルチリージョン CloudTrail を 1 本だけ作成し、全アカウント・全リージョンの管理イベントを一括で捕捉する構成が基本です。
監査要件で求められている改ざん検知は CloudTrail のログファイル検証機能が担い、さらに SSE-S3 より詳細なアクセス監査が残る SSE-KMS で暗号化し、書き込みは各本番アカウント、読み取りは監査アカウントに限定した S3 バケットを集中配置すると整合性とセキュリティを両立できます。
Athena や CloudTrail Lake でクロスリージョン・クロスアカウント検索が即座に行え、S3 ライフサイクルを 731 日で自動削除に設定すればストレージコストも抑制できるため、個別リージョンで複数 Trail を運用する案や CloudWatch／AWS Config に頼る方法よりシンプルで長期運用に強いという総合判断になります。

ヒントボタン

まず、Amazon SageMaker の既定メトリクスには p95 がないことを前提に、推論コード側で boto3 を使い CloudWatch PutMetricData を数行呼び出すだけでカスタムメトリクスを発行できることを思い出してください。CloudWatch では Statistic に p95 を指定できるので、個々のレイテンシ値を送るだけで 5 分単位のパーセンタイル計算が自動化でき、Amazon SNS 付きアラームも数クリックで作成できます。追加の Amazon S3 や CloudWatch Logs を伴わないため、構築手順とランニングコストを最も小さく抑えられるのがポイントです。

CloudWatch Logs へアクセスログを出力し Metric Filter でレイテンシを抽出する案は、一見シンプルに見えますが SageMaker Data Capture の設定、ログ保存期間、Insights でのクエリ作成など複数工程が必要です。また Metric Filter はパーセンタイルを自動集計しないため、p95 を監視するには追加処理が発生します。保管料金や処理待ち時間も生じるので「最短実装」「最小コスト」という要件とのギャップを意識して比較してみましょう。

Notebook インスタンスに CloudWatch Agent を入れてポーリングしたり、EventBridge と Step Functions で統計を計算する方法もありますが、新たな EC2 相当の課金や状態遷移コスト、外部呼び出しによる遅延を考慮すると過剰な設計になりがちです。既存エンドポイント内で完結し、CloudWatch と Amazon SNS だけでメール通知まで実装できる方法が全要件を俯瞰した際に最もバランス良い選択になるでしょう。

ヒントボタン

1つ目のヒント:
PHI を置く Amazon S3 バケットはサーバーサイド暗号化として SSE-KMS を選択し、カスタマー管理キー(CMK)を利用することで、鍵が年次ローテーション可能で CloudTrail に記録されます。kms:Decrypt や s3:GetObject を許す IAM ロールは Amazon SageMaker トレーニングジョブ専用に 1 つだけ作成し、開発者グループには一切その権限を与えない設計が「閲覧不可」の前提になります。

2つ目のヒント:
最小権限を担保するには IAM ポリシーだけでなく S3 バケットポリシーと KMS キーポリシーを三重で組み合わせるのがベストプラクティスです。バケットポリシーに aws:PrincipalArn 条件を書き、対象ロール以外のアクセスを拒否し、キーポリシーでも Principal をそのロールに限定すると、仮にアクセスキーが漏えいしても他主体からの s3:GetObject や kms:Decrypt を遮断できます。

3つ目のヒント:
AmazonS3FullAccess などの広範なマネージドポリシーや Principal:”*” を含むキーポリシーは、PHI という高機密データと「最小権限」「年間ローテーション」「監査」の総合要件にそぐいません。SageMaker 専用ロールにリソース ARN を絞った最小ポリシーを付け、CMK 自動ローテーションと CloudTrail 全域記録を有効化する構成こそ、セキュリティ・運用・監査の三要素をバランス良く満たす総合解だと整理できます。

ヒントボタン

推論エンドポイントを VPC 内で閉じたまま呼び出したい場合、SageMaker が提供するインターフェース型 VPC エンドポイント（AWS PrivateLink）を思い出してください。サブネットのルートテーブルを変えずにプライベート IP で通信でき、NAT Gateway や Internet Gateway を経由しません。さらにエンドポイントに関連付けるセキュリティグループで送信元 CIDR とポートを絞り込めるため、10.0.0.0/16 からの TCP 443 のみを許可すればネットワーク層の要件を満たせます。

アイデンティティ面では、SageMaker の VPC エンドポイントポリシーに IAM 制御を記述できます。sagemaker:* アクションを特定のロールだけに許可し、それ以外は Deny を明示すれば、サービスコントロールポリシーやカスタム Lambda 監視を置かなくても多層防御が成立します。ロール管理だけに集中でき、追加コードやアラート対応が不要になるため、最小権限と低運用コストという条件を同時にクリアできます。

ネットワーク経路を AWS 内に限定する PrivateLink、セキュリティグループによる送信元限定、エンドポイントポリシーによる IAM ロール限定という三段構えを単一リソースで実装できれば、インターネットを通らない閉域性・10.0.0.0/16 だけの到達性・MLRole 以外の拒否・保守工数削減という複数条件を俯瞰して最もバランス良く満たせる選択になります。

ヒントボタン

PCI-DSS ではカード会員データが不特定ネットワークを通過しないことが必須です。そのため Amazon S3 に届くパケットは AWS Backbone 内で完結させたいところです。SageMaker ノートブックをプライベートサブネットに配置し、com.amazonaws.region.s3 と com.amazonaws.region.sagemaker の Interface VPC エンドポイントをルートテーブルへ関連付ければ、IGW や NAT Gateway を使わず閉域網通信となります。
月次コストと運用負荷を下げるには NAT Gateway を撤廃し、代替に VPC エンドポイントと IAM 最小権限を組み合わせるのが定石です。S3 バケットポリシーで「aws:sourceVpce」を使い vpce-id を条件にすれば、同アカウントであってもエンドポイント経由以外の経路を遮断できますし、ノートブック用 IAM ロールは s3:GetObject と s3:PutObject など必要な API のみに限定してコンプライアンスを強化できます。
要件を俯瞰すると、1時間以内の RTO は高可用な S3 と VPC エンドポイントの冗長設計でクリアし、インターネット非通過とコスト削減は NAT 廃止＋Interface VPC エンドポイントで達成、管理容易性は最小権限 IAM とバケットポリシーで担保できるため、これらをすべて同時に満たす構成を選択することが最適解になります。