test

Sun Java System Directory Server Enterprise Edition 6.1 配備計画ガイド

第 7 章 セキュリティー要件の特定

Directory Server Enterprise Edition のデータを保護する方法は、ほかのすべての設計領域に影響します。この章では、セキュリティー要件の分析方法と、その要件を満たすディレクトリサービスの設計方法について説明します。

この章で説明する内容は次のとおりです。

セキュリティーに対する脅威

ディレクトリのセキュリティーを脅かすもっとも典型的な脅威は、次のとおりです。

セキュリティー手法の概要

セキュリティーポリシーは、不正なユーザーによって機密情報が変更または取得されるのを防げる必要がありますが、同時に十分に管理しやすい必要もあります。

Directory Server Enterprise Edition が提供するセキュリティー手法は、次のとおりです。

これらのセキュリティーツールは、ユーザーのセキュリティー設計で組み合わせて使用できます。セキュリティーの設計をサポートするために、レプリケーションやデータの分散など、ほかのディレクトリの機能を使用することもできます。

認証方法の決定

Directory Server Enterprise Edition は、次の認証方法をサポートしています。

ユーザーが人間か LDAP 対応アプリケーションかにかかわらず、すべてのユーザーに対して同じ認証メカニズムが適用されます。

この節には、上記の認証メカニズムのほかに、認証に関する次の情報も含まれています。

匿名アクセス

匿名アクセスは、ディレクトリアクセスのもっとも単純な形態です。匿名アクセスは、ユーザーが認証済みかどうかにかかわらず、すべてのディレクトリユーザーに対してデータを利用可能にします。

匿名アクセスでは、誰が検索を実行しているかや、どのような種類の検索が実行されているかを追跡することができません。追跡できるのは、誰かが検索を実行している、ということだけです。匿名アクセスを許可すると、ディレクトリに接続するユーザーはだれでもデータにアクセスできます。データへの匿名アクセスを許可したまま、あるユーザーやグループをそのデータからブロックしようとしても、そのユーザーは、ディレクトリに匿名でバインドすることでそのデータにアクセスできます。

匿名アクセスの特権は制限できます。通常、ディレクトリ管理者は、匿名アクセスに対して読み取り、検索、および比較の特権だけを許可します。また、ユーザー名、電話番号、電子メールアドレスなど、一般的な情報を含む属性のサブセットにアクセスを限定することもできます。政府識別番号、自宅の電話番号や住所、給与情報など、機密データへの匿名アクセスを許可しないでください。

ルート DSE (ベース DN "") への匿名アクセスは必要です。アプリケーションはルート DSE への匿名アクセスを使用することで、サーバーの機能、サポートされているセキュリティーメカニズム、およびサポートされているサフィックスを確認できます。

単純パスワード認証

匿名アクセスが設定されていない場合、クライアントは、Directory Server への認証を行わないとディレクトリのコンテンツにアクセスできません。単純パスワード認証では、クライアントは再使用可能な簡単なパスワードを提供して、サーバーへの認証を行います。

クライアントはバインド操作を使って Directory Server への認証を行いますが、そのバインド操作でクライアントは識別名と資格情報を提供します。サーバーは、そのクライアント DN に対応するエントリを特定したあと、そのクライアントのパスワードがエントリに格納された値に一致するかどうかをチェックします。パスワードが一致すれば、サーバーはそのクライアントを認証します。パスワードが一致しない場合、認証操作は失敗し、クライアントにエラーメッセージが返されます。

注 –

単純パスワード認証の欠点は、パスワードが平文として送信されることです。その場合、セキュリティーが損なわれる可能性があります。悪意のあるユーザーが盗聴している場合、そのユーザーは承認されたユーザーを偽装できます。

単純パスワード認証を使えば、ユーザーの認証を容易に行えます。ただし、単純パスワード認証を使用するのは、組織のイントラネットに限定する必要があります。この種類の認証では、エクストラネットを介した取引先との転送やインターネット上での顧客との転送に求められるレベルのセキュリティーは提供されません。

セキュリティー保護された接続での単純パスワード認証

セキュリティー保護された接続では、暗号化によって第三者がデータを読めないようにした上で、Directory Server とクライアントの間でデータを送信します。クライアントは、次のいずれかの方法でセキュリティー保護された接続を確立できます。

どちらの場合も、サーバーにはセキュリティー証明書が必要で、この証明書を信頼するようにクライアントを設定する必要があります。サーバーは、証明書をクライアントに送信することで、公開鍵暗号化方式を使用して「サーバー認証」を行います。その結果、クライアントは目的のサーバーに接続していること、およびサーバーが改ざんされていないことを認識します。

次に、機密保護のため、クライアントとサーバーは、接続を介して送信されるすべてのデータを暗号化します。クライアントは、暗号化された接続でバインド DN とパスワードを送信してユーザー認証を受けます。それ以降の操作はすべて、そのユーザーの ID を使って実行されます。バインド DN がほかのユーザー ID のプロキシ権限を持っている場合には、プロキシ ID を使って操作が実行される可能性もあります。操作の結果がクライアントに返されるときは、すべてが暗号化されます。

