更新プログラム 12/18/07: 削除するか、既定のグループ名の変更のポール Liebrand のいくつかの技術の結果をご覧ください。 (以下の彼のコメントを見る).

概要:

SharePoint のセキュリティは構成し、管理が容易. ただし, それは本当にその周りに手をラップするいくつかの初めての管理者ことが難しいことを証明して. それだけでなく, その間に構成を行うには持っていなかったので、金曜日までにそれを失っているだけに月曜日に完璧な理解に来ていくつかの管理者を見ています。. (自分自身、この問題を認める). このブログのエントリがうまくいけば有用な SharePoint セキュリティ入門を提供し、いくつかのセキュリティの構成のベスト プラクティスを指して.

重要な注意事項:

この説明は、SharePoint のセキュリティ ボックスから基づいてください。. ここでいくつかのコケ特定のものがありますので、私の個人的経験を向きモス周辺, WSS のため正確だと思いますが、. 私は願って、すべてのエラーまたは不作為を見て誰もが指摘コメントまたは 私にメールします。. ポスト急いで訂正を作ってあげる.

基礎:

この概要の目的のため, セキュリティの 4 つの基本的な側面があります。: ユーザー/グループ, セキュリティ保護可能なオブジェクト, アクセス許可レベルと継承.

ユーザーとグループ ダウンを破る:

• 個々 のユーザー: ディレクトリまたは SharePoint で直接作成されたアクティブから引っ張ら.
• グループ: Active directory から直接マップされたまたは作成できる SharePoint. グループは、ユーザーのコレクション. グループは、サイト コレクションのグローバル. 決して「縛られています。" 特定のセキュリティ保護可能なオブジェクトを.

セキュリティ保護可能なオブジェクト 少なくともダウンを破る:

• サイト
• ドキュメント ライブラリ
• リストおよびドキュメント ライブラリ内の個々 のアイテム
• フォルダー
• BDC のさまざまな設定.

ありますその他のセキュリティ保護可能なオブジェクト, しかし、画像を取得.

アクセス許可レベル: 粒状のバンドル / リストにエントリを作成、読み取り、削除のようなものは、低レベルのアクセス権.

継承: 既定のエンティティによってそれぞれの格納オブジェクトからセキュリティ設定を継承します。. サブサイトが親からアクセス許可を継承します。. ドキュメント ライブラリは、サイトから継承します。. などなどなど.

ユーザーおよびグループに関連するセキュリティ保護可能なオブジェクトのアクセス許可レベルと継承を介して.

最も重要なセキュリティの規則を理解するには, これまで🙂 :

1. グループはユーザーの集まりです。.
2. グループがグローバル サイト コレクション内で (すなわち. サイト レベルで定義されているグループのようなものはありません。).
3. グループ名は耐されていません, グループにはありません。, 自分の, セキュリティの特定のレベルがあります。.
4. グループは、特定のセキュリティ保護可能なオブジェクトのコンテキストのセキュリティを持っています。.
5. すべてのセキュリティ保護可能なオブジェクトの同じグループに異なるアクセス許可レベルを割り当てることがあります。.
6. Web アプリケーションのポリシーをすべてを切り札 (以下を参照してください。).

セキュリティ管理者グループおよびユーザーのリストの海で失われた常に管理し、セキュリティの構成を理解するこれらの公理を頼ることができます。.

一般的な落とし穴:

• グループ名を偽って示唆アクセス許可: ボックスのうち, SharePoint は、その名前が示す固有のレベルのセキュリティ グループのセットを定義します. 「投稿者」グループを検討してください. 不慣れな SharePoint のセキュリティのいずれか可能性がありますもその名前を見て、そのグループのすべてのメンバー」が貢献できると仮定" 任意のサイト/リスト/ライブラリは、ポータル内に. することがないので、グループの名前がたまたま「投稿者」. グループはルート サイトにコンテンツを追加/編集/削除することができますアクセス許可レベルを提供されていますので、箱から出して場合のみです。. 継承を通じて, 「貢献者" グループの可能性がありますもすべてのサブサイトでコンテンツを追加/編集/削除. 1 つことができる"破る" 継承チェーンとサブ サイトのアクセス許可レベルを変更してそのメンバーがいわゆる「寄稿者" グループは全然貢献できません。, しかし、読み取りのみ (たとえば). これは良い考えではないだろう, 明らかに, それは非常に混乱すると思いますので.
• グループは、サイト レベルで定義されていません. ユーザー インターフェイスが混同する簡単です。. マイクロソフトは、すべてのサイトの"ユーザーとグループでユーザー/グループ管理に便利なリンクを提供しています" リンク. それは簡単には私のサイト"xyzzy で信じ" xyzzy の人々 を使用してグループを作成して、グループは、xyzzy でのみ存在するグループを作成したリンク. それはケースではないです。. 私は実際に全体のサイト コレクションのグループを作成しました.
• グループ メンバーシップがサイトによって変化しません。 (すなわち. それはどこでも同じグループの使用): グループ所有者"を考慮します。" 2 つのサイト, 「HR" 「物流」. それは通常の 2 つの別々 の個人はこれらのサイトを所有するいると思うだろう — HR 所有者と物流の所有者. セキュリティ管理者がこのシナリオを誤って処理するが簡単なユーザー インターフェイス. 私はよく知っていない場合, HR サイトを介してユーザーとグループのリンクをアクセス可能性があります。, "所有者を選択します。" グループし、そのグループに私の HR の所有者を追加. 1 ヶ月後, 物流がオンラインになります。. 物流サイトからユーザーとグループにアクセスします。, "所有者をプルを追加します。" グループ. 人事担当者にして彼女を削除, 物流現場の所有者から彼女を削除いることを考えてください。. 実際, グローバルの所有者グループから彼女を削除して. はしゃぎのすさまじい.
• 特定の役割に基づく名前グループの失敗: 「承認者" グループは、完璧な例. 何ができるこのグループ承認のメンバー? 彼らはそれを承認することができます。? 私は本当に人々 物流部門人事文書を承認することができるをたく? コースではないです。. 組織内の役割に基づいてグループの名前を常に. これはグループが特定のセキュリティ保護可能なオブジェクトに対して不適切なアクセス許可レベルに割り当てられているリスクを軽減します。. 彼らの意図されていた役割に基づくグループの名前. 前の HR/ロジスティクス シナリオで, 2 つの新しいグループを作成する必要があります。: 「HR の所有者" "物流の所有者" およびそれらのユーザーを自分の仕事を行うに必要な最小限の各の良識があるアクセス許可レベルを割り当てる.

その他の有用な参照:

• Web アプリケーション ポリシー ガッチャ: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• SharePoint のセキュリティのためのクリアリングハウス: http://www.sharepointsecurity.com/
• Joel Oleson からのリンク: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

加えた場合それこれまでのところ:

私のコメントを介して自分の考えを知っている、または私にメールを教えてください。. 他の良い参照を知っている場合, 同じにしないでください。!