3.1.2　処理、機能の範囲限定

＠Essence

はじめに

原文見出し：
「Limit system access to the types of transactions and functions that authorized users are permitted to execute.」
見出し訳：
「認可（許可）された利用者が実行することを許可されている処理や機能の種類に対して、システムアクセスを限定する。」
この要件も、3.1.1同様、基本セキュリティ要件です。
組織にて必ず実施すべき共通的な基礎要件となります。
認可（許可）された利用者が、その利用者の利用範囲に限定した処理や機能を提供する事を要求しています。
代表的な権限例をITとして身近な事で次に図示します。

図１．代表的なOSのファイル、フォルダ権限


図２．アプリケーションサービスの権限例

図１、図２以外にもネットワークのアクセス制御においては、「許可」、「拒否」があります。物理的、仮想的な違いはあり、その対策は違うもののマシン電源の入切、リセット、CPU、メモリ、ストレージ、NICの増減、設定、管理などが役割、権限として存在します。

原文要約

雑な訳になりますが、要件の原文訳は次の通りです。
-------------------------------------------------------------------------------------
組織は、アクセス特権の定義或いは、アカウントによる他の属性、アカウント種別による他の属性、または両方の組み合わせに対して選択する事が可能である。
システムのアカウント種別は、個人、共有、グループ、システム、匿名、緊急、開発者、製造者、ベンダー及び一時的利用などが含まれる。
アクセスの認可（許可）に必要とされる他の属性は、１日の利用時間帯、週の利用日、及び利用起点の場所などの制限が含まれる。
他のアカウントの属性の定義の中で、組織は、システムに関わる要件（例：システムのアップグレード、計画的な維持管理など）やミッション或いは事業要件（例：時差の違い、顧客要件、出張の要件を支援する遠隔アクセスなど）を考慮する。
-------------------------------------------------------------------------------------

この要件でするべき事

アクセス制御ポリシー、モデルを特定します。
ポリシーと言っても、アクセス元に応じたアクセス先で行う制限事項を特定した内容となります。
また、パターンやモデルも限られているので、次の代表的なポリシー要素と組み合わせて、効果的なアクセス制御ポリシーを策定、適用してください。

  • 役割に応じた権限（管理者、開発者、利用者、運用者、監視者など）

  • 許可或いは拒否（通過させる、させない）

  • 利用範囲或いは領域

  • 利用時間帯（１日の６：００－２２：００）

  • 週の利用日（月ー金）

  • 利用場所（リージョン、地域など）

  • 暗号化・・・など

アクセス制御パターン

アクセス制御を施すパターンとしては、小生の経験上、次の３パターンです。

  • アクセス制御パターン１
    ネットワークのアクセス制御であるパターンです

    • ファイヤーウォール：IP Address

    • Web アプリケーション ファイヤーウォール：IP Address、URL

    • L2機器：MAC Address、接続Port、VLAN

    • L3機器：IP Address、接続Port、VLAN、経路情報

    • ロードバランサー・・・など

  • アクセス制御パターン２
    アクセス先にアクセス制御メカニズムを内包しているパターンです。

    • ファイルサーバ

    • アプリケーションサーバ

    • データベースサーバ・・・など

  • アクセス制御パターン３

    • パーソナルファイヤーウォール

    • IoT デバイス・・・など

アクセス制御モデル

次にアクセス制御モデルです。小生が知っているモデルとして５つあります。一般的に知られているモデルは、任意、強制、役割の３つと認識しています。

  • Discretionary access control (DAC)
    任意アクセス制御
    最も制限の少ないアクセス制御モデルの 1 つです。
    リソース所有者が他の利用者にリソースのアクセスを提供します。
    前述の通り、リソース毎に管理者、つまり複数の管理者が存在し、リソース或いはサービスへのアクセスを制御します。
    たとえば、リソース所有者は財務責任者である場合、財務情報が保存されているファイルへのアクセスを関係者に与えることができます。これは、この部門長がリソースを完全に管理しており、リソース所有者の裁量で誰にでもアクセス許可を割り当てたり取り消したりできることを意味します。
    リソース所有者は、各利用者が持つアクセス レベルを制御することもできます。通常、リソース所有者は、ビジネス全体ではなく、選択したリソースにのみアクセスできます。
    この方法では、ルールのリストと各ユーザーがリソースに対して実行できるアクションを指定するアクセス制御リスト (ACL) を使用します。
    長所：
    リソース所有者が、必要に応じて迅速に、特定の利用者にリソースへのアクセスを許可したい場合に役立ちます。
    リソース所有者は、必要に応じてリソースへのアクセスを取り消すこともできます。
    短所：
    リソース所有者は、社内の他の利用者に対してアクセス制御を構成し、セキュリティ レベルを設定できます。
    これにより、リソース所有者個人が完全に制御できるようになり、エラーの余地が十分に残されます。
    リソース所有者がセキュリティに重点を置いていない可能性があり、その結果、人的ミスが発生してマルウェア感染につながる可能性や関係者外の不正アクセスにつながる可能性があります。
    また、リソース所有者がアクセス権を持っている人とアクセス権を持っていない人について適切に連絡しないと混乱が生じる可能性があります。

  • Mandatory access control (MAC)
    強制アクセス制御
    任意アクセス制御の完全な代替手段として機能します。
    このモデルは、セキュリティと機密性を重視する事業、業務に最適です。
    このモデルでは組織的に認可された一人または複数のシステム管理者が利用者にアクセス許可の責任を与えられるとともに組織全体のアクセス制御を担当します。
    システム管理者を無視したり迂回したりすることはできず、リソースへのアクセスを誰に許可するかはシステム管理者によって決定されます。
    他にも次のような責任があります。
    ・リソースに誰がアクセスすべきかに関するセキュリティポリシーを策定
    ・セキュリティクリアランスの格付け　例： 公開、機密、極秘、極秘
    利用者がリソースにアクセスしようとすると (アクセス要求の生成とも呼ばれます)、強制アクセス制御システムがそのリソースへのアクセスを許可されている利用者の権限をチェックします。
    長所：
    リソースにアクセスする利用者に対する高レベルのセキュリティと制御を提供します。
    これにより、誰かが、重要なリソースに不正にアクセスすることが困難になります。
    利用者が必要なリソースのみにアクセスできるようにするため、機密情報が悪者の手に渡るリスクも軽減します。
    短所:
    システム管理者が 1 人の場合、新しい誰かがアクセスする必要があるときに承認プロセスが遅くなる可能性があります。
    強制的なアクセス制御を企業内で実装するのは、特に従業員やリソースが多い場合には非常に複雑になる可能性があります。
    事前定義されたルールを使用するため、柔軟性がありません。
    これは、職務が動的である場合や、アクセス許可を定期的に変更する必要がある場合には適していません。

