次の方法で共有


SharePoint での権限、ユーザー、グループ、およびオブジェクト モデル

SharePointでは、Web サイト、リスト、フォルダー、リスト アイテムへのアクセスは、ロール ベースのメンバーシップ システムによって制御されます。このシステムでは、ユーザーにロールを割り当て、それによって SharePoint オブジェクトへのアクセスを承認します。

ユーザーにオブジェクトへのアクセス権を与えるには、既にそのオブジェクトへのアクセス許可が与えられているグループにそのユーザーを追加するか、ロールの割り当てオブジェクトを作成して、ユーザーにロールの割り当てを設定し、必要に応じてそのロールの割り当てを基本的なアクセス許可を持つ適切なロール定義にバインドしてから、その割り当てを目的のリスト アイテム、フォルダー、リスト、Web サイトに対するロールの割り当てのコレクションに追加します。 ユーザーをロールに割り当てても、そのロールの割り当てをロール定義にバインドしていない場合、ユーザーにはアクセス許可が与えられません。 SharePointでは、次の方法でそのオブジェクトへのアクセスを制御しています。

  • オブジェクトでは、親 Web サイト、リスト、フォルダーと同じアクセス許可を使用することも (親オブジェクトで有効なロールとユーザーの両方とも継承)、固有のアクセス許可を使用することもできます。

  • 各サイト、リスト、フォルダー、およびアイテムはロールに割り当てられたコレクションを提供するので、オブジェクトへのユーザーのアクセスを詳細に管理できます。

  • グループはユーザーで構成されていますが、ロールに割り当てられている場合と、そうでない場合があります。 SharePointには、既定で以下の 3 つのグループがあります。

    • owners (管理者)

    • members (投稿者)

    • visitors (閲覧者)

      ユーザー インターフェイスから固有のアクセス許可が設定された Web サイトを作成すると、サイトのプロビジョニングの一環として、これらのグループにユーザーを割り当てることのできるページが表示されます。

  • 匿名アクセスを使用すると、ユーザーはリストやアンケートに匿名で投稿したり、ページを匿名で表示したりできます。 また、匿名アクセスを有効にしなくても、ドメインのすべてのメンバーが Web サイトにアクセスできるように、"すべての認証されたユーザー" にアクセス権を付与することもできます。

  • サイト作成権限 (CreateSSCSiteManageSubwebs) は、ユーザーがトップ レベル Web サイト、サブサイト、またはワークスペースを作成できるかどうかを制御します。

ユーザーは、ロールが割り当てられたグループを介して間接的に、またはロールの割り当てによって直接的に SharePoint オブジェクトのメンバーになります。 また、グループまたはロールに追加された Microsoft Windows NT ドメイン グループのメンバーにもなれます。 ロール定義は、ユーザーまたはグループを 、Microsoft.SharePoint.SPBasePermissions 列挙の値に対応する単一の権限または権限セットに関連付けます。 各ユーザーまたはグループには、一意のメンバー ID があります。 オブジェクト モデルを使用すると、addrole.aspx ファイルと editrole.aspx ファイルの機能を使用する方法とは異なる方法で、ロールの割り当てと定義を作成または変更できます。 ユーザー インターフェイスに表示されるこれらのページとは異なり、オブジェクト モデルでは権限の依存関係が強制されないため、権限の任意の組み合わせを使用してロール定義を作成できます。 ただし、不適切に計画されたロール定義と不適切に割り当てられた権限によってユーザー エクスペリエンスが低下する可能性があるため、オブジェクト モデルを使用してロールの定義とアクセス許可をカスタマイズする場合は慎重に計画してください。 SharePoint 権限の詳細については、「 SPBasePermissions」を参照してください。

セキュリティ ポリシー

セキュリティ ポリシーは、Web アプリケーション (仮想サーバー) 内のすべてのサイト コレクションで一貫したセキュリティを適用する手段です。 ポリシーを使用すると、ロール (つまり、権限のコレクション) を個々の SharePoint ユーザーと、Windows 認証やプラグ可能な認証システムを使用しているドメイン グループ (SharePoint グループを除く) に割り当てることができます。 ポリシー エントリごとに、Web アプリケーションのユーザーまたはグループの権限が指定されます。

