アクセス制御ルールの強化

アクセス制御ルールについて

MLDAP ESM モジュールを介した LDAP ベースのセキュリティでは、Enterprise Server リソースへのアクセスは、ルールを決定する際にアクセス制御リスト (ACL) によって制御されます。ルールは、特定のタイプのリソース (データ ファイル、プログラム、CICS トランザクション、管理コマンドなど) に対応するクラスにグループ化されます。各ルールには名前があり、ワイルドカード文字を含めることができます。

Enterprise Server は、特定のリソースに対する特定の操作 (読み取り、更新など) をユーザーに承認する必要がある際に、ESF に問い合わせて、リソースのクラスおよび名前、ユーザー情報、および要求されたアクセス レベルを渡します。ESF で MLDAP ESM モジュールは、指定のクラス内にあり、リソース名と名前が一致するルールをすべて検索します。ルール名にはワイルドカードを含めることができるため、複数が一致する場合があります。このモジュールは、最も一致するルールから最も汎用的なルールまで、これらのルールを 1 つ 1 つ調べ、明示的にまたはグループ メンバーシップを通じてユーザーに適用される ACL を持つルールを 1 つ見つけます。そのルールが、操作を許可または拒否する決定ルールになります。

ACL には 1 つ以上のアクセス制御エントリ (ACE) が含まれており、各エントリで、アクター (ユーザーまたはグループの名前。ワイルドカードで指定できる) への権限レベルまたは一連の権限を、許可あるいは拒否します (つまり、ACE は複数のユーザーまたはグループに適用できる)。ユーザーとグループの ACE 間の相互作用、allow と deny ACE 間の相互作用、および複数の ACE がある特定の要求に適用される場合は複雑になる可能性があり、製品ドキュメントで詳しく説明されています。一般的に、より具体的な ACE は具体的でない ACE をオーバーライドします。ユーザー ACE はグループ ACE をオーバーライドし、deny ACE は allow ACE をオーバーライドします。ほとんどの場合、ACE および ACL 処理アルゴリズムの結果は、「驚き最小の原則」に従い、管理者が想定した通りになります。

アクセス制御ルールは、その ACL がどのユーザーにも過剰な権限を付与しないようにすることで強化できます。そのためには、ACL の一部が付与する権限の変更が必要になる場合があります。また、ACE の追加または ACE の変更を行い、特定のユーザーのみに、ある種類のアクセス権を付与するように作成されたさまざまなアクター (通常はグループ) を ACE が参照することで、実現できる場合もあります。

グループ構造

大部分の組織の場合、個々のユーザーを参照する ACE はほとんど、またはまったくありません。ユーザーというきめ細かさで権限を割り当てると、規模の拡大や責任の再割り当てが難しくなります。ワイルドカード (たとえば、allow:*:none ) を使用してすべてのユーザーを参照する汎用ルールを除き、ほとんどの ACE はグループを参照します。

リソース アクセスを制御する目的で、ユーザーをグループに整理する方法は多数あります。グループは、ユーザーの役割 (プロジェクト、部門、または機能領域) 、または単にリソース アクセス割り当てのセットを表現できます。Micro Focus は、ユーザー グループの特定の解釈を推奨していません。グループ構造が明快で十分に文書化されていると、権限の割り当ておよび監査が容易になることに留意してください。

MLDAP ESM モジュールには、さまざまなタイプのグループ オブジェクトを使用するために、ネストされたグループおよび機能など、グループ構造に関する複数のオプションがあります。詳細については、製品ヘルプを参照してください。

最小権限の原則

セキュリティで最小権限の原則とは、ユーザー、グループ、アプリケーションなどのアクターに、必要な権限の最小限のセットを与えるべきであることを意味します。完全に達成するのが難しい場合もありますが、管理者がこの目標に近づくために有効ないくつかのガイドラインを次に示します。

汎用ルールを使用し、デフォルトでアクセスを拒否する

