【389 Directory Server講座 第4回】アクセス制御 (ACI) の設計論。ACLとの決定的な違いとセキュアな権限委譲

「全ユーザーが全データを見放題」になっていませんか？

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、dsidm コマンドによるユーザー・グループ管理と、JSON出力を活用した自動化について学びました。
これでディレクトリにデータが入りましたが、このままだとセキュリティ的に非常に危険な状態です。

LDAPサーバーの初期設定の多くは、「匿名（Anonymous）でも検索し放題」か、あるいは「認証さえすれば他人の電話番号もメールアドレスも見放題」になっています。
OpenLDAPでこれを制限しようとすると、slapd.conf や cn=config に正規表現混じりの複雑な ACL (Access Control List) を書く必要があり、多くのエンジニアが挫折してきました。

本記事では、ACIの基本構造、OpenLDAP ACLとの違い、実務で必須となる「自己パスワード変更」や「ヘルプデスクへの権限委譲」の設定パターン、そしてロックアウト時の対処法までを徹底解説します。

---

第1章：OpenLDAP ACL vs 389 DS ACI。決定的な違い

まず、OpenLDAPと389 DSのアクセス制御におけるアーキテクチャの違いを理解しましょう。
ここを理解していないと、389 DSのメリットを活かせません。

OpenLDAP: サーバー設定としてのACL

OpenLDAPのACLは、設定ファイル（slapd.conf）または設定用データベース（cn=config）の中に記述します。

• 管理場所： 設定ファイル内。
• 適用範囲： グローバル設定としてサーバー全体に適用されることが多い。
• 欠点： レプリケーションされない。 スレーブサーバーを構築するたびに、同じACL設定を手動（またはAnsible等）で投入する必要がある。設定変更時のオペミスリスクが高い。

389 DS: 属性としてのACI

389 DSのACIは、ディレクトリツリー内のエントリ（OUやユーザーなど）の属性（attribute）として保存されます。
具体的には aci という属性に権限ルールが文字列として格納されます。

• 管理場所： データ（エントリ）そのもの。
• 適用範囲： そのエントリ以下のサブツリーに継承される。
• 利点： データと一緒にレプリケーションされる。 マスターサーバーでACIを設定すれば、自動的に全スレーブサーバーにも権限設定が同期される。

---

第2章：ACIの解剖学。3つの構成要素を理解する

ACIは一見すると複雑な文字列に見えますが、構造は非常に論理的です。
3つの要素に分解して考えましょう。

基本構文

(targetattr = "属性名") (version 3.0; acl "ルールの名前"; allow (権限) (バインドルール);)

1. ターゲット (Target): 「何を」守るのか。
   特定の属性（userPasswordなど）や、特定のフィルタにマッチするエントリを指定します。
2. パーミッション (Permission): 「どう」させるのか。
   read（読み取り）、write（書き込み）、add（作成）、delete（削除）などを、allow（許可）または deny（拒否）します。
3. バインドルール (Bind Rule): 「誰に」適用するのか。
   特定のユーザー、グループ、IPアドレス、あるいは「自分自身（userdn = “ldap:///self”）」などを指定します。

ACIの評価順序

ファイアウォールとは異なり、ACIには「上から順に評価してマッチしたら終了」という概念はありません。
すべてのACIが評価され、最終的な権限が決定されます。
原則：デフォルトは拒否（Deny）。一つでも許可（Allow）があれば許可。ただし、一つでも明示的な拒否（Deny）があれば、すべてに優先して拒否。

---

第3章：実践ACI設定(1) 基本的な読み取り制限と匿名拒否

ここからは dsconf コマンドを使って実際に設定していきます。
まずは、セキュリティの基本である「匿名アクセスの拒否」です。

デフォルトの状態

インストール直後の389 DSは、ルートDSEに対して匿名での読み取りが許可されている場合があります。
誰でも ldapsearch -x -b "dc=..." でユーザー一覧を取得できてしまう状態です。

匿名アクセスの拒否設定

「認証されたユーザー（all authenticated users）」のみに読み取りを許可するACIをルートDNに設定します。

# インスタンス名: localhost, サフィックス: dc=linuxkoubou,dc=com
dsconf localhost aci add --name "Allow authenticated read" \
  --target-attr "*" \
  --allow-read --allow-search --allow-compare \
  --bind-rule "all" \
  dc=linuxkoubou,dc=com

解説：

• --target-attr "*": すべての属性を対象。
• --allow-read ...: 読み取り、検索、比較を許可。
• --bind-rule "all": これは「すべてのユーザー」ではなく、「認証に成功したすべてのユーザー」を意味します。匿名ユーザーは含まれません。

※逆に「誰でも許可（匿名含む）」にする場合は --bind-rule "anyone" を使いますが、公開ディレクトリでない限り推奨されません。

重要な属性の保護

userPassword などの機密情報は、認証済みユーザーであっても他人に見せてはいけません。
特定の属性へのアクセスを拒否するACIを追加します。

dsconf localhost aci add --name "Deny password read" \
  --target-attr "userPassword || krbPrincipalKey" \
  --deny-read --deny-search --deny-compare \
  --bind-rule "all" \
  dc=linuxkoubou,dc=com

ここで「Deny（拒否）」を使いました。
前述の通り、DenyはAllowより強いため、さきほどの「全属性読み取り許可」の設定があっても、パスワード属性だけは読み取れなくなります。

---

