AIPAIの安全性、セキュリティ、ガバナンス
ある企業が、複数の開発チームが共有する Amazon Bedrock 環境のガバナンスを強化しています。要件は次の3点です。(1)特定の承認済み基盤モデル（モデルID）以外の InvokeModel を IAM で拒否する、(2)各チームが自チームに割り当てられた Guardrail を必ず付与してモデルを呼び出すよう強制し、Guardrailなしの呼び出しを拒否する、(3)これらをコード変更なしにアクセス制御層で実現する。IAMポリシーで実現する設計として最も適切なものはどれですか。
AInvokeModel に対し、Resource でモデルARNを承認モデルのみに限定し、Condition の bedrock:GuardrailIdentifier が存在しない場合に Deny する条件付きポリシーを適用する
✓ 正解
InvokeModel の Resource を承認モデルARNに限定すると要件(1)を満たし、Condition で bedrock:GuardrailIdentifier 未指定の呼び出しを Deny すると要件(2)を満たし、いずれもIAMアクセス制御層で完結しコード変更不要なため3要件すべてを満たす。
BBedrock のサービスコントロールポリシー(SCP)で全 InvokeModel を許可し、Guardrail の付与は Lambda オーソライザーでアプリ実行時に検証する
SCPで全InvokeModelを許可するとモデル限定の予防制御が効かず、Guardrail検証をLambdaオーソライザーに任せると直接呼び出しを防げずアプリ層依存になるため、要件(1)(3)を満たせず誤りである。
CIAM ロールに AmazonBedrockFullAccess を付与し、承認外モデルとGuardrail未指定は Bedrock Guardrails のブロックポリシーで実行時に遮断する
AmazonBedrockFullAccess は承認外モデルの呼び出しも許可してしまい要件(1)と最小権限に反し、Guardrails のブロックポリシーは応答内容の制御であってGuardrail付与自体を強制できないため不適切。
DKMS キーポリシーで承認モデルのキーのみ復号許可とし、Guardrail 強制は CloudTrail のイベント検知後に自動修復(SSM)で事後ブロックする
KMS キーポリシーはモデルIDごとの呼び出し可否を制御する仕組みではなく、CloudTrail検知後のSSM自動修復は事後対応で予防的に呼び出しを拒否できないため、要件の予防的強制を満たさず誤りである。
解説
IAMの最も基本的かつ確実なアクセス制御は、Resourceでの対象限定とConditionでの条件付与である。InvokeModel の Resource を承認済みモデルのARNに限定すれば要件(1)を満たし、bedrock:GuardrailIdentifier コンディションキーを使い、当該キーが存在しない（Guardrail未指定の）呼び出しを Deny すれば要件(2)を満たす。これらはアプリのコードに依存せずアクセス制御層で強制でき要件(3)も満たす。
選択肢BはLambdaオーソライザーでの実行時検証となり、アクセス制御層での一律強制にならず（API Gateway未経由の直接呼び出しを防げない）コード/構成依存になる。
選択肢CのFullAccessは承認外モデルを許してしまい最小権限に反し、Guardrailの付与強制もできない。
選択肢DのKMSキーポリシーはモデル単位の呼び出し制御に対応せず、CloudTrail後の事後ブロックは予防的強制ではない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでAIPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →