Share via

Microsoft SharePoint Portal Server リソースキット

  • [アーティクル]

第 8 章 ‐ セキュリティの計画

トピック

役割に基づくセキュリティの使用
役割に基づいたセキュリティ
SharePoint Portal Server のセキュリティ アーキテクチャ
検索およびドキュメント管理のためのコンテンツのセキュリティ
まとめ

この章では、Microsoft Windows 2000 のセキュリティ機能を Microsoft SharePoint™ Portal Server 2001 で利用する場合の利点について概説します。また、企業ポータルのコンテンツのセキュリティを保護する Windows 2000 セキュリティの機能、および SharePoint Portal Server の役割に基づくセキュリティ モデルについて説明します。この章では、主に Windows 2000 セキュリティについて説明しますが、SharePoint Portal Server では、Microsoft Windows NT Version 4 のドメイン構造を使用できます。また、SharePoint Portal Server のセキュリティ アーキテクチャを公開モデルも含めて説明し、検索時のコンテンツの保護やコンテンツの統合に関する推奨事項も提供します。セキュリティに関連するトピックの詳細については、「付録 B 詳細情報」を参照してください。

分散セキュリティモデルの拡張
SharePoint Portal Server は、Windows 2000 がサポートしている分散セキュリティ モデルを拡張します。役割に基づくセキュリティ機能を使用すると、管理タスクをコンテンツ所有者に分散できるため、コンテンツ管理を単純化できます。SharePoint Portal Server では、アクセス権やアクセス許可を複雑で特殊なシステムで管理するのではなく、ユーザーをタスクに応じた役割に関連付ける方法で管理します。SharePoint Portal Server によって、ドキュメントへのアクセスは、そのドキュメントの状態に基づいて調整されます。役割を使うことで、動的で柔軟なセキュリティ モデルを作成できます。

Windows 2000 と SharePoint Portal Server で利用可能なセキュリティ機能を組み合わせると、強力で柔軟なセキュリティ インフラストラクチャを実現でき、コンテンツ管理者は便利な新機能を利用できます。

従来の NT セキュリティの割り当て
従来の NTFS ファイル システムに基づくサーバーでは、ローカル システムやドメイン内のユーザーのグループを管理者が定義できますが、コンテンツ フォルダにセキュリティ ポリシーを設定するために、これらのメンバシップをカスタマイズすることはできません。この場合、コンテンツ管理者は、次のような対応をするしかありません。

  • ローカル システムまたはドメインの管理者に、必要があるたびにグループ メンバシップを変更してもらう。

  • 数多くのフォルダのそれぞれに、さまざまなアクセス許可設定を指定する。

  • 制限が強すぎる、または弱すぎるセキュリティ ポリシーで妥協する。

SharePoint Portal Server では、コンテンツへのアクセスを制御するための主要な機構である役割を使用することで、この問題を解決します。

役割に基づくセキュリティの使用

コーディネータは、ユーザーまたはグループをフォルダのセキュリティ ポリシーに追加し、"閲覧者"、"作成者"、または "コーディネータ" の 3 つの役割のうちのいずれかに分類することで、コンテンツへのアクセス権を与えることができます。拡張フォルダでは、ユーザーを "承認者"に分類することもできます。SharePoint Portal Server は、フォルダ内のすべてのコンテンツに対するセキュリティを自動的に管理し、各ドキュメントにアクセスするユーザーが適切なレベルのアクセス権を持っているかどうかを確認します。拡張フォルダの場合は、ドキュメントが公開モデルの各種の状態に移行していくたびに、SharePoint Portal Server がセキュリティ設定を更新します。ドキュメントは、チェックイン、チェックアウト、チェックインと承認、というドキュメントの典型的なライフサイクルを経過するため、SharePoint Portal Server は、フォルダに対する役割メンバシップに基づいて、ドキュメント対する適切なレベルのアクセス権をユーザーに与えます。

役割に基づいたセキュリティ

SharePoint Portal Server では、あらかじめ組み込まれている 3 つの役割を使用して、柔軟で安全な方法で、コンテンツへのユーザー アクセスを制御します。特定の役割に関連付けられているアクセス許可を変更することはできませんが、役割は個々のフォルダ レベルで、またはワークスペースの最上位レベルであるワークスペース ノードのレベルで割り当てることができます。また、特定のドキュメントで、1 人または複数のユーザーからのアクセスをすべて拒否することもできます。SharePoint Portal Server は、ユーザーがコンテンツへのアクセスに Web ブラウザ、Web フォルダ、および Microsoft Office のうちのどれを使用している場合でも、役割に基づいたセキュリティを使用して、コンテンツへのアクセスを制御します。

重要 :
SharePoint Portal Server におけるセキュリティ設定は、ドキュメント コンテンツに対するアクセスのみを制限します。Windows 2000 の Everyone グループのメンバは、キーワードやカスタム プロパティなど、ドキュメントに関連したすべてのメタデータを表示できます。そのため、パスワード情報やプログラム コードのような機密にかかわる情報は、ドキュメントのメタデータに含めないようにしてください。

SharePoint Portal Server の役割ベースのセキュリティ モデルを使用すると、コンテンツへのアクセスを簡単にカスタマイズできます。

SharePoint Portal Server の役割の検討

図 8.1 は、SharePoint Portal Server の役割を示しています。

f08xx01

図 8.1: SharePoint Portal Server の役割

SharePoint Portal Server には、次の役割があります。

閲覧者
閲覧者は、ドキュメントを検索し、閲覧できますが、ワークスペースにドキュメントを追加することはできません。既定では、すべてのフォルダ ユーザーに閲覧者の役割が割り当てられます読み取りアクセス権があります。拡張フォルダでは、閲覧者は、フォルダと公開されたドキュメントのみを表示できます。拡張フォルダでは、承認ルーティングとバージョン管理を含め、ドキュメント管理の拡張機能が提供されます。閲覧者は、ドキュメントのチェックアウト、編集、および削除を行うことはできず、下書きドキュメントは表示できません。

既定では、ワークスペースの作成時に、そのワークスペースのすべてのフォルダに対する閲覧者役割に Windows 2000 の Everyone グループが割り当てられます。

作成者
作成者は、フォルダへの新規ドキュメントの追加、フォルダ内のすべてのドキュメントの編集、フォルダ内のドキュメントおよびサブフォルダの削除、およびフォルダ内のすべてのドキュメントの閲覧を行うことができます。また、フォルダ自体を削除することもできます。拡張フォルダでは、公開するドキュメントの投稿投稿提出もできます。

作成者は、フォルダの作成、名前変更、および削除を行うことができます。新しいフォルダを作成すると、作成されたフォルダは、親フォルダから役割やフォルダ ポリシーなどのセキュリティ設定を継承します。ただし、作成者は、作成したフォルダの役割と承認ポリシーは変更できません。

コーディネータ
ワークスペース コーディネータは、最上位レベルのフォルダ内のコンテンツを管理し、ワークスペース全体に関係する一連の管理タスクを実施します。管理タスクには、コンテンツ ソース、ドキュメント プロファイル、カテゴリ、ディスカッション、および購読の各管理と、ダッシュボード サイトのカスタマイズが含まれます。コーディネータは、更新されたコンテンツのインデックスを必要に応じて作成したり、自動的に作成されるようにスケジュールを設定したります。

フォルダの担当コーディネータは、ユーザーにそのフォルダでの役割を割り当てます。サブフォルダを作成したり、フォルダのドキュメントの追加、編集、および削除を行います。また、作成済みのまだチェックインされていないドキュメントの閲覧と削除ができます。拡張フォルダでは、適切な承認プロセスを選択します。さらに、コーディネータは、ドキュメントのチェックアウトの取り消しや、[公開のキャンセル] または [承認の省略] を使用した公開プロセスの終了も行うことができます。

メモ :
SharePoint Portal Server は、ワークスペースを作成した管理者を、ワークスペースの最上位レベルおよび各フォルダのコーディネータの役割に自動的に割り当てます。

SharePoint Portal Server では、ドキュメントについてのみ、[アクセスを拒否] セキュリティ オプションを提供しています。この設定は、ローカル Administrators グループのアクセス許可以外のすべてのアクセス許可よりも優先されます。特定のユーザーまたはグループにドキュメントを閲覧させたくない場合は、そのユーザーまたはグループに対してアクセスを拒否できます。ドキュメントへのアクセスを拒否すると、そのドキュメントは、拒否されたユーザーまたはグループからは見えなくなります。該当ドキュメントは、ドキュメントのリストにも検索結果にも表示されなくなります。ドキュメントに対するアクセスを拒否しても、そのドキュメントに対するローカル Administrators グループのアクセス権には影響しません。

ワークスペース管理機能をサポートしているフォルダとして、管理、Portal、System、SHADOW、およびカテゴリと、そのサブフォルダがあります。これらのフォルダを管理するには、ワークスペースの最上位レベルのコーディネータである必要があります。これらのフォルダに対するセキュリティを、直接設定することはできません。管理フォルダを除き、ワークスペースのユーザーには、これらのフォルダは通常見えません。

Windows 2000 のローカル Administrators グループには、ワークスペース内のドキュメントに対する読み取りアクセス権があり、ワークスペース内のすべてのフォルダとドキュメントに対してセキュリティを設定できる権限があります。このため、任意のフォルダやドキュメントにアクセスし、偶然に (または悪意を持って) アクセス許可設定を変更して、ユーザーがそれらのフォルダやドキュメントを利用できなくしてしまうおそれがあります。ローカル Administrators グループは、個々のフォルダのアクセス許可を元に戻すことができます。ドキュメントへのアクセスを拒否しても、そのドキュメントに対するローカル Administrators グループのアクセス権には影響しません。

重要 :
SharePoint Portal Server をドメイン コントローラにインストールする場合、そのコンピュータにはローカル Administrators グループが存在しません。したがって、コーディネータの役割が割り当てられているユーザーのみが、フォルダに対するセキュリティを設定できます。コーディネータが作業に失敗しても、セキュリティ問題を解決できるローカル管理者はいません。

例
あるアウトドア スポーツ用品会社の社員であるスーザンが、勤務先の支社のサーバーを管理しているとします。このサーバーは、そのオフィスのワークスペースを格納しているだけでなく、ドメイン コントローラとしても機能しています。

サーバー管理者のスーザンは、支社のワークスペースにある Finance フォルダのコーディネータにポールを任命します。ポールはコーディネータとして、このフォルダのほかの役割を設定し、コーディネータのリストからスーザンを削除しました。数か月後、ポールが会社を辞めました。スーザンは既にコーディネータではなく、ドメイン コントローラにはローカル Administrators グループがないため、スーザンには Finance フォルダへのアクセス権がなく、Finance フォルダに新しいコーディネータを追加するためにセキュリティを変更することもできません。

メモ :
SharePoint Portal Server をドメイン コントローラにインストールする場合は、慎重に計画することをお勧めします。上の例のようなセキュリティ ロックアウトを防止するために、セキュリティ設定に関する特別な規則を決めておくと、役に立ちます。

コンテンツへのアクセスの管理

SharePoint Portal Server には、ユーザーがドキュメントにいつどのようにアクセスできるかを定義できる、さまざまな機能があります。ドキュメントを管理しやすくするために、次のような機能を提供しています。

  • ドキュメントの改版履歴を記録するバージョン管理

  • ドキュメントを特定するための、検索可能な説明情報の適用

  • ドキュメントの公開制御

  • ドキュメントのレビューを行う人校閲者への自動ルーティング

バージョン履歴
SharePoint Portal Server では、ドキュメントの変更作業を管理し、変更内容が別のユーザーによって上書きされないようにするために、ドキュメントの履歴を記録します。ドキュメントを編集するには、まず、ドキュメントをチェックアウトする必要があります。チェックアウトすることで、ドキュメントをチェックインするまでは、ほかのユーザーがそのドキュメントを変更できないようにすることができます。

メモ :
ドキュメントをチェックアウトするには、作成者またはコーディネータの役割に割り当てられている必要があります。

ドキュメントをチェックインするたびに、SharePoint Portal Server は、新しいバージョン番号をドキュメントに割り当て、前のバージョンを保存します。ドキュメントをチェックアウトする場合は、古いバージョンを選択しない限り、最新版が取得されます。

ドキュメントプロファイル
ドキュメント プロファイルを使うと、ドキュメントに付随する検索可能な情報 (メタデータ) を追加できます。この情報は、ドキュメントをわかりやすく説明し、より正確に識別するために役立ちます。既定では、プロファイルには作成者やタイトルなどの基本的なプロパティが含まれます。コーディネータは、組織内のドキュメントの整理や検索を行いやすくするために、顧客番号やプロジェクト マネージャ名などのカスタム プロパティを簡単に追加できます。

メモ :
SharePoint Portal Server におけるセキュリティ設定は、ドキュメント コンテンツに対するアクセスのみを制限します。Windows 2000 の Everyone グループのメンバは、ドキュメントに関連付けられているすべてのメタデータ (キーワードや、その他のカスタム プロパティ) を表示できます。このため、パスワード情報やプログラム コードなどの機密にかかわる情報は、ドキュメントのメタデータに含めないようにしてください。

ドキュメントの公開
SharePoint Portal Server では、ドキュメントの "非公開用" と "公開用" の両方のバージョンをサポートします。公開されたドキュメントは、ダッシュボード サイトでユーザーが検索したり表示したりすることができます。作成者またはコーディネータであれば、ドキュメントをサーバーに保存するたびに自動的に公開することができます。また、下書きの状態のドキュメントを非公開で保持しておき、ドキュメントが完成してから公開するようにすることもできます。ドキュメントのいずれかのバージョンを公開する前であれば、必要な数だけ、下書きを作成することができます。

承認ルーティング
コーディネータは、承認ルーティングを設定することによって、ドキュメントの公開前の確認作業が確実に行われるようにすることができます。作成者がドキュメントを公開することにしたときに、そのドキュメントを自動的にルーティングして、公開前に 1 人または複数の人がドキュメントを確認するように設定できます。ドキュメントを確認する人 (承認者) は、ドキュメントを承認することも拒否することもできます。承認者は、ドキュメントの確認が必要なときに、電子メールで通知を受け取ります。

SharePoint Portal Server のセキュリティ アーキテクチャ

SharePoint Portal Server は、Windows 2000 にある従来の Windows NT セキュリティ モデルを拡張します。ここでは、SharePoint Portal Server セキュリティ アーキテクチャに関連する Windows 2000 のセキュリティ概念について説明します。

Windows 2000 は、以前のバージョンである Windows NT、Windows 95、および Windows 98 との完全な下位互換性を備えていますが、Windows 2000 では Kerberos 5 プロトコルを導入することで、セキュリティ モデルをかなり強化しています。Windows 2000 のセキュリティは、以前のバージョンの Windows よりも使いやすく、分散アプリケーションのサポートも強化されています。これらの変更により、以前の Windows NT バージョンと比較して、スケーラビリティが向上し、管理が容易になっています。拡張された機能の多くは、Microsoft Active Directory™ ディレクトリ サービスを直接サポートしています。SharePoint Portal Server は、管理プロセスをさらに単純化することで、ユーザーに高度な利便性を提供しています。

アクセス制御リストの使用

Windows 2000 セキュリティでは、アクセス制御リスト (ACL) を使用して、リソースへのアクセスを制御します。Windows NT は、NTFS パーティションにあるすべてのファイルとフォルダの ACL を保存します。ACL には、ファイルやフォルダへのアクセスを認められているすべてのユーザー アカウント、グループ、およびコンピュータのリストと、それらに認められているアクセスの種類が含まれています。ユーザーがファイルやフォルダにアクセスするには、ユーザーが属するユーザー アカウント、グループ、またはコンピュータのアクセス制御エントリ (ACE) が ACL に含まれている必要があります。また、このエントリに対して、ユーザーが要求しているアクセス権の種類が明確に許可されている必要があります。

ACL が存在しない場合、Windows 2000 では、すべてのユーザーに読み取りアクセス権が許可されます。ACL に ACE が存在しない場合は、リソースへのユーザー アクセスが拒否されます。空の ACL を適用すると、すべてのユーザーに対してアクセスが拒否されます。1 人のユーザーに対して複数の ACE が存在する場合は、最初のエントリが適用されます。このため、最初に個々のユーザーにアクセス許可を与え、その後、グループにアクセス許可を与えることをお勧めします。こうすることにより、ユーザーが属するグループのアクセス許可よりも優先される適切なアクセス許可を、ユーザーに確実に与えることができます。

図 8.2 は、ACL に基づいてアクセス権が与えられるしくみを示しています。

f08xx02

図 8.2: アクセス制御リスト

この図で、User2 には ACE がありません。このため、User2 には、NTFS パーティション上にあるリソースへのアクセス権は与えられていません。

SharePoint Portal Server では、コンテンツへの安全で適切なアクセスを確保するために、ACL を広範に利用してします。

Windows 2000 セキュリティの特徴

Windows 2000 の分散セキュリティ サービスは、安全でスケーラブルな分散アプリケーション構築のための柔軟なソリューションです。セキュリティ管理作業用に、権限の委任や詳細なアカウント制御を行うための豊富な機能が用意されています。Active Directory は、より多数のアカウントを組織構造に対応した名前付け規則で管理できるドメインをサポートしています。ドメイン間の信頼の管理は簡素化され、企業のニーズに合わせてドメインを柔軟に利用できるようになりました。SharePoint Portal Server は、Active Directory 環境で使用できます。

ネットワーク認証、データのプライバシ保護、デジタル署名、および暗号関連の Windows セキュリティ API を使用すると、企業内用およびインターネット用の安全なアプリケーションを開発できます。Microsoft SSPI (Security Support Provider Interface) と CryptoAPI インターフェイス、およびハイレベルなコンポーネント オブジェクト モデル (COM) と分散 COM (DCOM) のインターフェイス抽象化によって、Windows 2000 の統合セキュリティ機能のすべてが SharePoint Portal Server で使用できます。SharePoint Portal Server は、Windows NT の堅牢なセキュリティ アーキテクチャをシステム コンポーネント全般にわたって一貫して使用し、強力な認証機能と公開キー セキュリティをサポートしています。

Windows 2000 の分散セキュリティは、既に一般的になっている認証用のインターネット標準を統合し、同時に今後の動向と現時点で存在している標準を基にした新しい公開キー セキュリティ技術を導入しています。インターネットの公開キー セキュリティ標準の多くは、まだ作成過程にあります。Microsoft は、これらの標準の開発にも参加していますが、標準は時間と共に変化するものであることも認識しています。Windows 2000 セキュリティ アーキテクチャは、プロトコル、暗号技術サービス プロバイダ、サードパーティの認証技術などの形式で新しいセキュリティ技術を取り入れるように、特別に設計されています。Windows 2000 を配置するユーザーは、どのセキュリティ技術を使うか、どのようにして最小限の影響でアプリケーション環境にセキュリティ機能を統合するか、どの時点で新技術に移行するか、などを自由に決定できます。

以上のような理由で、Windows 2000 の分散セキュリティ サービスは、安全なインターネット分散型コンピューティングの最高の基盤となっています。SharePoint Portal Server での安全なインターネット分散型コンピューティングの最新情報については、「第 12 章 ‐ Deploying SharePoint Portal Server in an Extranet Environment」を参照してください。

Windows 2000 の認証方式の使用

SharePoint Portal Server では、ユーザーのセキュリティ識別子 (SID) に基づく適切なアクセス トークンを受け取ることで、さまざまな種類の認証をすべて使用できます。ただし、SharePoint Portal Server では機能しない認証機関 (CA) が使用される場合もあります。SharePoint Portal Server のセキュリティは、SID を使用します。有効な SID を持たないユーザーは、SharePoint Portal Server のコンテンツにアクセスできません。

SharePoint Portal Server では、ワークスペースへのアクセスが、有効な Windows NT のユーザーおよびグループ (ドメイン ユーザーまたはローカル サーバー ユーザー) に制限されます。SharePoint Portal Server を Windows NT ドメインに配置していて、ユーザーがこのドメインにログインすると、SharePoint Portal Server は認証にドメイン セキュリティ サービスを使用します。これにより、ユーザーのシングル ログオンが可能になります。SharePoint Portal Server を非 Windows NT ドメインに配置した場合は、SharePoint Portal Server がユーザー名とパスワードを取得し、認証します。この処理は、SharePoint Portal Server を実行しているサーバーで維持されているアカウントに基づく基本認証を使用して行われます。

メモ :
基本認証では、Windows 2000 はユーザー アカウントとパスワードをクリア テキストとして送信します。

ユーザーから SID を受け取るには、そのユーザーに Windows NT アカウントを割り当てる必要があります。SharePoint Portal Server では、SID を使用して役割を割り当てます。ユーザーには、コンテンツにアクセスできる役割を割り当てる必要があります。匿名アクセス用に、Windows 2000 セキュリティには、ACL で使用するための特別な SID が用意されています。そのため、匿名ユーザーを役割に割り当てることができます。

重要 :
ドキュメント ライブラリへの匿名アクセスを有効にしている場合、SharePoint Portal Server は、既定ですべてのユーザーに匿名アクセスを許可します。匿名閲覧者がドキュメント ライブラリにアクセスできるようにする場合は、そのようなアクセス用の別の仮想サーバーを作成することをお勧めします。

別の仮想サーバーを作成する方法の詳細については、「第 12 章 ?Deploying SharePoint Portal Server in an Extranet Environment?」を参照してください。

Windows 2000 は、ユーザーがシングル サインオンに成功した後は、そのユーザーのネットワーク セキュリティ資格情報を透過的に管理します。ユーザーは、ネットワーク サーバーへの接続に NTLM (NT LAN Manager)、Kerberos プロトコル、および公開キー ベースのセキュリティ プロトコルのいずれが使用されているのかを意識する必要がありません。ユーザーは、システムにサインオンするだけで、各種のネットワーク サービスへのアクセスが可能になります。

企業内でのリソースへのアクセスは、ユーザーのアカウントに認められている権限、またはグループ メンバシップに基づいて許可されます。インターネット経由の場合は、秘密キー署名操作およびそれに対応する公開キー証明書によって証明された資格に基づいて許可されます。すべてのセキュリティ プロトコルは、なんらかの形式のユーザー資格情報に依存しており、この情報は接続確立時にクライアント コンピュータからサーバーに提示されます。Windows 2000 はこれらのユーザー資格情報を管理し、使用されるセキュリティ プロトコルに合わせて適切な資格情報を使用します。

Windows 2000 Active Directory サービスは、ユーザー アカウント情報のセキュリティ部分で、複数のセキュリティ資格情報をサポートします。Windows 2000 は、オンラインのユーザー認証にドメイン コントローラを使用する企業内認証サービスに、これらの資格情報を使用します。高機能のアプリケーション サーバーでは、ネットワーク認証にセキュリティ サービス プロバイダ インターフェイスを使用することにより、統合された Windows 2000 認証に対応できます。

Windows 2000 セキュリティ グループの範囲の検討

グループの範囲によって、グループを複数のドメインにわたって使用できるかどうかが決まります。グループの範囲は、グループのメンバシップとグループのネスト化に影響します。ネスト化とは、あるグループをほかのグループのメンバとして追加することです。Windows 2000 のグループの範囲には、グローバル、ドメイン ローカル、およびユニバーサルの 3 つがあります。

グローバルグループ範囲
このグループ範囲は、ネットワーク アクセス要件が似通っているユーザーをまとめて組織化するときに使います。グローバル グループを使用すると、どのドメインにあるリソースに対してもアクセス許可を与えることができます。

  • グローバル グループには、メンバシップの制限があります。グローバル グループに追加できるのは、そのグループを作成したドメインのユーザー アカウントとグローバル グループだけです。

  • グローバル グループは、ほかのグループ内にネストできます。このネスト機能を使用すると、グローバル グループを同じドメイン内の別のグローバル グループに追加したり、ほかのドメイン内のユニバーサル グループやドメイン ローカル グループに追加したりすることができます。