証明書に基づくクライアント認証

SSL または TLS 上で暗号化接続を確立する場合、「クライアント認証」を要求するようにサーバーを設定することもできます。クライアントは、ユーザー ID の確認のためにサーバーに証明書を送信する必要があります。バインド DN の決定には、ユーザーの DN ではなく、証明書が使用されます。クライアント認証は、ユーザーの偽装を防ぐ保護で、もっとも安全な接続です。

証明書に基づくクライアント認証は、SSL 層と TLS 層のみで動作します。証明書に基づく認証 ID を LDAP で使用するには、SSL 接続の確立後に SASL EXTERNAL 認証を使用する必要があります。

証明書に基づくクライアント認証を設定するには、dsconf get-server-prop コマンドを使用します。詳細については、dsconf(1M) のマニュアルページを参照してください。

SASL ベースのクライアント認証

SSL または TLS 接続時のクライアント認証では、汎用セキュリティーインタフェースの Simple Authentication and Security Layer (SASL) を使ってクライアントの ID を確立することもできます。Directory Server Enterprise Edition が SASL を通じてサポートするメカニズムは、次のとおりです。

詳細については、『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 では、パスワードによる認証失敗が監視およびレプリケートされます。これにより、無効なパスワードによる認証の試みがある指定された回数だけ行われたときに、グローバルアカウントロックアウトを速やかに行えます。グローバルアカウントロックアウトは、次のどの場合でもサポートされています。

すべてのバインド試行が同一のサーバーに向けられず、ロックアウトデータがレプリケートされるよりも早く、クライアントアプリケーションが複数のサーバー上でバインド試行を実行するような状況を想像してください。最悪の場合、クライアントがバインドを試みたサーバーごとに、指定された回数の試みをクライアントに許可することになります。クライアントアプリケーションを駆動する入力を与えるユーザーが人間である場合には、こうした状況はあまり起こりそうにありません。しかし、トポロジを攻撃するために構築された自動化クライアントであれば、この配備選択を悪用することができます。

優先順位付きレプリケーションを使えば、侵入者検出の際に、非同期レプリケーションの遅れによる影響を最小限に抑えることができます。ただし、バインド試行が指定された回数だけ失敗した直後にアカウントロックアウトを行いたい場合もあります。その状況では、ある特定のエントリ上でのすべてのバインドの試みを、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) のマニュアルページを参照してください。

この節は、次の項目で構成されています。

パスワードポリシーのオプション

次のようなパスワードポリシーのオプションがあります。

レプリケーション環境でのパスワードポリシー

デフォルトパスワードポリシーの設定情報はレプリケートされません。代わりに、それはサーバーインスタンスの設定の一部になっています。デフォルトパスワードポリシーを変更すると、トポロジ内のすべてのサーバー上でそれと同じ変更が施されます。レプリケート「される」パスワードポリシーが必要な場合は、レプリケートされるディレクトリツリー内に、特殊なパスワードポリシーを定義する必要があります。

ユーザーエントリに格納されているパスワード情報のすべてがレプリケートされます。この情報には、現在のパスワード、パスワード履歴、パスワードの有効期限などが含まれます。

レプリケートされた環境では、パスワードポリシーによる次の影響を考慮してください。

パスワードポリシーの移行

Directory Server Enterprise Edition のパスワードポリシーの設定は、6.0 より前のバージョンの Directory Server で提供されていたパスワードポリシーの設定とは異なります。異なるバージョンの Directory Server が稼働するサーバーがトポロジ内に含まれている場合には、『Sun Java System Directory Server Enterprise Edition 6.1 Migration Guide』の「New Password Policy」を参照し、パスワードポリシーの設定の移行方法について確認してください。

Windows とのパスワードの同期

Identity Synchronization for Windows は、Directory Server と Windows との間で、パスワードを含むユーザーアカウント情報を同期させます。Windows Active Directory と Windows NT の両方がサポートされています。Identity Synchronization for Windows は、スケーラビリティーの高いセキュリティー機能の豊富なパスワード同期ソリューションを、小規模、中規模、および大規模企業向けに構築する際に役立ちます。

このソリューションが提供する機能は次のとおりです。

配備内での Identity Synchronization for Windows の使用方法の詳細については、『Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide』を参照してください。

暗号化手法の決定

暗号化は、転送中のデータや格納されたデータを保護する際に役立ちます。この節では、次のデータ暗号化手法について説明します。

SSL による接続のセキュリティー保護

セキュリティー設計には、ユーザーを特定するための認証スキーマ方式や、情報を保護するためのアクセス制御方式以外の要素も含まれます。サーバーとクライアントアプリケーションとの間でネットワーク経由で送信される情報の完全性も保護する必要があります。

ネットワーク上で安全な通信を可能にするために、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 属性を暗号化します。

図 7–1 属性暗号化のロジック

図では、データベース内で暗号化された属性が示されています。

属性暗号化の実装