ポリシーは、論理 Web アプリケーション レベルまたはゾーン レベルで設定されます。 ユーザーは、たとえば、2 つの Web アプリケーションのコンテンツが同じ場合でも、 と http://Server.extranet.microsoft.comに異http://Serverなるポリシーを設定できます。

権限は、ポリシーを通じて付与または拒否できます。 権限を付与すると、オブジェクトに対するローカルアクセス許可に関係なく、Web アプリケーション内のすべてのセキュリティで保護されたオブジェクトのユーザーまたはグループにその権限が付与されます。 権限の拒否は、権限を付与するよりも優先度が高く、Web アプリケーション内のすべてのセキュリティで保護されたオブジェクトのユーザーまたはグループに対する権限をアクティブにブロックします。 ユーザーに対してすべてを拒否すると、ユーザーが特定のコンテンツに対して明示的なアクセス許可を持っている場合でも、そのユーザーがコンテンツにアクセスできなくなります。ポリシーはサイトレベルのアクセス許可をオーバーライドします。

ポリシー ロールでは、ユーザーおよびグループはセキュリティ識別子 (SID) とログインまたはユーザー名の両方によって識別されます。 ポリシー ロールの適用は、Web サイト、リスト、フォルダー、またはドキュメントのアクセス許可の管理に似ています。ユーザーまたはグループを追加し、1 つまたは複数の役割の定義を割り当てます。 各 Web アプリケーションには独自のポリシー ロールがあります。 ポリシー ロールとアクセス許可の管理のもう 1 つの違いは、全体管理者が Web アプリケーション全体でユーザーの権限を拒否することができる点です。

注:

サーバーの全体管理のポリシー ロールは、サイト コレクションのロール定義と異なります。

ユーザー、グループ、およびプリンシパル

個々のユーザー ( SPUser ) が SharePoint オブジェクトにアクセスするには、個別のロールの割り当てを通じて直接アクセス権を取得するか、ロールの割り当てが設定されたドメイン グループまたは SharePoint グループ ( SPGroup ) を通じて間接的にアクセス権を取得します。 直接的なロール割り当てでは、ユーザーがプリンシパル ( SPPrincipal ) になります。 一方、ドメイン グループまたは SharePoint グループのロールの割り当てでは、ドメイン グループまたは SharePoint グループがプリンシパルになります。

SharePoint Server では、Windows ユーザー ( ドメイン\ User_Aliasなど) と外部ユーザー (プラグ可能な認証) がサポートされています。 ユーザーの ID の保守は、ID 管理システム (Active Directory ディレクトリ サービスなど) によって行われます。 ユーザー プロファイル (ユーザーの表示名、電子メール アドレス、その他の情報など) のスコープはサイト コレクション レベルです。 表示名を変更すると、サイト コレクション全体に変更が適用されます。

グループは、SharePoint Server がセキュリティを管理するユーザーのコレクションです。 ユーザー ベースの管理は、シンプルなサイトではわかりやすいのですが、個別にセキュリティ保護されるリソースの数が増えるにしたがって複雑になります。 たとえば、1 人のユーザーが 1 つ目のリストには Contribute ロールを持ち、2 つ目のリストには Read ロールを持ち、さらに 3 つ目のリストには Design ロールを持つような場合もあります。 そのような場合、このモデルはうまくスケールアップするこができず、たとえばユーザー数が 50,000 人もいる場合は、個別にセキュリティ保護されるオブジェクトごとにアクセス制御リスト (ACL) に 50,000 個ものアクセス制御エントリ (ACE) が連なることになります。

グループは、ユーザー ベースのアクセス許可管理の管理とスケーリングの問題に対する回答を提供します。 グループベースの管理は、より抽象的な管理や概念化が難しい場合がありますが、一意にセキュリティで保護された多数のオブジェクトを含む複雑なサイトの管理が容易になります。 たとえば、システム内のさまざまなオブジェクトに対して適切なロールが既に付与されているグループにユーザーを追加する場合などです。 グループのアクセス許可チェックは、格納する必要があるグループ ACE がはるかに少ないため、スケーリングが向上します。

