V4: アクセス制御
管理目標
認可とはリソースの使用を許可された人にのみアクセスを許可するという概念です。検証対象のアプリケーションが以下の上位要件を満たすことを確認します。
リソースにアクセスする人はそうするために有効なクレデンシャルを保持しています。
ユーザは明確に定義された一連のエンタイトルメントに関連付けられています。
アクセス制御ポリシーのメタデータはリプレイや改竄から保護されています。
アクセス制御の欠陥は一般的な自動テストツールを使用して発見される可能性はほとんどありません。このセクションの要件を検証するには、手動テスト、手動支援テスト、またはさまざまなシナリオでのアクセス制御の有効性を検証する一連の堅牢な自動エンドツーエンドアクセス制御テストが必要になります。これらのテストを継続的インテグレーション/継続的デプロイメント (CI/CD) パイプラインに統合することで、これらの要件を継続的に検証することが容易になります。
V4.1 一般的なアクセス制御設計
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
4.1.1 | [修正] アプリケーションは信頼できるサービス層でアクセス制御規則を適用しており、クライアント側の JavaScript など信頼できないユーザーが操作できるコントロールに依存していない。 | ✓ | ✓ | ✓ | 602 |
4.1.2 | [修正] 明示的に認可されていない限り、エンドユーザがユーザロール、パーミッション、機能アクセスレベルなどのアクセス制御ポリシーを変更できないようにする特定の制御が存在する。 | ✓ | ✓ | ✓ | 639 |
4.1.3 | 最小特権の原則が存在する。ユーザは特定の権限を持つ機能、データファイル、URL、コントローラ、サービス、およびその他のリソースにのみアクセスできるようにすべきである。これはなりすましや権限昇格に対する保護を意味する。 | ✓ | ✓ | ✓ | 285 |
4.1.4 | [削除, 4.1.3 と重複] | ||||
4.1.5 | [文法] 例外が発生した場合も含めて、アクセス制御がアクセスを拒否することでセキュアに失敗する。 | ✓ | ✓ | ✓ | 285 |
V4.2 操作レベルのアクセス制御
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
4.2.1 | 機密データおよび API が、他人のレコードの作成や更新、全員のレコードの閲覧、すべてのレコードの削除など、レコードの作成、読み取り、更新、削除を目的とする非セキュア直接オブジェクト参照 (Insecure Direct Object Reference, IDOR) 攻撃に対して保護されている。 | ✓ | ✓ | ✓ | 639 |
4.2.2 | [50.3.1 へ移動] |
V4.3 その他のアクセス制御に関する考慮事項
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
4.3.1 | [修正] 管理インタフェースは信頼できるエンドポイントまたは場所からのみ論理的にアクセスできる。例えば、要塞ホストやジャンプホスト、信頼できる管理ワークステーションやエンドポイント (デバイス認証など) 、管理 LAN などへのアクセスを制限している。 | ✓ | ✓ | ✓ | 419 |
4.3.2 | [14.3.4, 14.3.5 へ分割] | ||||
4.3.3 | [修正] データベースやサードパーティシステムとの統合のために、アプリケーションがパスワードや接続パラメータに関する機密性の高い設定の変更を許可する場合、再認証やマルチユーザー承認などの特別なコントロールによって保護される。 | ✓ | ✓ | 732 |
参考情報
詳しくは以下の情報を参照してください。
Last updated