属性の暗号化機能は、広範な暗号化アルゴリズムをサポートしています。異なるプラットフォーム間での移植性が保証されています。属性の暗号化は追加のセキュリティー手段として、サーバーの SSL 証明書の非公開鍵を使って自身の鍵を生成します。その後、この鍵は、暗号化および復号化処理を実行するために使用されます。属性を暗号化できるためには、サーバーが SSL 上で稼働している必要があります。SSL 証明書とその非公開鍵はデータベース内に安全に格納され、パスワードで保護されます。この鍵データベースのパスワードはサーバーへの認証時に必要になります。サーバーは、この鍵データベースのパスワードにアクセスできるユーザーであれば、だれもが復号化されたデータのエクスポートを承認されたものとみなします。

属性の暗号化が保護するのは格納された属性だけである点に注意してください。これらの属性をレプリケートする場合には、転送中の属性を保護できるよう、SSL 上でレプリケーションを設定する必要があります。

属性の暗号化を使用する場合、バイナリコピー機能を使ってあるサーバーから別のサーバーを初期化することはできません。

属性の暗号化とパフォーマンス

属性の暗号化を使えばデータのセキュリティーを高められますが、この機能はパフォーマンスに影響を与えます。属性の暗号化は、機密性の特に高い属性を暗号化するためだけに使用してください。

機密データには、インデックスファイル経由で直接アクセスできます。したがって、暗号化する属性に対応するインデックスキーを暗号化することで、それらの属性が完全に保護されるようにする必要があります。インデックスキーを暗号化することによる追加コストがないとしても、インデックスを作成すること自体がすでにパフォーマンスに影響を及ぼします。したがって、データベースに初めてデータをインポートまたは追加する「前」に、属性の暗号化を設定してください。こうすることで、暗号化された属性には最初からインデックスが付けられます。

ACI によるアクセス制御の設計

アクセス制御では、特定の情報へのアクセス権を一部のクライアントに与え、その他のクライアントには与えないように指定することができます。アクセス制御は、1 つまたは複数のアクセス制御リスト (ACL) を使用して実装します。ACL は、指定されたエントリとその属性へのアクセス権を許可または拒否する一連のアクセス制御命令 (ACI) から構成されます。アクセス権には、読み取り、書き込み、検索、プロキシ、追加、削除、比較、インポート、およびエクスポートを行う機能が含まれます。

ACL を使用すると、次の項目に対する権限を設定できます。

また、特定のユーザー、グループに属するすべてのユーザー、およびディレクトリのすべてのユーザーに対する権限を設定できます。さらに、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」を参照してください。

デフォルト ACI

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」を参照してください。

ACI の適用範囲

Directory Server 6.x には、ACI の適用範囲に対する主な変更が 2 つ含まれています。

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 の使用に関するヒント

次の各ヒントを参考にすれば、ディレクトリのセキュリティーモデルの単純化とパフォーマンスの改善を図れる可能性があります。

接続規則によるアクセス制御の設計

接続規則を使えば、選択されたクライアントが Directory Server への接続を確立するのを防ぐことができます。接続規則の目的は、悪意のあるクライアントや不適切に設計されたクライアントによって引き起こされるサービス拒否攻撃を防ぐことです。そうしたクライアントは Directory Server に接続し、そのサーバーを要求で溢れさせます。

接続規則は TCP レベルで確立されますが、それは「TCP ラッパー」を定義することで行われます。TCP ラッパーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「TCP ラップによるクライアントホストのアクセス制御」を参照してください。

Directory Proxy Server によるアクセス制御の設計

Directory Proxy Server の接続ハンドラは、サーバーに接続を試みるクライアントの分類を可能にするアクセス制御の方法を提供します。この方法では、接続がどのように分類されたかに基づいて、実行可能な操作を制限できます。

この機能を使えば、ある指定された IP アドレスから接続するクライアントだけにアクセスを制限したりすることができます。次の図は、Directory Proxy Server の接続ハンドラを使って特定の IP アドレスからの書き込み操作を拒否する方法を示したものです。

図 7–2 Directory Proxy Server の接続ハンドラのロジック

図には、クライアントへの書き込みアクセスの許可を IP アドレスに基づいて行うために使用される接続ハンドラが示されています。

接続ハンドラの動作

接続ハンドラは、一連の条件と一連のポリシーから構成されます。Directory Proxy Server は、ある接続の起点属性をクラスの条件とマッチングさせることで、その接続のクラスメンバーシップを決定します。接続があるクラスに一致すると、Directory Proxy Server はそのクラスに格納されているポリシーをその接続に適用します。

接続ハンドラの条件には、次の情報を含めることができます。

接続ハンドラには次のポリシーを関連付けることができます。

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 値をセキュリティー保護するには、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 以外のユーザーとして実行することで、悪用によって生じる可能性のあるあらゆる損害を制限できます。さらに、root 以外のユーザーとして実行されるサーバーは、オペレーティングシステムのアクセス制限メカニズムの処理対象となります。

その他のセキュリティー関連資料

セキュリティー保護されたディレクトリの設計については、以下のリソースを参照してください。