C1: アクセス制御を実装する (Implement Access Control)

説明

アクセス制御 (または認可) とは、ユーザー、プログラム、プロセスからの特定の要求を許可または拒否することです。アクセス制御の判定ごとに、所定の主体が所定のオブジェクトへのアクセスを要求します。アクセス制御は定義されたポリシーを考慮し、所定の主体に所定のオブジェクトへのアクセスを許可するかどうかを決定します。

アクセス制御にはそれらの権限を付与したり取り消したりする行為も含みます。

アクセス制御は多くの場合、複数のレベルに適用します。たとえば、データベースをバックエンドとするアプリケーションの場合、ビジネスロジックレベルとデータベース行レベルの両方に適用します。さらに、アプリケーションは操作を実行する複数の方法 (API 経由やウェブサイトなど) を提供することがあります。セキュリティ脆弱性から保護するには、これらすべてのさまざまなレベルとアクセスパスを揃える、つまり同じアクセス制御チェックを使用しなければなりません。

認可 (特定の機能やリソースへのアクセスを検証すること) は認証 (アイデンティティを検証すること) と同じではありません。

脅威

  • 攻撃者は緩く構成されたアクセス制御ポリシーに付け込んで、組織がアクセス可能にするつもりがないデータにアクセスできるかもしれません。

  • 攻撃者はアプリケーション内の複数のアクセス制御コンポーネントを発見し、最も弱いものを悪用できるかもしれません。

  • 管理者が古いアカウントを廃止することを忘れ、攻撃者がそのアカウントを発見して、それを使用してデータにアクセスできるかもしれません。

  • 攻撃者はアクセスを許可する最終段階にドロップするポリシーを持つデータへのアクセスを獲得できるかもしれません。 (デフォルト拒否の欠如)

実装

以下は、アプリケーションの初期段階で考慮すべきアクセス制御設計要件の最小限のセットです。

1) アクセス制御を前もって徹底的に設計する

特定のアクセス制御設計パターンを選択すると、新しいパターンでアプリケーションのアクセス制御を再設計することはしばしば困難で時間がかかります。アクセス制御はアプリケーションセキュリティ設計の主要な領域の一つであり、特にマルチテナントや水平 (データ依存) アクセス制御などの要件に対処する場合、前もって徹底的に設計しなければなりません。

アクセス制御設計では二つの中核となるタイプを考慮すべきです。

  • ロールベースのアクセス制御 (RBAC) はリソースへのアクセスを制御するためのモデルであり、リソースに対して許可されたアクションは個々の主体のアイデンティティではなくロールで識別されます。

  • アトリビュートベースのアクセス制御 (ABAC) は、ユーザーの任意のアトリビュートとオブジェクトの任意のアトリビュート、およびグローバルに認識され、現在のポリシーとの関連性が高い環境条件に基づいて、ユーザーアクセスを許可または拒否します。 アクセス制御の設計は最初はシンプルですが、複雑で機能の多いセキュリティ制御になることがよくあります。ソフトウェアフレームワークのアクセス制御の性能を評価する際には、アクセス制御機能が特定のアクセス制御特性のニーズに合わせてカスタマイズできることを確認してください。

2) すべてのアクセス要求がアクセス制御チェックを経るように強制する

すべてのアクセス要求がアクセス制御検証レイヤを経るように強制します。Java フィルタや他の自動要求処理メカニズムなどのテクノロジは、すべての要求がアクセス制御チェックを経るようにする理想的なプログラミングコンポーネントです。これは RFC 2904 では ポリシー適用ポイント (Policy Enforcement Point) と呼ばれています。

3) アクセス制御チェックを統合する

単一のアクセス制御手順またはルーチンを使用します。これにより、複数のアクセス制御実装があり、ほとんどは正しいが一部に欠陥がある、というシナリオを防ぎます。一元化されたアプローチを使用することで、アクセス制御チェックを実行する一つの一元的なライブラリや関数のレビューと修正にセキュリティリソースを集中し、コードベースと組織全体でそれを再利用できます。

4) デフォルトで拒否する

明示的に許可されていない限り、すべてのリクエストがデフォルトで拒否されるようにします。これにはアクセス制御が欠落している API (REST や Webhook) へのアクセスも含みます。 このルールがアプリケーションコードに現れる方法は多数あります。例をいくつかあげます。

  1. アプリケーションコードはアクセス制御要求の処理中にエラーや例外を投げることがあります。このような場合、アクセス制御は常に拒否されるべきです。

  2. 管理者が新しいユーザーを作成したり、ユーザーが新しいアカウントを登録する際、そのアカウントは、そのアクセスが構成されるまで、デフォルトで最小限のアクセスしかできないか、あるいはアクセスできないようにすべきです。

  3. アプリケーションに新しい機能を追加した際、それが適切に構成されるまで、すべてのユーザーがその機能を使用できないようにすべきです。

5) 最小権限の原則 / ジャストインタイム (JIT), ジャストイナフアクセス (JEA)

この原則を実装する例としては、高度な権限アクティビティを必要とする組織機能ごとに専用の権限ロールとアカウントを作成して、日常的に完全な権限を持つ「管理者」ロールやアカウントの使用を避けること、があります。

セキュリティをさらに向上させるには、ジャストインタイム (JIT) やジャストイナフアクセス (JEA) を導入するとよいでしょう。すべてのユーザー、プログラム、プロセスには、それらの現在のミッションを達成するために十分なアクセスのみが付与されます。このアクセスは、その主体が要求した時にジャストインタイムで提供されるべきであり、アクセスは短時間のみ許可されるべきです。きめ細かなアクセス制御構成機能を提供しないシステムには注意してください。

6) ロールをハードコードしない

多くのアプリケーションフレームワークはロールベースのアクセス制御をデフォルトとしています。この種のチェックが満載のアプリケーションコードを見かけることがよくあります。

if (user.hasRole("ADMIN")) || (user.hasRole("MANAGER")) {
    deleteAccount();
}

コード内でこのタイプのロールベースのプログラミングには注意してください。以下のような制限や危険があります。

  • この種のロールベースのプログラミングは脆弱です。コード内にロールチェックの間違いや欠落を簡単に作成します。

  • ハードコードされたロールはマルチテナントを可能にしません。ロールベースのシステムで顧客ごとに異なるルールを持つようにするには、コードをフォークしたり、顧客ごとにチェックを追加するような極端な手段が必要になります。

  • 多くのアクセス制御チェックを伴う大規模なコードベースでは、アプリケーション全体のアクセス制御ポリシーの監査や検証を困難に可能性があります。

  • ハードコードされたロールは、監査時に発見された際、バックドアと見なされることもあります。

7) ABAC ポリシー実施ポイントの例

以下のプログラミング方法を用いて、以下のアクセス制御実施ポイントを検討してください。

if (user.hasPermission("DELETE_ACCOUNT")) {
    deleteAccount();
}

この種のアトリビュートや機能ベースのアクセス制御チェックは、適切に設計されて機能が豊富なアクセス制御システムを構築する出発点となります。このタイプのプログラミングは時間の経過とともにより大きなアクセス制御のカスタマイズ性能も向上します。

防止される脆弱性

参考情報

ツール

PreviousはじめにNextC2: 暗号を使用してデータを保護する (Use Cryptography to Protect Data)

Last updated