GRC访问控制管理方案

1、SAP GRC项目访问控制方案设计SAP GRC项目组2012-10-20文档版本记录版本号更新日期更新摘要更新人V1.0V2.0V2.1V2.3文档审批与查阅记录版本号审阅日期审阅人职位审阅人备注V1.0V2.0V2.0V2.1V2.2目录1 项目整体介绍51.1 GRC项目实施的背景51.1.1 什么是GRC?5为什么要实施GRC?51.2 GRC AC的应用价值62 项目目标如何实现对权限的管控72.1 GRC10.0技术架构72.2 访问控制风险分析和改进ARA（Access Risk Management）72.2.1 规则架构82.2.1.1 FunctionSAP中的业务操作82

2、.3 企业角色管理BRM(Business Role Management)102.3.1 功能列表102.3.2 项目过程中的角色重组和设计112.3.4 角色日常维护与风险分析、改进122.4 用户授权管理ARQ(Access Request)132.5 特权用户紧急登录生产系统管理EAM(Emergency Access Management)172.5.1 特权用户范围17 基本功能和架构概览183 项目实施和管控20项目准备20蓝图设计21配置实现21上线211 项目整体介绍1.1 GRC项目实施的背景1.1.1 什么是GRC?GRC是Governance, Risk, Compli

3、ance三个单词的缩写。Governance指的是治理，包含公司治理、IT治理相关的内容；Risk指的是风险，由于不同行业对风险的定义略有不同，这里只认为风险是消极的事件，可能会造成损失；Compliance是合规性或者一致性，既包含外部法律法规的合规也包含内部政策、程序的合规。1.1.2 为什么要实施GRC?（1） 企业自身业务发展的需要，具体包括：· 企业内部管控的需要：由于越来越多的业务运行在信息系统上，需要一个统一的平台来分析和处理系统中以及业务中存在的风险。· 完善风险管理的需要：企业的风险管理不是孤立的、只由一个部门来考虑的问题，而是需要全员的参与，乃至形成企业

4、文化的一部分。因此，需要一个能将风险思想传递到每个部门、每个员工的信息平台。· 业务部门与IT部门之间的鸿沟容易导致低效率和控制的缺失，需要一个既能保证有效的控制，又能提高效率的工具。（2） 外部法律法规的要求：目前，已经很多法律法规对内部控制做出严格要求（举例见下表），GRC_AC能够帮助我们快速、高效的遵从这些法律法规。名称发布机构发布时间实施范围实施时间企业内部控制基本规范财政部、审计署等机构联合发布2008-6-28国内上市公司2009-7-1企业内部控制应用指引财政部、审计署等机构联合发布自2008年6月陆续发布国内上市公司2009-7-1企业管治常规守则香港联交所2004

5、年11月香港上市公司2005-1-1企业管治报告香港联交所2004年11月香港上市公司2005-1-11.2 GRC AC的应用价值· 分级管控规则制定集团管控 VS 企业个性化需求· 信息系统的授权不再是企业各行其是，而是按照集团审批通过的岗位设置、职责分离原则进行授权，在集团能够掌控系统中存在的风险的同时，兼顾企业自身的需求。· 实时违规分析与授权企业风险责任 VS 授权需求· 将风险管理的意识推广到集团各级，使下属企业不再是单纯的考虑权限需求，而必须关注其中存在的风险。· 定期检查与评估连续审计 VS 审计取证· 对信息系统进行

6、实时的监控，可以及时预警并保证审计轨迹的完整性，实现对信息系统及相关业务的连续审计。· 技术支持的持续优化安全管理 VS 授权操作· 使信息系统的管理人员可以更加全面的履行安全管理的职责，而不是简单的执行授权的操作。2 项目目标如何实现对权限的管控2.1 GRC10.0技术架构2.2 访问控制风险分析和改进ARA（Access Risk Management）具备集中式访问分析引擎与一个直观的界面，支持结束用户自定义和个性化。新的功能支持分散式的维护、自动化、审计，新的风险补偿选项带来了一个更快和更有效的路径来合规。解决方案概要优势要点新界面允许有针对性的风险分析，比如导入

