基于过去大部分时候都是直接在云上看安全问题，这次在上云做设计时对安全又有了一些新的感悟，因此记录下来，以供参考。其中不免有些经验和废话不得不说，只是因为遇到了糟糕设计，在解释过程中所体会到的。类似：“为什么正确的设计是正确”的这种废话。
全篇简单的将云上的安全设计分为以下五个部分：
* 网络及访问
* 身份及认证
* 数据及存储
* 应用及发布
* 检测及响应
并会先从上云开始介绍，之后关注到云上方案以及最后进行总结。
有的企业是通过上云实现降本增效，有的是通过下云实现降本增效。一般来说，初创企业比较喜欢完全云化，大企业可能会做私有云。听老板说有某家企业买过AWS的全套私有化方案，实力甚为雄厚。经历过全面上云的目标挑战，也看到过单个AWS账户每月几百万美元的账单，甚至也看到过运维群里有人丢过上千万美元一月的截图。在上云之前，中小企业一般都是具备自己的机房。无论是自建还是托管。不过，我也发现了，即便上云这种大动筋骨的项目也有可能浮于表面。
我不能很好的判断上云的契机。但简单的讲一下观测到的问题。最初的设计往往是符合预期的，但日常的运营之后规则被逐渐打破，以至于一团糟。我在和网络总监沟通时，发现最初设计的网络架构实际是非常标准，符合业界主流设计。以网络视角来看，Border-Leaf架构从边缘到核心。业务视角分为外联区，业务区，开发区，管理区等等。在隔离上也分别使用独立的交换机和防火墙，以及独立的机柜和物理容错等等。我对网络没有他研究的深入，但作为金融行业的设计，这套网络架构已经是标准中的标准。然而在日常的运营之后，无论是流程的疏忽，临时起意的例外以及业务优先的“创新需求”。导致了办公系统在业务区，远程管理部分功能在业务区，开发区自治。除了这种业务逻辑和管理逻辑的混乱，间接也导致了安全Zone的划分混乱，同一个Zone中针对不同的业务又进行的多次的划分。当然出于金融系统的“稳健性”，以及一种又不是不能用.jpg的心态作用下，现状就这样维持下来了。不得不说，在这种情况下推倒上云是急需勇气与魄力的。但最终事情的走向会是什么结果，仍是未知的。而我本身对于系统稳定的理解和传统金融的理解完全不同。我认为系统的稳定不是一成不变，而是能够很好的适应变化，并仍能保持稳定。例如一个证书的更换属于配置管理的同时，在互联网企业以及互联网金融行业就是一次简单的变更。但对于传统金融，则会因为多种莫须有的罪名，让其完成各种验证。美其名曰为了系统的稳定，交易的稳定。我愿称之为《思维固化》。
同样的，对于金融企业的上云而言，技术的挑战往往是其次的。毕竟监管暧昧的沉默，不会主动拒绝，也不会主动点头。业务也不会真正关心IT是否和业务相适应，在又不是不能用的驱动下，政策和对策相互抵消，更不用说用户体验了。尤其在初步梳理现有DC中的安全设计之后，并不能保持乐观的态度。至此，终于理解了CTO所说的：“我们这里不是从0-1的过程，是要先从-1到0的过程”。心中也开始暗想：“莫非上云就是负负得正的过程吗？”
据说在公司曾经辉煌的时候，大把的尝试过各种“先进”的安全产品。各种EDR，NDR都买了安装，但实际情况却是缺乏运营乃至无法有效的使用。老板说预算去年就做好了，供应商说这个产品一定要怎么怎么，才能做的更好。而我更大的感触是：先要选择好的产品，之后再把产品用好。金融企业在安全运营上效仿了客户服务的这种三级结构，从Layer1的处理响应到Layer3的调研分析，但同时又因为传统的外包观念深入人心。十个Layer1的员工9个是外包，甚至10个都是外包。好的层级结构设计在不具备技术能力和平台时，仅靠所谓的运营流程就显得非常机械化。即没有知识的沉淀，还要同时约束供应商以及外包。疲于救火的Layer2以及工单反馈的Layer1，并不能真正的运营什么。我不知道那些大量咨询出身的甲方为什么会倾向这种，亦或是大家都被传统金融的运营框架所束缚了。总之，足够无用，足够糟糕。
面对如此多的无效产品，以及运营的无效。在构建SOC原型的设计中，就需要大量的削减。去掉无用的产品，合并功能重复的产品，例如去除掉一些AV、HIDS产品，合并到EDR；去掉WAF和Anti-DDOS直接合并到CDN产品中；去掉AD ProxyCA去建立Private PKI；去掉Proxy以及VPN，采用SASE进行替代；避免直接使用HSM，KMS直接进行加解密而使用EAAS类服务等。
这里之所以没有提到使用最新的产品，还因为要面临着国产化改造的目标。国产化的改造中需要的产品潜力巨大，但是用户体验糟糕透顶。一成不变的稳定怎么能遥遥领先？
金融企业的另一特色是面向业务的隔离。比如在某项监管政策下的业务A，需要在接入（专线）、网络、存储、服务器、机柜等层面进行单独隔离。这意味着建设成本和运营成本的上升。而在安全方面亦是沿用了这个特恶。从面向互联网的DMZ，到面向第三方的DMZ以及面向机构的DMZ，从面向内部用户的IAM到面向供应商的IAM以及面向测试环境的IAM到面向审计的Splunk、面向SOC的Splunk等。除此之外的不合理还有测试环境暴露到公网，内部域名用于外部服务，提供互联网服务就把节点搬到DMZ等等。这些对隔离的盲目信任导致了运营过程中出现的各种例外，同时思维也逐步固化到边界安全中——使用隔离就足够安全！！使用IP白名单就是安全！！（错误示例）。
在上云的契机下，理想情况是可以将不合理的地方进行优化。从对系统的标准化到统一解决方案。例如之前文章中讲到过很多次对系统的HA，访问，端口，协议，日志监控的标准化，以及整个系统的内外网访问控制，域名解析，DNS服务器等等。只有从系统的标准化到架构的标准化才有可能去实现统一方案。例如合并DMZ构建统一的流量入口，也不要觉得使用HTTP协议的专线接入方案一定比使用HTTPS协议的公网API访问；针对非特殊业务的隔离需求外统一使用网络层面的逻辑隔离，对业务进行网络层面的物理隔离和逻辑隔离都无法阻拦应用层面的攻击。没有必要因为防止应用层面的攻击去物理隔离网络，更多的是需要提高检测能力和响应能力；针对加密即服务的调用，是全部PKCS11的方式和REST API方式并无区别，都需要关注在对密钥索引访问时的认证和权限；针对所有的外部暴露服务，通过Proxy进行暴露，而非直接丢到DMZ。Proxy类的产品类型固定，漏洞更新及时，而暴露在DMZ的各种业务产品则无法有效的收拢攻击面。除此之外还有统一的密钥管理服务，日志收集方案，堡垒机管理方案等等，诸如此类，不胜枚举。
在这个过程中，还涉及到对产品的选型。无论是使用CSP所提供的安全产品还是使用单独部署的安全产品，在方案设计上都需要尽可能满足架构稳定，易于运营的目标。对于同一个解决方案不建议采用不同的产品。这种混合产品组成的“统一方案”是虚假的，应尽可能覆盖产品选型，业务场景，系统架构上三个层面。以密钥管理方案为例，需要一种能在云上和云下提供加解密服务的EAAS产品，并且能够保持根密钥的安全。虽然支持多样性是一件好事，但是实际运营的过程没有人愿意维护一套阿里云的KMS，DC维护一套Cyberark，应用在K8S选型里用了Hashicorp Vault。更好的做法是通过一套产品在不同区域的部署对不同的服务端点统一提供服务。类似的，服务器的CLI登录也不需要用阿里云的运维安全中心提供服务器登录功能，DC内并存着齐治堡垒机和Cyberark。还有一些业务上对SAAS产品的采购选型，也应该尽量满足多云以及混合云模式下的运营场景。
我在这篇章里介绍遇到的种种问题，并不是为了抱怨怎么样一个现状。而是希望通过发现问题解决问题的思路去改善体验。我一向不认为承认失败是可耻，然而理想总和现实差距甚远。无论是业务优先还是安全是企业全体的责任，这些理念大概率只留于了表面的宣传与认同，实际的改善需要参与者的信任与真诚（或许某一天会认清现实，改成需要利益驱动）。
对于上云和云上的解决方案，没有什么是绝对的。如果每一个参与的架构师都抱着绝对A，绝对B的思路，那做出来的云上设计一定是草台中的草台。设计需要平衡，架构即是决策。不怕草包，只怕不听劝的草包。
* 没有哪朵云是最好的（AWS和Azure的国际版做的都很不错，但是政策要求下的版本————世纪互联和光环新网运营的云不会是最先选择的。）
* 没有哪个方案是必须的（LB放在WAF前或后亦或是使用具备抗D和WAF特性的CDN都是可以接受的，VPN还是SASE也都可以使用）
* 没有什么是绝对安全的（一边是加上白名单和拉上专线，一边是纵深防御，两类极端也都不能保证做到绝对安全）
我把开篇所说的五个部分制作成了脑图，并在后续以一个假想的上云场景来设计云上的安全：
把办公系统从DC业务区迁移出来；
把业务系统进行内外隔离；
将部分生产环境迁移上云；
网络和身份是访问数据及应用的基础，这里将其主要分为了两部分，一部分是访问时的网络（途径）和身份，一部分是平台里的应用和数据。
针对基础设施的设计，首先要从基础的隔离原则进行考虑，逻辑层面需要关注域名，证书，端点，解析等方面，从物理隔离层面还需要考虑交换机，路由器，机柜服务器等。
对于从隔离出发作出的设计之后，需要从安全Zone的角度罗列Zone的列表以及可实施的安全控制列表。例如：抗D，WAF，FW，流量分析等等。同时对于云上多租户模式，凡是生产账号下创建的VPC都可以被视为HRZ区域。如果是只有一个云账户，则需要按照业务的划分将对应的VPC按照安全Zone进行mapping，同时针对Zone间部署安全控制。例如通过云上防火墙作用于VPC，实现VPC间的访问控制，通过安全组作用于弹性网卡，实现实例层面的访问控制等等。当然还需要设置默认的Zone间访问规则，包含协议，端口等。以此实现默认的Zone间安全等级。允许低等级区域的数据向高等级区域流动，但不允许两个同等级的安全区域默认流动。例如Region A和Region B之间的HRZ区域默认可以互相访问。数据的同步应该通过DB层面进行。
这里只是简单的罗列了几个Zone（你需要按照自己的实际需要设计zone，并去实现对应的隔离）。之后开始考虑从控制平面到数据平面的访问：以SASE为代表的产品可以通过在本地部署Agent分离终端对互联网页面的访问流量，并在远程办公区实现对云Console以及其他已购SAAS产品的访问分离。
尤其是针对业务的后台管理系统，应当尽量的避免从办公区域直接访问，至少也应该通过类似Cyberark或AVD类产品进行管理。如果有资源的话应该去设计零信任架构，通过策略引擎和访问引擎完全屏蔽用户对后端实际服务的感知。除了用户对服务访问时的零信任，还有应用与应用之间的零信任，对于微服务最常见的模式就是基于K8S+Istio的形式，通过proxy和证书完成服务间的权限控制。
至此这里提到的都是网络与云相关的安全设计，针对主机，应用等等个人感受实际与传统DC并无大的差别。甚至网络，只是产品的选型以及设计理念带来的变化。
前面讲的这些所谓设计，实际落地后统统都离不开运营。甚至都不到落地的阶段就出现了比较悖论的事情。因为设计决定了运营的方式，但实际情况却是运营的能力影响着设计。例如没有DevOps怎么去谈DevSecOps的设计，没有标准化的系统何谈数据化运营？林林总总，暂不叙述了，写累了。这篇博客都快用了两个月时间，但就是收不下尾（要吐了），所以先不扩展了。
当然也开始体验到四方轮子在大草原上狂奔的感觉。例如世纪互联运营的M365不支持SSO，只能通过OAuth的Client ID/Secret ID进行配置，但配置后的应用程序又只能跳转到.com的Global站进行认证。简直是牛头不对马嘴。这种运营现象就是因为在架构设计之初没能完全识别到运营中的风险。
这里以阿里云为例，简单搭建了以DCDN（实际因为未备案被封掉了）到GTM，之后指向两个region的四个可用区SLB进行流量调度，并对SLB均开启了WAF3.0功能，其中SLB作为ACK的ingress，对外路由服务。左侧的虚线框均是需要对外暴露的，通过GTM区分业务流量，SLB对外暴露服务，API Gateway区分应用流量，除此之外均无直接对外暴露的。同时针对POC阶段限制仅允许办公网段访问ECS类终端等。这个POC只能说是中规中矩，但实际部署过程中却遇到了不少问题。
在云上使用云厂商的安全产品固然方便，但其运营成本依旧非常高。而且不能够直接仅仅通过测试安全产品来验证最终效果，应当部署最小原型后的基础设施并部署业务进行测试。此处以阿里云为例，简单列举一下在安全产品使用过程中的用户体验。云安全中心美其名曰“中心”，实际上给租户的感觉是收费巨兽，倘若能够通过收费巨兽实现对云安全产品的统一管理倒也罢了。实际上DNS安全在云解析产品，TLS安全策略配置在SLB产品，同时如果需要各个安全产品吐到同一个SLS中，则需要提前规划好每一个logstore。除此之外，日志功能的开启对于大部分云产品几乎都是需要手动单独打开的。应用安全的同事也反馈了一些问题，这尚且是领先的云厂商-_-#。另外在沟通过程中，没有一次是看到阿里员工及时响应，更没有一次能准时参加线上会议。对此著名的麦克阿瑟上将表示：“在阿里云安全面前，我就是个新兵蛋子。”
在架构之美这本书里，有的前辈认为架构只是过程而非目的，有的认为架构即是平衡。对于传统安全架构设计而言，理念开始从边界到纵深防御，从隔离到零信任过渡。云在提供里弹性伸缩之后，安全架构的设计需要更多考虑云本身的特性完成安全控制的替代或统一。这里没有绝对，只有适合与否。而从-1到0的过程中，组织和支付网络的所带来的阻力远大于技术问题。
如果你遇到了张口闭口Totally Wrong的同事，请尽量远离。例如你提问两种方案的优劣,会得到：“你见哪家公司用过”的反问；如果你去解释了关于安全的实现，就会得到：“你说的都是概念，我讲的才是原理”这种结果。甚至有时会出现你不要问我，你回答我的问题。没有边界感，没有专业的安全知识但还要表现的比安全专家更加专业。
读书，学习，实践，总结。但是仍然讨厌傻逼。远离傻逼，远离不幸。
