|
| |
| Sun Java™ System Directory Server 5.2 2005Q1 配備計画ガイド | |
第 7 章
アクセス制御、認証、および暗号化Directory Server のデータを保護する方法は、ほかのすべての設計領域に影響します。この章では、セキュリティ要件の分析方法と、その要件を満たすディレクトリの設計方法について説明します。この章は、次の節で構成されています。
セキュリティに対する脅威ディレクトリのセキュリティに対する脅威となるものは数多く存在します。一般的な脅威についての理解を深めておくと、全体的なセキュリティ設計を行うときに役立ちます。ディレクトリのセキュリティに対する代表的な脅威は、次のカテゴリに分類できます。
不正なアクセス
不正なアクセスからディレクトリを保護することは簡単なようにみえますが、この問題はかなり複雑です。ディレクトリ情報の配信経路には、権限のないクライアントがデータにアクセスできる箇所がいくつもあります。不正なアクセスには、次のようなものがあります。
たとえば、権限のないクライアントが別のクライアントの証明情報を利用してデータにアクセスする場合や、権限のないクライアントが、正当なクライアントと Directory Server の間でやり取りされる通信情報を傍受する場合があります。
権限のないアクセスは社内から発生することも、また、会社がエクストラネットやインターネットに接続している場合は、外部から発生することもあります。
Directory Server に備わっている認証方法、パスワードポリシー、およびアクセス制御のメカニズムは、不正アクセスの防止に効果があります。詳細は、「適切な認証方法の選択」、「パスワードポリシーの設計」、および「アクセス制御の設計」を参照してください。
不正な改ざん
侵入者がディレクトリへアクセスしたり、Directory Server とクライアントアプリケーションの間の通信を傍受した場合は、ディレクトリデータが変更 (あるいは改ざん) される潜在的な危険があります。このような不正な改ざんには、次のようなものがあります。
クライアントがデータを信頼できなかったり、ディレクトリ自体がクライアントから受信する変更や照会を信頼できない場合、ディレクトリは役に立たなくなります。
ディレクトリが改ざんを検出できない場合、侵入者がクライアントからサーバーへの要求を変更したり、要求を取り消したり、サーバーからクライアントへの応答を変更することができます。SSL (Secure Socket Layer) プロトコルや、それと同様の技術を利用して、接続の両端で情報に署名することで、この問題は解決できます。Directory Server での SSL の使用については、「SSL による接続のセキュリティ保護」を参照してください。
サービス拒否
サービス拒否攻撃とは、侵入者がディレクトリによるクライアントへのサービスの提供を妨害することです。たとえば、侵入者はひたすらシステムのリソースを消費して、ほかのユーザーがリソースを使用するのを妨害します。
Directory Server では、特定のバインド DN に割り当てるリソースに制限を設定することで、サービスの拒否攻撃を防ぎます。詳細は、『Administration Server Administration Guide』の「Setting Individual Resource Limits」を参照してください。
セキュリティ手法の概要セキュリティポリシーは、権限のないユーザーが機密情報を変更したり取り出したりできないような強固なものであると同時に、簡単に情報の管理ができるものでなければなりません。複雑なセキュリティポリシーを作成すると、許可したユーザーが情報にアクセスできなかったり、あるいはアクセスを許可していないユーザーがディレクトリ情報を変更したり取り出したりする問題につながります。
Directory Server では、次のセキュリティ手法を使用できます。
セキュリティを管理するこれらのツールは、セキュリティの設計と組み合わせて使用できます。セキュリティの設計をサポートするために、レプリケーションやデータの分散など、ほかのディレクトリの機能を使用することもできます。
セキュリティ要件の分析第 2 章「ディレクトリデータの計画とアクセス」でサイト調査を実施した際に、ディレクトリ内の各データについてどのユーザーが読み取りまたは書き込みができるかの決定は終わっているはずです。この情報が、ここではセキュリティの設計の基盤となります。
また、セキュリティの実装方法は、ディレクトリをどのように使用して業務をサポートするかによって異なります。イントラネットを供給するディレクトリでは、エクストラネットをサポートするディレクトリやインターネット上に公開されている電子商取引アプリケーションと同等のセキュリティレベルが要求されることはありません。
ディレクトリがイントラネットだけにサービスを提供する場合は、次の事項を考慮する必要があります。
ディレクトリがエクストラネットにサービスを提供したり、インターネットを介して電子商取引アプリケーションをサポートしたりする場合は、顧客とパートナー企業に機密性を保証する必要もあります。
次に、セキュリティ要件の分析について、以下の項目ごとに説明します。
アクセス権限の決定
データ解析を実行するときは、ユーザー、グループ、取引先、顧客、およびアプリケーションがアクセスする必要のあるデータを特定します。
次の 2 通りの方法でアクセス権を与えます。
どちらの方法でアクセス権限を与える場合でも、組織のユーザーが属するカテゴリとそのカテゴリに与えるアクセス権限を一覧にした、簡単な表を作成してください。また、ディレクトリに保持する機密データ、および各データを保護するために使用した手法を一覧にした表も必要に応じて作成してください。
ユーザーの識別方法については、「適切な認証方法の選択」を参照してください。ディレクトリ情報へのアクセスを制限する方法については、「アクセス制御の設計」を参照してください。
データの機密性と完全性の保証
エクストラネットを介して取引先との情報交換を行う場合、あるいはインターネット上で顧客が使用する電子商取引アプリケーションをサポートするためにディレクトリを使用する場合は、交換するデータの機密性と完全性を保証する必要があります。
これには、次のような方法があります。
Directory Server で使用可能な暗号化方法については、「パスワード保存スキーマ」および「属性の暗号化」を参照してください。データの署名については、「SSL による接続のセキュリティ保護」を参照してください。
セキュリティ監査の実行
セキュリティ監査により、セキュリティポリシーの実装が機能していることが保証されます。セキュリティ監査にはいくつかの側面があります。基本的な監査手順は、ネットワーク上のぜい弱性を識別するネットワークベースのセキュリティスキャナを使用したテストを自動化することです。また、ログファイルと SNMP エージェントによって記録された情報を検査することで、監査を実行することもできます。ディレクトリの監視については、第 8 章「Directory Server の監視」を参照してください。
適切な認証方法の選択セキュリティポリシーに関して決定が必要な項目に、Directory Server に対するユーザーのアクセス方法があります。匿名アクセスを許可するかどうか、または Directory Server を使用するすべてのユーザーにディレクトリへのバインドを要求するかどうかを決定します。
Directory Server は、次の認証方法をサポートしています。
相手がユーザーか LDAP 対応アプリケーションかにかかわらず、すべてのユーザーに対して同じ認証メカニズムが適用されます。
クライアント単位またはクライアントのグループ単位での認証の防止方法については、「アカウントの無効化による認証の防止」を参照してください。
匿名アクセス
匿名アクセスは、ディレクトリにアクセスするもっとも簡単な形式です。匿名アクセスを使用すると、認証とは関係なくだれでもディレクトリデータを利用できます。
しかし、匿名アクセスでは、だれがどのような検索を実行しているのかを追跡することはできず、検索を実行しているユーザーがいるということしかわかりません。匿名アクセスを許可すると、ディレクトリに接続するユーザーはだれでもデータにアクセスできます。
したがって、特定のユーザーまたはユーザーのグループによるディレクトリデータへの読み取りを禁止しようとしても、そのデータへの匿名アクセスを許可していれば、ユーザーは匿名でディレクトリにバインドすることでデータへのアクセスが可能になります。
匿名アクセスの特権は制限できます。通常、ディレクトリ管理者は、匿名アクセスに対して読み取り、検索、および比較の特権だけを許可します。また、アクセスは、ユーザー名、電話番号、電子メールアドレスなど、一般的な情報を含む属性のサブセットに限定されるのが普通です。匿名アクセスは、政府指定の ID (米国の社会保障番号など)、自宅の電話番号と住所、給与情報など機密データには絶対に許可しないでください。
ユーザーパスワード属性が含まれていないエントリでユーザーがバインドを試行した場合、Directory Server は次のどちらかを実行します。
たとえば、次の ldapsearch コマンドを考えてみます。
% ldapsearch -h ds.example.com -D "cn=joe,dc=Example,dc=com"
-w secretpwd -b "cn=joe,dc=Example,dc=com" "objectclass=*"ldap_simple_bind_s: Invalid credentials
この場合、Directory Server によって読み取りについての匿名アクセスが許可されますが、ldapsearch コマンドで与えたパスワードと一致するパスワードが自分のエントリに含まれていないため、Joe は自分のエントリにアクセスできません。
簡易パスワード
匿名アクセスを設定しない場合、ディレクトリの内容にアクセスするにはクライアントで Directory Server への認証を行う必要があります。簡易パスワード認証では、クライアントは再使用可能な簡単なパスワードを送信して、サーバーへの認証を行います。
たとえば、識別名と証明情報を送信するバインド操作によって、クライアントは Directory Server への認証を行います。サーバーはクライアント DN に対応したディレクトリ内のエントリを検出し、クライアントから送信されたパスワードとエントリ内に格納されている値が一致するかどうかを確認します。一致した場合、サーバーはクライアントを認証します。一致しない場合、認証操作は失敗し、クライアントにエラーメッセージが返されます。
多くの場合、バインド DN はユーザーのエントリに対応しています。ただし、ユーザーのエントリとしてではなく管理者のエントリとしてバインドする方が便利だと考えるディレクトリ管理者もいます。Directory Server では、バインドに使用するエントリは、userPassword 属性を使用できるオブジェクトクラスのエントリである必要があります。これにより、ディレクトリがバインド DN とパスワードを認識することができます。
ユーザーが DN の長い文字列を記憶できない場合もあるため、多くの LDAP クライアントはバインド DN をユーザーに表示しません。クライアントがバインド DN をユーザーに表示しない場合、クライアントは次のようなバインドアルゴリズムを使用します。
簡易パスワード認証ではユーザーを簡単に認証できますが、組織のイントラネットだけに使用を限定した方がよいでしょう。この認証では、エクストラネットを介した取引先との転送やインターネット上での顧客との転送に求められるレベルのセキュリティは提供されません。
プロキシ承認
プロキシ承認は特殊な形式のアクセス制御です。ユーザーは自分の ID を使用して Directory Server にバインドしますが、プロキシ承認によって別のユーザーの権限が与えられます。
プロキシ承認を使用すると、ディレクトリ管理者は一般ユーザーとして Directory Server へのアクセスを要求できます。ディレクトリ管理者は自分の証明情報を使用してディレクトリにバインドしますが、アクセス制御の評価のために、一般ユーザーの権限が与えられます。このような仮のユーザーはプロキシユーザーと呼ばれ、そのユーザーの DN は プロキシ DN と呼ばれます。
プロキシ要求を実行できる Directory Server を設定するには、次の手順を実行します。
プロキシの主な利点の 1 つとして、Directory Server に要求を送信している複数のユーザーにサービスを提供するために、LDAP アプリケーションが 1 つのバインドで 1 つのスレッドを使用できるようにする点が挙げられます。ユーザーごとにバインドして認証する代わりに、クライアントアプリケーションはプロキシ DN を使用して Directory Server にバインドします。
プロキシ承認については、『Directory Server 管理ガイド』の「アクセス制御の管理」を参照してください。
セキュリティ保護された接続での簡易パスワード
セキュリティ保護された接続では、暗号化によって第三者がデータを読めないようにした上で、Directory Server とクライアントの間でデータを送信します。クライアントは、次のいずれかの方法でセキュリティ保護された接続を確立できます。
どちらの場合も、サーバーにはセキュリティ証明書が必要で、この証明書を信頼するようにクライアントを設定する必要があります。サーバーは、証明書をクライアントに送信することで、公開鍵暗号化方式を使用してサーバー認証を行います。その結果、クライアントは目的のサーバーに接続していること、およびサーバーが改ざんされていないことを認識します。
これ以後、クライアントとサーバーは、この接続を通じて伝送されるすべてのデータを機密保護のために暗号化します。クライアントは、暗号化された接続でバインド DN とパスワードを送信してユーザー認証を受けます。それ以後のすべての操作は、そのユーザーの ID、またはバインド DN に別のユーザー ID へのプロキシ権限が含まれる場合はプロキシ ID による操作として実行されます。操作の結果がクライアントに返されるときは、すべてが暗号化されます。
SSL については、「SSL による接続のセキュリティ保護」を参照してください。証明書の設定と SSL の有効化については、『Directory Server 管理ガイド』の「認証と暗号化の管理」を参照してください。
証明書に基づくクライアント認証
SSL または TLS を使用する暗号化された接続を確立するときに、サーバーがクライアント認証を要求するように設定することもできます。クライアントは、ユーザー ID の確認のためにサーバーに証明書を送信する必要があります。バインド DN の決定には、ユーザーの DN ではなく、証明情報が使用されます。クライアント認証は、ユーザーの偽装を防ぐ保護で、もっとも安全な接続です。
クライアントが送信できる証明情報の 1 つにユーザー証明書があります。証明書ベースの認証を行うには、証明書のマッピングを行うようにディレクトリを設定し、すべてのユーザーは各自の証明書をそれぞれのエントリに格納しておく必要があります。クライアントからユーザー証明書を受け取ると、サーバーは証明書の内容に基づいてマッピングを行い、ディレクトリからユーザーエントリを検索します。このエントリには、そのユーザーの証明書とまったく同じコピーが含まれている必要があり、これによってユーザー ID の有効性が識別されます。すべての操作はこのエントリの DN をバインド DN として行われ、すべての結果は SSL または TLS 接続によって暗号化されます。
証明書のマッピングについては、『Administration Server Administration Guide』の「Using Client Authentication」および『Directory Server 管理ガイド』の「クライアントでの証明書ベースの認証の設定」を参照してください。
Directory Server は、従来可能だったものよりも大きい証明書に対応できる証明書ベースを含む、NSS (Network Security Services) コンポーネントのバージョンをサポートするようになりました。また、14K バイトより大きいオブジェクトがインポートされると、証明書データベースの次にディレクトリが自動的に作成されます。
SASL ベースのクライアント認証
SSL または TLS 接続でクライアントを認証する方法としては、SASL (Simple Authentication and Security Layer) によるクライアント ID の確認もあります。Directory Server は、SASL の汎用セキュリティインタフェースを通じて次のメカニズムをサポートします。
- DIGEST-MD5: このメカニズムは、クライアントから送信されたハッシュ値とユーザーパスワードのハッシュを比較することでクライアントを認証します。ただし、このメカニズムはユーザーパスワードを読み取る必要があり、DIGEST-MD5 による認証を希望するすべてのユーザーは、ディレクトリ内に {CLEAR} パスワード (クリアテキスト形式のパスワード) を持つ必要があります。
- GSSAPI: Solaris オペレーティングシステムで利用できる GSSAPI (General Security Services API) では、Directory Server は Kerberos V5 セキュリティシステムとの対話によってユーザーを識別します。クライアントアプリケーションは Kerberos システムに証明情報を提示し、このシステムがユーザーの ID を Directory Server に返します。
どちらの SASL メカニズムを使用する場合も、ID のマッピングを行うようにサーバーを設定する必要があります。SASL 証明情報は主体と呼ばれ、各メカニズムは特定のマッピングを使用して主体の内容からバインド DN を決定します。主体が 1 つのユーザーエントリにマッピングされ、SASL メカニズムがそのユーザーの ID を検証すると、ユーザーの DN がその接続のバインド DN となります。
詳細は、『Directory Server 管理ガイド』の「クライアントでの SASL DIGEST-MD5 の使用」および「クライアントでの Kerberos SASL GSSAPI の使用」を参照してください。
アカウントの無効化による認証の防止ユーザーアカウントまたはアカウントのセットを一時的に無効にできます。アカウントが無効になると、ユーザーは Directory Server にバインドできないため、このユーザーの認証操作は失敗します。
アカウントの無効化は、nsAccountLock オペレーショナル属性を使用して実装されます。エントリに true の値を持つ nsAccountLock 属性が含まれている場合、サーバーはバインドを拒否します。nsAccountLock 属性は、手動ではなくコマンド行ユーティリティを使って変更してください。
ユーザーとロールの無効化にも、同じ手法を使用します。ただし、ロールの無効化は、そのロールのメンバー全員を無効にしますが、ロールのエントリ自体は無効にはしません。ロールについては、「管理されているロール、フィルタを適用したロール、入れ子のロール」を参照してください。
パスワードポリシーの設計パスワードポリシーは、システム内でパスワードがどのように管理されるかを規定した規則の集合です。
パスワードポリシーにより、ディレクトリ全体に対して 1 つのグローバルポリシーではなく、複数のパスワードポリシーを設定できます。また、Cos およびロール機能を使用して、パスワードポリシーを特定のユーザーまたはユーザーセットに適用することができます。特定のユーザーまたはロールに合わせてパスワードポリシーを設定できるので、パスワードポリシーによるセキュリティ対策の実装時にも適用範囲が大幅に広がります。
パスワードポリシーは、スタティックグループには適用できません。
パスワードポリシーの作成に使用できる属性については、『Directory Server Administration Reference』の「Password Policy Attributes」および「Account Lockout Attributes」を参照してください。パスワードポリシーの設定と管理については、『Directory Server 管理ガイド』の「ユーザーアカウントとパスワードの管理」を参照してください。この節は、次の項目で構成されています。
パスワードポリシーの機能
ここでは、パスワードポリシーの主な機能について説明します。説明する内容は次のとおりです。
ユーザー定義のパスワード
パスワードポリシーを設定して、ユーザーが自分のパスワードを変更することを許可または禁止することができます。適切なパスワードを用いることは、パスワードポリシーを強固なものにする上で重要です。適切なパスワードとは、安易な単語、つまり辞書に載っているような単語、ペットや子供の名前、誕生日、ユーザー ID、あるいは、簡単に見破られる可能性があるユーザーに関するその他の情報 (ディレクトリ自体に格納されている情報も含む) を使用していないものです。
また、パスワードには、文字、数字、記号などの組み合わせを含めるようにしてください。しかし、ユーザーは単に覚えやすいパスワードを使用する傾向があります。そのため、「適切な」パスワードの条件を満たすパスワードを事前に設定し、ユーザーによるパスワードの変更を許可しない企業もあります。
ただし、ユーザーにパスワードを割り当てる作業は、管理者にとってかなりの時間がかかる作業です。また、自分にとって意味があり覚えやすいパスワードをユーザー自身が選択するのではなく、管理者がパスワードを提供すると、ユーザーはそのパスワードをどこかに書き留めてしまい、だれかが見つけてしまう危険があります。デフォルトでは、ユーザー定義のパスワードは許可されています。
最初のログインまたはリセット時のパスワードの変更
Directory Server のパスワードポリシーでは、初回のログイン時または管理者がパスワードをリセットしたあとに、ユーザーがパスワードを変更する必要があるかどうかを決めることができます。
多くの場合、管理者が設定した初回のパスワードは、ユーザーのイニシャル、ユーザー ID、会社名など、ある種の表記規則に従って設定されます。一度表記規則が発見されると、通常ハッカーがシステムに侵入するために最初に入力を試みる候補となります。そのため、初回のログイン時または管理者によるリセット後に、パスワードの変更をユーザーに義務付けるとよいでしょう。このオプションをパスワードポリシーに設定すると、ユーザーが定義したパスワードが無効になっている場合でも、ユーザーはパスワードを変更するように要求されます。前の「ユーザー定義のパスワード」の項を参照してください。
デフォルトでは、ログイン時またはリセット後にユーザーがパスワードを変更する必要はありません。
パスワードの有効期限
パスワードポリシーは、ユーザーが同じパスワードを無期限に使用できるように、または一定期間が過ぎるとパスワードが期限切れになるように設定することができます。一般に、パスワードの有効期限が長いほど見破られやすくなります。ただし、パスワードが頻繁に期限切れになると、ユーザーはパスワードを憶えることが困難になり、パスワードを書き留めるようになってしまいます。一般的なポリシーでは、パスワードを 30 から 90 日で期限切れにします。
Directory Server では、パスワードの有効期限を無効にしても、パスワードの有効期限の設定は残されます。つまり、パスワードの有効期限のオプションを有効に戻した場合、パスワードの有効期限は、最後にこの機能を無効にしたときに設定していた期間になります。たとえば、パスワードが 90 日で期限切れになるように設定して、次にパスワードの有効期限を無効にするように設定したとします。パスワード期限をもう一度有効にするように設定を戻すと、この機能を無効にする前には有効期限を 90 日に設定していたので、デフォルトのパスワードの有効期限は 90 日になります。
デフォルトでは、ユーザーパスワードは期限切れになりません。
新しいグローバル設定属性 usePwdChangedTime により、パスワードが変更されたあと、たとえば管理者がパスワードをリセットしたあとで、ユーザーがログインできる時間を制限することができます。
期限切れの警告
一定の期間が過ぎると、ユーザーパスワードが期限切れになるようにパスワードポリシーを設定した場合は、パスワードが期限切れになる前にユーザーに警告を送信します。パスワードが期限切れになる 1 〜 24,855 日前に、ユーザーに警告が送信されるようにポリシーを設定できます。ユーザーがサーバーにバインドすると、Directory Server によって警告が表示されます。デフォルトでは、パスワードの有効期限をオンに設定した場合、ユーザーのクライアントアプリケーションがこの機能をサポートしていれば、ユーザーパスワードが期限切れになる 1 日前に (LDAP メッセージを介して) 警告がユーザーに送信されます。
パスワードの構文検査
パスワードポリシーには、パスワード文字列の構文ガイドラインがあります。パスワードの構文検査メカニズムによって、パスワード文字列がこれらのガイドラインに従っているかどうかが検査されます。デフォルトでは、パスワードの構文検査はオフに設定されています。パスワード長の検査は、パスワードの構文検査が有効な場合にだけ行われます。
パスワード長
Directory Server では、ユーザーパスワードに必要な最少文字数を指定できます。一般に、パスワードが短いほど、不正な手段による解読が簡単になります。2 〜 512 文字のパスワードを要求できます。パスワードに適した長さは、8 文字です。これは不正な手段で解読することが難しく、またユーザーが記録しておかなくても覚えられる長さです。
デフォルトの最小パスワード長は 6 文字です。最小パスワード長の検査は、パスワードの構文検査が有効な場合にだけ行われます。
パスワードの最短有効日数
パスワードポリシーは、ユーザーが指定された期間の間パスワードを変更できないように設定できます。この機能とパスワード履歴機能を組み合わせると、ユーザーが古いパスワードを再使用するのを防止できます。
たとえば、パスワードの最短有効日数を 2 日に設定すると、1 つのセッションの間にパスワードを繰り返し変更して古いパスワードを履歴からいったんなくし、その後古いパスワードを再使用するという方法を防止できます。0 〜 24,855 日の間の任意の数字を指定できます。ゼロ (0) の値は、ユーザーがすぐにパスワードを変更できることを示します。
パスワードの履歴
Directory Server は、これまでに使用されたパスワードを最大 24 個格納するように設定できます。
パスワード履歴が有効な場合、ユーザーが Directory Server に格納されているパスワードを再使用しようとすると、そのパスワードが拒否されます。この機能を使用した場合、覚えやすい数個のパスワードをユーザーが再使用することはできなくなります。
パスワード履歴機能が無効の場合は、過去に使用されたパスワードは格納されず、ユーザーはパスワードを再使用できます。デフォルトでは、Directory Server はパスワード履歴を保持します。
パスワード保存スキーマ
パスワード保存スキーマでは、ディレクトリ内にパスワードを格納するときに使用する暗号化のタイプを指定します。次のタイプを指定できます。
ディレクトリに格納されているパスワードは ACI (アクセス制御情報) 命令を使用して保護できますが、ディレクトリにクリアテキストでパスワードを格納することはお勧めできません。CRYPT アルゴリズムは、UNIX のパスワードと互換性があります。SSHA はもっとも安全な方式で、Directory Server のデフォルトのハッシュアルゴリズムです。
パスワードポリシーの設定
次のようなパスワードポリシーのオプションがあります。
- グローバルパスワードポリシー。cn=Password Policy,cn=config の下に格納され、デフォルトで適用されます。このグローバルポリシーのパラメータは、変更可能です。
- Directory Server 5.2 より前の Directory Server のバージョンでは、グローバルパスワードポリシーが唯一のパスワードポリシーでした。グローバルパスワードポリシーのバックアップとして、ハードコーディングされたパスワードポリシーが用意されています。このポリシーは、グローバルパスワードポリシーが見つからない場合や、変更によって有効でなくなった場合に適用されます。ハードコーディングされたパスワードポリシーの属性値は、デフォルトのグローバルパスワードポリシーの値と同じです。
- パスワードポリシーを定義して、それを特定のユーザーに適用できます。
- パスワードポリシーを定義し、CoS 機能やロール機能を使用してそれをユーザーセットに適用することができます。
注: パスワードポリシーは、スタティックグループには適用できません。
ここでは、これらのオプションの詳細と、特定のユーザーエントリに複数のパスワードポリシーが存在する場合にパスワードポリシーの適用を制御する優先順位について説明します。この節は、次の項目で構成されています。
グローバルパスワードポリシー
グローバルパスワードポリシーは、cn=Password Policy,cn=config の下に格納され、デフォルトで適用されます。このポリシーは、セキュリティのニーズに合うように変更できます。デフォルトのグローバルポリシーには、次の項目が適用されます。
- SSHA 保管スキーマ。
- ユーザーはパスワードを変更できる。
- 最初のログイン時、または管理者がパスワードをリセットしたあとに、ユーザーはパスワードを変更する必要はない。
- パスワードの構文検査 (最小文字数の遵守) を行わない。
- パスワードには有効期限は設定されない。
- パスワードの有効期限を有効化した場合、パスワードの最大有効期間は 100 日である。
- パスワードの変更が可能になるまでの期間は設定されない。
- パスワードの有効期限を有効化した場合は、パスワードの有効期限が切れる 1 日前の最初のバインド試行時にパスワードの期限切れ警告が送信される。
- 使用したパスワードは記録されない。
- ユーザーはアカウントをロックアウトされない。
- アカウントロックアウトを有効にした場合は、3 回バインド試行に失敗すると、ユーザーはロックされ、ロックアウトは 1 時間継続する。
- パスワード失敗の記録は、600 秒後に失敗カウンタから削除される。
パスワードに有効期限が設定されず、構文検査は行われず、アカウントロックアウトメカニズムも有効化されていないデフォルトポリシーは、管理のオーバーヘッドは低くても、もっとも安全なものではありません。セキュリティ要件と、厳しいパスワードポリシーによる管理のオーバーヘッドの間でバランスを取る必要があります。
注
従来バージョンの Directory Server では、グローバルパスワードポリシー属性は cn=config の直下に格納されていました。現在は、cn=Password Policy,cn=config の下に格納されます。このエントリが存在しない場合は、Directory Server に用意されているハードコーディングされたパスワードポリシーが適用されます。
ユーザーまたはユーザーセットに適用するパスワードポリシーの定義
特定のユーザーエントリまたはユーザーセットに適用するパスワードポリシーは、passwordPolicySubentry という属性を使用して定義します。この属性の値は、ユーザーのエントリに直接適用するパスワードポリシー属性が含まれる LDAP サブエントリの DN です。この属性は、実際の属性にすることも、CoS 定義によって生成した仮想属性にすることもできます。
CoS 定義を設定し、ユーザーエントリが持つロールの機能として、ユーザーエントリ内の passwordPolicySubentry 属性に値を指定することで、ユーザーセットに適用するパスワードポリシーを定義できます。ユーザーセットに適用するパスワードポリシーを定義する方法はほかにもありますが、Directory Server コンソール ではこの方法を使用します。パスワードポリシーは、スタティックグループには適用できません。
パスワードポリシーの管理を容易にするために、パスワードポリシーの適用対象となるユーザーまたはユーザーセットと、パスワードポリシー自体を同じ場所で保管してください。これにより、パスワードポリシーの LDAP サブエントリがパスワードポリシーと一緒にレプリケートされます。
パスワードポリシーは、ダイナミックグループに適用できますが、スタティックグループには適用できません。
個々のパスワードポリシーの定義手順については、『Directory Server 管理ガイド』の「個別パスワードポリシーの管理」を参照してください。
複数のパスワードポリシーとその優先順位
ユーザーエントリに複数のパスワードポリシーが割り当てられている場合にパスワードポリシーの適用を制御する優先順位には、主に 3 つの規則が適用されます。適用する規則は次のとおりです。
- CoS 定義によって生成されるパスワードポリシーは、ユーザーエントリに直接割り当てられているパスワードポリシーに優先して適用されます。これは、CoS 定義エントリに定義されている cosAttribute 値には operational 修飾子が必ず含まれているためで、これにより、CoS 生成によるパスワードポリシーは、ユーザーに直接割り当てられたあらゆる実属性に優先して適用されます。ロールと CoS メカニズムについては、第 4 章「ディレクトリ情報ツリー」を参照してください。
- ユーザーエントリに直接割り当てられているパスワードポリシーは、グローバルパスワードポリシーに優先して適用されます。
- cn=Password Policy,cn=config の下に格納されているグローバルパスワードポリシーは、Directory Server に用意されているハードコーディングされたパスワードポリシーの値に優先して適用されます。
警告
CoS を使用してパスワードポリシーを設定するときは、CoS によって生成された複数のパスワードポリシーがユーザーに適用された場合の優先順位を指定する必要があります。優先順位を指定するには、CoS テンポラリエントリを作成するときに cosPriority 属性に適切な値を入力します。最優先を指定するには、値に 0 を割り当てます。cosPriority 属性を持たない CoS テンプレートの優先順位は最低と見なされ、複数のテンプレートの cosPriority 属性の値が同じ (または指定されていない) 場合は、任意の優先順位が適用されます。ロールと CoS については、第 4 章「ディレクトリ情報ツリー」を参照してください。
辞書攻撃の防止
辞書攻撃では、侵入者は認証が得られるまで、繰り返し一般用語のリストからパスワードを推測して解読しようとします。このような攻撃に対応するために、サーバーには 3 つのツールが用意されています。
- パスワード構文検査では、ユーザーエントリの uid、cn、sn、givenName、ou、または mail 属性の一致を検証します。いずれかの値と一致する場合、サーバーはユーザーによるパスワードの設定を拒否します。ただしパスワード構文検査では、/usr/dict/words の単語をすべて試すような実際の辞書攻撃は阻止されません。
- パスワードに最小限必要な文字数を設定すると、ユーザーは短いパスワードを設定できません。パスワードが長くなるほど、すべての値を想像したり、組み合わせることが指数関数的に困難になります。Directory Server では、パスワード構文検査と最小限必要な文字数の設定の両方を有効にする必要があります。
- アカウントロックアウトメカニズムは、認証の試みが数回失敗した後にバインドを拒否します。パスワードポリシーの厳密度に応じて、一時的なロックアウトと永続的なロックアウトのいずれかが適用されます。
いずれも、自動的なパスワードの推測を効果的に防止します。たとえば、5 回までの試行を許可してその後にユーザーアカウントを 5 分間ロックアウトした場合、平均すると侵入者は 1 分間に 1 回の推測しか行えず、正規のユーザーが入力ミスなどでロックアウトされた場合も短時間で再試行できます。永続的なロックアウトの場合は、Directory Manager から手動でパスワードをリセットする必要があります。
アカウントロックアウトのカウンタは Directory Server 固有です。この機能は、ディレクトリサービスからグローバルにロックアウトするようには設定されていません。つまり、レプリケーション環境でもアカウントロックアウトのカウンタはレプリケートされません。
レプリケーション環境でのパスワードポリシー
グローバルパスワードポリシーの設定情報は cn=config の下にあるエントリのため、レプリケートされません。このため、グローバルパスワードポリシーを変更する場合は、トポロジ内の各サーバーで、同じ変更を手動で加える必要があります。レプリケートされるグローバルパスワードポリシーが必要な場合は、レプリケートされるディレクトリツリーの一部の下に、そのようなポリシーを定義する必要があります。
ユーザーエントリに格納されるパスワード情報 (現在のパスワード、パスワード履歴、パスワードの有効期限など) は、すべてレプリケートされます。アカウントロックアウトのカウンタはローカルサーバーレベルで格納され、レプリケートはされません。
レプリケートされた環境では、パスワードポリシーによる次の影響を考慮する必要があります。
- パスワードの期限切れが近づいたユーザーは、パスワードを変更するまで、バインドするすべてのレプリカから警告を受信します。
- ユーザーがパスワードを変更すると、すべてのレプリカでパスワード変更の情報が更新されるまでに時間がかかります。ユーザーがパスワードを変更し、すぐに新しいパスワードでコンシューマレプリカのどれかに再度バインドしようとすると、レプリカが更新されたパスワードを受信するまでは、バインドに失敗します。
- 各レプリカには、レプリケートされない個別のアカウントロックアウトカウンタが保持されています。その結果、ロックアウトポリシーはどれか 1 つのレプリカで適用されますが、ユーザーが複数のレプリカでバインドを試みるとポリシーが適用されないことがあります。たとえば、レプリケーショントポロジに 10 のサーバーがあり、3 回の試行後にロックアウトが有効になる場合、侵入者はパスワードの推測を 30 回行える計算になります。
- 複数パスワードポリシーを使用する環境では、レプリケートされたエントリに適用するポリシーの定義を含む LDAP サブエントリをレプリケートする必要があります。これを行わない場合、ポリシー定義を含む LDAP サブエントリが存在しないため、デフォルトのパスワードポリシーが適用されます。
- レプリケーションのために作成したエントリ (サーバーの識別するレプリカマネージャエントリなど) には、無期限のパスワードを設定する必要があります。これらの特別なユーザーに確実に無期限のパスワードを使用させるには、passwordExpirationTime 属性をエントリに追加し、この属性に 20380119031407Z (有効範囲の最大値) を指定します。
アクセス制御の設計アクセス制御では、特定の情報へのアクセス権を一部のクライアントに与え、その他のクライアントには与えないように指定することができます。アクセス制御は、1 つまたは複数のアクセス制御リスト (ACL) を使用して実装します。ACL は、指定したエントリやその属性についてアクセス権限 (読み取り、書き込み、検索、プロキシ承認、追加、削除、比較など) を許可または拒否する一連のアクセス制御命令 (ACI) から構成されます。
ACL を使用すると、次の項目に対する権限を設定できます。
また、特定のユーザー、グループに属するすべてのユーザー、およびディレクトリのすべてのユーザーに対する権限を設定できます。さらに、IP アドレスや DNS 名など、ネットワークの場所に対してアクセス権を定義することもできます。
ここでは、Directory Server のアクセス制御メカニズムについて説明します。説明する内容は次のとおりです。
ACI 形式
ACI は、エントリの属性としてディレクトリ内に格納されます。aci 属性はオペレーショナル属性です。この属性は、そのエントリのオブジェクトクラス用に定義されたものであるかどうかに関わらず、ディレクトリ内のすべてのエントリで使用できます。aci 属性は、Directory Server がクライアントから LDAP 要求を受け取るときに、どのアクセス権が与えられ、どのアクセス権が拒否されるかを判定するために使用されます。aci 属性が ldapsearch 処理で返されるように指定することができます。ACI の形式については、『Directory Server 管理ガイド』の「ACI の構文」を参照してください。
デフォルト ACI
Directory Server をインストールしたときや新しいサフィックスを追加したときは、多数のデフォルト ACI が定義されます。この ACI は、セキュリティ要件に合うように変更できます。デフォルト ACI とそれを変更する方法については、『Directory Server 管理ガイド』の「デフォルト ACI」を参照してください。
権限の設定
ディレクトリに ACI が存在しない場合のデフォルトポリシーは、ユーザーにいかなるアクセス権も与えません。ただし、Directory Manager は例外です。このため、ユーザーがディレクトリにアクセスできるように、いくつかの ACI を設定する必要があります。次に、Directory Server に用意されているアクセス制御のメカニズムについて説明します。ACI の設定については、『Directory Server 管理ガイド』の「コマンド行からの ACI の作成」および「コンソールを使用した ACI の作成」を参照してください。
優先規則
ユーザーがディレクトリエントリに対してどのようなタイプのアクセスを試みた場合でも、Directory Server はディレクトリ内のアクセス制御セットを検査します。アクセスを確定するために、Directory Server は優先規則を適用します。この規則は、2 つの競合する権限が存在する場合、アクセス拒否の権限がアクセス許可の権限よりも常に優先されることを規定しています。
たとえば、ディレクトリのルートレベルで書き込み権限を拒否して、Directory Server にアクセスするすべてのユーザーにこの権限を適用した場合、ユーザーに許可されているほかの権限に関係なく、だれもディレクトリに書き込むことはできません。特定のユーザーに Directory Server への書き込み権限を許可するには、元の書き込み拒否の適用範囲を限定してそのユーザーを除外しておく必要があります。また、ユーザーに対して書き込みを許可する権限を作成し追加しておく必要があります。
アクセスの許可または拒否
ディレクトリツリーへのアクセスは、明示的に許可または拒否できます。Directory Server へのアクセスを明示的に拒否する場合は、慎重に行なってください。優先規則が適用されるため、明示的にアクセスを禁止する規則がディレクトリにある場合、アクセスを許可する権限の有無にかかわらず、アクセスは拒否されることになります。
アクセスを許可する規則の適用範囲を限定して、最低限のユーザーまたはクライアントアプリケーションだけが含まれるようにしてください。たとえば、ユーザーのディレクトリエントリにあるすべての属性への書き込み権限を許可し、ディレクトリ管理者を除くすべてのユーザーに uid 属性への書き込み権限を拒否するように権限を設定できます。あるいは、次の方法で書き込み権限を許可する 2 つのアクセス規則を作成するという方法もあります。
アクセス権だけを作成することにより、明示的な拒否アクセス権を設定する必要はなくなります。
アクセスを拒否する場合
明示的な拒否を設定する必要は、ほとんどありません。ただし、次のような状況では明示的な拒否が有効である場合もあります。
アクセス制御規則の格納場所
アクセス制御規則は、ディレクトリの任意のエントリに置くことができます。多くの場合、管理者は country、organization、organizationalUnit、inetOrgPerson、または group のタイプのエントリにアクセス制御規則を置きます。
ACL の管理を簡単にするために、この規則はできるだけグループ化します。通常、規則はターゲットエントリとそのエントリのすべての子に適用されるため、最下位にある個々のエントリ (ユーザーなど) にアクセス制御規則を分散させるよりも、ディレクトリのルートポイントまたは分岐点にアクセス制御規則を配置すると良いでしょう。
フィルタが適用されたアクセス制御規則の使用
Directory Server の ACI モデルの強力な機能の 1 つに、LDAP 検索フィルタを使用してアクセス制御を設定できるという機能があります。LDAP 検索フィルタでは、定義した条件に一致するすべてのディレクトリエントリへのアクセス権限を設定できます。
たとえば、マーケティングに設定されている organizationalUnit 属性を含むすべてのエントリへの読み取り権限を許可できます。
フィルタが適用されたアクセス制御規則では、事前にアクセスレベルを定義することもできます。たとえば、ディレクトリに自宅の住所と電話番号に関する情報が含まれているとします。これを公開したいと考える人と、リストからの情報の削除を求める人がいます。この情報は、次のように解決できます。
- 各ユーザーのディレクトリエントリに publishHomeContactInfo という属性を作成します。
- publishHomeContactInfo 属性が TRUE (有効を意味する) に設定されているエントリだけに、homePhone と homePostalAddress 属性への読み取り権限を許可するアクセス制御規則を設定します。LDAP 検索フィルタを使用して、この規則のターゲットを示します。
- ディレクトリユーザーが自分の publishHomeContactInfo 属性の値を TRUE または FALSE に変更できるようにします。このようにすると、この情報を公開するかどうかをディレクトリユーザーが決定できます。
ACI との LDAP 検索フィルタの使用については、『Directory Server 管理ガイド』の「LDAP フィルタを使用したエントリまたは属性のターゲット指定」を参照してください。
マクロ ACI の使用
マクロ ACI は、ACI の中で DN、または DN の一部を表すために使用される可変部分です。マクロを使用すると、ACI のターゲット部分またはバインド規則部分、あるいはその両方の DN を表すことができます。Directory Server が LDAP 要求を受け取ると、マクロ ACI が LDAP 操作のターゲットとなるリソースと照合されます。一致した場合、マクロは対象となるリソースの DN の値に置き換えられます。次に Directory Server は ACI を通常どおりに評価します。
サーバーを起動したとき、すべての ACI は、キャッシュの制限を受けることなくメモリに読み込まれます。これは、メモリの消費に大きな影響を与える可能性があります。このため、繰り返しのディレクトリツリー構造を使用する場合は、可能であればマクロ ACI を使用して、Directory Server で使用される ACI の数を最適化してください。
マクロ ACI については、『Directory Server 管理ガイド』の「高度なアクセス制御: マクロ ACI の使用」を参照してください。
実効権限に関する情報の取得
Directory Server が提供するアクセス制御モデルは強力で、さまざまなメカニズムを使用してユーザーにアクセス権を与えることができます。ただし、このような柔軟性が、セキュリティポリシーをかなり複雑にしてしまう要因になることがあります。たとえば、IP アドレスとマシン名、時刻、認証方法など、ユーザーのセキュリティはいくつかのパラメータを使って定義することができます。このため、ディレクトリのエントリと属性に対する特定のユーザーの権限をリスト化しておくと便利です。
Directory Server では、ユーザーが指定したディレクトリのエントリと属性に対して持つ実効権限を要求できます。取得される実効権限情報は、次のものに相当します。
ユーザーが特定のデータに対するアクセス権を持つ、または持たない理由を特定するときは、実効権限の検索を行うときに、ユーザーのパラメータすべてを反映する必要があります。
ここでは、実効権限機能の詳細について説明します。説明する内容は次のとおりです。
実効権限機能について
実効権限機能は、DSRK (Directory Server リソースキット) に含まれる ldapsearch ユーティリティを使用します。照会する権限情報の指定には、特別なオプションを使用します。権限に関する情報は、ldapsearch の結果として返されます。実効権限機能の使用方法については、『Directory Server 管理ガイド』の「実効権限の表示」を参照してください。
実効権限機能に対するアクセス制御
実効権限情報を取得するには、実効権限制御を使用するためのアクセス制御権と、aclRights 属性に対する読み取りアクセス権が必要です。実効権限機能に対する基本的なセキュリティは、この二重のアクセス制御によって得られ、これを必要に応じてさらに調整することができます。プロキシ承認のように、aclRights に対する読み取りアクセス権があれば、エントリと属性に対するどのユーザーの権限に関する情報でも要求することができます。つまり、リソースを管理するユーザーは、だれがそのリソースに対する権限を持つかを決定できます。これは、そのユーザーが実際にはその権限を使って管理していない場合も同様です。
権限情報を照会するユーザーが実効権限制御を使用する権限を持たない場合、操作は失敗し、エラーメッセージが返されます。一方、権限情報を照会するユーザーがこの制御を使用する権限は持つが、aclRights 属性に対する読み取りアクセス権を持たない場合は、返されるエントリから aclRights 属性が省略されるだけです。この動作は、Directory Server の通常の検索動作を反映しています。
実効権限制御に基づく検索操作にプロキシ制御が関わっている場合、実効権限の照会操作はプロキシユーザーとして承認されます。つまり、権限を照会して実効権限制御を使用するのはプロキシユーザーであり、返されるエントリは、そのプロキシユーザーが検索と表示の権限を持つエントリとなります。
実効権限要求の結果
実効権限要求の結果として返される情報には、次のものがあります。
これらの側面のそれぞれについては、『Directory Server 管理ガイド』の「実効権限検索結果の内容」を参照してください。
ACI の使用に関するヒント
次に示すヒントは、ディレクトリのセキュリティモデルを管理する際の負担を軽減し、ディレクトリのパフォーマンス向上にも役立ちます。一部のヒントについてはこの章ですでに説明しましたが、ここでは完全なリストを示します。
オブジェクトの属性の一部でアクセスを許可または制限している場合、その最小の属性リストが、許可される属性セットであるか、拒否される属性セットであるかを判定することを意味します。次に、最小の属性リストを管理するように ACI を表します。
たとえば、ユーザーオブジェクトクラスに多くの属性が含まれている場合を考えます。これらの属性のうち、1 つか 2 つだけをユーザーが更新できるようにする場合、その少数について書き込み権限を許可する ACI を作成します。逆に、1 つか 2 つの属性以外のすべてをユーザーが更新できるようにする場合は、それらの 1 つか 2 つの属性について書き込み権限を拒否する ACI を作成します。
可能な限り、すでに標準ユーザーエントリの一部となっている情報を使用して、アクセス権限を決めてください。特別な属性を作成する必要がある場合は、ロールまたはサービスクラス (CoS) の定義の一部として作成することを検討します。ロールと CoS については、「ディレクトリエントリのグループ化と属性の管理」を参照してください。
ACI の制限事項
アクセス制御ポリシーを決定するときは、次の制限事項に注意してください。
ただし、ターゲットエントリに格納された値と、バインドユーザーのエントリに格納された値のマッチングは可能です (userattr キーワードなどを使用)。ACI を持つサーバー上にバインドユーザーがエントリを持っていない場合も、通常どおりにアクセスに対する評価が行われます。
アクセス制御の評価の連鎖方法については、『Directory Server 管理ガイド』の「連鎖サフィックスのアクセス制御」を参照してください。
- CoS によって作成された属性を、すべての ACI キーワードで使用できるとは限りません。特に、userattr キーワードによって CoS で作成した属性を使用しないでください。アクセス制御規則が機能しなくなります。
- アクセス制御規則の評価は、常にローカルサーバー上で行われます。したがって、ACI キーワードで使用される LDAP URL で、サーバーのホスト名やポート番号を指定する必要はありません。指定しても、LDAP URL は無視されます。LDAP URL の詳細については、『Directory Server Administration Reference』の「LDAP URL Reference」を参照してください。
- サーバーが使用するメモリが利用可能な物理メモリに収めるためのキャッシュ設定は ACI キャッシュには適用されません。つまり、ACI の数が多すぎると、利用可能メモリが不足する可能性があります。
- プロキシ権限を与える場合、ユーザーに Directory Manager となるプロキシ権限を与えたり、Directory Manager にプロキシ権限を与えたりすることはできません。
SSL による接続のセキュリティ保護ユーザーを識別するための認証スキーマと、情報を保護するためのアクセス制御スキーマを設計することに加え、サーバーとクライアントアプリケーションの間のネットワーク上でやり取りされる情報の完全性を保護する必要があります。
ネットワーク上で安全な通信を可能にするために、SSL (Secure Sockets Layer) 上で LDAP プロトコルと、DSML over HTTP の両方を使用することができます。SSL を設定して有効化すると、クライアントはセキュリティ保護された専用ポートに接続します。このポートとの SSL 接続が確立されると、すべての通信内容が暗号化されます。Directory Server は、Start TLS (Start Transport Layer Security) 制御もサポートしています。この制御を使用することで、クライアントは標準の LDAP ポート上での暗号化通信を開始できます。SSL と TLS の概要については、『Administration Server Administration Guide』の「Using SSL and TLS with Sun Java System Servers」を参照してください。
Directory Server は、SSL によるセキュリティ保護された接続と、SSL が適用されていない接続を同時にサポートします。
SSL は暗号化によって機密情報を保護し、チェックサムのハッシュによってデータの完全性を確保します。SSL 接続を確立すると、クライアントアプリケーションと Directory Server は、両者が設定に対して共通して持つ強力な暗号化アルゴリズム (暗号化方式) を選択します。Directory Server で使用できる暗号化方式は、次のとおりです。
暗号化方式は、次のいずれかのハッシュアルゴリズムと組み合わせて使用できます。
セキュリティ保護された接続が確立されると、SSL プロトコルによってサーバーはクライアントに証明書を送信します。公開鍵暗号化方式を使用して、クライアントは、その証明書がクライアントが信頼する認証局によって発行されたものであるかどうかを検証し、証明書の確実性を判断することができます。証明書の検証によって、クライアントは、第三者への成りすましによる介入者攻撃を防止することができます。
また、クライアントからの認証を要求するようにサーバーを設定することもできます。Directory Server は、証明書ベースと SASL ベースのクライアント認証をサポートしています。これらのメカニズムについては、「適切な認証方法の選択」を参照してください。サーバーへのクライアント認証により、クライアントとサーバーとの間の通信が第三者によって傍受または妨害される可能性がなくなり、最大レベルのセキュリティが提供されます。
Directory Server 5.2 は Sun Crypto Accelerator ボードをサポートしています。この機能により、証明書ベースの認証を使用する SSL プロトコル通信のパフォーマンスが向上します。このボードは、SSL キー関連の計算を高速化します。クライアントアプリケーションが SSL 経由のバインド、検索、バインド解除を何度も繰り返す配備で有効な場合があります。キー関連の計算がパフォーマンスのボトルネックとならない場合、SSL アクセラレータボードを使用しても Directory Server のパフォーマンスが向上しない可能性があります。SSL アクセラレータボードがもっとも効果的なのは、クライアントが別のマシンから通信を確立する場合です。システムが SSL ベースの複数の接続を確立する場合、SSL キャッシングセッションによって RSA 操作の数が限定される可能性が高くなります。この場合、アクセラレータボードを利用するメリットも限定されてしまいます。Sun Crypto Accelerator ボードのインストール方法と設定方法については、『Directory Server 管理ガイド』の「Sun Crypto Accelerator ボードの使用」を参照してください。
Directory Server およびクライアントでの SSL の設定と有効化については、『Directory Server 管理ガイド』の「認証と暗号化の管理」を参照してください。
属性の暗号化ここでは、属性暗号化機能について説明します。説明する内容は次のとおりです。
属性暗号化とは
Directory Server では、簡易パスワード認証、証明書ベースの認証、SSL、プロキシ承認など、アクセスレベル (ディレクトリへの読み取りおよび書き込みアクセス時) でデータを保護するためのさまざまな機能が用意されています。しかし、データベースファイル、バックアップファイル、LDIF ファイルに記録されているデータの保護が必要になることも少なくありません。ディレクトリ内に 4 桁の暗証番号を記録している銀行を考えてみてください。保護されていないデータベースファイルにダンプが行われる場合、未認証のユーザーがこの機密情報にアクセスすることも考えられます。属性を暗号化する機能を使用することで、格納されている機密情報にユーザーがアクセスできないように保護できます。
属性暗号化では、どの属性を暗号化形式で格納するかを指定できます。これは、データベースレベルで設定されます。つまり、属性の暗号化を決定すると、データベース内のすべてのエントリでその属性は暗号化されます。属性の暗号化はエントリレベルではなく属性レベルで行われるため、エントリ全体を暗号化するには、すべての属性を暗号化する必要があります。
属性暗号化機能を使用することで、保管中のデータを保護できるだけでなく、データを別のデータベースに暗号化された状態でエクスポートすることができます。ただし、属性を暗号化する目的は、保管中またはエクスポート中の機密データを保護することであり、暗号化は常に可逆的です。このため、検索要求の結果として返された場合は、暗号化された属性は復号化されます。
図 7-1 は、データベースに追加されるユーザーエントリを示しています。ここで設定されている属性暗号化は、salary 属性を暗号化します。
図 7-1 属性暗号化のロジック
属性暗号化の実装
属性暗号化機能は、さまざまな暗号化アルゴリズムをサポートしているため、異なるプラットフォーム間での可搬性が確保されます。追加のセキュリティ対策として、属性暗号化はサーバーの SSL 証明書の非公開鍵を使用して専用の鍵を作成します。この鍵は、暗号化と復号化を行うときに使用されます。つまり、属性を暗号化するには、サーバーが SSL 経由で実行されている必要があります。SSL 証明書とその非公開鍵はデータベース内にセキュリティ保護された状態で格納されており、パスワードによって保護されています。サーバーへの認証では、この鍵データベースのパスワードが必要となります。つまり、この鍵データベースのパスワードにアクセスできるユーザーであれば、だれもが暗号化されたデータのエクスポートを承認されます。
データを暗号化するためにオンラインでインポートする場合、サーバーへの認証に使用される鍵データベースのパスワードはすでに指定されているため、2 回目には要求されなくなります。データをオフラインでインポートする場合、インポートするデータを暗号化するたびに Directory Server はパスワードを要求します。より機密性の高い操作であるデータの復号化では、エクスポートをオンライン、オフラインのどちらで行うかに関係なく、Directory Server は常に鍵データベースのパスワードを要求します。これにより、セキュリティはさらに高まります。
注
証明書または非公開鍵が変更されない限り、サーバーは同じ鍵を生成し続けます。このため、1 つのサーバーインスタンスから別のサーバーインスタンス (両者が同じ証明書を使用する場合) データを転送 (エクスポート後にインポート) することができます。
属性の暗号化とパフォーマンス
属性を暗号化することでデータのセキュリティは向上しますが、パフォーマンスに特定の影響が生じます。どの属性を暗号化するかを決定するときは、これを念頭に慎重に行い、特に機密性が高いと考えられる属性だけを暗号化してください。
インデックスファイルから機密性の高いデータに直接アクセスすることができるので、属性を完全に保護するために、暗号化された属性に対応するインデックスキーを暗号化する必要があります。インデックス付け自体がすでに Directory Server のパフォーマンスに影響しているため (インデックスキーの暗号化による負荷は含まれない)、データをインポートする、またはデータベースに初めて追加する前に属性暗号化を設定してください。こうすることで、暗号化された属性には最初からインデックスが付けられます。
属性暗号化の使用に関する注意点
属性暗号化機能を実装するときは、次の点を考慮してください。
- 一般に、属性暗号化の設定を変更するときは、データをエクスポートし、変更を加えた上で、新たに設定されたデータをインポートする必要があります。
これにより、機能が喪失することなく、すべての設定変更が全体として適用されます。このような方法で行わなかった場合、一部の機能が喪失し、データのセキュリティが危険にさらされる可能性があります。
- 既存のデータベースに対する属性暗号化の設定を変更すると、パフォーマンスに大きく影響することがあります。
たとえば、既存のデータが格納されたデータベースインスタンスについて考えてみましょう。このデータベースには、機密性の高い mySensitiveAttribute という属性を持つエントリが格納されています。この属性の値は、クリアテキストとしてデータベースとインデックスファイルに格納されています。mySensitiveAttribute 属性の暗号化を決定した場合、属性暗号化の設定を適用するためにサーバーがデータベースとインデックスファイルを更新する必要があり、データベースインスタンス内のすべてのデータはエクスポートされ、データベースに再びインポートされます。これにより、パフォーマンスに大きな影響が生じます。これは、この属性を最初から暗号化していた場合には回避できる影響です。
- 復号化された形式でデータをエクスポートするときに、誤ったパスワードを指定するとエクスポートが拒否されます。
セキュリティ対策として、復号化された形式でデータをエクスポートするユーザーに対してサーバーはパスワードを要求します。ユーザーが誤ったパスワードを指定した場合、復号化されたデータのエクスポートは拒否されます。パスワードは、直接入力するだけでなく、SSL パスワードファイルと同じ構文を持つパスワードが記録されたファイルへのパスを指定できます。
- アルゴリズムの変更はサポートされていますが、正しく作成されていない場合、インデックス付け機能は失われる可能性があります。
データの暗号化に使用するアルゴリズムを変更するときに、インデックス付けに関連する機能が喪失しないようにするには、データをエクスポートし、属性暗号化の設定を変更してから、データをインポートし直します。この手順どおりに行わない場合、内部暗号化アルゴリズムに基づいて作成されたインデックスは機能しなくなります。
暗号化された属性の前には、適用された暗号化アルゴリズムを指定する暗号化方式が付けられ、データのインポートはサーバーの内部処理として行われます。このため、Directory Server でアルゴリズムを変更する前にデータを暗号化された形式でエクスポートできるようにすることで、セキュリティがさらに提供されます。
- サーバーの SSL 証明書を変更すると、暗号化されたデータを復号化できなくなります。
属性暗号化機能は、専用鍵の生成にサーバーの SSL 証明書を使用し、暗号化と復号化の実行にはこの専用鍵を使用します。このため、暗号化されたデータを復号するには、この証明書が必要となります。事前にデータを復号化せずにサーバーの SSL 証明書を変更すると、そのデータを復号化できなくなります。これを回避するには、復号化された形式でデータをエクスポートし、証明書を変更してからデータをインポートし直す必要があります。
- 暗号化されたデータを伝送する、つまり、サーバーインスタンス間でエクスポートとインポートを行うには、両方のサーバーインスタンスが同じ証明書を使用する必要があります。
属性暗号化機能の手順については、『Directory Server 管理ガイド』の「属性値の暗号化」を参照してください。
エントリの安全なグループ化ここでは、エントリのグループ化に関するセキュリティ上の問題について説明します。説明する内容は次のとおりです。
ロールの安全な使い方
セキュリティの状況によっては、ロールの使用が適していない場合があります。新しいロールを作成するときは、エントリへのロールの割り当てやエントリからのロールの削除がどの程度簡単にできるかを考慮します。ロールへのユーザーの追加やロールからの削除をユーザー自身が実行できることが望ましい場合もあります。たとえば、Mountain Biking という名前の同好会のロールがある場合は、興味のあるユーザーが自身を簡単に追加または削除できるようにする必要があります。
ただし、セキュリティの状況によっては、このような開放的なロールが適していない場合があります。たとえば、アカウントの無効化に関するロールがあるとします。デフォルトでは、アカウントの無効化に関するロールには、そのサフィックスに対して定義された ACI が含まれています。アカウントの無効化については、『Directory Server 管理ガイド』の「ユーザーとロールの無効化と有効化」を参照してください。サーバー管理者は、ロールを作成するときに、ロールへのユーザーの追加やロールからの削除をユーザー自身が実行できるようにするかどうかを決定します。
たとえば、ユーザー A が、管理されているロール MR を持っているとします。さらに、MR ロールが、コマンド行からアカウントの無効化によってロックされたとします。つまり、ユーザー A の nsAccountLock 属性は「true」として計算されるので、ユーザー A はサーバーにバインドできません。ただし、ユーザーがバインド済みで、MR ロールに関して現在ロックされているという通知を受けたとします。ユーザーの行為を禁止する ACI がない場合は、ユーザーは、自分のエントリから nsRoleDN 属性を削除し、自分でロックを解除できます。
ユーザーが nsRoleDN 属性を削除できないようにするには、ACI を適用する必要があります。フィルタを適用したロールを使用する場合、ユーザーが属性を変更してフィルタが適用されたロールを放棄することを防ぐために、フィルタの一部を保護する必要があります。フィルタを適用したロールで使用される属性の追加、削除、変更をユーザーが実行できないようにし、フィルタの属性値が計算によって決定される場合は、フィルタの属性値に影響する可能性のあるすべての属性も保護する必要があります。入れ子のロールは、フィルタを適用したロールと管理されているロールから構成されることがあるため、入れ子のロールを構成する各ロールについても上記注意点を考慮する必要があります。
CoS の安全な使い方
読み取り用のアクセス制御は、エントリの実際の属性と仮想属性の両方に適用されます。サービスクラスメカニズムによって生成された仮想属性は、通常の属性として読み取ることができるので、読み取り保護も同様の方法で指定します。
ただし、CoS 値をセキュリティで保護するには、定義エントリ、テンプレートエントリ、ターゲットエントリなど、使用するすべての情報のソースを保護する必要があります。これは更新処理でも同様です。情報のソースから生成された値を保護するために、各情報のソースに対する書き込みを制御する必要があります。
次に、各 CoS エントリのデータに読み取りおよび書き込み保護を設定する際の一般的な原則について説明します。個々の ACI (アクセス制御命令) の定義手順については、『Directory Server 管理ガイド』の「アクセス制御の管理」を参照してください。
CoS 定義のエントリの保護
CoS 定義のエントリには、生成された属性の値は含まれません。このエントリは、値を検索するための情報を提供します。CoS 定義のエントリを読み取ると、値を含むテンプレートエントリの検索方法がわかり、このエントリへの書き込みによって、仮想属性の生成方法を変更できます。
したがって、CoS 定義のエントリに読み取りと書き込みの両方のアクセス制御を定義する必要があります。
CoS テンプレートエントリの保護
CoS テンプレートエントリには、生成された CoS 属性の値が含まれます。したがって、少なくともテンプレートの CoS 属性の読み取りと更新を保護する必要があります。
ポインタ CoS の場合は、名前の変更が禁止されているテンプレートエントリが 1 つ存在します。通常、テンプレートエントリ全体を保護するのがもっとも簡単な方法です。
クラシック CoS では、すべてのテンプレートエントリは、定義エントリで指定された共通の親を持ちます。この親エントリにテンプレートを格納するだけで、親エントリに対するアクセス制御によってテンプレートが保護されます。ただし、親の下のほかのエントリにアクセスする場合は、テンプレートエントリを個別に保護する必要があります。
間接 CoS の場合は、アクセスする必要があるユーザーエントリを含む、ディレクトリ内の任意のエントリにテンプレートを指定できます。必要に応じて、ディレクトリ全体の CoS 属性に対するアクセスを制御するか、またはテンプレートとして使用される各エントリの CoS 属性のセキュリティを保護するかを選択できます。
CoS のターゲットエントリの保護
仮想 CoS 属性が生成される、CoS 定義の適用範囲内のすべてのエントリも値の算出に役立ちます。
CoS 属性がターゲットエントリにすでに存在する場合は、デフォルトでは、CoS メカニズムはこの値を上書きしません。この動作を変更する場合は、ターゲットエントリを上書きするように CoS を定義するか、すべてのターゲットエントリで CoS 属性を保護します。手順については、『Directory Server 管理ガイド』の「ID とロールの管理」を参照してください。
間接 CoS とクラシック CoS は、ターゲットエントリの指示子属性に依存します。この属性は、使用するテンプレートエントリの DN または RDN を指定します。この属性を保護する場合は、CoS の適用範囲全体でグローバルに保護するか、または各ターゲットエントリで必要に応じて個別に保護する必要があります。
その他の従属関係の保護
生成されたその他の CoS 属性およびロールに関して仮想 CoS 属性を定義することができます。仮想 CoS 属性を確実に保護するために、これらの従属関係を理解し保護する必要があります。
たとえば、ターゲットエントリの CoS 指示子属性には nsRole を指定できます。したがってロール定義も保護する必要があります。詳細は、「エントリの安全なグループ化」を参照してください。
一般に、仮想属性値の算出に関係する属性またはエントリには、読み取りおよび書き込みアクセス制御を設定します。このため、複雑な従属関係は、十分に計画してから設定するか、以後のアクセス制御の実装の複雑さを軽減できるように簡素化する必要があります。その他の仮想属性との従属関係を最小限に抑えると、ディレクトリのパフォーマンスを向上させ、管理作業を削減することができます。
設定情報のセキュリティ保護ほとんどの配備では、ルート DSE エントリ (長さがゼロの DN が指定されたベースオブジェクト検索で返されるエントリ)、または cn=config、cn=monitor、または cn=schema の下のサブツリーでは、追加のアクセス制御は必要ありません。ルート DSE エントリとこれらのサブツリーには、Directory Server が自動的に生成する属性が含まれ、LDAP クライアントは Directory Server の機能と設定を判断するときにこの属性を使用します。
しかし、namingContexts というルート DSE エントリ属性には、各 Directory Server データベースのベース DN のリストが含まれます。このリストに加え、これらの DN は cn=config および cn=monitor の下のマッピングツリーエントリにも格納されます。セキュリティ上の理由から 1 つまたは複数のサブツリーを非表示に設定して設定情報を保護するには、次のような配置が必要です。
その他のセキュリティ関連資料セキュリティ保護されたディレクトリの設計については、以下の資料を参照してください。
- Sun 開発者向けのセキュリティ関連資料
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/- コンピューター緊急事態対策チーム (CERT) 管理センター
http://www.cert.org/- CERT セキュリティ向上モジュール
http://www.cert.org/security-improvement/