任意アクセス制御と強制アクセス制御 (jpcert.or.jp)

JPCERT/CC

  • Role Base Access Control(RBAC)
    役割に基づくアクセス制御
    非裁量アクセス制御とも呼ばれます。
    NISTでも、目につくアクセス制御モデルです。
    このモデルは、タスクまたは機能に基づいて役割に集め、利用者に各役割に準じた権利を割り当てます。
    つまりは、組織的に認可された一人または複数のシステム管理者が職務責任に基づいて権限を割り当てることで、組織内のアクセス制御を管理する理解しやすくかつ効果的な方法です。
    このモデルでは、アクセス制御リストも使用します。
    これらのモデルの中には、役割を階層構造にして、管理を簡素化するものもあります。
    長所：
    同様の役割を持つ利用者をグループ化し、職務に基づいてアクセスを許可することで、アクセス制御管理を簡素化します。
    個々の利用者に基づくのではなく、事前定義された役割に基づいて権限が割り当てられるようにすることで、エラーの余地を減らします。
    短所：
    ビジネスオーナーやシステム管理者が職務機能を分析し、モデルが機能することを確認するために徹底的なテストを実施する必要があるため、実装が複雑になる可能性があります。
    組織内で役割に基づくアクセス制御を有効にするには、ハードウェアやソフトウェアを含む追加のリソースが必要になる場合があります。
    RBACは、多くの方法で拡張され、組み合わされてきました。

  • Rule Base Access Control(RBAC)
    ルールに基づくアクセス制御
    省略すると役割に基づくアクセス制御と同じなので、混乱しないようにしてください。
    利用者またはセキュリティ管理者が事前に作成した一連のルールに基づいて、アクセスを許可または拒否できます。‍
    一連のセキュリティ ポリシーを定義する必要があり、これは組織的に認可されたシステム管理者によって適用されます。
    これらのポリシーは、前述した他のアクセス制御モデルのタイプと同様に、特定のリソースにアクセスする必要がある職務分掌を決定します。
    長所：
    事業、業務にアクセス制御を実装する比較的簡単な方法です。
    事前定義ルールにより、システムへのアクセスを誰に許可するかを簡単に維持および管理できます。
    さまざまな基準に基づいてルールを定義できるため、柔軟性があります。
    短所：
    事前に決められたルールを定義するのは、特に特定のアクセス要件があり、多くの従業員を抱える大企業の場合は難しい場合があります。
    ルールベースのアクセス制御では、アクセスが要求されているコンテキストは考慮されません。たとえば、一部の企業にとって重要な利用者の所在地は考慮できません。

  • Attribute Base Access Control（ABAC）
    属性に基づくアクセス制御
    ポリシーベースのアクセス制御とも呼ばれています。
    このモデルは通常、大量の機密情報を扱い、高レベルのセキュリティを必要とする企業内で使用されます。
    アクセスの許可または制限は、従業員、リソース、および環境の属性に基づいて行われます。

    属性:リソースを説明または識別する情報。
    　　※利用者名、パスワード、指紋などの利用者の属性を記述も可能。
    環境:利用者の職務、部門、または場所。

    利用者が、特定のリソースにアクセスしようとすると、属性ベースのアクセス制御システムが利用者の属性をリソースと照合してチェックします。
    長所：
    このモデルはコンテキスト認識型です。つまり、リソースへの利用者アクセスを割り当てる際に、場所、デバイス、時間などの情報が考慮されます。
    事業、業務の成長に合わせて簡単に拡張できると言われています。
    短所：
    このモデルにはいくつかのセキュリティ リスクが伴います。たとえば、属性が適切に管理または定義されていない場合、攻撃者が属性をコピーしてリソースにアクセスできる可能性があります。
    属性とポリシーの評価には時間がかかるため、このモデルは組織内のパフォーマンスのレベルに影響を与える可能性があります。

3.1.2としては、以上となります。
次は、「3.1.3　情報経路制御」です。
親は、「3.1　アクセス制御」です。

この記事が気に入ったらサポートをしてみませんか？