在Fortify里做权限，最容易出问题的不是按钮不会点，而是一开始就把“系统角色”和“项目访问”混成了一层。Fortify Software Security Center的官方文档写得很清楚，角色负责定义一个用户能做哪些动作，应用版本访问则决定这个用户能看和能操作哪些项目；同时，系统还支持自定义角色、LDAP角色映射，以及把用户单独分配到具体应用版本。也就是说，权限设计不是只建几个角色就结束，而是要把“能做什么”和“能进哪几个项目”分开管。

　　一、fortify工具怎么做权限

　　Fortify权限最稳的做法，不是直接给很多人Administrator，而是先按岗位拆角色，再给角色配权限。官方文档说明，SSC自带预置角色，也支持在Administration里的Roles页面新建自定义角色；新角色可以设置Universal access，并逐项勾选权限，但官方同时明确建议，Universal access只适合管理员级别用户。

　　1、先在【Administration】【Users】【Roles】里看现有角色

　　官方说明里写得很直接，想看不同角色到底能做什么，先进入Roles页面，再点开具体角色，就能看到该角色对应的权限明细。这一步特别重要，因为很多团队不是不会建角色，而是先没把系统自带角色看清。

　　2、再按岗位建自定义角色

　　如果默认角色不够用，就新建custom role。官方文档说明，创建角色时可以填写名称、描述、是否启用Universal access，然后通过【+ADD PERMISSIONS】逐项加入权限。也就是说，Fortify的权限模型本身就是按“角色加权限清单”来收的，不建议直接靠用户级临时加权来凑。

　　3、Universal access要慎用

　　官方已经明确提示，Universal access会把该角色直接赋予所有application versions的访问权，而且强烈建议只给administrator-level users使用。实际落地时，这意味着除了少数平台管理员外，大部分角色都更适合走“按项目分配访问”，而不是全局放开。

　　4、LDAP环境优先做角色映射

　　如果企业已经用LDAP管理用户，官方文档建议先决定哪些LDAP groups对应哪些SSC roles。这样做的意义很直接，用户的系统级权限由目录服务统一控制，后续人员变动也不需要每次都在SSC里重新手工分配。

　　二、fortify工具项目与成员权限怎么划分

　　Fortify里的“项目权限”，更准确地说，是application version访问权限。官方用户指南说明，用户是否能进入某个项目，不只看角色，还看这个用户有没有被分配到对应的application version；在编辑本地用户时，可以在Access区域删除或新增应用版本访问，在新建应用版本时也可以直接把团队成员分配进去。

　　1、项目访问按application version分配

　　官方文档写得很明确，编辑用户时，在Access区域可以删除已有application versions，也可以点【ADD】把用户分配到新的application versions。这个设计说明，Fortify项目访问本来就是精确到应用版本层，不是只按系统角色粗放控制。

　　2、成员划分先分平台管理员和项目成员

　　Administrator角色默认对整个系统和所有application versions都有完整访问权。官方文档也说明，管理员本身已经拥有全局访问，所以通常不需要再按项目做细分。实际划分时，更合理的做法是把管理员数量控制在少数，再把开发、审计、报告、集成账户这些成员放到项目级访问里。

　　3、项目成员更适合“小角色加小范围”

　　如果是开发者、审计人员或外部审核人员，更稳的方式通常不是给全局访问，而是给一份权限刚好够用的角色，再把访问范围限制在需要负责的application versions。官方关于创建新版本的说明里也体现了这一点，创建application version时就可以直接分配team members，而且本地用户和LDAP用户都支持。

　　4、批量成员管理优先走LDAP组

　　如果团队规模大、项目多，逐个用户手工加项目很快会变重。官方文档已经明确支持LDAP角色映射，而社区和官方资料也都围绕“组到角色”的方式来讲权限设计。对大多数企业来说，更稳的做法通常是系统级角色用LDAP组统一映射，项目访问再按application version精细控制。

　　三、fortify权限口径怎么收

　　很多团队后面越配越乱，不是因为Fortify权限模型不够，而是一开始没把“角色、项目、成员”三层收清。更稳的做法，是先定一套角色基线，再定项目访问规则，最后再决定成员通过本地账号、LDAP还是SCIM去接入。官方用户指南已经把这三层分别给出入口，角色在Roles页面管理，用户在Local Users或LDAP侧管理，项目访问则落在application version assignment上。

　　1、先定角色基线

　　先把管理员、项目负责人、开发者、审计者、自动化账户这些岗位拆开，再分别定义权限，不要让一个“通用开发角色”承担所有动作。因为角色一旦定清，后面项目授权就会简单很多。这个做法和SSC的角色加权限模型是一致的。

　　2、再定项目分配规则

　　哪些人按application version精确分配，哪些角色允许跨多个版本访问，哪些项目必须单独隔离，这些最好先收成统一口径。官方文档已经说明，application version访问是可以单独加减的，所以这一步完全可以制度化，而不必临时拍板。

　　3、然后统一成员接入方式

　　如果人少，Local Users够用；如果企业已经有目录服务，LDAP角色映射会更稳；如果身份体系更集中，较新版本还支持通过SCIM进行用户和组的外部管理。也就是说，成员接入方式本身也应该是权限设计的一部分，而不是后面临时补。

　　4、最后定期回看角色权限和项目访问

　　官方提供了查看角色权限明细的入口，也支持列出当前账号可访问的application versions。实际管理里，最好定期回看这些配置，避免角色权限越积越大、项目访问越加越散。这样做下来，权限体系通常会比只靠临时加人更稳。

　　总结

　　fortify工具怎么做权限，核心不是先给人开通账号，而是先把角色和权限清单收清，再决定哪些角色需要Universal access，哪些只保留最小权限。fortify工具项目与成员权限怎么划分，关键则是把application version访问单独管起来，让成员在角色之外，再按项目范围分配。把角色、项目、成员这三层拆开以后，Fortify的权限体系通常会比一开始更清楚，也更容易长期维护。