SharePoint Server では、ドメイン グループと SharePoint グループの 2 種類のグループがサポートされています。 ドメイン グループは SharePoint Server コントロールの外部に残ります。ユーザーは SharePoint Server を使用してドメイン グループ メンバーシップを定義、参照、または変更することはできません。 SharePoint グループの範囲はサイト コレクション レベルであり、サイト コレクション内でのみ使用できます。 ドメイン グループは、Active Directory ディレクトリ サービスのスコープ内の任意の場所で使用できます。

プリンシパルは、セキュリティ管理に使用されるユーザーまたはグループです。 1 つのサイトにユーザーを追加すると、ユーザーがプリンシパルになり、そのサイトにグループを追加するとグループがプリンシパルになります。 SharePoint Server でセキュリティをスケールアップするにあたり、スコープ内のプリンシパルを妥当な数に保つことが重要となります。 グループを使用すると、少数のプリンシパルで膨大な数のユーザーにアクセス権を与えることができます。

オブジェクト関係の概観 ? スコープ、ユーザー、グループ、ロール

図 1 は、論理データベースダイアグラムの SharePoint Server セキュリティ管理システムの概要を示しています。 各ボックスは、システム内のセキュリティ オブジェクトを表します。 線は、オブジェクト間のリレーションシップを表します。 1 および N 表記は、リレーションシップの種類を表します。 この図は、アクセス許可データをユーザー トークンと ACL に構造化する方法を示しています。

図 1. 承認オブジェクトの関係

承認オブジェクトの関係

スコープは、個別にセキュリティ保護される 1 つのオブジェクトまたは複数のオブジェクト セットで示されます。 サイト、リスト、フォルダー、アイテムの各レベルをスコープに指定できます。

ユーザーとグループは、多対多の関係 (N - N) にあります。 各ユーザー ( SPUser ) は複数のグループのメンバーに属することができ、各グループ ( SPGroup ) には複数のユーザーを含めることができます。

権限とロールの定義も、多対多の関係 (N - N) にあります。 各権限 ( SPBasePermissions ) は、複数のロール定義に属することができます。 たとえば、" Insert List Items" 権限は " Contributor"、" Designer"、" Administrator" の各ロール定義に属します。 また、各ロール定義 ( SPRoleDefinition ) にも、複数の権限を含めることができます。 たとえば、" Contributor" には、リスト アイテムを挿入する権限、更新する権限、削除する権限が含まれます。

ロール定義とロールの割り当て ( SPRoleAssignment ) は、一対多の関係 (1 - N) にあります。 各ロール定義は、複数のロールの割り当ての中で使用されます。 リスト 1 の閲覧者とリスト 2 の閲覧者が異なる場合もありますが、そのロールの割り当ては " Reader" という 1 つのロール定義を共有できます。

ユーザーまたはグループとロールの割り当ては、多対多の関係 (N - N) にあります。 各ユーザーまたはグループは、任意のオブジェクトに対して複数のロールの割り当てのメンバーに属することができます。 たとえば、1 人のユーザーが同じオブジェクトに対して " Designer" ロールと " Administrator" ロールを併せ持つことができます。

スコープとロールの割り当てには、1 対多のリレーションシップ (1 から N) があります。 各スコープには複数のロールの割り当てが含まれますが、各ロールの割り当てのスコープは 1 つだけです。 たとえば、1 人のユーザーが [イベント] リストの閲覧者であり、別のユーザーが [イベント] リストの共同作成者である可能性がありますが、これらのロールの割り当てはどちらも [お知らせ] リストには適用されないことがあります。 2 つのリストが同じロールの割り当てを共有する唯一の方法は、親コンテナーからアクセス許可を継承することです。その場合、セキュリティ スコープはコンテナーであり、2 つのリストではありません。

ユーザー トークンとアクセス制御リスト

