第1章 Identity Management の概要

セキュリティー情報は通常、ユーザー、マシン、およびサービスの アイデンティティー に関係があります。アイデンティティーの確認が済むと、サービスおよびリソースへのアクセスを制御できます。

IT 管理者は、効率性、リスク管理、管理の容易化ができるように、ID をできる限り一元管理し、認証ポリシーおよび認可ポリシーで I D 管理を統一しようと試みます。これまで、Linux 環境では、この集中管理の確立が非常に困難でした。ドメインを定義するプロトコル (NIS や Kerberos など) には多数ありますが、他にデータ(LDAP など) を保存したり、未だにアクセス権限 (sudo など) を管理したりするアプリケーションもあります 。これらのアプリケーションはいずれも、相互操作ができないだけでなく、異なる管理ツールを使用します。各アプリケーションは別々に、ローカルで管理される必要がありました。アイデンティティーポリシーを一貫性を持って取得するには、手動で設定ファイルをコピーするか、ID およびポリシーを管理するプロプライエタリーアプリケーションの開発を試みる方法しかありません。

Identity Management は、管理のオーバーヘッドを単純化することが目的です。ユーザー、マシン、サービス、およびポリシーはすべて、同じツールを使用して 1 つの場所で設定されます。IdM でドメインが作成されるので、複数のマシンはすべてそのドメインに参加して同じ設定とリソースを使用できます。ユーザーは一度だけサービスにログインするだけで済み、また管理者は単一のユーザーアカウントを管理するだけで済みます。

IdM は以下の 3 点を行います。

このように、Identity Management を使用することで、管理者は新しい作業を行うのではなく、作業内容を改善できるようになります。以下に、いくつか例を示します。

1 つの極端な例として、制御レベルの低い 環境が挙げられます。Little Example Corp. には複数の Linux サーバーと Unix サーバーがありますが、各サーバーは別々に管理されています。パスワードはすべてローカルマシンに保存されるので、集約された ID または認証プロセスはありません。Tim (IT 管理者) は、すべてのマシンでユーザーを管理し、認証ポリシーと承認ポリシーを別々に設定してローカルパスワードを管理する必要があります。IdM を使用すると、作業が整理されます。ユーザー、パスワード、およびポリシーストアを簡単に集約する方法があり、Tim (IT 管理者) は、マシン 1 台 (IdM サーバー) のみで ID を管理して、ユーザーとポリシーを同じように全マシンに適用します。ホストベースのアクセス制御、委譲などのルールを使用すると、ノートパソコンやリモートユーザーに異なるアクセスレベルを設定することもできます。

中間の例として、制御レベルが中規模 の環境が挙げられます。Mid-Example Corp. には Linux および Unix の複数のサーバーがありますが、Bill (IT 管理者) は、マシンの NIS ドメイン、ユーザー用の LDAP ディレクトリー、認証用の Kerberos を作成して、詳細にわたる制御レベルを管理しようとしています。この環境は適切に管理されていますが、異なるツールを使用して各アプリケーションは別々に管理する必要があります。また、インフラストラクチャーに新しいマシンが追加されたり、サービスがオフラインになると必ず、すべてのサービスを手動で更新する必要があります。このような場合に、IdM を使用すると、簡素化されたツールセット 1 つで、さまざまなアプリケーションをすべてシームレスに統合するため、管理のオーバーヘッドが大幅に削減されます。また、ドメイン内のすべてのマシンにシングルサインオンサービスを実装することもできます。

反対の極端な例として、制御のない 環境が挙げられます。Big Example Corp では、システムの大半が Windows ベースで、密接に統合された Active Directory フォレストで管理されています。ただし、開発、実稼働などのチームには、Linux システムや Unix システムが多数あり、これらのシステムは基本的に Windows が制御する環境から除外されます。IdM は、Active Directory フォレストでは利用できないネイティブツールおよびアプリケーションを使用して、Linux/Unix サーバーをネイティブで管理できるようにします。さらに、IdM は Windows に対応しているため、Active Directory と IdM との間でデータを同期し、集中管理されたユーザーストアを確保できます。

IdM は、ID 管理という非常に一般的であり、また非常に特殊な問題に、非常に簡単なソリューションを提供します。

Identity Management に最も近いものは、389 Directory Server などの標準 LDAP ディレクトリーですが、実際の機能と、意図する機能 にはいくつかの大きな違いがあります。

まず、ディレクトリーサービスとは何かを理解すると役立ちます。ディレクトリーサービスとは、情報を格納するソフトウェア、ハードウェア、およびプロセスの集合のことです。ディレクトリーサービスは、非常に具体的な情報 (例: ホスト名の情報を格納するためディレクトリーサービス) ですが、汎用ディレクトリーサービスはあらゆる種類の情報を保管して取得できます。389 Directory Server などの LDAP ディレクトリーは汎用ディレクトリーです。ユーザー、マシン、ネットワークエンティティー、物理的設備、ビルのエントリーをサポートする柔軟なスキーマがあり、このスキーマをカスタマイズしてほぼすべてのエントリーを定義できます。389 Directory Server のような LDAP サーバーは、拡張性があるため、他のアプリケーションのデータを格納するバックエンドとして頻繁に使用されます。389 directory Server には情報を格納するだけでなく、整理します。LDAP ディレクトリーは、階層構造 (ディレクトリーツリー) を使用して、エントリーをルートエントリー (サフィックス)、中間エントリーまたはコンテナーエントリー (サブツリーまたはブランチ)、およびリーフエントリー (実際のデータ) に整理します。ディレクトリーツリーには、多くの分岐点を持つ非常に複雑なものと、分岐点が少ない非常に単純な (フラット) ものがあります。

LDAP ディレクトリーの主な機能は汎用性で、さまざまなアプリケーションに適合するようにできます。

一方、ID 管理には非常に特殊な目的があり、非常に特殊なアプリケーションに適合します。これは一般的な LDAP ディレクトリーやバックエンド、ポリシーサーバーではなく、これは汎用性はありません。

Identity Management は、アイデンティティー (ユーザーおよびマシン) および、アイデンティティーとそのインタラクションに関連するポリシーに重点を置いています。IdM は LDAP バックエンドを使用してデータを保管しますが、ID 関連のエントリーの特定セットやその詳細を定義する高度にカスタマイズされた特定のスキーマセットがあります。IdM には、エントリータイプや、その目的に関連のある関係が少ししかないので、比較的フラットで、シンプルなディレクトリーツリーが使用されています。また、ID の管理といった特定の目的でしかデプロイできないので、IdM サーバーのデプロイ方法にはルールや制限があります。

また、IdM には制限があるので、管理作業が大幅に簡素化されます。IT インフラストラクチャー全体で明確にロールが定義されているだけでなく、インストールプロセスはシンプルで、コマンドも統一されています。IdM ドメインは、設定、参加、管理が簡単で、特にエンタープライズ全体でのシングルサインオンなどのアイデンティティー/認証タスクといった機能も、より汎用的なディレクトリーに比べ、IdM では実現しやすくなっています。

389 Directory Server などの LDAP ディレクトリーは柔軟性と適応性があるので、任意数のアプリケーションのバックエンドとして最適です。LDAP ディレクトリーの主な目的は、データを効率的に保存して取得することです。

IdM は非常に異なる隙間を埋めます。IdM は、1 つのタスクを非常に効果的に実行するように最適化されています。ユーザー情報、認証および認可ポリシー、およびホスト情報などのアクセスに関する情報などを保存します。その唯一の目的は、アイデンティティーを管理することです。