第4章：実践ACI設定(2) 「自分のパスワードは自分で変える」

LDAP運用の基本、「セルフサービス」の設定です。
ユーザーが自分自身の userPassword 属性を変更（書き込み）できるようにします。

自分自身（Self）への許可

dsconf localhost aci add --name "Allow self modification of password" \
  --target-attr "userPassword" \
  --allow-write \
  --bind-rule "userdn = \"ldap:///self\"" \
  dc=linuxkoubou,dc=com

解説：

• userdn = "ldap:///self": これが魔法のキーワードです。
  「アクセスしてきたユーザーのDN」と「アクセス対象のエントリのDN」が一致する場合にのみマッチします。
  これにより、TaroさんはTaroさんのパスワードだけを変更でき、Hanakoさんのパスワードは変更できません。

---

第5章：実践ACI設定(3) ヘルプデスクへの権限委譲（パスワードリセット）

「パスワードを忘れたユーザーのために、ヘルプデスクチームがパスワードを強制リセットできるようにしたい」。
しかし、ヘルプデスクに Directory Manager（特権管理者）のパスワードを教えるのは危険すぎます。
特定のグループに、特定の権限だけを委譲しましょう。

1. ヘルプデスクグループの作成

前回学んだ dsidm でグループを作成し、メンバーを追加しておきます。

dsidm localhost group create cn=HelpDesk,ou=Groups,dc=linuxkoubou,dc=com
dsidm localhost group add_member cn=HelpDesk,ou=Groups,dc=linuxkoubou,dc=com uid=staff1,ou=People,...

2. グループへの書き込み権限付与

HelpDeskグループのメンバーに対し、全ユーザーの userPassword への書き込み権限を与えます。

dsconf localhost aci add --name "Allow HelpDesk password reset" \
  --target-attr "userPassword" \
  --allow-write \
  --bind-rule "groupdn = \"ldap:///cn=HelpDesk,ou=Groups,dc=linuxkoubou,dc=com\"" \
  dc=linuxkoubou,dc=com

これで、staff1 ユーザーは、他人のパスワードを変更できるようになります。
ただし、管理者権限を持っているわけではないので、ユーザーを削除したり、新しいユーザーを作成したりすることはできません。
これが「最小権限の原則」に基づいた運用です。

---

第6章：高度なテクニック。マクロACIと拒否ルール

大規模環境では、ACIの数が増えすぎると管理が大変になり、パフォーマンスも低下します。
これを解決するのが「マクロACI」です。

マクロACIとは？

DNの一部を変数として扱う機能です。
例えば、「ou=Sales,dc=... の下のユーザーは、cn=SalesAdmins,ou=Groups,dc=... グループのメンバーによって管理される」といったルールを、部署ごとに書くのは大変です。

マクロを使えば、1つのACIで「自身の所属するOUと同じ名前を持つ管理者グループに権限を与える」といった記述が可能です。

# 例：($dn) マクロの使用（概念図）
bind-rule: groupdn = "ldap:///cn=($dn),ou=Groups,dc=example,dc=com"

※マクロACIは非常に強力ですが、設定ミス時の影響範囲も広いため、本講座では詳細な構文解説は割愛し、概念の紹介に留めます。

IPアドレス制限

バインドルールにはIPアドレスも指定できます。
「管理者権限でのアクセスは、社内管理セグメント（192.168.100.0/24）からのみ許可する」といった制御が可能です。

bind-rule: "ip = \"192.168.100.*\""

---

第7章：トラブルシューティング。締め出された時の対処法

ACIの設定をミスして、全員（自分含む）アクセス拒否にしてしまった！
……LDAP管理者なら一度は通る道です。

救世主：Directory Manager

389 DSには、すべてのACIをバイパスする特権アカウントが存在します。
それがインストール時に設定した cn=Directory Manager です。
このアカウントは、どんなDenyルールがあろうとも、常にフルアクセス権限を持ちます。

もしACIミスで一般ユーザーがログインできなくなっても、cn=Directory Manager でバインドすれば、問題のあるACIを修正・削除できます。

Get Effective Rights（実効権限の確認）

「なぜかアクセスできない」「なぜか見えてはいけないものが見える」。
そんな時は、CockpitのGUIにある「Access Control」画面か、CLIでACIの一覧を出力して確認します。

dsconf localhost aci list dc=linuxkoubou,dc=com

複雑なACIが絡み合っている場合、対象エントリの aci 属性を直接確認し、どのルールが適用されているか論理的にトレースする必要があります。

---

まとめ：権限管理は「設計」である

お疲れ様でした！
第4回は、389 DSのアクセス制御（ACI）について、基本から応用まで解説しました。

今回の重要ポイント：

• ACIはデータの一部としてレプリケーションされるため、運用管理が楽になる。
• デフォルトは「全て拒否」ではない場合があるため、明示的なルール設定が必要。
• userdn="ldap:///self" を使えば、セルフサービス機能を簡単に実装できる。
• cn=Directory Manager はACIを無視する特権アカウントである。

さて、これで単一サーバーとしての機能はほぼ完成しました。
しかし、このサーバーがハードウェア障害で停止したらどうなりますか？
認証基盤の停止は、業務の完全停止を意味します。

次回、第5回は「マルチマスターレプリケーション構築。可用性99.999%への道」です。
389 DSの真骨頂である、4台以上のマスター構成や、拠点間レプリケーションの構築手順について解説します。お楽しみに！