SharePoint Server では、権限チェックを速やかに行うため、そのセキュリティ モデル内にユーザー トークンと ACL が実装されています。 ユーザー トークンによって、ユーザーに適用される認証プロセスが識別されます。 Windows ユーザーは、ユーザー固有の文字列 (SID) と、そのユーザーが属するすべての Windows ドメイン グループのリストで構成される複雑なトークン (例: DOMAIN\Department 15688) を使用します。 Windows 認証が設定されていないユーザーは、ユーザー名に固有の文字列からなる非常にシンプルなトークンを使用する場合もあれば、Windows 認証で表されるようなグループ/ロールのメンバーシップが組み込まれた複雑なトークンを使用する場合もあります。 各ユーザーが属する SharePoint グループのメンバーシップはユーザー トークンを使って表されるため、SharePoint Server では、ユーザー トークンを読み取ることにより、現在のユーザーが属するすべてのグループが識別されます。

ACL は、特定のオブジェクトに対するユーザーとグループの権限を指定するバイナリ オブジェクトです。 ACL は複数の ACE で構成され、各セキュリティ プリンシパル (ユーザーまたはグループ) が ACL 内で 1 つの ACE となります。 権限、ロール定義、ロールの割り当てはスコープごとに ACL に構造化されているため、SharePoint Server では、指定された対象範囲内でユーザーまたはグループごとに許可されているアクションを識別できます。

オブジェクト モデルの変更: 廃止されたセキュリティ オブジェクト (前方互換性あり)

SharePoint では、すべてのオブジェクト スコープが同じ基本的なアクセス許可管理エクスペリエンスを共有します。 SharePoint はロール定義を使用してアクセス許可を管理します。これにより、リスト、フォルダー、アイテム レベルで一貫性のあるエクスペリエンスを実現できます。 Windows SharePoint Services 2.0 で使用される次のセキュリティ オブジェクトは廃止されましたが、下位互換性のために引き続き機能します。

ユーザーをロールに割り当てるには、 Microsoft.SharePoint.SPRoleAssignment クラスと Microsoft.SharePoint.SPRoleAssignmentCollection クラスのメンバーを使用します。 SPRights に代わる SPBasePermisssions 列挙には、追加の権限が含まれます。 また、 SPBasePermisssions 列挙には、 SPRights の以前の権限と同じ定数値にマッピングされる従来の権限も含まれます。 SharePoint グループの概念は、クロスサイト グループを表す既存の SPGroup オブジェクトと SPGroupCollection オブジェクトに対応付けられます。

ポリシー ロール: URL ゾーンのセキュリティ ポリシーを作成または変更する

URL ゾーンのセキュリティ ポリシーを作成または変更するには、以下のクラスとそのメンバーを使用します。

共有リソースに対応するためのゲスト ロール (制限付きアクセス)

ゲスト ロールの概念は、プラットフォームの共有リソースに対応するというものです。 たとえば、リスト ビューのページをレンダリングするには、Web サイトのテーマやナビゲーション構造を使用する必要があります。 この概念への対応は、フォルダー レベルとリスト レベルの権限にまで広がっています。

従来のオブジェクト モデルとの意味的互換性を保つために、SharePoint オブジェクト モデルはこれまでと同様に " Guest" ロールと呼ばれますが、ユーザー インターフェイスでは [ 制限付きアクセス] と表示されます。

フォルダとアイテムの権限が及ぶ範囲

ユーザーにフォルダーに対するアクセス許可が付与されると、そのフォルダーの親リストと、その一覧の親 Web サイトの ゲスト ロールも付与されます。フォルダーの上のすべての一意にセキュリティで保護されたスコープでは、最初の一意の先祖 Web サイトまでのすべての方法です。 これはリスト アイテムにも当てはまります。アイテムに対するユーザー アクセス許可を付与すると、最初の一意の先祖 Web サイトまで、すべての親フォルダー、リスト、Web サイトに対する ゲスト ロールもユーザーに付与されます。

1 つのスコープまたはすべてのスコープからユーザーを削除する

あるスコープからユーザーを削除すると、現在のスコープより下にある個別にセキュリティ保護されたすべてのスコープからもそのユーザーが削除されます。 たとえば、ある Web サイトからユーザーを削除すると、そのサイト内で個別にセキュリティ保護されたリストからもそのユーザーが削除されます。

すべてのスコープからユーザーを削除する唯一の方法は、サイト コレクションからそのユーザーを削除することです。そうすることにより、サイト コレクション内ですべてのスコープのすべてのロールからそのユーザーが削除されます。

関連項目