ドメインローカルグループ範囲
このグループ範囲は、このグループを作成したのと同じドメイン内にあるドメイン リソースへのアクセス許可を与えるときに使います。リソースは、ドメイン コントローラ上に存在する必要はありません。

  • ドメイン ローカル グループには、メンバシップの制限がありません。任意のドメインのユーザー アカウント、ユニバーサル グループ、およびグローバル グループを追加できます。

  • ドメイン ローカル グループは、ほかのグループ内にネストすることはできません。したがって、ドメイン ローカル グループは、同じドメイン内のグループにも追加できません。

ユニバーサルグループ範囲
複数のドメイン内の、関連性があるリソースへのアクセス許可を与えることができます。ユニバーサル グループを使用すると、どのドメインにあるリソースに対してもアクセス許可を与えることができます。

  • ユニバーサル グループには、メンバシップの制限がありません。すべてのドメイン ユーザー アカウントとグループがメンバになれます。

  • ユニバーサル グループは、ほかのドメインのグループ内にネストできます。この機能を使用すると、任意のドメインのドメイン ローカル グループまたはユニバーサル グループに、ユニバーサル グループを追加できます。

重要 :
ユニバーサル グループ範囲のセキュリティ グループは、ドメインがネイティブ モードである場合に限り利用できます。ネイティブ モードとは、すべてのドメイン コントローラが Windows 2000 を実行している場合のことです。

また、ローカル グループは、Windows 2000 Professional を実行しているコンピュータおよびメンバ サーバー上でのみ作成できます。ローカル コンピュータ上のリソースだけにアクセス許可を割り当てるときに使用します。ローカル グループのメンバシップには、次の規則があります。

  • ローカル グループには、そのローカル グループを作成したコンピュータのローカル ユーザー アカウントのみを含めることができます。

  • ローカル グループは、ほかのグループのメンバになることができません。

ローカル グループの使用に関するガイドラインを次に示します。

  • ローカル グループは、ドメインに属していないコンピュータ上でのみ定義します。

    ローカル グループは、そのローカル グループを作成したコンピュータ上でのみ使用できます。ローカル グループをドメインのクライアント コンピュータやメンバ サーバー上にセットアップすることもできますが、お勧めできません。ドメイン コンピュータ上のローカル グループを使用すると、グループの集中管理ができなくなります。ローカル グループは Active Directory サービスには表示されないため、各コンピュータで個別にローカル グループを管理しなければならなくなります。

  • ローカル グループは、ローカル コンピュータ上のリソースへのアクセスを制御するため、およびローカル コンピュータに対するシステム タスクを実行するために使用します。

SharePoint Portal Server がコンテンツをクロールできるようにするには、コンテンツを保護するためのグループ化方法とドメイン構造を慎重に計画する必要があります。

重要 :
SharePoint Portal Server では、フォルダに対する役割に関連付けられる SID 数が、最大 200 までに制限されます。したがって、大規模な配置では、コンテンツへの適切なユーザー アクセス権を与えるために、戦略的なグループ化計画が必要になります。

Windows 2000 でのセキュリティ グループの使用

図 8.3 は、ユーザーにリソースへのアクセス許可を与える場合の推奨される方法を示しています。

f08xx03

図 8.3: 単一ドメインでのグループ化方法

単一ドメインでグループを使用する場合は、"AGDLP" 手法を使用します。AGDLP 手法では、ユーザー アカウント (A) をグローバル グループ (G) に入れ、グローバル グループをドメイン ローカル グループ (DL) に入れます。次に、アクセス許可 (P) をドメイン ローカル グループに与えます。

グループを作成する場合、Windows 2000 では次の作成方法が推奨されます。

  • 共通の職務のユーザーを特定し、それらのユーザー アカウントをグローバル グループに追加します。たとえば、販売部門では、この部門で同じリソースを使用するすべての社員のユーザー アカウントを Sales というグローバル グループに追加します。

  • 組み込みドメイン ローカル グループを使用できるのか、それとも新しいドメイン ローカル グループを作成してユーザーにドメイン リソースへのアクセス許可を与えるのかを判断します。たとえば、ドメイン内の共有カラー プリンタでユーザーが印刷できるようにするには、Color Printer Users というドメイン ローカル グループを作成します。

  • 必要なアクセス許可が共通するすべてのグローバル グループを、適切なドメイン ローカル グループのメンバにします。たとえば、適切なグローバル グループ (Sales など) を、ドメイン ローカル グループ Color Printer Users に追加します。

  • ドメイン コントローラ上のドメイン ローカル グループに必要なアクセス許可を承認します。アクセス許可を与える作業は、リソース側で行います。たとえば、カラー プリンタを使用するために必要なアクセス許可を Color Printer Users ドメイン ローカル グループに与えます。

メモ :
複数のドメインに類似したグループがある場合は、名前も同じパターンにし、どのドメインのグループであるかがわかるようにしておきます。たとえば、各ドメインに管理者用のグループがある場合は、各グループを同じ名前付け規則で命名するようにします (例 : "Managers USA"、"Managers Australia")。

Windows 2000 では、特定のユーザーやグループが特定のリソースに対して持つアクセス権の種類をカスタマイズできます。また、リソースが親リソースからアクセス権を継承する方法もカスタマイズできます。このように、非常に柔軟な制御が可能ですが、セキュリティ構成が複雑になってしまう場合もあります。

重要 :
SharePoint Portal Server は、リモート コンテンツ リソースの検索をセキュリティで保護するため、検索結果には、ユーザーに表示とアクセスが実際に許可されているドキュメントのみが含まれます。この機能を実現するには、SharePoint Portal Server を実行しているコンピュータが、アクセス許可に使用される ACE を解決できる必要があります。

リモートの NTFS ファイル共有に格納されているドキュメントへのアクセス許可を、ローカル グループを使って与えている場合、SharePoint Portal Server は、ローカル グループの ACE を解決できません。したがって、これらのファイル共有のドキュメントは、検索結果に含まれません。このようなコンテンツへのアクセスを許可するには、ドメイン ローカル グループやグローバル グループなどの別の機構を通してアクセス許可を与える必要があります。

リモートの NTFS ファイル共有にあるコンテンツは、利用可能な別のグループ化手法を使って保護する必要があります。

SharePoint Portal Server へのセキュリティ グループの適用

SharePoint Portal Server では、管理作業を単純化するために、ユーザーとグループをタスクに応じて特定の役割に割り当てられます。この方法であれば、コンテンツ所有者は、より柔軟に対応できます。状況に応じて、自然な構成の大規模なグループを使用することができます。いくつかのグループは、役割に割り当てるのに適しています。たとえば、Windows 2000 の Users グループは、作成者の役割に割り当てることができます。セキュリティ モデルによって異なりますが、コーディネータの役割には、より小規模のグローバル グループを割り当てます。

拡張フォルダでは、SharePoint Portal Server が、ドキュメントの状態に応じてユーザーのアクセス権を自動的に変更します。

単一ドメインのセキュリティグループ
SharePoint Portal Server を単一ドメイン内に配置する場合は、ドメインがネイティブ モードであっても混在モードであっても、AGDLP 手法を適用できます。

この場合は、ユーザー アカウント (A) をグローバル グループ (G) に入れ、グローバル グループをドメイン ローカル グループ (DL) に入れ、このドメイン ローカル グループにアクセス許可 (P) を与えます。

複数ドメインのセキュリティグループ
SharePoint Portal Server をネイティブ モード環境の複数のドメインにわたって配置する場合、グループ化手法としてユニバーサル グループを使用すると、コンテンツを安全に保護できます。ユーザー アカウント (A) をユニバーサル グループ (U) に入れ、ユニバーサル グループをドメイン ローカル グループ (DL) に入れ、このドメイン ローカル グループにアクセス許可 (P) を与えます。

