認可とはリソースの使用を許可されたコンシューマ (ユーザ、サーバ、その他のクライアント) にのみアクセスを許可するプロセスです。検証対象のアプリケーションが以下の上位要件を満たすことを確認します。
- 意思決定要因や環境コンテキストを含むアクセス制御ルールを文書化している。
- コンシューマは定義された権限によって許可されたリソースにのみアクセスできる必要がある。
包括的なアクセス制御ドキュメントは、セキュリティ上の決定が一貫して適用され、監査可能であり、組織のポリシーに準拠していることを確保するために不可欠であり、開発者、管理者、テスト担当者にとってセキュリティ要件が明確で実行可能であることで、認可されていないアクセスのリスクを軽減します。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 1.4.1 | [削除, 4.2.3 でカバー] | ||||
| 1.4.2 | [削除] | ||||
| 1.4.3 | [削除] | ||||
| 1.4.4 | [削除, 不十分な影響] | ||||
| 1.4.5 | [削除, 不十分な影響] | ||||
| 1.4.6 | [追加] アクセス制御ドキュメントは、認証と認可に関連するものも含め、セキュリティ上の決定をするために、コンシューマの環境属性とコンテキスト属性 (時間帯、位置情報、IP アドレス、デバイスなど) の変更を組み込むコントロールを定義している。これらの変更は、コンシューマが新しいセッションを開始しようとするとき、または既存のセッション中の両方で検出される必要がある。 | ✓ | |||
| 1.4.7 | [追加] アクセス制御ドキュメントは、関連するコンシューマとリソースの属性、および意思決定に関わる環境要因を指定して、コンシューマパーミッションに基づいて機能レベル、データ固有、フィールドレベルのアクセスを制限するための明示的なルールを定義している。 | ✓ | ✓ | ✓ |
機能、データ、フィールドレベルできめ細かいアクセス制御を導入することで、コンシューマは明示的に許可されたものだけにアクセスできるようになります。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 4.1.1 | [4.2.3 へ移動] | ||||
| 4.1.2 | [削除, 4.1.3 でカバー] | ||||
| 4.1.3 | [修正, 4.1.2 をカバー] アプリケーションは機能レベルのアクセスが明示的なパーミッションを持つコンシューマに制限されることを確保している。 | ✓ | ✓ | ✓ | 285 |
| 4.1.4 | [削除] | ||||
| 4.1.5 | [7.4.5 へ移動] | ||||
| 4.1.6 | [修正, 4.2.1 から移動, 13.1.4 をカバー] アプリケーションは、安全でない直接オブジェクト参照 (IDOR) と壊れたオブジェクトレベル認可 (BOLA) を軽減するために、データ固有のアクセスが特定のデータ項目に対する明示的なパーミッションを持つコンシューマに制限されることを確保している。 | ✓ | ✓ | ✓ | 639 |
| 4.1.7 | [追加] アプリケーションは、壊れたオブジェクトプロパティレベル認可 (BOPLA) を軽減するために、フィールドレベルのアクセスが特定のフィールドに対する明示的なパーミッションを持つコンシューマに制限されることを確保している。 | ✓ | ✓ | 283 | |
| 4.1.8 | [追加] コンシューマの環境属性とコンテキスト属性 (時間帯、位置情報、IP アドレス、デバイスなど) に基づく認証と認可の決定に関する適用型セキュリティコントロールは、アクセス制御ドキュメントに定義されているとおりに実装されている。 | ✓ | ✓ |
特に動的な環境では、認可されていないアクションを防ぐために、アプリケーションのアーキテクチャの適切な層でアクセス制御の変更を即座に適用することが重要です。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 4.2.1 | [4.1.6 へ移動] | ||||
| 4.2.2 | [50.4.1 へ移動] | ||||
| 4.2.3 | [修正, 4.1.1 から移動, 1.4.1, 14.5.2 をカバー] アプリケーションは信頼できるサービス層でアクセス制御ルールを適用し、クライアントサイド JavaScript など、信頼できないコンシューマが操作できるコントロールに依存していない。 | ✓ | ✓ | ✓ | 602 |
| 4.2.4 | [追加] アクセス制御の決定が行われた値の変更は即座に適用されている。変更を即座に適用できない場合 (自己完結型トークンのデータに依存している場合など)、コンシューマがもはや実行できないはずのアクションを実行したときに警告を発し、その変更を元に戻すための緩和コントロールが必要である。これによって情報漏洩を緩和できないことに注意する。 | ✓ | ✓ | ||
| 4.2.5 | [追加] オブジェクトへのアクセスは、発信主体 (コンシューマなど) のパーミッションに基づいており、代理で動作する仲介者やサービスのパーミッションではない。たとえば、コンシューマが認証のために自己完結型トークンを使用して Web サービスを呼び出し、それからそのサービスが別のサービスにデータをリクエストする場合、二番目のサービスは、最初のサービスからのマシン間トークンではなく、コンシューマのトークンを使用してパーミッションを決定すべきである。 | ✓ | 441 |
特に管理インタフェースやマルチテナント環境では、アクセス制御をさらに考慮することで、認可されていないアクセスの防止に役立ちます。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 4.3.1 | [修正, レベル L1 > L3] 管理インタフェースへのアクセスは、継続的なコンシューマアイデンティティ検証、デバイスセキュリティ態勢評価、コンテキストリスク分析など、複数レイヤのセキュリティを組み込んでおり、ネットワークの場所や信頼できるエンドポイントが、認可されていないアクセスの可能性を減らすことはあるものの、認可の唯一の要素にはならないようにしている。 | ✓ | 419 | ||
| 4.3.2 | [14.3.4, 14.3.5 へ分割] | ||||
| 4.3.3 | [14.7.3 へ移動] | ||||
| 4.3.4 | [追加] マルチテナントアプリケーションはクロステナントコントロールを使用して、コンシューマ操作が、インタラクションするパーミッションを持たないテナントに決して影響を与えないようにしている。 | ✓ | ✓ | ✓ | 283 |
詳しくは以下の情報を参照してください。