网络安全架构设计方案

去年秋天，网络我帮一家做跨境电商的安全朋友看他们刚被勒索软件锁死的网络。攻击路径简单得让人无语：一个没打补丁的架构VPN设备，弱口令，设计从外网直接捅进来，网络然后横移到数据库。安全事后复盘，架构他们其实买了防火墙、设计WAF、网络EDR，安全钱没少花，架构但这些东西各管各的设计，日志格式都不一样，网络告警没人看。安全这就是架构典型的安全堆砌，不是架构。

安全架构的第一件事，是搞清楚你要保护什么。不是列资产清单那么简单。我习惯画一张数据流图：用户从哪进来，经过哪些组件，数据落在哪，谁有权限碰它。这张图不画出来，后面所有设计都是拍脑袋。那家电商的问题就在这——他们从没画过这张图，VPN设备在资产表里甚至没标成关键节点。

边界防护仍然重要，但思路得变。传统做法是“外网不可信、内网可信”，现在这个假设已经站不住。攻击者一旦进来，内网横向移动几乎没阻力。我的建议是：把每个关键服务都当成暴露在公网来设计。微隔离不是新概念，但真正落地的少。具体做法可以很土——用安全组把数据库的访问来源限制到具体应用服务器的IP和端口，别图省事写0.0.0.0/0。这一条规则能挡掉大部分横向渗透。

身份认证这块，MFA已经是最低要求，不是加分项。但MFA也有坑。短信验证码可以被SIM劫持，TOTP令牌如果种子文件存在同一台机器上等于没加。我见过一家公司全员上了MFA，结果服务账号的密钥明文写在Git仓库里——攻击者根本不需要碰人的账号。机器身份的管理比人的身份更容易被忽略。给每个服务发独立的短期凭证，别用长期AK/SK，这事Kubernetes的ServiceAccount和Vault都能做，成本不高。

日志和检测，这是大多数中小团队的短板。买不起SIEM没关系，但至少把关键日志集中到一个地方——认证日志、防火墙拒绝记录、数据库慢查询和异常连接。用Elasticsearch加简单的规则就能跑起来。关键是有人看。我认识一个运维，每天花十五分钟扫一眼前一天的异常登录和端口扫描记录，半年内提前发现了两次暴力破解。工具不重要，习惯重要。

备份要单独说。3-2-1原则（三份副本、两种介质、一份离线）说了很多年，但勒索软件专治各种不服。离线备份的意思是物理隔离——备份服务器平时不挂载，需要恢复时才连上。云上的对象存储如果开了版本控制和MFA删除保护，也能凑合。但别把备份和原数据放在同一个域控下，那家电商就是这么干的，攻击者拿到域管权限后第一件事就是删备份。

最后说人。安全架构设计得再好，运维图省事把防火墙规则改成any-any，全白搭。流程要简单到不遵守反而更麻烦。比如新服务上线，默认拒绝所有流量，要开通得提工单，工单模板里直接填源IP、目的IP、端口。别让人自由发挥。安全不是靠自觉，是靠设计上让人没机会犯错。

这套东西不复杂，也不需要顶配预算。核心就一句：假设网络一定会被突破，然后围绕这个假设去设计检测、隔离和恢复。别把安全当产品买，把它当系统来建。