SharePoint Portal Server を混在モード環境の複数のドメインにわたって配置する場合は、ドメイン間に適切な信頼関係を確立する必要があります。SharePoint Portal Server がほかのドメインのコンテンツにアクセスできるようにするには、SharePoint Portal Server を配置したドメインをほかのドメインが信頼する、一方向の信頼を確立します。さらに、グループ メンバシップを変更して、SharePoint Portal Server が使用するアカウントを追加します。

メモ :
このようにすると、SharePoint Portal Server は別のドメイン上のコンテンツを正常にクロールします。しかし、そのドメインのユーザーは、SharePoint Portal Server 上のコンテンツに対して、制限されたアクセス権しか与えられません。これらのユーザーに別のレベルのアクセス権を与えるには、双方向の信頼を確立する必要があります。

例
たとえば、Domain A に Server A があり、Domain B の Server B 上のコンテンツをクロールするとします。Server B は、もう 1 つの SharePoint Portal Server コンピュータ、Web サーバー、およびファイル共有のうちのいずれかです。

  • ネイティブ モード環境では、ユニバーサル グループを使用すると、どちらのドメインにあるリソースにもアクセス許可を与えることができます。これにより、管理プロセスが大幅に単純化されます。

    この場合、Server A は Server B のコンテンツをクロールでき、ユニバーサル グループのメンバである Domain A のユーザーは、それを利用できます。

  • 混在モード環境では、Domain B が Domain A を信頼する、一方向の信頼を確立することができます。

    この場合、Server A は Server B のコンテンツをクロールでき、セキュリティ グループに割り当てられている Domain A のユーザーは、それを利用できます。

Windows NT 4 環境での信頼関係の確立の詳細については、「付録 B 詳細情報」を参照してください。

SharePoint Portal Server では、ドキュメントへのアクセスを制御するための重要な新しい機能が用意されています。たとえば、ドキュメントの承認を構造化する State Machine があります。State Machine でイベントが発生すると、それに対応してオブジェクトが状態を変更し、オブジェクトの新しい履歴を反映します。SharePoint Portal Server は、従来の Windows NT セキュリティ モデルに基づいて構築された、複雑で拡張可能なアクセス許可システムを使用します。また、公開モデルとは競合しない方法で、操作に対するアクセスを制御する機能も提供します。

役割の状態と操作

次の表は、ドキュメントの状態とユーザーの操作、および各状態で役割がどの操作を実行できるかを示しています。使用できる役割は、次のとおりです。

  • ロックホルダ : ドキュメントを最後にチェックアウトした人

  • 提出者 : 承認を得るためにドキュメントを提出した人

  • 閲覧者 : ドキュメントを見る人

  • 作成者 : ドキュメントを作成、または変更する人

  • 承認者 : ドキュメントの現在の承認者 (承認者役割のすべてのメンバではなく)

  • コーディネータ : フォルダまたはドキュメントのセキュリティを設定する人

メモ :
これらの役割は、ユーザー インターフェイスで明示されることはありませんが、ドキュメントが公開モデルの各種の状態を移行していく際に、SharePoint Portal Server がどのようにアクセス権を変更するかを表しています。ユーザー側からは、SharePoint Portal Server には閲覧者、作成者、およびコーディネータの 3 つの役割があるように見えます。また、ワークスペース内のフォルダに対して、承認者のリストを指定することもできます。

次の表は、公開モデルにおけるドキュメントの各状態、実行できる操作、およびその操作を実行するためのフォルダに対するアクセス権を持つ役割を示したものです。

役割の状態と操作

状態/操作

作成済み/チェックアウト済み

チェックイン済み

チェックアウト済み

承認中

承認済み

上書き保存

 

 

ロック ホルダ

 

 

チェックイン

最初の作成者

 

ロック ホルダ

 

 

チェックアウト

 

作成者、コーディネータ

 

 

作成者、コーディネータ

チェックアウトの取り消し

 

 

ロック ホルダ、コーディネータ

 

 

提出

 

作成者、コーディネータ

 

 

 

承認

 

 

 

承認者

 

拒否

 

 

 

承認者

 

承認の省略

 

 

 

コーディネータ

 

承認のキャンセル

 

 

 

提出者、コーディネータ

 

移動

最初の作成者、コーディネータ

作成者、コーディネータ

ロック ホルダ

 

作成者、コーディネータ

コピー

最初の作成者、コーディネータ

閲覧者、作成者、承認者、コーディネータ

閲覧者、作成者、承認者、コーディネータ

閲覧者、作成者、承認者、コーディネータ

閲覧者、作成者、承認者、コーディネータ

削除

最初の作成者、コーディネータ

作成者、コーディネータ

ロック ホルダ

 

作成者、コーディネータ

下書きの閲覧

最初の作成者、コーディネータ

作成者、コーディネータ

作成者、コーディネータ

作成者、承認者、コーディネータ

作成者、承認者、コーディネータ

承認済みの閲覧

 

閲覧者、作成者、コーディネータ

閲覧者、作成者、コーディネータ

閲覧者、作成者、承認者、コーディネータ

作成者、コーディネータ

公開モデルの定義

図 8.4 は、SharePoint Portal Server の単純な公開モデルを示しています。また、ドキュメントが公開済みの状態から新たな公開済みのバージョンに至るまでの過程を示しています。

f08xx04

図 8.4: 公開モデル

この図では、作成者がドキュメントの未承認の最新バージョン (作業用コピー) で作業している間、閲覧者と承認者は承認済みの最新バージョン (1.0) を見ることになります。現在の作成者は、ドキュメントをチェックアウトしたユーザーとしてロック ホルダとなり、ドキュメントの作業用コピーを所有しています。現在の作成者がドキュメントをチェックインすると、SharePoint Portal Server によってドキュメントにバージョン番号 1.1 が割り当てられます。公開および承認後に、ドキュメントはバージョン 2.0 になります。

役割メンバシップの継承の有効化

SharePoint Portal Server の配置では、多くの場合、多数のフォルダを扱いますが、必要になるセキュリティ ポリシーの数は比較的少数です。SharePoint Portal Server では役割メンバシップを継承できるので、コーディネータは 1 つの親フォルダの役割メンバシップを変更するだけで、多数のフォルダのセキュリティ ポリシーを管理できます。どのフォルダも、親フォルダのセキュリティ設定を利用するように構成できます (Windows 2000 の ACL 継承と同様)。フォルダが親フォルダからセキュリティを継承すると、そのフォルダのすべての役割メンバシップが親フォルダと同じになります。このフォルダの役割メンバシップを変更することはできません。親フォルダでのセキュリティ設定の変更は、すぐにサーバーによって、その親フォルダの役割メンバシップを継承する子フォルダに適用されます。

継承を取り消す場合には、親フォルダの役割メンバシップをコピーするか、フォルダのすべての役割メンバシップを削除するかを選択できます。継承を取り消した後で継承を有効にすると、SharePoint Portal Server は、現在の役割メンバシップを親の役割メンバシップで完全に置き換えます。新しいフォルダを作成すると、作成されたフォルダは、親フォルダのセキュリティ設定を既定で継承します。

メモ
承認者の状態はセキュリティの役割には含まれないため、サブフォルダは承認ポリシーを継承しません。つまり、役割設定も承認トポロジも継承されません。承認ポリシーは、フォルダごとに指定する必要があります。

すべてのサブフォルダの継承を、リセットすることができます。サブフォルダの下にあるすべてのサブフォルダに対しても、継承をリセットする処理が再帰的に行われます。サブフォルダのセキュリティのリセットは、コーディネータとしての権限を持っているフォルダに対してのみ、行うことができます。

フォルダ階層の表示

フォルダ階層を参照してドキュメントを見つけるには、親フォルダの少なくとも 1 つの役割のメンバである必要があります。フォルダ内のサブフォルダの一覧を表示するには、親フォルダとサブフォルダの両方で、少なくとも 1 つの役割のメンバである必要があります。

