🥷
🥷
文章目录
  1. 前言
  2. 工作内容
  3. 问题思考
  4. 总结

安全架构之困

2022.09.17 放之 安全架构师

前言

中秋的时候，难得的同朋友们聚了聚。从拍日落到露营烧烤，从把酒言欢到困得迷迷糊糊。一年未见，却又没什么变化。只叹时间不等人，短短两天转瞬过去了，还有许多话未说便各自告别。只愿日后多得空相聚。
之前的博文大都是介绍一些技术经验和方案，很少去讨论其中的落地困难。但有类似经验的工程师依旧一眼能发现其中的问题。正是秋高气爽，借着这个周末。我将平时记下来的问题点简单整理一下，记录于此。

工作内容

先看下安全架构师主要有哪些工作要做，主要分为三大块，分别是

  • Risk Identification(Asset, IT, Infra, Cloud, Application, Data, Business, Legal, Compliance etc.)
  • Security Design(Strategy, Policy, Arhcitecture, Process, Workflow, etc.)
  • Security Consulting(Requirements review, Architecture review, Other)

其他还有Security Governance, 团队内的部门间的协作，Risk和Effort的平衡以及Project Management, Cost Management, Risk Management等. 在大的公司里，可能每个方向都有一个团队，每个人负责更细的一部分。在小的公司里，如果安全架构师能只负责这些就已经万幸了。可能还会做Security Product的Design，甚至Deployment等。

既然已经绍了工作内容，下面看一些问题思考。不过在此之前请思考一下，如何使用一个模型能够将这些设计输出出去？ 如果你是安全架构组的Leader会往什么方向走？

问题思考

  1. 如何确保内外部的有效协作？

    首先需要划分边界（职责范围），其次建立流程（协作机制与过程追踪），最后有效的沟通。但注意边界往往不是绝对的！另外在划分边界的时候可以按照安全领域进行（安全技术-Infra/App/Data），但落地的时候应该以组织架构为参考维度（例如网络与云安全组，安全平台组，应用安全组，安全运营组等）； 假设安全架构组按照上述工作内容进行输出，承接内部的安全建设方案，约束/帮助其余小组规范的提供各种能力；对外提供策略流程约束，将业务部门纳入到流程中来。例如应用要走SDLC，数据要走数据治理的流程等。那么对内来说，如果各组有能力自己设计相应的方案，安全架构最好不要全盘干涉，能从Review的角度给出建议即可。如果不能，再结合各组的能力去交付方案。而对外来说，如果业务方不接受你的合作/方案，那要么提供新的措施，要么走特殊流程，或者需要对方自己去承担风险。但无论是特殊流程还是承担风险都必须有一定的时限，同时提高一定的门槛。例如特批流程需要到VP，风险不得持续超过3个月。

  1. 如何有效沟通？

    不要成为对方的绊脚石；不要趾高气昂；不要默认对方能够理解；不要理所当然；不要锋芒毕露；不要敏感；尊重对方的原则； 最重要的是不要遇到SB。任何事情都要解释清楚，确认对方是否理解，理解的是否一致。当然即便如此，会上的结论，会后对方很可能依旧在邮件里给你一个他自己的理解。遇到对方不在同一条线上的沟通，自己千万不要着急，不要生气。

  2. 如何衡量成果？

    对于Security Consulting，是较为容易出指标的，这一点类似安全运营，处理一定的数量，以及质量评估等。对于Security Design以及Risk Identification来说，更多的是从项目维度追踪，对于旧的项目改造还可以提供出前后的对比。但对于一些新项目而言就缺乏一定的指标，当然也可以考虑到成本的优化，自动化的程度等。另外后续也可以通过安全运营的一些质量指标作为架构设计的一部分。在这一点上其实和老板讨论过几次，但都没有一个很好的结论。如果您有一些建议，欢迎随时沟通。无论是从解决的风险点出发，还是从输出的能力出发都不能很好的起到衡量作用，这一点是做架构设计和运营上的显著区别。

  3. 如何选择合适的技术方案？

    没有最好的方案一说，要做企业内最适合的方案。很多时候一些服务或产品都提供了Best Practice，例如AWS的Security Best Practice等。一方面是技术的沉淀，一方面是经验的产物。这些东西毫无疑问是有价值的，但不能说因为对方提供了最佳实践，我们就应该按照这个来。对此我更喜欢看到的是Reference Architecture。 具体来说，就是这个方案的设计之初应该考虑是否符合业务需求以及业务的使用成本，例如是否需要改造，是否需要大量精力运营等等，同时还需要考虑是否贴合当前的基础设施以及满足一定系统架构的约束，例如是否服务交互的方式（微服务中是Broker/服务注册发现/Sidercar，是ApiGateway/BFF等），部署环境（IDC，私有云/公有云，多云，混合云），是否符合一些架构标准（例如系统架构支持HA,TLS,Audit,Monitoring,Backup/Recovery etc，应用架构符合现有的模式-微服务/传统，支持熔断，服务发现，配置管理 etc，数据层面上，网络层面上等等)等。 在工作中经常能听到说“这个方案xx（竟对/头部）都在用”，“这个方案我上家公司就在用”，“这个方案根据我之前的经验就应该怎么怎么”，不胜枚举。除此之外还有一点就是甲方需求与乙方产品的差异，乙方的产品在攻击防御的各个领域往往提出了各种新的玩法（例如Aqua对Container和Infra层面的扫描，以及其他各家的SASE，SOAR，ASM和CSPM产品），但是在运营，SDLC之类的平台产品往往各有各的想法，一个看似功能全面，流程全面的产品，可能直接增加用户（甲方的架构师和甲方产研侧）的沟通成本和流程复杂度。这可能也是甲乙方间的Gap吧。同样的，绝不要妄图用一个方案解决所有的问题，但也绝不要一个方案仅解决一个问题点，要尽量将同类风险/需求一并收拢。例如做Secret Management，可以将Key Management以及Encryption As A Service 整合到一起，做Data Tokenization可以将Data Classification，Scanning,Tagging整合到一起，通过一个解决方案完成。

  4. 如何衡量成本？

    成本永远是一个不可逃避的话题，无论是人力也好，服务也好等等。当然云时代很多基础的问题已经得到了解决。可以在控制台上创建个RDS实例，即开即用而不需要一个DBA团队维护，不过另一方面需要研发拥有更多的Devops经验。虽然云可以很好的缩减创业公司的成本，但是随着业务的体量增加，场景的复杂度越来越高，云本身的提供的SAAS服务也越来越难以满足需求。此外多云环境下更为复杂，把业务放到不同的云上，采用不同的CDN等等。同样的，随之而来的各种安全问题，云资源的，Policy的，服务本身的等等。例如服务遭到攻击导致资源滥用可能会导致云厂商关停你的服务。那对业务的影响显然是很严重的。所以这并不是简单的招聘个AWS专家就能解决的问题，我们也不应该把所有的保障押注到一个厂商。而我想表达的就是，资源很难均摊到每一块上，我们也不应该简单的依赖厂商。在资源有限的情况下应该首先确保核心业务和核心链路的稳定性和安全性。还有一点时间既是成本，成本也是随着时间发生变化的。

