• 不要神化国外的安全建设

• Twitter的苦衷

• 要解决的问题

• 设计安全方案的原则

• 访问控制架构

• 注意事项

不要神化国外的安全建设

安全做的不差的NetFlix（参考Netflix的DevSecOps最佳实践），因为财报不理想最近股价大跌，Twitter有高危漏洞但是股价并未受影响，更加说明了笔者的论断：企业业务发展远比安全风险给股价带来的长期影响重要.....

此类漏洞举一反三TSRC（参考企业安全建设 丨 当我们在谈论推特安全事件时，我们在谈论什么？）给出的解决办法是一、内部系统需要零信任；二、权限类收敛采用框架集成全链路票据，数据操作层集中验票的，想来在腾讯完全落地有难度，也不能让Twitter快速解决问题。笔者看到Twitter内部这么久还没闭环，作为美国股市精神股东真替他们捉急。：）

根据最新的媒体报告，Twitter认为此次漏洞原因是”公司检测到了一次协同式社交工程攻击，发动者成功锁定了一些具有访问内部系统和工具权限的Twitter员工。黑客利用这些访问权限控制了许多知名账号和密码，之后便使用其账号发布关于比特币的动态。“，属于内部的人为失误\蓄意破坏\信息窃取这一类风险。上一次出类似的事情是前亚马逊工程师Paige Thompson 被指控利用工作方便来访问Amazon云服务上的Capital One服务器。

Twitter的市值只是1/48个谷歌，1/2个百度，市值决定安全的投入，不能盲目崇拜国外科技公司的安全建设。从历史反复漏洞披露的信息看到，Twitter内部存在不少历史安全问题。黑客简单社工后即可完全控制内部系管理统，利用内部权限可以控制用户Twitter账户，无审核机制，直接修改邮件重置密码，用户信息无隐私保护和数据脱敏。

Twitter的苦衷

Twitter案例中关键突破点是内部系统的高权限被社工或收买了。内部应用通常会涉及敏感数据或功能，例如用于生产系统的调试面板、账户管理系统或具有敏感公司数据的数据流和机器学习模型。Twitter安全性做的不好，是因为：

一、现有的商用防护方案又难以覆盖，传统的基于网络、员工身份的隔离方案完全不适用。不能仅仅将这些内部应用程序通过防火墙隔离，网络隔离仍然有可能会被意外配置暴露在公网，而且外部攻击者仍可通过XSS+CSRF或SSRF组合拳攻击，或者通过内网环境中已经隐藏攻击者（黑客或内部人员）。

二、这类问题一般并视为运维安全和办公网安全和开发安全的三者责任间。与生产环境相比，内部应用程序通常会被安全团队有意无意的忽略，安全团队反馈的吐槽是两个大问题：这类系统太多了，属于历史遗留问题；开发语言多样，没有统一的解决方案。

三、安全人员不足：Twitter的安全招聘信息已经挂了两个月了，看来还是缺人惹的祸。

要解决的问题

所以说现在的攻防趋势是技术上直接攻击越来越难，黑客转而关注间接从内部获取权限，并不仅仅遵循从internert-dmz-db存储的方式，走向了internert-内部用户或内部系统-信任关系-db存储。线上的生产环境经过了白帽子反复蹂躏，基本做到了符合安全基线，背后的开发语言、应用框架、资产管理是相对完善的。但是内部的私搭乱建，各种员工机器的的CI|CD系统，重要的内部服务系统，就有五花八门的开发语言，技术和风险了。

设计安全方案的原则

风险是普遍了，问题是需要复盘的。假设我们要防御类似于Twitter这样的攻击，需要安全建设的理念是：

• 不是ServiceMesh架构不能照搬lstio方案
• 防御方案应该是可扩展的，并且兼容后端的技术栈。
• 结合软件开发和发布流程
• 设计出色的技术解决方案还不够，落地才是
• 应用防御措施时，安全团队和开发项目组都需要参与进来

访问控制架构

以上是成形的架构。具体的解决办法是分为五步走：

1. 设置中间层代理，以往员工直接单独访问内部系统进行操作，危害性参考有：无网络隔离直接访问内部系统 里面可能包含未脱敏信息 缺少鉴权机制 这时候加个访问层的代理是解决问题的第一步。加入代理的好处多多，可以收敛入口，设置网络隔离，访问系统管理。一切的机制是在隔层的代理上做，代理的形式可以是api网关、统一portal。
2. 传输层加密。在准备推进代理的时候，不用等系统开发完成，可以调研引入全链路的tls进行传输层的加密。这里的理由有两个：Twitter这样和客户隐私强相关的企业，必须要防止内部网络层的窃听，每一层的安全措施都要做到底。借鉴google自研的ALTS，参考https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security?hl=zh-cn  或者FaceBook的方案 https://engineering.fb.com/security/service-encryption/ ，保证应用传输的安全，借用pki证书或者Kerberos机制可以用来表示服务的身份模型，而且具备极强的架构伸缩性。
3. 做到访问的统一收口，基于代理开发sso+u2f的机制做到访问的统一收口，逐步梳理系统让加入此机制。u2f机制一定层面上杜绝密码猜解、调用、离职员工访问的途径，后续添加FIDO等零信任访问控制措施。
4. 收敛员工的使用新版浏览器，前后端加入监控，日志，埋点，行为检测等功能，由运营风险分析（ORA）团队处置审计。
5. 代理添加通用CSRF保护（添加SameSitecookie标志）和XSS保护（Content-Security-Policy标头+随机数），设置内网waf。比如攻击者有个xss，可以使用csrf获取内部系统信息，这个时候在代理层设置csrf策略，对防护者成本极低，内部应用也无感知，但是收敛面向内部高权限人员xss的危害收益极高。内网的waf听起来会受到的接入阻力较多，但是内网场景固定，干扰项少，实际上内网waf的误报会很少，没有很多的噪音。

注意事项

拍脑袋出具安全方案不是问题，落地有防护效果才是，以下是几个要注意的点：

1. 安全需联合技术团队合作开发维护代理层，并在出现问题随时响应。有数字取证，安全工程或隐私工程方面的技术经验很重要，有维护高可用、系统稳定性运营经验的团队更重要！
2. 基于存量系统增加安全防护系统首先要考虑可维护性，可用性高于安全性，一定要避免出case。
3. 在不影响业务运营的时候同步进行开发和部署。理想情况下，如果代理服务器出现故障，背后存在关键系统，会阻止正常工作，假设如果代理后面有堡垒机，则如果代理发生故障，将再也无法再登录堡垒机故障排除......
4. 推进的节奏不用全面收敛，优先关注高危的风险。 如何确定要收敛的风险范围做到不遗漏呢？内部多打就好了。
5. 向上管理。这个框架可以帮助确定Twitter距离谷歌的差距在哪里，未来的安全投资方向是什么。有基于事件驱动的安全不可怕，没有将策略传达给高级管理层才可怕。笔者这里提供个简单的示例，点击可右移滑动：