SharePoint 安全性基础知识入门 / 避免常见的陷阱

更新 12/18/07: 请参阅删除或修改默认的组名的一些技术的后果 Paul Liebrand 文章 (见他下面的评论以及).

概述:

SharePoint 安全是易于配置和管理. 不过, 它已被证明是真的包装他们的手在它附近一些第一次管理员难以. 不只如此, 我见过一些管理员来到一个完美的理解,在周一只把它丢了周五因为他们没有做任何配置在这段时间. (我承认对这一问题我自己). 这篇博客希望提供一个有用的 SharePoint 安全引子和指向一些安全配置的最佳实践.

重要说明:

这种描述基于开箱即用 SharePoint 安全. 我个人的经验被面向各地苔藓,所以可能会有一些苔藓的具体东西在这里, 但我相信它是准确的 WSS. 我希望看到的任何错误或遗漏的任何人都将点,在评论中或 电子邮件通知我. 我会改正后匆忙.

基础知识:

为施行本概述, 有四个基本方面对安全: 用户/用户组, 安全对象, 权限级别和继承.

用户和组 打破降到:

  • 个人用户: 从活动目录或创建在 SharePoint 中直接拉.
  • 团体: 从 active directory 直接映射或在创建 SharePoint. 组是用户的集合. 组是全球化的站点集合中. 他们永远不会"绑" 到特定的安全对象.

安全对象 打破降到最少:

  • 网站
  • 文档库
  • 列表和文档库中的各个项
  • 文件夹
  • 各种 BDC 设置.

那里其他安全对象, 但是你图片.

权限级别: 捆绑的颗粒 / 在列表中包含诸如创建/读取/删除条目的低级别的访问权限.

继承: 默认情况下从其包含的对象实体继承安全设置. 子网站从其父项继承权限. 继承他们网站的文档库. 等等等等等等.

涉及通过继承和权限级别的安全对象的用户和组.

最重要的安全规则,来理解, 曾经 🙂 :

  1. 组是简单的用户的集合.
  2. 组是全球网站集内 (e 小节. 没有这种东西在站点级别上定义的一个组).
  3. 不耐的组名称, 团体却不, 本身, 有任何特定的安全水平.
  4. 组在某一特定的安全对象的上下文中具有安全.
  5. 可将不同的权限级别分配给每个安全对象的同一组.
  6. Web 应用程序策略胜过所有这一切 (请参阅下面的).

安全管理员迷失在海上的组和用户列表可以始终依靠这些公理来管理和了解他们的安全配置.

常见的陷阱:

  • 组名虚假地暗示的权限: 开箱即用, SharePoint 定义一组组名字暗示了固有的安全级别. 考虑"参与者"组. 一个熟悉 SharePoint 安全性可能会看看那名字,假设,那组的任何成员可以"作出贡献" 对任何网站/列表/库在门户中. 这可能是真的,但并不是因为该集团的名字恰巧是"讨论参与者". 这是唯一真正开箱即用,因为该集团提供了权限级别,使它们能在根站点添加/编辑/删除内容. 通过继承, "参与者" 集团也可能在每个分站点添加/编辑/删除内容. 一个可以"打破" 继承链和更改权限级别的子站点这种所谓的"参与者的成员" 组不能作出贡献, 但只读取 (例如). 这不会是一个好主意, 很明显, 因为它将是非常令人困惑.
  • 组不在站点级别定义. 它很容易被混淆的用户界面. Microsoft 提供了方便的链接到用户/组管理通过每个站点的"人和组" 链接. 很容易相信,当我在网站"xyzzy" 我创建一个组通过 xyzzy 的人和团体联系起来,我只是在 xyzzy 创建只存在一组. 这不是个案. 我实际上已经创造了一群为整个网站集.
  • 组成员资格不会由站点不同 (e 小节. 它是一样到处都使用组): 考虑"所有者组" 和两个站点, "HR" 和"物流". 它会正常想两个独立的个体将会拥有这些网站 — HR 所有者和物流所有者. 用户界面轻松安全管理员责难这种情况下. 如果我不知道更好, 我可能会访问的用户和用户组的链接,通过人力资源网站, 选择"业主" 组并向该组添加我的 HR 主人. 一个月后, 物流上线. 访问从物流站点中的用户和用户组, 添加"业主拉起" 集团. 我看到那里 HR 所有者和删除她, 我在消除她从所有者在物流网站的思考. 事实上, 我在消除她从全球的所有者组. 接着而来的欢乐.
  • 对基于特定的角色的名称组失败: "审批者" 组是一个完美的例子. 什么可以这组批准成员? 他们在那里能批准它? 我真的想人物流部门能够批准人事相关文件吗? 当然不是. 始终命名组基于其在组织内的角色. 这将减少风险的组分配特定的安全对象所需的权限级别. 基于其预期角色名称组. 在前面的 HR/物流场景, 我应创建两个新的组: "HR 业主" 与"物流业主" 和分配每个明智的权限级别和对这些用户做他们的工作所需的最低金额.

其他有用的引用:

如果您做了它这远:

请让我知道你的想法通过评论或给我发电子邮件. 如果你知道其他有益的参考, 请这样做!

Technorati 标签:

8 上“的想法SharePoint 安全性基础知识入门 / 避免常见的陷阱

  1. 佩里

    更多的陷阱:

    * 有某些特殊权限可用 SSP 中的其他地方,并在用户和用户组部分中不可见: "个性化服务权限"和"业务数据目录权限"

    * 我读了我们还有 SharePoint 设计器的特殊权限在埋葬在某处的 html 一些神秘 xml 中可用.

    * 小学和中学为网站集的管理员是其他地方保存在网站集的设置, 在用户和用户组部分中,均不可见.

    * 特定帐户具有神奇 (特别) 无论您在用户和用户组区域中看到的能力: 在 web 服务器上的内置管理员组的成员, 和农场服务帐户.

    (PS: 删除垃圾评论将改善这里的易读性。)

    答复
  2. 让 · 赖特
    这是一个很好的职位. 我有几次落入这种陷阱. 安全管理可以得到复杂,当你开始混合使用的身份验证方法和不同的安全的分组方法. 这需要被视为规划过程的一部分,不应忽视.
    答复
  3. 马克 · 米勒写道::
    (注意从保罗: 马克问我对他的评论作出小小的改变,但不能编辑活空格评论所以我添加它重新在这里与更改和删除原始).
    保罗,
    提交此信息的摘要方法来很好. 我尤其喜欢"陷阱" 一节, 因为我已经陷入的那些自己几个.
    另一件事你说击中要害: 周一的学习并不一定意味着你会记住它上周五. 我很高兴有人除了我之外使用自己的博客作为"tickler" 这些关键的事情没有做定期的系统.
    良好的工作.
    问候,
    马克
    EndUserSharePoint.com

    11 月 27 9:04 上午
    (http://www.EndUserSharePoint.com)

    答复
  4. 保罗 · 高尔文
    我认为它可能是一个好主意,要删除这些默认组, 特别是部队派遣国和所有者. 他们是过于宽泛,很容易产生混淆. 我更喜欢使用"所有经过身份验证的用户" "访问者的位置" 集团以及. 如果一组特定的用户应该只有只读访问权限,然后我会建议您创建 AD 组或 SharePoint 组,适当描述性的名称, 例如:. "物流访客".
    –保罗 · G
    答复
  5. 没有名称
    听起来好像你应该做的第一件事是只转储访客, 部队派遣国和所有者组和它们替换为您自己的逻辑组. 这是有意义吗?
    答复

留言

您的电子邮件地址不会被公开. 必需的地方已做标记 *