嗨，这就像一个非常广泛的问题。

基本上，GRC AC系统连接有许多RFC目的地，反之亦然。

Synchjobs也需要在GRC系统中维护。

此致

感谢您的答复。

很抱歉，我不是GRC人士，对此我也不是很了解。 同步作业和RFC已全部设置。 我们刷新了一个附属系统/受管系统，并在受管系统上保持用户主记录和RFC完整，但是安全团队抱怨说，从GRC角度来看，它破坏了用户到角色之间的链接。 因此，任何用户终止或角色删除实际上都不会从刷新系统中的用户中删除角色。

希望这有助于澄清

Stephan

Stephan，

我认为非生产更新是一个常见/已知问题：），因为受管系统上有一些特定于GRC的插件配置。您的GRC/安全团队是否对非生产系统使用了业务角色概念（GRC BRM） 并且他们是否还在非生产系统上使用访问请求（GRC ARM）。

谢谢

Ramesh

是的，他们正在使用业务角色概念和访问请求。 我们刷新的卫星/托管系统是一个preprod实例，它们与Production保持同步。 因此，基本上，当人们提出生产请求时，它将在预生产实例中进行相同的分配。 我们刷新了preprod，但保留了UMR的原始副本，因此不会有任何更改。

现在，他们抱怨大约50％的用户的链接断开。 但老实说，也许这些链接在刷新之前就已经断开了，但只有在刷新完成后才注意到。 不能100％确定。 我只是想知道是否存在与此相关的已知问题，或者是遵循刷新后的特殊刷新过程。

谢谢

Stephane

嗨，Stephane。

后端刷新后，没有特定的脚本可遵循。 如前面的答案中所述，您只需要：

1）确认从GRC到此后端系统的RFC连接是否仍在工作（此后端中的GRC用户密码可能已更改，或者他已被锁定）。

2）确保GRC用户没有在此后端系统中失去任何权限。

3）在GRC端确认是否有适当的作业（同步，FF日志收集，批处理风险分析等）仍在此后端系统上运行且没有错误。

关于业务角色，这确实是一个不错的功能，但是却很薄弱。 它是在GRC端处理的，后端没有任何可轻松实现对帐的控件。

但是请与您的GRC团队联系，因为在GRC方面需要进行业务角色分配，这应该使业务角色和技术角色之间的联系恢复。 您只需要注意，因为如果业务角色的内容已更改，或者在后端系统中手动维护了技术角色分配，则此工作还可以（重新）向用户分配技术角色。

此致

Marcelo Monsores