Microsoft Dynamics CRM 2016分配Activity权限限制的Security Role咨询

核心结论 #

该需求完全可通过原生Security Role权限配置实现，无需额外定制开发。配置核心是将所有Activity关联操作的权限边界严格限定在“用户本人拥有的记录”层级，杜绝全组织、跨业务单元的权限越界。

需逐项核查的具体权限项 #

核查需覆盖Activity基类下的全部子实体（包含任务Task、邮件Email、电话联络Phone Call、约会Appointment、传真Fax、信函Letter、循环约会Recurring Appointment等所有继承自Activity基类的活动类型），不要漏配：

• 实体基础操作权限（所有对应项的权限层级全部设置为User（用户层级））
  • Read权限：设为User层级。从数据查询层面限制用户仅能检索到Owner字段为自己的Activity，无法查看其他用户名下的活动记录
  • Write权限：设为User层级。Dynamics CRM 2016没有独立的“关闭活动”“响应活动”专项权限，用户对Activity的状态变更（标记活动为已完成、关闭活动、响应会议邀请、更新邮件跟进状态）本质都是对Activity记录的字段更新，完全受Write权限约束。只要Write权限限定为User层级，用户就无法修改、关闭不属于自己的Activity
  • Append/Append To权限：设为User层级。确保用户将Activity关联到其他业务实体（客户、商机等）时，不会因关联操作绕过自有Activity的权限边界
• 易遗漏的关联权限校验项
  • 核查是否存在Organization（组织层级）的ActivityRead权限：如果误配了组织层级的读权限，即使用户没有修改权限，也能通过高级查找、默认视图浏览看到全组织的Activity数据，存在数据泄露风险
  • 核查Activity对应的Bulk Delete批量删除权限层级：如果配置为Organization层级，用户可通过批量操作删除不属于自己的Activity，需将该权限调整为User层级匹配
  • 核查Activity参与方（Activity Party）的默认授权逻辑：如果用户是某个Activity的抄送收件人、会议参会人，默认会基于参与方关联关系获得部分访问权限。若需严格落实“仅作为Owner的Activity才可操作”的规则，可通过轻量插件补充校验Activity的Owner字段是否匹配当前操作用户，避免参与方身份带来的权限绕过
  • 核查共享规则带来的权限缺口：安全角色仅管控原生访问路径，如果Activity被共享给用户所在的团队、岗位，用户即便不是Activity的Owner，也会基于共享规则获得操作权限，这部分需配合日常权限审计同步排查

内容的提问来源于stack exchange，提问作者Supermode