> For the complete documentation index, see [llms.txt](https://coky-t.gitbook.io/owasp-asvs-ja/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://coky-t.gitbook.io/owasp-asvs-ja/owasp-apurikshonsekyuriti-50/0x17-v8-authorization.md).

# V8: 認可

## 管理目標

認可は、許可されたコンシューマ (ユーザ、サーバ、その他のクライアント) にのみアクセスを付与することを確保します。最小権限の原則 (POLP) を適用するために、検証対象のアプリケーションが以下の上位要件を満たす必要があります。

* 意思決定要因や環境コンテキストを含む認可ルールを文書化している。
* コンシューマは定義された権限によって許可されたリソースにのみアクセスできる必要がある。

## V8.1 認可ドキュメント

包括的な認可ドキュメントは、セキュリティ上の決定が一貫して適用され、監査可能であり、組織のポリシーに準拠していることを確保するために不可欠です。これにより、開発者、管理者、テスト担当者にとってセキュリティ要件が明確で実行可能なものとなり、認可されていないアクセスのリスクを軽減します。

|     #     | 説明                                                                                                                                                | レベル |
| :-------: | ------------------------------------------------------------------------------------------------------------------------------------------------- | :-: |
| **8.1.1** | 認可ドキュメントは、コンシューマのパーミッションとリソース属性に基づいて、機能レベルとデータ固有のアクセスを制限するためのルールを定義している。                                                                          |  1  |
| **8.1.2** | 認可ドキュメントは、コンシューマのパーミッションとリソース属性に基づいて、フィールドレベルのアクセス (読み取りと書き込みの両方) を制限するためのルールを定義している。これらのルールは、状態やステータスなど、関連するデータオブジェクトの他の属性値に依存する可能性があることに注意する。   |  2  |
| **8.1.3** | アプリケーションのドキュメントは、認証と認可に関連するものを含め、セキュリティ上の決定をするために、アプリケーションで使用される環境属性とコンテキスト属性 (時間帯、ユーザの位置情報、IP アドレス、デバイスなどを含むがこれらに限定されない) を定義している。                |  3  |
| **8.1.4** | 認証と認可のドキュメントは、機能レベル、データ固有、フィールドレベルの認可に加えて、環境要因とコンテキスト要因が意思決定でどのように使用されるかを定義している。これは、評価される属性、リスクの閾値、実行されるアクション (許可、チャレンジ、拒否、ステップアップ認証など) を含む必要がある。 |  3  |

## V8.2 一般的な認可設計

機能、データ、フィールドレベルできめ細かい認可コントロールを実装することで、コンシューマは明示的に許可されたものだけにアクセスできるようになります。

|     #     | 説明                                                                                                                                                                                 | レベル |
| :-------: | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-: |
| **8.2.1** | アプリケーションは機能レベルのアクセスが明示的なパーミッションを持つコンシューマに制限されることを確保している。                                                                                                                           |  1  |
| **8.2.2** | アプリケーションは、安全でない直接オブジェクト参照 (IDOR) と壊れたオブジェクトレベル認可 (BOLA) を軽減するために、データ固有のアクセスが特定のデータ項目に対する明示的なパーミッションを持つコンシューマに制限されることを確保している。                                                       |  1  |
| **8.2.3** | アプリケーションは、壊れたオブジェクトプロパティレベル認可 (BOPLA) を軽減するために、フィールドレベルのアクセスが特定のフィールドに対する明示的なパーミッションを持つコンシューマに制限されることを確保している。                                                                      |  2  |
| **8.2.4** | アプリケーションのドキュメントに定義されているように、認証と認可の決定には、コンシューマの環境属性とコンテキスト属性 (時間帯、位置情報、IP アドレス、デバイスなど) に基づく適応型セキュリティコントロールが実装されている。これらのコントロールは、コンシューマが新しいセッションを開始しようとするときだけでなく、既存のセッション中にも適用する必要がある。 |  3  |

## V8.3 操作レベルの認可

特に動的な環境では、認可されていないアクションを防ぐために、アプリケーションのアーキテクチャの適切な層で認可の変更を即座に適用することが重要です。

|     #     | 説明                                                                                                                                                                                                                      | レベル |
| :-------: | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-: |
| **8.3.1** | アプリケーションは信頼できるサービス層で認可ルールを適用し、クライアントサイド JavaScript など、信頼できないコンシューマが操作できるコントロールに依存していない。                                                                                                                                 |  1  |
| **8.3.2** | 認可の決定が行われた値の変更は即座に適用されている。変更を即座に適用できない場合 (自己完結型トークンのデータに依存している場合など)、コンシューマがもはや認可されていないアクションを実行したときに警告を発し、その変更を元に戻すための緩和コントロールが必要である。この代替手段では情報漏洩を緩和しないことに注意する。                                                          |  3  |
| **8.3.3** | オブジェクトへのアクセスは、発信主体 (コンシューマなど) のパーミッションに基づいており、代理で動作する仲介者やサービスのパーミッションではない。たとえば、コンシューマが認証のために自己完結型トークンを使用して Web サービスを呼び出し、それからそのサービスが別のサービスにデータをリクエストする場合、二番目のサービスは、最初のサービスからのマシン間トークンではなく、コンシューマのトークンを使用してパーミッションを決定する。 |  3  |

## V8.4 他の認可の考慮

特に管理インタフェースやマルチテナント環境では、認可をさらに考慮することで、認可されていないアクセスの防止に役立ちます。

|     #     | 説明                                                                                                                                                                  | レベル |
| :-------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-: |
| **8.4.1** | マルチテナントアプリケーションはクロステナントコントロールを使用して、コンシューマ操作が、インタラクションするパーミッションを持たないテナントに決して影響を与えないようにしている。                                                                          |  2  |
| **8.4.2** | 管理インタフェースへのアクセスは、継続的なコンシューマアイデンティティ検証、デバイスセキュリティ態勢評価、コンテキストリスク分析など、複数レイヤのセキュリティを組み込んでおり、ネットワークの場所や信頼できるエンドポイントが、認可されていないアクセスの可能性を減らすことはあるものの、認可の唯一の要素にはならないようにしている。 |  3  |

## 参考情報

詳しくは以下の情報を参照してください。

* [OWASP Web Security Testing Guide: Authorization](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/05-Authorization_Testing)
* [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)