慎独
慎独
文章目录
  1. 0x01 前言
  2. 0x02 正文
  3. 0x03 总结

安全架构师的运营一二事

0x01 前言

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

0x02 正文

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

  • 我们在内网,不需要密码,不需要tls,key就存数据库就行;
  • 别人怎么怎么用的,别的公司都是这么用的;
  • 这个github上的star分数很高;
  • 这个业务很急,优先级很高;

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

  • 一个文档十句话,架构图一个没有,上下文也不记录;
  • 丢个第三方软件的链接当作答案,让你自己去看;
  • 加密哈希编码傻傻分不清楚;
  • 几个会开下来,该改的地方一个没改;

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

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

0x03 总结

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

// 微软的技术支持是真的菜,即便开了A Case(据说A Case的技术支持基本上干了8年以上,不能理解),很多bug都不能得到及时解决。另一方面也说明了安全类产品并不成熟,回头另记录一篇吧。

支持一下
三思而后行