两年间，安在采编“诸子云”社群日常交流（各会员群内脑力碰撞）之精华，出品“微话题”栏目，两年多时间里，先后整理上千次讨论，汇整数百个热点话题，发布数十期文章，涉及企业网络安全最佳实践方方面面、角角落落。与此同时，我们还以月为单位，把所有经过整理的讨论内容归档到诸子云知识星球，让微话题可沉淀、能检索，成为可持续输出价值的甲方“新鲜事儿”。
我们诚挚欢迎更多朋友进入到诸子星球，参与话题讨论。
本期“微话题”，我们从“诸子云”社群里选取了两个引发热议的小话题为读者们予以呈现，分别为“重要岗位离任时，会审计信息安全类的内容吗？一般都会包含哪些？统一认证平台，哪家做的比较好？”
重要岗位离任时，会审计信息安全类的内容吗？一般都会包含哪些？
来源：诸子云上海分会
时间：6月29日
观点1：
当然要做，一般包含账号，离职前行为审计，离职期间行为监控，离职倾向、离职去向、数据泄露转存之类。还查DLP记录，看岗位做，全做不容易。如果有一整套的解决方案机器自动跑，就简单，把离职审计加到员工离职的流程里。
观点2：
那主要是查离职期间的行为轨迹，岗位经手的信息资产方面有什么可以去做审计的吗？离职审计这个活动是已经在离职流程里的，只是针对重要岗位离职审计内容方面，原先主要是针对：人、财、物 这方面做审计。但在信息资产方面，信息安全方面的审计内容。我觉得不是很清晰。
观点3：
看风险。如果接触很多机密信息，还是应该审计。信息泄露这些有UEBA的话，一下子就串出来了，要联动把系统日志串起来。UEBA有一个现成拿来开箱即用，本质上还是自己有规则模型在跑。这个日常监控也是会用到的，只是在离任审计中再将这部分做一下复查。多了一个拉开时间线的比较，再加上颗粒度可能要更细。
观点4：
离职审计最好具备实时阻断能力...很多人lastday最后一刻转移数据。离职审计是在离职过程中的活动节点，如果审计不通过，离职过程也会受阻。这个要有正规termination process，可以用刑法第二百一十九条吓唬一下……然后就删掉了，然后离职转辞退。一开始HR也不愿意给我们数据，说是高度敏感数据，后来我们就抓了几个HR……其实大部分人，也不是一定要硬杠，你只要立刻发现及时拦截，大家也就老实了。
观点5：
我们先不纠结法律问题，先考虑离任审计中就信息资产审计的必要性。如果存在疑似信息安全风险，也可以做一下阻断工作。UEBA分析他要离职了，先给他换个岗位脱离核心。我原来准备挖阿里的DLP专家，阿里说脱敏期半年，我就拉倒了。监控逻辑要建，可视性的提高是必须的。但如果平常也不监控，那倒确实没必要专门为离职建一个。
观点6：
我的理解：审计必要性是有，审计内容和形式要根据已有的信息安全监控能力来确定；如果基础能力还不具备，则需要考虑投入产出效益。先从基础建设着手了。先看看自己公司有啥重要的不能外漏的，再看看离职人员的岗位职务，重要岗位涉及核心业务的，做，不重要的普通员工，放；总不见得一个不在办公室走动的清洁阿姨离职，也花钱去做离职审计吧，公司也不是钱多到这种地方，纯消耗的没意义。离任审计的受众岗位定义一般是：研发类总监及以上岗位；总部职能线总监及以上岗位；分公司总经理...基础普通员工，都不会去做离任审计的。
来源：诸子云深圳分会
时间：6月9日
观点1：
通过统一认证平台，实现单位内部多平台、多业务、多场景的统一身份认证和授权管理，实现用户密码的便捷化管理，支持生物特征识别登录等功能。好像去年也有这类产品报告。这个领域还是很多厂家做的都不错的，你说的都是标准功能。IAM，比如IBM，但是我最近了解到有的厂家（不知道是不是所有厂家）为了支持LDAP协议，还需要你在IAM之外再配一个AD，我就有点抓狂了……
观点2：
微软的域控？有些设备、系统只支持LDAP认证，然后就要求你再装一个AD，最后上了IAM，结果这部分实际认证都是到AD去认证。国内的竹云、派拉、申石，国外的ibm，oracle，最近比较火爆适合云原生环境的okta、adptive等等。统一身份，统一认证好做；统一授权比较复杂，这对于已有AD的情况下还好，如果需要新增AD的话，阻力会有些大。
观点3：
统一授权可以了解下硅孚.授权和具体表现应用是强相关的，有大量应用改造的工作。一般是平台搭建好，先从统一认证开始做，统一授权功能一个个系统去推，对接旧业务的时候涉及系统改造，阻力会比较大，还会涉及一个portal门户，轻重可以根据实际情况去做。IAM项目都是长期性的，最重要的还是通过项目形成一套接入标准，后续新增的业务应用就可以按照标准规范快速接入了。
观点4：
通常做4A都是先做，统一身份和统一认证；权限后面慢慢去集成；或者，简单粗暴的在资源url上用网关做个条件访问。不涉及应用改造的统一授权管理方案几乎没有。统一授权细粒度很高，需要付出的工作量极大。你做个对接也算是改造了，毕竟你要废掉别人原本的认证方式。应用系统的授权属于应用运维的一部分，大多数都是各个业务系统自己有套逻辑。多系统，认证授权不一致，存在多次登录问题，密码复杂度高，影响使用体验。
观点5：
统一授权管理是个理想状态，一般其实也没有那么严格的授权管理需求，能把授权对应到系统、能及时变更或注销，我觉得已经算很好了。如何用一套授权机制，控制内部用户到底能访问哪些数据和多少数据。做单次访问单次授权用的，其他场景，说实话没必要。可以理解为，将用户到各个应用的入口进行统一认证，从入口到应用内部的细分，由应用侧负责。授权得和应用强耦合，这个梳理不清做了就是深坑。
观点6：
确实，典型的坑点就是数据和功能的访问授权。原本应用可以根据页面设计角色的。你如果统一授权了，不同应用的角色并不一样，用户对象也不一样，你怎么做统一？你是让所有的应用都改成你认定的角色-权限体系么？那在具体应用上权限过大过小，粒度过粗过细你怎么解决呢？按页面授权，按功能授权，按数据授权，单次授权，持久授权，间歇性授权……这些授权一个统一授权平台能支持得了么？所以，真要搞统一授权，除非有类似数据安全这种合规监管刚需压下来，否则很难做得到。很多坑不碰到根本想不到。
观点7：
SSO做认证也只是折中，后面应用最多让你登录做游客，不让你用还是不让你用。对吧。那核心是统一认证。如果做统一授权，还得仔细考虑统一审批。现有的所有审批，都是强流程的，估计很难做到真正的一事一审，真做统一授权了，审批的运营工作量会压垮人的，没有一个team做不过来，而且授权、审批一定不能是安全兜底，否则就是背锅侠。
观点8：
是的，你最多提供基础应用和平台，实际管理一定交出去，或者使用上任何审批不严，授权不当，都怪不到平台提供者和运营者，而是实际操作的人。能做到这点，才不会背锅。大厂估计可能能做到，貌似大厂都有专门的账号安全、授权运营团队。这一点非常关键，统一认证相对好做，统一授权取决于业务复杂度和管理层级。这一方面是为了避免背锅，另一方面也体现了“业务自己管好安全”的治理思路，因为安全团队不可能像业务部门那样熟悉业务、知道应该如何更恰当地授权。所以，这样做，一般而言是恰当的。
本文始发于微信公众号（安在）：诸子云 | 话题：重要岗位离任时，会审计信息安全类的内容吗？统一认证平台，哪家好？
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论