您好藤井太郎，

在这种情况下，GRC风险终结者是 一个不错的选择。 它可以使用默认的SoD矩阵或您创建的矩阵来进行analisys风险分析。 每当在配置文件生成器中创建新角色（TA：PFCG）或在用户创建中将其分配给用户（TA：SU01）时，风险终结者都会验证此创建/分配是否会导致违反SOD。 最后，它将显示您在公司中面临的风险。

直接使用SUIM，在系统中，创建冲突的角色计算方案会有些困难

还有其他选择 除了GRC之外，还可以使用，例如SAP（BOBJ GRC访问控制风险分析和补救），CSI（授权审核员），警报企业等。

如果您想直接与分开进行， 那么您没有什么选择

1。 使用程序rsusr008_009_new（关键组合）-将进行大量的阅读和调整以进行设置。 这样可以节省
中长期的时间。

2。 做我们在工具广泛可用之前所做的工作-创建不兼容功能的矩阵（具有业务和内部风险
管理/审计），将范围内的交易映射到该矩阵，然后分析
角色不应该在一起。 确保在分配访问权限时执行验证（如果您有免费的SoD作业，并且有一个用户只能拥有1个作业的策略，这将变得更加容易）。 修改角色或增加范围时，矩阵需要更新。

3。 利用您对S＆A的了解，可以说服您的雇主，他们可以通过实施一种工具来节省资金并降低风险。 有
个可用的工具，其费用与您花费
rsusr008_009_new开始工作所花费的精力类似。

请同时检查以下内容，

https://www.csi-tools .com/metas-blog/434-如何在关键系统中执行关键授权和sod-sod-checks

谢谢，

Kaushik

您能解释一下我如何在标准SAP中管理SoD吗？
我的客户希望在不使用SAP GRC访问控制的情况下防止和检测SoD冲突。

首先，管理标准角色的SOD毫无意义。 标准SAP角色应始终复制到客户名称空间（Z角色等）。 如果您的客户不想使用GRC ARA，那么您将面临巨大的任务。 您的客户将必须指定他们所有的业务和职能线索，以概述所有关键流程以及T代码。 获得此权限后，您将决定将使用哪种角色结构（单一，复合或派生）？ 这完全取决于角色构建要求以及您将如何限制SOD，这非常罕见，您仅凭T代码就可以实现这一点，我主要涉及ORG UNIT，COMPANY CODE，文档类型，ACVT等。

我知道我们可以使用SUIM（用户信息系统）列出所有角色和用户。但是，我认为此交易代码与SoD无关。

SOD肯定与T代码相关联，但是您应该更深入地了解auth对象和该级别的特权，以实现更全面的SOD矩阵。

请注意，当通过SU01，Su10手动分配角色时，不会对违反SOD的行为进行检查。 强烈建议任何认真对待SAP中的安全性和隔离性的公司都应该考虑实施GRC。

要记住的另一件事是，具有强大的SOD并不能解决所有可能的情况。 客户还必须考虑缓解控制。 给用户SAP_ALL而无需进行任何审核检查或冒风险的日子已经一去不复返了，（GRC EAM）我有两种感觉；）

Michael