そろそろLDAPにしてみないか?

第10回OpenLDAPとACL

今回はOpenLDAPにおけるアクセス管理についてお話ししたいと思います。コンピュータの世界でファイルやDBにアクセス権という概念が存在するように、LDAPにおいても同様の考え方が存在します。たとえばLDAP上にUNIXアカウント情報を格納する場合、それぞれのユーザのパスワード情報はツリー上のuserPassword属性に格納します。

/etc/shadowと同様、パスワードは一般的に一方向関数で暗号化した状態で保存しますが、この情報が万が一他人の手に渡ってしまうと、John The Ripperなどのツールによって元のパスワードが漏洩してしまう可能性もあります。そのため、次のような形で適切なアクセスコントロールを行う必要があります。

  • あるユーザは他のユーザのuserPassword属性を得ることはできない。
    他ユーザのエントリを変更することもできない。
  • ただし自分のエントリであれば自由に参照、変更することができる

これ以外の例として、OpenLDAPでは次のようなアクセスコントロールを実現することもできます。

  • 特定のIPアドレスからであれば読み書き可能、それ以外からはリードオンリー
  • mail属性が登録されているユーザからであれば読み取り可能、それ以外からは参照不可能

slapd.confとACL

アクセスコントロールはおなじみのslapd.conf中で設定します。フォーマットは次の通りですが、設定が長くなりがちなので、通常は複数行にまたいでACL設定を行います。

リスト1 ACLの書式
access to <what> [ by <who> <access> [ <control> ] ]+

まずは単純な設定を見てみましょう。

リスト2 全エントリに参照を許可
access to dn.subtree="ou=People,dc=example,dc=com"
  by * read

この設定は、ou=People,dc=example,dc=com以下のサブツリーに対して、アスタリスク、つまり全アクセスにおける読み込み許可を設定しています。もちろん改行を行わず、

リスト3
access to dn.subtree="ou=People,dc=example,dc=com" by * read 

と設定することも可能です。

先ほどのwhatフィールドに設定できる項目は、DN、フィルタ、属性です。つまり「~というDNに対して」⁠~という検索フィルタにマッチする場合に」⁠特定の属性に対して」といった設定を行うことができます。

whoフィールドについては、⁠特定のDNである場合」⁠特定のフィルタにマッチする場合」⁠特定のIPアドレスの場合」などさまざまな設定を行うことができます。すべてを紹介することはできませんので、マニュアルであるslapd.access(5)を参照してください。

accessフィールドでは読み込みや書き込みなどの実際の挙動を設定します。具体的にはnone, disclose, auth, compare, search, read, writeという設定を行うことができますので、たとえば、特定のDNからであれば認証のみ許可するがエントリは参照させない、といった設定も可能です。それぞれの意味は表1の通りです。

表1 それぞれの意味
none なし
disclose なし(エラー情報は開示)
auth 認証の許可
compare 比較の許可
search 検索の許可
read 読み込みの許可
write 読み書きの許可

ちなみに、OpenLDAP-2.4系には管理DITを編集するために、writeよりも強いmanageという設定項目があるようですが、時間の都合により詳しく検証することができませんでした。

最後に、CONTROLフィールドではstop, continue, breakを設定することができます。たとえば

リスト4
access to dn.subtree="dc=example,dc=com"
  by * none
  by peername.ip=127.0.0.1 write

という設定の場合、2行目で全アクセスに対してnoneを設定しているため、通常であれば3行目は評価されず、仮にローカルホストからの接続であっても検索を行うことができません。一方、

リスト5
access to dn.subtree="dc=example,dc=com"
  by * none continue
  by peername.ip=127.0.0.1 write

という設定を行っておけば、2行目にマッチした場合でもcontinueにより3行目の評価を行うことが可能で、その結果ローカルホストからの接続であれば読み書きが可能となります。

ちなみに、これらの例は良くない例なので、実は最初から

リスト6
access to dn.subtree="dc=example,dc=com"
  by peername.ip=127.0.0.1 write
  by * none

という設定を行っておけば、この要件を満たすことができます。では次はbreakに関する例です。

リスト7
access to dn.subtree="dc=example,dc=com"
  by * none
access to dn.subtree="dc=example,dc=com"
  by * read

という設定が存在した場合、全てのアクセスが2行目にマッチしてしまうため、全ての検索などができません。一方、

リスト8

access to dn.subtree="dc=example,dc=com" 
  by * none break 
access to dn.subtree="dc=example,dc=com" 
  by * read 

という設定の場合、2行目の評価が終わっても、継続して以降の評価を行うことができます。この結果、まずは2行目にマッチしてしまうのですが、その後4行目にマッチすることで、読み込み操作が可能となります。

実践: ACL設定

再びUNIXアカウントの例ですが、一般ユーザからの要求であればリードオンリー、ユーザ管理者(ディレクトリサーバ管理者とは異なる)からのアクセスではエントリの編集が可能、といった機能を実現するための設定は次のようになります。

