認可 (Authorization) とは、リソースへのアクセスを、その使用を許可されたユーザのみに制限する概念です。検証対象のアプリケーションが以下の上位要件を満たすことを確認します。
- リソースにアクセスするユーザが有効なクレデンシャルを持つ
- ユーザには、正しく定義された一連のロールと権限が割り当てられている
- ロールとアクセス許可のメタデータがリプレイや改ざんから保護されている
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 4.1.1 | 特に、クライアント側のアクセス制御が存在し、それが迂回される可能性がある場合には、アプリケーションは信頼できるサービスレイヤに対してアクセス制御ルールを適用する。 | ✓ | ✓ | ✓ | 602 |
| 4.1.2 | アクセス制御で使用されるすべてのユーザ属性とデータ属性およびポリシー情報は、特に認可されていない限りエンドユーザーによって操作されない。 | ✓ | ✓ | ✓ | 639 |
| 4.1.3 | 最小権限の原則が導入されている。ユーザは認可されているものについてのみ、機能やデータファイル、URL、コントローラ、サービス、他のリソースにアクセスできる。これは、なりすましや権限昇格に対する防御となる。 (C7) | ✓ | ✓ | ✓ | 285 |
| 4.1.4 | [削除, 4.1.3 と重複] | ||||
| 4.1.5 | 例外が発生した場合も含めて、アクセス制御がセキュアに失敗する。 (C10) | ✓ | ✓ | ✓ | 285 |
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 4.2.1 | 機密データおよび API が、他人のレコードの作成や更新、全員のレコードの閲覧、すべてのレコードの削除など、レコードの作成、読み取り、更新、削除を目的とする非セキュアダイレクトオブジェクト参照 (Insecure Direct Object Reference, IDOR) 攻撃に対して保護されている。 | ✓ | ✓ | ✓ | 639 |
| 4.2.2 | 認証済みの機能を保護するために、アプリケーションやフレームワークが強力な CSRF 対策メカニズムを実施していること、および有効な自動化対策や CSRF 対策が未認証機能の保護を実施している。 | ✓ | ✓ | ✓ | 352 |
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 4.3.1 | 管理インタフェースが、不正使用を防ぐために、適切な多要素認証を使用している。 | ✓ | ✓ | ✓ | 419 |
| 4.3.2 | ディレクトリリスティグは、意図して許可されない限り、無効となっている。また、ファイルやディレクトリのメタデータ (Thumbs.db、.DS_Store、.git、.svn フォルダなど) の検出や開示が許可されていない。 | ✓ | ✓ | ✓ | 548 |
| 4.3.3 | アプリケーションが、低価値のシステムを対象とした追加の認可 (ステップアップ認証または適応認証など)や高価値アプリケーションを対象とした職務分掌を備えており、アプリケーションのリスクや過去に行われた不正行為に基づき、不正行為対策の管理策を必須とする。 | ✓ | ✓ | 732 |
詳しくは以下の情報を参照してください。