1. 問題と背景
あるサービスが、リソースの読み取りまたは書き込みのリクエストを受け付けます。サービス自体は広範な権限を持っていますが、呼び出し元には限定的な権限のみが与えられるべきです。サービスが呼び出し元によって制御されたパスやリソースIDを使用し、自身の特権で動作すると、攻撃者は呼び出し元が直接実行できないアクションをそのサービスに実行させることが可能になります。AWSはこれを「代理人の混乱（confused deputy）問題」と呼んでいます。
ケイパビリティベースのセキュリティは、リソースを識別すると同時にそれを使用する権利を保持する参照またはトークンにおいて、権限を明示化することでこれに対処します。ケイパビリティは偽造不可能（unforgeable）であり、スコープが制限され、それを必要とするコードにのみ渡される必要があります。この質問は一般的なセキュリティモデルに関する議論であり、特定のクラウドプロバイダーやプログラミング言語に限定されるものではありません。
2. 面接官が評価するポイント
- 権限に関する推論: 認証、認可、および委任された権限の保持を区別できるか？
- 脅威モデリング: 代理人、混乱を引き起こす入力、特権的なアクション、攻撃者が制御する境界を示せるか？
- 最小特権の原則: ケイパビリティを単一の操作、オブジェクト、テナント、または時間枠に減衰（attenuate）させているか？
- ライフサイクルの判断力: ケイパビリティがすべてを解決すると主張することなく、失効、有効期限、監査性、漏洩について説明できるか？
- トレードオフの明確さ: 現実的な運用上の制約の下で、ケイパビリティをアンビエントなアイデンティティやポリシーチェックと比較できるか？
不十分な回答は「トークンを使う」とだけ述べます。優れた回答は、トークンが何を認可するのか、どのように制約されているのか、トークンが漏洩した場合や失効させる必要がある場合に何が起こるのかを説明します。
3. 最初に確認すべき質問
代理人はローカルコード、サービス、またはクラウドアカウントのロールですか？
パターンは同じですが、境界が変化します。ライブラリが誤ってファイルハンドルを継承する場合、サービスが自身のワークロードアイデンティティを使用する場合、クラウドアカウントのロールが騙されてクロスアカウントのリソースに対して操作を行う場合があります。広範な権限を所有するプリンシパルを特定してください。
どのリソースと操作が委任されていますか？
権限が読み取り、書き込み、追加、削除、呼び出し、または複合操作のどれであるかを明確にします。単一のオブジェクトと単一のメソッドに対するケイパビリティは、ワイルドカードのリソース名よりも監査や失効が容易です。
失効および漏洩に関する要件は何ですか？
即時失効、オフライン使用、マルチテナント分離、または否認防止監査が必要かどうかを尋ねます。これらの制約によって、インメモリ参照、署名付きトークン、リース、ブローカー、または中央ポリシーチェックのどれを使用するかが決まります。
4. 30秒の回答フレームワーク
「代理人の混乱は、より権限の低い呼び出し元がより特権の高いサービスにリソース名を提供し、サービスが呼び出し元の意図したスコープにリクエストをバインドすることなく自身の権限を行使するときに発生します。ケイパビリティセキュリティは権限を明示化します。つまり、1つのリソースと許可された操作を指定する偽造不可能な参照またはトークンを渡し、代理人にはその参照のみを使用するように要求します。私は委任時にケイパビリティを減衰させ、テナントと対象者（audience）にバインドし、リスクに応じて有効期限の設定や失効を行い、発行と使用をログに記録します。ケイパビリティはアンビエントな権限と代理人の混乱のリスクを低減しますが、漏洩、リプレイ、リカバリ、監査は設計上の課題として依然残ります。」
5. ステップごとの解説
ステップ1: アイデンティティと権限を分離する
認証は「誰が呼び出しているか」に答えます。認可は「そのアイデンティティがポリシーの下で何を行えるか」に答えます。ケイパビリティは具体的な権限を持つ参照です。所持していること、およびその参照の偽造不可能な完全性によって、特定のアクションが許可されます。このモデルはアイデンティティと共存できますが、すべての内部呼び出しにおいてグローバルでアンビエントなアイデンティティチェックに依存することはありません。
ステップ2: 代理人の混乱フローを描く
レポートサービスが自身のワークロードアイデンティティの下で任意のファイルを読み取ることができると仮定します。ユーザーは file=/reports/other-tenant.csv を送信します。サービスがリクエストが認証されていることのみを検証する場合、サービスは代理人になります。ユーザーが名前を提供し、サービスが自身のより広範な特権を行使します。欠けているバインディングは、「この呼び出し元にこのオブジェクトに対する権限が明示的に与えられていた」という点です。
ステップ3: 名前をスコープ付きの権限に置き換える
代わりに、認可された所有者が特定のレポートと操作に対するケイパビリティを作成します（例：期日までのテナントA用の読み取り専用アクセス）。呼び出し元はそのケイパビリティをサービスに渡します。サービスはケイパビリティをデリファレンスするか、ブローカーに提示します。任意のパスを権限へと変換することはありません。オブジェクトケイパビリティの研究では、このパターンを、個々のオブジェクトにアクセス権をエンコードし、それらの相互作用を制限することとして説明しています。
ステップ4: 委任時に減衰させる
コンポーネントが委任を行う際は、より弱いケイパビリティを生成する必要があります。メソッド数の削減、単一の子オブジェクトへの限定、有効期間の短縮、テナント制約、またはレート制限などです。ダウンストリームのコンポーネントにとって都合が良いからといって、ケイパビリティを拡張してはなりません。readMetadata() のみを公開するラッパーは、書き込み権限と削除権限を持つファイルシステムハンドルを渡すよりも安全です。
ステップ5: トークンとリプレイに対処する
ケイパビリティがプロセスの境界を越える場合は、署名付きかつ対象者が制限されたトークンやブローカーが発行したハンドルなど、保護された参照を使用します。リソース、アクション、テナント、発行者、対象者、有効期限、およびリプレイが問題となる場合は一意のIDを含めます。使用前に完全性とコンテキストを検証します。暗号化によって内容は隠蔽できますが、暗号化自体がスコープを強制したりリプレイを阻止したりするわけではありません。
ステップ6: 失効とリカバリを計画する
純粋なインメモリのケイパビリティは受け渡しが容易ですが、グローバルに失効させることが困難です。リース、短い有効期限、失効ストアによる間接参照、またはキーのローテーションは、即時の制御と可用性・レイテンシとの間でトレードオフの関係にあります。トークンが漏洩した場合は、ハンドルまたはバインディングを失効させ、必要に応じて関連するキーをローテーションし、使用ログを調査します。単にユーザーレコードを削除するだけでは、すでに発行されたケイパビリティが無効化されない場合があります。
ステップ7: 監査およびポリシーの境界を維持する
誰がケイパビリティを発行したか、どのようなスコープを持っていたか、どの代理人がそれを使用したか、そしてその結果を記録します。ケイパビリティが認可プリミティブである場合でも、説明責任のためにアイデンティティコンテキストを保持します。高リスクなアクションについては、ケイパビリティチェックをテナントの状態、リーガルホールド、またはステップアップ認証などのポリシーチェックと組み合わせます。
6. 高品質な回答例
「代理人の混乱とは、特権の不一致です。呼び出し元がリソース名を提供し、より広範な権限を持つサービスが操作を実行します。名前が権限として扱われるため、サービスは混乱します。AWSは、クロスアカウントおよびクロスサービスアクセスのためのパターンとしてこれを文書化しています。
私は代わりに明示的なケイパビリティを渡します。これは、単一のテナント、オブジェクト、操作、対象者、および有効期限にスコープが設定された、偽造不可能な参照または保護されたトークンです。代理人はそのケイパビリティのみを使用でき、委任によって減衰された子が作成されます。リモートトークンの場合、完全性、コンテキスト、およびリプレイ制約を検証し、発行と使用をログに記録します。
失効はトレードオフです。機密性の高いアクションに対しては、検索コストを受け入れた上で、存続期間の短いリースや失効可能なハンドルを使用する場合があります。ケイパビリティはアンビエントな権限を減らし、データフローの検査を容易にしますが、漏洩、リカバリ、監査、またはポリシーの要件を排除するものではありません。私なら、テナント間の試行、トークンのリプレイ、混乱を招く名前、および失効の競合状態をテストします。」
7. よくある間違い
- 「認証だけで十分である」 → 広範なサービスアイデンティティにスコープを決定させてしまう → 操作を明示的かつ制約された権限にバインドする。
- 「署名付きトークンは自動的にケイパビリティになる」 → 対象者、操作、有効期限、リプレイを無視している → 完全性を1つのプロパティとして扱い、スコープを個別に適用する。
- 「ログイン確認後に呼び出し元のパスを使用する」 → 代理人の混乱フローを再現してしまう → 任意の名前ではなく、ケイパビリティまたはブローカーハンドルを渡す。
- 「ケイパビリティによって認可ポリシーが不要になる」 → テナントの状態やコンテキストに応じたルールを見落とす → ケイパビリティチェックを高リスクなポリシーチェックと組み合わせる。
- 「失効にはコストがかからない」 → 分散コピーやオフライン使用を見落とす → 失効要件に基づいてリース、間接参照、または有効期限を選択する。
- 「すべてのアイデンティティコンテキストを隠蔽する」 → インシデント調査が不可能になる → 監査のために発行者、サブジェクト、スコープ、および使用イベントを保持する。
8. フォローアップ質問
ケイパビリティはACLの検索とどのように異なりますか？
ACLの検索はアイデンティティとリソース名から始まり、使用時にポリシーを参照します。ケイパビリティは、データフローを通じて委任された権限参照を運びます。ACLはポリシーと失効を一元化します。ケイパビリティは権限を明示化し、アンビエントな権限を削減できますが、ライフサイクルと漏洩の制御が必要です。
ケイパビリティをコピーすることはできますか？
プロセス内の参照は、すでにそれを保持しているコードによってコピーできることがよくあります。セキュリティの境界は、誰がそれを受け取ることができるか、およびそれが減衰されているかどうかです。リモートトークンは、チャネル、ノンス、対象者、または短いリースにバインドされていない限りリプレイされる可能性があります。コピー可能性はモデル化すべきリスクであり、トークンが無害であると見なす理由にはなりません。
ケイパビリティURLはどのように保護しますか？
ベアラクレデンシャルとして扱います。HTTPS、狭いスコープ、短い有効期限、推測不可能なエントロピー、対象者のバインディング、レート制限、ログおよびリファラーからのマスキングを使用します。機密性が高いアクションや再利用可能なアクションの場合は、失効可能なハンドルとの1回限りの交換を優先します。
クラウドシステムにおいて代理人の混乱はまだどこで発生しますか？
サービスロール、ビルドランナー、またはストレージプロキシがユーザー制御のリソース識別子を受け入れ、自身の広範なロールを使用するときに発生します。リクエストをリソースポリシー、テナント、および意図したアクションにバインドしてください。AWSのクロスアカウントガイダンスは、この境界の具体的な例です。