IT基盤部の窪田です。

私からはDeNAインフラのLDAPによるユーザアカウント管理について歴史を振り返りながらご紹介します。

2010年頃まではサーバにSSHでログインするときにはLDAPなどのディレクトリサービスを使わずに、全てのサーバに全ユーザ共通で利用するLinuxユーザを作成し、SSH秘密鍵も全てのサーバにコピーして持たせていました。rootについてはパスワードなしでスイッチできていました。 インフラが小規模なうちはこのやり方でも悪くなかったのかもしれませんが、会社の急成長に伴ってサーバにログインする人数も増えていたため、次第に下記のようなことが問題視されはじめていました。

• rootのような強い権限を誰でも使えるとオペミスがあった場合の被害が大きい。
• 対象サービスの関係者外の人がサーバにログインできてしまう。
• 誰がどんなオペレーションをしたのか見分けがつかない。

サーバにログインする人が増えてくると、サーバ運用面には十分精通していない人も中には出てきたりします。そのような人でもあらゆるサーバにログインできて、かつ、かんたんにrootが扱えてしまうのはオペミス時に大障害を引き起こすリスクを抱えてしまいます。 また、Aというサービスしかみていない人でも自分とは無関係なBというサービスのサーバにログインできてしまうのも問題です。 さらに共通ユーザだと誰がどんなオペレーションをしたのか見分けがつかず、ユーザ個別のオペレーションに問題があってもどのユーザによるものか特定し難いことがあります。

サーバにログインする前に運用ルールについて十分にレクチャーするのは大切なことですが、ヒューマンエラーを完全になくそうとするアプローチは現実的ではないので可能な限りシステマチックにこれらの問題を解決したいところです。

LDAPの導入

既にサーバ台数は数千台の規模で増加していたインフラに円滑に導入できる方法を検討した結果、OpenLDAPを導入して下記のようにユーザアカウントの管理を改善することにしました。

• ユーザ個別にアカウントを作成する。
• rootやシステムユーザへのスイッチはできるだけ禁止して、必要なコマンドをsudoで許可する。
• LDAPとサーバ管理DB（Admintoolと呼んでいます）を連携させてユーザがログインしていいサーバを限定する。

OpenLDAPの細かい設定については割愛しますが、拡張スキーマ openssh-lpk-openldap.schema を使ってSSH公開鍵の一元管理もしているということだけ触れておきます。

ユーザ個別のアカウントについては説明不要と思います。

rootやシステムユーザへのスイッチを極力やらず、必要なだけのコマンド実行権限をLDAPによって一元化されたsudoersで管理することで、rootやシステムユーザ権限を扱えるユーザを必要最小限に抑え、オペミスの被害を抑えることができます。また、sudoするとsyslogにコマンド実行履歴が残るメリットもあり、いつ誰が何をしたのかを追跡しやすくなります。

LDAPとサーバ管理DBの連携というのは何をやっているのかというと、下図のように、サーバにSSHログインする際にSSHサーバがDBに記録されたログイン先サーバに紐づく情報（対象サービス、WebなのかDBなのかのような属性情報など）とLDAPに記録された対象ユーザの情報（description属性に記録しています）を突合させ、ユーザをログイン許可してよいかを自動判別しています。

SSHサーバに上のような機能をアドオンするにはOpenSSHサーバのAuthorizedKeysCommandを使います。OpenSSHサーバはユーザ認証をする際にAuthorizedKeysCommandに設定されたコマンドを実行し、コマンドの標準出力をクライアントが持つ公開鍵として認証に使います。CentOSでopenssh-lpk-openldap.schemaを導入している場合、AuthorizedKeysCommandにはデフォルトで/usr/libexec/openssh/dena-ssh-ldap-wrapperを実行してLDAPサーバからクライアントの公開鍵を取るような仕組みになっていますが、ここを独自のスクリプトに置き換え、スクリプト内でサーバとユーザに紐づく情報を照合することで上の機能を実現しています。

以上のようにDeNAインフラではユーザアカウントの認証、コマンドの認可、サーバログイン許可をLDAPで一元管理しています。LDAP導入後にもログイン許可サーバをOpenStackでテナント化したり、現在進行中のクラウドジャーニーでは現状の管理の課題をふまえて仕組みを刷新しようとしています。これについても別の機会にご紹介できたらと思います。