这篇博客最开始计划标题为《你需要一个安全架构师吗？》一会儿又想改成《安全架构设计中平衡的艺术》，最后又想叫《安全架构师的吐槽大会》，中间又改成了《团队的鸡肋——安全架构师》
安全架构师的工作是干吗？
首先，问自己一个问题，安全架构师的工作内容只是做架构设计吗？从工程的纬度来看，要求一个安全架构师上能够要写Policy（资深点的可能还需要制定Strategy），分析需求，确定Scope，拆解Gap，制定解决方案等；中能够做实施，选型POC，部署运维，上架交付；下能够做运营，告警分析，流程编写（SOP），知识培训，应急响应，事件复盘等；这意味着一个架构师能够随时的快速补位到任意一个角色。从团队和项目纬度来看，一个合格的架构师应该能够快速的Lead一个项目从开始到结束，能够完成跨团队的沟通，站在方案视角下协调各方的利益，使Stakeholder能够接受方案并能够推进方案的顺利进行。还要能够跟进方案。从治理的纬度来看，应该能够理解监管合规的条文约束对应在技术上的语言转换，换句话说要知道的是合谁的规矩？受谁的监管？代价多大，又能够干些什么，尺度在哪里，灰度在哪里？怎么样转换官话要求到企业内，怎么把框架/模型、新技术跟现有技术栈结合，怎么从流程策略补全？是否需要引入新的产品，能不能实现一个Quick Win等等。
当然这都是理想情况，实际情况，架构师只是极小的一部分。在其中某个领域担任相应的角色。甚至可能做着一些完全不搭边的事情。
安全架构师需要专业吗？
我的回答是，Yes！不仅需要在技术上专业，还应该在职场上。不论是你在项目中承担POC的角色，还是换了个名字叫Business Partner。都务必应该扮演好这个Role所需要做的事情。我不是一个绝对的流程主义者，但我一定坚持那些必须的节点。当很多时候大家都在说技术不是问题，只怕是已经遇到了很多的技术问题。但相信有很多人更加聪明，因为公司又不是我的，我又何必认真？大不了离开之后，管我屁事？无意讨论好坏，立场不同，结论自然不同。回答是否需要架构师专业的话题上，我先列几个问题以供思考：
- 如何从业务需求思考和评估未来的架构设计需求？
- 如何避免降本增效还是降本增笑？平替的过程中，哪些可以用开源的，还是都可以用开源的？
- 我在做纵深防御还是重复防御？ //掩耳盗铃竟是我自己
- 技术设计的平衡边界在哪里？
- 制定的目标和指标具备可落地性吗？如何衡量？
当然技术的专业性之外，职场中团队的管理也非常重要，如果管理不能行之有效，那所有的技术方案和所谓合作都是白搭。换一百个名词也没有用，从POC到BP（Business Partner）只是换汤不换药罢了。有时候一个正常的方案正在顺利推进（可能是我自以为是的错觉），遇到一些奇怪的同事之后，事情就变得复杂了。急转直下，成为一坨DB。
我同时也整理了一些案例，可以用来看技术纬度是否需要专业(当你见识了所有混乱的组合，也许才能体会我对专业的认可）：
- 金融企业总是因各种原因会拒绝数据上云，因此产生了一些所谓的“存算分离”的模式？那么这个边界在哪里？一眼看起来是用在哪里解密作为了一种边界？那继续来看，怎么判断这种边界？以及是否可以通过内存转储来判断内存是否安全？是否要求Vendor在云环境下除了客户数据在IDC之外，还需要提供关于密钥安全的一些说明？那是不是又可以引入TPM了,以及是使用二级密钥三级密钥结构？与此是不是需要密钥分量? 密钥的分发和校验要不要引入keyblock,填充模式的要求呢？ gcm. cbc.业务不支持的情况下呢？
- 金融企业还会尽可能避免PII信息出现在不该出现的地方？比如说日志中，那么解决方案是从通过公共SDK库升级实现Log的统一脱敏？还是统一处理所有吐日志的中间件，把所有消息队列经过规则引擎过滤一遍？还是检查所有的代码，正则一下打包发个新版本？
- 厂商最近都喜欢做ALLINONE,你做我也做，那么问题来了,卖点看着不错，但我该怎么用？类似XDR可以推基线，UEM呢？这里出现了一个问题，功能重叠部分，怎么设置只在一处开关，整体怎么设计？你Proxy要流量解密，我DLP要解密流量，他SASE也要解密流量？不好意思的是，有时候你又用了M365系列做生态（先抛却国内国外版本差异的巨坑）, 产品如何集成三方的产品？某个地方你支持Conditional Access想弹二步验证，那我entra呢？这个产品要黑名单，那个也要，一堆产品一起怎么运行起来？
- 上云和SAAS也是一个选型的趋势，如果我的Vendor都只提供Saas产品，我除了通过合同约束，采购准入，三方认证之外，又能提供哪些控制措施？
在这些场景里，不仅是通过技术对问题的识别和提出解决方案，也很考验自己是否能够具备心力维持是否退一步。相信大家心中，一定会闪过一句：“又不是不能用！” ， 但千万不要还没有踏出第一步，就已经放弃了。有时候你知道不是自己能够决定的，但也不应该在一开始就缴械。
我讨厌不够专业，因此也时常怀疑自己。如果是环境问题，不要内耗，问题不在你。在你现在所在的位置上，尽责尽职就够了。有时候我听到一些车轱辘话也觉得想笑。例如:功能肯定可以实现,但是可能会影响性能。但是要知道，这些是不能认真的，如果你真的认真去问什么时候能实现，大概相比原版本增加多少性能损耗？这时候你就是杠精，不识趣的杠精！和你的语气，态度没有关系，和你的出发点也没有关系。
你的团队需要一个安全架构师吗？
这个角色似乎能帮你变得更好，但却没办法阻止变得更差。
这个问题其实我无法回答，需要老板们才能回答。很小的企业里可能不存在安全架构师，也不会单独去招安全架构师。一个安全工程师就可以充当安全运营，安全运维。在这个过程中也不要想有什么完善的制度/策略。能简单的建立起SOP已经是难如登天了，与此同时，公司能存活下去也就不错了。也别想什么预算，除了不得不买的东西基本都是开源产品。文档的沉淀也是看命。对于ToB类的企业，除了出于售卖目的请三方拿些等保的证书，基本上应该是什么也没有了。这种情况随着团队的规模增长到3-5人，意味着企业已经从开始关注安全到开始付出，但实际也不会有什么能改变现状的能力，只不过几个人之间互相交叉的看着运维运营的产品，看看攻击处理处理告警，买到的也只是管理者的部分内心安慰。等到了5-10人，似乎开始关注到了合规的部分，这时候会为等保，ISO27001投入精力，设置专职岗位。然而专业的合规项目背后，往往不需要专门的合规团队。一个专业的项目经理就能实现，收集到对应的资料即可。当然，任何专业的人都是很难找到的。一个专业的具有安全项目经验背景的项目经理也是大海捞针。使用开源的产品尚且要求你自己有运营部署的能力，进行自研虽然不见得比商业采购更加节省成本，但却能够更满足企业内部的定制需求。那纯粹的供应商外包管理，又能做的了什么？外企里很多都是一个中介配个供应商服务结束。我以前以为工程师要熟练的掌握对应的产品，结果在一家Director比工程师还要多的公司里见到了Proxy模式如何运转的，有时候觉得找几个链家的员工不也能干的下去。起码链家员工还能对自己的Scope有一个明确的认知，知道什么是边界感。当然，当团队中存在这种“人物”， 实际不再需要安全架构师，因为谁来了也救不了。
那么问题来了，当你觉得运营水平低下？当你觉得产品没有效果？投入很多钱买了一堆废品？是当你觉得招了不少人却发现工单压的喘不过气？还是当你以为买了先进的产品却告警应急频频？也许给了1kw的预算说多不多，说少不少，但为什么安全水位还在持续在下降？从预算节省，运营增效，架构远景的方向是会需要一个安全架构师吗？我的内心是认为极度需要一个具备Leadership的专业架构师来进行大刀阔斧的改变。但我不是老板，所以我无法回答这个问题。
回头看看，安全架构师工作存在很强的壁垒么？似乎也没有，喂给AI充分的场景之后，似乎没有什么不能解决的。尤其是在没有人追求质量的时候，为什么不用AI的呢？ 而且人类的幻想似乎也不比AI轻多少，例如对厂商的偏见，对未知的恐惧，等等。有时候，我觉得自己其实不用存在目前的团队里，因为这对降本增效没有任何帮助。Less Operation， More Efficient？这动了太大一块蛋糕。Defense In Depth？什么我的DID只是重复没有深度！Zero Trust？怎么可能，我都快要用三套MFA了，谁会信任我。
我没事的时候就刷LinkedIn，去看人家的Principal Security Architect和CISO的成长路线。我以为我在窗口看世界，却忘了萤火之光无法长久。曾几何时，普通的技术实践也成了井底的天空，既然没见过，那又怎么可能是真的？我身边的每个人看起来都很聪明，履历也很光鲜。只有我不那么聪明。
既食之无味，弃之……则不可惜。