7、功能，编辑功能和重用风险分析标准更高效的、灵活的访问风险分析选项和能力，提高了分析结果新功能允许定制和个性化访问风险结果更快的部署和更简单的数据维护可以分析Business Role 和 CUA composite role的风险减少跨application的访问控制的时间新功能允许从系统层面补偿风险或是如果RULE ID来补偿工作流包括路由和升级的逻辑,通过利用标准化工作流程引擎统一的实现允许大批量补偿包括分配，更改和批量更新按照模块来维护的工作流增强的审计功能2.2.1 规则架构GRC风险分析的前提是事项的识别，也就是建立风险分析的规则架构，具体包括：梳理SAP中的操作（Function）

8、；定义职责分离的规则与关键操作。FunctionSAP中的业务操作Function指的是SAP中一组功能相似的操作，同时还包括这些操作所涉及的对象与值。这些构成风险分析规则的基础，也是角色重组时的依据之一例如：Function CategoryFunction IDDescription中文描述SDAR04AR04 - Credit Management信贷管理SDAR05AR05 - Maintain Billing Documents维护系统发票SDAR06AR06 - Process Customer Credit Memos处理客户贷项凭证FICOCC01CC01 - Maintain

9、 Cost Center Distributions维护成本中心分配FICOCC02CC02 - Maintain CC or CE Groups维护成本中心或者成本要素组FICOCC03CC03 - Maintain Cost Centers维护成本中心MMPR01PR01 - Vendor Master Maintenance供应商主数据维护MMPR02PR02 - Maintain Purchase Order采购订单维护MMPR03PR03 - Service Master Maintenance服务主数据维护PPPP01PP01 - Confirm Production Order确

10、认生产订单PPPP02PP02 - Production Order Processing生产订单处理说明：（1） Function Category指的是Function按照业务模块的分类。（2） Function ID指的是系统中的ID号。（3） Function在实施过程中已经结合了我们集团自身业务，增加了自定义的程序、报表，以及需要特殊管控的对象、值，详见附件。（4） 在系统日常运行中，实际业务常会变化。因此，需要对应的检查Function是否需要随之变更，详细的流程见。2.2.2 风险识别在上一节对Function梳理的基础上，根据SOD（职责分离）的原则定义了不同Function的

11、组合所产生的风险，以及所需关注的关键操作，例如：Risk IDFunction DescriptionRisk LevelRisk TypeDetailed Description中文描述F001GL02 - Maintain GL Master Data & GL01 - Post Journal EntryMediumSegregation of DutiesCreate a fictitious GL account and generate journal activity or hide activity via posting entries.通过过账条目创建虚拟总账科目、

12、生成日记账活动或隐藏活动。F002CC06 - Cost Transfer Processing & CC03 - Maintain Cost CentersMediumSegregation of DutiesAlter a cost center without authorization and process unauthorized cost transfers to this center, possibly distorting CO reporting.未经授权而改变成本中心并处理未授权的成本转账，这很可能会篡改 CO 报表。说明：（1） Risk ID是系统中此风险规

13、则的ID。（2） Function Description 是对此规则涉及到的需要分离的功能(Function)或关键操作的描述。（3） Risk Level是风险等级，可以根据自身的风险偏好进行调整。（4） Risk Type是风险的类型，具体分为Segregation of Duties和Critical Action。（5） 在项目上线后的日常运行时，业务的变更会导致风险规则的变更，因此，需要检查规则是否要做相应调整 2.3 企业角色管理BRM(Business Role Management)访问控制提供了可扩展的和协作业务角色建模,支持技术和业务两方面用户。支持设计的集中的,顺从的角

14、色通过健壮的角色治理过程。解决方案概要优势要点新的集中的业务角色管理与嵌入式访问风险分析协作化的角色治理，定义的设计过程避免了业务和技术owner之间设计过程的反复增强的映射流程和技术化的业务访问授权功能执行职责的分离，从最基础的角色设计开始监控，使用干净的角色新角色设计和灵活的角色构建工作流,包括预防性模拟过程流线型的角色设计简化管理新的功能来分析角色的使用情况和优化角色分配，保持角色的定义实时更新优化角色定义，减少角色冗余改进的角色比较，以便检测后端变化，并提供角色一致性,同步和遵从性报告新流程定期的角色认证过程2.3.1 功能列表New FeaturesCertification Pro