リスト9 slapd.confの一部
access to dn.subtree="ou=People,dc=example,dc=com"
  by dn.exact="cn=useradmin,ou=People,dc=example,dc=com" write 
  by * read
  by anonymous auth

ACLとuserPassword属性

冒頭で説明しましたように、このままでは一般ユーザが別ユーザの暗号化されたパスワード情報を取得することができてしまいますので、設定をもう少し厳しくします。さらに、パスワードはユーザ自身が変更できるように修正してみます。

リスト10 slapd.confの一部
# userPassword属性に対する設定
access to dn.subtree="ou=People,dc=example,dc=com" attrs=userPassword 
  by dn.exact="cn=useradmin,ou=People,dc=example,dc=com" write 
  by self write 
  by anonymous auth 

# それ以外に対する設定
access to dn.subtree="ou=People,dc=example,dc=com" 
  by dn.exact="cn=useradmin,ou=People,dc=example,dc=com" write 
  by * read 
  by anonymous auth 

さて、これまでの設定ではou=People,dc=example,dc=comというツリー以下で設定を行ってきましたが、UNIXアカウントをLDAPで管理する上で、グループ情報は通常ou=Group,dc=example,dc=comというツリーの下に保存されるはずです。従ってこのツリーにもACL設定を行わなければなりません。

リスト11 グループを考慮したACL設定
# ou=People: userPassword属性に対する設定
access to dn.subtree="ou=People,dc=example,dc=com" attrs=userPassword 
  by dn.exact="cn=useradmin,ou=People,dc=example,dc=com" write 
  by self write 
  by anonymous auth 

# ou=People: それ以外に対する設定
access to dn.subtree="ou=People,dc=example,dc=com" 
  by dn.exact="cn=useradmin,ou=People,dc=example,dc=com" write 
  by * read 
  by anonymous auth 

# ou=Group: userPassword属性に対する設定
access to dn.subtree="ou=Group,dc=example,dc=com" attrs=userPassword 
  by dn.exact="cn=useradmin,ou=People,dc=example,dc=com" write 
  by self write 
  by anonymous auth 

# ou=Group: それ以外に対する設定
access to dn.subtree="ou=Group,dc=example,dc=com" 
  by dn.exact="cn=useradmin,ou=People,dc=example,dc=com" write 
  by * read 
  by anonymous auth

このように、ACLの設定自体は同じなのですが設定が長くなってしまいました。このような場合は正規表現ルールを用いて設定をまとめることができます。

リスト12 正規表現を使ったACL設定
# userPassword属性に対する設定
access to dn.regex="ou=(People|Group),dc=example,dc=com$" attrs=userPassword 
  by dn.exact="cn=useradmin,ou=People,dc=example,dc=com" write 
  by self write 
  by anonymous auth 

# それ以外に対する設定
access to dn.regex="ou=(People|Group),dc=example,dc=com$" 
  by dn.exact="cn=useradmin,ou=People,dc=example,dc=com" write 
  by * read 
  by anonymous auth 

このように、正規表現を使うと柔軟なACLを作成することができます。

もう一歩進んだ正規表現ルール

次のように、部署毎にツリーが分かれた状態でアカウントが存在するとします。営業部に所属する鈴木さんは当然サポート部の鈴木さんのエントリを変更してはなりません。

リスト13
cn=suzuki,    ou=People, o=Sales,   dc=example, dc=com
cn=useradmin, ou=People, o=Sales,   dc=example, dc=com
cn=tanaka,    ou=People, o=Support, dc=example, dc=com
cn=useradmin, ou=People, o=Support, dc=example, dc=com

この場合の正規表現を用いたACLは次のようになります。$1を使って正規表現の後方参照を使っているところがミソです。つまり、

o=任意の文字列A,dc=example,dc=com

以下のツリーを変更可能なのは

cn=useradmin,ou=People,o=任意の文字列A,dc=example,dc=com

という設定を実現することができるのです。

リスト14 後方参照を使ったACL
# userPassword 
access to dn.regex="o=([^,]+),dc=example,dc=com$" attrs=userPassword 
  by dn.regex="cn=useradmin,ou=People,o=$1,dc=example,dc=com" write 
  by self write 
  by anonymous auth 

# others  
access to dn.regex="o=([^,]+),dc=example,dc=com$" 
  by dn.regex="cn=useradmin,ou=People,o=$1,dc=example,dc=com" write 
  by * read 
  by anonymous auth

まとめ

単にディレクトリサービスを提供するのは簡単ですが、適切なACLを設定するのは少し面倒な作業になるかもしれません。

例えば、きちんと設定したつもりであっても穴があった、その逆で設定を厳しくしすぎてソフトウェアから参照できない、ということも考えられます。実際にACLを設定したら、ダミーアカウントなどを作成し、正しく動作するか事前に確認しておくことが大切です。

おすすめ記事

記事・ニュース一覧