前へ
目次
索引
DocHome
次へ
|
| iPlanet Directory Server 5.1 導入ガイド |
第 7 章 安全なディレクトリの設計
Directory Server のデータを保護する方法は、これまで説明してきたすべての設計領域に影響します。セキュリティの設計は、ディレクトリに格納されているデータを保護し、ユーザとアプリケーションのセキュリティおよび機密性の要件を満たすものでなければなりません。
この章では、セキュリティ要件の分析方法と、その要件を満たすディレクトリの設計方法について説明します。この章は、次の節で構成されています。
セキュリティに対する脅威について
セキュリティに対する脅威について
ディレクトリのセキュリティに対する脅威となるものは数多く存在します。一般的な脅威についての理解を深めておくと、全体的なセキュリティ設計を行うときに役立ちます。ディレクトリのセキュリティに対する代表的な脅威は、次のカテゴリに分類できます。
不正なアクセス 次に、ディレクトリのセキュリティポリシーを設計するときに役立つように、一般的なセキュリティの脅威について説明します。
不正なアクセス
不正なアクセスからディレクトリを保護することは簡単なようにみえますが、実際にはこの問題はかなり複雑です。ディレクトリ情報の配信経路には、権限のないクライアントがデータにアクセスできる箇所がいくつもあります。
たとえば、権限のないクライアントが別のクライアントの資格を利用してデータにアクセスする場合があります。保護されていないパスワードをディレクトリで使用している場合は、この種の不正アクセスが行われることがよくあります。権限のないクライアントが、正当なクライアントと Directory Server の間でやり取りされる通信情報を傍受する場合も考えられます。
権限のないアクセスは社内から発生することも、また、会社がエクストラネットやインターネットに接続している場合は、外部から発生することもあります。
ここに挙げた例は、権限のないクライアントからディレクトリデータにアクセスする例の一部にすぎません。
iPlanet Directory Server に備わっている認証方法、パスワードポリシー、およびアクセス制御のメカニズムは、不正アクセスの防止に効果があります。これらの問題に関しては、「適切な認証方式の選択」、「パスワードポリシーの設計」、および「アクセス制御の設計」を参照してください。
不正な改ざん
侵入者がディレクトリへアクセスしたり、Directory Server とクライアントアプリケーションの間の通信を傍受した場合は、ディレクトリデータが変更 (あるいは改ざん) される潜在的な危険があります。クライアントがデータを信頼できなかったり、ディレクトリ自体がクライアントから受信する変更や照会を信頼できない場合、ディレクトリは役に立たなくなります。
たとえば、ディレクトリが改ざんを検出できない場合、侵入者はクライアントからサーバへの要求を変更 (または遮断) したり、サーバからクライアントへの応答を変更したりすることが可能になります。SSL や類似の技術では、接続のどちらかで情報に署名することで、この問題を解決しています。iPlanet Directory Server での SSL の使い方については、「SSL による接続のセキュリティ保護」を参照してください。
サービス拒否 (DoS)
サービス拒否攻撃とは、侵入者がディレクトリによるクライアントへのサービスの提供を妨害することです。たとえば、侵入者はひたすらシステムの資源を消費して、ほかのユーザが資源を使用するのを妨害します。
iPlanet Directory Server では、特定のバインド DN に割り当てる資源に制限を設定することで、サービスの拒否攻撃を防ぎます。ユーザのバインド DN に基づく資源制限の設定方法については、『iPlanet Directory Server 管理者ガイド』の「ユーザアカウントの管理」を参照してください。
セキュリティ要件の分析
自社のセキュリティ要件を特定するには、環境とユーザを分析する必要があります。第 3 章の「ディレクトリデータの設計」でサイト調査を実施した際に、ディレクトリ内の各データについてどのユーザが読み取りまたは書き込みができるかの基本的な決定は終わっているはずです。この情報が、ここではセキュリティの設計の基盤となります。
また、セキュリティの実装方法は、ディレクトリをどのように使用して業務をサポートするかによって異なります。イントラネットを供給するディレクトリでは、エクストラネットをサポートするディレクトリやインターネットに解放されている e コマースアプリケーションと同等のセキュリティレベルが要求されることはありません。
ディレクトリがイントラネットだけにサービスを提供する場合は、次の事項を考慮する必要があります。
ディレクトリがエクストラネットにサービスを提供したり、インターネットを介して e コマースアプリケーションをサポートしたりする場合は、上記の点に加えて、次の事項を考慮する必要があります。
次に、セキュリティ要件の分析について、以下の項目ごとに説明します。
「アクセス権限の決定」
アクセス権限の決定
データ解析を実行するときは、ユーザ、グループ、取引先、顧客、およびアプリケーションがアクセスする必要のあるデータを特定します。
次の 2 とおりの方法でアクセス権限 (access rights) を与えます。
機密データを保護しながら、すべてのカテゴリのユーザに最大限のアクセスを与える
この開かれた方法を選ぶ場合は、どのデータが業務上の機密事項あるいは重要事項に該当するのかを十分検討する必要があります。
各カテゴリのユーザに業務に必要な最小限のアクセスだけを与える
この方法は制限が多いので、この方法を選ぶ場合は、各カテゴリの内部ユーザが必要とする情報、また場合によっては外部のユーザが必要とする情報について、ある程度の時間をかけて検討する必要があります。
どちらの方法でアクセス権限を与える場合でも、組織のユーザが属するカテゴリとそのカテゴリに与えるアクセス権限を一覧にした、簡単な表を作成してください。また、ディレクトリに保持する機密データ、および各データを保護するために使用した手法を一覧にした表も必要に応じて作成してください。
ユーザの識別方法については、「適切な認証方式の選択」を参照してください。ディレクトリ情報へのアクセスを制限する方法については、「アクセス制御の設計」を参照してください。
データの機密性と完全性の保証
エクストラネットを介して取引先との情報交換を行う場合、あるいはインターネット上で顧客が使用する e コマースアプリケーションをサポートするためにディレクトリを使用する場合は、交換するデータの機密性と完全性を保証する必要があります。
iPlanet Directory Server で使用可能な暗号化方法については、「パスワード保存スキーマ」を参照してください。データの署名については、「SSL による接続のセキュリティ保護」を参照してください。
定期的な監査の実行
さらにセキュリティを高めるために、セキュリティポリシー全体の効率を検証する定期的な監査を実行する必要があります。定期的な監査では、ログファイルと SNMP エージェントによって記録された情報を検査します。
SNMP については、『iPlanet Directory Server 管理者ガイド』を参照してください。
セキュリティ要件の分析例
ここでは、架空の ISP である siroe.com 社が自社のセキュリティ要件をどのように解析したかを例に示しながら説明します。
siroe.com 社の業務は、Web ホスティングとインターネットへのアクセスを提供することです。siroe.com 社では業務の一部として、クライアント企業のディレクトリをホストしています。また、多数の個人加入者にインターネットへのアクセスを提供しています。
このため、siroe.com 社はディレクトリ内に次の 3 つの主要な情報カテゴリを持ちます。
siroe.com 社は、次のようなアクセス制御を必要とします。
Company22 と Company33 のディレクトリ管理者に自社のディレクトリ情報へのアクセスを許可する
Company22 と Company33 自身のアクセス制御ポリシーをそれらのディレクトリの情報について実装する
siroe.com 社のサーバを使用して自宅からインターネットにアクセスするすべての個人クライアントについて、標準のアクセス制御ポリシーを実装する
セキュリティ手法の概要
iPlanet Directory Server では、個々の要件に合ったセキュリティポリシーを設計するためのさまざまな手法が用意されています。セキュリティポリシーは、権限のないユーザが機密情報を変更したり取り出したりできないような強固なものであると同時に、簡単に情報の管理ができるものでなければなりません。複雑なセキュリティポリシーを作成すると、許可したユーザが情報にアクセスできなかったり、あるいはアクセスを許可していないユーザがディレクトリ情報を変更したり取り出したりする問題につながります。
iPlanet Directory Server では、次のセキュリティ手法を使用できます。
認証
一方が他方の識別情報を検証する方法です。たとえば、LDAP のバインド操作時に、クライアントは Directory Server にパスワードを与えます。
パスワードポリシー
たとえば、有効期限、長さ、構文など、パスワードの有効性を証明するための条件を定義します。
暗号化
情報の機密性を保護します。データを暗号化すると、データは受信者だけが理解できるような方法で符号化されます。
アクセス制御
さまざまなディレクトリユーザに与えるアクセス権限を調整し、必要な資格またはバインド属性を指定する方法を提供します。
アカウントの無効化
ユーザアカウント、アカウントのグループ、またはドメイン全体を無効にし、すべての認証試行を自動的に拒否します。
SSL による署名
情報の完全性を保持します。情報が署名されている場合、受信者は情報が転送中に変更されていないことを確認できます。
監査
ディレクトリのセキュリティが危険にさらされていないかを確認できます。たとえば、ディレクトリで保持されるログファイルを監査できます。
セキュリティを管理するこれらのツールは、セキュリティの設計と組み合わせて使用できます。セキュリティの設計をサポートするために、複製やデータの分散など、ほかのディレクトリの機能使用できます。
適切な認証方式の選択
セキュリティポリシーに関して決定が必要な項目に、ユーザのディレクトリへのアクセス方法があります。匿名アクセスを許可するかどうか、またはディレクトリを使用するすべてのユーザにディレクトリへのバインドを要求するかどうかを決定します。
iPlanet Directory Server では、次のような認証 (authentication) 方法を使用できます。
匿名アクセス ディレクトリでは、相手がユーザか LDAP 対応アプリケーションかにかかわらず、すべてのユーザに対して同じ認証メカニズムを使用します。
クライアント単位またはクライアントのグループ単位での認証の防止方法については、「アカウントの無効化による認証の防止」を参照してください。
匿名アクセス
匿名アクセスは、ディレクトリにアクセスするもっとも簡単な形式です。匿名アクセスを使用すると、認証とは関係なくだれでもディレクトリデータを利用できます。
しかし、匿名アクセス (anonymous access) では、だれがどのような検索を実行しているのかを追跡することはできず、検索を実行しているユーザがいるということしかわかりません。匿名アクセスを許可すると、ディレクトリに接続するユーザはだれでもデータにアクセスできます。
したがって、特定のユーザまたはユーザのグループによるディレクトリデータへの読み取りを禁止しようとしても、そのデータへの匿名アクセスを許可していれば、ユーザは匿名でディレクトリにバインドすることでデータへのアクセスが可能になります。
匿名アクセスの特権は制限できます。通常、ディレクトリ管理者は、匿名アクセスに対して読み取り、検索、および比較の特権だけを許可します (書き込み、追加、削除、本人による書き込みは許可しません)。また、アクセスは、ユーザ名、電話番号、電子メールアドレスなど、一般的な情報を含む属性のサブセットに限定されるのが普通です。匿名アクセスは、政府指定の ID (米国の社会保障番号など)、自宅の電話番号と住所、給与情報など機密データには絶対に許可しないでください。
ユーザパスワード属性が含まれていないエントリでユーザがバインドを試行した場合、Directory Server は次のどちらかを実行します。
たとえば、次の ldapsearch コマンドを考えてみます。
% ldapsearch -D "cn=joe" -w secretpwd -b "siroe.com" cn=joe
この場合、ディレクトリによって読み取りについての匿名アクセスが許可されますが、ldapsearch コマンドで与えたパスワードとマッチするパスワードが自分のエントリに含まれていないため、Joe は自分のエントリにアクセスできません。
簡易パスワード
匿名アクセスを設定しない場合、ディレクトリの内容にアクセスするにはディレクトリへの認証を行う必要があります。簡易パスワード認証では、クライアントは再使用可能な簡単なパスワードを送信して、サーバへの認証を行います。
たとえば、識別名と資格のセットを送信するバインド操作によって、クライアントはディレクトリへの認証を行います。サーバはクライアント DN に対応したディレクトリ内のエントリを検出し、クライアントから送信されたパスワードとエントリ内に格納されている値がマッチするかどうかを確認します。マッチした場合、サーバはクライアントを認証します。マッチしない場合、認証操作は失敗し、クライアントにエラーメッセージが返されます。
多くの場合、バインド DN (bind DN) はユーザのエントリに対応しています。ただし、ユーザのエントリとしてではなく組織のエントリとしてバインドする方が便利だと考えるディレクトリ管理者もいます。バインドに使用するエントリは、userPassword 属性を使用できるオブジェクトクラスのエントリである必要があります。これにより、ディレクトリがバインド DN とパスワードを認識することができます。
ユーザが DN の長い文字列を記憶できない場合もあるため、多くの LDAP クライアントはバインド DN をユーザに表示しません。クライアントがバインド DN をユーザに表示しない場合、クライアントは次のようなバインドアルゴリズムを使用します。
ユーザはユーザ ID などの一意の識別子を入力する (たとえば、fchen)
LDAP クライアントアプリケーションはこの識別子でディレクトリを検索し、関連付けられている識別名を返す (uid=fchen,ou=people,dc=siroe,dc=com など)
LDAP クライアントアプリケーションは、検出した識別名とユーザが入力したパスワードを使用してディレクトリにバインドする
注
簡易パスワード認証の欠点は、パスワードがクリアテキストでネットワークに送信されることです。悪意を持ったユーザが盗聴している場合、認証されたユーザになりすます可能性があり、ディレクトリのセキュリティを危険にさらすことになります。
簡易パスワード認証ではユーザを簡単に認証できますが、組織のイントラネットだけに使用を限定した方がよいでしょう。この認証では、エクストラネットを介した取引先との転送やインターネット上での顧客との転送に求められるレベルのセキュリティは提供されません。
証明書に基づく認証
ディレクトリ認証のもう 1 つの方式として、ディレクトリへのバインドにセキュリティ証明書を使用する方法があります。ユーザがディレクトリに初めてアクセスすると、ディレクトリはユーザにパスワードを要求します。ただし、このパスワードは、ディレクトリに格納されているパスワードとマッチするものではなく、そのユーザの証明書 (certificate) データベースを開くためのパスワードです。
ユーザが入力したパスワードが正しい場合は、ディレクトリクライアントアプリケーションは証明書データベースから認証情報を取得します。次に、クライアントアプリケーションとディレクトリは、この情報を使用し、ユーザの証明書をディレクトリの DN に割り当てることでユーザを識別します。この識別過程で検出されたディレクトリ DN に基づいて、ディレクトリへのアクセスが許可または拒否されます。
証明書および SSL については、『Managing Servers with iPlanet Console』を参照してください。
TLS を介した簡易パスワード
SSL または「Start TLS」操作を使用して Directory Server とクライアントアプリケーションの間に安全な接続が確立された場合、サーバはパスワードを要求して特別なレベルの認証を要求することができます。この場合、パスワードがクリアテキストでネットワークに送信されることはありません。
SSL については、「SSL による接続のセキュリティ保護」を参照してください。「Start TLS」操作については、『iPlanet Directory Server 管理者ガイド』を参照してください。
プロキシ認証
プロキシ認証 (proxy authorization) 方式は特殊な形式の認証で、 ユーザは自分の ID を使用してディレクトリにバインドしますが、プロキシ認証によって別のユーザの権限が与えられます。
たとえば、プロキシ認証を使用すると、ディレクトリ管理者は一般ユーザとしてディレクトリへのアクセスを要求できます。ディレクトリ管理者は自分の資格を使用してディレクトリにバインドしますが、アクセス制御の評価のために、一般ユーザの権限が与えられます。このような仮のユーザはプロキシユーザと呼ばれ、そのユーザの DN は プロキシ DN と呼ばれます。
プロキシ要求を実行できるディレクトリを構成するには、次の手順を実行します。
管理者には、ほかのユーザとしてのプロキシ権限を与える
一般ユーザには、アクセス制御ポリシーで定義されている通常のアクセス権を与える
注
ディレクトリマネージャ以外のディレクトリのすべてのユーザにプロキシ権限を与えることができます。プロキシ権限により、すべての DN (ディレクトリマネージャ DN を除く) をプロキシ DN として指定する権限が与えられるので、プロキシ権限を与える場合には十分な注意が必要です。
プロキシのメカニズムは非常に強力です。プロキシの主な利点の 1 つとして、Directory Server に要求を送信している複数のユーザにサービスを提供するために、LDAP アプリケーションが 1 つのバインドで 1 つのスレッドを使用できるようにする点が挙げられます。ユーザごとにバインドして認証する代わりに、クライアントアプリケーションはプロキシ DN を使用して Directory Server にバインドします。
プロキシ DN は、クライアントアプリケーションが送信した LDAP 操作で指定されます。
アカウントの無効化による認証の防止
ユーザアカウントまたはアカウントのセットを一時的に無効にできます。無効にされると、ユーザはディレクトリにバインドできず、認証操作は失敗します。
アカウントの無効化は、nsAccountLock 操作属性を使用して実装されます。エントリに true の値を持つ nsAccountLock 属性が含まれている場合、サーバはバインドを拒否します。
ユーザとロールの無効化にも、同じ手法を使用します。ただし、ロール (role) の無効化は、そのロールのメンバー全員を無効にしますが、ロールのエントリ自体は無効にはしません。ロールについては、「管理されているロール、フィルタを適用したロール、入れ子のロール」を参照してください。
パスワードポリシーの設計
パスワードポリシーは、システム内でパスワードがどのように使用されるかを規定した規則の集まりです。Directory Server で使用できるパスワードポリシーのメカニズムでは、パスワードの長さやユーザによるパスワードの再使用の可否などを指定できます。ユーザがディレクトリへのバインドを試行すると、ディレクトリはそのパスワードとユーザのディレクトリエントリのパスワード属性に格納されている値を比較し、マッチしているかどうかを確認します。また、Directory Server は、ユーザにディレクトリへのバインドを許可する前に、パスワードポリシーで定義されている規則を使用して、パスワードが有効であるかどうかを確認します。
パスワードポリシーの属性
ここでは、サーバのパスワードポリシーを作成するために設定する属性について説明します。次の項目ごとに属性を説明します。
リセット後のパスワードの変更
Directory Server のパスワードポリシーでは、初回のログイン後または管理者がパスワードをリセットしたあとに、ユーザがパスワードを変更する必要があるかどうかを決めることができます。
多くの場合、管理者が設定した初回のパスワードは、ユーザのイニシャル、ユーザ ID、会社名など、ある種の表記規則に従って設定されます。一度表記規則が発見されると、通常ハッカーがシステムに侵入するために最初に入力を試みる候補となります。そのため、初回のログイン後または管理者によるリセット後に、パスワードの変更をユーザに義務付けるとよいでしょう。このオプションをパスワードポリシーに設定すると、ユーザが定義したパスワードが無効になっている場合でも、ユーザはパスワードを変更するように要求されます (詳細は、「ユーザ定義のパスワード」を参照してください)。
パスワードの変更をユーザに許可しないようにした場合、管理者は簡単に推測できる表記規則に従ったパスワードを割り当てるのではなく、簡単に見破られないパスワードを設定します。
デフォルトでは、リセット後にユーザがパスワードを変更する必要はありません。
ユーザ定義のパスワード
パスワードポリシーを設定して、ユーザが自分のパスワードを変更することを許可または禁止することができます。適切なパスワードを用いることは、パスワードポリシーを強固なものにする上で重要です。適切なパスワードとは、安易な単語、つまり辞書に載っているような単語、ペットや子供の名前、誕生日、ユーザ ID、あるいは、簡単に見破られる可能性があるユーザに関するその他の情報 (ディレクトリ自体に格納されている情報も含む) を使用していないものです。
また、パスワードには、文字、数字、記号などの組み合わせを含めるようにしてください。しかし、ユーザは単に覚えやすいパスワードを使用する傾向があります。そのため、「適切な」パスワードの条件を満たすパスワードを事前に設定し、ユーザによるパスワードの変更を許可しない企業もあります。
ただし、ユーザにパスワードを割り当てる作業は、管理者にとってかなりの時間がかかる作業です。また、自分にとって意味があり覚えやすいパスワードをユーザ自身が選択するのではなく、管理者がパスワードを提供すると、ユーザはそのパスワードをどこかに書き留めてしまい、だれかが見つけてしまう危険があります。
パスワードの有効期限
パスワードポリシーでは、ユーザが同じパスワードを無期限に使用できるように設定することができます。また、一定期間が過ぎると、パスワードが期限切れになるように設定することもできます。一般に、パスワードの有効期限が長いほど見破られやすくなります。その一方で、パスワードが頻繁に期限切れになると、ユーザはパスワードを憶えることが困難になり、パスワードを書き留めるようになってしまいます。一般的なポリシーでは、パスワードを 30 〜 90 日で期限切れにします。
パスワードの有効期限をオフにした場合でも、サーバはパスワードの有効期限を記録しています。つまり、パスワードの有効期限のオプションをオンに戻した場合、パスワードの有効期限は、最後にこの機能を無効にしたときに設定していた期間になります。たとえば、パスワードが 90 日で期限切れになるように設定して、次にパスワードの有効期限を無効にするように設定したとします。パスワード期限をもう一度有効にするように設定を戻すと、この機能を無効にする前には有効期限を 90 日に設定していたので、デフォルトのパスワードの有効期限は 90 日になります。
期限切れの警告
一定の期間が過ぎると、ユーザパスワードが期限切れになるようにパスワードポリシーを設定した場合は、パスワードが期限切れになる前にユーザに警告を送信します。パスワードが期限切れになる 1 〜 24,855 日前に、ユーザに警告が送信されるようにポリシーを設定できます。ユーザがサーバにバインドすると、Directory Server によって警告が表示されます。パスワードの有効期限をオンに設定した場合、ユーザのクライアントアプリケーションがこの機能をサポートしていれば、デフォルトではユーザパスワードが期限切れになる 1 日前に (LDAP メッセージを介して) 警告がユーザに送信されます。
パスワードの構文検査
パスワードポリシーでは、最小パスワード長のガイドラインなど、パスワード文字列についての構文のガイドラインを定義します。パスワードの構文検査メカニズムによって、パスワード文字列がパスワードポリシーで定義したパスワード構文のガイドラインに従っているかどうかが検査されます。また、パスワードの構文検査メカニズムは、パスワードが「安易な」単語かどうかも検査します。この場合、安易な単語とは、ユーザのエントリの uid、cn、sn、givenName、ou、または mail 属性に格納されているような値のことです。
デフォルトでは、パスワードの構文検査はオフに設定されています。
パスワード長
Directory Server では、ユーザパスワードの最低文字数を指定できます。一般に、パスワードが短いほど、不正な手段による解読が簡単になります。2 〜 512 文字のパスワードを要求できます。パスワードに適した長さは、8 文字です。これは不正な手段で解読することが難しく、またユーザが記録しておかなくても覚えられる長さです。
パスワードの最短有効日数
指定した期間はユーザにパスワードの変更を許可しないように、Directory Server を設定できます。この機能と passwordHistory 属性を組み合わせると、ユーザが古いパスワードを再使用するのを防止できます。
たとえば、パスワードの最短有効日数 (passwordMinAge) 属性を 2 日に設定すると、1 つのセッションの間にパスワードを繰り返し変更して古いパスワードを履歴からいったんなくし、その後古いパスワードを再使用するという方法を防止できます。0 〜 24,855 日の間の任意の数字を指定できます。ゼロ (0) の値は、ユーザがすぐにパスワードを変更できることを示します。
パスワードの履歴
Directory Server では、2 〜 24 のパスワードを履歴に格納するように設定したり、パスワードの履歴を無効にしたりすることができるので、ユーザはパスワードを再使用できます。
パスワードポリシーを設定してパスワードの履歴を有効にした場合、ディレクトリには指定した数の古いパスワードが格納されます。ユーザが Directory Server に格納されているパスワードを再使用しようとすると、ディレクトリはそのパスワードを拒否します。この機能で、覚えやすい数個のパスワードをユーザが再使用することはできません。
履歴機能をオフに設定しても、パスワードは履歴に残ります。つまり、パスワードの履歴オプションをオンに戻した場合でも、パスワードの履歴を無効にする前に履歴に格納されていたパスワードをユーザは再使用できません。
パスワード保存スキーマ
パスワード保存スキーマでは、ディレクトリ内に Directory Server パスワードを格納するときに使用する暗号化のタイプを指定します。次のタイプを指定できます。
ディレクトリに格納されているパスワードは ACI (アクセス制御情報) 命令を使用して保護できますが、ディレクトリにクリアテキストでパスワードを格納することはお勧めできません。暗号化アルゴリズムは、UNIX のパスワードと互換性があります。SSHA がもっとも安全な選択です。
レプリケーション環境でのパスワードポリシーの設計
複製環境では、パスワードポリシーとアカウントロックアウトポリシーが次のように適用されます。
ディレクトリ内にあるパスワードポリシー情報の一部は複製されます。次の属性が複製されます。
ただし、設定情報はローカルだけで保持され、複製されません。この情報には、パスワードの構文とパスワードの変更履歴が含まれます。アカウントロックアウトのカウンタはレプリケートされません。
レプリケーション環境でパスワードポリシーを設定するときは、次の点を考慮します。
すべての複製は、パスワードの期限切れが近づくと警告を発行する。この情報はローカルの各サーバ上に保持される。したがって、ユーザが複数の複製に順番にバインドした場合、ユーザは同じ警告を数回受信する。また、ユーザがパスワードを変更した場合は、この情報がコンシューマのレプリカで更新されるまで時間がかかることがある。ユーザがパスワードを変更し、その直後にバインドし直した場合は、マスターレプリカに対する変更がコンシューマレプリカに登録されるまではバインドが失敗する場合がある
マスターや複製を含むすべてのサーバでバインドの動作を一致させたい場合は、各サーバ上でパスワードポリシーの設定情報を一致させる
多重マスター環境では、アカウントロックアウトのカウンタが予測できない動作をする場合がある
複製のために作成したエントリ (サーバの識別情報など) には、無期限のパスワードを設定する必要がある。これらの特別なユーザに確実に無期限のパスワードを使用させるには、passwordExpirationTime 属性をエントリに追加し、この属性に 20380119031407Z (有効範囲の上限の値) を指定する
アカウントのロックアウトポリシーの設計
ディレクトリのパスワードポリシー (password policy) を定義したら、アカウントのロックアウトポリシーを設定して、ユーザのパスワードを潜在的な脅威から保護することができます。
ロックアウトポリシーをパスワードポリシーと組み合わせて使用すると、セキュリティが向上します。パスワードポリシーを設定し、ユーザが一定の回数バインドに失敗したら、そのユーザをディレクトリからロックアウトすることができます。
アカウントのロックアウト機能を使用すると、ハッカーがユーザパスワードを繰り返し推測して、ディレクトリに侵入しようとするのを防止できます。アカウントロックアウトのカウンタは、Directory Server と同じマシン上にあります。この機能はディレクトリサービスからのグローバルなロックアウトとして設計されているわけではありません。これは、レプリケーション環境においても、アカウントロックアウトのカウンタがレプリケーションされないことを意味します。
アクセス制御の設計
ディレクトリのクライアントの識別情報を特定する 1 つ以上の認証スキーマを定義したら、ディレクトリ内に含まれる情報を保護するためにスキーマをどのように使用するか決定する必要があります。アクセス制御では、特定の情報へのアクセス権を一部のクライアントに与え、その他のクライアントには与えないように指定することができます。
アクセス制御は、1 つ以上のACL (アクセス制御リスト (access control list)) を使用して指定します。ディレクトリの ACL は、アクセス権限 (読み取り、書き込み、検索など) を許可または拒否し、指定したエントリやその属性と比較する一連のアクセス制御情報 (ACI) 文で構成されています。
また、特定のユーザ、特定のグループに属するすべてのユーザ、およびディレクトリのすべてのユーザに対する権限を設定できます。さらに、IP アドレスや DNS 名など、ネットワークの場所に対してアクセス権を定義することもできます。
ACI の形式について
セキュリティポリシーを設計する場合、ディレクトリ内での ACI の表現方法を理解していると役立ちます。また、ディレクトリで設定できる権限を理解していることも有用です。ここでは、ACI のメカニズムの概要を簡単に説明します。ACI の形式については、『iPlanet Directory Server 管理者ガイド』を参照してください。
target
ACI が対象とするエントリ (通常はサブツリー)、属性、またはその両方を指定します。target は、ACI が適用されるディレクトリの要素を示します。ACI は 1 つのエントリだけを対象にする場合もありますが、複数の属性を対象にすることもできます。また、target には LDAP 検索フィルタを含めることもできます。これにより、共通の属性値を持つ多種多様なエントリに権限を設定できます。
permission
この ACI で設定される実際の権限を示します。permission は、指定した target に対して読み取りや検索などの特定のタイプのディレクトリアクセスを、ACI が許可または拒否していることを示します。
bind_rule
権限が適用されるバインド DN またはネットワークの場所を示します。また、バインド規則で LDAP フィルタを指定することもあり、バインド中のクライアントアプリケーションについてフィルタが true であると評価されると、この ACI がクライアントアプリケーションに適用されます。
つまり、ACI は次のように表現されます。
「ディレクトリオブジェクトの target に対して bind_rule が true の場合、permission が許可または拒否される」
permission と bind_rule はペアで設定し、各ターゲットに対して複数の permission bind_rule ペアを設定できます。これにより、特定のターゲットに複数のアクセス制御を効率的に設定できます。たとえば、次のようにします。
target(permission bind_rule)(permission bind_rule)...
たとえば、Babs Jensen としてバインドしているすべてのユーザに Babs Jensen の電話番号への書き込み権限を設定できます。この権限のバインド規則は、「Babs Jensen としてバインドする場合」と記述している部分です。target は Babs Jensen の電話番号で、permission は書き込み権限です。
ターゲット
ディレクトリで作成した各 ACI で、どのエントリをターゲットとするのかを決定する必要があります。ディレクトリの分岐点を示すディレクトリエントリをターゲットとする場合は、その分岐点だけでなくその子エントリすべてが権限の適用範囲に含まれます。ACI がターゲットとするエントリを明示的に指定しない場合は、その ACI 文が含まれているディレクトリエントリが ACI のターゲットとなります。また、ACI のターゲットとなるデフォルトの属性セットは、ターゲットとなったエントリのオブジェクトクラス構造の中で利用可能なあらゆる属性になります。
ACI ごとに、1 つのエントリだけをターゲットにすることも、1 つの LDAP 検索フィルタに一致するエントリだけをターゲットにすることもできます。
エントリをターゲットとする設定以外にも、そのエントリの属性をターゲットに含めることができます。これにより、属性値の一部だけに適用される権限を設定できます。属性のセットをターゲットとするには、ACI によってターゲットに含まれる属性を明示的に指定するか、ターゲットに含めない属性を明示的に指定します。オブジェクトクラス構造で許可される数個の属性を除くすべての属性に権限を設定する場合は、後者の方法を使用してください。
権限
権限を許可あるいは拒否することができます。一般に、「アクセスの許可または拒否」で説明している理由から、権限を拒否することは避けてください。
Read (読み取り)
ディレクトリデータを読み取ることができるかどうかを示します。
Write (書き込み)
ディレクトリデータを変更または作成できるかどうかを示します。この権限でディレクトリデータを削除することもできますが、エントリ自体を削除することはできません。エントリ全体を削除するには、削除権限を持っている必要があります。
Search (検索)
ディレクトリデータを検索できるかどうかを示します。読み取り権限では、検索操作の一部としてディレクトリデータが返された場合にそれを閲覧できるという点で、この権限は読み取り権限とは異なります。たとえば、共通名の検索と、部屋番号の読み取りを許可している場合、共通名の検索の一部として部屋番号が返されることはありますが、部屋番号自体は検索できません。これにより、ディレクトリを検索しても特定の部屋にだれがいるのかを知ることはできません。
Compare (比較)
比較操作にこのデータを使用できるかどうかを示します。比較には検索機能もありますが、検索操作で実際のディレクトリ情報が返されることはありません。代わりに、比較した値がマッチしたかを示す簡単なブール値だけが返されます。これは、ディレクトリの認証中に userPassword 属性値を照合するために使用されます。
Selfwrite (本人による書き込み)
グループ管理用だけに使用されます。この権限を使用すると、自分をあるグループに追加したり、削除することができます。Selfwrite はプロキシ認証で使用されます。これは、グループエントリに対して、バインドしたユーザの DN ではなく、プロキシ DN の追加や削除を行うための権限を与えます。
Add (追加)
子エントリを作成できるかどうかを示します。この権限を使用すると、対象のエントリの下に子エントリを作成できます。
Delete (削除)
エントリを削除できるかどうかを示します。この権限を使用すると、対象のエントリを削除できます。
Proxy (プロキシ認証)
ディレクトリマネージャ DN 以外の DN を使用して、その DN の権限でユーザがディレクトリにアクセスできることを示します。
バインド規則
バインド規則は通常、権限が適用されるバインド DN を示します。また、時刻や IP アドレスなどのバインド属性を指定することもできます。
バインド規則を使用すると、ユーザ自身が所有しているエントリだけに ACI が適用されることを簡単に表すことができます。これにより、ユーザが自分以外のエントリを更新することを防ぎ、各ユーザが自分のエントリだけを更新できるように設定できます。
バインド規則を使用すると、次の場合に ACI が適用可能であることを示すことができます。
バインド操作が特定の IP アドレスや DNS ホスト名から行われている場合のみ。これは、ディレクトリへのすべての更新が、特定のマシンまたはネットワークドメインから行われるように強制する場合によく使用される
ユーザが匿名でバインドした場合。匿名バインドの権限を設定すると、ディレクトリにバインドするすべてのユーザにその権限が適用されることになる
ディレクトリに正常にバインドしたすべてのユーザについて。これは、匿名アクセスを防ぐ一方、一般的なアクセスを許可する これらのタイプのアクセスをより簡単に表現するために、次のキーワードを使用できます。
Parent (親)
バインド DN が直接の親エントリの場合、バインド規則は true です。たとえば、これにより、あるディレクトリの分岐点ですぐ下の子エントリを管理できるという特定の権限を許可できます。
Self (本人)
バインド DN がアクセスを要求しているエントリと同じ場合、バインド規則は true です。たとえば、個々のユーザに自分のエントリを更新できるという特定の権限を許可できます。
All (すべて)
ディレクトリに正常にバインドしたすべてのユーザについて、バインド規則は true です。
Anyone (全員)
すべてのユーザについて、バインド規則は true です。このキーワードによって、匿名アクセスを許可または拒否します。
権限の設定
デフォルトでは、すべてのユーザに対してすべてのタイプの権限が拒否されています。ディレクトリマネージャは例外です。このため、ユーザがディレクトリにアクセスできるようにするには、ディレクトリにいくつかの ACI を設定する必要があります。
次に、Directory Server が備えているアクセス制御のメカニズムについて説明します。ディレクトリでの ACI の設定方法については、『iPlanet Directory Server 管理者ガイド』を参照してください。
優先規則
ユーザがディレクトリエントリに対してどのようなタイプのアクセスを試みた場合でも、Directory Server はディレクトリ内のアクセス制御セットを検査します。アクセスを確定するために、Directory Server は優先規則を適用します。この規則は、2 つの競合する権限が存在する場合、アクセス拒否の権限がアクセス許可の権限よりも常に優先されことを規定しています。
たとえば、ディレクトリのルートレベルで書き込み権限を拒否して、ディレクトリにアクセスするすべてのユーザにこの権限を適用した場合、ユーザに許可されているほかの権限に関係なく、だれもディレクトリに書き込むことはできません。特定のユーザにディレクトリへの書き込み権限を許可するには、元の書き込み拒否の適用範囲を限定してそのユーザを除外しておく必要があります。また、対象となるユーザに対して書き込みを許可する権限を作成し追加しておく必要があります。
アクセスの許可または拒否
ディレクトリツリーへのアクセスは、明示的に許可または拒否できます。ディレクトリへのアクセスを明示的に拒否する場合は、慎重に行ってください。優先規則が適用されるため、明示的にアクセスを禁止する規則がディレクトリにある場合、アクセスを許可する権限の有無にかかわらず、アクセスは拒否されることになります。
アクセスを許可する規則の適用範囲を限定して、最低限のユーザまたはクライアントアプリケーションだけが含まれるようにしてください。たとえば、ユーザのディレクトリエントリにあるすべての属性への書き込み権限を許可し、ディレクトリ管理者を除くすべてのユーザに uid 属性への書き込み権限を拒否するように権限を設定できます。あるいは、次の方法で書き込み権限を許可する 2 つのアクセス規則を作成するという方法もあります。
uid 属性を除くすべての属性への書き込み特権を許可する規則を 1 つ作成する。この規則はすべてのユーザに適用する必要がある
uid 属性への書き込み特権を許可する規則を 1 つ作成する。この規則は、ディレクトリ管理者グループのメンバーだけに適用する必要がある 許可特権だけを作成することにより、明示的な拒否特権を設定する必要はなくなります。
アクセスを拒否する場合
明示的な拒否を設定する必要がある場合は、ほとんどありません。ただし、次のような状況では明示的な拒否が有効である場合もあります。
複雑な ACL が全体的に適用されている大きなディレクトリツリーがある場合
セキュリティ上の理由から、特定ユーザ、特定グループ、または物理的な場所へのアクセスを拒否する必要性が突然生じる場合があります。許可の権限の適切な制限方法を把握するために既存の ACL を詳しく調べるよりも、検討の余裕ができるまでの間、明示拒否を一時的に設定することができます。ACL がこのように複雑になってしまった場合、拒否の ACI 設定は、長期的には管理の負担を増大させるだけです。できるだけ早期に ACI を修正して、明示的な拒否を取り除きアクセス制御スキーマ全体を簡略化します。
曜日または時間帯に基づいてアクセス制御を限定する場合
たとえば、日曜日の午後 11:00 (2300) から月曜日の午前 1:00 (0100) まで、すべての書き込み操作を禁止します。管理上の観点からは、ディレクトリを検索してすべての ACI 書き込み権限を特定し、この時間帯における許可範囲を制限するよりも、この種の時間に基づいたアクセスを明示的に制限する ACI を管理した方が簡単な場合があります。
ディレクトリの管理権限を複数の管理者に与えるときに、特権を制限する場合
個人またはグループのメンバーにディレクトリツリーの管理を部分的に許可し、その上でそのツリーの一部を変更しないようにする場合は、明示的な拒否を使用します。たとえば、メール管理者に共通名属性への書き込み権限を許可しないようにする場合、共通名属性への書き込み権限を明示的に拒否する ACI を設定します。
アクセス制御規則を置く場所
アクセス制御規則は、ディレクトリの任意のエントリに置くことができます。多くの場合、管理者は country、organization、organizationalUnit、inetOrgPerson、または group のタイプのエントリにアクセス制御規則を置きます。
ACL の管理を簡単にするために、この規則はできるだけグループ化します。通常、規則はターゲットエントリとそのエントリのすべての子に適用されるため、最下位にある個々のエントリ (ユーザなど) にアクセス制御規則を分散させるよりも、ディレクトリのルートポイントまたは分岐点にアクセス制御規則を配置すると良いでしょう。
フィルタが適用されたアクセス制御規則の使用
Directory Server の ACI モデルの強力な機能の 1 つに、LDAP 検索フィルタを使用してアクセス制御を設定できるという機能があります。LDAP 検索フィルタでは、定義した条件に一致するすべてのディレクトリエントリへのアクセス権限を設定できます。
たとえば、マーケティングに設定されている organizationalUnit 属性を含むすべてのエントリへの読み取り権限を許可できます。
フィルタが適用されたアクセス制御規則では、事前にアクセスレベルを定義することもできます。たとえば、ディレクトリに自宅の住所と電話番号に関する情報が含まれているとします。ユーザの中には、この情報の公開を希望する者もいれば、「非公開」を希望する者もいます。このような場合は、次のようにして対処します。
各ユーザのディレクトリエントリに publishHomeContactInfo という属性を作成する
publishHomeContactInfo 属性が TRUE (有効を意味する) に設定されているエントリだけに、homePhone と homePostalAddress 属性への読み取り権限を許可するアクセス制御規則を設定する。LDAP 検索フィルタを使用して、この規則のターゲットを示す
ディレクトリユーザが自分の publishHomeContactInfo 属性の値を TRUE または FALSE に変更できるようにする。このようにすると、この情報を公開するかどうかをディレクトリユーザが決定できる LDAP 検索フィルタの使用方法と、ACI での LDAP 検索フィルタの使用については、『iPlanet Directory Server 管理者ガイド』を参照してください。
ACI の使用 : ヒントと秘訣
セキュリティポリシーを適用する前に知っておくべきヒントを以下に示します。これらのヒントは、ディレクトリのセキュリティモデルを管理する際の負担を軽減し、ディレクトリの性能向上にも役立ちます。
次のヒントの中には、この章ですでに説明したものも含まれますが、内容を完全なものにするために、もう一度ここでも説明します。
ディレクトリに含まれる ACI の数を最小限にする
Directory Server は 50,000 以上の ACI を評価することができますが、多数の ACI 文を管理するのは困難です。ACI の数が多すぎると、特定のクライアントが利用できるディレクトリオブジェクトを即時に判断するのが難しくなります。
iPlanet Directory Server 5.1 には、マクロを使用することによりディレクトリ内の ACI の数を最小限に抑える新しい機能が備わっています。マクロは、ACI の中で DN、または DN の一部を表現するために使用される可変部分です。ACI のターゲット部分、バインド規則、またはその両方で、DN を表現するためにマクロを使用できます。マクロ ACI については、『iPlanet Directory Server 管理者ガイド』の「アクセス制御の管理」を参照してください。
許可権限と拒否権限のバランスを図る
デフォルトの規則ではアクセスを与えられていないすべてのユーザに対してアクセスを拒否しますが、アクセスを許可する 1 つの ACI をツリーのルート近くで使用し、アクセスを拒否する少数の ACI を最下位のエントリの近くで使用することで、ACI の数を減らすことができます。このようにすると、最下位のエントリの近くでアクセスを許可する複数の ACI を使用する必要がなくなります。
ACI では最小の属性セットを指定する
これは、オブジェクトの属性の一部でアクセスを許可または制限している場合、その最小の属性リストが、許可される属性セットであるか、拒否される属性セットであるかを判定することを意味します。次に、最小の属性リストを管理するように ACI を表します。
たとえば、ユーザオブジェクトクラスに多くの属性が含まれている場合を考えます。これらの属性のうち、1 つか 2 つだけをユーザが更新できるようにする場合、その少数について書き込み権限を許可する ACI を作成します。逆に、1 つか 2 つの属性以外のすべてをユーザが更新できるようにする場合は、それらの特定の属性を除くすべてについて書き込み権限を許可する ACI を作成します。
LDAP 検索フィルタは慎重に使用する
検索フィルタではアクセスを管理するオブジェクト名が直接指定されないため、特にディレクトリが複雑になる場合などは、検索フィルタを使用すると、予期しない状況が発生することがあります。ACI の中で検索フィルタを使用する場合、同じフィルタを使用して ldapsearch 操作を実行し、変更の結果がディレクトリに及ぼす影響を確認します。
ディレクトリツリーの別の部分で ACI を重複させない
ACI が重複しないよう注意してください。たとえば、あるグループに commonName および givenName 属性への書き込み権限を許可する ACI がディレクトリのルートポイントにあり、同じグループに commonName 属性だけへの書き込み権限を許可する別の ACI がある場合は、ACI を作り直して 1 つの制御でそのグループに書き込み権限を許可するようにしてください。
ディレクトリが複雑になるにつれ、偶発的に ACI が重複する事態が発生しやすくなります。ACI の重複を避けることにより、セキュリティ管理が容易になる上、ディレクトリに含まれる ACI の総数も減少します。
ACI に名前を付ける
ACI に名前を付けるかどうかは任意ですが、各 ACI にわかりやすい短い名前を付けておくと、特に Directory Console から ACI を検査するときなど、セキュリティ モデルの管理に役立ちます。
ユーザエントリに標準属性を使用して、アクセス権限を決める
可能なかぎり、すでに標準ユーザエントリの一部となっている情報を使用して、アクセス権限を決めてください。特別な属性を作成する必要がある場合は、ロールまたはサービスクラス (CoS) の定義の一部として作成することを検討します。ロールと CoS については、「ディレクトリエントリのグループ化」を参照してください。
ディレクトリ内のできるだけ近い場所に ACI をグループ化する
ACI の配置をディレクトリのルートポイントとディレクトリの主な分岐点に限定します。ACI をグループ化すると、ACI を総合したリストの管理に役立つだけでなく、ディレクトリ内の ACI の総数を最小限に留めるのにも役立ちます。
二重否定は使用しないようにする。たとえば、バインド DN が cn=Joe と等しくない場合の書き込みの拒否など
サーバはこの構文を完全に理解できますが、管理者にとっては混乱の元となります。
SSL による接続のセキュリティ保護
ユーザを識別する認証スキーマとディレクトリ内の情報を保護するアクセス制御スキーマの設計が完了したら、サーバとクライアントアプリケーションの間でやり取りされる情報の整合性をどのように確保するのかを計画する必要があります。
ネットワーク上で安全な通信を可能にするために、SSL (Secure Sockets Layer) 上で LDAP プロトコルを使用できます。
SSL は、RSA 社が開発した RC2 および RC4 暗号化アルゴリズムと組み合わせて使用することができます。特定の接続で使われる暗号化方式は、クライアントアプリケーションと Directory Server の間のネゴシエーションの結果で選択されます。
また SSL は、転送中に情報が変更されていないことを保証するハッシュメカニズムである、CRAM-MD5 と組み合わせて使用することもできます。
Directory Server では、SSL でセキュリティ保護された接続と SSL を使用しない接続を同時に使用することができます。
SSL の使用については、『iPlanet Directory Server 管理者ガイド』を参照してください。
その他のセキュリティ関連資料
安全なディレクトリの設計方法については、以下の資料を参照してください。
iPlanet Security Developer Central
http://developer.iplanet.com/tech/security/
『Understanding and Deploying LDAP Directory Services』
(T. Howes、M. Smith、G. Good 著、Macmillan Technical Publishing 発行、1999 年)
SecurityFocus.com
http://www.securityfocus.com/
コンピューター緊急事態対策チーム (CERT) 管理センター
http://www.cert.org/
CERT セキュリティ向上モジュール
http://www.cert.org/security-improvement/
前へ 目次 索引 DocHome 次へ
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.
Last Updated March 02, 2002