填坑一:乙方(IT 软件供应商)信息安全未来发展的思考

周一,全天A项目等保测评会议, 对云上项目PaaS 的系统有了一个比较具体的认识, PaaS 层面灵活性还是相当大的, 对于基础设施不是很care, 但是可以集成各种服务, 通过订阅服务来进行环境的部署。数据库是一个服务, Auditlog 是一个服务, 等等,公司或者部门,可以在global account 下面申请额度, 然后subaccount 可以进行订阅。。 与SaaS 不同, service 在部署层面进行购买,直接通过虚拟机部署到系统中。 不过这个也显然对IAM 的管理提出了更高的要求。 明显在原来的类似于console 的 管理层面就多了3层:一层供应商管理,一层用户管理, 一层最终用户。 再考虑不同的服务可能来自于不同的供应商,供应商的那边的IAM的角色,就会更加复杂了。 

今天准备为乙方的信息安全开个头, 因为自己也算是身在其中的,素材丰富, 而且自己日常的思考也挺多, 相对成体系。 前面也思考过的CISO 的score card应该算是乙方的一个总结, 但是经过和甲方的交流发现对甲方的理解还是有点狭隘了。 对于乙方的定义, 不是像四大, 律所的那样的乙方, 主要是讨论云服务供应商这样的IT 设备和服务供应商的乙方。 

内容两个方面, 一方面是关于乙方信息安全工作的梳理,另外一个方面是关于未来的思考 。 

先写第一点。

一:乙方信息安全的工作。 

乙方,在这里作为系统和云计算服务的供应商, 提供的是 系统和服务,乙方的特性大约有这么一些。

1. 有大量的开发与维护工作,但是使用的很少。

2. 技术的主要集成者,对信息领域的新技术更敏感。

3. 承担主要的信息安全责任, 合规责任。  

4. 信息安全的投入数倍于甲方。 

乙方的信息安全的工作还是要提一下 六字诀:

上下前后左右。 

前向: 外部信息安全合规

后方:内部安全标准验证与审计。 跨部门资源的整合, 

左侧:供应商/供应链的信息安全管理, 

右侧:客户互动/客户信息

上:风险喜好对齐。 

下:团队管理与培训。 

19日 未完待续。

20日继续:

今晚应该来写k8s的安全梳理的,因为今天公司请了一位号称是业界的大咖来公司讲k8s, 但是他的课程是从 云计算安全开始讲起, 实话实说, 讲得并不好, 办公环境和生产环境的隔离都没有讲好, 一个jumpserver 解决所有。 k8s 的知识讲得也是稀碎,连k8s的基本理念都没介绍好, 毫不客气地说,我司当时给我们内部做k8s培训地讲师,随便一个拉出来都能比他讲得好100多倍, 但是他的title 竟然是k8s 布道者。不过这一次我很好地控制了我的情绪, 问了他k8s 安全性的问题, 他的回答涵盖了SDLC,镜像, pod,然后到 应用安全,访问控制,主机安全,这个也是一个非常好的回答问题的思路, 完全没有纠结于我的ingress engress 的细节, 我可能是曾经在这个问题上被卡过,所以一直过不了这个心结。(每日的这种吐槽到底该怎么归属,确实是个很难的话题 )

回到前面的问题,  今天时间有限, 只写一个上, 所谓上就是和上面的战略对齐, 风险偏好的对齐, 公司当然希望是一切都好,业务好,无风险,没有安全隐患, 业务上的又快又稳,但是事实上很难, 业务系统的  效率,安全,低成本,三者之间好像是一个不可能的三角。 又安全合规,又很高效的系统,肯定很贵,耗资巨大。 不想花钱, 还想要安全,那啥也别做了,或者极端方法,招个安全人员,专门背锅用的。 但是,大都数情况下,安全是最先被舍弃的, 裸奔,怎么方便怎么来, 快速开发一个系统。  为了避免安全处于背锅的境地, 要和领导进行战略对齐, 把业务的重要程度排成序。 然后,信息安全要求按照导致的风险排好序,workaroud(变通方案),DDL 都弄弄好, 然后让领导来决策, 这样,背锅的人就不是安全人员了。切记,没有了业务,安全就没有存在的必要了。 安全服务于业务而不是卡业务, 要时刻参与业务系统的决策, 从系统的设计阶段就要高调参与。

