SAP系统安全审核,对于企业来说,主要分为内部审核和外部审核两部分,而SAP内部审核分为用户安全审核和系统安全两大类,这里主要就SAP内部安全的审核方法给予浅析:
SAP主要通过ROLE,PROFILE两种方式来进行权限的管理控制，其中系统在安装初始阶段就已经包括了一些已经被系统定义好的重要的角色与参数文件，这些角色与参数文件一旦被分配，所持有者就可以对系统内部作出相应的管理操作，当然就会对整个系统产生非常大危险性，所以我们一定要在开始就得慎用，并且设定符合自身的管理规则.
首先列出应注意使用的参数文件:
对于以上的参数文件请按照以下控制策略进行恰当的使用：
1）尽量少的减少管理员与超级用户个数
2）参照想要实现的权限功能尽可能的复制新的参数文件，进行控制调整，避免使用原始参数文件所带来的控制漏洞
3）对管理员，业务人员，开发人员进行权限分类，避免混用权限角色与参数文件,必须遵守由业务部门跟审计部门共同制定的权限制度，避免冗余的CCA（职责不相容）出现 。
在SAP安装完毕后，也会有几个特殊的用户，在系统安装设置阶段，都要完成特殊的功用，那么我们在设置阶段结束后，一定要妥善的管理者几个用户：
1) SAP*—–系统初始用户，拥有系统所有权限
2) DDIC—-系统初始化进行配置使用的用户，拥有系统所有权限
3) SAPCPIC—-系统通讯用途的超级用户
4) EarlyWatch—–用来做系统分析的超级用户
控制策略：
通过以下参数设置可以制定用户密码策略：
在企业SAP运作中，SAP生产系统是整个企业的根本，任何数据的更改、后台设置的更改、系统参数的更改，都会对整个企业的数据流、业务流产生很大的影响，因此对于生产系统在上线以后数据出口一定要有严格的策略进行管控。
1）在SAP生产系统内，更新所有的公司代码为“生产”类型，通过执行OBr3，来检查并且保障设置正确。
2）SAP生产系统内，集团设定一定要标记为不允许作程序与配置更改，通过执行SCC4 与SE06进行设定。
3）SAP生产系统内，所有的更改策略都要围绕系统传输机制来完成，执行STMS控制上传请求号码。
SAP审计功能主要包括：
1)用户登陆及进程监控
2)文件类型已经文件变更纪录
3)开发纪录
4)系统日志文件审计
(从CCA安全意义来讲，由于SAP将AUDIT LOG以文件形式存储在SAP服务器上，所以原则上更应该将SAP管理员与OS管理员真正意义上分开来控制)
因此为了配合系统安全控制，SAP严谨的采用了自身的AUDIT 工具，系统内TRACE工具，可控制型TRACE工具，通过这些来进一步完善和加强系统安全。
系统安全控制策略如下：
基本监控策略：
1)每天作一次日常检查，通过ST22,SM21,OY18,ST02,ST04查看系统内的动作，控制每日的运行状态。
2)系统管理员通过STAT 监控每三天用户的系统动作，配合以SM20监控更详细的内容，并且对于用户的一些不恰当的操作可以通过SUIM来完成监控。
3)对于系统管理员的任何动作SM20也能够详细地反馈出来，每两周可以列出系统管理员的动作列表。
关于SAP审计：
广义其实指SAP basis security以及其OS，DB的audit，而狭义就是SAP FI/CO, MM, SD等提供的系统控制的审计。是吧。
SAP自带的审计功能有两个，一个是event level的audit log，参数 rsau/enable = 1开启该功能，再用SM19 configure 要审计的event，SM20来做audit log analysis。
另外一个是对table的审计，也就是对重要的数据参数表的变动进行审计，参数rec/client开启功能，根据管理层定义的SAP系统关键的数据表列表，使用SE13配置数据表的属性，启动这些数据表变更日志的功能。再用SCU3查看这些关键数据表的变更日志。
audit log 在操作系统上以文件形式存储的,因此没有sap_all却有操作系统root权限的一样可以删除日志.
所以OS admin 一定要进可能与 SAP admin 分开。
如果能做到这个SOD的话，即使有SAP_ALL在SAP上删除了audit log，但这个删除audit log这个动作是可以被SAP记录下来的。所以audit log依然可以起一定作用。
关注微信
