| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド 11g リリース1 (11.1.1.7.0) B72436-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド 11g リリース1 (11.1.1.7.0) B72436-01 |
|
前 |
次 |
Directory Server Enterprise Editionでデータを保護する方法は、設計の他のすべての領域に影響します。この章では、セキュリティ要件の分析方法およびその要件を満たすディレクトリ・サービスの設計方法について説明します。
この章の内容は、次のとおりです。
ディレクトリのセキュリティに対する最も一般的な脅威には、次のものがあります。
傍受。情報は元の状態のままですが、そのプライバシが損なわれます。たとえば、他人に、クレジット・カード番号を知られたり、機密性の高い会話を記録されたり、機密情報を傍受される可能性があります。
未許可アクセス。この脅威には、データのフェッチ操作による、データへの未許可アクセスが関与します。また、未許可のユーザーが、他のユーザーのアクセスを監視することにより、再使用可能なクライアント認証情報にアクセスする可能性もあります。Directory Server Enterprise Editionの認証方式、パスワード・ポリシーおよびアクセス制御メカニズムを使用することで、効果的に未許可アクセスを防止できます。
改ざん。転送中の情報が変更または置換されて受信者に送信されます。たとえば、他人が商品の注文を変更したり、履歴書を変更する可能性があります。
この脅威には、データまたは構成情報の未許可の変更が関与します。ディレクトリで改ざんを検出できない場合、攻撃者がサーバーに対するクライアントのリクエストを変更する可能性があります。また、攻撃者がリクエストを取り消したり、クライアントに対するサーバーのレスポンスを変更する可能性もあります。Secure Socket Layer (SSL)プロトコルおよび類似のテクノロジを使用し、接続の両側で情報に署名することによって、この問題を解決できます。
偽装。目的の受信者を装ったユーザーに情報が渡されます。
偽装には、スプーフィングと虚偽表示の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とクライアント間のネットワークを経由してデータを送信します。クライアントでは、次のいずれかの方法でセキュア接続を確立できます。
Secure Socket Layer (SSL)を使用して保護ポートにバインドします。
保護されていないポートに匿名アクセスでバインドし、Start TLS制御を送信してトランスポート層セキュリティ(TLS)の使用を開始します。
いずれの場合も、サーバーにはセキュリティ証明書が必要であり、この証明書を信頼するようにクライアントを構成する必要があります。サーバーでは、証明書をクライアントに送信することで、公開鍵暗号化を使用してサーバー認証を実行します。その結果、目的のサーバーに接続していること、およびサーバーが改ざんされていないことが、クライアントによって認識されます。
次に、プライバシを保護するために、クライアントとサーバーでは、接続を介して転送されるすべてのデータを暗号化します。クライアントでは、ユーザーを認証するために、暗号化された接続でバインドDNとパスワードを送信します。それ以降のすべての操作は、そのユーザーのアイデンティティを使用して実行されます。また、バインドDNが他のユーザー・アイデンティティに対するプロキシ権限を持っている場合には、プロキシ・アイデンティティを使用して操作が実行される可能性もあります。いずれの場合も、操作の結果は暗号化されてクライアントに返されます。
SSLまたはTLS経由で暗号化接続を確立する場合、クライアント認証を要求するようにサーバーを構成することもできます。クライアントからは、ユーザーのアイデンティティを確認するために、サーバーに証明書を送信する必要があります。バインドDNの決定には、ユーザーのDNではなく、証明書が使用されます。クライアント認証は、ユーザーの偽装に対する保護で、最も安全なタイプの接続です。
証明書ベースのクライアント認証は、SSLおよびTLS層でのみ動作します。証明書ベースの認証IDをLDAPで使用するには、SSL接続の確立後にSASL EXTERNAL認証を使用する必要があります。
証明書ベースのクライアント認証を構成するには、dsconf get-server-propコマンドを使用します。詳細は、dsconfを参照してください。
SSLまたはTLS接続時のクライアント認証では、汎用セキュリティ・インタフェースのSimple Authentication and Security Layer (SASL)を使用してクライアントのアイデンティティを確立することもできます。Directory Server Enterprise Editionでは、SASLを使用して次のメカニズムをサポートします。
DIGEST-MD5。このメカニズムでは、クライアントから送信されたハッシュ値とユーザー・パスワードのハッシュを比較することによって、クライアントを認証します。ただし、このメカニズムではユーザー・パスワードを読み取る必要があるため、DIGEST-MD5による認証を希望するすべてのユーザーは、ディレクトリ内に{CLEAR}パスワードを持つ必要があります。
GSSAPI。General Security Services API (GSSAPI)は、Solarisオペレーティング・システムでのみ使用できます。これにより、Directory ServerではKerberos V5セキュリティ・システムと対話してユーザーを特定できます。クライアント・アプリケーションではKerberosシステムに資格証明を提示する必要があり、Kerberosシステムでは、ユーザーのアイデンティティを検証してDirectory Serverに返します。
EXTERNAL。このメカニズムでは、SSLやTLSなどの外部セキュリティ・レイヤーによって指定された資格証明に基づいて、LDAPのユーザーを認証します。
詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のクライアントでのSASL DIGEST-MD5の使用に関する説明および『Oracle Directory Server Enterprise Edition管理者ガイド』のクライアントでのKerberos SASL GSSAPIに関する説明を参照してください。
あるユーザー・アカウントまたは一連のアカウントを非アクティブにすることで、認証を一時的に防止できます。アカウントを非アクティブにされたユーザーは、Directory Serverにバインドできず、認証処理が失敗します。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のアカウントの手動ロックに関する説明を参照してください。
このバージョンのDirectory Serverでは、パスワードによる認証失敗が監視およびレプリケートされます。これにより、無効なパスワードによる認証の試行がある指定された回数だけ行われた後、速やかにグローバル・アカウント・ロックアウトできます。グローバル・アカウント・ロックアウトは、次のすべての場合にサポートされます。
クライアント・アプリケーションがトポロジ内の単一のサーバーにのみバインドする場合
読取り専用のコンシューマがトポロジ内に含まれていない場合
Directory Proxy Serverを使用してすべてのバインド・トラフィックが制御される場合
すべてのバインド試行が同一のサーバーに向けられず、ロックアウト・データがレプリケートされるよりも速く、クライアント・アプリケーションにより複数のサーバー上でバインド試行が実行されるような状況を想像してください。最悪の場合、クライアントによりバインドが試行されたサーバーごとに、指定された回数の試行をクライアントに許可することになります。人間のユーザーの入力によってクライアント・アプリケーションが駆動される場合、通常、このような状況は発生しません。ただし、トポロジを攻撃するために構築された自動化クライアントでは、このデプロイメントの選択を悪用できます。
優先順位付きレプリケーションを使用すると、侵入者が検出されたときに、非同期レプリケーションの遅れによる影響を最小化できます。ただし、バインド試行が指定された回数だけ失敗した直後にアカウント・ロックアウトを実行する必要がある場合もあります。このような状況では、ある特定のエントリ上でのすべてのバインド試行を、Directory Proxy Serverを使用して同一のマスター・レプリカにルーティングする必要があります。これを行うためのDirectory Proxy Serverの構成方法は、Oracle Directory Server Enterprise Editionリファレンスのグローバル・アカウント・ロックアウトの操作アフィニティ・アルゴリズムに関する説明を参照してください。
レプリケーション・トポロジ内で厳密にローカルなロックアウト・ポリシーを維持するには、5.2のパスワード・ポリシーとの互換性を維持する必要があります。その状況では、有効なポリシーをデフォルトのパスワード・ポリシーにすることはできません。また、読取り専用のコンシューマにバインドを制限することによっても、ローカル・ロックアウトを実現できます。
グローバル・アカウント・ロックアウトの動作方法の詳細は、Oracle Directory Server Enterprise Editionリファレンスのグローバル・アカウント・ロックアウトに関する説明を参照してください。
Directory Serverでは、ネットワーク・ユーザー・アカウントをDirectory Serverユーザー・アカウントに関連付けるユーザー・アカウント・ホスト・マッピングを使用できます。この機能によって、両方のユーザー・アカウントの管理が簡略化されます。ホスト・マッピングは、外部で認証されたユーザーの場合に必要です。
プロキシ認可は、特殊な形態のアクセス制御です。プロキシ認可またはプロキシ認証においては、アプリケーションが、特定のユーザー名/パスワードの組合せを使用してサーバーへのアクセスを取得することを強制されます。
プロキシ認可では、管理者は、ある一般ユーザーのアイデンティティを引き受けることでDirectory Serverへのアクセスを要求できます。管理者は、自分自身の資格証明を使用してディレクトリにバインドし、その一般ユーザーの権限を付与されます。この引き受けるアイデンティティをプロキシ・ユーザーと呼びます。そのユーザーのDNはプロキシDNと呼びます。プロキシ・ユーザーは一般ユーザーとして評価されます。プロキシ・ユーザーのエントリがロックまたは非アクティブ化されているか、そのパスワードの有効期限が切れている場合、アクセスが拒否されます。
プロキシ・メカニズムの利点は、Directory Serverにアクセスする複数のユーザーに対して、LDAPアプリケーションで単一のバインドを使用してサービスを提供できることにあります。各ユーザーがバインドおよび認証する必要があるのではなく、クライアント・アプリケーションでDirectory Serverにバインドし、プロキシの権限を使用します。
詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第6章「Directory Serverのアクセス制御」を参照してください。
パスワード・ポリシーは、システム内でのパスワードの管理方法を制御するルールのセットです。Directory Serverでは、デフォルトのパスワード・ポリシー以外に、複数のパスワード・ポリシーがサポートされています。
パスワード・ポリシーのいくつかの要素は構成可能であるため、組織のセキュリティ要件に合ったポリシーを設計できます。パスワード・ポリシーの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第7章「Directory Serverのパスワード・ポリシー」を参照してください。パスワード・ポリシーの構成に使用可能な個々の属性は、pwpolicyのマニュアル・ページを参照してください。
この項は次のトピックに分割されています。
パスワード・ポリシーのオプション
レプリケーション環境でのパスワード・ポリシー
パスワード・ポリシーの移行
次のパスワード・ポリシーのオプションがあります。
デフォルトのパスワード・ポリシーが適用されます。このデフォルト・ポリシーのパラメータは変更可能です。
別の特殊なパスワード・ポリシーを特定のユーザーに適用できます。
CoSおよびロール機能を使用することで、別の特殊なパスワード・ポリシーを一連のユーザーに適用できます。パスワード・ポリシーは、静的なグループには適用できません。
デフォルト・パスワード・ポリシーの構成情報はレプリケートされません。かわりに、サーバー・インスタンスの構成の一部となります。デフォルト・パスワード・ポリシーを変更する場合は、トポロジ内のすべてのサーバーに同じ変更を加える必要があります。レプリケートされるパスワード・ポリシーが必要な場合は、レプリケートされるディレクトリ・ツリー内に、特殊なパスワード・ポリシーを定義する必要があります。
ユーザー・エントリに格納されているパスワード情報のすべてがレプリケートされます。この情報には、現在のパスワード、パスワード履歴、パスワードの有効期限などが含まれます。
レプリケーション環境では、パスワード・ポリシーによる次の影響を考慮してください。
パスワードの期限切れが近づいたユーザーは、パスワードを変更するまで、バインドするすべてのレプリカから警告を受信します。
ユーザーがパスワードを変更した場合、その新しいパスワードがすべてのレプリカ上で更新されるまでに、しばらく時間がかかる可能性があります。ユーザーが、パスワードを変更した直後に、新しいパスワードを使用してコンシューマ・レプリカの1つにバインドしなおす状況になることがあります。この場合、そのレプリカが更新済のパスワードを受信するまで、バインドが失敗する可能性があります。この状況を緩和するには、優先順位付きレプリケーションを使用してパスワード変更が最初にレプリケートされるように強制します。
Directory Server Enterprise Editionのパスワード・ポリシーの構成設定は、5.2バージョンのDirectory Serverで提供されていたパスワード・ポリシーの構成設定とは異なります。異なるバージョンのDirectory Serverが稼働するサーバーがトポロジ内に含まれている場合は、パスワード・ポリシーの設定の移行方法の詳細について、『Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド』のパスワード・ポリシーに関する説明を参照してください。
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の使用方法の詳細は、Identity Synchronization for Windowsのデプロイメント・プランニング・ガイドを参照してください。
暗号化は、転送中のデータや格納されたデータを保護する場合に役立ちます。この項では、次のデータ暗号化方式について説明します。
セキュリティ設計には、ユーザーを特定するための認証スキームや、情報を保護するためのアクセス制御スキーム以外の要素も含まれます。サーバーとクライアント・アプリケーションとの間でネットワーク経由で送信される情報の整合性も保護する必要があります。
ネットワーク上で安全な通信を可能にするために、Secure Sockets Layer (SSL)上でLDAPプロトコルとDSMLプロトコルの両方を使用できます。SSLが構成されてアクティブ化されると、クライアントでは、SSL接続の確立後にすべての通信が暗号化される、専用の保護ポートに接続します。Directory ServerとDirectory Proxy Serverでは、Start Transport Layer Security (Start TLS)制御もサポートされています。クライアントではStart TLSを使用して、標準のLDAPポート経由での暗号化接続を開始できます。
Directory ServerのSSLおよびTLSの概要は、Oracle Directory Server Enterprise Editionリファレンスの第5章「Directory Serverのセキュリティ」を参照してください。
属性の暗号化は、格納されたデータの保護に関係します。この項では、属性の暗号化機能について説明し、次のトピックを取り上げます。
Directory Server Enterprise Editionには、パスワード認証、証明書ベースの認証、SSLおよびプロキシ承認など、アクセス・レベルでデータを保護する様々な機能が備えられています。ただし、データベース・ファイル、バックアップ・ファイルおよびLDIFファイルに格納されたデータも保護する必要があります。属性の暗号化機能を使用することで、格納されている機密データにユーザーがアクセスできないよう防止できます。
属性の暗号化を使用すると、特定の属性を暗号化された形式で格納できます。属性の暗号化はデータベース・レベルで構成されます。したがって、ある属性を暗号化すると、その属性がデータベース内のすべてのエントリで暗号化されます。属性の暗号化は、エントリ・レベルではなく属性レベルで行われるため、エントリ全体を暗号化する唯一の方法は、すべての属性を暗号化することです。
属性の暗号化を使用すると、データを暗号化された形式で別のデータベースにエクスポートすることもできます。属性の暗号化の目的は、機密データが格納またはエクスポートされる場合にのみ、それらのデータを保護することです。したがって、この暗号化は常に可逆です。検索リクエストの結果として返されるときには、暗号化された属性が復号化されます。
次の図は、データベースに追加されるユーザー・エントリを示しており、ここに示す属性の暗号化は、salary属性を暗号化するように構成されています。
属性の暗号化機能では、広範な暗号化アルゴリズムがサポートされています。異なるプラットフォーム間での移植性が保証されています。属性の暗号化では、追加のセキュリティ手段として、サーバーのSSL証明書の非公開鍵を使用して、それ自体の鍵を生成します。その後、この鍵は、暗号化および復号化処理を実行するために使用されます。属性を暗号化できるためには、サーバーがSSL上で稼働している必要があります。SSL証明書とその非公開鍵はデータベース内に安全に格納され、パスワードで保護されます。この鍵データベースのパスワードはサーバーへの認証時に必要です。サーバーでは、この鍵データベースのパスワードにアクセスできるすべてのユーザーが、復号化されたデータのエクスポートを承認されているとみなします。
属性の暗号化によって保護されるのは、保存された属性のみであることに注意してください。これらの属性をレプリケートする場合には、転送中の属性を保護するように、SSL上でレプリケーションを構成する必要があります。
属性の暗号化を使用する場合、バイナリ・コピー機能を使用してあるサーバーから別のサーバーを初期化することはできません。
属性を暗号化することでデータのセキュリティが向上しますが、この機能はパフォーマンスにも影響を及ぼします。属性の暗号化は、機密性の特に高い属性を暗号化するためにのみ使用してください。
機密データには、索引ファイル経由で直接アクセスできます。したがって、暗号化する属性に対応する索引キーを暗号化することで、それらの属性が完全に保護されるようにする必要があります。索引キーを暗号化することによる追加コストはありませんが、索引を作成することがすでにパフォーマンスに影響を及ぼしています。したがって、データベースに初めてデータをインポートまたは追加する前に、属性の暗号化を構成してください。こうすることで、暗号化された属性には最初から索引が付けられます。
アクセス制御では、特定の情報へのアクセス権を一部のクライアントに付与し、その他のクライアントには付与しないように指定できます。アクセス制御は、1つ以上のアクセス制御リスト(ACL)を使用して実装します。ACLは、指定されたエントリとその属性に対する権限を許可または拒否する一連のアクセス制御命令(ACI)で構成されます。権限には、読取り、書込み、検索、プロキシ、追加、削除、比較、インポートおよびエクスポートを行う権限が含まれます。
ACLを使用すると、次の項目に対する権限を設定できます。
ディレクトリ全体
ディレクトリの特定のサブツリー
ディレクトリ内の特定のエントリ
エントリの属性の特定のセット
特定のLDAP検索フィルタに一致するすべてのエントリ
また、特定のユーザー、グループに属するすべてのユーザーまたはディレクトリのすべてのユーザーに対する権限を設定できます。さらに、IPアドレスやDNS名など、ネットワークの場所に対してアクセス権を定義することもできます。
この項では、Directory Serverのアクセス制御メカニズムの概要を示します。アクセス制御およびACIの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第6章「Directory Serverのアクセス制御」を参照してください。アクセス制御メカニズムのアーキテクチャの詳細は、Oracle Directory Server Enterprise EditionリファレンスのDirectory Serverによるアクセス制御の実施方法に関する説明を参照してください。
デフォルトの動作では、Directory Serverは、アクセスを許可する特定のACIがないかぎりアクセスを拒否します。したがって、ACIが定義されていない場合、サーバーへのすべてのアクセスが拒否されます。
Directory Serverをインストールしたり新しい接尾辞を追加すると、ルートDSE内にいくつかのデフォルトACIが自動的に定義されます。これらのACIは、セキュリティ要件に合うように変更できます。
デフォルトACIおよびそれらの変更方法の詳細は、Oracle Directory Server Enterprise EditionリファレンスのDirectory Serverによるアクセス制御の実施方法に関する説明を参照してください。
Directory Server 6.x以上には、ACIの対象範囲に対する主な変更が2つ含まれています。
ACIの対象範囲を指定する機能。Directory Server 5.2では、ACIの対象範囲を指定できませんでした。ACIは自動的に、そのACIの格納先となるエントリとそのすべてのサブツリーに対して適用されていました。このため、場合によっては拒否ACIを使用する必要がありました。拒否ACIと許可ACIが単一のエントリに適用される場合は、特に、拒否ACIの管理が困難になる可能性があります。
Directory Server 6.x以上では、ACIの対象範囲を指定できます。つまり、許可ACIを使用してアクセスを制御できます。拒否ベースのアクセス制御の使用が避けられない場合や、そのようなアクセス制御を使用した方が構成が容易になる場合もありますが、拒否ACIを使用することは、基本的にはお薦めしません。ACIの対象範囲を指定する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第6章「Directory Serverのアクセス制御」を参照してください。
ルートACIがルート・エントリおよびそのサブツリー全体に適用されるようになりました。Directory Server 5.2では、ルートDSEに格納されたACIはルート・エントリにのみ適用され、その子には適用されませんでした。その他のエントリ内に配置されたACIは、そのACIの格納先となるエントリとそのすべてのサブツリーに対して適用されていました。Directory Server Enterprise Editionでは、ルート・エントリ内に配置されたACIが、他の任意の場所に配置されたACIと同様に扱われます。
新しいルートACIには、明白なセキュリティ上の利点が1つあります。管理者は、特定の操作を実行するときにディレクトリ・マネージャとしてバインドする必要がなくなりました。SSLなどの強力な認証によるバインドを管理者に強制できるようになりました。今後、ルート・エントリにのみ適用することを目的としたACIを構成するには、そのACIの対象範囲を具体的にbaseに設定する必要があります。
ACIの対象範囲の変更は移行に影響を与えます。5.2バージョンのDirectory ServerからDirectory Server 7.0に移行する場合は、『Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド』のACIに対する変更に関する説明を参照してください。
Directory Serverで提供されるアクセス制御モデルでは、異なる多くのメカニズムを通じてユーザーにアクセス権を付与できます。ただし、この柔軟性によって、セキュリティ・ポリシーが非常に複雑になる可能性があります。IPアドレス、マシン名、時刻および認証方式など、いくつかのパラメータによって、あるユーザーのセキュリティ・コンテキストを定義できます。
セキュリティ・ポリシーを単純化するために、Directory Serverでは、指定されたディレクトリ・エントリおよび属性に対する、ある特定のユーザーの実効アクセス権を要求および一覧表示できます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の実効権限の表示に関する説明を参照してください。
ディレクトリのセキュリティ・モデルを単純化し、ディレクトリのパフォーマンスを改善するためのヒントを次に示します。
ディレクトリ内の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の詳細は、Oracle Directory Server Enterprise Editionリファレンスの第11章「Directory Serverのグループおよびロール」およびOracle Directory Server Enterprise Editionリファレンスの第12章「Directory Serverのサービス・クラス」を参照してください。
ACIできるだけ近い位置にまとめます。
ACIの配置をディレクトリのルート・ポイントとディレクトリの主なブランチ・ポイントに限定します。ACIを編成してグループにまとめると、ACIリストの全体を簡単に管理できるようになり、ACIの合計数を最小に保つことができます。
二重否定の使用を避けます(バインドDNがcn=Joeと等しくない場合の書込みの拒否など)。
この構文はサーバーでは許容されますが、管理者にとっては混乱の元となります。
接続ルールを使用すると、選択されたクライアントでDirectory Serverへの接続が確立されないようにできます。接続ルールの目的は、Directory Serverに接続してサーバーをリクエストであふれさせる、悪意のあるクライアントや適切に設計されていないクライアントによって引き起こされるサービス拒否攻撃を防止することです。
接続ルールは、TCPラッパーを定義することによって、TCPレベルで確立されます。TCPラッパーの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のTCPラップによるクライアント・ホスト・アクセス制御に関する説明を参照してください。
Directory Proxy Serverの接続ハンドラでは、クライアントからの着信接続の分類を可能にするアクセス制御の方法を提供します。この方法では、接続がどのように分類されたかに基づいて、実行可能な操作を制限できます。
この機能を使用すると、たとえば、ある指定されたIPアドレスから接続するクライアントのみにアクセスを制限できます。次の図は、Directory Proxy Serverの接続ハンドラを使用して特定のIPアドレスからの書込み操作を拒否する方法を示したものです。
接続ハンドラは、一連の基準および一連のポリシーで構成されます。Directory Proxy Serverでは、接続の起点属性をクラスの基準と照合することにより、その接続のクラス・メンバーシップを決定します。接続があるクラスに一致すると、Directory Proxy Serverではそのクラスに格納されているポリシーをその接続に適用します。
接続ハンドラの基準には、次のものを含めることができます。
クライアントの物理アドレス
ドメイン名またはホスト名
クライアントDNのパターン
認証方式
SSL
接続ハンドラには次のポリシーを関連付けることができます。
管理制限ポリシー。特定の制限(たとえば、ある特定クラスのクライアントからのオープン接続数)を設定できます。
コンテンツ適応ポリシー。属性の名前変更など、接続で実行できる操作の種類を制限できます。
データ分散ポリシー。接続で特定の配布スキームを使用できるようにします。
Directory Proxy Serverの接続ハンドラおよびその設定方法の詳細は、Oracle Directory Server Enterprise Editionリファレンスの第20章「クライアントとDirectory Proxy Server間の接続」を参照してください。
ロールおよびCoSでは、セキュリティに関する特別な考慮が必要となります。
ロールの中には、セキュリティ・コンテキスト内での使用に適していないものがあります。ロールを作成するときは、エントリへのロールの割当てやエントリからのロールの削除がどの程度簡単に実行できるかを考慮します。ユーザーは、場合によっては、自分自身をロールに追加したりロールから削除できる必要があります。ただし、一部のセキュリティ・コンテキストには、そのようなオープンなロールは適しません。詳細は、Oracle Directory Server Enterprise EditionリファレンスのDirectory Serverのロールに関する説明を参照してください。
読取り用のアクセス制御は、エントリの実際の属性と仮想属性の両方に適用されます。サービス・クラス(CoS)メカニズムによって生成される仮想属性は、通常の属性と同様に読み取られます。したがって、仮想属性には、同じ方法で読取り保護を付与する必要があります。ただし、CoS値をセキュリティ保護するには、CoS値で使用されるすべての情報ソース(定義エントリ、テンプレート・エントリおよびターゲット・エントリ)を保護する必要があります。更新操作についても同じです。各情報ソースから生成される値を保護するには、それらのソースへの書込みアクセス権を制御する必要があります。詳細は、Oracle Directory Server Enterprise Editionリファレンスの第12章「Directory Serverのサービス・クラス」を参照してください。
ファイアウォール・テクノロジは、通常、内部ネットワークを出入りするネットワーク・トラフィックをフィルタリングまたはブロックするために使用されます。LDAPリクエストが境界ファイアウォールの外側から送信される場合には、ファイアウォールの通過を許可するポートとプロトコルを指定する必要があります。
指定するポートとプロトコルはディレクトリのアーキテクチャによって異なります。一般的に、ポート389および636上のTCPおよびUDP接続を許可するように、ファイアウォールを構成する必要があります。
Directory Serverが稼働しているのと同じサーバーに、ホストベースのファイアウォールをインストールできます。ホストベースのファイアウォールのルールは、境界防御ファイアウォールのルールと類似しています。
サーバー・インスタンスをroot以外のユーザーとして作成および実行できます。サーバー・インスタンスをroot以外のユーザーとして実行することで、悪用によって発生する可能性のあるすべての損害を制限できます。さらに、root以外のユーザーとして実行されるサーバーは、オペレーティング・システムのアクセス制御メカニズムの処理対象となります。
セキュリティ保護されたディレクトリの設計の詳細は、次のリソースを参照してください。
Sun Developer Security Resources (http://developers.sun.com/techtopics/security/index.html) (http://java.sun.com/javase/technologies/security/)
『Understanding and Deploying LDAP Directory Services』T.Howes、M. Smith、G. Good、Macmillan Technical Publishing、1999
SecurityFocus.com (http://www.securityfocus.com/) (http://www.securityfocus.com/)
Computer Emergency Response Team (CERT) Coordination Center (http://www.cert.org/) (http://www.cert.org/)
