身份安全 | 特权管控难题之应用系统特权

堡垒机、特权账号管理系统等主流特权运维安全产品能解决的是运维账号、特权账号的合规性授权、统一入口、安全审计问题。但这里注意的是他们所能管控的运维账号、特权账号，仅涵盖了操作系统、数据库、网络设备、安全设备等IDC设备的特权。

主机管理员、DBA、网络管理员、业务系统主管、应用系统厂商实施人员、应用系统IT管理员、API接口代码等等；这里我们能够借助于堡垒机、特权账号管理系统等实现特权的集中管理、集中授权发放及回收、过程访问控制等从而达到事前、事中管控的目标，但所能管控的同样有限，仅有主机管理员、DBA、网络管理员。

我们可以借助于特权账号管理系统实现对主机、数据库、网络设备、安全设备等整个IDC基础设施的资源进行定期修改密码、密码申请、公私钥生命周期管理，但我们的应用系统、API接口中的特权密码却因代码编码限制、业务管理限制、应用系统厂商限制，无法对超大权限的管理账号、授权账号做密码的定期修改。

目前市面上比较成熟的堡垒机、特权账号管理产品都可以在主机、数据库、网络设备、安全设备等整个IDC基础设施层面实现事后全过程的监控视频审计。但我们的应用系统、API接口中的特权就仅能凭借应用系统本身的日志进行事后审计。

A11.2.2 特权管理：特殊权限管理，应限制和控制特殊权限的分配及使用；

A11.5.2 用户标识：所有用户应有唯一的、专供其个人使用的标识符（用户ID）

应选择一种适当的鉴别技术证实用户所宣称的身份；

A10.10.1要求组织必须记录用户访问、意外和信息安全事件的日志，并保留一定期限，以便安全事件的调查和取证；

A10.10.4要求组织必须记录系统管理和维护人员的操作行为；

A15.1.3 明确要求必须保护组织的运行记录；

A15.2.1则要求信息系统经理必须确保所有负责的安全过程都在正确执行，符合安全策略和标准的要求。

8.1.4.1 身份鉴别：应对登录的用户进行身份标识和鉴别，身份标识具有唯一性；

8.1.4.2 访问控制：应授予管理用户所需的最小权限，实现管理用户的权限分离；

8. 1.5. 1 系统管理：应对系统管理员进行身份鉴别，只允许其通过特定的命令或

操作界面进行系统管理操作，并对这些操作进行审计；

8.1.4.3 安全审计：应启用安全审计功能，审计覆盖到每个用户，对重要的用户

行为和重要安全事件进行审计；

8.1.5.2 审计管理：应对审计管理员进行身份鉴别，只允许其通过特定的命令或

操作界面进行安全审计操作，并对这些操作进行审计；

应用系统的出厂内置管理员账号admin/sysadmin通常并不具备用户实名制唯一标识的特质，通常是会被应用负责人或厂商运维人员掌管着账号密码。在使用过程中由使用者人为输入账号口令进行登录。（如图1所示）解决的关键借助于一个特殊的平台作为跳板，能让用户通过自己的个人账号进行登录认证，成功后再通过这个特殊的平台访问应用系统的特权，这样就可以解决实名制问题（如图2所示）

特权账号在使用过程中应用负责人通常会将账号、口令转告知第三人。这么以来管理员账号的密码就会不经意地传给第三个、第四个...导致特权账号密码扩散的风险，所以我们将通过密码定期修改、密码自动代填或基于票据的方式由中转系统自动完成应用系统的特权登录过程，避免使用者因登录需要而知晓密码。

通常企业中申请使用特权账号的方式：管理员代为输入口令、邮件申请、工单申请、微信、钉钉等。那么这些方式的通病就是授权的过程不严谨导致申请记录无从查起；授权之后权限不能及时主动的收回。为了避免这种情况多数企业都会将所有的权限相关与流程工单系统进行结合，如OA、BPM等，用户通过流程工单走线上的特权申请，并备注使用的周期。工单由相关干系人完成审批后由中转系统自动完成自然人（特权申请人）与应用系统特权的授权映射过程。用户登录中转系统即可查阅自己的应用特权权限。最后在特权申请时间结束后中转系统自动完成自然人（特权申请人）与应用系统特权的授权关系解除操作，那么用户也是无法再次访问特权账号的。