网络安全架构

### 零信任架构

BeyondCorp 的思路方向是正确的，但执行时过于强调去 vpn、去防火墙化，google 自己有着庞大的高素质的内网安全团队，这么做还行。其他大部分公司按这个照本宣科基本就是往坑里跳了，正确的做法不是去掉边界防护，而是给边界防护减负

主要是把人访问服务的场景，通过受控设备+证书+SSO+安全基线+权限管理+全局风控 的思路，可以减少特权内网的负担，这个模式本身成本并不是太大。

核心还是风险认知模型，谷歌认为自己面临的风险级别很高，传统的边界安全防护思路根本无法依靠，这才提出的零信任安全模型，把安全防护级别原子化，更安全势必成本也更高，这么做的除了少数政府部门也就屈指可数的巨型互联网公司了吧

https://mp.weixin.qq.com/s/DKTODvkmZqTVi1lfqtHdDw

BeyondCorp的思路方向是正确的，但执行时过于强调去vpn、去防火墙化，google自己有着庞大的高素质的内网安全团队，这么做还行。其他大部分公司按这个照本宣科基本就是往坑里跳了

主要是把人访问服务的场景，通过受控设备+证书+SSO+安全基线+权限管理+全局风控 的思路，可以减少特权内网的负担，这个模式本身成本并不是太大。

核心还是风险认知模型，谷歌认为自己面临的风险级别很高，传统的边界安全防护思路根本无法依靠，这才提出的零信任安全模型，把安全防护级别原子化

除了互联网巨头，国内一般企业确实没有谷歌这种基因和技术基础，需要想清楚真实需求是什么，选择适当体量的解决方案。

VPN解决了什么： 认证+加密+收到一个内网

达到这个目标必须要VPN么？不是的

代理+TLS+ 终端认证（证书+账号密码+可信设备ID+物理环境+补丁杀毒软件无告警+xxx），能起到一样的作用

下面这个朴实无华的思路叫做BeyondCorp

叫什么不重要，做到了终端授信，终端补丁打了，杀毒装了，账号认证通过了才是有意义的

领会精神，重其意，不要看形状，全套难，可以优先搞准入呀，全协议难，可以优先搞web协议代理，风控难，可以只收数据不做动态调整

理解想实现的目标，再看怎么快速实现（不要管实现得是不是足够彻底优雅，就看性价比是不是最高，一步一步迭代到理想状态）

零信任会涉及比较大的架构改造，目前要么是大公司自己玩（谷歌），大it厂商结合自己的一整套产品提供比较自己闭环的一套方案（微软）。安全厂商层可能还只能在单点提供基础能力（如sdp）

零信任要做的并不是把内网系统互联网开放（他不是标准），只能说做好零信任的系统（按零信任做好安全设计），遇到远程办公这个场景，很多问题变成小问题而已，加上VPN的保护本质上还是提升安全了

信任层次的假设与区分本来就是组织最优化分配有限安全资源的基础，“有限”没有明显改善的时候打破信任层次，可能这就是大家说大企业才能做零信任的原因吧。我们内部也蹭零信任的概念向公司提方案，要资源，主要还是解决远程办公环境能访问的内部资源越来越多、这些资源越来越核心的情况下对传统VPN的不信任问题。简单的说就是，VPN这道锁保护的东西更多更重要了，我们需要一个加强版“VPN”，比如像谷歌的那种能识别设备可信度、增强账号认证强度、更严格访问控制与审计的“VPN”。

不能把所有的问题都推到一个产品中去解决，你这个是VPN+，谷歌的对这个问题，是一系列解决方案，不是VPN+的思路啊

### 网络安全域

安全域的话，我们是正儿八经的没做起来，做起来的话动作较大，要改变很多人的网络使用习惯，除了安全域，想到一些现有环境的安全改善，比如安全设备正儿八经的部署与使用、vpn权限与账号管理，网络设备上的安全策略梳理..

如果是已有数据中心，那么现状只能分阶段进行整改，需要网络部门同事大大支持才行，毕竟实施的都是他们

我们国外网络安全险产品比较成熟了，国内由于定价，定损，理赔存在较多不成熟的地方，产品还不敢引入

网络安全险目前限制还是很多，理赔范围主要还是误工这类损失。客户的期待是对结果风险的兜底。

数据中心网络架构除通常的边界安全和零信任热点外，一般安全也是不会有很大话语权的，就算有也建议从灾备、业务连续性和灵活扩展的可用性来提，加上监管红线的风险提示或通报部分即可，如 ddos，设备选型等，若需求被采纳则最好验收准备，此前发现问题而无法整改的，则提出要补偿控制措施，以此增加可能的安全鉴权和防护检测软硬件投入。

如果安全架构参与整体 infra 和网络规划的，根据数据中心所采用的技术，提对应要求，如是否采用集群技术、SDN、公私有云、监管、内外联等进行必要划分（非一定物理），根据业务体系来划分，并对不同应用定group、更甚至是超融合的等，安全根据所用架构和技术特点评估架构风险及可能弱点，给予调优，这也是成本合理考虑。而参与建设时需要结合安全战略或项目需要设置埋点，如是否同步采购安全资产和安全资源，或者统计好数据用于预算申请，可通过内部头脑风暴及和供应商的调研中进行补足。当然数据中心传统安全要求也是要的，这个gb标准很多，包括建设和验收。

### 自建机房与云

自建数据中心问题看得见摸得着，云端的让你云里雾里，出了问题无从入手，这样恐惧感会放大。抛开费用和功效率，其实云端问题出现概率和影响程度还是比自建要低。

我觉得，总得来说云的可靠性、安全性应该比自建数据中心要好，就像飞机的安全性相比于其它交通方式，是最好的。但是每次事故的影响都是灾难性的，所以看起来比较恐怖

上云是为了节省成本，不过节省成本不代表不要冗余了，从业务连续性角度看，冗余是必须的。要么是云服务商提供冗余，要么是自己提供冗余，相同的冗余要求下，还是云便宜

### 安全编排

安全编排 (Orchestration) 是指将客户不同的系统或者一个系统内部不同组件的安全能力通过可编程接口 (API) 和人工检查点，按照一定的逻辑关系组合到一起，用以完成某个特定安全操作的过程。

譬如用户针对一封收到的可疑邮件进行深入检测与响应（操作）的过程可以分解为根据拆解出来的发件人、URL 链接和 IP 等信息查询威胁情报系统，将附件送入沙箱系统进行分析，并根据情报系统和沙箱系统返回的信息进一步决定是否要通知邮件系统删除该邮件或者附件，是否要通过 EDR 获取收件人终端上的进一步信息做分析，等等。上述这个可疑邮件分析的过程就是一个将邮件系统、威胁情报系统、沙箱系统、EDR 等等系统通过一定的逻辑编排到一起的实例。

没有反对“安全编排”那个意思。但是我还是感觉，这东西对安全成熟度的要求挺高，能用起来的企业太少，一方面期待有大佬带动起来使用，一众人等观摩学习，另一方面也希望能有更能贴近中小企业的东西，他们不需要这么高要求或者驾驭不了这么高要求的产品，但是安全欲望却实打实的存在。