フォルダのコンテンツを一覧表示するには、そのフォルダの役割の 1 つに割り当てられている必要があります。SharePoint Portal Server は、そのフォルダ内のすべてのアイテムの一覧を変更し、ユーザーが実際に読み取りアクセス権を持っているアイテムのみが表示されるようにします。つまり、ユーザーがアクセスを拒否されているドキュメントや、ユーザーが役割メンバシップを持っていないサブフォルダは、コンテンツの一覧に表示されません。検索結果には、ユーザーが表示およびアクセスの権利を与えられているドキュメントのみが含まれます。

前に説明したように、ローカル管理者は、すべてのコンテンツに対する読み取りアクセス権を暗黙的に必ず持っています。

既定の役割メンバシップの割り当て

既定では、ワークスペースを作成すると、表示可能なすべてのフォルダに次の既定の役割メンバシップが割り当てられます。

  • 閲覧者 : Everyone

  • コーディネータ : ワークスペースの作成者

ディレクトリ ソースからのユーザーの選択

役割を使用する場合、コーディネータは、各役割のメンバシップのリストに、特定のドメイン内の実際の Windows NT ユーザーとグループを追加します。ユーザー、グループ、および役割は、Windows NT 標準のユーザー選択用ダイアログ ボックスで選択します。ユーザーとグループは、次の場所から選択できます。

Windows 2000 Active Directory ドメイン
役割メンバシップのリストの内容は、Windows 2000 ディレクトリ構造のユーザーとグループです。

Windows NT 4 ドメイン
Windows NT 4 ドメインでは、セキュリティ アカウント マネージャ (SAM) データベースに SID が格納されています。コーディネータは、ユーザーを役割に追加する必要がある場合、ディレクトリからユーザーを選択します。このとき、SharePoint Portal Server は、ユーザーおよびグループの SID リストを SAM データベースから取得し、役割メンバシップのリストに追加できるようにします。

Windows NT 4 の SID 構造は、Windows 2000 の SID と同じです。Windows NT 4 ドメインから選択されたユーザーやグループに対して、特別な処理は必要ありません。

ローカル Windows NT アカウント
コーディネータは、ドメイン グループのほかに、SharePoint Portal Server を実行しているサーバー上のローカル グループやユーザーを選択することもできます。この方法は、Windows NT ドメインを利用しない環境で、特に役立ちます。この場合は、SharePoint Portal Server がユーザー名とパスワードを収集し、Windows 2000 を実行している SharePoint Portal Server コンピュータ上で保持されているローカル アカウントに基づいて、認証を行います。

重要
通常は、コンテンツのセキュリティ設定にローカルのユーザーやグループを使用しないでください。SharePoint Portal Server を実行しているほかのサーバーは、個々のコンピュータ上のローカル アカウントを解決できないためです。ダッシュボード サイトでは、ほかのサーバー上のローカル アカウントで保護されているコンテンツについては、インデックスに含めることも表示することもできません。

SharePoint Portal Server での認証

SharePoint Portal Server ワークスペースへのアクセスは、有効な Windows NT ユーザーおよびグループに制限されます。ユーザーは、ドメイン ユーザーである場合も、ローカル サーバー ユーザーである場合もあります。Windows NT ドメイン内に SharePoint Portal Server を配置していて、ユーザーがこのドメインにログインすると、SharePoint Portal Server は認証にドメイン セキュリティ サービスを使用します。これにより、ユーザーのシングル ログオンが可能になります。SharePoint Portal Server を配置していて、Windows NT ドメインは実装しない場合は、SharePoint Portal Server がユーザー名とパスワードを収集し、SharePoint Portal Server を実行しているコンピュータ上で保持されているアカウントに基づいて認証を行います。

メモ
Windows 2000 は、匿名ユーザーに SID を割り当て、ACL に含められるようにします。したがって、匿名アカウントを役割に割り当てることもできます。しかし、匿名アカウントを有効にしている場合、Windows 2000 はすべてのユーザーを匿名ユーザーとして扱います。このようなアクセスのためには、別の仮想サーバー (vroot) を作成することをお勧めします。

別の仮想サーバーを作成する方法の詳細については、「第 12 章 ‐ Deploying SharePoint Portal Server in an Extranet Environment」を参照してください。

ダッシュボード サイトのセキュリティの確保

SharePoint Portal Server は、セキュリティを確保するためにインターネット インフォメーション サービス (IIS) を利用しています。SharePoint Portal Server は、Web ストレージ システムへの URL アクセスをサポートしています。ダッシュボード サイトへのすべてのアクセスは、IIS が制御する vroot 経由で行われ、セキュリティを確保するために Windows NT アクセス許可が使用されます。Windows NT は、Web ストレージ システムに組み込まれているアクセス権の基本セットを要求します。IIS は、NTFS や Microsoft Web ストレージ システムなど、基盤となるストレージ システムを利用して、要求されたオブジェクトに対するアクセス権を持つユーザーから成る ACL を提供します。

検索セキュリティの確保

ユーザーによる検索では、検索過程で次の 2 つのセキュリティが必要です。

  • 既定のコンテンツアクセスアカウント : SharePoint Portal Server は、ユーザー アカウントのコンテキストで、外部コンテンツをクロールします。そのときに SharePoint Portal Server が使う既定のコンテンツ アクセス アカウントを用意しておく必要があります。また、個々のコンテンツ ソース用のアクセス アカウントを指定することもできます。このアカウント情報は、クロールの起点となるアイテムのプロパティとして保存されます。

  • 検査結果へのアクセス : 検索結果は、ドキュメントの内容に関する論理的な表示であるため、ユーザーがファイルの読み取りアクセス権を持っていない限り、ドキュメントやフォルダを表示することはできません。

適切な信頼関係が確立されていない限り、既定のコンテンツ アクセス アカウントや特定コンテンツ ソース用アクセス アカウントは、コンテンツをクロールしたりインデックスに含めたりするには、そのコンテンツが存在するドメインの適切なグループのメンバである必要があります。さらに、コンテンツを表示するためには、ユーザーが適切なセキュリティ グループのメンバである必要があります。

ネイティブ モード環境では、ユニバーサル グループを使用すると、セキュリティ管理を簡単に実施できます。混在モード環境では、一般的なグループ化方法を実装するだけでなく、適切な信頼関係を確立する必要があります。

セキュリティ タスクの実行

コーディネータは、コンテンツのセキュリティを指定し、役割を割り当てます。定義済みの役割のセットを使って、適切なレベルの制御を柔軟に行うことができます。

SharePoint Portal Server の管理
SharePoint Portal Server を実行しているコンピュータには、通常、1 つまたは複数のワークスペースが含まれます。ワークスペースを作成すると、ワークスペースの所有者の指定を求めるメッセージが表示されます。SharePoint Portal Server は、この所有者をワークスペースのコーディネータの役割に割り当てます。

ワークスペースのロックアウト
SharePoint Portal Server を使用すると、コーディネータは、ドキュメントに対する閲覧と表示の両方についてアクセスを制御できます。ドキュメントやフォルダに対するアクセス権を持たないユーザーは、検索やフォルダ参照を行っても、それらを見つけることができません。また、フォルダのセキュリティ メンバシップを親フォルダの役割メンバシップとまったく異なるように構成することもできます。そのため、保護されているオブジェクトを誰も表示できないように、セキュリティを構成することも可能です。この場合、セキュリティ設定を変更するために親フォルダを参照してサブフォルダのプロパティ ページにアクセスすることができなくなるため、フォルダの役割メンバシップを再変更することは不可能になってしまいます。

この問題に対応するため、SharePoint Portal Server は、すべてのワークスペースのドキュメントとフォルダへの読み取りおよび参照アクセス許可をローカル Administrators グループに割り当てます。これは、構成も取り消しも不可能な、ローカル Administrators グループの権限です。この権限は、個別のアイテムの "アクセス許可のない役割" の設定よりも優先されます。ローカル Administrators グループには、すべてのフォルダとドキュメントに対して役割メンバシップを指定できるアクセス許可もあります。したがって、上で説明したような理由でフォルダがアクセスできなくなった場合は、サーバーのローカル Administrators グループのメンバが、この問題を解決できます。ローカル Administrators グループのメンバであるユーザーは、フォルダの役割メンバシップにかかわらず、すべてのファイルとフォルダに対して役割メンバシップを割り当てることができます。

