アクセス制御（または認可）は、ユーザ、プログラム、またはプロセスからの特定の要求を許可または拒否するプロセスです。 アクセス制御には、それらの特権を付与および取り消す行為も含まれます。 認可（特定の機能またはリソースへのアクセスを検証すること）は、認証（IDの検証）とは異なることに注意してください。 アクセス制御機能は、アクセス制御システムの複雑さに応じて、ソフトウェアの幅広い領域に広がっています。 例えば、アクセス制御メタデータの管理やスケーラビリティのためのキャッシングの構築は、アクセス制御システム内に構築または管理する必要のある追加のコンポネントです。 考慮すべきアクセス制御設計は複数あります。
- 任意アクセス制御（DAC）は、IDに基づきオブジェクト（ファイル、データエンティティなど）へのアクセスを制限する手段です。また、必要最小限のサブジェクト（例えば、ユーザ、プロセス）、および/またはグループへのアクセスのみに制限する手段です。
- 強制アクセス制御（MAC）は、システムリソースに含まれる情報の機微性（ラベルで表される）と、そのような機微情報にユーザがアクセスするための正式な認可（すなわちクリアランス）に基づいて、システムリソースへのアクセスを制限する手段です。
- ロールベースアクセス制御（RBAC）は、リソースへのアクセスを制御するためのモデルで、リソースに対する許可されたアクションが、個々のサブジェクトIDではなくロールで識別されます。
- 属性ベースアクセス制御（ABAC）は、ユーザーの任意の属性とオブジェクトの任意の属性、およびグローバルに認識され現在のポリシーとの関連性が高い環境条件に基づいてユーザー要求を許可または拒否します。
アプリケーション開発の初期段階では、以下に示す「肯定的な」アクセス制御設計要件を考慮する必要があります。
一度アクセス制御の設計パターンを選択すると、新しいパターンでアプリケーションのアクセス制御を再設計するのは困難で時間がかかります。 アクセス制御は、マルチテナンシーや水平（データ依存）アクセス制御などの要件に対処する場合に特に、徹底的に前もって設計しなければならないアプリケーションセキュリティ設計の主要領域の1つです。 アクセス制御の設計は簡単に始めることができますが、しばしば複雑で機能を持ち過ぎたセキュリティ制御に成長することがあります。 ソフトウェアフレームワークのアクセス制御機能を評価する際には、アクセス制御機能により、特定のアクセス制御機能のニーズに合わせたカスタマイズが可能になるようにしてください。
すべての要求が何らかの種類のアクセス制御検証レイヤーを受けることを確認します。 Javaフィルタやその他の自動リクエスト処理機構などの手法は、すべての要求が何らかのアクセス制御チェックを確実に行うのに役立つ理想的なプログラミングの結果です。
デフォルトで拒否するのは、要求が特に許可されていない場合、拒否されるという原則です。 このルールがアプリケーションコードで明示される方法はたくさんあり、以下に例示します。
- アプリケーションコードは、アクセス制御要求の処理中にエラーまたは例外を投げる可能性があります。 このような場合、アクセス制御は常に拒否されるべきです。
- 管理者が新しいユーザを作成するか、ユーザが新しいアカウントを登録すると、そのアカウントが設定されるまで、そのアカウントにはデフォルトで最小限のアクセス権が与えられるか、全くアクセス権が与えられません。
- アプリケーションに新しい機能が追加されると、その機能が正しく構成されるまで、すべてのユーザはその機能の使用を拒否されます。
すべてのユーザ、プログラム、またはプロセスが必要最小限のアクセスしか得られないようにしてください。 きめ細かなアクセス制御構成機能を提供しないシステムには注意してください。
多くのアプリケーションフレームワークは、ロールベースのアクセス制御をデフォルトにしています。 この性質のチェックで満たされたアプリケーションコードを見つけるのが一般的です。
if (user.hasRole("ADMIN")) || (user.hasRole("MANAGER")) {
deleteAccount();
}
このタイプのロールベースのプログラミングでは、コードに注意してください。 それには以下の制約や危険があります。
- この性質のロールベースのプログラミングは脆弱です。 不適切または欠落しているロールチェックを簡単に作成できます。
- ロールベースのプログラミングではマルチテナントが許可されていません。 ロールベースのシステムが異なる顧客に対して異なるルールを持つことを可能にするには、コードをフォークする、または各顧客にチェックを追加するなどの極端な手段が必要になります。
- ロールベースのプログラミングでは、データ固有または水平アクセス制御規則が許可されていません。
- アクセス制御チェックを多数行う大規模なコードベースでは、アプリケーションのアクセス制御ポリシー全体を監査または検証するのが難しい場合があります。 代わりに、以下に示すアクセス制御プログラミング方法を検討してください。
if (user.hasAccess("DELETE_ACCOUNT")) {
deleteAccount();
}
この性質の属性または機能ベースのアクセス制御チェックは、うまく設計された機能豊富なアクセス制御システムを構築するための出発点です。 このタイプのプログラミングにより、時間の経過とともにより大きなアクセス制御カスタマイズ機能が可能になります。
アクセス制御の失敗は、悪意のあるユーザーがアプリケーションの脆弱性を調査していることを示している可能性があるため、すべて記録する必要があります。
- OWASP Top 10 2017-A5-Broken Access Control
- OWASP Mobile Top 10 2014-M5 Poor Authorization and Authentication
- OWASP Cheat Sheet: Access Control
- OWASP Cheat Sheet: iOS Developer - Poor Authorization and Authentication
- OWASP Testing Guide: Testing for Authorization
- OWASP ZAP Access Control Testingアドオンを選択できます