すべてを LDAP に入れる
この記事は https://docs.evolveum.com/iam/myths/everything-in-ldap/ の翻訳です。
Don't Repeat Yourself (DRY) は単なる良い考え方ではなく、law です。 Computer システム内のあらゆる情報は、正確に1か所に存在すべきです。 これはアイデンティティ管理にも当てはまります。 現代のアプリケーションはいずれにせよ LDAP をサポートしています。 では、すべてのアカウントを LDAP に移し、すべてのアプリケーションをその LDAP に接続すれば完了です。 単純で、簡単で、安価です。
実際、それができるなら単純で簡単で安価でしょう。 しかし通常、それは実現可能ではありません。 少なくとも、このような単純な形ではありません。
ディレクトリサービス
LDAP はアプリケーションをディレクトリサービスに接続するプロトコルです。 ディレクトリサービスは phone book に非常によく似ています。単なるデータベースです。 スケーラブル、分散した、標準化されたであるよう設計されていますが、それでも単なるデータベースです。 しかも非常に simplified されたデータベースです。 その職務はデータをストア、検索、取得することです。実際には "検索" の部分も非常に単純です。 ディレクトリサービスの設計判断は拡張性と可用性を優先し、機能と強いデータ整合性を犠牲にしています。
ディレクトリサービスは現在、主に2つの目的で使われています。ユーザーアカウントデータベースと認証です。 ユーザーアカウントなどのデータをストアすることは、ディレクトリサービスが設計された目的であり、そこそこ適切に行えます。 しかし認証は単なる side effect です。 LDAP を認証サービスとして使うアプリケーションは、外部利用のために設計されていない内部 LDAP 認証機構を実際には abuse しています。 LDAP はそのために作られたわけではないため、非常に基本的な認証 "サービス"、つまり認証情報 verification しか提供しません。 そして credential とはパスワードを意味します。 Original LDAP 認証はパスワード以上のものをサポートするにはあまり柔軟ではなかったため、現在は SASL のようなより柔軟な機構に置き換えられつつあります。 しかしそれでも、ディレクトリサービスが認証サービスでは ない という事実は変わりません。 たとえばユーザーセッションを維持しないためシングルサインオンの可能性はなく、historical データをストアしないため login 時間レポートの可能性はなく、logout について何も知りません。
データモデル
LDAP のデータモデルは 標準化された されるよう設計されています。
そしてこれはアイデンティティおよびアクセス管理 (IAM) 分野全体で最も広く受け入れられた標準の1つです。
Standardization には否定できない効果がありますが、欠点もあります。
LDAP データモデルは、すべてのクライアントが適応しなければならないインターフェイスを作ります。
ユーザープロファイルから非常に基本的なデータだけを必要とする、新しく単純なアプリケーションであればこれは問題ありません。
uid、cn、sn、givenName はそのような trivial アプリケーションには十分すぎるでしょう。
しかしアプリケーションがもっとデータを必要としたらどうでしょうか。たとえばローカル時間情報を正しく表示するために必要なユーザーの timezone です。
幸い LDAP は extensible であり、新しい timezone 属性を追加するのは簡単です。
しかし、あるアプリケーションは timezone を "+0200" 形式で期待し、別のアプリケーションは "CEST" を期待し、さらに別のアプリケーションは "Europe/Bratislava" を期待します。
Houston, we have a 問題。
単一属性ではこれは機能しません。
これらのアプリケーションに時間 zone 用の3つの異なる属性を使うよう説得したとしましょう。
しかし今度は、単一のデータ片 を3か所にストアすることになり、DRY 原則 は台無しになります。
そして単純さも一緒に失われます。
今度は、これら3つの価値の整合性を保つ構成要素が必要です。
多くの modern ディレクトリサーバーには、それを行うために使えるプラグイン能力があります。
しかし、この種のことを行う 簡単な方法ではありません。
物事は DIY 方法 に向かい始めます。
そしてすべてはさらに悪化します。
少なくとも2つの標準化された、しかし互いに incompatible な LDAP グループ化機構、groupOfNames と groupOfUniqueNames があります。
あるアプリケーションは前者をサポートし、別のアプリケーションは後者をサポートします。
しかしディレクトリサービスが本当に汎用データベースであるためには、アカウントを両方の種類のグループに配置する必要があります。
そして再び、それを一貫したに保つ何かが必要です。
また多くのアプリケーションは単純なグループ化機構だけでは満足しません。
Sophisticated アプリケーションには sophisticated な認可方法が必要です。
ロール、ACL、権限などが必要です。そして LDAP でこれを行う標準化された方法はありません。
そして本当の難所は組織構造です。
LDAP には organizationalUnit オブジェクトの階層的構造があります。
しかしそれはあまりにも inflexible であり、21世紀の会社で使われる柔軟で多次元な組織構造をモデル化できません。
また、それを表現する incompatible な方法が多数あり、各アプリケーションは少しずつ異なるものを期待します。
さようなら DRY。
データ整合性
データ重複は、複数の LDAP 属性に価値を duplicate することだけに限られません。 もっと深刻な問題があります。 非常に多くの場合、データは LDAP の外にコピーされ、アプリケーションデータベースにストアされる必要があります。 理由は多数あります。 理由の1つはアプリケーションの単純さです。 ほとんどのアプリケーションは LDAP をサポートするように作られて いません。 LDAP サポートは後から追加されただけです。 そのためアプリケーションは、自分自身のデータベースからアカウントデータを read するよう hardcoded されています。 これを LDAP と統合する最も簡単な方法は、first login 時に LDAP からアプリケーションデータベースへデータをコピーすることです。 そして多くのアプリケーションはまさにそれを行っています。 他のアプリケーションは単にデータをローカルにストアする必要があります。 データベース表とディレクトリサーバーの間で join はできません。 したがってアプリケーションがユーザーのフルネームを含むレポートを作成する必要がある場合、その情報を LDAP からデータベース表に replicate しなければなりません。
データを一度コピーするのは比較的簡単です。 しかしコピーを最新に保つにはどうすればよいでしょうか。それははるかに難しいです。 そもそも本当に必要なのでしょうか。アカウントデータはかなり静的ですよね。 実際には、期待するほど静的ではありません。 人口のおよそ半分は、人生で少なくとも一度は名前を変更します。 人には結婚するという厄介な習慣があるからです。 そして結婚は通常 生産年齢 に起こるため、ユーザーアカウントの 名前変更 は驚くほど頻繁です。 組織構造、職務職位、責任の変更を混ぜ合わせると、得られるのはユーザー管理悪夢です。
LDAP が効率的にできないことがもう1つあります。デプロビジョニングです。 LDAP 対応アプリケーションは通常、次のように動きます。ユーザーがアプリケーションに行き、ユーザー名とパスワードを入力します。 アプリケーションはユーザー名を LDAP DN に変換し、LDAP に "login" しようとします。 成功すれば、そのユーザーのローカル記録がアプリケーションに作成され、ユーザーはアプリケーションへのアクセスを許可されます。 ユーザーはアプリケーション内で作業し、新しいデータ、ファイル、history 記録などを作成します。 数年後、そのユーザーは会社を退職し、アカウントは LDAP から削除されます。 しかしアプリケーションはこれについて何も知りません。 Signal を受け取りません。 ユーザーがアプリケーションにアクセスしなくなるだけです。 誰かがアクセスを試みれば認証は fail します。LDAP アカウントがないからです。しかしもう誰も認証を試そうとはしません。 そのため 役に立たなく データはアプリケーション内に永遠に残ります。 これはデータが大きなファイルでいっぱいのホームディレクトリの形である場合に特に興味深い問題になります。 簡単に言えば、クリーンアップする人がいません。 そしてアプリケーションに secondary non-LDAP 認証機構、たとえば SSH キー pair があり、それが LDAP アカウントの removal 後も valid な場合、これはセキュリティリスクにさえなり得ます。
しかしおそらく最も差し迫った実践的な課題は、ユーザーアカウントがそもそもどうディレクトリサーバーに入るのかです。 通常、ディレクトリサービスはデータの主なソースでは ありません。 ソースは人事（HR）システム、CRM、自己登録システム、または類似のものです。 しかし最も頻繁には、複数ソースの組み合わせです。 これらのソースからディレクトリサーバーへデータをどう取り込むのでしょうか。 もちろん DIY 方法 は常にあります。 これは良い start かもしれませんが、驚くほど早く破綻します。
解決策
Key は、ディレクトリサービスは単なるデータベースだと理解することです。 それは完全 IDM ソリューションではなく、そのソリューションの1 構成要素にすぎません。 良い 最初の手順かもしれませんが、その後に他の手順が必要です。 具体的には次の2つです。
- ソース、HR や CRM から LDAP へデータを同期するプロビジョニングシステムを導入する。 これは複雑で高額なものである必要はありません。 単純なオープンソースソリューションで十分です。 同じプロビジョニングシステムは、アプリケーションからのアカウントデプロビジョニング、アカウントデータの同期、グループメンバーシップの管理、ディレクトリデータの整合性維持管理なども処理できます。
- Full 認証機能、SSO などを得るためにアクセス管理ソリューションを使う。
実践的なソリューションは通常、'ディレクトリサービス, アイデンティティ管理 と アクセス管理' という3つの構成要素を持ちます。
しかしそれはディレクトリサービスがもう不要だという意味ではありません。 むしろその反対です。アプリケーションを LDAP に接続するより安価な統合方法はありません。 LDAP を使えるなら、ためらわずに使ってください。 特にアプリケーションが単純で mostly stateless である場合です。 これによりソリューションの price を許容できるに保てます。 しかし heavyweight なアプリケーションには "計画 B" が必要です。 プロビジョニングシステムがそれを非常にうまく処理します。 そしてアクセス管理については、通常 パズルの最後のピース です。 これをうまく行う方法を見極める時間は十分にあります。 後から来ても構いません。 LDAP 認証はかなり長い間、非常にうまく機能します。 同じパスワードであり、10個の異なるパスワードを覚える必要がない限り、人々は何度もパスワードを入力することに対応します。 LDAP はそれをかなりうまく行い、プロビジョニングシステムは LDAP をサポートしないシステムに到達するのを助けます。 そしてアクセス管理の導入は後で計画できます。