重要 :
SharePoint Portal Server では、すべてのコーディネータ操作を行うための完全な特権をローカル Administrators グループのメンバに与えているわけではありません。たとえば、ローカル Administrators グループのメンバは、Web パーツ設定やダッシュボード サイトのレイアウト変更などの操作を試行できますが、このような操作は失敗します。この失敗は、SharePoint Portal Server によって報告されないため、エラー メッセージなどは表示されません。これらの操作を正常に行うには、フォルダのコーディネータ役割に該当ローカル Administrator を追加する必要があります。

検索およびドキュメント管理のためのコンテンツのセキュリティ

サーバー管理者とワークスペース コーディネータは、ダッシュボード サイトを通じてコンテンツを利用できるようにする場合、組織のセキュリティ ポリシーを考慮する必要があります。以前は、組織構造全体にわたって、情報が見つけにくいためにセキュリティが守られていたという場合がよくありました。SharePoint Portal Server を使用する場合、見つけにくいために情報がアクセスされないということはなくなります。コンテンツとして特定されたソースは、インデックスに含められ、組織内の適切な役割に関連付けられているすべてのユーザーが利用できるようになります。

情報が適切に保護されていない場合は、対象外の閲覧者に見られる可能性があります。たとえば、金融機関の特定の部門で、保護されていないファイル サーバーに機密情報を保存していると、ダッシュボード サイトを通じて別の部門のユーザーから参照されてしまう可能性があります。

SharePoint Portal Server には、すばやく適切な検索をユーザーに提供するための機能がいくつかあります。これらの機能は、適切に保護されていないコンテンツに対するアクセスを許してしまう可能性があります。たとえば、次のような機能があります。

  • さまざまな場所に格納されている情報に対する単一の場所からの検索

  • ドキュメントのフル テキストおよびドキュメントのプロパティを検索するキーワード検索

  • ドキュメントのプロファイル、プロパティ、または日付に対する高度な検索

  • 主題 (カテゴリ) 別の分類に基づく情報検索

  • ドキュメントの自動カテゴリ分類

  • 検索条件との関連性が高いドキュメントを対象にした "おすすめコンテンツ"

  • 役立つ最新情報の購読

SharePoint Portal Server を配置する場合は、すべての情報ソースにわたってコンテンツを保護し、確実に対象者のみが情報を利用できるようにする手順をとる必要があります。

SharePoint Portal Server は、Windows NT のセキュリティ設定に従って、情報を適切なユーザーに開示します。NTFS のセキュリティ ポリシーが明確に定義されていないと、セキュリティ上の大きな問題が発生する可能性があります。

ヒント :
組織のセキュリティ ポリシーを再確認し、潜在的なセキュリティ上の危険性を特定します。各問題点に応じてセキュリティ ポリシーを修正し、適切なユーザー グループに正確で十分なアクセス許可を与えるようにします。

セキュリティを構成する場合、考慮すべきコンテンツのソースとして、ワークスペースに保存されるコンテンツと、ワークスペース外に保存されるコンテンツの 2 つがあります。それらをダッシュボード サイトでどのように表示するかについても、考慮する必要があります。

ワークスペースのコンテンツの保護

ワークスペースに保存されるコンテンツには、標準フォルダのドキュメントと拡張フォルダのドキュメントがあります。ワークスペースのコンテンツを保護する場合、考慮すべき問題がいくつかあります。

セキュリティ設定の継承
新しいサブフォルダを作成すると、作成されたフォルダは、親フォルダのセキュリティ設定を既定で継承します。親フォルダのセキュリティ設定を使用しない場合は、サブフォルダの役割設定をカスタマイズします。親フォルダのセキュリティ設定を変更する場合は、すべてのサブフォルダが新しい設定を使用するように指定できます。この場合、サブフォルダで変更されていた役割設定は上書きされます。

フォルダは、役割設定のみを継承します。拡張フォルダでは、フォルダの作成時に、承認者と承認ルートがサブフォルダにコピーされます。ただし、その後に親フォルダに対して行われる変更は、サブフォルダには反映されません。

役割によるアクセスの制御
役割は、フォルダ階層にある情報へのユーザー アクセスを制御するのに役立ちます。たとえば、フォルダ構造に基づいて情報が推測されることを避けたい場合は、特定のドキュメントの検索と表示はできても、親フォルダは表示できないように、役割を構造化します。

フォルダ階層を移動しながらドキュメントを探すことができるようにするには、ユーザーを親フォルダの少なくとも 1 つの役割に割り当てる必要があります。親フォルダのサブフォルダに移動できるようにするには、ユーザーを親フォルダとサブフォルダの両方の少なくとも 1 つの役割に割り当てる必要があります。

ユーザーがサブフォルダへのアクセス権を持ち、親フォルダへのアクセス権を持たない場合、親フォルダは Windows エクスプローラには表示されませんが、URL を使って直接そのサブフォルダにアクセスできます。この場合、このサブフォルダにあるドキュメントは、検索結果に表示されます。

複合ドキュメント
SharePoint Portal Server では、標準フォルダ上でのみ、複合ドキュメント (Office アプリケーションでドキュメントを Web ページとして保存した場合に作成されるファイルとフォルダのセット) をサポートします。コーディネータだけが、複合ドキュメントのサブフォルダに対するセキュリティを設定できます。拡張フォルダでは、複合ドキュメントに類似した構造はサポートされていません (例 : 相対リンクがある HTML ファイル、または Microsoft Excel スプレッドシートへのリンクがある Word ドキュメントで、どちらのドキュメントもワークスペースに保存されている場合)。複合ドキュメントを拡張フォルダにチェックインしようとすると、SharePoint Portal Server によって警告メッセージが表示されます。

Windows 2000 認証での購読通知
ユーザーが購読を作成するときに、ドキュメントの読み取りアクセス権が Windows 2000 の Authenticated Users の SID (ドメインまたはローカル グループのアカウント) を通じて割り当てられる場合、ユーザーは購読通知を受け取りません。Windows 2000 の Everyone グループは、このカテゴリの SID ではないことに注意してください。

たとえば、ADVENTURE･user が、ADVENTURE ドメイン内の Authenticated Users のカテゴリに分類されるとします。SharePoint Portal Server コンピュータの Marketing が同じドメインにあります。ADVENTURE･user が Marketing に対して、"specification" の検索結果という条件で購読を作成します。この場合、インデックス内のドキュメントで、"specification" という語を含むものがあると、通知が生成されます。

  • "specification" という語を含むドキュメントが Projects フォルダにあり、そのフォルダの "閲覧者" 役割に Everyone がある場合、ADVENTURE･user は通知を受け取ります。

  • "specification" という語を含むドキュメントが Web サーバー上でクロールされる場合、ADVENTURE･user は通知を受け取ります。

  • "specification" という語を含むドキュメントが SpecialCase フォルダにあり、そのフォルダの閲覧者役割がドメイン グループ AuthPeople のみで、このドメイン グループに Authenticated Users が含まれている場合、ADVENTURE･user は通知を受け取りません。

ドキュメントに対してユーザーが持っている唯一のアクセス権が、Authenticated Users または次のような特別な SID を通じて割り当てられている場合、ユーザーは通知を受け取りません。

  • ANONYMOUS LOGON

  • BATCH

  • DIALUP

  • INTERACTIVE

  • NETWORK

  • TERMINAL SERVER USER

アクセス制御リスト (ACL) に、ADVENTURE･user と Authenticated Users の両方から構成されるグループが含まれている場合、ユーザーは通知を受け取ります。

IFS および IIS によるコンテンツへのアクセス
インストール可能ファイル システム (IFS) およびインターネット インフォメーション サービス (IIS) は、ワークスペース フォルダにフルにアクセスできます。SharePoint Portal Server ワークスペースには、既定 Web サイトで IIS によって作成された vroot が関連付けられています。ダッシュボード サイトのセキュリティは、ここで管理できます。