名前 ** のルール、およびリソース クラスの ACL deny:*:all は、より具体的なルールがなければ、すべての要求に一致して、アクセスを拒否します。これにより、具体的なルールでは隠せないリソース名を攻撃者が指定できてしまう場合、問題を回避できます。

注: これらのルールにより不明なリソースがなくなるため、[Allow unknown resources] セキュリティ オプションは有効になりません。少なくとも、リソースはすべて汎用ルールによって隠されます。

ワイルドカード ルールを簡単に使えるようにリソースを整理する

カタログ化されたデータセットが十分に文書化された修飾子の階層に合わせている場合、一連の正確なルールの作成、およびポリシーに対する検証が簡単になります。たとえば、最上位の修飾子 SYS. 以下すべてを SYSADM グループのメンバーだけが書き込み可能な場合、SYS.** という名前の DATASET クラスに、ACL allow:SYSADM group:alter; deny:*:update でルールを作成でき、より具体的なルールにオーバーライドされなければ、このルールが望ましいポリシーを実装することがわかります。一般に、可能な場合はセキュリティ ポリシーに類似した命名規則に合わせることで、作成、維持、および精査が必要なルールの数を減らせます。

厳しく制限する方がいい

厳しすぎるルールにしてから緩和する方が、最初に緩すぎるルールにするよりも優れています。ユーザーが習慣を身につけたり、アプリケーションを展開したりした後で権限を削除しようとすると、多くの問題が発生する恐れがあり、多くの場合、過剰な権限は決して取り消せません。

シンプルで明快なルールを目指す

セキュリティでもう 1 つの重要な概念は、驚き最小の原則です。これは、認識、理解、および推論が困難なシステムには脆弱性が含まれる可能性が高いということを述べています。セキュリティ ルールを読み、その意図を理解できることは重要です。どのようにセキュリティ マネージャーで競合に優先順位を付け、解決しているかについて理解しなければならない例外的なルールおよび競合するルールは避けてください。

経験則では、リソースへのアクセスを制限してから、具体的な要件に従ってアクセスを付与します。そうすると、セキュリティ構成の安全性が高まるだけでなく、アクセス要件およびその正当な理由を文書化することにもつながります。

一般的な推奨事項

Micro Focus は、アクセス制御ルールを強化するために次のことを推奨しています。

• 未使用の機能の権限は、削除するか、システム管理者などの特権ユーザーに制限します。
  注: Enterprise Server で提供されるサンプル ルールには、特に実稼働環境では削除する必要がある多くのサンプルおよびデモンストレーション リソースが含まれています。
• トレース、デバッグ、システム情報のクエリなどの機能が、正当な必要性があるユーザーに制限されていることを確認します。これは、リソース、システム タイプ (たとえば、生産または開発)、およびその他の要因に応じて、システム管理者のみ、またはオペレーターあるいは開発者も意味する場合があります。
• 特定のセキュリティ要件を達成するために、ルール名および ACL をできるだけ一般的なものにします。
• 個々のユーザーではなく、グループに対して ACE を適用します。組織にとって意味のあるものを表現するグループを作成します。
• セキュリティ要件に対応する場合は、高度な機能の使用を検討します。たとえば、MLDAP ESM モジュールのユーザー名置換機能を使用すると、各ユーザーに独自のデータセット「名前空間」へのアクセスを簡単に付与できます。この機能を有効にすると、DATASET クラスに次の 2 つのルールを作成できます。

  USERS.**

  deny:*:all

  USERS.${user}.**

  allow:*:alter

  2 番目のルールは、ユーザーの ID が 2 番目の修飾子として続く USERS の最上位データセット修飾子にのみ適用されるため、各ユーザーは、USERS 領域の下にある自分のデータセットにのみアクセスできます。たとえば、ユーザー ALICE は、USERS.ALICE 以下のすべてにアクセスできます。