这是上的方面。 对上的管理,战略对齐,风险偏好对齐。 

20号就写道这里, 明天写下的部分, 团队建设和培训 。    

2023.06. 28 继续更新

这几天去过了端午节,参与了一次甲方和一次乙方的面试,当然这两次两次都并没有希望,但是从面试的过程中也能感觉到甲方和乙方对安全的截然不同的要求,对于我自己来说,我还是觉得甲方才是安全的归宿。  后面又去了亚马逊云的2023中国峰会,看着亚马逊在中国做了那么多的成就,在各个方面的能力不断地集中,尤其是在生成式AI 上的快速的反应还是出乎了我的意料。我越发觉得云计算才是所有计算场景的终极模式, 未来的计算能力应该就像现在的电和水一样,即连即用,而不用自己去维护,在云上的各种能力也会以服务的形式提供。 每个人也将拥有自己的计算助手, 随时随地获得计算能力。 而这种时候,云计算的安全应该就是一个非常重要的事情了。 

继续回到上面的话题,说到信息安全的培训,其实是比较难做的, 主要是因为公司里的各个岗位对于信息安全的要求差别非常的大,

1) 有些岗位距离公司的系统很远, 只是一些日常的考勤,报销什么的才会接触公司的办公系统, 而且完全不接触生产系统。 对于他们的信息安全意识的要求完全可以通过技术手段来降到最低,可能他们连自己的密码都不需要。 要教育他们注意个人信息, 注意防止钓鱼等等。

2) 而有些技术类的岗位,他们的接触系统的机会很多,权限还很大, 那么对于他们的信息安全的意识, 可不只是教育那么简单, 要有系统的培训,要有定期的考察,还要有日常audit,才能覆盖。

3) 这些岗位中, 比较难搞的是公司的管理层, 权限不好控制,还没有时间参加培训, 对于他们这样的岗位,要做好权限的管理,资源的隔离,防止误操作。 

在这样的情况下, 对于不同的岗位的培训就提出了不同的要求, 岗位1),要进行经常性的轻量级的培训,反钓鱼培训, 个人信息保护培训, 桌面信息保护。 

岗位2) 按照信息安全专家的要求, 运维岗或者开发岗,制定日常操作规范,进行专门的培训和考核。 并对他们的操作进行review 和 audit。

岗位3) 比较特殊, 需要有一系列轻量级的培训,提醒他们的权限,安全对业务的影响,BCP, compliance 这些的要求。 从他们的业务处打动他们。 

以上是乙方的培训的考虑。 对于安全团队来说, 除了全员的强制性信息安全意识培训,建议时不时的弄一些信息安全周,信息安全新闻交流这样的常规的,大家都能参与的活动, 提升整体信息安全的意识。 钓鱼邮件要无规律的,时时的发,内容要新颖, 让人一看就想点, 一点就点名批评。 让大家行程下意识的恐惧。

至于安全团队的配置,对比来看,在乙方安全团队是富裕的,奢侈的,是很幸福的,在乙方做安全的人可多了,按照经验来看,大约能有个5%左右的配置。而且可以覆盖从信息安全,到研发,到架构,到运维,到合规等多个岗位。毕竟安全对乙方公司的系统的最终价值是有不错的加成的。 不过在乙方做安全虽然幸福,但是安全总归还是开发下面的一个小的模块,话语权相对来说比较有限。 而在甲方做安全就完全不一样,很多的时候安全是IT 的附庸部门,在甲方经常看到3个人负责公司所有安全事情的情形。那比乙方就惨了不是一点半点,不过因为人少,安全部门的重要性就更凸显,可以参与到公司的IT方面的很多的决策。所以各有各的好处和缺点。   


本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场,不承担相关法律责任。如若转载,请注明出处。 如若内容造成侵权/违法违规/事实不符,请点击【内容举报】进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部