ユーザーは、SharePoint Portal Server コンピュータ上の Windows エクスプローラで、IFS にアクセスできます。SharePoint Portal Server は、通常、IFS をネットワーク ドライブ M にマップします (既に M を使用しているマッピングがある場合を除く)。IFS を利用すると、SharePoint Portal Server が使用している Microsoft Web ストレージ システムのコンテンツを表示できますが、このアクセスは読み取り専用です。

重要 :
IFS (ネットワーク ドライブ M) を使用して、SharePoint Portal Server のフォルダまたはドキュメントを作成したり、ドキュメントやフォルダに対してセキュリティの割り当てやプロパティの編集を行うことは、お勧めできません。SharePoint Portal Server の役割と構成のオプションは、サポートされている Web フォルダ インターフェイスを通して利用できます。IFS のセキュリティ属性を操作すると、SharePoint Portal Server に関連付けられている役割情報と競合して、データを失う可能性があります。ドキュメント プロファイルの作成など、ワークスペースの管理機能も、Web フォルダ インターフェイスからだけ利用できます。

SharePoint Portal Server のフォルダとドキュメントのセキュリティを設定するのに、Microsoft ActiveX D ata Objects (ADO) や OLE DB は使用しないでください。

ワークスペース外のコンテンツの保護

SharePoint Portal Server は、組織のサーバー、ファイル共有、およびデータベースに現在割り当てられている、ユーザー レベルのセキュリティ ポリシーを認識します。共有レベルのセキュリティは、適用しません。

セキュリティマッピング

  • SharePoint Portal Server は、コンテンツ ソースのセキュリティ スキームを Windows 2000 セキュリティにマップし、コンテンツをクロールする場合とユーザーがコンテンツを検索する場合に、セキュリティ スキームを適用します。

  • 別のドメインのサーバーにあるコンテンツをクロールする場合、コンテンツを保護するためには、クロールされるサーバー上のローカル グループ アカウントは使用しないでください。SharePoint Portal Server はローカル グループ アカウントを認識しないため、ユーザーはクロールされたコンテンツを見ることができなくなる場合があります。

メモ :
SharePoint Portal Server は、ユニバーサル グループ アカウント、グローバル グループ アカウント、およびドメイン ローカル グループ アカウントを認識できます。

たとえば、Domain A に Server A があり、Domain B の Server B 上のコンテンツをクロールするとします。Server B は、もう 1 つの SharePoint Portal Server コンピュータ、Web サーバー、およびファイル共有のうちのいずれかです。

  • Server B 上のコンテンツは、ローカル グループ アカウントを使って保護できます。

  • Server A が Server B をクロールする場合、コンテンツに関連付けられている SID は、Server B 上のローカル グループ アカウントに関連付けられている SID になります。

  • Domain A の閲覧者が、Server A 上のクロールされたコンテンツにアクセスしようとする場合、SID は Server B に関連付けられているため、Server A は、このコンテンツのセキュリティを認識することはできません。

  • 閲覧者は、Domain B の認証ユーザーであったとしても、コンテンツを表示することはできません。

コンテンツソースの種類に応じたセキュリティの強制
コンテンツ ソースの種類ごとのセキュリティは、次のように機能します。

  • Web サイト : SharePoint Portal Server は、クエリ時にはセキュリティを強制しません。クロール用にはパスごとのログオンを指定しますが、クエリ結果には誰でもアクセスできます。SSL 共有 (https:// が先頭に付く) は、クロールできません。

  • ファイル共有 : SharePoint Portal Server は、クエリ時にユーザー レベルのセキュリティを強制します。FAT などのユーザー レベルのセキュリティがないファイル システムには、共有レベルのセキュリティはありません。クロール用にはパスごとのログオンを指定するので、共有レベルのセキュリティを通じたアクセスが可能です。暗号化されたドキュメントは、クロールされません。

  • SharePoint Portal Server コンピュータ : SharePoint Portal Server は、クエリ時にユーザー レベルのセキュリティを強制します。

  • Microsoft Exchange 2000 サーバー : SharePoint Portal Server は、クエリ時にメッセージ レベルのセキュリティを強制します。暗号化されたメッセージは、クロールされません。

  • Microsoft Exchange 5.5 サーバー : SharePoint Portal Server は、クエリ時にメッセージ レベルのセキュリティを強制します。暗号化されたメッセージは、クロールされません。

  • Lotus Notes サーバー : Lotus Notes ユーザー ID と Windows NT ユーザー ID のマッピングを使用すると、クエリ時にレコード レベルのセキュリティを利用できます。

Exchange Server 5.5 および Lotus Notes コンテンツ ソースを作成する前に、Exchange Server 5.5 および Lotus Notes コンテンツ ソースをクロールするようにサーバーを構成する必要があります。

SharePoint Portal Server は、ネットワーク ファイル システム (NFS) プロトコルを使用して、UNIX システムにアクセスできます。また、NetWare クライアントを使用すると、Novell NetWare にアクセスできます。その場合、Unix または NetWare ファイル システム用のクライアントを、SharePoint Portal Server コンピュータ上にインストールする必要があります。

SharePoint Portal Server は、NTFS ファイル システム以外のリモート ファイル システム (Unix や NetWare などの外部ファイル システム) 上のセキュリティ記述子は認識できません。非 NTFS ファイル システムのファイルごとのセキュリティ設定は失われますが、共有ごとのセキュリティ設定は維持されます。セキュリティ マッピングがない場合、SharePoint Portal Server は匿名 (guest) アカウントでログオンするので、匿名ユーザーではアクセスできないコンテンツに対してはアクセス権がありません。この場合、SharePoint Portal Server はドキュメントをクロールし、Windows 2000 の Everyone グループ用の読み取りアクセス権を設定します。つまり、クロールされたすべてのドキュメントが、誰でも検索できるようになります。Windows NT とは互換性がない方法で保護されている情報が公開されてしまわないようにするために、管理者はこの点に注意する必要があります。

SharePoint Portal Server は、Unix や NetWare などの外部ファイル システムにアクセスする際に、セキュリティ資格情報を送信することができます。サイト パス内のアカウントとパスワードが、基本認証を必要とするリモート ファイルのシステム パスを制御するように指定することもできます。セキュリティ記述子の取得に失敗すると、SharePoint Portal Server はアイテムをインデックスに含めないようにします。

重要 :
SharePoint Portal Server は、Windows ファイル共有 (SMB) をインデックスに含められますが、そのほかのネットワーク ファイル システム プロトコル用の組み込みサポートはありません。これらのファイル システムも、エミュレータを使用して Windows ファイル共有として公開すれば、インデックスに含められます。ただし、ファイル共有のセキュリティは、エミュレーション ソフトウェアが公開する方法でのみ適用されます。一般に、インデックスに含まれるすべての非 NTFS ファイル システム ドキュメントは、SharePoint Portal ワークスペースのすべての閲覧者から検索可能です。

まとめ

この章では、Windows 2000 のセキュリティ機能を Microsoft SharePoint Portal Server 2001 で利用する場合の利点について概説しました。また、企業ポータルのコンテンツのセキュリティを保護する Windows 2000 セキュリティの機能、および SharePoint Portal Server の役割に基づくセキュリティ モデルについて説明しました。SharePoint Portal Server のセキュリティ アーキテクチャを公開モデルも含めて説明し、検索時のコンテンツの保護やコンテンツの統合に関する推奨事項も提供しました。

SharePoint Portal Server は、強力で柔軟なセキュリティ インフラストラクチャを提供し、コンテンツ管理者は便利な新機能を利用できます。Windows 2000 でサポートされている分散セキュリティ モデルは、SharePoint Portal Server によって拡張されます。役割に基づくセキュリティ機能を使用すると、管理タスクをコンテンツ所有者に分散できるため、コンテンツ管理を単純化できます。ユーザーは、タスクに応じて役割に関連付けられます。ドキュメントに対するアクセスは、ドキュメントの状態に基づいて調整されます。役割を使うことで、動的で柔軟なセキュリティ モデルを作成できます。