15、visioning EnhancementsRole MappingSAP Role MaintenanceRole Derivation Role Update / Mass Role DerivationCUA Composite RolesAdditional FeaturesRole Management CustomizingSettingsBRF+Workflow Role Owner2.3.2 项目过程中的角色重组和设计角色重组和设计的目的（1） 消除角色层面的风险。（2） 便于无风险的用户账号的快速提供。（3） 建立清晰的，基于风险分析的，便于长期维护的角色体系，形成SAP应用

16、安全的基础。角色重组和设计的原则（1） 与业务类型、组织结构相结合：在Role重组的过程中充分考虑集团业务类型与组织结构。例如Role按公司或组织的类型分为工厂、共享服务中心等，在名称上即给予区别。（2） 与实际业务中的岗位设置相结合：梳理每个岗位的职责，避免因人设岗。例如共享服务中心的即使用了集团设置的标准的财务岗位。（3） 可重用性：结合实际业务与风险分析的规则，定义粒度较小的模板Role，可反复用于派生或组合成新的Role。（4） 职责分离：充分考虑职责分离的规则，在单个Role层面实现无SOD冲突。（5） 统一性：充分考虑整个集团所有的业务，各公司的Role均按照统一的规则进行派生、复

17、合。2.3.3 重组后的参考角色体系模板ROLE模板Role描述派生ROLE复合ROLE岗位描述T_FI_GL01_Post.Doc一般凭证记账D_FI_LG_GL01_Post Docs_01C_FI_LG_GL POST总账凭证记账T_FI_GL01_Doc.Dsp一般凭证显示D_FI_LG_GL01_Doc.Dsp_01T_FI_GL01_Doc.Rev一般凭证冲销D_FI_LG_GL01_Doc.Rev_01T_FI_Doc.Chg一般凭证修改D_FI_LG_GL01_Doc.Chg_01显示预制凭证(FV50显示）T_FI_G/L.Clear总账清账/重置已清项D_FI_LG_GL0

18、1_G/L.ClearC_FI_LG_GL Clear总账清账T_FI_Doc.Dsp一般凭证显示D_FI_LG_GL01_Doc.Dsp_01说明：（1） 模板Role即粒度最小的Role，不包含组织级别的值，不直接赋予用户，仅用来派生出各组织级别的派生Role。其命名规则为：T(Template) +,模块名（例如FI表示FI模块，） + 具体操作的描述。模板Role层面保证没有风险冲突，是用来生成全集团使用的其他角色。（2） 模板Role描述保证了能从其中直接看出Role的功能。（3） 派生Role在模板Role的基础上添加了组织级别的信息，用于组合成复合Role，也可直接赋予用户。其命

19、名规则为：D(Derive) + 模块名称 + 公司代码+ 具体操作的描述。由于是从模板Role派生而来，因此也是没有风险冲突的，如需调整，只需更改模板Role便可实现全集团范围内的统一更改，因此便于长期的使用、维护。（4） 复合Role是根据实际业务中的岗位设置，同时参考职责分离的规则制定的，是由派生Role组合而成。C (Composite) + 模块名称 + 公司代码 + 岗位描述。复合Role可能存在风险冲突，但是可能实际业务中需要的，可以对其创建Mitigation。2.3.4 角色日常维护与风险分析、改进在GRC的模板项目中，已经对SAP中的Role做了全局性的规划，但是在日常业务

20、中，以下几种情况还是会导致SAP中角色的变更：· 新工厂上线· 新增的二次开发的程序、报表· 支持人员在处理用户权限申请时找不到合适的角色· Basis检查发现Role存在风险。参考流程图：2.4 用户授权管理ARQ(Access Request)在SAP业务工作流基础上的技术访问控制规范，并支持更灵活的、量身定制的访问请求和批准者的视图，简化配置过程。 解决方案概要优势要点基于SAP标准工作流技术的工作流业务工作流可以减少人工任务，并提供平滑的访问请求处理访问请求增强功能:n新的定制访问请求形式n新模板的访问请求n新的角色定位分配请求n新用户层面显示的

21、配置文件,访问作业,可查的请求历史可以利用现有的资源工作流管理和配置增强的角色，用户组，基于系统的权限查询功能更快更简单的让用户来申请他们所需要的角色可自定义的审批人界面利用现有的人力资源结构提供自动化和兼容的定位角色分配多样化的规则库支持更强的安全控制和丰富请求的内容周期性的用户访问和访问风险审查工作流结构图在实施阶段清理完所有的风险后，要使系统持续的保持无风险的状态，必须从用户权限授予阶段即进行风险分析（可选），将风险的意识贯彻到业务的各个层面。此流程在保证用户层面无风险的同时也会提高现有授权管理的效率，优化的流程可以在IT部门建立好角色后，使用系统自动授权的流程进行自动授权（可选），参考

22、流程图如下：说明：（1） 用户方权限收集人登陆GRC提交申请，在申请中说明所要的权限。（2） SAP支持人员确认关键用户的申请，并选择相应的角色。（3） 关键用户（一般也是SAP小组人员）登陆GRC执行风险分析，如果有风险，则需检查权限授予是否必须（最小授权原则）。如果的确必须，则转入补偿控制流程。如果不是必须，则需修改授权，重新提交；如果没有风险，则直接审批通过。（可选步骤）（4） 用户方负责人登陆GRC审核。（5） 权限已经分配到系统中（6） Basis最终确认执行结果（可选）（7） 用户使用和测试，授权流程完成。注：GRC的工作流节点和流程可以客户化定制，在流程中任意节点都可以加入风险分

23、析的步骤以及对需要添加的角色进行变更，在流程结束后，系统会自动将角色provisioning到目标系统中并和用户自动匹配2.5 特权用户紧急登录生产系统管理EAM(Emergency Access Management)Access control集中了对权限较大却又属于日常运维和必须的业务流程中存在的系统用户，如firefighter（救火员）以及系统管理员和业务顾问的访问和管理,增强了配置和提供自动化日志审查过程。解决方案概要优势要点管理员集中管理救火员分配,风险控制者,和其他的主数据。集中式的救火员管理对救火员行为的简单管理具备新的功能选项来定义用户组所有者和风险控制这和以此改进合规减少

24、重复作业，简化系统管理员管理可以通过没有定制计划的救火员任务来更新救火员的操作日志通过事前控制系统中的风险行为提高日志审查效率可以从事务代码的报告中提取特殊的日志报告改进日志报告的导航基于工作流的救火员日志报告2.5.1 特权用户范围SAP中进行日常业务操作以外的用户均应属于特权用户的范围。此类用户登陆SAP一般只是为了特殊的需要，例如支持人员帮助用户查看问题、实施顾问实施期间的权限等。我们计划逐步将此类用户纳入GRC的管理范畴。用户类别举例用户权限集团内部审计根据审计范围，赋予相应的权限。（只能显示，不能操作）外部审计根据确定的审计范围，经过集团确认，赋予相应的权限。（只能显示，不能操作）S

25、AP顾问根据项目实施、上线需要及集团权限管控要求，赋予相应的权限。（有显示，有少部分操作）SAP支持人员根据日常支持工作的需要，有一定范围内的显示权限，主要用于问题解决。基本功能和架构概览 Firefighter 简介GRC的特权用户管理模块包含以下几类主要的功能角色：Ø AdministratorFirefighter”配置；分配“Owner”和“Controller”给“FirefighterID“，一般为BASIS或者IT技术顾问负责Ø Owner分配“FirefighterID”给“Firefighter”；分配他们负责范围内的“FirefighterID”给“Co

26、ntroller”，建议为项目经理或者部门负责人对日常和项目中的FFID进行分配，目前由BASIS暂代处理。Ø Controller检查“FirefighterID”分配日志报告；接受“FirefighterID”登录时产生的邮件，建议由GRC顾问担任Ø Firefighter需要通过“Firefighter”功能登录到系统的用户，如实施顾问、支持顾问，目前系统中包含支持顾问，项目实施顾问，后续建议加入其他顾问，如：ABAP开发顾问、BASIS顾问、MDMC主数据部门顾问等。该模块功能主要针对日常业务支持运维和项目实施中，权限非常大，但是又不能取消的一些特殊的用户。我们称之为firefighter救火员。这些FF的账号用于处理紧急生产系统中的一些问题，保证关键业务的运行，为这些业务提供支持。在传统运维对这一类关键用户进行权限的管控的方式是最小授权原则，在处理业务的同时，需要反反复复的添加删除权限至合适，同时也要对所有申请审批。可能会延迟关键业务的执行时间，导致了业务中断的可能性大大增加。为了均衡效率和风险，就引入了Firefighter的概念，一个账号