总结

想要又快又好，往往一定程度上意味着成本的增加，无论是人力还是产品上，快大多意味着未得到充分验证，那“好”也大概只能是一厢情愿了。想要节能增效，往往意味着开支的节省，好听点叫把钱花到刀刃上，不好听的话叫“xxxx”。那既要节能增效又要又快又好显然是存在很大风险的，或者说不现实的，是一种赌博。 赌压对了宝，压到了好的没被节能掉，压到了增对了，压到了快也没出事。这看起来多少有点荒诞，但却往往并不仅是管理层的一种心甘情愿，而是一群人的心甘情愿。管理层傻吗？不傻，但是人人都可能为眼前的树叶遮蔽了双眼。还有一些人只窥得了“结果导向”几个字,又不愿意面对过程。或者说过程都没有，哪里来的结果呢？高喊口号，去自我欺骗。或者内心也抱着一股希冀——赌赢了。但事实往往会告诉你并不是那0.001%的幸运儿。

回到安全再聊两句，记得有次和人聊天说：“安全的本质是对抗”，当时因为没什么时间，也没有多讨论。安全的本质是对抗这句话，更具体的应该说是安全攻防的本质是对抗。对于安全治理来说，则是一种平衡。平衡风险和成本，确保业务成长过程中和IT相适应，风险在一定的范围内。当然各有理解，未必绝对。

再聊两句原则。虽然万事无绝对，但一个人如果没有自己的原则，是不可以做朋友的。当然小事插科打诨，无所谓，毕竟没什么事是绝对的。但一定是要有做人的原则，至于怎么判断，也不好说，可能交给时间检验了。随着年纪增长，愈发觉得赤子之心，尤为可贵。至于工作，仅仅只是工作罢了，知道什么事情一定不许做，其他的就没什么绝对了。所以大可不必大动肝火，上纲上线。奔着实心用事，解决问题去就行了，各人的立场不同罢了。但一定要注意工作和生活的界限，要出淤泥而不染。