Directory Server Enterprise Edition のデータを保護する方法は、ほかのすべての設計領域に影響します。この章では、セキュリティー要件の分析方法と、その要件を満たすディレクトリサービスの設計方法について説明します。
この章で説明する内容は次のとおりです。
ディレクトリのセキュリティーを脅かすもっとも典型的な脅威は、次のとおりです。
盗聴:情報は元の状態のままですが、その機密性が損なわれます。たとえば、誰かが、ユーザーのクレジットカード番号を知ったり、機密性の高い会話を記録したり、極秘情報を傍受したりする可能性があります。
不正なアクセス:この脅威には、データ取得操作による、データへの不正なアクセスが含まれます。不正なユーザーが、他のユーザーのアクセスを監視することにより、再利用可能なクライアント認証情報にアクセスする可能性があります。Directory Server Enterprise Edition の認証方法、パスワードポリシー、およびアクセス制御のメカニズムは、不正アクセスの防止に効果があります。
改ざん:転送中の情報が、変更または置換されてから宛先に送信されます。たとえば、誰かが商品の注文を変更したり、他人の履歴書を変更したりできます。
この脅威には、データまたは設定情報の不正な変更が含まれます。ディレクトリが改ざんを検出できない場合、攻撃者がサーバーへのクライアントの要求を変更する可能性があります。また、攻撃者が要求を取り消したり、クライアントへのサーバーの応答を変更したりする可能性もあります。SSL (Secure Socket Layer) プロトコルや、それと同様の技術を利用して、接続の両端で情報に署名することで、この問題は解決できます。
偽装:情報が、意図する受信者のふりをした人に渡されます。
偽装には、なりすましと不当表示の 2 つの形態があります。
なりすまし:人またはコンピュータが、ほかの誰かのふりをします。たとえば、ある人がメールアドレス jdoe@example.com を持っているふりをしたり、あるコンピュータが自身を偽って www.example.com という名前のサイトのふりをしたりする可能性があります。
不当表示:人または組織が自身を不当表示します。たとえば、サイト www.example.com が、あたかも家具販売店であるふりをしているが、実際にはクレジットカードによる支払いを受けても決して商品を送らないサイトだったりします。
サービス拒否:攻撃者が、システムリソースを使用することで、それらのリソースが正規ユーザーによって使用されるのを妨害します。
サービス拒否攻撃とは、侵入者がディレクトリによるクライアントへのサービスの提供を妨害することです。Directory Server Enterprise Edition では、特定のバインド DN に割り当てるリソースに制限を設定することで、サービスの拒否攻撃を防ぎます。
セキュリティーポリシーは、不正なユーザーによって機密情報が変更または取得されるのを防げる必要がありますが、同時に十分に管理しやすい必要もあります。
Directory Server Enterprise Edition が提供するセキュリティー手法は、次のとおりです。
認証:一方が他方の識別情報を検証する方法を提供します。たとえば、LDAP のバインド操作時に、クライアントは Directory Server にパスワードを提示します。「パスワードポリシー」は認証プロセスの一部として、有効期限、長さ、構文など、パスワードが有効とみなされるために満たす必要のある条件を定義します。「アカウントの無効化」は、ユーザーアカウント、アカウントのグループ、またはドメイン全体を無効にして、すべての認証の試行に対して、自動的に拒否するようにします。
暗号化:情報の機密性を保護します。データを暗号化すると、データは受信者だけが復号化できるような方法で符号化されます。「Secure Sockets Layer」(SSL) は、転送中の情報を暗号化することでデータの完全性を維持します。送信する情報に暗号化とメッセージダイジェストを適用した場合、受信者は、その情報が転送中に改ざんされていないことを確認できます。「属性暗号化」は、格納された情報を暗号化することでデータの完全性を維持します。
アクセス制御:さまざまなディレクトリユーザーに与えるアクセス権限を調整し、必要な証明情報またはバインド属性を指定する方法を提供します。
監査:ディレクトリのセキュリティーが危険にさらされていないかを確認できます。たとえば、ディレクトリで保持されるログファイルを監査できます。
これらのセキュリティーツールは、ユーザーのセキュリティー設計で組み合わせて使用できます。セキュリティーの設計をサポートするために、レプリケーションやデータの分散など、ほかのディレクトリの機能を使用することもできます。
Directory Server Enterprise Edition は、次の認証方法をサポートしています。
ユーザーが人間か LDAP 対応アプリケーションかにかかわらず、すべてのユーザーに対して同じ認証メカニズムが適用されます。
この節には、上記の認証メカニズムのほかに、認証に関する次の情報も含まれています。
匿名アクセスは、ディレクトリアクセスのもっとも単純な形態です。匿名アクセスは、ユーザーが認証済みかどうかにかかわらず、すべてのディレクトリユーザーに対してデータを利用可能にします。
匿名アクセスでは、誰が検索を実行しているかや、どのような種類の検索が実行されているかを追跡することができません。追跡できるのは、誰かが検索を実行している、ということだけです。匿名アクセスを許可すると、ディレクトリに接続するユーザーはだれでもデータにアクセスできます。データへの匿名アクセスを許可したまま、あるユーザーやグループをそのデータからブロックしようとしても、そのユーザーは、ディレクトリに匿名でバインドすることでそのデータにアクセスできます。
匿名アクセスの特権は制限できます。通常、ディレクトリ管理者は、匿名アクセスに対して読み取り、検索、および比較の特権だけを許可します。また、ユーザー名、電話番号、電子メールアドレスなど、一般的な情報を含む属性のサブセットにアクセスを限定することもできます。政府識別番号、自宅の電話番号や住所、給与情報など、機密データへの匿名アクセスを許可しないでください。
ルート DSE (ベース DN "") への匿名アクセスは必要です。アプリケーションはルート DSE への匿名アクセスを使用することで、サーバーの機能、サポートされているセキュリティーメカニズム、およびサポートされているサフィックスを確認できます。
匿名アクセスが設定されていない場合、クライアントは、Directory Server への認証を行わないとディレクトリのコンテンツにアクセスできません。単純パスワード認証では、クライアントは再使用可能な簡単なパスワードを提供して、サーバーへの認証を行います。
クライアントはバインド操作を使って Directory Server への認証を行いますが、そのバインド操作でクライアントは識別名と資格情報を提供します。サーバーは、そのクライアント DN に対応するエントリを特定したあと、そのクライアントのパスワードがエントリに格納された値に一致するかどうかをチェックします。パスワードが一致すれば、サーバーはそのクライアントを認証します。パスワードが一致しない場合、認証操作は失敗し、クライアントにエラーメッセージが返されます。
単純パスワード認証の欠点は、パスワードが平文として送信されることです。その場合、セキュリティーが損なわれる可能性があります。悪意のあるユーザーが盗聴している場合、そのユーザーは承認されたユーザーを偽装できます。
単純パスワード認証を使えば、ユーザーの認証を容易に行えます。ただし、単純パスワード認証を使用するのは、組織のイントラネットに限定する必要があります。この種類の認証では、エクストラネットを介した取引先との転送やインターネット上での顧客との転送に求められるレベルのセキュリティーは提供されません。
セキュリティー保護された接続では、暗号化によって第三者がデータを読めないようにした上で、Directory Server とクライアントの間でデータを送信します。クライアントは、次のいずれかの方法でセキュリティー保護された接続を確立できます。
SSL (Secure Socket Layer) を使用してセキュリティー保護されたポートにバインドする
匿名アクセスでセキュリティー保護されていないポートにバインドし、Start TLS 制御を送信して TLS (Transport Layer Security) を使用する
どちらの場合も、サーバーにはセキュリティー証明書が必要で、この証明書を信頼するようにクライアントを設定する必要があります。サーバーは、証明書をクライアントに送信することで、公開鍵暗号化方式を使用して「サーバー認証」を行います。その結果、クライアントは目的のサーバーに接続していること、およびサーバーが改ざんされていないことを認識します。
次に、機密保護のため、クライアントとサーバーは、接続を介して送信されるすべてのデータを暗号化します。クライアントは、暗号化された接続でバインド DN とパスワードを送信してユーザー認証を受けます。それ以降の操作はすべて、そのユーザーの ID を使って実行されます。バインド DN がほかのユーザー ID のプロキシ権限を持っている場合には、プロキシ ID を使って操作が実行される可能性もあります。操作の結果がクライアントに返されるときは、すべてが暗号化されます。
SSL または TLS 上で暗号化接続を確立する場合、「クライアント認証」を要求するようにサーバーを設定することもできます。クライアントは、ユーザー ID の確認のためにサーバーに証明書を送信する必要があります。バインド DN の決定には、ユーザーの DN ではなく、証明書が使用されます。クライアント認証は、ユーザーの偽装を防ぐ保護で、もっとも安全な接続です。
証明書に基づくクライアント認証は、SSL 層と TLS 層のみで動作します。証明書に基づく認証 ID を LDAP で使用するには、SSL 接続の確立後に SASL EXTERNAL 認証を使用する必要があります。
証明書に基づくクライアント認証を設定するには、dsconf get-server-prop コマンドを使用します。詳細については、dsconf(1M) のマニュアルページを参照してください。
SSL または TLS 接続時のクライアント認証では、汎用セキュリティーインタフェースの Simple Authentication and Security Layer (SASL) を使ってクライアントの ID を確立することもできます。Directory Server Enterprise Edition が SASL を通じてサポートするメカニズムは、次のとおりです。
DIGEST-MD5:このメカニズムは、クライアントから送信されたハッシュ値とユーザーパスワードのハッシュを比較することでクライアントを認証します。ただし、このメカニズムはユーザーパスワードを読み取る必要があり、DIGEST-MD5 による認証を希望するすべてのユーザーは、ディレクトリ内に {CLEAR} パスワード (平文形式のパスワード) を持つ必要があります。
GSSAPI:General Security Services API (GSSAPI) は、Solaris オペレーティングシステム上でしか利用できません。これを使えば、Directory Server は Kerberos V5 セキュリティーシステムと対話してユーザーを特定できます。クライアントアプリケーションは Kerberos システムに証明情報を提示し、このシステムがユーザーの ID を Directory Server に返します。
EXTERNAL:このメカニズムは、SSL や TLS などの外部セキュリティー層によって指定された資格情報に基づいて、LDAP のユーザーを認証します。
詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「クライアントでの SASL DIGEST-MD5 の使用」および『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「クライアントでの Kerberos SASL GSSAPI の使用」を参照してください。
あるユーザーアカウントまたは一連のアカウントを無効にすることで、認証を一時的に防止することができます。アカウントを無効にすると、ユーザーは Directory Server にバインドできず、認証処理が失敗します。詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「アカウントの手動でのロック」を参照してください。
このバージョンの Directory Server では、パスワードによる認証失敗が監視およびレプリケートされます。これにより、無効なパスワードによる認証の試みがある指定された回数だけ行われたときに、グローバルアカウントロックアウトを速やかに行えます。グローバルアカウントロックアウトは、次のどの場合でもサポートされています。
クライアントアプリケーションがトポロジ内の単一のサーバーだけにバインドする
読み取り専用のコンシューマがトポロジ内に 1 つも含まれていない
Directory Proxy Server を使ってすべてのバインドトラフィックが制御される
すべてのバインド試行が同一のサーバーに向けられず、ロックアウトデータがレプリケートされるよりも早く、クライアントアプリケーションが複数のサーバー上でバインド試行を実行するような状況を想像してください。最悪の場合、クライアントがバインドを試みたサーバーごとに、指定された回数の試みをクライアントに許可することになります。クライアントアプリケーションを駆動する入力を与えるユーザーが人間である場合には、こうした状況はあまり起こりそうにありません。しかし、トポロジを攻撃するために構築された自動化クライアントであれば、この配備選択を悪用することができます。
優先順位付きレプリケーションを使えば、侵入者検出の際に、非同期レプリケーションの遅れによる影響を最小限に抑えることができます。ただし、バインド試行が指定された回数だけ失敗した直後にアカウントロックアウトを行いたい場合もあります。その状況では、ある特定のエントリ上でのすべてのバインドの試みを、Directory Proxy Server を使って同一のマスターレプリカに配信する必要があります。そうするための Directory Proxy Server の設定方法については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Operational Affinity Algorithm for Global Account Lockout」を参照してください。
レプリケーショントポロジ内で厳密にローカルなロックアウトポリシーを維持するには、version 5.2 のパスワードポリシーとの互換性を維持する必要があります。その状況では、有効なポリシーがデフォルトのパスワードポリシーであってはいけません。また、読み取り専用のコンシューマにバインドを制限することによっても、ローカルロックアウトを実現することができます。
グローバルアカウントロックアウトの動作方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Global Account Lockout」を参照してください。
Directory Server は、ネットワークユーザーアカウントを Directory Server ユーザーアカウントに関連付けるユーザーアカウントホストマッピングを提供します。この機能を使えば、両方のユーザーアカウントの管理が容易になります。ホストマッピングは、外部で認証されたユーザーの場合に必要となります。
プロキシ承認は、特殊な形態のアクセス制御です。プロキシ承認またはプロキシ認証では、アプリケーションが、特定のユーザー名/パスワードの組み合わせを使ってサーバーへのアクセスを取得することを強制されます。
プロキシ承認では、管理者は、ある通常ユーザーの ID を引き受けることで Directory Server へのアクセスを要求できます。管理者は、自身の資格情報を使ってディレクトリにバインドし、その通常ユーザーの権利を許可されます。この引き受ける ID は、「プロキシユーザー」と呼ばれます。そのユーザーの DN は、「プロキシ DN」と呼ばれます。プロキシユーザーは通常のユーザーとして評価されます。プロキシユーザーのエントリがロックまたは無効化されているか、そのパスワードの有効期限が切れていると、アクセスが拒否されます。
プロキシメカニズムの利点は、Directory Server にアクセスしようとする複数のユーザーに対して、LDAP アプリケーションが単一のバインドを使ってサービスを提供できるという点にあります。各ユーザーがわざわざバインドおよび認証する代わりに、クライアントアプリケーションが Directory Server にバインドし、プロキシの権限を使用します。
詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の第 6 章「Directory Server のアクセス制御」を参照してください。
パスワードポリシーは、システム内でパスワードがどのように管理されるかを規定した規則の集合です。Directory Server は、デフォルトのパスワードポリシーはもちろん、複数のパスワードポリシーもサポートします。
パスワードポリシーのいくつかの要素は設定可能であるため、組織のセキュリティー要件に合ったポリシーを設計できます。パスワードポリシーの設定については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の第 7 章「Directory Server のパスワードポリシー」を参照してください。パスワードポリシーの設定時に利用可能な個々の属性については、pwpolicy(5dssd) のマニュアルページを参照してください。
この節は、次の項目で構成されています。
パスワードポリシーのオプション
レプリケーション環境でのパスワードポリシー
パスワードポリシーの移行
次のようなパスワードポリシーのオプションがあります。
デフォルトパスワードポリシーが適用されます。このデフォルトポリシーのパラメータは、変更可能です。
別の特殊なパスワードポリシーを特定のユーザーに適用できます。
CoS およびロール機能を使用することで、別の特殊なパスワードポリシーを一連のユーザーに適用できます。パスワードポリシーは、スタティックグループには適用できません。
デフォルトパスワードポリシーの設定情報はレプリケートされません。代わりに、それはサーバーインスタンスの設定の一部になっています。デフォルトパスワードポリシーを変更すると、トポロジ内のすべてのサーバー上でそれと同じ変更が施されます。レプリケート「される」パスワードポリシーが必要な場合は、レプリケートされるディレクトリツリー内に、特殊なパスワードポリシーを定義する必要があります。
ユーザーエントリに格納されているパスワード情報のすべてがレプリケートされます。この情報には、現在のパスワード、パスワード履歴、パスワードの有効期限などが含まれます。
レプリケートされた環境では、パスワードポリシーによる次の影響を考慮してください。
パスワードの期限切れが近づいたユーザーは、パスワードを変更するまで、バインドするすべてのレプリカから警告を受信します。
あるユーザーがパスワードを変更しても、その新しいパスワードがすべてのレプリカ上で更新されるまでに、しばらく時間がかかる可能性があります。あるユーザーがパスワードを変更してすぐに、新しいパスワードを使ってコンシューマレプリカの 1 つにバインドし直した、といった状況が発生する可能性があります。この場合、レプリカが更新されたパスワードを受信するまで、バインドがおそらく失敗します。この状況を緩和するには、優先順位付きレプリケーションを使ってパスワード変更が最初にレプリケートされるように強制します。
Directory Server Enterprise Edition のパスワードポリシーの設定は、6.0 より前のバージョンの Directory Server で提供されていたパスワードポリシーの設定とは異なります。異なるバージョンの Directory Server が稼働するサーバーがトポロジ内に含まれている場合には、『Sun Java System Directory Server Enterprise Edition 6.1 Migration Guide』の「New Password Policy」を参照し、パスワードポリシーの設定の移行方法について確認してください。
Identity Synchronization for Windows は、Directory Server と Windows との間で、パスワードを含むユーザーアカウント情報を同期させます。Windows Active Directory と Windows NT の両方がサポートされています。Identity Synchronization for Windows は、スケーラビリティーの高いセキュリティー機能の豊富なパスワード同期ソリューションを、小規模、中規模、および大規模企業向けに構築する際に役立ちます。
このソリューションが提供する機能は次のとおりです。
Active Directory、Windows NT、および Directory Server 間における同期アカウントの作成、変更、無効化、および削除
ネイティブパスワード変更を同期させるための、プロプライエタリな異種ディレクトリソースとの統合
配備内での Identity Synchronization for Windows の使用方法の詳細については、『Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide』を参照してください。
暗号化は、転送中のデータや格納されたデータを保護する際に役立ちます。この節では、次のデータ暗号化手法について説明します。
セキュリティー設計には、ユーザーを特定するための認証スキーマ方式や、情報を保護するためのアクセス制御方式以外の要素も含まれます。サーバーとクライアントアプリケーションとの間でネットワーク経由で送信される情報の完全性も保護する必要があります。
ネットワーク上で安全な通信を可能にするために、SSL (Secure Sockets Layer) 上で LDAP プロトコルと DSML プロトコルの両方を使用することができます。SSL が設定および有効化されると、クライアントはある専用のセキュアポートに接続します。そして、SSL 接続の確立後にすべての通信が暗号化されます。Directory Server と Directory Proxy Server は、Start Transport Layer Security (Start TLS) 制御もサポートします。Start TLS を使えば、クライアントは標準の LDAP ポート上で暗号化接続を開始できます。
Directory Server の SSL と TLS の概要については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 2 章「Directory Server Security」を参照してください。
属性の暗号化は、格納されたデータの保護に関係します。この節では、属性の暗号化機能について説明し、次のトピックを取り上げます。
Directory Server Enterprise Edition は、パスワード認証、証明書に基づく認証、SSL、プロキシ承認など、アクセスレベルでデータを保護するためのさまざまな機能を提供しています。ただし、データベースファイル、バックアップファイル、および LDIF ファイルに格納されたデータも保護する必要があります。属性を暗号化する機能を使用することで、格納されている機密情報にユーザーがアクセスできないように保護できます。
属性の暗号化を使えば、特定の属性を暗号化された形式で格納できます。属性の暗号化はデータベースレベルで設定されます。したがって、ある属性を暗号化すると、その属性がデータベース内のすべてのエントリで暗号化されます。属性の暗号化はエントリレベルではなく属性レベルで行われるため、エントリ全体を暗号化するには、すべての属性を暗号化する必要があります。
属性の暗号化を使えば、データを暗号化された形式で別のデータベースにエクスポートすることもできます。属性の暗号化の目的は、格納またはエクスポートされる機密データを保護することです。したがって、この暗号化は常に可逆です。検索要求の結果として返された場合は、暗号化された属性は復号化されます。
次の図は、データベースに追加されるユーザーエントリを示しています。ここで設定されている属性暗号化は、salary 属性を暗号化します。
属性の暗号化機能は、広範な暗号化アルゴリズムをサポートしています。異なるプラットフォーム間での移植性が保証されています。属性の暗号化は追加のセキュリティー手段として、サーバーの SSL 証明書の非公開鍵を使って自身の鍵を生成します。その後、この鍵は、暗号化および復号化処理を実行するために使用されます。属性を暗号化できるためには、サーバーが SSL 上で稼働している必要があります。SSL 証明書とその非公開鍵はデータベース内に安全に格納され、パスワードで保護されます。この鍵データベースのパスワードはサーバーへの認証時に必要になります。サーバーは、この鍵データベースのパスワードにアクセスできるユーザーであれば、だれもが復号化されたデータのエクスポートを承認されたものとみなします。
属性の暗号化が保護するのは格納された属性だけである点に注意してください。これらの属性をレプリケートする場合には、転送中の属性を保護できるよう、SSL 上でレプリケーションを設定する必要があります。
属性の暗号化を使用する場合、バイナリコピー機能を使ってあるサーバーから別のサーバーを初期化することはできません。
属性の暗号化を使えばデータのセキュリティーを高められますが、この機能はパフォーマンスに影響を与えます。属性の暗号化は、機密性の特に高い属性を暗号化するためだけに使用してください。
機密データには、インデックスファイル経由で直接アクセスできます。したがって、暗号化する属性に対応するインデックスキーを暗号化することで、それらの属性が完全に保護されるようにする必要があります。インデックスキーを暗号化することによる追加コストがないとしても、インデックスを作成すること自体がすでにパフォーマンスに影響を及ぼします。したがって、データベースに初めてデータをインポートまたは追加する「前」に、属性の暗号化を設定してください。こうすることで、暗号化された属性には最初からインデックスが付けられます。
アクセス制御では、特定の情報へのアクセス権を一部のクライアントに与え、その他のクライアントには与えないように指定することができます。アクセス制御は、1 つまたは複数のアクセス制御リスト (ACL) を使用して実装します。ACL は、指定されたエントリとその属性へのアクセス権を許可または拒否する一連のアクセス制御命令 (ACI) から構成されます。アクセス権には、読み取り、書き込み、検索、プロキシ、追加、削除、比較、インポート、およびエクスポートを行う機能が含まれます。
ACL を使用すると、次の項目に対する権限を設定できます。
ディレクトリ全体
ディレクトリの特定のサブツリー
ディレクトリ内の特定のエントリ
特定のエントリの属性セット
特定の LDAP 検索フィルタにマッチするすべてのエントリ
また、特定のユーザー、グループに属するすべてのユーザー、およびディレクトリのすべてのユーザーに対する権限を設定できます。さらに、IP アドレスや DNS 名など、ネットワークの場所に対してアクセス権を定義することもできます。
この節では、Directory Server のアクセス制御メカニズムの概要を説明します。アクセス制御や ACI の設定方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の第 6 章「Directory Server のアクセス制御」を参照してください。アクセス制御メカニズムのアーキテクチャーについては、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「How Directory Server Provides Access Control」を参照してください。
Directory Server のデフォルト動作は、アクセスを許可する特定の ACI が存在していないかぎりアクセスを拒否する、というものです。したがって、ACI が 1 つも定義されていなければ、サーバーへのすべてのアクセスが拒否されます。
Directory Server をインストールしたり新しいサフィックスを追加したりすると、ルート DSE 内にいくつかのデフォルト ACI が自動的に定義されます。この ACI は、セキュリティー要件に合うように変更できます。
デフォルト ACI やそれらの変更方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「How Directory Server Provides Access Control」を参照してください。
Directory Server 6.x には、ACI の適用範囲に対する主な変更が 2 つ含まれています。
ACI の適用範囲を指定する機能:以前のバージョンの Directory Server では、ACI の適用範囲を指定できませんでした。ACI は自動的に、その ACI の格納先となるエントリとそのすべてのサブツリーに対して適用されていました。このため、場合によっては「拒否」ACI を使用する必要がありました。 拒否 ACI と許可 ACI が単一のエントリに適用される場合は特に、拒否 ACI の管理が困難になる可能性があります。
Directory Server 6.1 では ACI の適用範囲を指定できます。つまり、「許可」ACI を使ってアクセス制御を行えます。拒否ベースのアクセス制御の使用が避けられなかったり、そうしたアクセス制御を使用したほうが設定が容易になったりする場合もありますが、拒否 ACI の使用は基本的にはお勧めできません。ACI の適用範囲の指定方法については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の第 6 章「Directory Server のアクセス制御」を参照してください。
ルート ACI がルートエントリとそのサブツリー全体に適用されるようになった:以前のバージョンの Directory Server では、ルート DSE に格納された ACI はルートエントリのみに適用され、その子には適用されませんでした。ほかの任意のエントリ内の ACI は、その ACI の格納先エントリとそのすべてのサブツリーに対して適用されていました。Directory Server Enterprise Edition では、ルートエントリ内に配置された ACI が、ほかの任意の場所に配置された ACI と同様に扱われます。
新しいルート ACI には、明確なセキュリティー上の利点が 1 つあります。管理者は、特定の操作を実行する際に Directory Manager としてバインドする必要がなくなりました。SSL などの強い認証によるバインドを管理者に強制できるようになりました。ルートエントリ「だけに」適用することを目的とした ACI を設定するには、その ACI の適用範囲を具体的に base に設定する必要があります。
ACI の適用範囲の変更は移行に影響を与えます。以前のバージョンの Directory Server から Directory Server 6.x に移行する場合には、『Sun Java System Directory Server Enterprise Edition 6.1 Migration Guide』の「Changes to ACIs」を参照してください。
Directory Server 6.1 が提供するアクセス制御モデルでは、異なる多くのメカニズムを通じてユーザーにアクセスを許可できます。しかしながら、この柔軟性のために、セキュリティーポリシーがかなり複雑になる可能性があります。IP アドレス、マシン名、時刻、認証方法など、いくつかのパラメータを使用すれば、あるユーザーのセキュリティーコンテキストを定義できます。
セキュリティーポリシーを単純化するために、Directory Server 6.1 では、指定されたディレクトリエントリおよび属性に対する、ある特定のユーザーの実効アクセス権限を要求および一覧表示できるようになっています。詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「実行権限の表示」を参照してください。
次の各ヒントを参考にすれば、ディレクトリのセキュリティーモデルの単純化とパフォーマンスの改善を図れる可能性があります。
ディレクトリ内の ACI の数を最小化し、可能であればマクロ ACI を使用する。
Directory Server は 50,000 件を超える ACI を評価可能ですが、多数の ACI 文を管理するのは容易ではありません。また、過剰な ACI はメモリー消費にも悪影響を及ぼす可能性があります。
許可権限と拒否権限のバランスを図る。
デフォルトの規則は、アクセスを具体的に許可されていないすべてのユーザーのアクセスを拒否することです。ただし、ツリーのルートの近くでアクセスを許可する 1 つの ACI を使用し、リーフエントリの近くで少数の拒否 ACI を使用すれば、ACI の数を減らすことができます。このようにすると、最下位のエントリの近くでアクセスを許可する ACI が必要以上に多くなることがなくなります。
ACI では最小の属性セットを指定する。
オブジェクトの属性の一部でアクセスを許可または拒否する場合、許可または拒否する属性の最小リストを決めます。次に、最小の属性リストを管理するように ACI を表します。
たとえば、ユーザーオブジェクトクラスに多くの属性が含まれている場合を考えます。いくつかの属性だけをユーザーが更新できるようにするには、その少数について書き込み権限を許可する ACI を作成します。1 つか 2 つの属性以外のすべてをユーザーが更新できるようにする場合は、それらの 1 つか 2 つの属性について書き込み権限を拒否する ACI を作成します。
LDAP 検索フィルタは慎重に使用する。
検索フィルタは、アクセス管理対象のオブジェクトを直接指定しません。したがって、特にディレクトリが複雑になるにつれて、検索フィルタによって予期しない結果が得られる可能性があります。ACI 内で検索フィルタを使用する場合、その同じフィルタを使って ldapsearch 操作を実行してください。このアクションにより、その変更の結果がユーザーのディレクトリにとって何を意味するのかを確認できます。
ディレクトリツリーの別の部分で ACI を重複させない。
オーバーラップしている ACI を探します。グループ書き込みアクセス権を commonName および givenName 属性に対して許可する ACI が、ディレクトリのルート位置に存在するとします。さらに、それと同じグループ書き込みアクセス権を commonName 属性に対してだけ許可する別の ACI も存在するとします。この場合、そのグループに対して 1 つの属性のみの書き込みアクセス権を与えるように、ACI を修正することを検討してください。
ディレクトリが複雑になるほど、ACI のオーバーラップが間違って発生する確率も高くなります。ACI のオーバーラップを回避すれば、セキュリティーの管理が容易になり、ディレクトリ内の ACI の合計数も減少します。
ACI に名前を付ける。
ACI に名前を付けることは省略可能ですが、各 ACI に意味のある短い名前を付ければ、セキュリティーモデルの管理が容易になります。
ユーザーエントリの標準属性を使用して、アクセス権限を決める。
可能なかぎり、すでに標準ユーザーエントリの一部となっている情報を使用して、アクセス権限を決めてください。特別な属性を作成する必要がある場合は、それらの属性をロールまたはサービスクラス (CoS) の定義の一部として作成することを検討します。ロールと CoS の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 8 章「Directory Server Groups and Roles」および『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 9 章「Directory Server Class of Service」を参照してください。
ACI を互いにできるだけ近い位置にまとめる。
ACI の配置をディレクトリのルートポイントとディレクトリの主な分岐点に限定します。ACI を編成してグループにまとめると、ACI リストの全体を管理しやすくなり、ACI の合計数を最小に保つことができます。
二重否定は使用しないようにする (バインド DN が cn=Joe と等しくない場合の書き込みの拒否など)。
サーバーはこの構文を理解できますが、管理者にとっては混乱の元となります。
接続規則を使えば、選択されたクライアントが Directory Server への接続を確立するのを防ぐことができます。接続規則の目的は、悪意のあるクライアントや不適切に設計されたクライアントによって引き起こされるサービス拒否攻撃を防ぐことです。そうしたクライアントは Directory Server に接続し、そのサーバーを要求で溢れさせます。
接続規則は TCP レベルで確立されますが、それは「TCP ラッパー」を定義することで行われます。TCP ラッパーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「TCP ラップによるクライアントホストのアクセス制御」を参照してください。
Directory Proxy Server の接続ハンドラは、サーバーに接続を試みるクライアントの分類を可能にするアクセス制御の方法を提供します。この方法では、接続がどのように分類されたかに基づいて、実行可能な操作を制限できます。
この機能を使えば、ある指定された IP アドレスから接続するクライアントだけにアクセスを制限したりすることができます。次の図は、Directory Proxy Server の接続ハンドラを使って特定の IP アドレスからの書き込み操作を拒否する方法を示したものです。
接続ハンドラは、一連の条件と一連のポリシーから構成されます。Directory Proxy Server は、ある接続の起点属性をクラスの条件とマッチングさせることで、その接続のクラスメンバーシップを決定します。接続があるクラスに一致すると、Directory Proxy Server はそのクラスに格納されているポリシーをその接続に適用します。
接続ハンドラの条件には、次の情報を含めることができます。
クライアントの物理アドレス
ドメイン名またはホスト名
クライアント DN のパターン
認証方法
SSL
接続ハンドラには次のポリシーを関連付けることができます。
管理制限ポリシー:たとえば、ある特定クラスのクライアントからの接続数を制限できるようにします。
コンテンツ適応ポリシー:属性の名前変更など、接続が実行できる操作の種類を制限できるようにします。
データ分散ポリシー:ある接続で特定の配布方式を使用できるようにします。
Directory Proxy Server の接続ハンドラやその設定方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 20 章「Connections Between Clients and Directory Proxy Server」を参照してください。
ロールと CoS では、セキュリティーに関する特別な考慮が必要となります。
セキュリティーの状況によっては、ロールの使用が適していない場合があります。ロールを作成するときは、エントリへのロールの割り当てやエントリからのロールの削除がどの程度簡単にできるかを考慮します。ユーザーは場合によっては、自身をロールに追加したりロールから削除したりできるべきです。ただし、一部のセキュリティーコンテキストでは、そうしたオープンなロールは不適切です。詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Directory Server Roles」を参照してください。
読み取り用のアクセス制御は、エントリの実際の属性と仮想属性の両方に適用されます。サービスクラス (CoS) メカニズムによって生成される仮想属性は、通常の属性と同様に読み取られます。したがって、仮想属性には、同じ方法で読み取り保護を付与すべきです。ただし、CoS 値をセキュリティー保護するには、CoS 値が使用する次のすべての情報ソースを保護する必要があります。定義エントリ、テンプレートエントリ、およびターゲットエントリ。更新操作についても同じことが言えます。各情報ソースから生成される値を保護するには、それらのソースへの書き込みアクセスを制御する必要があります。詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 9 章「Directory Server Class of Service」を参照してください。
ファイアウォールテクノロジは通常、内部ネットワークを出入りするネットワークトラフィックをフィルタリングまたはブロックするために使用されます。LDAP 要求が境界ファイアウォールの外側から送られてくる場合には、ファイアウォールの通過を許可するポートとプロトコルを指定する必要があります。
指定するポートとプロトコルはディレクトリのアーキテクチャーによって異なります。一般的な規則として、ポート 389 および 636 上の TCP および UDP 接続を許可するように、ファイアウォールを設定する必要があります。
Directory Server が稼働しているサーバーに、ホストベースのファイアウォールをインストールできます。ホストベースのファイアウォールの規則は、境界防御ファイアウォールの規則に似ています。
サーバーインスタンスを root 以外のユーザーとして作成および実行できます。サーバーインスタンスを root 以外のユーザーとして実行することで、悪用によって生じる可能性のあるあらゆる損害を制限できます。さらに、root 以外のユーザーとして実行されるサーバーは、オペレーティングシステムのアクセス制限メカニズムの処理対象となります。
セキュリティー保護されたディレクトリの設計については、以下のリソースを参照してください。
Sun Developer セキュリティーリソース http://developers.sun.com/techtopics/security/index.html
『Understanding and Deploying LDAP Directory Services』。T. Howes, M. Smith, G. Good、Macmillan Technical Publishing 発行、1999 年
SecurityFocus.com http://www.securityfocus.com/
Computer Emergency Response Team (CERT) Coordination Center http://www.cert.org/
CERT セキュリティー改善モジュール http://www.cert.org/security-improvement/