安全架构师的运营一二事
2022-10-27 19:6:32 Author: mp.weixin.qq.com(查看原文) 阅读量:0 收藏

做工程师的以为做了专家就不搞运营了,做安全运营的以为做了架构不需要关注运营了。实际上运营又是始终逃不掉的一个话题,不过今年好在不像前两年吹的那么厉害了。简单总结下架构中的运营工作。

先讲讲常规的运营工作有哪些,需求收集(安全团队内外的奇奇怪怪需求)和风险跟踪这两块是日常工作中最常见的,主要体现在架构评审和安全咨询两部分。拿架构评审举例,经常需要沟通去说服业务方接受一定的baseline。但业务方往往会有以下的理由:

  • 我们在内网,不需要密码,不需要tls,key就存数据库就行;

  • 别人怎么怎么用的,别的公司都是这么用的;

  • 这个github上的star分数很高;

  • 这个业务很急,优先级很高

在这种背景知识不对等的情况下,一方面由策略/规范去强制要求业务方遵守规则,另一方面需要一遍遍的耐心沟通,补齐背景知识。而往往结果又会变成:

  • 一个文档十句话,架构图一个没有,上下文也不记录;

  • 丢个第三方软件的链接当作答案,让你自己去看;

  • 加密哈希编码傻傻分不清楚;

  • 几个会开下来,该改的地方一个没改;

架构评审做的越多越让人感觉无奈。针对事后的风险管理,即便通过流程进行跟踪,但很大程度上会出现牛头不对马嘴的解决方案,会上说的是一套,实际做的又一套,甚至可能没往某方面设计就close掉风险点了。

除此之外还有规范建设,内部(或者和其他部门一起)写策略,写基线,写管理办法,写流程等等。一般格式会分为:目的,范围,内容,附录几块。初版之后要review/cross-review规范,release规范,update规范。这些规范应该具备统一的格式,编号,水印,固定的更新周期。同时由于有的是写给员工的,有的是写给IT的,还有的是写给运维的。还会涉及到能力推广,这又包括培训,宣讲,分享几种不同的情况,当然可能还需要建设一个团队对外的Portal,供企业内其他部门的员工查看。一般会包含以下几个板块,org&leadership,mission,capability,event,policy&sop,所有在portal上的都将被认为是released版本。草稿版本放在wiki上编辑。

以前是在“砖家岗”做架构,现在是架构岗上做“砖家”。从9月来是平均每周20h的会议,10月的几周更是爆炸,感觉最近至少要平均到30h了,有时候真的不知道是未来先来还是稻草先来。人特别累的时候脑子里就会疯狂嗡嗡嗡,思绪飘飞,有时候会把想到的写下来,可能会缓解一点,但有时候又没什么作用。想想很久没跑步了,今天去跑了一次,才2km就已经大汗淋漓,想来想去,还是休一天假,放过自己。毕竟狗命要紧。


文章来源: https://mp.weixin.qq.com/s?__biz=Mzg3ODAzNjg5OA==&mid=2247485068&idx=1&sn=d7452b1153454ed2ab0d77630d1075aa&chksm=cf189441f86f1d578a2477b4d60582d7f29241dd4a4bd76a6a16fad89e5e00b32eef14d433cf&scene=58&subscene=0#rd
如有侵权请联系:admin#unsafe.sh