网络安全观

安全产品终将成为服务

Sun, 12 Feb 2023 16:15:00 +0800

原创柯学 2023-02-12 16:15 北京

觉醒

全文约6千字 2图

本文的重点是讨论产品与服务的关系。产品与服务一直在纠缠之中，既是一对恋人，又是一对冤家。为此，我们将会讲述一个故事和一个模型。

一个故事：产品与服务之间有可能产生恶性循环，一个知名案例就是FireEye（硬件大师）和Mandiant（服务大师）之间的网络安全婚姻。在经历了传奇般的结婚和离婚故事后，郎才女貌并没有形成珠联璧合，最终分道扬镳。这也许是因为基因的差异性根深蒂固。

一个模型：尽管FireEye和Mandiant的故事反映了产品与服务之间的不良关系，但这却并非常态。安全服务飞轮从理论上解释了产品与服务之间的良性循环，并且表明：每个产品终将成为服务，只要产品活得足够久。所以，当你发现EDR供应商成为MDR供应商、XDR供应商推出托管XDR、SaaS供应商管理自己的SaaS功能时，请不要奇怪。因为安全服务飞轮在发挥作用。安全服务飞轮是一种永动机，即使在技术范式发生变化时也能保持服务的价值，从而使产品供应商转变为服务供应商以求生存。

360集团创始人周鸿祎在《星空下的对话》中提到的“安全服务化，服务托管化”，与安全服务飞轮的价值主张不谋而合。周鸿祎还提到：360的全部安全服务都将通过云和SaaS化的方式（如360企业安全云）来落地，这既是一种创新模式，也是对安全行业的颠覆式挑战。

安全领导者及其团队需要适应这种转变，逐步消除其心智模型和实施路线图中的产品与服务孤岛。

目录

1. 恋人还是冤家：FireEye(产品)与Mandiant(服务)的故事

1）Mandiant和FireEye的联姻寄托了美好希望

2）梦之队的艰难婚姻生活

3）STG：FireEye的收购者

4）Google：Mandiant的收购者

5）预言的兑现：Mandiant和FireEye的未来

2. 安全服务飞轮

3. 安全服务飞轮的新变化

4. 从产品转向服务

1）对甲方（客户方）的好处

2）对乙方（供应商）的好处

3）结束语

恋人还是冤家：FireEye(产品)与Mandiant(服务)的故事

产品与服务一直在纠缠之中，既是一对恋人，又是一对冤家。一个经典案例是Mandiant和FireEye的网络安全婚姻。关键时间线如下：

2013年，FireEye在以10亿美元收购Mandiant；
2021年6月，FireEye将其安全产品业务以12亿美元出售给STG（Symphony Technology Group）。STG是一家私募股权巨头；
2022年1月，STG将McAfee企业安全与FireEye合并成立新公司，正式命名为Trellix，致力于提供XDR（扩展检测与响应）解决方案；
2022年3月，Google 宣布斥资54亿美元收购Mandiant，成为Google 史上第二大收购案。Mandiant将加入Google Cloud，并保留Mandiant品牌。

1）Mandiant和FireEye的联姻寄托了美好希望

在婚姻之前，两个团体都分别赢得了他们的声誉：

FireEye：当FireEye在2013年以10亿美元收购Mandiant时，FireEye还是刚刚IPO成功的网络安全新宠，其股价较IPO首日暴涨80%，一跃成为网络安全领域的创新领军企业。当时，FireEye处于安全复兴的前沿，是一家“新型供应商”，采用新方法替代了过去十年的防病毒安全供应商。
Mandiant：随着APT1报告的发布而声名鹊起，并成为少数几家首选的事件响应公司之一，对国家参与者的多次入侵做出了回应。
美好愿望：FireEye期望借助产品+服务的联姻，可以构筑无比强大的网络安全梦之队。

2）梦之队的艰难婚姻生活

从第一天就开始了文化冲突。FireEye和Mandiant的文化从未真正融合。FireEye人员是硬件销售大师，而Mandiant 培养了一种专业和精通的文化。文化冲突导致梦之队的设想从未实现。而伤害是由于收购后的人才流失造成的，导致Mandiant人才散居国外，创办初创公司、经营其他安全公司。FireEye人员以同样的速度退出，并做出同样的事情。

FireEye的敏锐嗅觉。FireEye最值得被记住的事情就是：FireEye总是能在竞争对手之前采取正确的行动。比如收购Invotas（现为Helix）进军SOAR领域，收购Verodin（现称为Mandiant安全验证）进军BAS（入侵攻击与模拟）领域，收购Mandiant进军事件响应领域。然而，仅仅因为在对手之前采取行动，并不能总是成功。正如在所有上述赛道中，FireEye产品从未成为必备品。但反过来看，不能总是成功，也并不意味着它们是错误的选择。事实上，FireEye的敏锐嗅觉起到了市场催化剂的作用，促使竞争对手竞相模仿和跟随。

FireEye的产品从未成为必需品。FireEye的产品组合几乎涵盖整个技术栈的安全硬件，FireEye产品虽然不错但从未真正取代现有产品，也始终未能在市场上占据主导地位。比如防火墙仍然存在，而沙箱功能成为它们的一个特性；FireEye的其他产品如TAP和Helix，也从未能替换安全分析或SOAR(安全编排、自动化和响应 ) 领域。在同一时期内，Mandiant的业务表现非常出色（在多项Forrester Wave评估中被列为领导者），但FireEye安全产品在Forrester的评估中表现不佳。

Mandiant遭受的损失：Mandiant在其MDR（托管检测和响应）产品和其他安全服务方面，花了很长时间与“全FireEye生态”（all-FireEye ecosystem）绑定在一起（即排斥其它供应商产品）。正是因为如此，Mandiant不得不放弃其事件响应的声誉，并眼睁睁地看着其竞争对手（主要是针对CrowdStrike）在市场估值、股价、客户渗透率方面遥遥领先。最终Mandiant认识到传统FireEye解决方案阻碍了其业务发展。

Mandiant的行动：Mandiant开始慢慢通过传统服务和软件即服务 (SaaS)来重塑自己。通过MDR（托管检测和响应）、攻击面管理、Advantage威胁情报、安全验证（即BAS）及其传统事件响应业务等SaaS产品找到新动力。

3）STG：FireEye的收购者

STG（Symphony Technology Group）是一家私募股权巨头。到目前为止，私募股权对网络安全公司的收购，虽然为安全投资带来了大量活力，但为最终用户带来的创新很少。

无论STG收购RSA、McAfee、FireEye的原因是什么，这些供应商中的每一个都代表了一个曾经引以为豪的安全品牌，当这些品牌发现自己未能迁移到云并且转向SaaS时为时已晚，然后眼睁睁地看着自己的市场份额被竞争对手夺走。

STG收购的资本优势一定是巨大的，否则也没有信心将这些破碎的公司重新组合起来。也许STG计划创建某种网络安全超级团队，要么整合新公司，要么发布新品牌。无论如何，我们都不大可能会记得它是McAfee、RSA、FireEye。

最新进展是：2022年1月，STG将McAfee企业安全与FireEye合并成立新公司，正式命名为Trellix，致力于提供XDR（扩展检测与响应）解决方案。Trellix的名称取自trellis（格架），意为支持植物生长的安全框架。

所以，我们真地看不到FireEye了。

4）Google：Mandiant的收购者

安全实践始于内部零信任项目。Google的网络安全工作始于2011年发起的BeyondCorp（零信任项目）、2014年发起的Project Zero（旨在应对“零日漏洞”威胁）等内部安全项目。

网络安全商业化较晚。2012年Google对VirusTotal的收购可能表明谷歌对网络安全商业化的兴趣。但GCP（谷歌云）转向以企业为中心的商业能力的确有些晚，Google的X计划于2018年推出Chronicle，GCP于2019年收购它。

起步较晚只能买买买。谷歌和微软在企业业务上展开了广泛的竞争，两者都表示，将在未来五年内花费超过100亿美元发展网络安全。起步较晚需要溢价才能赶上。谷歌在2022年1月就收购了Siemplify（SOAR提供商）。2022年3月耗资54亿美元对Mandiant的收购，成为Google 史上第二大收购案。收购Mandiant，不仅能够补充Google Cloud在安全方面的现有优势，还将增强谷歌的安全运营套件和咨询服务，为其带去由包括600多名安全顾问和300多名情报分析师组成的网络安全精英。

开启网络安全发现新时代。GCP希望成为一流的网络安全公司。借助Mandiant的事件响应专业知识，再加上VirusTotal数据和Project Zero项目的人才，随着两个团队的合作，可能会开启一个网络安全发现新时代。

5）预言的兑现：Mandiant和FireEye的未来

2021年6月，Forrester副总裁兼首席分析师Jeff Pollard（正是提出“安全服务飞轮”概念之人）在其博客中预测了Mandiant和FireEye的未来：

Mandiant ：将受益于其收购方的剥离。Mandiant似乎能够通过精简自身来继续其前进势头。从FireEye中的拆分，还将使Mandiant能够继续利用其情报驱动的服务并发展MDR业务。通过更多地监控和管理任意供应商的安全产品，网络威胁情报团队将受益于对全球威胁形势的更高可见性。这一次性消除了Mandiant的所有偏见。
FireEye：当然也会受益于STG的财大气粗。但风险在于，它会与STG的另外两大网络安全“过时品牌”（McAfee 、RSA）进行合并。尽管FireEye确实大放异彩。然而，在一支糟糕的球队中成为最好的球员，仍然意味着你会输掉大部分比赛。而且到目前为止，PE（私募股权）对网络安全公司的收购，虽然为投资者带来了大量活力，但为最终用户带来的创新很少。
预言：Jeff Pollard在2021年6月的博客中预测，五年后，Mandiant将成为一个知名度很高的安全品牌；而FireEye可能会被淹没历史的车轮中。这毫无疑问反映出他对安全服务的看好。
预言的兑现：自2021年6月至今（2023年2月），还没到两年的时间，却已经出现了新的结果：FireEye确实已经融入到一家新公司Trellix中开启XDR之路，但已然失去了独立品牌；而Mandiant则融入到GCP中，准备大放MDR异彩，并且保留了独立品牌。他们的选择或许都是恰当的，也为我们留下了宝贵的启示。

安全服务飞轮

在前面FireEye(产品)与Mandiant(服务)的故事中，反映了盒子大师与服务大师之间的较量。而Forrester副总裁兼首席分析师Jeff Pollard的偏好无疑是站在Mandiant安全服务这一边的。

另外，FireEye(产品)与Mandiant(服务)的故事似乎反映了产品与服务之间的恶性循环（或许是缘于基因/文化的原因）。但Forrester副总裁兼首席分析师Jeff Pollard提出的安全服务飞轮概念，却完美地诠释了产品与服务之间的良性循环。

“安全服务飞轮”（Security Services Flywheel）是Forrester副总裁兼首席分析师Jeff Pollard在第一次加入Forrester时创造的概念。

机械飞轮：在机械工程中，飞轮实际上是一个储存动能的轮子，是拖拉机、蒸汽机、脚踏缝纫机运转的关键。
业务飞轮：当将飞轮概念应用于业务时，它通常表示公司不同的组成部分建立起不可阻挡的动力。关键点在于：飞轮的步骤不能只是企业不同部分的单独行动。它们必须在因果关系中相互引导。
安全服务飞轮：解释了为什么安全服务能持续保持价值，无论产品变得多么复杂。
安全服务飞轮的要点很简单：产品供应商承诺过多而交付不足。当用户发现交付问题时，通常为时已晚。他们购买的每件产品都会发生这种情况，只好求助于服务来解决未达到的期望。

图1-安全服务飞轮

安全服务飞轮的循环：

新产品出现：由于存在产品市场的匹配，新产品获得市场份额。
专业服务出现：产品售卖给客户后，客户的采用问题出现了，因为客户发现：部署和实施新产品给他们带来了挑战。这些采用难题导致了部署和集成专业服务的出现，这些专业服务通过产品供应商的服务合作伙伴来提供。
MSS出现：当客户的采用问题被解决之后，产品的日常运营问题又变得令人头疼，于是第三方MSS（托管安全服务）被引入进来。
SaaS出现：接下来，“产品”逐渐变成了一种服务：软件即服务(SaaS)！这时，客户不再需要维护它了，是吗？不。SaaS只是由其他人在其他地方托管的产品，它仍然需要悉心照料。
托管型SaaS出现：这才是SaaS产品功能和效果真正得到妥善管理的地方。

这个飞轮循环虽然特定于网络安全领域，但也适用于其他领域的产品和服务。飞轮循环可以一路验证回到防火墙和SIEM（安全信息与事件管理）。

先以防火墙为例：

首批防火墙在20世纪90年代初期和中期获得了认可和市场份额。
增值经销商和集成商前来安装它们。
1990年代中后期出现了第一批托管安全服务(MSS)提供商。

再以SIEM（安全信息与事件管理）为例：

早期的SIEM出现于2000年代中期；
实施SIEM的专业服务出现；
新一轮的托管安全服务(MSS)提供商出现，其他人将其添加到服务组合中。

安全服务飞轮在历史上持续发挥作用：每一个出现的产品都需要专业服务来实施，需要托管安全服务来运行，最终采取托管SaaS的方式（如果产品能够存在足够长的时间）。

但是，安全服务飞轮也并非一成不变，我们接下来看看它的新变化。

安全服务飞轮的新变化

现在，安全服务飞轮的主要变化在于供应商不再依赖这些服务的合作伙伴关系，而是几乎立即推出了自己的托管安全SaaS服务。这种情况最近在EDR（端点检测和响应）领域中显现，并在XDR（扩展检测和响应）领域中实时发生。

从历史上看，产品供应商会与服务提供商合作来提供服务，并且在推出自己的服务之前会等待很长时间，或者根本不会推出服务。而在最近的历史中，这种差距从几年缩短到几个月，而到2022年几乎消失了。供应商在发布新产品的同时，就会将其产品的完全托管版本推向市场。

下面，以EDR和XDR领域为例，我们来看看安全服务飞轮的新变化：

阅读原文

跳转微信打开

中国的网空能力

Wed, 01 Feb 2023 13:55:00 +0800

原创柯学 2023-02-01 13:55 北京

反方视角

全文约6千字

如果想知道美国如何看待ZG的网络空间能力，最佳资料当属2022年11月美国国会下属机构美中经济和安全审查委员会发布的《致国会2022年度报告》。该报告接近800页，其中有一节（第3章第2节）《ZG的网络（Cyber ）能力》，专门论述了ZG的进攻性网络能力。别小看这一节！它的篇幅是101页。

《ZG的网络能力》报告认为：“在过去的十年中，ZG大规模增强了其网络能力，并在今天的网络空间中对美国构成了巨大威胁。” 报告从三大方面来阐述ZG如何实现十年跨越式发展：

重组网络决策机构：对应于组织调整，这是顶层设计；
发展先进的网络战能力：以SSF为代表；
实施网络情报活动：以MSS为代表。

作为对比，在2021年的美国国际战略研究所（IISS）的评估报告《网络能力与国家实力：净评估》中，将ZG作为第2梯队国家看待。而这一次，明显更进一步，将ZG不仅仅是作为第2梯队，而是作为第2名看待，甚至为ZG是否美国的匹敌对手而争论。

报告在大谈ZG网络能力突飞猛进的同时，也列出了四点不足：

缺乏网络战理论和经验；
缺乏横向信息拉通；
无法高效运用预备役；
国内整体网络安全能力依然薄弱。

从立场的角度看，这是一次大反派的呐喊和宣泄，也是一次集中爆料。其中穿插了许多历史安全事件和人物，涉及不少国内安全公司、院校、科研机构。其中出现最多的是360公司，不少于11次，这当然是因为360最具备对美方网络攻击活动的披露能力。

英文原文的下载地址：

https://www.uscc.gov/annual-report/2022-annual-report-congress

在本文末尾，也直接给出了英文原文（PDF版）和付费机器翻译中文版（Word版）的下载方式，但需付费查看。

阅读原文

跳转微信打开

美军进攻性网络作战架构

Sun, 27 Nov 2022 15:29:00 +0800

原创柯学 2022-11-27 15:29 北京

网络作战平台的天选之子

全文约7500字 17图阅读约20分钟

通常认为，网络攻击是一种"小作坊"的工作方式，从来不觉得它与高大上有何关联。但是，美军就真地把它变得高大上了。

自2018年来，美国网络司令部尝试建立"正规军"的网络作战方式——联合网络作战架构（JCWA）。但遗憾的是，我们对美国国防部的进攻性网络作战架构，难以有深入的了解。因为进攻性网络作战的领导者是网络司令部，它的前身是NSA（国家安全局），这两个部门都是出了名的嘴巴严，很少透露深度资料。

但嘴巴再严，也有被迫张开嘴的时候。特别是在GAO（政府问责局）的审计要求下，它不得不透露更多的信息；而在一些国防部对外采购会议上，它也不得不展示一些细节。这也使得我们看到了一些真面目。虽然不多，但胜于无。

不论网络攻击，还是网络防御，都有两个共性难题：一是时间（效率），二是空间（规模）。而解决之道，唯有自动化。放在防御领域，就是安全自动化；放在攻击领域，就是攻击自动化。

很多人曾经认为：美国国防部（由DISA主导）以急先锋姿态推进的零信任架构（ZTA）是一种虚张声势！但现实是：美国国家级别的联邦政府零信任战略已经颁布；美国国防部级别的零信任战略和零信任参考架构已经发布；国防部的零信任试点项目（雷霆穹顶）正在加速推进。

很多人仍然认为：美国国防部（由网络司令部主导）以颠覆者姿态推出的联合网络作战架构（JCWA）是一种虚张声势！但现实是：该架构的所有六大支柱型产品均已具备交付能力，正在按照推进时间表有序迭代。

我们当然可以怀揣着阿Q精神/精神胜利法，继续对自己小作坊式的攻击方式感到沾沾自喜，但请不要对美军的集团军式的网络作战架构掉以轻心。

关键词：JCWA（联合网络作战架构，Joint Cyber Warfighting Architecture）；UP（统一平台，Unified Platform）；JCC2（联合网络指挥与控制，Joint Cyber Control and Command）；JCAP（联合通用访问平台，Joint Common Access Platform）；PCTE（持续网络演训环境，Persistent Cyber Training Environment）；JADC2（联合全域指挥与控制，Joint All-Domain Command and Control）；GAO（政府问责局，Government Accountability Office）；

目录

1. 网络司令部的创新战略

2. What：JCWA是什么？

2.1 JCWA是什么？

2.2 JCWA的体系组成图

2.3 JCWA的六大支柱

3. Why：为什么要开发JCWA？

3.1 JCWA的根因是网络司令部要独立

3.2 为什么情报工具和作战工具必须分开

3.3 JCWA成为作战工具的天选之子

4. How：JCWA的运行机理

4.1 JCWA在网络司令部使命中的定位

4.2 JCWA的运行机理

4.3 JCWA如何用于网络作战

4.4 值得深究的JCWA传感器

5. How：如何推进JCWA建设工作？

5.1 JCWA的建设预算

5.2 JCWA的建设进度

5.3 对JCWA的评估情况

网络司令部的创新战略

网络司令部在2022年8月的一次对外采购会议PPT上展示了它的创新战略。

网络司令部创新战略的目的：建立并培养一种鼓励和奖励创新思维和冒险精神的文化。

网络司令部创新战略的目标：

开发一个框架，在我们最具挑战性的问题上实现协作，并展示前所未有的能力和大幅提高的效率。
将投资投入到相关的、前瞻性的概念上，以创造能力优势，同时获得切实的、重大的任务成功。
扩大网络创新团体的规模、专业性、影响力；让网络司令部成为思想领袖——“塑造网络空间作战的未来”。

网络司令部还引用了下面的创新类型矩阵图：

图1-创新频谱

这个创新频谱并没有什么稀罕的，而真正令我稀罕的是网络司令部随后展示的这张图：

图2-网络司令部的持续创新：跨越创新频谱

笔者对此图的理解是：

“跨越创新频谱”之含义：是指4种类型的创新（图中最右侧）都需要；
“转折点”之含义：是指如果缺少颠覆型创新，就不可能在能力上超越网络对手。原因何在？因为敌手的能力是指数性增长的（即图中的红色曲线），而增量型创新、进化型创新、彻底型创新都是线性增长的（即图中的蓝色直线），仅靠这些类型的创新永远追赶不上敌手的能力；而颠覆型创新才具有指数性增长的潜能（即图中的绿色曲线），所以它也是唯一的希望。

问题来了：网络司令部的颠覆型创新是指什么呢？毫无疑问，正是联合网络作战架构（JCWA）！

What：JCWA是什么？

2.1 JCWA是什么？

JCWA是网络空间进攻领域的作战架构：

JCWA是一个能力套件；
数据整合：JCWA整合了进攻性数据和防御性数据；
作用领域：JCWA涵盖竞争、危机、冲突领域；
目标：JCWA使得指挥官能够

● 衡量风险；

● 及时做出决策；

● 以足够快的速度（时间维度）和足够大的规模（空间维度）展开行动。（笔者注：这一条正是笔者认为国防部努力实现攻击自动化的佐证。）

笔者的观点：JCWA的关键要求是互操作性、集成性、自动化，核心目标是实现网络攻击自动化。

JCWA是一种企业架构。与国防部（DoD）和情报界（IC）的企业观一致，网络司令部将联合网络作战架构（JCWA）视作一种企业方法。网络司令部的执行主任称“就像任何公司企业都会考虑如何管理广泛的业务一样，我们将网络司令部视为一个企业，而联合部队总部也是该企业的一部分。”联合网络作战架构（JCWA）正是这样一种企业作战架构。当然，JCWA的五大不同组件可以在统一架构之下由不同军种开发，比如统一平台（UP）由空军开发，联合网络指挥和控制（JCC2）系统由陆军开发。

2.2 JCWA的体系组成图

图3-JCWA的组成

2.3 JCWA的六大支柱

如上图所示，联合网络作战架构（JCWA）包括五个组成部分：

统一平台（UP，Unified Platform）：是JCWA的大数据分析平台，负责数据管理和集成，目的是为网络作战人员和支撑人员提供数据同步和系统访问。它被认为是摄取、分析、共享数据的核心。
联合网络指挥与控制（JCC2，Joint Cyber Control and Command）系统：是决策平台，目标是整合来自多个来源的态势感知数据，以支持指挥官的作战决策；旨在战略、战役、战术各个层面增强美军网络空间作战的态势感知和战斗管理，从而加强网络指挥和控制，提升联合作战效能。
联合通用访问平台（JCAP，Joint Common Access Platform）：是任务执行平台，目的是为美军网络空间作战部队提供一个通用的网络火力投送平台。
持续网络演训环境（PCTE，Persistent Cyber Training Environment）：是演训平台，旨在为网络空间作战部队提供持续的网络演训、评估、任务演练；
传感器：用于传递情报、监视和侦察数据，支持网络防御和推动作战决策。由于传感器常常被忽视，笔者专门用一小节（详见第4.4节）来讨论它。
网络工具：是用于保卫己方网络和攻击敌方系统的各种网络工具。

下图中关于各个支柱的能力分解，有助于理解六大支柱的基本功能：

图4-JCWA六大支柱的基本功能

这6大支柱如何统筹运行，以开展网络作战行动呢？笔者专门在4.3节中，用一张2022年8月新发布的网络作战示意图（图9；也是本篇微信的封面图）和流程解读，来回答这个问题。

Why：为什么要开发JCWA？

3.1 JCWA的根因是网络司令部要独立

官方的说法是：网络司令部一直希望摆脱各个军种独立开发各自网络战工具的情况，希望创建一个更具联合性的架构，使得各个军种都可以为整个网络任务部队开发工具和能力。于是，网络司令部在2018年创建联合网络作战架构（JCWA）。

但笔者认为：从根因分析的角度来看，开发JCWA的根本原因是网络司令部要真正地独立。绝大部分人不会意识到这一点。

了解美国国防部“双帽体制”的人都清楚，网络司令部是从NSA（国家安全局）拆分出来的，而且网络司令部和NSA一直拥有同一个最高领导人（这被称为“双帽体制”）。

为了防止2009年新成立的网络司令部的夭折，也为了防止NSA做甩手掌柜，2017年《国防授权法案》中规定了一项硬性要求：“在分裂之前，参谋长联席会议主席和国防部长必须证明，如果分裂，网络司令部和NSA的能力都不会降低。” 也就是说，如果不能证明这一点，网络司令部和NSA就只能维持双帽体系，而不能彻底分离。

笔者认为：网络司令部和NSA的彻底分离必须包含以下三个方面：

人员和员工的分离：这一步是完成时，即由6千多人组成的133个网络任务部队；
基础设施和工具的分离：这一步是进行时，将在下面小节专门解释；
领导人的分离：这一步是将来时，也是彻底分离的标志，网络司令部和NSA将不再共用同一领导人。

3.2 为什么情报工具和作战工具必须分开

由于作战需要情报支撑这一天然需求，网络司令部与NSA的合作关系将永远保持下去。

但是，两者毕竟扮演不同的角色：NSA是一个情报组织，执行情报任务；网络司令部是一个作战组织，执行作战任务。

所以，从长远来看，正确的答案是将两者分开。这几乎是不可避免的。

正是因为网络司令部具有与NSA不同的任务集，当然就需要单独的基础设施、工具、培训才能独立运作。想想看，旨在延迟、降级、破坏等等的作战工具，与旨在驻留和提取信息的情报工具，确实是很不相同的。而两者主要重叠的部分在于网络渗透。

从另一方面看，如果网络司令部和NSA共享同一套基础设施和工具集，将对情报工作带来巨大的潜在风险：因为作战行动通常执行破坏目标网络的嘹亮、进攻性军事行动，并不会过多考虑网络通道的隐蔽性。那么，这些嘹亮的攻击行动就可能会导致承载它的网络通道被对手追溯，从而将对手带回 NSA服务器，并获悉NSA的情报能力。这就对NSA的情报工作造成了破坏它。

说得简单点：网络司令部的思考方式是“我正在打仗，会不会被抓并不重要！”而NSA的思考方式是“我在搞间谍活动，绝不想被抓住！” 让者两拨人使用同一套基础设施，一定会造成互相伤害的。

想想看，如果你搞情报活动的工具上有作战组织的签名，那么你的情报活动就很有可能被误会为战争行动，从而违反国际法。但事实上，这本来只是一项微不足道的情报监视活动。

也正是因为上述原因，情报工具和作战工具必须分开，情报组织和作战组织必须分离。

3.3 JCWA成为作战工具的天选之子

在很长一段时间里，网络司令部都使用着NSA的各种工具集，包括斯诺登泄露的那些。但那是过去时。

网络战士为了成功执行网络作战任务，需要适合的平台、界面、工具集、基础设施，就像更传统物理领域中的战士一样。独立的网络司令部必然需要自己的基础设施，来执行自己的作战任务。

国防部的多数高层领导认为：除非网络司令部拥有一个单独平台来独立开展作战任务，否则就不主张将网络司令部与NSA分开。

这个单独平台的历史使命最终落到JCWA的身上。当然，它在早期也有别的名字，比如军事网络作战平台（MCOP）。

所以，笔者才认为：JCWA是网络作战平台的天选之子。

所以，JCWA不仅从网络司令部独立的角度来看是必不可少的，而且对于行使网络作战职责的指挥部来说也是必不可少的。

阅读原文

跳转微信打开

网络安全的三大支柱和攻击向量

Sun, 11 Sep 2022 06:59:00 +0800

原创柯学 & 启承 2022-09-11 06:59 北京

身份高于账户，权限细于身份

全文约5000字 10图表阅读约5分钟

BeyondTrust公司（连续4年Gartner特权访问管理象限之领导者）的首席技术官和首席信息安全官Morey Haber（莫雷·哈伯），与人合著，一口气写了三本书：

《身份攻击向量》：从身份角度出发，考察攻击向量，设计IAM(身份与访问管理)方案。
《特权攻击向量》：从权限角度出发，考察攻击向量，设计PAM(特权访问管理)方案。
《资产攻击向量》：从资产角度出发，考察攻击向量，设计漏洞管理方案。

有趣的是，作者认为：这三本书正好构建了网络安全的三大支柱：1）身份；2）权限；3）资产。而只有基于稳固的三角架结构，才能构建稳健的安全基础。

最值得提醒的是：三大支柱的集成/整合至关重要。一个好的安全解决方案一定要有利于三大支柱的集成。反之，如果一个安全方案没有跨这三个支柱来运行，也没有促进三大支柱的互操作性和数据集成，那么它就是一个孤岛解决方案。

对于如此系统阐述其安全框架和具体方案的系列书籍，笔者自然不愿错过。在纵览近千页的英文版后，希望将其推荐给大家。

目前，《身份攻击向量》中文版已经于2022年8月面市，在此感谢译者赠书！据悉，另外两本也在翻译过程之中。

本文试图以世界顶级IAM和PAM专家的视角，反映身份和权限的攻击向量和防御之道。

看见是王道！孤岛很糟糕。你是在创造“看见”，还是在创造“孤岛”？你能同时看见漏洞、身份、权限吗？

关键词：IAM（身份和访问管理）；PAM（特权访问管理）；

目录

1.网络安全的三大支柱

2.横向移动的攻击向量

3.网络杀伤链中的身份攻击向量

4.从传统4A到现代5A

1）IAM(身份访问管理)的5个A

2）为何少了账户(Account)？

3）为何多了管理(Administration)？

4）为何多了分析(Analytics)？

5.从IAM(身份访问管理)到PAM(特权访问管理)

6.洞察和见解

网络安全的三大支柱

作者认为：在宏观层面上，如果对所有安全解决方案进行分组，就会发现每个方案都属于三个逻辑分组之一。这三个逻辑分组构成了网络安全的三大支柱。如下图所示：

图1-网络安全的三大支柱

三大支柱：

身份(Identity)：保护用户的身份、帐户、凭证，免受不当的访问；
权限(Privilege)：对权限和特权的保护，以及对身份或帐户的访问控制；
资产(Asset)：对一个身份所使用（直接使用或作为服务使用）的资源的保护；

一个好的安全解决方案应该同时涵盖所有三个支柱，而这三大支柱的集成/整合至关重要。所以，一个好的安全解决方案一定要有利于三大支柱的集成/整合。

如果一个安全解决方案只能孤立运行，无法与其它方案兼容，也无法使三个支柱互通，就无法有效应对现代威胁：

比如孤立的杀毒软件方案：虽然能够报告资产的感染情况，却无法判断恶意软件使用什么身份（账户或用户）或权限来入侵目标资产。因为它无法共享和获取用户的身份信息和身份的上下文。
再比如孤立的漏洞管理方案：虽然能够扫描到资产的漏洞信息，却无法发现可访问该资产的账户和用户组信息，也就无法更好地帮助确定补丁的优先级，也无法帮助管理好身份攻击向量。

话再说得狠一点：如果一个安全厂商没有跨这三个支柱来运行，也没有促进三大支柱的互操作性和数据交换的集成/整合策略，那么它确实就是一个单点/孤岛解决方案。请慎用这样的方案。

为何是3大支柱，而不是4或5根支柱？作者解释说：因为3条腿的凳子不会晃！

作者为三大支柱分别写了一本书：

《身份攻击向量》：中文版已出版。本文主要引自该书。该书更多地从身份角度出发，考察攻击向量，设计IAM方案。
《特权攻击向量》：中文版尚在编写过程中，待出版。该书更多地从权限角度出发，考察攻击向量，设计PAM方案。
《资产攻击向量》：中文版尚在编写过程中，待出版。该书主要讲述资产漏洞管理。其重要性在于：漏洞管理是安全的基础。当资产本身可被漏洞利用时，身份也难以得到保护。

横向移动的攻击向量

攻击向量总体上可以分为两类：1）资产攻击向量；2）权限攻击向量。这两类正好对应于作者的两本书：《资产攻击向量》和《特权攻击向量》。

资产攻击向量/方法：一般通过漏洞和配置缺陷来实现。防御方法是漏洞管理、补丁管理、配置管理等传统的网络安全最佳实践。在这个方面，每个组织都应该做好，但在现实中并非如此。
权限攻击向量/方法：通常采取某种形式的特权远程访问，所用技术包括口令猜测、字典攻击、暴力破解、Hash传递、口令重置、默认凭据、后门凭证、共享凭据等。防御方法是零信任模型和即时(JIT)权限访问管理。

值得特别说明的是：(狭义)零信任、即时身份、特权访问管理这样的现代安全模型，主要用于缓解权限攻击向量，并不能缓解资产攻击向量。

横向移动是勒索软件、机器人（Bot）、蠕虫和其他恶意软件等现代威胁的主要攻击手段。

横向移动是指从一种资源转向另一种资源并在这些资源之间持续跳转的能力。所谓“资源”，不仅指资产（如计算机、操作系统、应用程序、容器、虚拟机等），还包括账户和身份（如下表第一列所示）。

以横向移动攻击为例，两类攻击向量的示例如下表所示：

表2-横向移动技术中的攻击向量

上面只提到了两个支柱的攻击向量，第三个支柱（身份）的攻击向量呢？我们将在下一小节专门呈现。

网络杀伤链中的身份攻击向量

以业界熟知的网络杀伤链为例，来看看身份攻击向量的表现方式。我们按照杀伤链的四个阶段来分别反映（身份攻击向量以蓝色字体标记）：

图3-侦察阶段的身份攻击向量

图4-入侵阶段的身份攻击向量

图5-利用阶段的身份攻击向量

图6-渗出阶段的身份攻击向量

从上述攻击链的四个阶段来看，身份攻击的重点在于其中的两个阶段：入侵阶段和利用阶段。在这两个阶段中，身份攻击的主要目标是两个：权限提升和横向移动。

所以，可以得出的结论是：身份攻击向量的本质是构建权限攻击链，以实现权限提升和横向移动。如下图中的蓝色虚线小圈所示：

图7-权限攻击链

从传统4A到现代5A

1）IAM(身份访问管理)的5个A

图8-身份管理的五个A

IAM的新5A是指认证(Authentication)、授权(Authorization)、管理(Administration)、审计(Audit)、分析(Analytics)。

而传统4A是指认证(Authentication)、授权(Authorization)、账户(Account)、审计(Audit)。

新5A和老4A的共性是：认证、授权、审计。审计就不说了。书中对认证、授权给了如下简明公式：

认证=登录名+密钥（口令）；
授权=权限(privilege)+认证；

新5A和老4A的区别是：少了账户(Account)，但多了管理(Administration)和分析(Analytics)。这块涉及到新5A和老4A的理念问题，故值得解释一下。

2）为何少了账户(Account)？

笔者认为：这与该书作者强调“身份”而弱化“账户”有关。

这里就涉及身份与账户和用户的区别：

账户是身份的电子表示；
一个身份可以对应到多个账户；
一个身份只能对应到一个用户；

从身份安全的角度看，身份比账户更重要。但身份只能通过账户来发挥作用，账户是身份的表现形式。而账户能否真正发挥身份的价值，取决于账户能否能被映射到身份上。

所以，账户与身份的关联至关重要。无法关联到身份的账户，都是身份的攻击向量。比如企业中常见的“孤儿帐户”，即那些没有关联到已知用户的帐户。还有应用程序用来访问数据库的共享服务账户，如果无法关联到真实的用户身份，就没法知道究竟是谁访问了你的数据（参见《谁动了你的数据？》）。而现代身份治理的核心目标之一正是将账户与真实用户（身份）建立关联，尽量消除孤儿账户的存在。

所以，在传统4A中，尽管已有账户体系，但很多时候却无法映射到身份。这就是传统4A只是账户安全，而现代5A才是身份安全的原因。

这里甚至涉及到类似哲学层面的问题：账户可以赋予一切网络主体，而身份只能赋予人类或软件机器人。也就是说，一个网络主体（应用程序、网络设备等）是否被赋予身份，要看它是否模仿一个人。想要模仿人的（比如快递机器人）才需要身份，否则只需要赋予账户即可。也就是说，通常的网络设备和应用程序，只需要分配账户即可。过度分配身份，将会把问题复杂化，也会导致更大的攻击向量（因为身份攻击向量大于账户攻击向量）。

我们曾经设想，在即将来临的万物互联时代，要对联网的万事万物（物联网设备）都分配数字身份。看完这本书时，你必然产生大大的问号。因为它不像我们之前想的那么简单。

3）为何多了管理(Administration)？

此处的管理是指对身份验证、授权、审计的任何变化进行配置管理和治理控制。

在IAM领域发展了25年之后，我们回头想一想：有多少东西发生了变化，又有多少东西没有变化。就会发现：认证(Authentication)和授权(Authorization)技术发现了太大变化；而管理(Administration)一直是比较稳定的需求（也一直没有做好）。所以，才要把管理从认证和授权中分离出来，构成单独的一个A。

也许你会问起身份治理（Identity Governance），而身份治理恰恰涵盖了管理(Administration)、审计(Audit)、分析(Analytics)这三个A。

4）为何多了分析(Analytics)？

分析是指通过持续收集和处理与身份相关的配置、分配、使用数据，获得运营和安全洞察。

高级身份分析支持更明智、更具预测性的治理方法。通过使用机器学习(ML)和人工智能(AI)技术，身份分析工具可以提供重要的对等组分析信息，有助于扩展身份审核和管理功能，并使它们更具动态性和响应性。

传统4A缺少分析。随着机器学习(ML)和人工智能(AI)的进步，现在可以发现和处理大量的运营数据，以揭示隐秘的洞察和可操作的指示，远远超越了传统的基于规则的引擎所能实现的能力。

从IAM到PAM

领域的差异。IAM（身份与访问管理）更加侧重于身份；PAM（特权访问管理）更加侧重于权限。两者分别应对了两大支柱（即身份支柱和权限支柱）的安全需求。

功能的差异。下图展示了IAM和PAM的功能组成：

图9-IAM和PAM的组件

用户的差异。特权是比普通权限更高的权限。对用户的最基本分类是两种：标准用户（具有普通权限）和管理员（具有特权，还进一步分为本地管理员和域管理员）。通常，也会增加来宾用户（低于标准用户的权限）。

关于用户的更加精细的划分。我们以具有制造环境的组织为例，IAM和PAM的用户范围如下图所示：

图10-IAM和PAM的范畴对比

资源的差异。权限的视角一方面是在宏观用户级别上（这是IAM侧重的），另一方面是在微观资源级别上（这是PAM侧重的）。从资源层面看，将权限仅仅视作应用程序的一部分，是短视的。权限还必须嵌入到资源的每个层次中，即嵌入到操作系统、文件系统、应用程序、数据库、虚拟机管理程序、云管理平台，甚至通过分段嵌入网络中，才能应对高级别的权限攻击。

可见性的差异。IAM可以回答“谁有权访问什么？”但是，为了实现完全的用户可见性，PAM解决了剩下的问题:“这种访问合适吗？”以及“这种访问是否被恰当地使用?”也就是说，PAM可以对特权帐户的访问和使用提供更多的可见性和更深入的审计。

很多时候，IAM会将用户添加到系统或应用程序组中，但不会提供有关该组成员具备的访问权限的详细信息，也不会提供对特权会话期间收集的详细会话日志或键盘记录的访问能力。而PAM可以扩展这些能力。因此，PAM扩展了IAM解决方案的可见性。

特别说明：在同一作者的另一篇书籍《特权攻击向量》中，系统阐述了PAM。而《身份攻击向量》的翻译团队也正在对其进行翻译中。期待译本在不久的未来面世。

洞察和见解

在该书的最后一章中，作者给出了身份访问管理（IAM）的关键原则：

思考身份而非账户。组织中的一个用户通常拥有多个帐户和每个帐户的多项权限。如果企业只将IAM计划的重点放在帐户级别（而非身份级别）的管理上，它将永远无法获得正确了解“谁有权访问什么”所需的整体可见性。理解身份与其帐户之间、帐户与其权限之间、权限与其保护的数据/信息之间的三向关系是关键。只有围绕身份（而非账户）来集中相关数据，企业才能形成正确的视图和可见性。
看见是王道！孤岛很糟糕。伴随着云、物、移、大的趋势，集中化的单点可见性成为组织安全性之关键。唯有如此，才能确保在企业范围内看见其身份和访问数据。
全生命周期的身份治理是必需的。通过在身份的整个生命周期中嵌入策略和控制，组织可以实现增强的自动化、持续的合规性、降低的安全风险。
将IAM与PAM集成部署。PAM是对IAM方案的补充，增加了对"特权"帐户的控制和审计层。
采用预测性方法。积极应用机器学习和人工智能技术，以实现更加智能、更加明智的访问决策。
实现最小权限。
用户体验至上！身份治理和权限管理技术必须有助于提供更好的用户体验，如果不想被业务人员否定其安全价值。

（本篇完）

阅读原文

跳转微信打开

谁动了你的数据？

Sun, 04 Sep 2022 06:06:00 +0800

原创一帆 & 柯学 2022-09-04 06:06 北京

你以为你以为的，就是你以为的吗？

全文约4000字阅读约5分钟

“谁访问了你的数据？” 这看似一个简单的问题，却很难回答：

首先，你以为数据库日志记录了身份，但数据库日志常常是被禁用的；
然后，你以为应用程序日志记录了身份，但其实没有；
于是，你以为强行启用数据库日志就可以解决问题，但并没有；
接着，你以为应用程序可以把身份带给数据，但其实不行；
终于，你以为这样就没辙了，但聊暗花明又一村……

上述问题本质上是数据访问的身份归因。

我们知道，对于应用程序的访问而言，身份归因是比较容易的，通常由单点登录(SSO)即可解决；那对于数据的访问，身份归因为何就如此困难呢？

区别就在于：“谁访问了你的应用”并不等同于“谁访问了你的数据”。在应用程序和数据之间，存在一条难以逾越的大河。

所以，将零信任思想应用于数据访问时，听起来很简单；但将零信任技术应用于数据访问时，做起来却很困难。

当然，对于正确的事情，即使困难，也该做。

再问一遍：在贵组织的数据访问过程中，真地有用户身份吗？

关键词：SSO（单点登录）；DSP（数据安全平台）；身份提供者（IdP）；

目录

1.问题：谁访问了你的数据？

2.你以为数据库日志是默认启用的

3.你以为应用程序日志可以办到

4.你以为强行启用数据库日志就好

5.既然无解，请向前辈(应用程序)学习

6.然而，数据并没有SSO(单点登录)

7.既然没有数据SSO，那就创造一个

8.答案：具备数据SSO的数据访问平台

问题：谁访问了你的数据？

谁访问了你的数据？很容易提问，但很难回答。

当我们在被审计过程中试图证明我们过去的访问行为是正当的时，我们可能会被问到这个问题；当我们处理数据泄露问题时，我们可能会被问到这个问题。

在大多数情况下，我们都以非常被动的方式回答这些数据。因为我们看不清也说不清这个问题。

当被问及这个问题时，你可能会觉得自己被置于聚光灯下，甚至是审讯椅上。

你以为数据库日志是默认启用的

遇到这个问题，我们通常的想法是查看数据库日志，看看是否可以找到答案。但通常没有数据库日志，因为数据库日志经常被禁用。

为什么我们经常会关闭数据库日志呢？

一是延迟。通常，应用程序中的最慢部分就是数据访问，即连接到数据库并检索数据。而数据库检索数据的最慢部分是从磁盘读取数据。当我们写入日志时，我们需要执行两个磁盘操作，从而增加了应用程序的延迟。因此，出于性能原因，我们可能会选择禁用日志记录。

二是存储。我们也可能出于存储原因选择禁用日志。数据库服务器的工作是存储关键业务数据。随着时间的推移，我们可能会存储大量数据，导致我们很久以前选择的磁盘大小现在可能不够了。我们只好先删除一些不需要的东西，首先想到的自然是删除数据库日志。

另一方面，即便数据库日志存在，它们可能太贫乏而无法获得有价值的见解。对此，后文再做解释。

你以为应用程序日志可以办到

接下来，我们考虑应用程序日志。

任何使用我们数据库的东西，都可能来自我们的应用程序。值得庆幸地是，我们对应用程序的使用过程有很好的日志记录。我们可能有非常漂亮的仪表板，向我们展示经过身份验证的用户活动、页面请求、响应HTTP状态代码，以及完成请求所花费的时间。于是，我们希望通过这些日志来回答“谁访问了我们的数据？”这个问题。

但是应用程序日志是否足以回答这个问题？不幸的是，并非如此。因为还存在许多不通过应用程序连接到数据库的场景：

SRE（站点可靠性工程师，Site Reliability Engineer）：会跳转到客户帐户，以快速修复一些数据错误并让客户恢复正常。
DBA(数据库管理员)：直接登录数据库，以调整索引或重写慢查询。
部署工具：运行数据库迁移，以部署软件的新版本。
批量数据提取工具：可以帮助新客户加入或帮助老客户离开。

这些连接是否通过应用程序？他们可能不是。他们可能通过数据库管理工具直接访问数据库。

还可以列举多种合法的场景，其中正常的数据访问都不是通过我们的应用程序完成的；而对于其它不合法的活动，当然很可能也不是通过应用程序来完成的。

使用应用程序日志来回答有关数据库访问的问题，仍是一个谎言。因为数据访问不仅仅通过应用程序发生。

你以为强行启用数据库日志就好

既然没辙，就让我们启用数据库日志吧。

如果我们查看Postgres官方文档，就会发现：默认情况下日志是禁用的——正如前文所述。

当然，我们可以启用日志，即通过如下配置，将日志级别从无更改为全部：

postgres -c log_statement=all -c logging_collector=on

启用日志后，再重启数据库。然后，使用应用程序和终端工具访问数据库。这时，我们可以看到类似下面的日志信息：

2021-02-21 15:35:07 CET [3492-349] postgres@prod LOG: execute : SELECT id FROM public.task WHERE id = 7;

2021-02-21 15:35:07 CET [3492-350] postgres@prod LOG: duration: 11.069 ms

2021-02-21 15:35:08 CET [3494-223] postgres@prod LOG: duration: 0.030 ms

2021-02-21 15:35:08 CET [3494-224] postgres@prod LOG: duration: 0.081 ms

我们的确可以看到执行的查询操作、查询的日期/时间、消耗的时间，但看不到查询是由谁执行的。即便我们想记录用户信息，我们可能只会看到应用程序使用的服务帐户。

而即便是由非应用程序型工具所运行的查询，也可能仍然使用相同的服务帐户。我敢打赌，DBA或SRE用户只是打开了Web应用程序，又从配置文件中提取了凭据，然后登录。

为何会执着地使用服务帐户？因为在数据库中创建个人用户，并使其在员工加入和离开时保持同步，真是太困难了——所以没法这么做。于是，大家都使用相同的服务帐户。

关于日志的小结和回顾。出于性能原因，可能会关闭数据库日志，以避免额外的磁盘访问延迟或节省宝贵的存储资源。即使我们打开了日志，所有访问都使用单个服务帐户——不论是来自我们的微服务的访问，还是来自非应用程序型工具的访问（如DBA、SRE、DevOps工具）。总之，数据库日志不包含用户身份信息，所以无法帮助我们回答“谁访问了数据？” 这个问题。

既然无解，请向前辈(应用程序)学习

或许，你以为没辙了。但还可以向前辈（应用程序）学习。

我们知道，Web应该程序使用单点登录 (SSO) ，完美地解决了身份问题。我们来看看，它是如何做到的。

SSO的工作流需要用户、应用程序、身份提供者 (IdP) 这三方的共同努力：

用户启动Web应用程序
用户点击登录
浏览器重定向到身份提供者 (IdP) 登录页面
用户登录到这个受信任的资源
浏览器重定向回应用程序
用户完成工作

可见，应用程序、身份提供者、用户共同构建了很好的体验：

身份提供者：将用户凭据安全地存储在一处。身份提供者提供丰富的用户上下文，包括经过验证的身份和组成员资格。
应用程序：接受此令牌，并可以根据用户的组成员资格或其他声明对用户做出授权决定，但Web服务不需要存储凭据或验证用户的电子邮件。
用户：如果已经登录到共享的SSO身份提供程序，他们可能会直接被重定向回网站，而无需再次登录。这是一种很棒的用户体验。

当我们审视SSO内部的这种机制时，我们看到了一个优雅的机制，即应用程序、身份提供者、用户三者一起工作，来创建这个优雅的解决方案。如果我们查看微服务的日志，我们可以看到用户的身份、组成员资格、请求URL、响应状态代码、请求持续时间、日期/时间、连接的细节（如源IP等）。

既然SSO已经解决了应用程序的问题，我们是否可以用SSO解决数据库的问题呢？

然而，数据并没有SSO(单点登录)

对于应用程序而言，单点登录 (SSO) 是应用程序的绝佳解决方案，可以获取请求和响应的细节、连接的细节、身份上下文。

那为什么我们不能对数据这么做呢？

图1-数据没有SSO（单点登录）

如上图所示：

面对Web应用程序：我们可以轻松地转发给身份提供者 (IdP)。借助云资源，我们可以使用OIDC或SAML进行身份验证。
面对本地和云中的数据资源：我们却一下子回到了石器时代，因为许多流行的数据库并不支持SAML/OIDC协议。尽管Snowflake或Redshift这样的现代数据库的确可以通过Okta或IAM支持原生SSO，但大多数业务用户使用BI工具（如Looker、Tableau、Thoughtspot等）通过单个服务帐户来访问数据，所以仍然看不清这些工具背后的真实用户。

简言之，应用程序有SSO，但数据没有SSO。

既然没有数据SSO，那就创造一个

让我们从应用程序的SSO解决方案中学习，并设计能够为数据提供身份上下文的日志记录解决方案。

我们先列举我们理想中的日志记录解决方案：

SSO用户名
SSO组
SQL查询
结果行数
客户端连接的细节
日期和时间

这正是我们想要的信息：SQL查询、响应的细节、日期和时间、连接的细节、用户身份。

这也正是我们通过启用SSO的应用程序所能获得的数据。我们得到经过身份验证的用户和组、请求URL、响应状态代码、返回的字节数、用户的源IP、查询的日期和时间。

如果我们的数据日志中有这些细节，我们就可以明确而自信地回答问题——谁访问了我们的数据？

那么，我们该如何获得数据存储的这种详细程度？让我们采用数据访问平台，或者称为数据安全平台（DSP）。

答案：具备数据SSO的数据访问平台

我们的方案是一个数据安全平台（DSP），它必须是一个身份联合访问控制系统，也必须能够将SSO带入数据网格。

由于数据访问需要区分应用程序访问场景和非应用程序访问场景，故需区分两种场景，分别进行应对。

1）应用程序场景的数据SSO

图2-传统方案 vs. 数据SSO方案

在上图中，左侧是DSP之前的场景；在右侧，我们添加了DSP来支持身份上下文日志记录。

在左侧（传统方案）：前端向SSO提供者进行身份验证，并检索包含所有 SSO 组和其他声明的 JWT（JSON Web Token）。应用程序可以在微服务之间传递此身份验证令牌，以验证用户的身份并做出授权决策。但是，一旦微服务接触到数据，它就会切换到共享服务帐户，于是身份上下文就丢失了。

在右侧（数据SSO方案）：增加了DSP（数据安全平台）来支持身份上下文日志记录。我们使用相同的SSO身份验证机制，检索相同的JWT，并通过微服务传递此身份验证令牌。然后，我们要做一些新颖的事情：我们还将这个身份验证令牌传递给DSP的Sidecar（边车）代理。DSP捕获查询请求和响应的细节，以及用户身份的细节。DSP将该查询操作，代理到数据存储，并将结果返回给应用程序。也就是说，通过使用DSP，我们可以通过数据层保留用户身份。

2）非应用程序型场景的数据SSO

注意到，许多数据访问场景并不经过应用程序：SRE、DBA和其他人可以直接连接到数据存储。所以，现在让我们来看看通过终端（terminal）或其他专用连接的数据访问。

图3-传统方案 vs. 数据SSO方案

在左侧（传统方案）：用户直接连接到数据库。他们很可能使用共享服务帐户，从而导致用户身份丢失。

在右侧（数据SSO方案）：用户通过DSP门户，登录到他们选择的SSO提供商。从那里，他们获得了一个令牌，用于向DSP的Sidecar验证他们的身份。所以，DSP可以捕获查询请求和响应的细节以及用户身份。然后，DSP将该查询操作，代理到数据存储。

3）结论：具有数据SSO的DSP

对于应用程序和非应用程序的数据访问，DSP都可以在数据访问过程中捕获用户身份。也正是在DSP日志中，我们找到了我们正在寻找的东西：用户身份！

借助DSP，我们可以使用各种身份联合访问控制，如Okta Azure Active Directory、G-Suite等；也可以连接到各种数据存储，如MariaDB、MongoDB、SQL Server等；还可以将日志发送到您选择的SIEM平台，如ELK、Splunk、DataDog等。

有了DSP的Sidecar代理，我们就可以使用标准SSO工具，向我们的数据库进行身份验证。应用程序用户和非应用程序用户（如SRE、DBA、部署工具）都可以通过SSO进行身份验证。DSP收集的日志包括查询请求、响应行数、所用时间、连接的细节（如客户端IP等），以及最重要的SSO用户和组。

谁访问了我们的数据？有了具备数据SSO能力的DSP，我们就能知道。

（本篇完）

本文的封面来自于下面这本书：

阅读原文

跳转微信打开

美国国防工业网络保护框架和启示

Sun, 21 Aug 2022 12:51:00 +0800

原创启承 & 柯学 2022-08-21 12:51 北京

大开眼界

全文约7000字阅读约10分钟

兰德公司基于对美国国防工业的研究考察，提出了关于国防工业网络安全保护的鲜明观点，比如：

安全预算比例：国防工业公司应该将其IT预算的22%用于网络安全；而对于易遭受网络攻击的公司，则应该进一步提高安全预算的比例。
从监管到服务：国防工业中小型公司无力承担应该投入的网络安全资源，所以国防部仅依靠纯监管方式，难以提升DIB公司的整体安全防护能力；管理层还应为中小企业提供免费/廉价的安全服务，而云服务是最具成本效益的选项。
统一保护计划：必须采取统一保护计划（而非各自为战），来提升DIB中小型公司的网络安全能力，该计划的核心是优惠政策和数据交换。

在其洞察结果的基础上，兰德公司进一步提出了国防工业基础网络保护计划（DCP2）框架。并通过严谨细致的分类方式（四个维度：大型公司 vs. 小型公司；本地网络部署 vs. 云网络部署；国防部安全运营中心 vs. 商业公司安全运营中心；高价值敏感信息 vs. 中等价值敏感信息）和五颜六色的部署拓扑，将其防护思想展示得淋漓尽致。

毫无疑问，兰德公司的洞察结论和保护框架，对我国国防军工企业的网络安全保护具有重要借鉴意义。兰德报告的下载地址见文末。

关键词：DIB（国防工业基础）；DCP2（国防工业基础网络保护计划）；CUI（受控非密信息）；CST（网络安全工具）；

目录

1.国防工业基础(DIB)的定义

1）什么是国防工业基础(DIB)

2）国防工业基础有多庞大

2.国防工业基础网络保护计划(DCP2)框架

1）框架选项和部署说明

2）国防工业基础(DIB)之安全部署现状

3）国防工业基础网络保护计划(DCP2)之安全部署场景

3.洞察和启示

1）易遭受网络攻击的公司，应该提高安全预算的比例

2）DIB公司应该将其IT预算的22%用于网络安全

3）DIB中小型公司无力承担应该投入的网络安全资源

4）国防部仅依靠纯监管方式，难以提升DIB公司的整体安全防护能力

5）当前国防部提出的网络安全成熟度模型认证(CMMC)程序仍有不足

6）必须采取统一保护计划，来提升DIB中小型公司的网络安全能力

7）国防工业基础网络保护计划(DCP2)的核心是优惠政策和数据交换

8）网络安全的管理层，需要提供安全服务功能

9）网络威胁共享服务，并非想象的那么容易

10）向云迁移是最具成本效益的选项

国防工业基础（DIB）的定义

1）什么是国防工业基础

国防工业基础（DIB）是一组提供国防工业能力的私营和公有公司（从小公司到大公司）。国防工业能力是“设计、开发、制造、维修、保障国防部产品及其必要子系统和组件所需的技能和知识、流程、设施、设备”。

国防工业基础（DIB）有两个组成部分：

国内制造业和国防工业基础；
全球制造业和国防工业基础。

图1-国防部的国防工业基础（DIB）的范畴

国内DIB包括来自小、中、大公司的产品和服务的生产者。进一步划分为私营机构和国有工业基础。私营机构拥有一些主要的系统集成商；国有工业基础包括政府所有、政府运营的实体和政府所有、承包商经营的实体。

全球制造基础由位于其他国家的企业组成，其中一些国家与美国有正式的关系，另一些则没有。

下图展示了本文所关注的DIB企业类型（如图中红色框所示）：

图2-本文的研究对象（由红色框标记）

图中红色框表示兰德报告的研究重点。在国内基础中，兰德报告的私营机构关注重点是为国防部进行研究的中小型技术行业公司。在兰德报告的研究中，国防工业基础（DIB）的小型公司是年收入在 1 亿美元以下的公司，中型公司是年收入在 1 亿美元到 5 亿美元之间的公司，而大型公司是年收入在 5 亿美元以上的公司。以下是 2018 财年的一些例子：

国防工业基础（DIB）小型公司：如MaXentric Technologies，美国国防部高级研究计划局（DARPA）承包商，雇员超过 50 人，年收入 500 万-1000万美元；
国防工业基础（DIB）中型公司：如佐治亚理工学院研究公司，来自国防部的收入约为 3.93 亿美元；微软公司，商业高科技公司，来自国防部的收入大约 4 亿美元；
国防工业基础（DIB）大型公司：如波音，飞机领域的主承包商，雇员 137000人，年收入 1010 亿美元，来自国防部的收入约 270 亿美元；洛克希德·马丁公司，飞机、电子、雷达、电子战领域的主承包商，雇员 105000 人，年收入 538 亿美元，来自国防部的收入约为 390 亿美元。

2）国防工业基础有多庞大

总体上看，拥有巨额收入的顶级防务公司在DIB中占主导地位，但在整个DIB公司的数量中只占很小比例。

兰德公司认为，DIB供应链的规模分布与美国整体经济中的企业规模分布没有显著差异。因此，可以使用美国联邦采办数据系统，来估计国防部承包商的数量和来自国防部的收入（国防部对公司的年度拨款）。如下图所示，估计DIB公司的总数大约为7.2万家。（美国国防部2022年的最新官方说法是大约22万家公司）

图3-国防工业基础（DIB）公司规模分布

国防工业基础网络保护计划（DCP2）框架

1）框架选项和部署说明

兰德报告为国防工业基础网络保护计划（DCP2）提供了多个框架选项。这些选项由几个关键因素定义：

第1因素：国防部的作用：直接、间接。分为两个选项：

选项A：国防部领导的DIB安全运营中心（SOC）；
选项B：商业公司主导的安全运营中心（SOC）；

第2因素：DIB公司的规模：大型、中型、小型；

DIB小型公司：年收入在1亿美元以下；
DIB中型公司：年收入在1亿到5亿美元之间；
DIB大型公司：年收入在5亿美元以上。

第3因素：DIB公司非密网络所在的位置：

本地网络部署；
云网络部署；

第4因素：DIB公司的受控非密信息（CUI）级别：

高价值（HV）；
中等价值（MV）。

网络部署图展示了国防工业基础网络保护计划（DCP2）中的每个工具或功能在不同规模的DIB公司网络上的部署情况：

大型公司；
具有云环境的大型公司；
小型公司；
具有云环境的小型公司。

兰德报告对网络安全工具集（CST）进行了分类，以便将其映射到建议的国防工业基础网络保护计划（DCP2）。

网络部署图的颜色说明：

红色：显示了DIB公司自购的网络安全工具集（CST）；
绿色：显示了国防工业基础网络保护计划（DCP2）提供的网络安全工具集（CST），如自动打补丁、电子邮件筛选、终端检测和响应（EDR）等。
黑色：表示威胁；
蓝色：表示网络资源。

所以，以下网络部署拓扑图中的绿色部分，都是国防工业基础网络保护计划（DCP2）的内容，值得特别关注。

2）国防工业基础（DIB）之安全部署现状

图4-国防工业基础（DIB）现状：大型公司 vs. 小型公司

通过该图明显可见，总体来看，大型公司通常使用更多、功能更强的网络安全工具集（CST）；而小型公司使用更少的功能更弱的工具，比如缺少SOC、自动补丁、威胁情报、邮件安全、数据过滤、网络访问控制、EDR等安全能力。

特别是，大多数DIB小型公司，通常缺少安全运营中心（SOC）和内部安全信息和事件管理（SIEM）能力，因此难以有效应对复杂网络攻击或高级持续性威胁（APT）的挑战。

3）国防工业基础网络保护计划（DCP2）之安全部署场景

3.1）大型DIB公司场景

图5-大型公司网络：现状 vs. 选项A

对于大型公司而言，由于大型公司通常已经自建了大部分的安全能力（见左图，以红色标记），故通过DCP2提供的安全能力（以绿色标记）并不多，主要是DLP、自动补丁、Web安全工具等（见右图，以绿色标记）。右图（选项A）中，还连接到国防部领导的DIB安全运营中心。

图6-大型公司网络：选项A vs. 选项B

上图显示了选项A和选项B的区别：

两者的安全控制几乎是完全相同的；
但选项A（左图）仅使用了国防部领导的DIB安全运营中心；
而选项B（右图）除了还增加了商业安全运营中心，并且将网络威胁情报、高级防火墙能力转交商业安全运营中心来提供。

图7-大型公司（选项A）：本地网络 vs. 云网络

上面左、右两图的安全能力几乎是相同的，其主要差异在于是否上云。而上云情况下主要是由云服务提供商（CSP）提供对DIB公司云中飞地（其中包含邮件、门户网站等）的安全防护。

3.2）小型DIB公司场景

图8-小型DIB公司的本地网络（选项A）：拥有高价值CUI vs. 中等价值CUI

如图所示，由红色标记的DIB公司自购的网络安全工具非常少，这是现状；而绿色标记的DCP2网络安全工具就非常多，极大补充了DIB小型公司的安全能力。这也正是国防工业基础网络保护计划（DCP2）的目的所在。

前面提到，大多数DIB小型公司，通常缺少安全运营中心（SOC）和内部SIEM能力。而通过参与国防工业基础网络保护计划（DCP2），DIB小型公司将可以由一个集中式的DIB安全运营中心（SOC）提供SIEM功能，从而具备了一些要求最高、劳动力最密集的网络安全功能：如威胁分析、数据关联、数据汇总、警报分类。

上面左、右两图的主要区别在于：在访问控制方面，右侧的中价值公司采用了常见的网络访问控制（MFA），而左侧的高价值公司则采用了密码安全MFA，提高了安全标准；此外，在数据安全方面，右侧的中价值公司采用了数据过滤程序，而左侧的高价值公司则采用了DLP（数据防泄漏），也提高了安全标准。

图9-小型DIB公司的云网络（选项A）：拥有高价值CUI vs. 中等价值CUI

该图的最大特色是，红色的自购安全控制全部消失，表明所有安全控制皆由DCP2计划提供（绿色标记）。

上面左、右两图的主要区别在于：右侧的中价值公司采用了数据过滤程序；而左侧的高价值公司则采用了DLP（数据防泄漏），提高了安全标准。

对于后面的各种场景图，请自行对比，不再赘述：

图10-小型DIB公司的本地网络（选项B）：拥有高价值CUI vs. 中等价值CUI

图11-小型DIB公司的云网络（选项B）：拥有高价值CUI vs. 中等价值CUI

图12-拥有高价值CUI的小型DIB公司的本地网络：选项A vs. 选项B

图13-拥有高价值CUI的小型DIB公司的云网络：选项A vs. 选项B

图14-拥有中等价值CUI的小型DIB公司的本地网络：选项A vs. 选项B

图15-拥有中等价值CUI的小型DIB公司的云网络：选项A vs. 选项B

洞察和启示

1）易遭受网络攻击的公司，应该提高安全预算的比例

兰德认为，一家公司的网络安全预算必须足够大，才能支付网络安全专业人员的工资和福利、网络安全工具集（CST）的软件许可费，以及应对网络安全事件可能需要的额外资金，如额外的工具或服务和来自外部专家或公司的建议。

兰德同时认为，不论国内外网安市场中安全预算的实际比例如何，当一家公司有较大概率遭受网络攻击时，就应该提高安全预算的比例。考虑到其业务和资产的价值，DIB公司当然属于这类公司，理所应当提高安全预算的比例。

这一结论启示我们，设置安全预算比例，不能只是参考市场平均数字，而要考虑实际面临的威胁和风险状况。如果确实面临较大网络攻击风险，则在某种程度上有必要“不计成本”地提高安全预算比例。

2）DIB公司应该将其IT预算的22%用于网络安全

兰德报告中指出，IBM建议有严重网络安全问题的公司将其IT预算的14%用于网络安全措施。Forrester数据显示，如果一家公司遭到黑客攻击，它将把IT 预算的30%或更多用于网络安全。

兰德测算结果表明，平均而言，一家DIB公司应该将其IT预算的22%用于网络安全，这是上述14%和30%建议的平均值。

兰德认为这个目标是可以接受的，因为已经假设有多达一半的DIB可能受到了网络攻击。

为了支撑该结论和观点，兰德进行了以下五项分析：

网络安全预算估算
国防工业基础公司信息技术预算估算
网络安全人员工资估算
国防工业基础公司小样本特征分析
国防工业基础中小型公司网络安全预算估算与建议的比较

3）DIB中小型公司无力承担应该投入的网络安全资源

网络安全是必要的，但也是昂贵的。一套网络安全工具需要专业人员才能使用，而所需的工具和熟练的专业人员对许多DIB公司来说可能负担不起。此外，管理环境复杂且难以驾驭，即使对于拥有强大网络安全团队的大型公司也是如此。

兰德分析表明：

对于DIB小型公司：要么无法拥有足够的网络安全专业人员，要么无法维护全套的网络安全工具集（CST），几乎不可能同时拥有网络安全专业人员和全套的网络安全工具集（CST）；
对于DIB中型公司：在承担网络安全工具和专业人员成本方面处于更有利的地位，但它们仍面临挑战。

更多的资金未必意味着更多的网络安全。要保护DIB公司的非密网络，除了花钱购买网络安全工具集（CST），还需要有效管理、网络安全最佳实践、员工培训。然而，如果公司没有足够的钱花在网络安全工具集（CST）和网络安全专业人员身上，这将严重阻碍他们的网络安全努力。

4）国防部仅依靠纯监管方式，难以提升DIB公司的整体安全防护能力

目前国防部防止DIB遭受网络攻击的方法，主要基于国防联邦采办条例补充规定（DFARS）800-7012和NIST SP 800-171，但这样做并不够。

兰德报告的成本分析显示，DIB的小型公司和一些中型公司没有足够资源，来遵守NIST SP 800-171的合规要求。

5）当前国防部提出的网络安全成熟度模型认证（CMMC）程序仍有不足

国防部推出的网络安全成熟度模型认证（CMMC），仍然是基于合规性的，并将增加DIB公司的成本。

兰德报告的成本分析表明，大多数DIB的小型公司可能无力负担网络安全成熟度模型认证（CMMC）的网络防御要求。许多中等规模的DIB公司可能面临同样的挑战，特别是如果要求它们达到网络安全成熟度模型认证（CMMC）的最高合规等级的话。

兰德报告建议的国防工业基础网络保护计划（DCP2），并非要取代网络安全成熟度模型认证（CMMC），而是为了完善这一认证，帮助改善DIB公司对NIST SP 800-171指南的合规性。

6）必须采取统一保护计划，来提升DIB中小型公司的网络安全能力

一方面，兰德报告称，如果遵循国防部目前的方法，可能无法保护DIB公司在非密网络上拥有的大量受控非密信息（CUI）不受外国对手的攻击。而来自非密网络的持续攻击和关键信息技术的损失，以及重大的经济损失，侵蚀了美国的国防工业基础（DIB），也威胁到美国的长期军事优势。

另一方面，对于DIB的小型公司来说，网络安全专业人员的成本将导致在聘请网络安全专业人员和购买额外的网络安全工具集（CST）上两者不可兼得。许多DIB的中型公司也不得不做出类似的决定。即便是当前国防部提出的网络安全成熟度模型认证（CMMC）程序，对许多中小型国防工业基础公司来说可能是负担不起的。

为了充分保护DIB公司的非密网络，需要替代的解决方案。这个替代方案就是国防工业基础网络保护计划（DCP2），其目的是推动国防部加强非密DIB网络的保护，用来抵御网络空间严重的安全威胁。

7）国防工业基础网络保护计划（DCP2）的核心是优惠政策和数据交换

为了系统性解决DIB公司非密网络网络安全防护面临的各种问题，兰德报告建议国防部，建立国防工业基础网络保护计划（DCP2），包括：

改善DIB的监控和实时健康状况；
为那些无力负担所需网络安全工具集（CST）和专业人员的公司，改善网络安全；
提供数据保护，防止从DIB公司到国防部的敏感企业信息、DIB上的敏感供应链信息、DIB的敏感数据，泄露给对手；
为DIB公司提供法律保护，如果DIB公司提供给政府的信息被非预期使用，最小化他们可能承担的责任。

国防工业基础网络保护计划（DCP2）的核心是优惠政策和数据交换：

一方面是优惠政策：DIB公司参加国防工业基础网络保护计划（DCP2）将是自愿的。参与该计划的DIB公司将同意安装和使用国防部提供的网络安全工具集（CST）。关键在于，这些网络安全工具集（CST）将免费提供，或者以大幅降低的许可价格提供。

另一方面是数据交换：DIB公司将同意向新的DIB安全运营中心（SOC）或专门为DIB服务的商业安全运营中心（SOC），提供网络安全工具集（CST）产生的经过清洗的数据，以改善DIB的实时监控和健康状况。这些数据包括网络元数据、应用程序元数据、匿名用户帐户元数据、安全警报和匿名系统日志文件。这些经过清洗的数据不包括DIB公司员工的个人身份信息（PII）、公司专有信息、员工通信，或者任何受控非密信息（CUI）。国防部将免费提供数据清洗程序，确保只将相关的网络安全数据传输到DIB安全运营中心（SOC）或商业安全运营中心（SOC）。

管理国防工业基础网络保护计划（DCP2）的成本很重要。只有拥有重要受控非密信息（CUI）并向国防部提供关键国防技术的DIB公司，才有资格获得该计划的全部好处。那些主要为国防项目提供大宗商品相关产品的小公司，可能不符合条件。

8）网络安全的管理层，需要提供安全服务功能

兰德报告认识到国防工业基础网络保护计划（DCP2）会给政府带来新的巨大成本，也预料到一些反对者可能会争论说，这笔成本应该由私营行业承担，因为他们将在许多方面从国防部提供的网络安全工具集（CST）中受益。

然而，兰德报告认为保护DIB归根结底是美国政府的责任。DIB公司正受到有能力的民族国家的网络攻击，对手使用的大量资源在许多情况下都远远超过DIB公司的可用资源。2019年，美国国家安全局（NSA）局长呼吁公共和私营行业团结起来共同应对网络安全威胁：“指望私营行业能够真正经受住整个国家的集中攻击（而这些国家还正在以一种非常同步的战略路线努力尝试获得优势），我认为这是不现实的。”

就像在其他领域（如司法领域），私营公司应该受到执法机构的保护，使其免受犯罪行为的侵害（例如，由当地警察部门或联邦调查局保护）。DIB公司也有权获得美国政府的某种形式的网络安全保护，尽管这种保护需要公共和私营实体之间的合作才能取得成功。

国防工业基础网络保护计划（DCP2）的思路，反映了使管理层从单纯监管视角转向帮扶弱者的观点，值得我们深深的思索。这也许是国防工业基础网络保护计划（DCP2）能够落地的关键思想。

当然，精打细算是美国的传统。兰德报告建议研究网络安全工具（CST）许可成本和模型，其中包括规模经济和价格选项。因为向每个DIB公司提供网络安全工具集（CST）并不是一个合理的经济建议，必须建立门槛和限制，以确定国防部支付的网络安全工具集（CST）数量，并探索不同的网络安全工具集（CST）的补贴模式。

9）网络威胁共享服务，并非想象的那么容易

兰德报告指出，当前自愿性的国防部网络威胁共享服务，对许多国防工业基础公司是不可用的。因为不是所有的DIB公司都能使用这项服务。为了使用这个网站，DIB公司用户必须使用国防部通用访问卡（CAC）进行登陆。而一些防务承包商可能没有任何员工拥有这些证件。

兰德报告提出的解决方案是，通过实施国防工业基础网络保护计划（DCP2）：

一方面，通过DIB安全运营中心或商业安全运营中心，向DIB公司提供动态情报、安全警报、行动建议，以识别和应对高级持续性威胁（APT）入侵；
另一方面，它使实时威胁情报能够以目前不可能的方式，在DIB中进行收集和综合。

DIB安全运营中心或商业安全运营中心，使用这些数据和其他数据来生成警报，并把这些警报发送回DIB公司，以保护和改善对其网络的监控，免受外部和内部威胁。

毫无疑问，这种设想为国内网安行业的威胁情报共享，提供了很好的落地思路。

10）向云迁移是最具成本效益的选项

实施国防工业基础网络保护计划（DCP2）的最具成本效益的选项可能是基于云计算功能。国防工业基础网络保护计划（DCP2）中有一个重要选项，是将国防工业基础非密网络迁移到国防工业基础（DIB）云，DIB公司可以使用这个云实现非密数据的计算和存储。

如果实现了DIB云，DIB公司将获得的不仅仅是网络安全，还将免费获得计算和存储资源。DIB公司拥有的受控非密信息（CUI）将不再存储在本地，它将只在DIB云中存储和处理。

云服务提供商（CSP）将为国防工业基础网络保护计划（DCP2）在商业云中划出一个安全飞地，并提供一组标准化的计算系统资源（CSR）。国防工业基础网络保护计划（DCP2）将提供DIB云虚拟机和容器仓库，供DIB公司使用。云服务提供商（CSP）将负责修补和更新DIB成员公司使用的云基础设施。国防部还将建立和维护DIB云的元数据服务。

参与国防工业基础网络保护计划（DCP2）的DIB公司，将在自己的安全飞地内得到一套标准化的安全计算系统资源（CSR）。不同公司的安全飞地相互隔离，并建立硬安全边界，以防止受控非密信息（CUI）和专有信息未经授权流动。而在DIB公司本地部署的网络由瘦客户端或胖客户端机器组成，它们被配置为防止公司数据的本地存储，不会将任何受控非密信息（CUI）存储在本地网络中。

（本篇完）

参考文献：兰德公司报告《非密安全：针对非密网络的国防工业基础网络保护计划》（Unclassified and Secure - A Defense Industrial Base Cyber Protection Program for Unclassified Defense Networks）的150页英文版原文下载地址：

https://www.rand.org/pubs/research_reports/RR4227.html

阅读原文

跳转微信打开

云隔离的梦想

Sun, 14 Aug 2022 06:36:00 +0800

原创柯学 & 徐珊 2022-08-14 06:36 北京

我有一个梦想

全文约4000字 10图表阅读约5分钟

美国国防部把隔离技术用到了极致：1）在涉密网和非密网之间使用网闸隔离；2）在非密网和互联网之间使用互联网隔离；3）在上云过程中使用云隔离；4）在数据中心使用微隔离。

总体来看，云是未来，浏览器是工作入口，所以云和浏览器隔离的结合，也就是云隔离，可以实现隔离技术的普惠化，才可以把隔离的梦想带到现实。

在安全领域，你可能不得不关注四大安全平台：1）网络安全领域中的SSE（安全服务边缘）平台；2）数据安全领域中的DSP（数据安全平台）；3）应用安全领域中的CNAPP（云原生应用保护平台）；4）事件响应领域的XDR（扩展检测与响应）。

其中，SSE（安全服务边缘）本质就是零信任云访问平台。Gartner将SSE作为四大安全平台之首，是有原因的。而每个SSE头部厂商都将云隔离作为必备功能项，也是有原因的。本文将为你揭秘。

聪明的读者会发现：本文与其说是云隔离的梦想，不如说是云访问的梦想，也就是零信任云访问平台（SSE）的梦想，终究也是企业安全云的梦想。

本文来自2022年8月2日在ISC 2022大会上的演讲《云隔离的梦想》，总共只有10张片子。视频见文末。

目录

1.安全隔离的梦想

2.何为云隔离平台

3.云隔离平台为何重要

4.美国国防部大力推进RBI项目

5.DISA技术路线图

6.成熟度曲线反映RBI日趋成熟

7.SSE前十厂商全部整合RBI能力

8.SSE的能力构成

9.RBI在正反两个方向同时工作，增强边缘安全方案

10.RBI与浏览器相得益彰

安全隔离的梦想

想必大家听说过美国黑人运动领袖马丁·路德·金发表的著名演讲——《I have a dream》（我有一个梦想），呼吁了种族平等。

在安全行业里，也有一个梦想，是关于安全隔离的梦想——即把好的东西放进来，把坏的东西隔离在外。

隔离的强度。值得提醒的是，隔离（Isolation）其实是一种非常强的安全控制措施，通常用于密级不同的网络之间，比如高密级和低密级之间。所以隔离经常会成为军方或涉密部门的强需求。

谁是真隔离。真正敢称为“隔离”的产品和技术并不多。

有时候说的“隔离”，只是“分段”。隔离是Isolation；分段是Segment。比如说，微隔离=微分段（microsegment）。以前的网络安全域划分就是典型的“网络分段”，它是粗粒度的分段。在零信任的思想下，又产生了身份分段、应用分段、数据分段，这些算是细粒度的分段。但是，它们都不是隔离。
最为人所熟知的隔离技术，是物理隔离。比如网闸、光闸这类安全设备。
而虚拟化隔离呢？就要看他的操作系统底层，是否有足够强的隔离机制。
那么，浏览器隔离呢？英文用的就是Isolation，所以它也算隔离。尽管浏览器隔离的强度不如物理隔离，但是浏览器隔离的使用场景比物理隔离广泛得多。这主要是因为浏览器已经成为工作入口。而且它还是很大的风口：比如，今年的RSA创新沙盒大赛冠军，就是Talon企业安全浏览器；而另一家成立不到两年的企业安全浏览器公司Island，估值竟高达13亿美元。实际上，经过全方位的对比，360企业安全浏览器是优于这两款国外企业安全浏览器了。
这次的主题是云隔离：云隔离就是基于云的浏览器隔离。

照亮隔离梦想。正因为云是未来，浏览器是工作入口，所以云和浏览器隔离的结合，也就是云隔离，就可以实现隔离技术的普惠化，也可以把隔离的梦想带到现实。

何为云隔离平台

我们先解释云隔离是什么？然后再说明它为何重要。

云隔离=云浏览器隔离=基于云的远程浏览器隔离。

云隔离的基本思想：

在用户浏览器和互联网网站之间，插入云端浏览器；
用户浏览器想要访问的内容，由云端浏览器转发过来；
用户浏览器本会遭受的威胁，都由云端浏览器来屏蔽掉。

这里的关键是：怎么转发内容，怎么屏蔽威胁。也就是图中的第4步。这里存在三种技术路线：

像素推送：云浏览器直接将网页展示的像素图像，传输给用户浏览器。这是非常安全的。
DOM重建：云浏览器通过重建网页的HTML和CSS等内容，来清除已知漏洞和潜在的恶意内容。
智能渲染：云浏览器向用户浏览器传输的内容是渲染指令，而非网页资源。

这三种技术路线各有利弊，综合运用时，可以适用于不同安全等级的场景，从而发挥最佳效果。

云隔离平台为何重要

这里做了一个梳理，反映云隔离平台为何值得关注：

美国国防部当前正在大力推进RBI项目。计划推广到它的几百万终端上。
通过Gartner的成熟度曲线，来反映RBI技术日趋成熟。
SSE（安全访问边缘）排名前十的国际供应商，全部整合了RBI能力。SSE是安全访问边缘，也就是零信任访问平台。
RBI大大增强边缘安全解决方案。第3条只是一个外在现象，第4条却是内在本质。

下面，分别解释下这几个方面。

美国国防部大力推进RBI项目

美国国防部的RBI项目名称是CBII（基于云的互联网隔离），本质就是基于云的远程浏览器隔离。

美国国防部采用RBI的一个非常重要的原因，就是他们发现，针对美国国防部网络的攻击中，大约有30%到70%来自浏览器。所以，浏览器成为最大的攻击暴露面。而RBI技术就可以解决此问题。

DISA开展RBI项目的大概过程是这样的：

2018年6月，DISA（国防信息系统局）发布RBI方案需求；
2020年8月，DISA以1.99亿美元，签订RBI项目合同。Menlo Security公司负责CBII项目解决方案的交付工作。
2020年底，DISA（国防信息系统局）发布《2019-2022财年战略计划》2.0版本。将RBI纳入未来两年的战略计划。
2021年初，CBII技术已经完成测试验证，处于国防部内部推广部署的阶段。DISA原计划在2021财年将其扩展到整个国防部，并将其应用于电子邮件和附件。
2021-2022年期间，DISA计划大力推进RBI项目的部署实施，将其扩展到整个国防部，将RBI用户数量从最初的10万，最终扩展至350万。DoD总共有多少人呢？不过两三百万（美军现役加文职大概200万）

接下来，再看看DISA战略计划中的RBI内容。

DISA技术路线图

在DISA的《2021-2022财年战略计划》图中，我们用以红色字体标记了RBI项目。其中，这个技术路线图中，有三大领域：网络防御、云计算、企业办公。而RBI项目，则同时出现在网络防御和云计算这两个领域中。我们分别来看看：

在网络防御领域，DoD有三层纵深防御：边界防御+区域防御+终端防御；而云隔离属于边界防御的范畴。我来解释一下：美国国防部有涉密网和非密网两类网络，会产生两种连接需求：

一是涉密网和非密网的连接，采取类似物理隔离（也就是网闸、光闸）的方法来解决；
二是非密网和互联网的连接，以前主要使用老三样（也就是防火墙、防病毒、入侵检测），当然还有安全大脑的分析。但它现在有了RBI以后，就可以极大减少面向互联网的暴露面。

在云计算领域有3项关键工作（右下角浅蓝色框）：一是云基础设施（云连接）；二是云访问和安全（云访问）；三是基于云的互联网隔离（CBII）（云隔离）。正是通过这三个大招（云连接、云访问、云隔离），DoD搞定了安全上云问题。

现在，我来总结一下：1）DoD在涉密网和非密网之间使用网闸隔离；2）在非密网和互联网之间使用RBI，被称为“互联网隔离”；3）在国防部的云中，也使用了RBI，被称为“云隔离”；4）在数据中心中，则使用零信任的微隔离。

所以，我才认为，美国国防部把隔离技术用到了极致，也几乎实现了隔离梦想的普惠化。

成熟度曲线反映RBI日趋成熟

Gartner是顶级的咨询机构，其成熟度曲线非常著名。但其实它来自心理学领域著名的达克效应，反映了人类认知事物的过程，主要包括3段：愚昧之山+绝望之谷+开悟之坡：

人们总是先兴冲冲地登上愚昧之山（就像说风口来了、风口来了，跟着炒概念）；
然后发现现实没有想象的那么美好，于是跌下神坛，掉入绝望之谷；
历经过度的希望和过度的失望之后，终于产生了稳定的期望。于是踏上了开悟之坡。

2017年，浏览器隔离（BI）技术被纳入Gartner 11大顶级安全技术。2018年进入Gartner端点安全和网络安全这两条成熟度曲线。我们对比了近5年的成熟度曲线，发现BI/RBI依次经过上升期、山顶期、低谷期，已经逐步趋于成熟。

SSE前十厂商全部整合RBI能力

正是因为RBI在技术上基本成熟，所以相关的国外供应商，开始加速整合RBI能力。在Gartner于2022年2月发布的《安全服务边缘（SSE）魔力象限》，象限中的所有提供商，看起来是11个，但因为有收购关系，正好是10个。我逐个排查了一遍，发现他们全部都整合了RBI能力，当然有各种整合方式，有自研、有收购、有集成、有合作等。

当然了，这只是一个表象和结果。我们会问，原因是什么？只是因为RBI技术成熟了吗？非也。下面进行解读。

SSE（安全服务边缘）的能力构成

四大安全平台。在安全领域，你可能不得不关注四大平台：

SSE（安全服务边缘）：边缘零信任访问平台。
DSP（数据安全平台）：统合数据安全控制，逐步淘汰孤立的数据安全工具。
CNAPP（云原生应用保护平台）：涵盖云原生应用程序的整个生命周期（从开发到生产的闭环）。
XDR（扩展检测与响应）：面向威胁检测与响应，降低安全运营复杂性。

Gartner把SSE列为四大平台之首，可见对SSE的重视。

SASE背景。我们知道，自Forrester提出来的零信任架构大火之后，Gartner也不甘示弱，在2019年提出SASE（安全访问服务边缘）架构。SASE架构的愿望非常好，融合了网络+安全两个方面，形成一体化安全架构。然而，理想很丰满，现实很骨感。当前大多数大型组织，都有独立的网络团队和安全团队，他们通常做出互相独立的采购决策，难以有效整合网络和安全这两个方面的工作。

SSE概念。于是，Gartner于2021年又提出SSE新概念，SSE由SASE缩减而来，SSE是从SASE中解耦出来的纯安全部分，更加容易落地。本质就是想把安全与网络解耦。所以，这是一个很有意思的现象：SASE用来融合网络和安全；而SSE则用来解耦网络和安全。当然，从某种程度上看，这是对现实的妥协，也算是对企业客户的尊重。

在甩掉网络的包袱后，Gartner对SSE寄予厚望。除了把SSE列为四大平台之首，还把SSE纳入Gartner的4条成熟度曲线：云安全、端点安全、网络安全、应用安全。你觉得4条不够多是吧？Gartner的成熟度曲线的确很多，但是跟咱们安全密切相关的成熟度曲线，总共也就7条（还有身份与访问管理（IAM）、数据安全、安全运营）。

为什么SSE架构要集成RBI能力？如上图所示：

SSE是以零信任为基础的，这是底层能力；
SSE对外体现为3大网关能力，也是3大支柱能力：SWG（安全Web网关）、CASB（云访问安全代理）、ZTNA（零信任网络访问，即SDP）。
而在中间层的安全服务能力中，RBI为什么能占有一席之地？因为它能够同时补充和增强这3大网关能力。下面来解释为什么这么说？

RBI在正反两个方向同时工作，增强边缘安全方案

在这里，我们看到了前面SSE平台的三种网关：

SWG（安全Web网关）：保护用户终端，免受互联网Web攻击。
SDP（零信任网关）：保护云中私有应用，免遭网络攻击。
CASB（云访问安全代理）：保护SaaS应用，免遭数据泄露。

而RBI有正反两种工作方式，大家比较熟悉的是正向方式。

RBI在正向工作时：

可以保护用户终端，免受互联网Web攻击。
而这种场景正是SWG（安全Web网关）的核心价值。
差异性：SWG仅针对已知威胁，例如白名单网站或者黑名单网站；而RBI则可以应对未知风险网站。两者组合才能高效防护。

RBI在反向工作时：

可以保护企业敏感数据和应用，免遭数据泄露。注意：它不是防止终端上的数据泄露，而是防止云中企业数据的泄露。
而这种场景正是零信任SDP网关（保护私有应用）和CASB（云访问安全代理，保护SaaS应用）的核心价值。
差异性：有了RBI之后，应用程序（私有应用或SaaS应用）返回的数据，不会直接传给用户终端，而是传给云隔离平台。也就是说数据可以不落地，用户终端拿不走敏感数据（包含文件、邮件等）。

所以，综合上述正反两种工作方式，RBI可以极大地补充和增强SSE的三大支柱能力。这才是RBI真正的价值所在。

RBI与浏览器相得益彰

最后，再强调下：RBI与浏览器是相辅相成、相得益彰的：

一方面，RBI保护了客户浏览器，避免了客户浏览器的失陷；
另一方面，RBI中云端浏览器毕竟也是浏览器。只有对浏览器技术的深入理解，才能造就出强大的RBI产品。

所以，360企业安全浏览器与360云隔离平台的结合，是一种强强联合。可以为云隔离梦想的实现，贡献力量。

（本篇完）

阅读原文

跳转微信打开

美国国防部的百亿大单和上云启示

Sun, 07 Aug 2022 06:53:00 +0800

原创一帆 & 柯学 2022-08-07 06:53 北京

金山银山，皆在云中

全文约4000字阅读约5分钟

美国国防部有两个百亿美元云计算合同——国防飞地服务（DES）和联合作战云能力（JWCC）计划：

DES参考：《美国国防部IT改革的“皇冠宝石”：DES（国防飞地服务）》
JWCC参考：《绝地云上的绝地反击》

本文意在更新这两个大单的进展：

国防飞地服务（DES）项目合同已授予Leidos公司；
联合作战云能力（JWCC）项目合同授予将推迟到2022年12月。

本文还将通过一名技术顾问在Dragon Cloud（龙云）推进过程中的心路历程，来体会美军如何突破上云的阻碍：

最艰难的因素是推动一种更具风险承受能力的云文化；
通常是高层领导在早期犹豫不决；
通过技术演示打开高层领导的想象空间；
从非密云资源扩展到涉密云资源。

面对许多不敢联网、不敢上云的行业和领导，这4个洞察或许戳中了痛点！

关键词：DES（国防飞地服务，Defence Enclave Services）；JWCC（联合作战云能力，Joint Warfighting Cloud Capability）；JEDI（绝地/联合企业防御基础设施，Joint Enterprise Defense Infrastructure）；JADC2（联合全域指挥与控制，Joint All-Domain Command and Control）；GAO（政府问责局，Government Accountability Office）；

目录

1.美军上云的启示

2.DES合同被授予Leidos

3.JWCC合同被延迟授予

4.美军的其它云项目

美军上云的启示

图1-国防部企业云战略

不论IT还是安全，美国国防部都在尽可能地对可以通用化的产品和服务进行标准化，以避免各行其是的定制化。归根结底是两字诀：一是“快”（快速应用和创新），二是“省”（省钱）。

比如两个百亿美元云计算合同，即联合作战云能力（JWCC）和国防飞地服务（DES）计划，都是通用化和标准化的上云项目。

但这并不意味着美国人天生就容易接受新理念、新技术。实际上，美军在其上云之路上也是经历了百转千回。

美军第十八空降兵团第101空降师高级技术顾问布赖恩·麦克唐纳 (Brian McDonell)就对此深有感触。通过他讲述的故事，我们也可以感受到美军上云的心路历程。

1）推动风险承受度。McDonell参与了应急部队的Dragon Cloud（龙云）（参见后文）的建设，他表示，上云推进工作中最艰难的因素之一是推动一种更具风险承受能力的文化，以便进行更深入的实验。

2）高层领导是障碍。他说：“我们提前把云环境全部建成，还进行了为期一个月的现场演练，准备出去使用所有这些云的东西。这时，有一群指挥官说“我不想使用它”，因为他们很害怕。没有人相信它，这是有史以来第一次。”高层领导在早期的犹豫不决，是非常普遍的现象。

3）说服和技术演示。McDonell表示，要想获得相关领导的支持，最致命的一击就是在说服他们值得冒险之后，通过技术演示向他们展示好处。

4）尝试非密云资源。McDonell说：“我在布拉格堡（Fort Bragg）遇到一位三星级将军，他的陆军配发电脑是他的非密电脑。我给了他一个URL，他点击了我从肯塔基州坎贝尔堡（Fort Campbell, Kentucky）部署、配置、维护的云资源——他立刻就被震撼到了。而这正是最欣喜若狂的事。之后，我们开始探索其他机会。我们开始尝试与欧洲的部队建立联系，而所有的云尝试都开始迅速蔓延。”

5）拓展涉密云资源。正是从那里开始，官员们选择进一步扩展云功能，以托管与任务指挥系统相关的敏感和涉密工作负载，并使它们能够在全球可访问的云环境中运行。“所以我将我在坎贝尔堡的目标系统，连接到并共享复制到德国本地目标系统的数据。它是实时的，没有延迟。太棒了！”McDonell说。“而且我们今天仍在这样做。我们现在仍在添加各种服务，以构建这种云环境。”

6）以云改进SWaP指标。McDonell补充说，服务需要到达一个士兵可以停止背负网络的地方。而基于云的应用程序，就有助于减轻所有硬件繁重的负担。“SWaP（大小、重量、功率）是我们通常用来评估选项可行性的一个指标。我们一直在努力减少大小、重量并提高功率，以使我们更加敏捷、更具杀伤力和战斗力。通过在这种混合环境中使用云——我说混合是因为我们总是会为那个战士在战术边缘配备某种硬件——但是在将其他所有东西都托管在云中时，我们可以提升SWaP中60%的改进。”他说。

随着这项工作的继续展开，相关人员正在认真考虑确保云环境可以在全球范围内使用，并最终对整个陆军和国防部产生持久影响。

DES被授予Leidos

DES的详细情况请参考《美国国防部IT改革的“皇冠宝石”：DES（国防飞地服务）》。

DES（国防飞地服务）是美国国防部推动数字化转型的重要举措，被誉为国防部IT改革的皇冠上的宝石之一。其核心工作内容是通用IT的整合和安全性的提升。

作为庞大的云计算合同，DES的目的是改变国防部“第四产业”（Fourth Estate）的IT运营状况（含安全运营），旨在通过企业电子邮件、语音、视频、协作和更好的网络安全性，来解决第四产业IT生态系统效率低下的问题。所谓“第四产业”，主要是指国防部内除了军种和情报机构之外的国防机构和外勤机构（DAFA）。

2019年，国防部副部长指定DISA作为单一服务提供商，以优化其22个第四产业机构的网络能力。

2022年3月10日，DISA在其官网宣布：将DES（国防飞地服务）合同授予弗吉尼亚州雷斯顿的Leidos公司。

DES合同的最高价值为115亿美元。这是一份单一授予的无限期交付/无限量合同，有1个为期4年的基本履约期，随后是3个为期2年的选择期。合同期自2022年2月28日开始。招标还要求所有要约人将至少25%的工作分包给小企业。Leidos的提案超过了这个最低限度。

DES合同涉及为超过37万名用户提供广泛的IT服务，这些用户跨越22个国防机构和在美国和国外拥有500多个站点的外勤机构。

作为DES承包商，在DISA的第四产业网络优化计划办公室的指导下，Leidos将管理和运营网络架构，并提供必要的技术专业知识，以提供标准化、响应迅速、具有成本效益的IT服务，专注于任务价值和网络用户体验，同时提高第四产业机构的安全性、网络可用性、可靠性。

图2-DES的工作内容

Leidos公司简介。Leidos（纽约证券交易所代码：LDOS）是财富500强中技术、工程、科学解决方案和服务的领导者，致力于解决国防、情报、民用、卫生市场中世界上最严峻的挑战。Leidos 的4.3万名员工为政府和商业客户的重要任务提供支持。Leidos总部位于美国弗吉尼亚州雷斯顿，截至2021年12月31日的财政年度的年收入约为137亿美元。

Leidos中标之波折。2022年2月28日，Leidos就在其官网上宣布获得了DISA授予的国防飞地服务 (DES) 合同。称其为该公司历史上金额最大的合同。然而，3月10日，GDIT (通用动力信息技术) 向政府问责局(GAO) 提出了投标抗议，导致政府问责局对此项投标进行审查。直到6月22日，Leidos再次在其官网上宣布：DES合同经由政府问责局彻底的审查之后，得到确认和维持。

然而，在后文的空军Cloud One项目中，Leidos就比较悲剧了。Leidos在2016年中标了Cloud One项目，却在2020年被解雇！

Leidos官网上的几个其它军方大单：

海军海上系统司令部后续合同：2022年7月，获得了一份后续合同，以支持海军项目执行办公室综合作战系统指挥部。单项授予的成本加固定费用合同价值约为2.91亿美元。它包括一年的基本期和四个额外的一年选择期。工作将在全球范围内进行。
北约弹道导弹防御合同：2022年5月，获得北约通信和信息局（NCI Agency）授予的两项国际竞争合同，以增强联盟的弹道能力导弹防御（BMD）能力。两份单一授予的固定价格合同的总估计价值为9000万美元，每份合同的履约基期为四年，最多可有四个选择期。
美国海军海底战争系统合同：2022年3月，获得美国海军海军信息战系统司令部 (NAVWAR) 授予的主要合同，以支持该军种的海底战系统。这个单一奖项的下一代海港 (NxG) 任务订单的总估计价值为8400万美元。它包括一年的基期，以及四个一年的选择期。工作将在弗吉尼亚州和日本进行。

JWCC合同被延迟授予 

JWCC的详细情况请参考《绝地云上的绝地反击》。

JWCC项目旨在打造一项多云工作，将为国防部提供所有三个安全级别的企业云能力：非涉密、机密、绝密，从美国大陆一直到战术边缘。JWCC将为JADC2（联合全域指挥和控制）计划提供服务，并协助人工智能应用等。 

2021年7月，国防部官员预计采购合同将在2022年4月准备就绪。当时预计只有两家云服务提供商有资格竞标采购。 但是国防部在进行市场调查后，于2021年11月，将五家公司纳入考虑，最终四家收到了招标，即谷歌、甲骨文、微软、AWS。云服务提供商的数量从两家增加到四家，极大地复杂了评估周期。

于是，2022年3月31日，国防部网站发布消息称，国防部首席信息官John Sherman（约翰·谢尔曼）表示，计划在2022年12月授予JWCC（联合作战云能力）采购合同，以便有更多时间来评估供应商的提案。

谢尔曼表示，更改为12月授予合同，并不表明采购有任何问题。相反，它确保了政府有足够的时间来做美国纳税人应得的尽职调查。“这正是四个提案所需的评估工作量，……我们只是一开始低估了所需花费的时间。” 

在宣布将合同授予从4月推迟到12月时，国防部官员对战略和方法充满信心，并且12月的时间表不会再次推迟。

该项目计划是1个为期3年的基础合同，外加2个1年的选择期。五年合同上限为90亿美元。在这个可能的五年采购结束时，国防部将发起“一场全面而公开的未来多云采购竞赛”。华盛顿总部服务处（Washington Headquarters Services）在DISA（国防信息系统局）的协助下领导采购工作。 

JWCC可能与四家供应商签订四份单独的合同，并且根据任务所有者的要求，它们之间将在任务订单级别进行竞争。

JWCC被设想为作战司令部和第四产业机构的企业级能力。虽然国防部并没有强制要求每个人都迁移到JWCC——尤其是军种（所有军种都在同时开展云计算工作）——但希望随着JWCC得到证实，更多的军种将过渡到它。

JWCC一旦授予后，官员们相信将获得非密能力。授予后大约60天，将可以使用涉密服务。不迟于授予后180天，将可以使用绝密和战术边缘服务。

美军的其它云项目 

1）空军Cloud One项目

Cloud One是空军内部基于云的“通用开发、测试、生产计算环境”计划，允许团队和其他分支机构快速获取Microsoft Azure和 AWS云服务。

自2016年以来，Leidos（正是上面中标DES合同的那家公司）一直持有Cloud One合同，前身为空军云计算环境（Air Force Cloud Computing Environment），并由相关分包商提供支持。在此期间，空军将30多个应用程序迁移到商业云环境中。

但是，2020年1月，空军决定解雇Leidos，因为其提议的分包商之一存在组织利益冲突。这导致SAIC与空军签订为期五年、价值7.27亿美元的Cloud One云计算合同。也就是说，SAIC将接手这项工作，继续为空军和其他军种整合向商业云的迁移。根据合同，将把大约800个空军和陆军应用程序迁移到云端。

在此期间，Leidos提出了抗议。而政府问责局（GAO）最终驳回了该项抗议。

空军首席信息官Lauren Knausenberger在接受采访时：“我们不会等待JWCC。”

虽然国防部希望在今年12月授予JWCC企业云合同，但空军仍计划继续构建其Cloud One平台作为其首选的云环境。

Knausenberger希望JWCC能够“很快”授予并取得成功，并表示它“至少可以为我们提供更好的计算定价”。“如果是这样，我们仍将使用Cloud One作为前门，我们将通过JWCC购买该计算。”

“如果它可以解决全球数据主权问题，我可以利用世界上任何地方的任何数据中心，……你知道，数据在美国以外的地方会出现问题吗？”

数据在美国以外的地方会出现问题吗？Knausenberger非常期待，能够通过JWCC解决全球数据主权问题，解决不同密级之间传输数据的问题。因为现在的过程需要“许多、许多、许多、许多层次的批准”。这些都是希望JWCC能改变的事情。

2）应急部队的Dragon Cloud（龙云）项目

着眼于实现以数据为中心的战争，“美国的应急部队”正在云中运行不同于陆军以前运行过的任何工作负载。在过去几年中，第十八空降兵团（XVIII Airborne Corps）构建了Dragon Cloud。

当自然灾害或人为危机发生，美国需要快速反应部队介入时，第十八空降兵团准备在世界任何地方部署。该部队由大约9.2万名士兵组成。

龙云是战术云。该军团与AWS公司合作，推出了他们认为是常规陆军第一个持久的战术云——Dragon Cloud（龙云）。

非密云资源。龙云首先开发了影响级别5 (IL5) 的概念验证 (POC) 云环境，可托管符合政府法规的非密数据和工作负载。

涉密云资源。在该POC成功的基础上，龙云随后继续开发和改进一个可操作的云环境，可以处理影响级别6 (IL6) 的涉密数据和工作负载。

企业云vs.战术云。随着国防部准备授予JWCC合同并最终为企业云服务铺平道路，龙云将标志为军方内部多个孤立的云驱动项目之一。

（本篇完）

阅读原文

跳转微信打开

致美国总统的零信任报告

Sat, 23 Jul 2022 14:03:00 +0800

原创柯学 & 启承 2022-07-23 14:03 北京

焦虑使人进步

全文字不多阅读5分钟

2022年2月23日，总统国家安全电信咨询委员会（NSTAC）投票通过了一份致拜登总统的零信任报告《零信任和可信身份管理》。CISA（网络安全和基础设施安全局）在其官网上发布了该报告。

在此前1个月（2022年1月26日），拜登政府发布了《联邦政府零信任战略》，对政府机构在两年半内实施零信任做出计划要求。

NSTAC报告总体上做了两方面工作：

一是给出了零信任实施模型。即先通过DAAS（数据、应用程序、资产、服务）来定义保护面，然后采用五步流程法实施零信任。其中，使用Kipling方法编写零信任策略，使用成熟度模型来度量零信任进展。

二是提出了零信任实施的长期建议。为什么是“长期”？因为NSTAC认为：联邦政府零信任战略虽然名为“战略”，但只是关注了两年半的短期行为。而对于未来十年的考量，却存在疏忽。而NSTAC报告正是为了填补这一长远考量的空白。

人有近忧又有远虑。笔者从联邦政府零信任战略和这份NSTAC报告中，看到了深深的焦虑：如果说，联邦政府零信任战略解决了两年半内的短期焦虑——给出了任务矩阵；那么，NSTAC报告旨在解决两三年后的长期焦虑——提出了24条建议和9条关键建议。

注：NSTAC报告的PDF文档有56页，译文大概3.5万字。报告原文下载地址，参见本文图1下方。

关键词：NSTAC（总统国家安全电信咨询委员会）；DAAS（数据、应用程序、资产、服务）；Kipling方法；OMB（管理和预算办公室）；CISA（网络安全和基础设施安全局）；FISMA（联邦信息安全管理法案）；NIST（国家标准与技术研究所）

目录

1.报告背景

2.零信任实施模型（方法论）

3.报告建议条目

4.九项关键建议

5.报告详细目录

图1-报告首页

报告原文地址：

https://www.cisa.gov/sites/default/files/publications/NSTAC%20Report%20to%20the%20President%20on%20Zero%20Trust%20and%20Trusted%20Identity%20Management.pdf

报告背景

总统国家安全电信咨询委员会（NSTAC）的职责是向总统办公厅（EOP）提供基于业界的分析和建议，说明政府如何制定政策或采取行动，以加强国家安全和应急准备（NS/EP）通信。

1）三箭连发

2021年5月，白宫责成NSTAC开展一项多阶段研究任务“增强2021年之后的互联网弹性”。该任务要求NSTAC研究对美国国家安全和应急准备至关重要的三个关键网络安全问题：

商业信息和通信技术供应链中的软件保障。
零信任和可信身份管理。
信息技术（IT）和运营技术（OT）的融合。

NSTAC已经在2021年11月提交了第1阶段的供应链软件保障报告。这次提交的是第2阶段的《零信任和可信身份管理》报告。而第3阶段的工业物联网安全还处于研究过程中。

2）战略延续

2022年1月26日，拜登政府发布了《联邦政府零信任战略》，要求各机构在2024财年结束之前（即2024年9月底之前，即两年半时间内），实现具体的零信任安全目标。这些目标按照零信任的五大支柱分别设置。

NSTAC报告认为：当前和未来的政府必须将联邦零信任过渡视为国家的当务之急，并因此建立必要的领导优先顺序、资金和问责机制，以在未来十年维持政府对零信任的整体承诺。为了实现这一目标，NSTAC提出了24条建议和9条关键建议（参见本文的后文）。

3）主要内容

报告的主要内容是：

第0章：概述报告摘要；
第1章：回顾美国联邦政府零信任战略；
第2章：介绍零信任实施模型，主要包括五步流程和成熟度模型；
第3章：提出建议，解决联邦政府零信任战略实施的障碍；
第4章：提出建议，解决非联邦实体零信任战略实施的障碍；

注：报告详细目录，放在了本文末尾。

零信任实施模型（方法论）

NSTAC总结了一套零信任实施模型，本质是零信任实施方法论。它基于保护面的概念，采用五步流程法来实施零信任，并使用成熟度模型来度量零信任进展。

1）定义保护面和DAAS

保护面：是零信任策略保护的区域。

每个保护面都包含单个DAAS（数据、应用程序、资产、服务）元素。
每个零信任环境可以包含多个保护面。
零信任架构则以“每个保护面”为基础进行构思，由内而外设计，从保护面开始向外移动。

DAAS（数据、应用程序、资产、服务）：进入单个保护面的敏感资源。

数据：如果泄露或误用，会造成最大风险的敏感数据。示例包括支付卡信息、受保护的健康信息、个人身份信息、知识产权。在政府背景下，还包括机密信息、国家安全信息、受控非密信息。
应用程序：使用敏感数据或控制关键资产的应用程序。
资产：包括组织的信息技术（IT）、运营技术（OT）、物联网设备。
服务：组织最依赖的服务。示例包括域名系统（DNS）、动态主机配置协议（DHCP）、目录服务、网络时间协议（NTP）、定制的应用程序编程接口（API）。

2）梳理零信任实施五步流程

图2-零信任实施五步流程（极简版）

对上面这五步流程的具体描述，如下表所示：

表3-零信任实施五步流程（含可量化进度指标）

3）给出零信任成熟度模型

报告在附录A中给出了零信任成熟度模型。该模型将零信任成熟度（横向维度）与零信任实施五步流程（纵向维度）相结合。如下所示：

表4-NSTAC零信任成熟度模型

联邦零信任战略中引用了CISA零信任成熟度模型。笔者对比了NSTAC零信任成熟度模型与CISA零信任成熟度模型，发现主要区别是：

成熟度维度不同：CISA模型的成熟度划分为3个阶段，即传统、高级、最优；而NSTAC模型的成熟度划分为5个阶段，即初始、可重复、定义、管理、优化。
另一个维度不同：CISA模型的另一个维度是五大支柱，即身份、设备、网络、应用程序工作负载、数据；而NSTAC模型的另一个维度是五步流程，如图2和图3所示。

4）使用Kipling方法编写零信任策略

Kipling方法：是一种创建零信任策略的方法，描述了资源访问的人员、内容、时间、地点、原因、方式（Who, What, When, Where, Why, How）：

Who：应该允许谁访问资源？
What：允许断言的身份用于访问资源的应用程序是什么？
When：何时允许断言的身份访问资源？
Where：资源位于哪里？
Why：为什么允许用户（Who）访问资源？
How：流量访问资源时应如何处理？

作为示例，报告在附录B中，采用Kipling方法，给出了目录服务管理员的零信任策略示例：

表5-目录服务管理员的零信任策略示例

表中这条零信任策略的具体含义是：成功完成MFA（多因素认证）的管理员用户（由组成员身份而非源IP地址定义），可以在通过IDS（入侵检测系统）和DPI（深度数据包检查）检查后的任何时间（24/7），使用“目录管理工具应用”（Directory Admin Tool App）（由web/client-server/SSH而不是端口和协议定义），访问“Dir_Server_Loc（目录服务器位置）” （由工作负载上的标签而非目标IP地址定义）的服务器，因为他需要管理目录服务的“元数据”。

笔者对Kipling方法实在是太喜欢，于是就尝试寻找它的来源。结果发现它真地就是经典的"5W1H"方法论。

图6-Kipling

诺贝尔文学奖得主、英国作家Kipling在1902年出版的《原来如此故事集》中写道：

我有六个诚实的仆人，

他们教会了我所知道的一切。

他们的名字是What和Why和When

和How和Where和Who。

5）给出了零信任成熟度模型的示例

由于目录服务是控制访问权限的核心，因此它是攻击者的主要目标。在零信任上下文中，目录服务是支持身份认证和授权的底层基础设施。它的失陷会使任何零信任的实施变得无效。所以，报告专门在附录B中给出了目录服务的零信任成熟度模型示例。

对于其它类型的关键性服务，可以参考这个示例，制定零信任实施成熟度模型。

报告建议条目

NSTAC报告中所有建议的条目如下：

24条建议：除了粗体标记的条目（即5个标题），其它所有条目正好构成24条建议。
9条关键建议：以绿色标记的条目，是报告声称的最关键的9条建议。

3. 解决联邦政府零信任战略实施的障碍和促进因素

3.1. 解决监督问题并建立成熟度指标

3.1.1. 通过零信任战略实施的进度指标，加强问责制

3.1.2. 通过进度指标，提高透明度并支持持续改进

3.1.3. 成立工作组，为关键联邦企业基础设施服务开发零信任成熟度模型

3.2. 解决治理障碍和促进因素，以实现联邦对零信任的持续承诺

3.2.1. 将零信任原则纳入联邦网络安全政策

3.2.1.1 阐明零信任战略与FISMA要求之间的一致性

3.2.1.2 自动化FISMA合规任务

3.2.2. 将零信任实践纳入联邦网络安全技术计划

3.2.2.1 利用CISA网络安全部门的计划和服务

3.2.2.2 明确将CISA的CDM(持续诊断和缓解)计划与零信任对齐

3.2.2.3 建立一个民间零信任项目办公室

3.2.2.4 优先创建CISA共享安全服务，以发现互联网可访问资产

3.2.2.5 在拟定的民用和国防零信任计划办公室之间建立协同关系

3.2.3. 将零信任实践纳入联邦网络安全预算和采购流程

3.2.3.1 扩大采购工具的范围

3.2.3.2 鼓励各部门和机构为零信任确定额外资金

3.2.3.3 在联邦技术采购中传达对零信任的支持

3.3. 解决技术障碍和促进因素，以实现联邦对零信任的持续承诺

3.3.1. 在特别出版物中评估零信任生态系统技术互操作性

3.3.2. 鼓励采用云计算

3.3.3. 探索新的可信身份管理方法

4. 发挥联邦政府在激励非联邦零信任采纳方面的作用

4.1. 提高和维系公众意识

4.2. 制定和完善标准和指南，包括国际标准和指南

4.3. 在为IT安全现代化提供的联邦拨款中激励零信任

4.4. 在联邦采购中考虑对零信任的偏好

4.5. 考虑监管救助行动

九项关键建议

下面对报告中最关键的九项建议，展开其内容。笔者也分别做了“评论”。而更多的详情，可以参见报告原文中的对应章节。

1）加强问责制，以度量联邦零信任进展（对应于3.1.1节）

联邦首席信息安全官（CISO）应该与国家网络总监（National Cyber Director）密切合作，针对零信任最佳实践，制定基于进度指标的报告要求，如表3中的第3列所示。报告责任需在机构CISO或以上级别。

评论：美国政府实在是太擅长搞量化指标了！用量化指标来评估效果，才能有效问责。

2）提高联邦零信任进程的透明度（对应于3.1.2节）

联邦政府必须致力于在记录零信任进程中的经验教训方面保持透明度，在政府内部培养持续改进的文化，并教育更加广泛的国家生态系统。管理和预算办公室（OMB）应要求各机构每年至少发布一个零信任用例，记录实施经验教训。OMB应与美国NIST（国家标准与技术研究所）共同召开年度工作组会议，审查用例，并在适当情况下更新现有的联邦零信任指南和标准。

评论：既然大家都知道零信任不那么容易落地，就请把各家踩过的坑、绕过的弯都如实共享出来，照亮后人的前行之路吧。

3）为关键的联邦企业基础设施服务开发零信任成熟度模型（对应于3.1.3节）

OMB应通过联邦CISO委员会开展全面的流程，以识别目前在联邦机构中普遍存在并可能至少在未来5年内继续存在的企业基础设施服务。一旦确定这些服务后，联邦CISO委员会应成立一个跨机构工作组，为保护每项服务创建相应的零信任成熟度模型，可以参考附录B中NSTAC为目录服务（如Active Directory）创建的零信任成熟度模型示例。

评论：一定要对“联邦企业基础设施服务”有正确的理解！“企业”一词是企业级/全局性/整体性之意，而非一家具体的企业。

评论：企业基础设施服务有哪些呢？示例包括目录服务、域名系统（DNS）、动态主机配置协议（DHCP）、网络时间协议（NTP）等。NSTAC希望为所有关键企业基础设施服务，创建相应的零信任成熟度模型。

评论：为什么要选择目录服务作为示例？因为它是核心企业服务，几乎所有联邦机构都要用到它，而且这种情况可能还会持续至少十年。

4）将零信任原则与关键治理和合规框架相一致（对应于3.2.1.1节）

OMB应发布一份备忘录，澄清零信任战略原则与FISMA（联邦信息安全管理法案）及其相关标准NIST800-53（信息系统和组织的安全控制）的机构合规要求之间的战略一致性。此外，OMB应责成NIST编制一份特别出版物（SP），将零信任映射到NIST SP-800-53的安全控制，以避免机构遇到其常规的合规义务与长期的零信任转型之间的冲突。

评论：这一招比较狠！直接给NIST派了工单：将零信任能力映射到NIST SP-800-53的安全控制项。如果真地能做出这个映射，零信任的落地难题就更容易解决了，对零信任的符合性验证也更简单了。笔者非常期待！

5）建立一个民用零信任项目办公室（对应于3.2.2.3节）

网络安全和基础设施安全局（CISA）应为联邦民用机构建立一个专用的零信任项目办公室，以托管实施指南、参考架构、能力目录、培训模块，并通常作为一个零信任的民间政府知识管理中心。在可行的范围内，民用零信任项目办公室应与最近成立的国防部零信任项目办公室协作并分享最佳实践。

评论：有军用，就该有民用。军民融合，不难理解。

6）创建CISA零信任共享安全服务以发现为互联网可访问资产（对应于3.2.2.4节）

CISA应阐明其现有共享服务技术产品如何帮助机构实现零信任。此外，CISA应建立一项新的共享服务，以帮助机构“全面了解其互联网可访问资产”，这是任何开始实施零信任的机构所应具备的基础能力，正如《联邦零信任战略》中明确强调的那样。

评论：为什么各个机构的互联网暴露资产还需要政府的共享服务来发现呢？这只能说明：发现和跟踪机构的互联网暴露资产，对机构自身来说具有很大挑战性。这也正是Gartner所提的外部攻击面管理（EASM）能力。由于这种可见性非常重要，机构自己又搞不定，只好请出安全管家CISA，把它做成一项共享型安全服务，普惠所有政府机构，避免安全短板效应。

7）评估零信任生态系统技术互操作性（对应于3.3.1节）

作为国家网络安全卓越中心（NCCoE）现有零信任工作的延伸，NIST应该评估商业、政府、开源零信任技术解决方案生态系统的技术互操作性。该NIST出版物应该输出未来的政策和投资建议，以提高零信任架构的采用效率。

评论：关于零信任生态系统的技术互操作性，几乎是每篇零信任建议书的必谈内容。这里就不再赘述了。

8）推进在国际标准机构中的零信任（对应于4.2节）

美国政府在NIST的领导下，与行业合作伙伴密切合作，应该启动一条多年的路径，在国际标准机构内部推进零信任。当前零信任指南的持续成熟至关重要；当它们演变为基于共识、得到广泛认可的国际标准，就可以成为美国政府鼓励在全国范围内采用零信任的各种政策行动的基础，正像NIST网络安全框架所做的那样。

评论：这个建议很有趣，但也很自然。由于美国的NIST网络安全框架（CSF）已经成为国际性的事实标准，它自然也就成为零信任的榜样。如果能将零信任从美国标准推广为国际性标准，当然就更好地保障了零信任的发展方向。

9）优先考虑在联邦IT现代化拨款中采用零信任（对应于4.3节）

CISA应在其自由裁量权中优先考虑零信任项目，以便为各州和地方授予IT安全现代化拨款。在CISA对《州和地方网络安全促进法案》（属于《基础设施投资和就业法案》（IIJA）的一部分）的管理中，这一机会尤其明显。根据该法案，他们将在未来4年（至2026年）投入10亿美元。交通部长、商务部长、能源部长根据IIJA的规定，还拥有自由裁量权，要求资金接收者证明“良好的网络安全实践”，作为在其管辖范围内接收资金的条件。他们应该酌情行使这一权力，鼓励采纳零信任原则。

评论：千言万语一句话，有钱才是好“爸爸”。只要资金预算和拨款都朝着零信任项目倾斜，还有什么搞不定的呢！

报告详细目录

0. 执行摘要

0.1 报告焦点和范围

0.2 关键结论的摘要

0.3 建议的摘要

0.4 九项关键建议的详细信息

1. 介绍零信任和美国联邦政府的零信任战略

1.1. 零信任的历史和基本原则

1.2. 零信任和联邦政府的网络安全战略

2. 零信任实施的业界标准和最佳实践

2.1. 零信任实施的业界模型

2.1.1. 零信任实施的五步流程

2.1.2. 零信任成熟度模型

2.2. 促进零信任的业界技术能力

3. 解决联邦政府零信任战略实施的障碍和促进因素

3.1. 解决监督问题并建立成熟度指标

3.1.1. 通过零信任战略实施的进度指标，加强问责制

3.1.2. 通过进度指标，提高透明度并支持持续改进

3.1.3. 成立工作组，为关键的联邦企业基础设施服务开发零信任成熟度模型

3.2. 解决治理障碍和促进因素，以实现联邦对零信任的持续承诺

3.2.1. 将零信任原则纳入联邦网络安全政策

3.2.2. 将零信任实践纳入联邦网络安全技术计划

3.2.3. 将零信任实践纳入联邦网络安全预算和采购流程

3.3. 解决技术障碍和促进因素，以实现联邦对零信任的持续承诺

3.3.1. 在特别出版物中评估零信任生态系统技术互操作性

3.3.2. 鼓励采用云计算

3.3.3. 探索新的可信身份管理方法

4. 发挥联邦政府在激励非联邦零信任采纳方面的作用

4.1. 提高和维系公众意识

4.2. 制定和完善标准和指南，包括国际标准和指南

4.3. 在为IT安全现代化提供的联邦拨款中激励零信任

4.4. 在联邦采购中考虑对零信任的偏好

4.5. 考虑监管救助行动

5. 结论

附录A. 零信任成熟度模型

附录B. 零信任成熟度模型的示例：目录服务

附录C. 成员和参与者

附录D. 缩略词

附录E. 定义

附录F. 参考文献

（本篇完）

阅读原文

跳转微信打开

数据访问控制的未来

Mon, 04 Jul 2022 06:36:00 +0800

原创一帆 & 柯学 2022-07-04 06:36 北京

原生控制>数据代理>数据边车

全文约4000字阅读约8分钟

数据访问控制是零信任的最后环节和终极目标。基于零信任的数据访问控制，已经成为数据安全保护和治理的新方法。

但是，对于数据访问控制的实施问题，企业客户却不得不面对几种选择：

1）基于数据存储原生控制的方法：是指利用数据存储的原生控制能力，来构建自己需要的数据访问控制。企业客户可以自己动手构建DIY(自己动手)解决方案，也可以花钱购买数据访问编排解决方案。但都无法摆脱数据存储原生控制存在可观察性不足的问题。

2）基于数据访问代理的方法：通过在数据消费者(用户/应用程序)和数据存储之间建立独立的数据访问层，将访问控制与数据存储基础设施分离。这是目前主流的商用数据访问平台采用的方式，也是当前最被看好的数据访问控制方法。但传统的数据库代理技术主要用于南北向的流量控制，且难以适应于云原生微服务环境。

3）基于数据层边车的方法：将服务网格(Service Mesh)中的边车(Sidecar)技术理念，应用到数据网格(Data Mesh)，专门解决云原生微服务环境中的东西向数据访问控制难题。数据层边车本质上充当应用程序和数据之间的断路器。尽管数据层边车还是发挥代理的作用，但它是为云原生架构和数据网格架构而设计的未来型代理。

虽然新一代技术常常代表了未来的方向，但是企业客户还是应该结合自身的实际情况，选择最适合的数据访问控制实施方案。

目录

1.数据存储原生控制方法

1）DIY(自己动手)解决方案

2）数据访问编排解决方案

3）数据存储库的可观察性不足

2.数据访问代理方法

1）代理和数据库代理

2）SQL无感知数据库代理

3）SQL感知数据库代理

3.数据层边车方法

1）传统代理无法适应云原生环境

2）云原生世界需要数据层边车

3）数据层边车 vs. 数据库代理

数据存储原生控制方法

数据存储原生控制方法可以细分为两种方案：DIY(自己动手)解决方案+数据访问编排方案。

1）DIY（自己动手）解决方案

方法说明。DIY（自己动手）解决方案是指客户利用数据存储原生能力，自己动手构建客户需要的数据访问控制。

原生功能包括数据存储中可用的安全视图、函数、策略。
如果客户的数据团队有能力利用数据存储中的原生功能，他们通常会这样做。

方法不足。使用原生能力构建DIY（自己动手）解决方案的问题在于：

它不是核心业务。在大多数情况下，利用原生功能构建DIY数据访问控制方案，并不是客户的高优先级事项。客户的工程资源最好用于支持和发展客户业务的核心活动，从而为企业创造更大的业务价值。
维护成本高。数据访问控制不是那种“设置好后就可以抛之脑后”的东西，它需要持续、悉心的照料，这会带来隐性成本和风险。
学习曲线陡峭。很多时候，如果您缺乏创建或管理数据访问解决方案的经验，此类项目可能会带来未知的工程挑战。
迁移数据平台的烦恼。如果客户想从一个数据平台迁移到另一个数据平台，可能需要重新编写DIY解决方案的大部分内容。
原生功能受限。DIY解决方案受限于可用的数据存储原生能力。参见下文。

2）数据访问编排解决方案

方法说明。数据访问编排解决方案是对原生数据存储能力进行编排的产品，只需要付费购买即可，无需客户自己的数据团队亲自动手实现它们。

数据编排通常由软件平台支持，该平台连接各种存储系统，并在需要时启用与其他应用程序的连接。它将来自多个存储位置的数据进行整合，以便企业可以在其分析和管理平台中使用这些数据。
在数据访问编排中，被编排的是对数据的访问，而非数据本身。不是在数据存储本身（例如数据库、数据仓库和数据湖）中手动配置数据访问，而是使用单个工具定义访问策略，然后在各种数据存储中执行安全策略。
编排解决方案可能会节省客户利用原生能力构建方案的时间。

方法不足。与后文介绍的数据访问代理方案相比，编排解决方案在许多方面受到限制：

缺乏数据感知能力。通常来说，编排解决方案依赖于定期批处理，来识别和标记敏感数据。而数据访问代理平台则能够在访问数据的同时对其进行分析，可以即时发现敏感信息并立即采取行动。
侵入性。编排解决方案经常会使用抽象数据访问所需的对象，污染数据基础设施。此外，在许多情况下，它们会迫使您更改现有逻辑（例如访问新的抽象对象而非现有对象）。而使用数据访问代理，则无需添加任何数据库对象，也无需改变查询中的任何内容。
超级管理员凭据使用。编排解决方案需要使用高访问权限账户。这意味着您可能需要设置一个账户，能在SaaS或设备上执行很多操作（即创建对象和读取数据）。而使用数据访问代理，您无需添加任何额外的凭据，从而消除了意外更改的风险。
原生功能受限。编排解决方案受限于可用的数据存储原生能力。参见下文。

3）数据存储库的“可观察性不足”

数据存储库存在“可观察性不足”的问题。

3.1）数据存储库日志通常被禁用

在传统的本地数据库和DBaaS（数据库即服务）中，日志的唯一来源通常是由数据存储库本身将活动记录到文件系统中。但是，日志记录通常会因为性能下降和PII泄密风险等原因而关闭：

性能下降。在MySQL和PostgreSQL数据库中，当打开查询日志记录时，由于关键查询执行路径中产生的额外I/O，QPS(每秒查询数)通常会下降25-30%；
PII泄密的风险。被记录的查询/请求日志，并没有经过对PII信息的隐私处理。这必然导致安全问题。

3.2）DBaaS(数据库即服务)的可见性不足

DBaaS中的指标主要有两个来源，但都存在不足：

一是粗粒度的DBaaS指标。这些是由DBaaS引擎自身发布的聚合指标，比如说每秒连接次数、每秒SELECT/UPDATE/INSERT次数、每秒慢速查询次数。但它们都是粗粒度的，无法对应到与DBaaS交互的特定用户或服务；
二是汇总的云提供商指标。但这些指标也无法被有效映射和归因。例如，AWS Cloudwatch发布了与DBaaS引擎的网络I/O活动相对应的字节数和吞吐量。然而，它无法识别出某个表中的多少行或者某个集合中的多少文档，对应于网络层观察到的字节数量。也不可能将这些指标的观察值，归因于特定用户或服务。

3.3）传统数据库部署的可见性不足

传统的数据库部署的确增加了一些可见性，如下所示。但由于性能影响或存储成本，这些日志通常会被禁用。

服务帐户：用户通常使用BI(商业智能)工具或应用程序登录数据库，而BI工具和应用程序将使用共享型服务帐户来查询数据库。也就是说，真实用户的身份无法记录在数据库日志中。
用户活动：身份认证日志可以突出显示身份认证失败时间，包括事件的日期和时间。但是，这类日志不包括上下文数据，包括执行的查询或调用者的源IP。
查询活动：这类日志通常用于数据库调优，包含性能细节，包括查询计划和执行时间。
系统健康状况：关于数据库健康状况的聚合指标，包括使用的内存和存储、上次运行性能调优的时间，以及硬件或损坏问题。

3.4）增强型数据库原生控制方法的不足

增强数据访问控制的一种常见方法，是将数据存储与IAM产品进行集成，从而为数据访问增强用户身份识别能力。
但是，这种集成在安全和监管方面留下了空白，因为它们没有将数据库原生访问控制的全部功能扩展到经过SSO身份认证的用户，也没有提供可以扩展的访问策略工具。

总而言之，数据存储原生控制在很多时候都靠不住。所以，数据访问代理方法才被广泛采用。

数据访问代理方法

1）代理和数据库代理

代理是位于客户端和服务器之间的拦截服务。当代理靠近客户端部署时，称为正向代理。当代理部署在离服务器更近的地方，使得客户端不知道服务器的来源时，它被称为反向代理。

数据库代理（ProxySQL、MaxScale等）基本上是一种反向代理，旨在为数据库、键值存储、消息队列提供安全性、可伸缩性、高可用性等优势。

图1-数据库代理

2）SQL无感知数据库代理

在高度分布式的数据存储库（如MongoDB和Cassandra）流行之前，数据库代理通过为后端数据存储库提供连接池，来实现扩展性和高性能。通过将请求路由到健康的数据后端，来确保高可用性，并减少故障转移时间。

此类数据库代理通常被称为L4层代理或SQL无感知代理，包括HAProxy、Nginx和类似工具。

3）SQL感知数据库代理

随着应用程序迁移到云端，数据量猛增，现代数据存储库开始提供可扩展性和高可用性功能，使用分布式Coordinator-Worker（协调器-工作节点）架构的数据分片和复制。

图2-Coordinator-Worker架构

为了保护应用程序逻辑免受底层拓扑变化的影响，ProxySQL和MaxScale等 SQL感知数据库代理开始受到关注。

SQL感知代理可以执行这类任务：通过将读查询定向到Worker并将写查询定向到Coordinator中的master，来执行SQL读查询/写查询的路由。

SQL感知代理也用于这些场景：需要在SQL层操作以缓存SQL查询的响应，以提高性能；或者重写和阻断某些SQL查询，以增加安全性。

事实上，目前主流的数据访问平台都采用了感知型数据库代理的方式。这也是当前最被看好的数据访问控制方法。

图3-基于数据库代理模式的数据访问平台

数据层边车方法

1）传统代理无法适应云原生环境

随着容器技术尤其是Docker的成熟，以微服务为可组合单元的面向服务架构（SOA）开始受到广泛欢迎。云原生应用程序开始使用微服务作为它们的构建模块，从而将自身用于持续集成和持续部署的DevOps方法。

虽然基于微服务的新架构带来了许多好处，但它们也暴露了挑战，特别是在安全和流量管理方面：

这些分散的微服务之间的通信，导致东西向流量激增；
却没有可以强制执行安全规则的明确边界；
也没有可以执行流量管理的单一入口/出口点。

因此，在应用程序和数据存储库（数据库或数据仓库）之间部署代理的传统模型，在云原生的新世界中不再适用。

2）云原生世界需要数据层边车

在云原生世界中部署代理的思路是数据层边车（Sidecar），即采用边车模式部署的无状态拦截服务。

在云原生应用程序部署架构中，数据层边车本质上充当应用程序和数据之间的断路器，以保护数据存储库。

数据层边车诞生于云中，可以快速部署到客户环境中，并实时拦截对任何类型数据存储库（数据库、数据管道、数据仓库等）的所有请求，而不会影响性能和可扩展性。所有的集成和配置，都可以从统一控制平面进行集中管理。

由于数据层边车便于使用Kubernetes等服务编排工具进行部署，因此企业可以确保其所有存储库的数据保护始终处于开启状态。

虽然数据层边车仍然发挥代理的作用，但它的架构是为云原生架构而设计的：

图4-拦截方式对比：传统代理 vs. 数据层边车

如上图所示，数据层边车可以采取无状态方式运行，从而支持横向扩展和高可用性。

传统的应用程序代理，需要管理查询客户端的会话状态，以帮助旧数据库架构应付繁重的工作压力。
而如今，数据存储库能够自己管理数据层连接，因此数据层边车可以无状态运行。于是，可以部署多个边车，来保护单个数据存储库。

3）数据层边车 vs. 数据库代理

数据层边车与数据库代理相比，具有很多明显的优势：

数据架构的先进性：数据层边车支持现代数据网格架构；而数据库代理采用中心辐射架构，来自微服务的流量被迫先到达代理，然后才被发送到目标。
云编排平台的可用性：数据层边车使用云编排平台（如Kubernetes）部署；而数据库代理通常使用未集成到云编排平台。
流量控制能力：数据层边车支持全方向流量控制，即包括南北向和东西向；而数据库代理仅支持南北向。
可观测能力：数据层边车与可观测性技术栈（如ELK、Prometheus等）高度集成，具有丰富的遥测数据；而数据库代理只有基本的日志数据。
微服务环境的适应性：数据层边车与基础设施模板工具（如Terraform、Cloudformation等）一起使用；而数据库代理不适合高度分布式的微服务环境。
DevOps集成：数据层边车采取API优先原则，与DevOps工具（如Prometheus、Grafana等）集成，用于日志记录、监测、可视化、CI/CD；而数据库代理缺少与DevOps工具的集成。
持续部署：数据层边车通过与CI/CD工具（如Jenkins X、Spinnaker等）的集成，实现持续部署；而数据库代理不支持CI/CD。
网络延迟：数据层边车采用无状态的断路器设计，使得去往数据存储库的流量延迟可以忽略不计；而数据库代理在服务和数据存储库之间引入额外控制点，导致不可忽略的网络延迟。
身份保护：数据层边车内置了使用mTLS的身份保护，提供了原生的身份认证和授权能力；而数据库代理缺少对连接服务进行身份认证和授权的原生支持。

（本篇完）

阅读原文

跳转微信打开

数据治理的三种共享范式

Wed, 01 Jun 2022 06:18:00 +0800

原创启承 & 柯学 2022-06-01 06:18 北京

共享，还是独享

全文约3000字阅读约5分钟

数据共享范式的演变，从过度授权的“默认知道”（Default-to-Know），到默认不共享的“需要知道”（ Need-to-know），再到默认共享的“需要共享”（ Need-to-share）。这些范式，本质上是在数据价值和数据风险之间进行取舍和平衡。

众所周知，安全法规和最佳实践似乎经常要求组织将数据锁定，从而限制“需要知道”的员工的访问。然而，数据只有与需要它的人共享时，才有价值。但是，数据的更广泛共享，既需要秉持“需要共享”的原则，又需要采用创新的数据安全方法，如数据安全治理框架和数据安全平台。

数据共享范式将影响许多数据驱动型组织。根据Gartner的观点，到2025年，30%的Gartner客户将使用“需要共享”方法，而非传统的“需要知道”方法，来保护他们的数据。

组织应该审视：其数据安全策略和数据安全治理框架，是否还停留在石器时代。

目录

1.杰出数据共享的好处

2.传统数据共享的问题

3.从“默认知道”到“需要知道”

4.从“需要知道”到“需要共享”

5.DataSecOps方法

杰出数据共享的好处

杰出数据共享意味着，大量用户可以快速、轻松地访问数据，以便他们可以分析数据并使用数据，来改善各种职能（包括客户服务、留存、支持、运营、营销、销售等）的业务成果。

杰出数据共享蕴含了数据民主化的理念，使组织内的尽可能多的人能够访问数据，并将其转化为有意义的业务价值。

杰出数据共享有以下主要好处：

当组织中的许多数据消费者使用数据时，他们能够快速将数据转化为价值，组织将获得较高的数据投资回报率。
当组织拥有杰出数据共享时，数据产品/项目的上市时间和实现价值的时间就会缩短。这可能会对组织的业务结果产生重大影响。
当组织的数据共享运行良好时，组织可以减少数据的瓶颈和排队时间。这使组织的用户（如数据科学家、业务分析师、工程师）更加快乐，并使数据工程和数据治理等团队更加专注于他们的核心职责，而不是手动管理和处理数据访问请求。

传统数据共享的问题

数据治理是指监督数据管理的政策和流程。数据治理需要保证数据安全可靠。

传统上，在数据共享方面，组织倾向于“选择加入”（opt-in）方法。这意味着默认情况下数据所有者不与组织的其他成员共享数据。

评估过程需要时间。当有其他成员专门请求数据共享时，数据所有者通常会评估共享数据的好处和风险：好处主要是不同类型的业务成果，例如改进的营销、客户服务、运营；风险主要是合规和安全风险（例如不符合监管要求或数据泄露）。而这个评估过程需要时间。

技术启用还需要时间。从数据所有者批准对共享数据集的访问开始，通常还需要额外时间由数据团队（如数据工程、平台和共享数据服务等）在技术上启用共享，才能真正与数据消费者（如数据科学家、业务分析师、工程师等）共享数据。

从“默认知道”到“需要知道”

“默认知道”访问模式的后果。很多企业，特别是处于高速增长模式时，都采用“默认知道”的数据访问模式。这意味着以过度授权（甚至是不受控制）的方式访问数据。这种过度授权通常会在安全和合规风险方面产生问题。

总有一天，企业想要缩小这些授权。而缩小这些授权通常是个很费劲的过程。因为公司不得不设置新的安全控制，创建新的流程，应用新的安全策略。而那些之前已经习惯于免费访问所有数据的用户，将只能基于其角色和责任获得有限的访问权限。而这个过程必然是痛苦的，比如：

生产和分析环境中不断变化的安全控制，会带来运营风险和成本。
这个过程需要被具有不同目标的多个不同团队所理解、接受、执行。
这个过程通常很难获得支持，尤其是当业务价值并不总是增长时。一般来说，如果公司不满足某些数据访问控制要求，它们将会达到增长上限。

“需要知道”访问模式。企业的下一步自然是从“默认知道”转变为“需要知道”。这意味着，在转变之前，所有（或大多数）数据消费者都可以访问数据存储中的所有（或大多数）数据；而现在，基于他们在组织中的角色（如客户成功、工程师、营销）和具体职责，他们对数据的访问将受到限制。其他的例子还包括仅限特定团队访问敏感数据、数据匿名化和脱敏，以及应用数据本地化策略。

从“需要知道”到“需要共享”

已经看到并且可以预期，已经处于“需要知道”心态的组织，正在意识到，重点应该放在允许组织中更多的数据可访问性上，并保持共享优先的心态。

为了更好地向“需要共享”范式转变，组织需要改变思维方式和行为：

1）从风险厌恶到风险调整

风险厌恶（Risk-Averse）策略。许多组织采用风险厌恶的策略，即先试图缓解所有风险，然后才接受数据共享请求。

风险调整（Risk-Adjusted）策略。但更优的策略是风险调整，即组织直接从数据被共享和处理的位置开始，着手缓解风险。

风险调整策略的一个例子是拥有一个连续的匿名化层，以确保共享的数据被匿名化或脱敏到所需的程度。具有基于角色的脱敏非常重要，这样客户成功团队就可以访问客户的出生日期（即月份和日期），这样他们就可以祝他们生日快乐，但无法访问出生日期字段的年份；而其他用户则根本无法访问出生日期的任何部分，因为他们的工作不需要。

2）从选择加入到选择退出数据共享

选择加入（Opt-In）数据共享：意味着数据所有者默认不共享数据，只是有选择地共享某些数据。这种方式很容易产生数据孤岛。

选择退出（Opt-Out）数据共享：意味着数据所有者默认共享数据，只是有选择地不共享某些数据。

共享方式转变。从“选择加入”转变为“选择退出”数据共享，意味着组织中的数据默认都是共享的，而数据所有者需要决策的是哪些数据不能共享。

数据访问控制。更加重要的是，数据默认共享隐含了数据访问控制的要求。也就是说，数据所有者以及其他数据干系人（数据治理、数据安全、数据隐私等团队）可以并且应该对要共享的数据（尤其是敏感数据）进行访问限制。

3）从数据所有者手中夺走（部分）权力

数据所有者拥有过度权力。传统上，数据所有者会收到组织中其他团队的共享请求，有时会在与他人协商后决定是否共享数据。他们大多是根据风险与价值的衡量，来做出这个决定。而问题在于，数据所有者通常对风险和价值的看法存在偏见。因为数据所有者和数据创建者通常对共享数据所涉及的风险持有狭隘的观点，而忽视了数据共享所带来的价值。

组织需要剥夺数据所有者的部分权力。剥夺权力的最佳方式，就是采用上面提到的“选择退出”模式，即数据默认都是共享的，而数据所有者只能选择那些不能共享的特定数据集。

4）清晰透明的安全、治理、隐私策略

前面已经提到，在共享数据时，如果不采取必要的控制措施来避免风险，就不可能实现“需要共享”的目标。

要实现这一点，组织需要制定非常清晰的数据共享“参与规则”。这意味着组织需要清楚地了解：

持续了解敏感数据的位置。否则，数据暴露风险可能会压倒数据民主化的愿望。
具备敏捷访问控制的能力。这意味着，即使数据集在整个组织中共享，也只有某些特定组才能访问PII（个人识别信息）。这通常通过动态数据脱敏等方法来实现。
有一个“委员会”（或团队），可以针对数据共享的限制性做出快速决策，并解决冲突。
培训所有数据干系人（在许多数据驱动型组织中，他们可能是组织的重要组成部分），在数据隐私、数据安全、数据治理等方面。

DataSecOps方法

在组织内转向更加开放的数据共享策略，非常符合DataSecOps（数据安全运营）理念。换句话说，一个组织要想处于数据民主化的态势，就不得不采用DataSecOps原则，如将安全性嵌入在流程本身中，否则，将无法以自动化方式应用访问策略来获得即时数据访问。

“需要共享”是所有组织处理其数据的恰当方式吗？不，这种方法可能被视为“纯粹数据民主化”。它适用于在DataSecOps方面达到成熟或部分成熟水平的组织。

然而，在数据优先经济中，一个高阶的“需要共享”型组织，必然会对“默认知道”和“需要知道”型组织形成“不公平的优势”。

而一个好的数据安全平台，也是一个DataSecOps平台，无论组织采取“默认知道”、“需要知道”、“需要共享”范式的哪一种，都可以帮助组织增强数据访问控制并加速数据价值实现。

（本篇完）

阅读原文

跳转微信打开

数据治理的三本数据秘籍

Wed, 11 May 2022 06:09:00 +0800

原创一帆 & 柯学 2022-05-11 06:09 北京

秘籍在手，数据不愁

全文约3500字阅读约5分钟

数据目录、数据清单、数据字典是良好数据治理活动的组成部分。它们被经常混用，但它们并不相同。

数据目录汇总了组织中数据资产的整体概况；数据清单详细说明了组织中可用的所有数据集，并显示所有相关元数据；数据字典定义了这些数据集的规则，指示了它们的格式、形状、schema。

这些数据秘籍的最大挑战是保持其最新。由于数据采集管道的速度和数量是天文数字，因此需要自动化和敏捷的协议来更新它们。

拥有这些数据秘籍并保持最新，可确保高效的数据交互，使企业团队能够简化其数据操作并获取有价值的数据洞察。

数据清单是执行数据清点/盘点的基础。一个高价值的数据安全平台，应该能够自动化维护一个持续更新的数据清单，其中包括敏感数据的分类分级。

目录

1.数据治理中的三本秘籍

1）数据目录（Data Catalog）？

2）数据清单（Data Inventory）？

3）数据字典（Data Dictionary）？

2.为何需要这些数据秘籍

1）为何需要数据目录？

2）为何需要数据清单？

3）为何需要数据字典？

3.数据秘籍之间的区别

1）数据目录 vs. 数据清单

2）数据目录 vs. 数据字典

3）数据清单 vs. 数据字典

4.创建数据秘籍的关键因素

1）重点关注敏感数据

2）持续敏感数据发现

3）确保对半结构化数据进行分类分级和更新

数据治理中的三本秘籍

1）数据目录（Data Catalog）

数据目录是企业用来管理其数据的集中式元数据存储库。其中概述了企业数据资源的组织、使用、管理的信息。该目录支持数据工程、分析操作、科学的功能。

数据目录的目标是使数据管理变得简单有效，共享有关收集和存储在组织中的数据的知识和信息。它概述了各种管道中的数据流，并提供数据景观的鸟瞰图。

数据目录通常与它们所引用的数据集分开存储在数据仓库或数据湖中。

数据目录的建立，需要遵循以下五个步骤：

数据获取：首先确定哪些元数据是相关的，找到这些相关数据所在的位置和存储的形式，确定如何捕获它们。通过了解数据的形状、结构、语义，来发展数据目录的形状和结构。尽量自动更新数据目录，几乎所有的数据库和数据存储都有工具，可以帮助您以所需的形状和语义提取元数据。通过数据沿袭，了解数据的来源和去向，为数据用户提供上下文。数据目录应支持各种数据类型，包括表和流数据。
分配数据所有者：捕获数据后，组织必须分配对该数据的所有权。赋予某人确保数据和文档完整和准确的责任，并为需要额外信息的数据用户提供了一个联系人。最重要的数据所有者，是数据管理员和技术所有者。数据管理员管理和解决与业务相关的查询；而技术所有者负责解决技术问题。
建立数据文档：一次性对所有数据进行编目通常是不可行的，所以需要一种切合实际的方法。首先对最重要的数据进行编目，然后是第二重要的数据，以此类推。
定期更新数据目录：数据集是不断变化的，所以识别这些变化并更新数据目录至关重要。理想情况下，这个过程应该是自动化的。
优化数据交互：数据目录是一种工具，使企业团队能够有效地与企业的数据交互。了解这些团队的需求并优化相关的标准和规范，为优化数据交互铺平道路。如标准化所有内部数据库、schema、字段、数据沿袭的文档格式。

2）数据清单（Data Inventory）

数据清单是数据清点/盘点的成果。数据清单是集中化的元数据集合，它指示了组织收集和维护的所有数据集。该文档（或文档集合）精确定位每个数据集的位置及其包含的数据类型。

数据分析师使用数据清单来确定哪些数据可用以及如何访问它们。

数据管理员维护数据清单，并为每个数据集制定相关的数据访问策略。

数据清单的主要挑战是保持最新。最有效的方法是通过自动化方式持续更新数据清单。

数据清单的示例如下：

3）数据字典（Data Dictionary）

数据字典描述了如何命名和定义数据资产的信息。数据字典通常包含围绕数据资产、关系、有关来源和使用的元数据、数据schema等术语的集中定义。比如数据资产的名称、设置和其他重要属性。

数据字典示例。数据字典通常包含以下元素：

数据资产名称
格式类型
与其他数据实体和资产的关系
参考数据
数据质量规则
元素数据资产层级
数据存储位置
质量指标代码
业务规则（数据质量验证和schema对象）
实体关系图

有两种类型的数据字典：

静态数据字典：不绑定到任何特定的数据库，因此必须手动更新。但手动过程更新的延迟，会导致数据字典中的元数据不同步。
动态数据字典：会随着它们所链接的数据存储库的增长而自动更新。建议组织实施动态数据字典，以确保所有数据字典保持更新和准确。

数据字典的创建方法。大多数情况下，由计算机辅助软件工程创建的数据库管理系统和信息系统，都包含动态数据字典。团队可以使用这些字典作为创建数据字典的起点。如果您无法自动生成可机读的数据字典，则可以使用单源字典，例如电子表格中包含的字典。

为何需要这些数据秘籍

1）为何需要数据目录？

当您拥有跨多个数据字典且可供多个用户访问的数据时，最好有一个数据目录。数据目录将这些数据组织成简单、易于消化的形式，从而简化数据提取和处理。

数据目录有助于改进数据管理。它们提供组织中可用数据集的高层级类别信息，从而提供高层级洞察和分析。该资产使干系人能够有效地找到存储在不同位置的任何类型的相关数据集，例如数据湖、仓库和其他数据库。

数据目录可支持数据工程操作。数据目录通过跟踪数据schema变更，来支持数据工程操作，以促进数据管道中的转换和聚合。数据目录通过在发生变更时触发警报，来帮助数据工程师检查传入数据是否符合预期schema。

数据目录使组织能够有效跟踪数据资产，并使干系人能够快速轻松地找到相关数据集，同时适应不断变化的数据环境。

2）为何需要数据清单？

数据清单满足数据法规合规性。依据GDPR（欧洲通用数据保护条例）等数据治理法规，要求企业知道他们收集和存储的所有敏感数据的位置，这隐含要求了详细和最新的数据清单。这在收集个人身份信息(PII)时尤其重要。

数据清单提供了数据可见性。当组织拥有广泛的数据采集时，了解其所拥有的数据及其有用的原因是一项艰巨的任务。而数据清单可以成倍地简化此任务，因为它提供了组织拥有的数据及其位置的详细信息。数据清单为数据消费者提供了数据发现和访问的起点。数据清单也简化了数据跟踪，因为组织的数据现在本质上是可搜索的。

3）为何需要数据字典？

数据字典可以防止数据冗余和歧义。当企业拥有被许多用户访问的大量的定量数据时，数据字典是必不可少的，因为它可以防止数据冗余和歧义。如果使用得当，数据字典可以提高效率。虽然准备这份文件可能需要一些时间，但长期的结果是值得的。

数据字典有助于防止在项目中使用数据资产时出现不一致和冲突。

数据字典中的元数据，主要关注数据资产的业务属性。它通常促进业务干系人和技术用户之间的沟通，确保所有信息、内容、格式都满足要求。

数据字典可用于支持数据工程操作。数据字典与数据仓库、关系数据库、数据管理系统密切相关。

数据秘籍之间的区别

1）数据目录 vs. 数据清单

数据目录：提供了组织中所有可用数据的鸟瞰图以及在哪里可以找到这些数据。数据目录通过根据常规业务功能进行组织，例如了解潜在客户生成管道、管理采购和库存、跟踪客户消费习惯。虽然数据清单中的每个条目都是唯一的，但数据目录可以引用不同条目中的相同数据点。
数据清单：包含组织所有数据集的元数据（如每个数据点的位置和类型），使这些数据集本质上是可搜索的。它本质上是细粒度的，提供有关单个数据集的详细信息。数据清单中的每个条目都是唯一的。数据清单中包含的信息始终是唯一的，而一个数据集可能会出现在数据目录的多个条目中。因此，数据清单比数据目录更加细化和技术化。

2）数据目录 vs. 数据字典

数据目录：反映了组织中数据资产的整体概况。
数据字典：用于命名和定义数据资产，目的是防止数据冗余和歧义。

3）数据清单 vs. 数据字典

数据清单：详细说明了组织中可用的所有数据集，并显示所有相关元数据。
数据字典：定义了这些数据集的规则，指示了它们的正确格式、形状、schema。

创建数据秘籍的关键因素

创建数据目录、数据清单、数据字典是现代数据处理中的基本功能。然而，这些过程存在一些固有的常见缺陷，特别是在处理敏感数据和非结构化或半结构化数据时。此时，数据目录、数据清单、数据字典协同工作，共同构成了理解和保护这些数据的基础。

1）重点关注敏感数据

敏感数据应该被准确地标记、编目和清点，因为知道数据在哪里以及它有多敏感，可以采取进一步的数据保护措施。

组织应该分配对这些敏感数据的所有权，因为知道谁对数据负责会产生保护它的紧迫性。

限制对敏感数据的访问，并在数据目录中相应地更新使用和访问指南。

2）持续敏感数据发现

勾勒并实施协议，以不断发现组织数据结构中的敏感数据。如果企业不知道那里有敏感数据，就无法开始保护它。

3）确保对半结构化数据进行分类分级和更新

半结构化数据不适合明确定义的结构或schema。相反，它是通过标签进行组织的，这些标签允许对它们进行分组和组织。这些非关系或NoSQL数据类型通常难以捕获、分类分级、更新，但它们构成了数据治理的重要组成部分。

需要实施一些流程来识别和编目此种数据，以确保组织不会创建一个充满暗数据的湖泊。

（本篇完）

阅读原文

跳转微信打开

数据治理的三位数据大师

Sun, 24 Apr 2022 06:08:00 +0800

原创启承 2022-04-24 06:08

想起星战中的尤达大师

全文约3000字阅读约5分钟

数据的价值取决于数据治理的效果。而数据治理工作有一个至关重要的基础——具有明确的数据治理角色，并确保所有干系人理解这些角色之间的差异。

完备的数据治理角色应该包含三位数据大师：1）数据所有者：对数据治理的结果负责；2）数据管理员：对数据治理的任务负责；3）数据保管员：对数据安全负责。

这些角色叫什么名字，并不重要。最重要的是：为什么这些角色如此重要？组织为什么应该关心这个问题？

数据治理对网络安全至关重要，因为网络安全的核心是保护数据免受网络威胁。当把数据治理与网络安全结合时，就产生了数据安全治理的需求。而作为数据安全治理的工具，一个好的数据安全平台，应使三位数据大师能够各司其职，共同执行组织的数据安全治理工作。

目录

1.企业的数据是资产还是负债？

2.三位“数据大师”

1）数据所有者（数据主人）

2）数据管理员（数据管家）

3）数据保管员（数据卫士）

3.数据治理角色之间的差异

1）数据所有者 vs. 数据管理员

2）数据所有者 vs. 数据保管员

3）数据管理员 vs. 数据保管员

4.数据治理角色的示例

企业的数据是资产还是负债？

大多数企业的业务主管都认同，数据已经成为组织的宝贵资源。而且数据的规模在快速扩大。

但是，数据在企业中可能扮演截然不同的角色。特别是对于现代监管环境中的组织而言，糟糕的数据治理可能会将数据转化为严重的负债，而不是资产，从而使企业面临严重的隐私处罚。

只有当我们知道如何使用数据、正确管理数据并给予它应有的尊重时，数据才会有价值，才能变成资产。

当今的普遍现象是，组织在缺乏良好数据治理的情况下开展业务运营：

组织通常拥有大量数据，但没有很好地记录或标准化，因此他们不了解所拥有的数据。
即使他们了解，他们在查找或访问恰当的数据时，也会遇到障碍。
即使组织可以找到他们想要的数据，他们通常也不能完全确定它是否足够可靠。

一个数据驱动型组织，应该制定数据管理的完善制度。同样重要的是，拥有一个数据治理团队，充分了解数据治理过程中的具体角色和职责。

数据治理中的三位数据大师

如果您研究过数据治理的实施，您肯定已经遇到过许多角色。以下是任何组织在数据治理背景下都需要了解的三个最重要的角色：

数据所有者（数据主人）
数据管理员（数据管家）
数据保管员（数据卫士）

注意，在现实中，上述数据治理角色中的任何一个，都很少对应于组织中的一个专门岗位。也就是说，上述角色与现实岗位并非一一对应。因为在多数情况下，企业并不会雇用一个人承担一个新岗位。而是利用现有的团队成员，来同时承担各种数据治理职责。

1）什么是数据所有者？

数据所有者：应对组织内一个或多个数据集的分级分类、保护、使用、质量，担负责任。此责任涉及的活动包括但不限于确保：

组织的数据词汇表是全面的，并得到所有干系人的同意；
建立了审计和报告数据质量的系统；
数据质量问题的上报矩阵已就位；
采取措施在规定的时间范围内解决数据质量问题。

大多数数据治理专家都认为，给定的数据集应该只有一个数据所有者。如果多个干系人都关注同一组数据，则应该指定其中一个人来担任数据所有者角色。

为履行上述职责，数据所有者需要：

有权在工作流、实践、基础设施方面进行任何必要的变更，以确保数据质量；
启动确保数据质量的措施的资源，例如数据清洗和数据审计。

实际上，这意味着必须将数据所有者角色分配给相对高级的人员，通常是企业高层管理人员。如果没有足够的权限和对资源的访问权限，数据所有者将无法有效地履行其职责，而这一缺陷会沿着整个数据治理链向下传递，从而使整个数据治理工作失败。

然而，大多数高级管理人员不一定了解有关数据集及其管理的更精细的技术细节。他们也几乎总是受到时间限制，这意味着他们无法实际实施数据治理所需的所有流程。这就需要数据管理员派上用场。

2）什么是数据管理员？

数据管理员：是对特定数据集有透彻了解的主题专家，负责确保数据的分级分类、保护、使用、质量，符合数据所有者设定的数据治理标准。一些组织也将此角色称为“数据质量管理员”。

注意，主题专家不一定具有IT背景。根据组织的数据和业务性质，主题专家可能具有业务、运营、IT、项目职能方面的经验。

典型情况下，数据所有者会任命一名数据管理员。当然，也可以根据组织及其数据的规模，任命多名数据管理员，来协助数据所有者执行组织的数据治理策略。

尽管数据管理员不拥有数据，但他们必须彻底理解这些数据被如何记录、存储、保护。

数据管理员还可以细分为四种不同类型：

业务(Business)数据管理员
运营(Operational)数据管理员
技术(Technical)数据管理员
项目(Project)数据管理员

列出的每一个角色，都反映了该角色在组织中的职能背景。当组织需要不同类型的数据管理员或多个相同类型的数据管理员来处理共同的数据集时，他们需要协同工作以确保有效的数据治理。

在许多情况下，数据管理员可能不一定具备管理数据存储、检索、格式化的专业知识。这又需要下一个角色：数据保管员。

3）什么是数据保管员？

数据保管员：负责实施和维护给定数据集的安全控制（包括对数据进行维护、归档、恢复、备份，防止数据泄露/损坏等）以满足数据所有者在数据治理框架中指定的要求。

数据保管员通常是IT部门的成员。通常在其专业领域进一步划分，例如：数据建模师、数据架构师、数据库管理员等。

数据治理角色之间的差异

与数据治理相关的不同角色的名称，存在很多混淆。

1）数据所有者 vs. 数据管理员

数据所有者和数据管理员之间有什么区别？

数据所有者对数据治理结果负责，以结果为导向；
数据管理员对具体的数据治理任务负责，以任务为导向。

例如，数据所有者可能对数据卓越指标负责，例如审计结果和质量分数。他们还可能对业务指标负责，例如数据治理对战略目标的影响。

相比之下，数据管理员可能负责确保数据治理清单上的所有项目都得到实施，并及时预防和解决实施中的问题。

企业组织是否同时需要数据所有者和数据管理员？这取决于企业的数据治理计划的规模和范围。大型组织很可能同时需要这两种角色；而在小型企业中，数据所有者和数据管理员可以是同一个人。

2）数据所有者 vs. 数据保管员

数据保管员通常是物理地或直接地处理数据集的存储和安全性的人员。但仅仅因为数据存储在某人控制的设备上，并不能使他们成为数据所有者。就像银行客户将钱存入银行时，仅仅因为钱存放在银行中，并不能使银行成为这笔钱的所有者。

数据所有者和数据保管员之间有什么区别？

数据所有者通常是担任高级业务角色的人员，负责一组或多组数据的分级分类、保护、使用、质量。
数据保管员通常是担任IT角色的人员，负责以符合组织数据治理策略的方式，维护一个或多个数据集的存储和安全基础设施。

在小型组织中，数据所有者和数据保管员的角色可能由同一个人担任。

3）数据管理员 vs. 数据保管员

数据管理员和数据保管员在数据治理中起着相互补充的作用。两者都被分配了一组他们负责的数据资产。

数据管理员和数据保管员的主要区别在于：数据保管员从技术角度对数据资产负责。数据管理员从业务角度对数据资产负责。

数据管理员：负责与一组数据资产相关的业务控制、数据内容和元数据管理。他们与受数据影响的干系人合作，制定定义、标准、数据控制。他们还可以支持数据质量、数据采集、数据输入计划。在许多情况下，使用相同数据的业务部门和运营部门对数据的看法并不相同。数据管理员是确保数据支持所有业务需求和法规要求的人。
数据保管员：负责数据的技术控制，包括安全性、可扩展性、配置管理、可用性、准确性、一致性、审计跟踪、备份和恢复、技术标准、策略和业务规则实施。

注意：在实际工作中，分配给这两种角色的，通常是个人，而非团队。

数据治理角色的真实示例

要了解数据管理在实践中如何发挥作用，让我们看一下这些角色在不同组织中的几个示例。

1）零售链中的数据管理

一家高端零售连锁店让顾客参与抽奖活动，需要顾客将名片放入位于每家店面的抽奖箱。通过提供顾客的个人数据并参加抽奖，顾客同意接收连锁店的营销电子邮件。

在这种情况下，自下而上开展数据管理：

数据创建者：一名后台员工收集并手动记录每个客户的数据，录入公司数据库。此人不是数据所有者、数据管理员、数据保管员，而只是数据创建者。
数据保管员：客户数据存储在云服务器上，IT管理员是数据保管员，必须确保数据安全且只有授权人员才能访问。
数据管理员：营销人员负责在电子邮件营销活动使用数据集之前清理和验证数据集。他被任命为数据管理员，负责通过数据治理策略规定的格式化、清洗、富化程序，来确保电子邮件营销数据的质量。
数据所有者。销售主管对销售目标负责，并且非常重视营销活动的成功。他被指定为该数据集的数据所有者，因为他处于高级职位，可以洞察组织的目标，并且拥有权力和资源来做出提高数据质量和安全性的决策（例如，通过执行身份验证保护措施以允许访问数据）。

2）制造企业中的数据管理

在这种情况下，自上而下开展数据管理：

数据所有者：在制造企业中，生产经理被指定为所有生产数据的数据所有者。

数据管理员：数据所有者任命了几个数据管理员：

生产数据管理员：生产轮班主管是材料使用、循环时间、零件输出数据的数据管理员；
维护数据管理员：维护工程师是机器性能、可用性、故障、维修时间等数据的数据管理员；
计划数据管理员：生产计划员是利用率和效率数据的数据管理员；
质量数据管理员：质量主管是缺陷和拒收数据的数据管理员。

数据保管员：这些数据被捕获并存储在本地服务器中，该服务器由组织的IT部门操作和管理，IT部门的一名员工被任命为数据保管员。

（本篇完）

阅读原文

跳转微信打开

安全的未来是上下文

Wed, 09 Mar 2022 05:30:00 +0800

原创柯善学 2022-03-09 05:30

Context (上下文) 和 Content (内容)

全文约6000字 13图表阅读约10分钟

VirusTotal称：“上下文是王道”。一位营销大师说：“如果内容（Content）为王，那么上下文（Context）就是上帝。”辩证地看，上下文和内容是既对立又统一的关系。两者相辅相成，还可以相互转化。

上下文是什么？有人认为是环境、语境、背景、情报，有人认为：低阶的上下文是属性（比如黑客组织的攻击特征和作案方式）；高阶的上下文是意图（比如黑客组织的攻击原因和战略目的）。非常明确的是，属性隶属于上下文的范畴。因此，ABAC（基于属性的访问控制）是上下文的典型应用。而零信任则将上下文发挥到极致。

本文最重要的工作是将零信任访问模型推演为零信任操作模型。零信任的重要特征是动态性（时间维度）和细粒度（空间维度），而这两种特征都完全依赖于上下文。既然零信任访问和上下文的关系如此密切，那么零信任操作与上下文的密切关系也是顺理成章的。如此一来，也就容易理解：不仅安全访问的未来是上下文，安全操作的未来也是上下文。

本文还梳理了上下文的各种类型（参见表6），如环境上下文、社区上下文、流程上下文、内容上下文、身份上下文、应用程序上下文、操作系统上下文、设备上下文、网络上下文。本文也梳理了获取各种类型上下文的方法和来源（参见表7）。这些对于上下文的实操，具有重要价值。

笔者的另一个断言：上下文的未来是图谱化。因为语义表达是上下文的最高境界，而知识图谱正是上下文的语义表达。笔者展示了几个网络安全领域的图谱（VirusTotal图谱、CrowdStrike威胁图谱、RecordedFuture安全情报图谱、Securiti个人数据图谱），作为趋势的证词。

笔者最终断言：安全的未来是安全云。大数据、图谱、云是阻止当今威胁的三个关键。三者合在一起，就是笔者所说的“安全云”。

目录

1.开门见山：Context（上下文）和 Content（内容）

2.进入正题：网络安全中的上下文感知

3.模型推演：从安全访问模型到安全操作模型

4.范式转变：信任度量需要实时上下文

5.五彩纷呈：安全上下文的类型和来源

6.展望未来：上下文的未来是图谱化

7.最终陈述：安全的未来是安全云

开门见山：Context（上下文）和 Content（内容）

Context（上下文）和 Content（内容）是一个有趣的话题。不妨看看几个有趣的对比：

图1-Context（上下文）和 Content（内容）

字形的对比。上图很有趣：图中的倒影并不是Context（上下文），而是Content（内容）。两者只有一个字母之差，但两者却是几乎对立的含义。

图2-上下文的意义/价值

上下文的价值。从上图可以看出，上下文（Context）分别赋予了数据（Data）、内容（Content）、信息（Information）以更多的意义和价值。正是在上下文的作用下，数据转化成内容，内容转化成信息，信息转化成知识。上下文（Context）和内容（Content）是既对立又统一的关系。两者相辅相成，还可以相互转化。

图3-内容离不开上下文

上下文的地位。微软创始人比尔·盖茨曾说过内容为王。营销大师Gary Vaynerchuk却说：“如果内容为王，那么上下文就是上帝。”

进入正题：网络安全中的上下文感知

1）上下文感知的含义

上下文（Context）是某事物存在或发生的环境/条件/情况/背景，可以帮助解释或理解该事物。这里的“某事物”也可以理解为上一节中的内容（Content）。

上下文感知安全，是在做出决策时使用补充性上下文信息，来改进安全决策。为了更快、更准确地评估某个给定的操作请求应该被允许还是拒绝，需要在做出安全决策时加入更多实时上下文信息。

2）上下文感知的示例

当今，所有网络安全领域都在向上下文感知基础设施转变。应用程序感知、身份感知、内容感知、流程感知、环境感知，都是向上下文感知转变的例子。

先看几个熟知的传统型转变：

网络级防火墙是最先转型的。下一代防火墙已经超越了传统的静态网络级属性（例如端口号或IP 地址），特别强调应用程序感知能力，也开始强调身份感知能力。
入侵防御系统 (IPS) ：下一代IPS系统不再将所有IPS规则应用于所有流量，而是使用实时上下文知识，包括工作负载正在运行的操作系统或应用程序的哪个版本，以及它们所保护的系统中存在哪些漏洞。这些上下文提高了IPS决策的速度和准确性，节省处理资源，减少误报率。
端点保护平台 (EPP) ：EPP的发展早已超越了传统的基于签名的白名单和黑名单方法，正在使用公开情报和社区声誉，来确定给定的可执行代码是否足够可信。
安全Web网关 (SWG) ：SWG的发展远远超越了传统的静态URL过滤，以在策略决策点处融合上下文信息，例如URL的信誉、源IP地址的位置和信誉等。同时也增强内容感知，以监控出站连接上的数据泄露。

再看几个流行的现代型转变：

网络准入控制 (NAC)：无论是用于访客网络、VPN访问、全网络访问，NAC解决方案会在允许工作站连接到企业网络之前，使用实时上下文信息，如对设备的“健康”评估（即零信任终端环境感知）。
身份和访问管理：身份验证在认证决策点融入了更多实时上下文，例如当事务上下文反映异常行为时，则需要更强的身份验证。
授权决策：授权决策也变得更加上下文化。超越了传统的RBAC（基于角色的访问控制）静态模型，积极向ABAC（基于属性的访问控制）的零信任架构转变。
数据保护：为了在整个数据生命周期和整个企业IT生态系统中充分保护敏感信息，策略执行点变得更加内容感知和身份感知，支持根据操作时确定的数据分级分类而动态应用策略。

下面，笔者将对这些上下文感知转型示例，进行归纳提升和模型推演，总结出一般性规律。

模型推演：从安全访问模型到安全操作模型

1）零信任访问模型

零信任访问的目的是：在不可信环境中，实现实体对资源的安全访问。它本质上是要做出一个安全访问决策：在当前的上下文中，主体能否访问客体？

笔者绘制了如下零信任访问模型：

图4-实体之间的安全访问模型

2）零信任操作模型

笔者将上述零信任思想推广到各种操作类型（而不仅仅只是访问这种操作），就可以得到下面的零信任安全操作模型：

图5-实体之间的安全操作模型

分层IT技术栈模型。在上图中，左右两侧的实体A和实体B，按照IT技术栈进行了分层，即网络、设备、操作系统 (OS)、应用程序、身份、内容、业务流程。在这种分层IT技术栈模型中，各个层级都包含其物理或逻辑实体（对象）——数据包、机器、应用程序、服务、用户、组、事务等。

安全操作决策：安全的本质是对操作的安全决策。结合上图来看，网络安全可以被视为一组安全决策的执行，以实现IT堆栈中不同实体之间的操作。如上图所示，当左侧任何层的实体A想要对右侧的实体B进行操作时，就会发生安全决策。例如：

网络通信：这个IP地址可以和另一个IP地址通信吗？这种类型的策略传统上由网络防火墙强制执行。
程序执行：这个用户可以加载并执行这个未知的应用程序吗？此类策略传统上由防病毒软件和应用程序白名单软件强制执行。
用户访问：此用户可以访问此内容吗？这种类型的策略传统上由访问控制机制强制执行。
输入验证：这个输入可以被这个应用程序接受吗？这种类型的策略传统上由应用程序防火墙（例如WAF或数据库防火墙）强制执行。

上下文感知。对应于图中的每一层，都有各层的上下文，通过感知各层的上下文，如应用程序感知、身份感知、内容感知、流程感知，可以将上下文添加到安全决策的输入中，从而做出更加正确的安全操作决策。

范式转变：信任度量需要实时上下文

1）基础设施转变：从静态IT基础设施转向动态IT基础设施

静态业务和IT基础设施。当业务和IT基础设施相当静态且明确时，企业拥有和控制图5中的大部分实体，所以网络安全策略执行点（如防火墙、邮件安全网关）通常只放置在企业拥有的东西（因此信任）和企业不拥有的东西（因此不信任）之间的分界点（边界）。

绝对信任模型。这种信任“我们”（我们拥有它并且控制它）而不信任“他们”（他们拥有它并且控制它）的安全模型，就是绝对信任模型。

动态业务和IT环境。业务和IT领域的多种融合趋势，正在打破传统静态IT基础设施和业务的边界，正在形成越来越动态的业务和IT环境：

移动化。意味着随时随地使用“可信度”不同的设备（并非都归企业所有）从不同地点访问企业的系统。
外部协作化。意味着向外界开放企业的 IT 系统。访问内部系统的外部用户会越来越多，甚至多于内部员工。
虚拟化。意味着工作负载和信息将不再与特定设备和固定IP地址绑定，从而打破基于物理属性的静态安全策略。
云计算。意味着企业不再拥有或控制保存和处理企业的工作负载和信息的基础设施或应用程序。
黑客产业化。意味着黑客从大规模攻击转向针对性攻击。导致企业对内部用户和系统的信任度降低。

绝对信任的丧失。在动态的业务和IT环境中，企业无法预测访问系统和内容的所有需求。试图预先确定所有可能的使用场景，并使用静态的、预定义的安全策略来执行它们，无法提供企业所需的扩展性和灵活性。在动态IT基础设施的世界中，绝对信任模型失败了。

2）安全范式转变：从绝对信任到信任度量

IT基础设施从静态向动态的转变，促使安全范式从绝对信任转向信任度量。与可以提前预先定义的非黑即白的二元静态决策不同，新兴IT环境中的安全决策难以明确定义和事前预知。IT技术栈的每个元素，都需要以一定程度的不确定性对待。绝对信任（即二元信任）将被“信任度量”范式所取代。

我们必须抛弃幻想的绝对信任（实际上我们从未真正拥有过这种信任），将转向一种信任度量的范式，即上下文感知的安全策略执行机制——它可帮助我们回答真正的问题：“我是否对相关实体有足够的信任，可以在我目前的风险承受能力水平和上下文中，执行所请求的操作？”

3）不可或缺：信任度量需要实时上下文

为了能够更快、更准确地度量信任级别，评估是否应该允许或拒绝给定的操作，我们必须在做出安全决策时纳入更多实时上下文信息。这是上下文感知安全的核心。

五彩纷呈：安全上下文的类型和来源

1）安全上下文的类型

除了经常使用的环境上下文（如位置和时间），还有多种类型的上下文信息，可用于改进安全决策。图5中显示的任何层，都可以为改进安全决策提供额外的上下文。下表罗列了各个层中的上下文示例：

表6-与安全决策相关的上下文示例

所有这些层——环境、社区、流程、内容、身份、应用程序、操作系统、设备和网络——都可以为它们下面的层中做出的实时安全决策，提供有用的上下文。例如，身份级别和应用程序级别的信息，可以为网络级别的防火墙决策提供额外的上下文。内容级信息可以为决定是否允许通过电子邮件发送文档提供额外的上下文。

2）安全上下文的来源

想用好上下文，除了知道有什么上下文，还要知道从哪里获取这些上下文。下表总结了一些常见上下文的来源（即获取方式）：

表7-上下文的类型和来源

展望未来：上下文的未来是图谱化

1）上下文的未来是图谱化

在安全世界中，威胁情报显然是上下文的重要组织部分（参见表7中的“威胁上下文”）。而在很多语境中，情报就是上下文。

笔者明确看到了主流安全情报产品的图谱化趋势，从而给出断言：（大规模）上下文的未来是图谱化。

图谱为何如此重要？因为图谱含有语义(语言有意义，容易被理解)，是最高层次的信息表达方式。图谱以类似人类大脑的方式，组织各种实体和上下文知识。对于海量信息中的知识探索和发现活动，图谱无疑是最值得期待的工具。图谱采取用图说话的可视化方法，将上下文的易用性提升到新的高度，为降低威胁调查、行为异常、隐私合规等安全技术的门槛提供了可能。

图谱的难度很大。也许有人会说：图谱的应用门槛没多高！但笔者想提醒的是：关系之中见精髓，规模之上见工夫。实体和关系的建模方式、规模量级、丰富程度，图谱的易用性、探索性、启发性，无不是横亘在图谱面前的巨大挑战。实际上，图谱与图论、本体论、自然语言处理、神经网络、人工智能等前沿理论关系紧密。

贫穷会限制想象力。要做好自己的图谱，还是应该先看看别家的图谱。

2）VirusTotal图谱

VirusTotal称：“上下文是王道（Context is king）”。可见其对上下文之重视。

VirusTotal认为：你不能仅仅依靠“一枚子弹”（即一个样本）或“一块拼板”（即你的本地数据），来与全球范围内的攻击者进行战斗。你需要有持续跟踪恶意活动的“整部电影”，必须有尽量完整的上下文。VirusTotal图谱（VirusTotal Graph）正是你的救星。

VirusTotal图谱充分利用各种实体的属性和关系，以可视化方式，浏览或搜索VirusTotal的海量数据集，高效执行安全事件和威胁的调查。如下图所示：

图8-VirusTotal图谱的调查示例

3）CrowdStrike威胁图谱

CrowdStrike将威胁图谱（Threat Graph）视为自己的云端安全大脑。CrowdStrike声称自己是第一个有目的地使用图数据库来实现网络安全的公司，并基于图数据库构建了威胁图谱。

正是利用了图数据模型，威胁图谱得以每天处理数十亿个事件，处理来自数百万个传感器的数据流，支持每秒50万个事件写入，并在纷繁复杂中快速发现威胁踪迹。

图9-CrowdStrike威胁图谱（Threat Graph）

4）RecordedFuture安全情报图谱

RecordedFuture称：安全情报图谱（Security Intelligence Graph）代表了RecordedFuture用来完成使命的方法论和专利技术。安全情报图谱用于指导人类分析师和算法的分析过程。

RecordedFuture安全情报图谱综合了各种各样的情报信息，如下图所示：

图10-RecordedFuture安全情报图谱的信息

安全情报图谱连接了数十亿个实体，通过本体和事件，映射网络安全领域中的各种复杂关系。如下图所示：

图11-RecordedFuture安全情报图谱的原理

5）Securiti 个人数据图谱（People Data Graph）

上面展示的都是威胁情报图谱，而Securiti构建了一个与身份和数据相关的图谱——个人数据图谱（PDG，People Data Graph）。

Securiti是一家数据安全和隐私保护公司，是RSAC 2020创新沙盒的冠军。PDG是Securiti实现现代隐私运营(PrivacyOps)框架的基础技术。

PDG可以跨系统地连接到云中和本地、结构化和非结构化的异构数据源，自动发现和构建个人数据与所有者之间的关系图谱，从而为隐私合规奠定了坚实基础。

图12-个人数据图谱（PDG）

最终陈述：安全的未来是安全云

安全的未来是（实时）上下文。上下文感知安全机制提供了安全策略的抽象和自动化层。上下文感知有助于使安全成为动态业务需求的推动因素，而不是阻碍因素。企业安全解决方案应该具备越来越强的上下文感知能力。

安全的未来在云端。如果安全的未来是上下文，得到的下一个推论就是：安全的未来在云端。因为孤岛式、分散式的上下文是非常低效的，也不具备共享和扩散的价值。安全上下文需要集中化、规模化、图谱化，而只有云化才能承载这样的要求。

安全的未来是SaaS化。如果安全的未来在云端，得到的下一个推论就是：安全的未来是SaaS化。虽然很多人都会争论说，SaaS只适合中小客户，并不适合大型客户。但笔者觉得，恰当的说法是：仅有SaaS，是不适合大型客户的。大型客户的最佳策略应该修正为：客户本地化安全建设+厂商云化安全服务（如图13所示）。

安全的未来是安全云。安全是要花钱的。我们不能平等地保护一切，我们所保护的一切也不是同等价值。网络安全预算不大可能以比整体IT预算更快的速度增长。预算和资源的限制，将迫使我们不断优化风险/回报比，并采取智能化的安全保护措施。这正是安全云的意义所在（如图13所示）。与其部署所有可能的安全控制措施，不如根据所请求操作的上下文（如受保护过程的重要性、所处理内容的敏感度、所涉及实体的信任度、客户的风险容忍度等），采取更加智能化的控制措施。不论称之为“基于信任”、“基于风险”、“基于度量”、“基于智能”的安全转型，上下文感知都是最关键的促成因素。

图13-CrowdStrike云化威胁图谱与纯本地化解决方案的成本比较

CrowdStrike称：“大数据、图谱、云是阻止当今威胁的三个关键。” 这三个关键，一个都不能少。而三者合在一起，就是CrowdStrike威胁图谱，也正是笔者所说的“安全云”。

（本篇完）

阅读原文

跳转微信打开

美国国防部Thunderdome零信任原型正式启动

Sun, 13 Feb 2022 17:38:00 +0800

原创柯善学 2022-02-13 17:38

这是DISA的一小步，也是DoD的一大步。

全文约4000字阅读约6分钟

2022年1月24日，美国国防信息系统局（DISA）向 Booz Allen Hamilton（以下简称BAH）授予了一份价值 680万美元的合同，用于执行Thunderdome原型。这是自2021年5月发布Thunderdome信息请求和7月发布方案白皮书请求（9月3日截止）以来，靴子终于落地的声音。

DISA称，Thunderdome是其最先进的零信任安全和网络架构。这个断言意味着安全和网络的融合，也就是SASE（安全访问服务边缘）架构。

我们知道，完美的SASE架构通常要求网络重构。通常而言，一般企业并不愿意进行网络重构，因为重构的成本和挑战都太大了。以至于著名咨询机构Forrester给出了基本策略：应该先从容易干的零信任下手，然后等到机会成熟了再去搞定难搞的网络重构。参见《戏说零信任和SASE——安全界的如来和大圣》。甚至DISA的Thunderdome项目经理兼边界安全部门负责人 Angela Landress 也承认：虽然SASE已在大部分商业世界中实施，但尚未被政府广泛采用。

那么，作为世界上规模最大、网络最为复杂的美国国防部，为什么会下定决心要做出网络重构这一决策呢？

我们先看看官方的解释。DISA副局长Chris Barnhurst在新闻稿中表示：向Thunderdome原型的迈进是“国防部向下一代网络安全和网络架构的重大转变”，该工作“从根本上改变了我们传统的以网络为中心的纵深防御安全模式转变为以数据保护为中心的模式。”

笔者觉得，这种官方解释只是说出了正确的废话，并未点明要害。笔者以为，美国国防部狠下决心要做网络重构的最关键原因，就是要建立下一代中间层安全。这是因为上一代中间层安全，即搞了十年的JRSS（联合区域安全栈），被批评为运行效率低下。关于中间层安全的含义，参见《用零信任替代中间层安全？》。

DISA的决心是如此之强，以至于DISA对Thunderdome的时间进度要求非常紧迫——只给了6个月时间！从1月24日算起，大概是到7月底。然后，再经过3至6个月的过渡期后，将于2023财年初开始进入生产阶段。Thunderdome是DISA的第一个零信任工作原型，该原型可能会在第四产业（含DISA）和海军开始实施，然后可扩展到整个国防部。

DISA最擅长的事情就是为美国国防部及其全球作战人员构建、测试、验证、实施一流的网络安全解决方案。对于Thunderdome的后续发展，让我们拭目以待。

关键词：DoD (美国国防部) ；DISA (国防信息系统局) ；BAH（Booz Allen Hamilton）；JRSS（联合区域安全栈）；SASE（安全访问服务边缘）；IDIQ(不定期限/不定数量)。

目录

1.DISA授予Thunderdome合同

2.Thunderdome的目标受众和推广策略

3.为何取名Thunderdome？

4.Thunderdome代表下一代网络和安全架构

5.中标者BAH是何来历

DISA授予Thunderdome合同

前期方案征集。DISA于2021年5月发布关于Thunderdome零信任方案的信息请求，又于2021年7月发布关于Thunderdome方案的白皮书请求，并于9月3日截止方案征集。关于Thunderdome方案白皮书请求的内容，可参见《美国国防部零信任实施方案：Thunderdome（雷霆穹顶）》。在8月中旬的时候，DISA已经收到了近60份Thunderdome白皮书提案。

当下合同授予。经过4个月之后，DISA于2022年1月24日向Booz Allen Hamilton（BAH）授予了一份价值680万美元的合同，用于执行Thunderdome原型。

图1-DISA官宣Thunderdome原型合同授予

注：图中的副标题是“Thunderdome将是DISA最先进的零信任安全和网络架构”。

合同周期是6个月。DISA的目标是在6个月内生产一个可在整个国防部扩展的工作原型。

后续推进计划。原型阶段（即Thunderdome原型合同）仅仅持续六个月，然后经过3至6个月的过渡期后，将于2023财年初开始生产。

Thunderdome的主要目标。DISA将通过利用SASE（安全访问服务边缘）和SD-WAN（软件定义广域网）等商业技术，测试如何实现DISA于2020年3月发布的国防部零信任参考架构（参见《DISA发布国防部零信任参考架构》）。DISA还想确定其初始零信任概念是否可以扩展到大规模的国防部企业，以及需要进行哪些调整来满足军事网络原则。

与美国联邦网络安全现代化工作保持一致。DISA的Thunderdome原型与美国联邦政府的多项网络安全现代化工作保持一致，实际上是针对这些政策或战略中的零信任要求，进行了呼应。包括：

美国总统关于改善国家网络安全的行政指令（即EO 14028）；
国防部首席信息官 (DOD CIO) 的数字现代化战略：参见《美国国防部将JIE升格为DMS（数字现代化战略）》；
DISA战略计划：参见《DISA战略计划2.0版抬升零信任地位》。

Thunderdome的目标受众和推广策略

Thunderdome的目标受众。最终目标是整个国防部，但先从所谓的第四产业机构开始。所谓“第四产业”，主要是指国防部内除了军种和情报机构之外的国防机构和外勤机构（DAFA），大概有二十多个机构，如国防部长办公室、联合参谋部、DISA、导弹防御局等。关于第四产业的具体范围，可参见《美国国防部IT改革的“皇冠宝石”：DES（国防飞地服务）》。Thunderdome项目的任务合作伙伴包括海军、陆军、空军。其中，海军将率先开始实施Thunderdome能力，因为他们表现出最大的兴趣。

为何Thunderdome要从第四产业开始？笔者推测有两个原因：一是第四产业可能是国防部中IT成熟度相对比较高的机构（与各作战部队相比），已经具备了标准化的前提条件；二是早期国防部首席信息官和DISA的联合审查，显示了第四产业“令人大开眼界的低效率”。较高的IT成熟度+极低的运行效率，使得第四产业成为Thunderdome的首个试验田。

Thunderdome不具有强制性。Thunderdome并非国防部的唯一零信任解决方案。DISA不打算强制国防部或军种使用Thunderdome方案。这意味着军种可以选择与DISA合作或实施自己的零信任方案。

DISA推广Thunderdome的策略。DISA的思路是让Thunderdome变得足够好，然后吸引各军事部门采用Thunderdome。DISA新兴技术部负责人Stephen Wallace（是DISA推行零信任理念的关键人物）表示：如果其它部门看到Thunderdome的价值，自然就会采用它；而如果其它部门想走自己的路，那也没关系。但DISA确实担心各走各的路，其中特别值得担心的就是由此导致的互操作性问题。

为何取名Thunderdome

Thunderdome的能力。Thunderdome共有七项能力，与国防部的七大零信任支柱相一致，包括用户、设备、网络、应用程序、数据、可见性与分析、自动化与编排。同时，Thunderdome具有显著的SASE(安全访问服务边缘)特征，包含SD-WAN(软件定义区域网络)功能。

图2-国防部零信任实施框架

笔者在之前的《美国国防部零信任实施方案：Thunderdome（雷霆穹顶）》中，揣测了Thunderdome的含义"雷霆穹顶"。

现在，笔者找到了准确的解释：Thunderdome的灵感来自于——从建筑学的角度来看，圆顶比传统建筑更轻、更快，也是最坚固的设计之一。因为圆顶可以均匀地支撑屋顶的重量，所以没有哪个点支撑整个负载或在压力下屈服。

DISA官员们表示，这恰好反映了Thunderdome想要实现的零信任状态，即其所包含的许多零信任概念，需要相互协同工作，为基于云的实现创建了一种强大、高效、架构合理的方法。

所以，笔者之前将其翻译为"雷霆穹顶"还是相对准确的。

Thunderdome代表下一代网络和安全架构

Thunderdome的价值究竟在哪里？以笔者看来，主要是以SASE取代JRSS，成为下一代网络和安全架构，也是下一代中间层安全。SASE架构既包含了网络与安全的融合，又需要对复杂网络的整体重构。这对于美国国防部而言，绝对是颠覆性的。

以SASE取代JRSS。笔者曾在2021年1月的微信《用零信任替代中间层安全？》中，以标题中的疑问号"?" 提出了这个替代性问题。但当时，笔者以为是用SDP(软件定义边界)来替代JRSS。直到2021年7月，DISA开始发布Thunderdome白皮书请求，明确以Thunderdome取代JRSS。笔者才确定，DISA是要以SASE来替代JRSS。之后，DISA积极制定国防部范围的战略，使得任务合作伙伴可以从当前的网络安全解决方案（如JRSS）过渡到Thunderdome或其他零信任方案。而为期6个月的Thunderdome原型设计，将产生从JRSS过渡到Thunderdome方案的整体实施战略。

何谓“中间层安全”？无论JRSS还是SASE，都是DISA口中的中间层安全。只不过，JRSS是上一代中间层安全，SASE是下一代中间层安全。JRSS可以参考《美军网络安全 | 第7篇：JIE（联合信息环境）启示和综述》中的JRSS章节。

超越纵深防御安全模型。DISA副局长Chris Barnhurst说，“ Thunderdome反映了国防部向下一代网络安全和网络架构的重大转变” “扎根于身份和增强的安全控制，Thunderdome 从根本上改变了我们传统的以网络为中心的纵深防御安全模型，以保护数据为中心，最终将通过采用零信任原则为国防部提供更安全的运行环境。”

SASE落地的挑战性不会太大。Thunderdome项目经理Angela Landress女士认为：由于SASE是一种成熟的商业能力，因此使其适应DISA的需求应该不会太具有挑战性。“但我们需要对其进行一些设计，以便将其与 ICAM（身份、凭证和访问管理）、虚拟安全栈、SD-WAN集成。我认为我们将找到一些真正创新的解决方案，以在像 DISA这样的复杂网络上实施SASE。”

互操作性可能是最大的挑战。但DISA会直面该挑战，在一开始而非最终，就努力找出解决此问题的方法。为了帮助缓解这种挑战，DISA打算鼓励使用一套通用的标准、协议、分类法，以便将一切联系在一起，并与DISA的任务合作伙伴（即海、陆、空军）无缝合作。

中标者BAH是何来历

由于并未透露其它的投标方，也没透露任何投标方案，所以没法知道DISA为何选择BAH。笔者只能查阅BAH的官网资料，来寻找端倪。

BAH公司成立于1914年。BAH是一家领先的专业服务公司，在管理、技术、咨询、工程领域提供广泛的服务和解决方案。100多年来，军方、政府、商界领袖都求助于BAH来帮助组织进行转型，解决他们最复杂的问题。

截至2021年12月31日，BAH的全球总部位于美国弗吉尼亚州麦克莱恩，在全球拥有约 29,500 名员工。截至2021年3月31日的12个月收入为 79 亿美元。要了解更多信息，请访问 www.boozallen.com。（纽约证券交易所代码：BAH）

BAH支持美国国防部的历史悠久，自1940年公司赢得第一份海军合同以来，这一历史已超过 75 年。

作为美国国防部 (DOD) 的首要数字集成商，BAH将数十年的任务经验与最先进的人工智能/机器学习 (AI/ML)、下一代数据解决方案、网络、网络空间、高级软件开发相结合，提供了卓越的交付能力。

BAH近三分之一的专家是退伍军人，再加上数十年为军队提供服务的经验，可以确保其解决方案在现实中有效——而不仅仅是在实验室中。

BAH正在加速创新以帮助保卫国家（如下图所示）：

加速决策优势；
赋能未来战士；
推动国防未来。

笔者还在BAH官网上查到了一些亿美元级别的军方合同：

2016年，BAH被美国国防部 (DoD) 评选为一份为期5年、价值50亿美元的IDIQ(不定期限/不定数量)合同的主要获奖者，该合同专注于网络安全和信息系统支持。
2018年，BAH获得DISA授予的一份为期10年、价值175亿美元的IDIQ合同，以提供信息和通信系统IT解决方案。
2018年，BAH获得美国陆军工程兵团授予的一份为期10年、价值9亿美元的IDIQ合同，为国防部联合测试和评估计划(JT&E)提供技术支持。
2020年，BAH获得美国总务管理局 (GSA) 和美国国防部授予的一份为期5年、价值8亿美元的合同，为美国国防部的联合人工智能中心(JAIC)提供人工智能（AI）服务。
2020年，BAH成为美国空军授予的一份价值9.5亿美元的IDIQ合同的几个获奖者之一，以支持高级战斗管理系统(ABMS)的开发，从而实现国防部联合全域指挥与控制 (JADC2) 。

令人意外的是，最近被授予的Thunderdome原型合同，未能在BAH官网上查到。或许是680万美元的金额对BAH而言还不够大吧。

（本篇完）

阅读原文

跳转微信打开

《美国联邦政府零信任战略》正式版发布

Fri, 28 Jan 2022 06:08:00 +0800

原创柯善学 2022-01-28 06:08

春节前的问候

全文约3000字阅读约8分钟

2022年1月26日，美国管理和预算办公室（OMB）发布《联邦政府零信任战略》（Federal Zero Trust Strategy）正式版。这是继2021年9月7日发布《联邦政府零信任战略》草案之后的重要进展。

联邦政府零信任战略以备忘录的方式发布，备忘录的全称是：OMB M-22-09 《推动美国政府走向零信任网络安全原则》（Moving the U.S. Government Toward Zero Trust Cybersecurity Principles）。

在之前的微信文章《美国联邦政府零信任战略》中，笔者已经概述了《联邦政府零信任战略》草案的内容要点。本文中，则主要对两个版本的目录结构进行了对比，解释了几个重要的变化，并展示了最大的变化——任务矩阵（Task Matrix）。该任务矩阵对各个政府机构实施零信任的具体行动做出了计划安排，体现了真正的推动力。

本文件的PDF文档有29页，译文大概2万字。原文链接：

https://zerotrust.cyber.gov/federal-zero-trust-strategy/

关键词：OMB（管理和预算办公室）；CISA（网络安全和基础设施安全局）；GSA（总务管理局）；MFA（多因素认证）；

目录

1.目录对比

2.内容差异

3.任务矩阵

图1-《联邦政府零信任战略》（Federal Zero Trust Strategy）正式版发布的网站截图

目录对比

以下是两个版本的目录。笔者分别使用蓝色和绿色，标记了草案目录和正式版目录的主要区别：

草案目录：

1. 概述

2. 目的

3. 目标

3.1 身份

3.1.1 愿景

3.1.2 行动

1. 企业范围的身份

2. 多因素认证，抵御网络钓鱼

3. 面向公众的身份验证

4. 使用强口令策略

3.2 设备

3.2.1 愿景

3.2.2 行动

1. 盘点资产

2. 政府范围的EDR（端点检测和响应）

3.3 网络

3.3.1 愿景

3.3.2 行动

1. 加密 DNS 流量

2. 加密 HTTP 流量

3. 加密电子邮件流量

4. 围绕应用程序，分段网络

3.4 应用

3.4.1 愿景

3.4.2 行动

1. 应用安全测试

2. 容易获得的第三方测试

3. 欢迎应用漏洞报告

4. 安全地使应用程序可访问互联网

5. 发现可上网的应用程序

3.5 数据

3.5.1 愿景

3.5.2 行动

1. 联邦数据安全策略

2. 自动化安全响应

3. 审计对云中敏感数据的访问

4. 及时获取日志

附录. 参考资料

正式版目录：

1. 概述

2. 执行摘要

3. 行动

3.1 身份

3.1.1 愿景

3.1.2 行动

1. 企业范围的身份系统

2. 多因素认证

3. 用户授权

3.2 设备

3.2.1 愿景

3.2.1 行动

1. 盘点资产

2. 政府范围的EDR（端点检测和响应）

3.3 网络

3.3.1 愿景

3.3.1 行动

1. 网络可见性和攻击面

2. 加密 DNS 流量

3. 加密 HTTP 流量

4. 加密电子邮件流量

5. 企业范围的架构和隔离策略

3.4 应用和工作负载

3.4.1 愿景

3.4.1 行动

1. 应用安全测试

2. 容易获得的第三方测试

3. 欢迎应用漏洞报告

4. 安全地使应用程序可访问互联网

5. 发现可访问 Internet 的应用程序

6. 不可变的工作负载

3.5 数据

3.5.1 愿景

3.5.1 行动

1. 联邦数据安全策略

2. 自动化安全响应

3. 审核对云中敏感数据的访问

4. 及时获取日志

3.6 OMB 政策对齐

1. OMB M-21-07：IPv6 和零信任

2. OMB M-19-17：PIV 和非 PIV 身份验证器

3. OMB M-19-26 和 OMB M-21-31：网络检查的替代方案

4. OMB M-15-13：用于内部连接的HTTPS

附录A. 参考资料

附录B. 任务矩阵（Task Matrix）

内容差异

经过对比，主要的发现是：

目录级别的差异并不大：差异反映在蓝色和绿色标记的地方；
文字级别有大量的变化：尽管如此，但很多的文字变化，要么是改变了描述方式，要么是移动了位置，并无实质性的变化。

总体上看，两个版本的差别并不大。比较显著的变化包括：

1）在身份支柱方面，草案中一再强调的单点登录（SSO），在正式版中被完全抹除。比如草案中的要求"机构必须为机构用户建立单点登录 (SSO) 服务"，在正式版中被替换成"机构必须为机构用户采用集中式身份管理系统"。

2）在身份支柱方面，正式版中增加了用户授权要求。指出目前联邦政府中的许多授权模型都侧重于RBAC（基于角色的访问控制），应该采取RBAC与ABAC（基于属性的访问控制）相结合的方式。

3）在网络支柱方面，正式版中增加了关于网络可见性和攻击面的讨论。强调了权衡网络流量监控深度的观点：即随着零信任的普遍实施，大量流量将被加密。那么，对加密流量执行解密和检查，应该被限制在最低限度。而深度流量检查更适合保护敏感数据并具有少量预期网络客户端的应用程序环境。

4）在应用和工作负载支柱方面，正式版中增加了不可变工作负载的内容。强调基于云的自动化、不可变部署方式，由于具有天然的最小权限特性，可以很好地支持零信任目标。所以，机构在部署服务时，应努力采用不可变的工作负载。

5）正式版中增加了任务矩阵（Task Matrix）。在下面进一步描述。

任务矩阵

正式版附录B中的任务矩阵如下：

部分	任务	机构行动时间表（最后期限自本备忘录发布日期起）
全体	各机构必须向OMB和CISA提交一份22-24财年的实施计划，供OMB批准，并提交一份23-24财年的预算估算。	60天内。
身份	机构必须为机构用户使用集中的身份管理系统，这些系统可以集成到应用程序和通用平台中。	纳入机构实施计划。
身份	机构必须要求其用户使用防网络钓鱼方法，来访问机构托管的帐户。	纳入机构实施计划。
身份	支持MFA的面向公众的机构系统，必须允许用户选择使用防钓鱼认证。	一年之内。
身份	机构必须从所有系统中删除要求特殊字符和定期口令轮换的口令策略。	一年之内。
身份	机构授权系统应将至少一个设备级信号与认证用户的身份信息结合起来。	纳入机构实施计划。
设备	各机构必须建立持续、可靠和完整的资产清单，包括利用CDM项目。	纳入机构实施计划。
设备	各机构必须确保其EDR工具符合CISA的技术要求，并在其机构内部署和运行。	见M-22-01。
设备	各机构必须与CISA合作，以识别差距，协调部署，并与CISA建立信息共享能力，如M-22-01中所述。	见M-22-01。
网络	在技术支持的任何地方，机构都必须使用加密的DNS，解析DNS查询。	纳入机构实施计划。
网络	机构必须对所有生产HTTP流量，强制执行经过身份验证的HTTPS，包括不穿越公共互联网的流量。	纳入机构实施计划。
网络	各机构必须与CISA的DotGov项目合作，在web浏览器中以仅HTTPS的形式“预加载”机构所有的.gov域名。	纳入机构实施计划。
网络	各机构必须与CISA协商，制定零信任架构计划，描述机构计划如何隔离其应用程序和环境，并将其纳入本备忘录要求的全面实施和投资计划。	纳入机构实施计划。
应用程序和工作负载	机构系统授权过程必须采用自动分析工具和手动专家分析。	纳入机构实施计划。
应用程序和工作负载	机构必须欢迎其互联网接入系统的外部漏洞报告。	2022年9月，与OMB M-20-32和BOD 20-01保持一致。
应用程序和工作负载	机构必须选择至少一个需要认证且目前无法通过互联网访问的FISMA中级系统，并安全地允许其在互联网上进行全功能运行。	一年之内。
应用程序和工作负载	各机构必须开始向CISA和GSA提供其互联网可访问信息系统使用的任何.gov主机名。	60天内。
应用程序和工作负载	机构在部署服务时，尤其是在基于云的基础设施中，应该努力使用不可变工作负载。	纳入机构实施计划。
数据	机构首席数据官必须与关键机构利益干系人合作，为其企业内的敏感电子文档制定一套初始分级分类，目的是自动监控并可以限制这些文档的共享方式。	120天内。

该矩阵的重要性在于，它高度浓缩了美国联邦政府对零信任的5个支柱（身份、设备、网络、应用和负载、数据）的具体要求，同时做出了明确的时间进度安排，具有实实在在的推动力。

其中，最重要的一条是：各机构必须在60天内，提交一份22-24财年的零信任实施计划和一份23-24财年的零信任预算估算。

另外，在身份方面，比较有趣的一点是：口令策略不得要求使用特殊字符或定期轮换。

之所以会提出这个要求，是因为美国研究人员在关于密码过期策略影响的定量研究论文中，发现定期轮换口令极度影响用户体验，但又不能切实提高口令安全性。

作为每隔几个月就被逼迫修改系统登录口令的切实感受者，笔者深深地赞同这一点。

（本篇完）

阅读原文

跳转微信打开

CrowdStrike：零摩擦，零信任

Fri, 31 Dec 2021 00:06:00 +0800

原创柯善学 2021-12-31 00:06

我为何与众不同

全文约4800字 9图表阅读约10分钟

CrowdStrike已经在向零信任快速挺进。

CrowdStrike占据全球网络安全公司市值排行榜的首位，已经有相当长一段时间了。作为一家以终端安全打天下、以安全云服务立天下、上市一年半即市值第一的安全公司，其传奇发展令人着迷。

CrowdStrike的特点是永远在创新。而本文要谈的即是它在零信任领域的思路和布局。

如果广泛阅读国外的零信任宣传资料，会经常看到"摩擦"(Friction)这个词。意思是指：零信任通常会让用户感到不舒服。至少有两方面原因：一是零信任的使用会体验不佳、令人不爽；二是零信任的落地会阻碍重重、倍感挫折。

所以，CrowdStrike的目标是努力构建一个零摩擦（无摩擦）的零信任。

在本文的最后一节（为何与众不同）中，笔者梳理总结了CrowdStrike近年来的主要发力点，包括零信任、数据安全、XDR、新一代日志管理。再一次为其颠覆式创新能力所折服。

对于想模仿CrowdStrike的公司，需要回答一个问题：是否具有类似CrowdStrike的基因，包括端点基因、颠覆基因、创新基因。因为基因难以被模仿。

目录

1.向零信任进军

2.零信任的支柱

3.以三段论实现零信任支柱

4.零摩擦的零信任方法

5.零信任的下一步：数据安全

6.为何与众不同

1）CrowdStrike产品能力图变迁

2）CrowdStrike主要收购活动

3）CrowdStrike发展思路洞察

向零信任进军

在Crowdstrike看来，无论企业的动机是业务转型还是降低风险，零信任策略都是实现企业目标的最佳和最安全的途径，而保护身份存储则是零信任策略的关键。

2020年9月，Crowdstrike收购Preempt Security，后者是零信任访问技术的提供商。Crowdstike 为该公司支付了9600万美元。CrowdStrike首席执行官George Kurtz 解释说，“在完成了第二轮‘百天百个’客户之旅（我在100天内会见了100名客户和潜在客户）后，我明确地听到，企业正在寻找一种现代化的以身份和工作负载为中心的零信任安全战略，以奠定他们的安全转型基础。”

与Preempt的产品融合之后，Crowdstrike推出了新的身份保护平台——Falcon Identity Protection（猎鹰身份保护），用于保护员工身份，可以帮助企业实现零摩擦的零信任。

由于80%的成功入侵都涉及失陷凭据，Falcon Identity Protection将身份威胁检测和对本地和云身份的条件访问统一起来。通过使用身份、行为、风险分析，得以跟威胁抢占先机，从而保护400多家企业的400多万个身份。

零信任的支柱

采用零信任策略来确保员工身份安全的组织，应通过六个支柱（身份（用户）、端点（设备）、网络、应用程序/工作负载、自动化、分析）来实现统一的可见性、检测、执行。

图1-CrowdStrike零信任安全模型的六大支柱

关于零信任的支柱，之前已经介绍过多次，不再赘述。这里仅解释下CrowdStrike六大支柱与下面的Forrester零信任七大支柱（下图）的区别：

Forrester将数据作为零信任的一大支柱；
CrowdStrike将数据和身份作为基础支撑层，分别体现零信任是以数据为中心和以身份为中心的安全模型。

以笔者的观点看：之所以CrowdStrike将身份作为零信任的基础支撑层，意味着CrowdStrike在零信任领域的技术路线是IAM；之所以CrowdStrike没有把数据作为一大支柱，则可能是由于其还未涉足数据安全领域。

图2-Forrester零信任扩展生态系统的七大支柱

以三段论实现零信任支柱

为了创建一个完整零信任安全栈，需要实现上面提到的零信任6大支柱，这显然既昂贵又复杂。市面上已经有针对其中一/两个支柱的单点化解决方案，但是在实施时，不同的方案可能不会很好地集成在一起。

Falcon Identity Protection提供了一个集中化解决方案，该解决方案通过动态身份风险评估来控制身份访问，以防止穿越网络的横向移动。同时，它提供了一种灵活的认证方法，为最终用户带来零摩擦的使用体验。

图3-CrowdStrike零信任三段论

如上图所示，通过"分段-自动化-验证"（图中内环）三段论，实现了零信任六大支柱（图中外环）。

1）分段（Segment）

在零信任模型中，分段是降低风险的关键因素。通过身份分段，可以抑制大部分入侵的横向移动。企业需要将用户帐户（员工、承包商、远程工作人员，甚至特权用户）和端点都分段为微分段。

所有数据源和计算服务都被视为资源：笔记本电脑、台式机、物理服务器、虚拟机等实体，都被视为资源。所有这些端点都与用户（人员账户或服务账户）相关联。

2）自动化（Automate）

零信任不能依靠人工方式，来审核用户行为模式并判断他们是否可疑。安全需要自动化和智能化，以在每个事务上尽可能多地接收数据，从而发现模式、意图、异常、事件。

零信任方案通过专有的人工智能和机器学习（AI/ML）能力，来评估用户的信任等级。也可以从人类分析师的调查诊断中进行学习。

对资源的访问由动态策略决定。动态策略包括客户端身份、应用程序、请求资产的可观察状态，也可以包括其他行为属性，如100多种行为模式。

3）验证（Verify）

验证模型包括针对模式和已知行动的验证，以及针对凭证健康和行为分析的验证。零信任意味着动态验证和建立常态，从而使异常更迅速地显现出来。

为了确保无摩擦的用户体验，仅在风险增加时才触发MFA。绝不会为具有相同源和目标的常规任务添加持续的重新认证而降低业务速度。

零信任系统提供了一个90天窗口基线，在该时间窗口中，系统将持续学习和调整基线，以改进认证策略、策略创建和执行。

零摩擦的零信任方法

零信任的成功，可以通过三种方式来衡量：

员工体验：跨组织中的所有通道和触点，提供一致或更优的用户体验；
运营效率：在时间、人力资源、资金方面，简化运营、降低风险、降低开销的推动力；
风险降低：持续跟踪并获得风险评分的改善。通过降低风险，帮助企业回归核心业务。

CrowdStrike的零摩擦零信任方法，正是为了帮助客户取得零信任的成功。

图4-CrowdStrike零信任部署模型

1）基于风险的条件访问（上图中蓝色能力模块）

风险是一个不断变化的分值。当用户加入或者改变角色和团队时，他们的行为和访问需求就会发生变化。零信任系统对用户及其行为以及会话和端点的质量进行用户建模，从多个来源提取多种数据，为组织中的每个用户创建风险评分。

在一天或一个会话中多次进行登录/认证挑战，必然会影响用户体验。为了提供零摩擦的用户体验，零信任系统收集用户模式数据，并通过行为变化或异常检测来评估实际风险。零信任系统收集每个请求的上下文，以将该活动与该用户/组的活动基线进行比较。

基于风险的条件访问，可以检测和阻止沿着MITRE ATT&CK杀伤链的凭据和身份存储上的复杂威胁，例如权限提升（凭证喷洒、暴力破解、泄露口令）、横向移动（PowerShell、传递散列（PtH）、Golden Ticket、RDP）、NTLM中继攻击等。

当存在可疑或恶意活动时，零信任系统将hold住访问请求。基于自适应策略，可以在任何网络资源（包括PowerShell、RDP、文件夹等）上，使用MFA、电子邮件、短信、阻止或警报的各种实时机制，来质询用户。

2）零信任检测引擎

Falcon零信任检测引擎既包括静态规则（基于已知的攻击模式和特征码），也包括异常检测算法（可检测复杂的攻击）。综合多种检测模型，就可以检测出各种类型的恶意活动，如特权提升、横向移动、地理异常等。

图5-零信任检测引擎的规则配置

3）零信任的实施

实施速度快。零信任系统可以很快建立起来，管理的部署和数据的收集工作，可在半天内完成。而价值实现的时间，取决于进行身份存储普查的时间，包括普查用户、特权用户、影子用户、服务帐户，以及它们各自的弱点或不足。

认证集成广。零信任系统与几乎所有主流MFA供应商合作（包括但不限于Duo、Azure MFA、RSA SecurID、CA、Symantec、Okta等），扩展到云端和本地资源，甚至是遗留系统，而不会造成用户的口令疲劳。通过为所有SSO供应商提供插件，该解决方案允许客户选择认证，为SSO活动提供完全可见性、风险和威胁检测，而不需要端点代理。

安全集成广。零信任系统可与现有的安全方案集成，以增加风险评分和实时信息，使得整体安全方案更加智能。零信任系统还为一些主要的SOAR（安全协调、自动化和响应）供应商和SIEM系统提供了插件——提供有关任何IP和设备、与之相关的用户帐户以及已知威胁的详细上下文信息。对于经验丰富的SIEM或SOC分析师，零信任系统提供CEF和LEEF格式的API，来帮助构建感兴趣的规则和事件。

零信任的下一步：数据安全

值得注意的是，CrowdStrike似乎没有谈及数据安全。因此，虽然CrowdStrike已经吸收了主体侧身份零信任的概念，但还没有涉及到客体侧数据零信任的领域。如果你问两者有何不同，请参见《数据安全保护和治理的新方法》。既然身份侧的零信任会有如此多的摩擦，那么数据侧的零信任毫无疑问会有更多的摩擦。

正当笔者自以为是地认为发现了CrowdStrike产品布局缺项的时候，好在谨慎地浏览了一遍CrowdStrike的Blog（博客），竟然发现：他刚刚进行了数据安全的布局！在2021年11月1日对外官宣，收购SecureCircle公司，以进军端点数据安全领域。

CrowdStrike认为：多年来数据保护市场几乎没有创新，而DLP(数据防泄漏)已经被证明是失败的技术。DLP解决方案的不足在于，它们仅在数据离开端点时并且仅在由一组复杂的预配置规则和行为参数触发时，才会阻止或加密数据。而攻击者很清楚 DLP 的弱点，并不断改进他们的技巧，以构建特定的恶意软件和勒索软件。DLP已经无效！我们需要一种新模型来实现无摩擦的数据保护。

在吸收SecureCircle的技术之后，CrowdStrike 将可实现数据保护的现代化，将零摩擦的零信任，扩展为零摩擦的数据安全。从而使其客户能够同时在设备级别、身份级别、数据级别的不同级别，实现零信任。而所有这一切，都是通过端点上的 CrowdStrike 轻量级代理提供！这也再一次表明，端点就是一切！

为何与众不同

1）CrowdStrike产品能力图变迁

笔者积攒了CrowdStrike近两年来的产品能力图，以观察其发展思路：

图6-CrowdStrike Falcon端点保护平台（2020版）

图7-CrowdStrike产品能力（2021年4月版）

注：此图中，以绿色标记了相对于2020版的重大变化：增加了云安全领域和身份保护（零信任）领域。

图8-CrowdStrike产品能力（2021年12月版）

注：此图中，以黄色圆圈标记了相对于2021年4月版的主要变化：增加了端点安全中的XDR；增加了HUMIO（日志管理）+HUMIO数据库；增加了FUSION（自动化编排）。

2）CrowdStrike主要收购活动

接下来，按图索骥，查阅Crowdstrike官网新闻，梳理Crowdstrike自2019年上市以来的相关事件：

2019年6月，Crowdstrike上市；
2020年9月，CrowdStrike宣布收购Preempt Security，增强零信任安全能力；
2021年2月，CrowdStrike 宣布收购 Humio，为下一代无索引 XDR 提供业界最先进的数据平台；
2021年10月，CrowdStrike宣布推出首创的 XDR 模块，以在整个安全栈中提供实时检测和自动响应；
2021年10月，CrowdStrike宣布推出 Fusion自动化工作流解决方案，以实现SOAR (安全编排、自动化和响应) 框架；
2021年11月，CrowdStrike 宣布收购 SecureCircle，以实施零信任数据保护。

3）CrowdStrike发展思路洞察

综合上述信息，笔者从中得出了两方面结论：

关于零信任，CrowdStrike的发展思路是：

与零信任厂商（Zscaler、Illumio、Okta等）合作，推出联合零信任方案；
通过收购Preempt，弥补零信任身份安全；
通过收购SecureCircle，弥补零信任数据安全；
通过这两个收购，完成了对零信任领域的整体布局。

关于XDR，CrowdStrike的发展思路是：

EPP->EDR->XDR；
创造威胁图谱，增强威胁关联能力；
收购Humio，增强日志管理能力；
推出Fusion，增加安全自动化编排能力。

其中，CrowdStrike威胁图谱（Threat Graph）被誉为CrowdStrike的云中大脑。它出现在图6-8的基础平台层中，之前在《CrowdStrike | 无文件攻击白皮书》中简单介绍过，不再赘述。

最后，隆重介绍一下日志管理平台Humio。这个平台是在2021年收购的。从图8中可以看出，它的地位与威胁图谱并列，所以也是非常重要的基础平台。Humio被誉为下一代日志管理系统。其颠覆之处在于：

无索引架构。众所周知，为了执行大规模搜索，传统的日志管理系统会在数据被摄取时编制索引。而Humio最大的颠覆性就在于：它是一种无索引的架构！
超强存储能力。借助 Humio 的高级压缩能力，其存储的数据量是传统基于索引的日志解决方案的 5-15 倍（或更多）。
秒级搜索PB级数据。Humio 使用智能过滤和高级压缩来减少数据集，然后将所有数据加载到内存中，使得暴力搜索速度更快，从而在一秒内搜索 1 PB 数据并获得结果！
记录一切。SIEM或传统日志管理产品通常只是跟踪预先选择的数据（因为其摄取和存储所有日志的成本高得惊人），从而在监控中留下盲点。而一旦有了 Humio，企业不再被迫做出关于记录哪些数据以及保留多长时间的艰难决定。通过记录所有内容，Humio 客户可以获得实时检测和响应任何事件所需的完整可见性。
成就XDR。Humio 彻底解决了 XDR 的大数据挑战。如果没有新一代日志管理能力，将无法支撑XDR所需的大数据能力。

图9-为什么无索引架构可以这么快

CrowdStrike 一直在创造一种创新性的文化。颠覆是这家公司的底线。

（本篇完）

阅读原文

跳转微信打开

数据安全保护和治理的新方法

Sun, 28 Nov 2021 14:43:00 +0800

原创柯善学 2021-11-28 14:43

零信任是数据访问控制的必杀技

秉持数据驱动战略的数据驱动型组织，正在利用数据，以前所未有的速度开创未来。同时，也面临日益增长的安全、隐私、合规风险。

在过去几十年中，保护敏感数据的现有方法是孤立地建立起来的，缺乏整体性。考虑到各组织正在越来越严格的隐私法规下处理比以往任何时候都多的数据，寻求一种新方法是极为必要的。

当今，数据访问控制的所谓“最佳实践”，是创建一个明确定义的可访问数据列表，并在此基础上制定权限。然而，不幸的是，一旦考虑到现实世界的企业数据挑战，这根本不可行。

一个好的数据保护和数据治理解决方案，必须能够实现正常的数据访问，而不是中断或产生负面影响。而一个伟大的解决方案，将使数据访问比以前更容易、更高效、更广泛。

数据访问控制是零信任的最后环节和终极目标。基于零信任的数据访问控制，必将成为数据安全保护和治理的新方法。

目录

1. 背景：数据驱动战略与DataSecOps

1）数据驱动战略与数据驱动型组织

2）数据民主化与DataOps

3）数据安全与DataSecOps

2. 数据安全保护为什么这么难

1）数据的规模化治理难题

2）为什么数据分级分类很难

3）仅凭日志是远远不够的

4）数据存取方式的演变

5）难以设置的访问权限

6）新法规要求组织重新思考其数据战略

3. 保护敏感数据的现有方法

1）数据编目与分级分类

2）访问控制和权限管理

3）掩蔽、加密、符号化

4. 数据安全保护和治理的新方法

1）执行动态和细粒度数据访问控制

2）为数据访问添加上下文

3）建立分离的数据访问安全层

4）持续的敏感数据发现和分级分类

5）在数据源头保护数据

6）开展持续的权限治理

7）可在现有环境中部署

5. 示例：Satori数据访问平台

6. 总结：数据安全新方法与零信任的关系

1）数据安全新方法彻底贯彻了零信任思想

2）零信任是以数据为中心的安全架构

3）美国国防部将零信任应用于数据安全

4）数据访问控制与零信任的区别

背景：数据驱动战略与DataSecOps

1）数据驱动战略与数据驱动型组织

数据是一切的中心。数据的创建、存储、使用，是形成竞争优势和创新的引擎。由于云数据存储和访问技术的飞跃，在很大程度上使数据成为一种战略资产。

数据驱动战略已经彻底改变了企业的运营方式，并为那些正确利用它的人带来了惊人的增长。实施数据驱动战略，成为帮助企业进入数字化转型下一阶段的关键。

数据驱动型组织，即坚持数据驱动战略的组织，尤其是金融科技和健康科技等受监管行业的组织，开始越来越关注数据湖和数据仓库中日益增长的安全性和合规性挑战。

图1-数据驱动型组织的竞争优势

2）数据民主化与DataOps

数据民主化。为了让组织充分利用数据，数据必须是可发现和可访问的。数据民主化意味着更多的人能够访问更多的数据。但直到最近，人们还认为数据最好是分开保存，只有少数人能够很好地理解数据并使用它。为了从这些过时的方法过渡到现代方法，人们必须提升对数据的认知。

DataOps是数据民主化的基石。DevOps致力于成为现代应用程序开发的更好框架。而DataOps用于描述在运营动态数据环境的组织中处理数据的方式。

图2-DevOps与DataOps

3）数据安全与DataSecOps

组织正在生成、存储、分析前所未有的数据量，同时还需要比以往更广泛、更高效的数据访问。然而，更多的数据、更多的访问、更多的监管，代表着日益增长的安全、隐私、合规风险。

正如DevOps向DevSecOps的演进，DataOps向DataSecOps的演进，也是一种必然。DataSecOps 是组织将安全视为其数据运营的一部分的方式的演变。DataSecOps是一种敏捷、整体、安全的嵌入式方法，用于协调不断变化的数据及其用户，旨在提供快速的数据转化价值，同时保持数据的私密性、安全性和良好的治理。DataSecOps应该被视为数据民主化进程的推动者。

数据驱动战略呼唤新一代数据安全方案。我们需要一种新的方法，它依赖于完整的数据流可见性、策略执行、丰富的数据访问上下文，并且可以扩展以满足当今和未来的需求。

数据安全保护为什么这么难

1）数据的规模化治理难题

云让企业能够比以往更轻松地构建大型计算和存储基础设施。很多情况下，云存储运营的新定价模型基于查询/访问而非存储量。这直接导致，几乎所有拥有在线业务的公司，都以一条阻力最小的路径，快速建立了一个PB级数据存储。

而这又进一步导致，这些平台中的数据保护和数据治理，必须以大规模方式进行。而数据治理的所有一切，从发现和分级分类，到访问控制和安全，再到策略和审计，都需要重新发明，以应对存储的海量数据及其生成和使用的速度。

2）为什么数据分级分类很难

敏感数据分级分类的重要性毋庸置疑，但数据分级分类真地很难：

数据是一个移动的目标。在许多情况下，数据不是先生成再存储，而是从不同的位置获取，在这些位置它经历了ETL/ELT过程。由于ETL/ELT过程，数据通常是一个移动目标，在这些过程中，数据被移动，以富化、匿名化或经历其他转换。这些移动可能发生在同一平台内，也可能跨越不同的公共云或数据平台，使得跟踪起来非常复杂。

数据本身正在发生变化。当数据从一个地方移动到另一个地方时，它不仅是在旅行，而且自身还会发生变化。您的表中原本没有任何敏感数据，但可能有人不小心添加了敏感个人信息。

对半结构化数据进行分级分类是一项挑战。半结构化数据（例如存储在 JSON 文件或数据仓库或数据湖中其他半结构化数据对象中的数据）会增加数据分级分类的复杂性。例如，Snowflake表中名为 event_data 的列，可能包含不同类型的半结构化对象，并且在某些情况下存在包含敏感数据的条目。对于半结构化数据，遍历数据以发现敏感数据变得更加困难。

3）仅凭日志是远远不够的

日志通常非常重要。数据访问日志极其重要，因为它们可以阐明数据访问情况。数据访问日志是由数据库引擎生成的日志，提供了有关数据库事务的信息。

虽然数据访问日志确实存在、也非常有用，但真正理解它们非常具有挑战性：

标准不一：数据访问日志一般没有标准化，粒度级别也各不相同。各种日志经常记录在不同的数据存储中，而从不同的数据存储收集日志，有时需要大量工作来统一日志。

设置不明：数据访问日志并不总是“默认开启”，在某些情况下，它们必须进行设置和配置，包括通过设置特定的ETL流程来“照料”它们。

信息不足：有时日志并不包含您以为该有的信息，例如，有时数据访问用户实际上并不是数据消费者，而是分析框架使用的通用账户。找出是谁发送了查询，可能需要关联来自其他系统的日志，这非常复杂甚至不可能实现。此外，在大多数情况下，数据访问日志不包含提取数据的实际位置（数据库、schema、表），想从查询中了解此信息是一项艰巨任务，因为一些数据消费者并没有运行“SELECT * FROM table”，而是一个 1000 行的分析查询，其中包括多个子查询。

缺乏上下文：通常缺乏理解这些日志所需的关键上下文，如关于用户访问数据的信息、关于被访问数据的性质的信息、关于什么被认为是正常的和符合组织策略的信息。这些信息通常散布各处，并跨越各种与日志不相关的工具。

这些问题导致的结果是：仅有本机日志是远远不够的，组织仍然缺乏数据可见性。

4）数据存取方式的演变

过去，企业依靠精通SQL的分析师，直接从数据库查询信息。他们使用客户机-服务器接口直接访问数据库，并使用数据库的用户管理系统验证其访问权限。

后来，随着组织内部对数据需求的增长，人们发明了更复杂的客户机，以简化分析师的工作。这在很大程度上需要使用GUI（图形用户界面）抽象出SQL和数据库连接。

再后来，随着这些客户机在组织中的应用越来越广泛，通过将其部署为Web应用程序来进行大规模供应变得越来越容易。

再后来，随着企业迁移到云，这些部署转变为即服务交付。

导致的改变。从少数单用户桌面客户端访问组织中数据，转变为大量用户使用基于Web的应用程序甚至移动应用程序，这使得组织更难以使用数据库的用户管理系统为用户提供服务。组织将身份验证转向应用程序，并开始使用服务帐户（service accounts）将应用程序连接到数据库，而不是同时在数据库和应用程序两层中为每个用户调配资源。

数据访问归因问题。数据访问由不同的工具驱动，包括自主开发的应用程序、BI工具、命令行界面、脚本。在大多数情况下，必须创建服务账户才能授予和管理这些工具的数据访问权限。这时，连接到数据存储的用户是为工具本身配置的账户，而不是工具背后的实际员工。虽然从用户管理的角度来看很方便，但这意味着数据访问不能归因于驱动它的真实用户。

5）难以设置的访问权限

在许多组织中，数据和分析团队被授予非常广泛的数据访问权限。虽然广泛的数据访问对于企业的创新和成功必不可少，但由于缺乏访问权限控制，因此很难降低数据泄露的风险。

一个常见的情况是服务帐户的特权过高。服务帐户（service accounts）是应用程序用来代表其用户访问资源的一种特殊类型的身份。服务帐户不代表任何特定用户，它代表需要访问资源的任何用户。对于数据存储，即数据库、数据仓库、数据湖、其他系统（如缓存、搜索引擎、消息队列等），这意味着服务帐户通常可以访问数据存储中的所有数据。这将导致两个重大后果：

首先，数据访问的安全控制已从数据存储层转移到应用层，这意味着构建、维护、监控安全控制的责任，已从安全团队转移到工程团队。
其次，数据已经变得更加暴露——要么是应用程序中的安全漏洞（如安全控制或SQL注入中的漏洞），要么是使用服务帐户的凭据并直接连接到数据存储，从而完全绕过应用程序。

过度放纵的反面则是过度限制数据访问。这当然违背了数据驱动战略的目标，所以不能被视为合适的替代方案。

6）新法规要求组织重新思考其数据战略

随着数字转型，企业正在走向在线，每天生成、存储、处理和交换的个人信息数量惊人。出于对个人和一般敏感信息的安全和隐私的担忧，许多司法管辖区引入了新的法规，如国内的《数据安全法》和《个人信息保护法》、欧盟的GDPR、美国加利福尼亚的CCPA。

随着大量罚款和客户对其数据拥有的权利的明确定义，以及组织在收集、存储、使用这些数据时必须遵守的要求，这些新法规极大地改变了组织对数据安全、隐私、治理的思考方式。

保护敏感数据的现有方法

1）数据编目与分级分类

大多数数据治理计划，都是从试图了解数据在组织中的位置以及正在生成、处理、存储、读取的数据类型开始的。

在大多数情况下，这一过程要求所有利益相关者合作并共享他们所知道的信息，以构建所有数据流的地图。包括谁正在访问数据，他们正在访问什么类型的数据，以及数据存储在哪里。对于大型组织来说，这本身就是一个巨大的挑战，因为团队成员分布在不同的地理位置和不同的时区。通常情况下，这些计划启动缓慢，往往中途失败。

另一个障碍是数据是一个移动的目标——特别是在云环境中，生成新的数据存储既快速又简单，而传统的IT治理效果较差。当这些举措产生结果时，背景和环境可能已经改变，组织可能在不知不觉中掌握更敏感的信息。

即使在了解了敏感信息的位置之后，组织仍需努力使该信息具有可操作性。而依赖数据防泄漏（DLP）解决方案来提供上下文通常太少、太晚。

2）访问控制和权限管理

一旦组织知道他们拥有什么样的敏感信息以及这些信息在哪里，就有必要建立防护栏和边界，限制只有需要的人才能访问这些信息。

虽然有很多工具可以帮助组织管理对资源的访问，例如数据存储，但它们并不了解数据。试图在数据存储schema的特定部分上定义访问控制，是非常具有挑战性的：半结构化和非结构化数据存储没有schema，而且，就基于模式的数据存储而言，为每个用例的每个用户，在表和列级别管理细粒度权限的过程，在规模上是一个无法克服的挑战。

3）掩蔽、加密、符号化

一些组织遵循复制敏感数据的策略，并应用各种技术消除静止数据的风险，例如掩蔽、加密、符号化——例如，在掩蔽其中的任何敏感信息的同时，为开发团队提供生产数据库的副本以供调试。

虽然这种方法对特定用例有效，但由于缺乏灵活性和由此产生的开销，在规模上失败了。为每个用例创建一个数据副本，应用所需的转换来保护它，并授予对它的访问权，是一个缓慢的过程。每当克隆数据存储中需要新字段时，都需要调整并重新运行复制过程。此外，这种设计方法会产生更多的数据，从而导致更大的风险、更大的运营开销和更高的基础设施成本。

总之，在过去几十年中，保护敏感数据的现有策略是一个一个地建立起来的，缺乏整体性。它们会导致巨大的操作开销，并且只能解决部分问题。考虑到各组织正在云中采用新的数据存储技术，并在越来越严格的隐私法规下处理比以往任何时候都多的数据，寻求一种新方法是很必要的。

数据保护和治理的新方法

新一代数据安全方案应遵循以下原则：

1）执行动态和细粒度数据访问控制

必须意识到，解决数据访问安全挑战，不能以牺牲业务输出为代价。一个好的解决方案必须既能确保企业的安全，又不会减慢企业的速度。

为了解决这个问题，组织需要能够了解他们的敏感数据在哪里，尤其是当它与数据湖和数据仓库中的其他数据混合时，并跟踪其消费者的使用情况，还要能够对用户访问敏感数据和受监管数据设置限制。

为了真正解决数据安全问题，组织需要能够强制执行动态和细粒度数据访问控制，可以保护敏感数据，揭露行为异常。这才是新一代数据安全方案的基本思想。

2）为数据访问添加上下文

数据存储库本身就是一个宇宙。如果没有专门的平台，企业就不可能高效跟踪内部发生的事情。组织希望回答一些基本问题，例如谁在访问他们的数据、正在访问哪些类型的数据、这些数据的用途。

实现这一目标的最佳且唯一的方法，是为数据访问添加用户、数据、意图上下文，即将用户身份、数据类型、访问意图的信息关联起来。这些类型的上下文，通常存在于多个系统中。如组织的身份系统提供有关人员及其群体的信息；数据目录和主数据管理系统包含有关数据集及其业务上下文的信息；数据存储维护与访问相关的日志；数据库权限则上下文化授权访问。

为此，至少需要将标签分为两类：身份标签和数据标签。身份标签提供有关尝试访问数据的实体的上下文信息（例如，组织单位、位置，甚至特定帐户）。数据标签提供有关所访问数据的上下文信息。大多数上下文信息，默认由分级分类引擎生成，但客户也可以自定义。

3）建立分离的数据访问安全层

每个组织都以不同的方式处理数据保护。可以将它们提炼为两种方法：

1）外挂安全：在现有系统之外，挂接安全/隐私控制；
2）设计安全：通过设计，嵌入安全/隐私。

就流行偏好而言，当今大多数公司都倾向于外挂安全。从表面上看，这似乎是阻力最小的路径，因为它容易集成到他们已有的系统架构和运营中。

但实际上，采用设计安全方式，建立一个与数据架构分离的数据访问安全层，可以在不限制访问的情况下确保数据安全，使得现代企业更有可能获得成功。

将访问控制与数据平台分离，是与DataSecOps方法保持一致的唯一方法，是阻力最小和功效最大的真正途径。因此，必须采用可跨任何数据平台或API工作的通用数据访问服务。

通过建立分离的数据访问安全层，将访问控制（以及访问控制日志记录）与数据存储基础设施分离。这样，设置访问控制策略以及审计它们，就可以跨不同平台实现统一，从而获得跨多个数据存储的访问管理的统一体验。

4）进行持续的敏感数据发现和分级分类

敏感信息往往会出现在意料不到的地方，当你刚刚绘制完成敏感数据地图后，可能发现敏感数据随即出现在新的位置。这正是墨菲定律想表达的意思。

数据经常变化，只有通过持续的可见性和洞察力，才能大规模地保护和治理数据，比如数据盘点、数据访问审计、数据访问控制等。

为此，需要进行持续的敏感数据发现和分级分类。根据不同的数据类型，可以采取的具体方法包括：字典匹配、模式匹配、算法匹配、机器学习等。

对半结构化数据进行持续分级分类很重要。在许多数据分类中，半结构化数据通常被忽略或统一归为一个块（例如，包含 1,000 个不同值的消息，被标记为“电子邮件”，仅仅因为其中一个值是电子邮件地址）。由于半结构化数据在许多情况下不一致，因此对其进行持续分级分类很重要。例如，半结构化数据可能包含随时间添加的额外键，而没有任何数据库schema变更。

数据分级分类的粒度级别。所需的粒度级别有两个：

位置级粒度：可以细化到特定的数据存储、数据库、schema、表或列。要求了解位于特定列内的半结构化数据中不同数据类型的位置，可能更加细化。
数据类型粒度：在大多数情况下，至少需要定义分类数据的类别。在许多情况下，要求更加具体，并将数据分类为特定类型，例如电话号码、姓名、血型、患者 ID 或社会保障号码。

5）在数据源头保护数据

避免传统的数据副本方法。传统数据控制的一个主要问题在于，许多组织都会为不同的用例（例如，掩蔽和非掩蔽数据集）复制schema。这种粗糙的方法，会导致过时的数据、繁冗而缓慢的审批流程，以及每种使用模式的数据仓库数量不断增加。对于具有合理数据规模的组织来说，复制数据或复制基础设施都是不可扩展或不切实际的。

基于上下文的数据访问控制，通过强制执行多个策略，来避免创建数据的副本。这些策略负责解释每种使用模式，可以根据每种单独的使用模式，掩蔽、减少、转换数据，而无需修改schema或数据。

尽量避免使用静态数据转换（例如，用掩蔽的电子邮件地址，替换数据集中的所有电子邮件地址），而是利用动态数据转换在源头保护敏感数据，例如，当用户查询不应暴露于个人识别信息（PII）的电子邮件地址时，可以掩蔽这些地址。这确保了组织只存储他们需要的数据，并允许通过配置谁可以访问数据而不是运行在线复制过程，以更灵活的方式提供对数据的访问。

6）开展持续的权限治理

无法贯彻最小权限原则，是许多组织面临的问题。权限几乎是单向发展的——请求增加权限的情况频繁发生，但很少会有人主动请求删除访问权限。这导致，权限的膨胀速度，会比面团发酵还要快。

为解决权限回收问题，应分析用户权限（用户有权使用什么）和实际数据访问（用户实际使用什么）之间的差距。然后对差距进行优先级排序，以便及时回收不必要的权限。

将数据授权给人，而非授权人到数据。目前最流行的数据授权方式是RBAC（基于角色的访问控制）。RBAC是一个授权用户访问数据的系统，它可以定义哪些角色可以访问哪些位置的数据。事实上，数据位置是不明确的，因为数据在不断地移动。此外，在一个快速发展的组织中，角色也未必准确定义其工作范围。因此，公司不得不实施手动流程，旨在验证控制的准确性，这就必然降低了流程速度。

因此，应该考虑将数据授权给人的选项。这种方法可以定义感兴趣的数据类型以及获取访问权限所需的内容。这种替代方案需要一种更细粒度的授权机制，该机制考虑到数据和访问属性。ABAC（基于属性的访问控制）就是这样一种方法，它允许更灵活的策略。再加上一个数据访问层，不仅可以控制访问，还可以控制返回的数据和涉及的过程。这样，就使得对于不同使用模式的维护，可以从手动转向自动。

7）可在现有环境中透明化部署

避免重建数据基础设施。大多数组织不会仅仅为了采用数据安全解决方案，而重新构建其数据基础设施。通过替换部分数据基础设施（如存储或查询引擎）或依靠广泛部署应用程序或端点代理来提供安全价值的解决方案，既很难实施，又很难被欣赏。

在现有环境中透明化部署。数据安全不是一个全新市场，企业已经投资建立自己的数据平台和流程。因此，数据安全解决方案必须能够在不中断企业业务的情况下适应现有环境，并在不影响现有使用模式和工具的情况下集成到现有基础设施中。最重要的是，目标必须是通过简单、高效、广泛的数据访问，来优化他们的数据运营。

按照这个逻辑，一个好的数据保护和数据治理解决方案，必须能够实现正常的数据访问，而不是中断或产生负面影响。然而，一个伟大的解决方案，将使数据访问比以前更容易、更高效、更广泛！

示例：Satori 安全数据访问

Satori是RSA 2021大会的创新沙盒十强决赛入围者。Satori在日语中有“顿悟”之意。Satori秉持DataSecOps理念，引入了位于数据消费者和数据存储之间的通用数据访问服务的概念。毫无疑问，Satori通用数据访问平台是上述数据安全新方法的典型示例。

Satori提出了一种新的数据安全方法，提供了对数据和数据流的持续可见性，实施必要的安全控制，强制执行合规性和隐私政策，同时使合法访问变得简单、快速、高效。Satori通过将用户/应用程序身份与实时数据发现、分级分类、行为分析相结合，实现了这一点。

Satori 充当数据消费者（用户/应用程序）和数据存储之间的数据访问层，也是一个上下文感知层，其方式与代理类似。它检查每个事务，对动态数据进行分级分类，通过 IAM 解决方案或数据存储用户和角色配置添加身份上下文，并为所有云数据存储提供精细的访问控制策略和集中分析。

Satori 的核心是一个透明代理服务，数据消费者连接到它，而不是连接到实际的数据存储本身。Satori 对其数据用户是透明的，因此不需要对业务智能 (BI) 或分析工具进行任何更改，也不会改变数据用户使用数据的方式（即查询或命令中没有变化）。Satori 对数据存储也是透明的，因此不会改变数据存储本身中的任何内容（即没有创建视图或schema），身份认证、授权、审计机制也保持不变。

Satori 通过下述上下文，富化每个数据活动：

身份：Satori 监控到数据存储的新连接的创建，并使用该信息在组织的IAM (身份和访问管理) 系统中查找用户的配置文件。
数据：Satori 会同时观察查询和结果集，以对包含敏感信息（如姓名、电子邮件地址、社会保障号码）的事务进行分类。
行为：Satori 分析环境中的真实用户访问，以了解正常访问是什么样的，同时还提供了一套丰富的开箱即用的行为策略，以促进数据访问安全。

图3-Satori通用数据访问平台/服务

Satori架构解决可靠性和低延迟问题的方法是，将数据流量分成两个数据路径：代理和分析。代理意味着将字节从数据消费者传输到数据存储；分析是运行算法和策略引擎的地方。每条路径都由一组单独的计算资源处理，更重要的是，由具有不同代码库和发布节奏的单独软件处理。

对于代理，Satori 使用Nginx，这是一种众所周知的代理软件。使用 Nginx 的开箱即用功能，来代理 TCP 和 HTTP 流量并终止 TLS 连接。每个 Satori 部署都包含一组高度可用的 Nginx 代理服务器，作为 Kubernetes 集群中的容器。数据消费者和数据存储之间的连接仅通过 Nginx。

对于分析，Satori 使用Rust构建了“分析器”（Analyzer），Rust是一种专注于安全性、并发性、高性能的系统编程语言。分析器不在数据消费者和数据存储之间的数据路径中。相反，它从 Nginx 接收流量捕获，并异步处理它们。根据应用于连接的策略，分析器可以指示 Nginx 终止连接、阻止查询、返回空结果集、掩蔽敏感数据。

总结：数据安全新方法与零信任的关系

简单总结下数据安全新方法与零信任的关系：

1）数据安全新方法彻底贯彻了零信任思想

数据安全新方法本质上是一种新型的数据访问控制方法，而数据访问控制必然依赖于零信任方法。作为新一代数据访问控制的代表，Satori正在全面实现基于零信任的数据访问控制服务。

2）零信任是以数据为中心的安全架构

这是零信任与以网络为中心的传统安全模型的主要区别。

数据是零信任的支柱目标之一。在《美国联邦政府零信任战略》中支柱目标包括：支柱目标1-身份；支柱目标2-设备；支柱目标3-网络；支柱目标4-应用；支柱目标5-数据。本质上，实现数据安全，是零信任的终极目标。

3）美国国防部将零信任应用于数据安全

不妨看看美国国防部（DoD）面向数据安全的零信任架构。

图4-DoD面向数据安全的零信任架构

从图中可以看到，有4道授权决策点，但考虑到第1道授权包含了人和设备两种情况，所以实际上可以展开成5道授权决策点。如下图所示：

图5-逐层深入的数据授权过程

从上图可见，5道授权决策点依次是：用户->设备->网络->应用->数据。而通常意义上的零信任，主要是实现了前面的4道授权。而第5道数据授权，才是数据访问控制的核心。数据授权的基本原理如下图所示：

图6-数据访问控制的基本原理

数据访问控制与之前几道访问控制的重要区别在于：之前的几道网关都是功能级的访问控制；而数据访问网关是数据级的访问控制。数据访问网关通过数据访问策略引擎，实现数据库的表级、行级、列级、字段级的数据访问控制。这是其它的网关通常无法实现的能力，也是数据安全中最值得重视的能力。

4）数据访问控制与零信任的区别

如果一定要分辨数据访问控制与零信任访问控制的区别，可以简单地认为：

保护对象：零信任保护的是业务/应用访问；数据访问控制保护的是数据访问。
实现方式：零信任的实现方式通常是应用代理；数据访问控制的实现方式通常是数据代理。
控制粒度：零信任访问控制的粒度通常是功能级；而数据访问控制的粒度必然是数据级。

但其实，以笔者观点看，数据访问控制是零信任的最后环节和终极目标。正如图5（逐层深入的数据授权过程）所反映出的，彻底的零信任方案应该包含数据访问控制。

此外，数据安全与零信任还有个相似的性质在于：它们都超越了传统的安全领域。零信任渗透到身份治理领域；数据安全扩展到数据治理领域。而这两种治理活动，都需要足够的积累和沉淀。

未来已来，不谈零信任，何谈数据安全！这就是为什么必须在新一代数据安全框架中，为零信任留出半壁江山。

（本篇完）

阅读原文

跳转微信打开

美国国防部零信任实施方案：Thunderdome（雷霆穹顶）

Sun, 07 Nov 2021 08:53:00 +0800

原创柯善学 2021-11-07 08:53

雷霆穹顶：雷霆之上，穹顶之下。

全文约4000字 6图表阅读约10分钟

在美国国防部旗帜鲜明地宣布零信任战略和发布零信任参考架构之后，国防部开始正式向零信任实施方案快速推进。美国国防信息系统局（DISA）提出的Thunderdome（雷霆穹顶），正式成为国防部零信任实施阶段的急先锋。

DISA已经向行业合作伙伴征集关于Thunderdome零信任实施方案的白皮书。DISA希望，通过授予25个SD-WAN站点和5000个用户的试点范围，在六个月内，为具有客户边缘安全栈和应用程序安全栈原型的SASE（安全访问服务边缘）和SD-WAN（软件定义广域网）架构，提供初始的最小可行产品（MVP）。而对这些能力的改进和运行实施，将一直计划到2025年。

另一方面，国防部首席信息官在2021年夏天已经决定取消JRSS（联合区域安全栈）计划，并寻找替代计划。而在2021年10月召开的2021年度TechNet Cyber会议，进一步明确将Thunderdome作为JRSS的替代方案。

简而言之，Thunderdome就是美国国防部的零信任/SASE实施原型。它的提出，实锤了三件事：一是国防部网络架构向零信任和SASE演进；二是国防部零信任工作正式进入落地试点阶段；三是以SASE架构替代JRSS中间层安全。

值得提醒的是，由于SASE的网络重构属性，Thunderdome试点或将导致对国防部信息网络的彻底重构。

关键词：RWP（白皮书请求，Request for White Paper）；DISA（国防信息系统局）；SASE（安全访问服务边缘）；JRSS（联合区域安全栈）；ICAM（身份、凭证与访问管理）

目录

1.背景概述

2.战略定位

3.主要意图

4.技术关注度

5.技术要求

6.实施计划

背景概述

2020年11月，笔者曾在《美国国防部零信任的支柱》一文中，展示了美国国防部网络架构的三次演进，并指出第3次演进是2020年代的软件定义边界（SDP）。

随着时间推移，DISA（国防信息系统局）进一步强化了这种演进思路，寻求在SASE（安全访问服务边缘）安全框架下实施零信任。2021年7月，DISA在开始发布Thunderdome白皮书请求《Request for White Paper DISA-OTA-21-9-Thunderdome》，并且更新了7个版本。如下图所示：

图1-Thunderdome白皮书请求

Thunderdome项目本质上就是零信任/SASE原型项目。Thunderdome的提出，相当于实锤了国防部向SASE架构的演进趋势。

2021年1月，笔者曾在《美军网络安全 | 用零信任替代中间层安全？》一文中，说明JRSS（联合区域安全栈）是标准化的中间层安全设备。2020财年DOT&E年度报告，强烈地期待零信任架构能够替代JRSS，承担起国防部网络的中间层安全的重任。

2021年10月，美国武装部队通信与电子协会（AFCEA）举办了2021年度TechNet Cyber会议。会上进一步明确，国防部决定逐步淘汰JRSS，并考虑将Thunderdome作为JRSS的替代方案。如果Thunderdome得到验证，DISA会将JRSS计划过渡到零信任架构。这也是本界TechNet Cyber大会上最令人激动的事情之一。

战略定位

图2-国防部零信任实施框架

笔者从上面这张图中，大致推断Thunderdome的战略定位：

国防部的零信任，将主要由企业级ICAM（身份、凭证与访问管理）和Thunderdome构成。ICAM是底层基础设施；Thunderdome是上层架构。
所有访问者，使用多因素认证（MFA）、通用访问卡（CAC）、PIV、令牌、口令等方式，通过ICAM基础设施进行认证。同时，在访问过程中，会对所有账号进行生命周期管理和审计。
被访问资源，分为两大类：一是本地的资源和数据；二是云中资源和数据。
访问过程的控制和分析手段：包括策略强制执行（PE）、微分段（MSG）、网空态势感知（CSA）。

再解释下：笔者在写本文之前，都一直难以理解Thunderdome这个名称的内在含义。直到看到这张图，才觉得Thunderdome最好被拆分为两个单词——Thunder dome，被翻译成“雷霆穹顶”比较合适，因为Thunderdome在此图中的位置正是穹顶。

主要意图

国防部正在计划在SASE安全框架内实施关键的零信任概念。这些是国防部的新作战能力，它将显著改善路由和安全服务。

DISA发布Thunderdome白皮书请求（RWP）的主要目的，就是着眼于零信任实施相关的原型、开发、测试活动。DISA计划采购工具/系统/能力，以在国防部的SIPRNet（机密互联网协议路由器网络）和NIPRNet（非机密IP路由器网络）上，部署具有SASE能力、集成SD-WAN技术、客户边缘安全栈、应用程序安全栈的零信任安全模型。

国防部打算通过实施本项目，充分利用商业最佳实践，建立若干工具和流程的原型。具体而言，国防部打算创建、设计、开发、演示以下安全能力的运行效用：

SASE；
DISN（国防信息系统网络）客户边缘PoP（存在点）的客户边缘安全栈；
部署在应用程序工作负载前的可扩展应用程序安全栈。

SD-WAN集成包括提供微分段和特定流量优先级排序的能力。这些能力将与现有DISA系统（如ICAM、遵从连接（C2C）、端点系统、SIEM、数据分析平台等）集成，提供条件化访问和策略，基于用户和端点属性以及基于应用程序和数据标签的策略，来限制访问功能。

技术关注度

DISA新任命的首席技术官（CTO）兼新兴技术办公室负责人Steve Wallace，在2021年10月Forecast to Industry（行业预测） 2021的演讲PPT中，主要展示了下面这张图：

图3-2022财年DISA技术观察名单

从上图中，笔者观察到：

所有被关注技术的热度/成熟度：自内向外依次降低，共分为4个环：第1环是部署环（Deploy）；第2环是原型环（Prototype）；第3环是计划环（Plan）；第4环是监视环（Monitor）。
第1环（部署）：包括CAIM（网络资产清单管理）、BYOAD（自带批准设备）、企业灰核（Enterprise Grey Core）；
第2环（原型）：包括Thunderdome、ICAM（身份、凭证和访问管理）、AI/ML（人工智能/机器学习）、SOAR（安全编排、自动化和响应）、自动化（Automation）、移动/桌面融合、涉密移动能力；
第3环（计划）：包括零信任（Zero Trust）、边缘计算、入侵与攻击模拟（BAS，Breach and Attack Simulation）、分布式账本（Distributed Ledgers）、反向浏览器隔离等；
第4环（监视）：包括加密流量分析（Encrypted Traffic Analysis）等；

可以看出，Thunderdome处于第2环（原型），而零信任（Zero Trust）处于第3环（计划）。由于Thunderdome是零信任的一个具体实现方案，所以对Thunderdome的紧迫性更高。Steve Wallace说：“能力的好坏取决于它的实施。”因此，国防部零信任能力的好坏，取决于Thunderdome的实施。

技术要求

在第7版Thunderdome白皮书请求（RWP）中，给出了评估供应商技术优势的标准：

A.供应商创建、设计、开发、集成SASE的方法；

B.供应商实施可由DISA作为服务提供商管理的SASE能力的方法；

C.供应商实现支持多租户（多个客户和组织）的SASE能力的方法；

D.供应商提供可部署到本地客户位置或云托管企业位置的拟议SASE解决方案的技术方法；

E.供应商在DISN POP创建、设计、开发、集成客户边缘安全栈的方法；

F.供应商在应用程序工作负载前创建、设计、开发、集成可扩展应用程序安全栈的方法和创新；

G.供应商设计、开发、集成用于防御性网络作战（DCO）和持续监控的网络态势感知（SA）工具的方法；

H.供应商获取、丰富、格式化、转换数据的方法；

I.供应商的数据持久化方法（90天热存储、180天热存储、365天冷存储）；

J.供应商查询、共享、可视化网络态势感知数据的方法；

K.供应商开发网络态势感知解决方案的方法，该解决方案在给定环境的情况下尽可能具有可移植性和云不可知性；

L.供应商采用标准化身份来验证用户和设备的方法；

M.供应商制定新的基于风险的安全策略以促进条件访问的方法；

N.供应商将访问策略与用户属性和设备加固状态相关联的方法；

O.供应商集成端点技术的方法；

P.供应商实现多种设备和来自不同地点的条件访问的方法；

Q.供应商从任何设备上的任何位置提供一致体验的方法，可针对用户设备进行优化；

R.供应商以连续、一致、低延迟的方式提供遥测（日志/事件数据）的方法；

S.供应商与安全DNS架构集成的方法；

T.供应商保护国防部免受DDoS（分布式拒绝服务攻击）的方法；

U.供应商确保DISA能够支持在NIPR和SIPR连接上从SD-WAN控制器到DISN主干的默认（静态路由）或BGP（边界网关协议）对等的方法；

V.供应商为租户客户提供服务门户的方法，提供服务状态和SLA指标，以及租户管理员管理特定于租户的网络和安全服务策略和配置的能力；

W.供应商自动化和编排网络和安全服务的设计和部署的方法，包括软件增强、更新和补丁的敏捷部署；

X.供应商提供设备清单、软件清单、配置、配置合规性、漏洞状态的方法，包括端点保护工具和功能的配置；

Y.供应商创建、设计、开发、集成SD-WAN的方法和创新，包括提供微分段、自动资源调配、流量优先级排序；

Z.供应商支持用户指定边界的SD-WAN方法，不受设施、地理、设备和作战人员移动和位置的限制：

aa.供应商使用现有宽带能力的SD-WAN方法——无MPLS（多协议标签交换）/VLAN（虚拟局域网）；
bb.供应商在处理之前对网络流进行身份验证的方法；
cc.供应商在传输之前加密网络流的方法；
dd.供应商的混合网络SD-WAN方法，其中一些流量在SD-WAN上，而其他流量在MPLS和OOT操作上；
ee.当SLA降至用户指定级别以下时，供应商提供网络和网络路径按需可扩展的方法；
ff.供应商监控SD-WAN并在细粒度级别提供网络流量可见性的方法；
gg.供应商在4个NIPR站点（DISA HQ、DISA PAC、DISA EUR、JSP）实施完整解决方案的方法，每个站点估计有5000名用户；
gg.供应商测试和实施完整Thunderdome原型的方法，应通过里程碑图进行描述，且需在授予之日起的6个月内完成。

从上面罗列的技术要求，大致可以看出，Thunderdome项目主要涉及SASE、SD-WAN、网络态势感知、客户边缘安全栈、应用程序安全栈、条件访问、自动化编排、资产/配置/漏洞、微分段、流量优先级排序等。

下图展示了部分关键技术与国防部零信任七支柱之关系：

图4-关键技术与国防部零信任七支柱之关系

以笔者的观点看：为了覆盖国防部零信任的七大支柱，上图左边罗列的关键技术都是必不可少的，因此可以视为零信任实施的最小集。

实施计划

如果您在过去 20 年里一直关注DISA，有一件事很清楚：DISA确实喜欢试点或概念验证（POC）。

而DISA正是将Thunderdome作为零信任的原型，以验证构成零信任架构的概念。从一定程度上看，Thunderdome试点将是对国防部信息网络的彻底重构。这项试点活动将帮助国防部理解如何在整个国防部实施这一计划。

在Thunderdome白皮书请求（RFW）的各种版本中，给出了里程牌计划。

第5版中的里程牌，如下图所示：

图5-Thunderdome里程碑（第5版）

但是，在第6版和第7版中，却删除了里程碑。如下所示：

图6-Thunderdome里程碑被删除（第7版）

尽管最新版中删除了里程碑图，但也要求白皮书提交者必须提交里程碑图。笔者推测：也许是DISA不想对供应商的时间进度控制得过度苛刻，而是多给他们一些灵活空间。

但是，白皮书请求中的里程碑，多少反映了DISA对Thunderdome的进度期待。从中可以看出：

里程碑划分成3个阶段（Phase），共计19个里程碑节点；
每个阶段（Phase）大概2个月，3个阶段总共半年时间；

Thunderdome白皮书请求（RFW）的截止日期是2021年9月3日。当前，DISA正在审查各个供应商提交的Thunderdome白皮书，计划采用三阶段评估方法，授予Thunderdome原型：

第一阶段-白皮书评估：按照评估标准，针对收到的白皮书进行评估，以确定最小可行产品（MVP）。
第二阶段-口头陈述：邀请第一阶段选定的供应商提供口头陈述，可通过视频会议或电话进行。在演示过程中，供应商应准备详细讨论其解决方案。
第三阶段-项目建议书申请：向第二阶段中不超过两个供应商，发出项目建议书请求（RFPP）。

除了Thunderdome计划本身，ICAM也是DISA零信任实施的关注重点。多年来国防部一直在本地运行PKI，DISA希望利用其传统PKI，在混合云环境中实现PKI现代化。DISA预计将在2022财年第二季度发布PKI现代化支持服务的提案请求，并在2023财年做出授予。作为PKI现代化的一部分，DISA新任首席技术官 Steve Wallace 表示，DISA将继续寻找新方法，来简化身份和访问管理，同时又不失安全性。

（本篇完）

阅读原文

跳转微信打开

《美国联邦政府零信任战略》

Thu, 09 Sep 2021 07:44:00 +0800

原创柯善学 2021-09-09 07:44

零信任不会不来，只会迟到。

全文约5000字阅读约15分钟

这无疑是目前零信任应用领域的最大消息——表明整个美国联邦政府已经正式开启零信任战略。

美国管理和预算办公室（OMB）在2021年9月7日发布了《联邦零信任战略》（Federal Zero Trust Strategy）草案，以支持第14028号行政指令（EO 14028）《改善国家网络安全》，以改变民用机构的企业安全架构，使其基于零信任原则。

拜登总统曾在EO 14028中指出：“渐进式改进不会为我们提供所需的安全性；相反，联邦政府需要做出大胆的改变和重大的投资，以保护支撑美国生活方式的重要机构。” 而本次的《联邦政府零信任战略》无疑就是对此的最好支持和回应。

《联邦政府零信任战略》的目的是将政府机构的企业安全架构迁移到零信任架构。但该战略文件只是一个起点，而不是完全成熟的零信任架构的综合指南。当然，零信任的成熟度模型和参考架构，已经在该战略的参考文献中列出，政府机构应该使用它们来规划和执行其长期安全架构的迁移计划。

本战略草案的PDF文档有23页，译文大概1万5千字。笔者概述了本战略的内容要点，并做了相关解读。战略草案原文链接：https://zerotrust.cyber.gov/federal-zero-trust-strategy/

关键词：《联邦政府零信任战略》（Federal Zero Trust Strategy）；OMB（管理和预算办公室）；EO 14028（第14028号行政指令，Executive Order 14028）《改善国家网络安全》；MFA（多因素认证）；CISA (网络安全和基础设施安全局)；GSA（总务管理局）

目录

1.战略背景解读
2.战略路径解读

3.支柱目标1：身份

4.支柱目标2：设备

5.支柱目标3：网络

6.支柱目标4：应用

7.支柱目标5：数据

8.本战略的参考文件

战略背景解读

《联邦政府零信任战略》（Federal Zero Trust Strategy）草案发布的网站截图如下：

本战略文档开宗明义：“管理和预算办公室（OMB）在2021年9月7日发布了《联邦政府零信任战略》草案，以支持第14028号行政指令（EO 14028）《改善国家网络安全》，以改变民用机构（civilian agencies）的企业安全架构，使其基于零信任原则。”

笔者对上面这段文字，给予解读：

1）零信任战略是用来支撑EO 14028的。该战略中也重申了EO 14028的重要性：“成功地使联邦政府的安全方法现代化，需要全政府的努力。2021 年 5 月，总统发布了第14028号行政指令 (EO)，《改善国家网络安全》，启动了政府范围内的全面努力，以确保基线安全实践到位，将联邦政府迁移到零信任架构，并实现基于云的基础架构的安全优势，同时降低相关风险。”很明显，EO 14028中已经对联邦政府向零信任架构的迁移做出了明确指示。而这次发布的《联邦零信任战略》就是进一步明确联邦政府零信任战略的实施。

2）战略中最重要的关键词无疑是“机构”（agencies）。简单理解，主要是指政府机构。那为什么要强调“民用机构”（civilian agencies）呢？这主要是和美国国防部这类的“军用机构”划分界限。我们可以简单将本战略中的“民用机构”理解为“政府机构”。

3）为什么要保护这些政府机构？该战略中提到：“每天，联邦政府都在执行独特且极具挑战性的任务：机构保护我们国家的关键基础设施、开展科学研究、参与外交、为美国人民提供福利和服务，以及许多其他公共职能。为了有效地执行这些任务，我们的国家必须明智而积极地利用现代技术和安全实践，同时避免恶意网络活动造成的破坏。”

4）零信任战略的目的是将政府机构的企业安全架构迁移到零信任架构。这里面的“企业安全架构”就不多解释了。在美国人眼中，一切机构皆为“企业”，不论民用机构还是军用机构。比如，美国国防部，就是最典型的“企业”。

5）评论期很短，正式版可能很快发布。注意到，该战略草案的评论期只有两周（2021年9月21日之前），时间很短。说明OMB希望尽快发布正式版。

6）美国国防部是美国联邦政府机构的零信任先锋。美国机构虽然有军用和民用之分，但不要轻视美国国防部对美国联邦政府的影响力。美国国防部曾经称自己不是一个“热衷于追求热词”的部门。但在零信任这个方向上，国防部如此激进，甚至走在所有联邦政府机构的前头，就是因为美国国防部提前认识到零信任的价值。而现在整个联邦政府都全面转向零信任架构，不能不说：美国国防部功不可没。笔者当然是深知美国国防部的影响力，所以才会在美国国防部开始重视零信任的早期，就密切关注零信任形势的发展。

7）尽管零信任背后的概念并不新鲜，但对联邦机构而言仍然是一个重大转变，因为从概念上消除了对设备和网络的隐式信任。这要求美国政府机构的安全架构必须假设——网络和其他组件将受到入侵和损害，并且要求遵循最小权限原则。

8）联邦政府零信任战略是一项大胆的行动。对于像联邦政府这样复杂且技术多样的企业来说，过渡到零信任架构不是一项容易的任务。但正如拜登总统在 EO 14028 中所述，“渐进式改进（Incremental improvements）不会为我们提供所需的安全性；相反，联邦政府需要做出大胆的改变（bold changes）和重大的投资（significant investments），以保护支撑美国生活方式的重要机构。”

9）零信任战略实施进展时间要求：

该战略要求政府机构在2024 财年 (FY) 结束前，实现特定的零信任安全目标（具体目标参加下文中的五个支柱）。
EO 14028要求各机构制定自己的零信任架构实施计划。在本战略发布之日起 60 天内，各部门和机构应在各自零信任架构实施计划的基础上，纳入本战略中规定的额外要求，并向 OMB 提交 22-24 财年的实施计划和 23-24 财年的预算估算。机构应在22财年重新确定资金的优先次序，以实现优先目标，或从其他来源寻求资金。
自本战略发布之日起，部门和机构将有 30 天的时间，为其组织指定和确定零信任架构实施负责人。OMB将依靠这些指定的领导，进行政府范围内的协调以及参与每个组织内的规划和实施工作。

战略路径解读

1）联邦零信任战略不是什么？零信任战略并不试图描述或规定一个完全成熟的零信任实现。甚至不鼓励任何机构超越此战略中所述的行动。该战略的目的是通过制定机构必须采取的初始步骤，将所有联邦机构置于一个共同路线图上，以使其迈向通往高度成熟的零信任架构的旅程。它承认每个机构目前处于不同的成熟状态。

2）联邦零信任战略是什么？零信任战略的目标是加速各机构实现早期零信任成熟度的共享基线。对于政府机构来说，转向零信任架构将是一个多年的旅程。 “EO 14028 指示机构专注于满足整个政府的关键基线安全措施，例如通用日志记录、多因素身份验证 (MFA)、可靠的资产清单、无处不在的加密使用，并采用零信任架构。” 该战略试图将机构引导到零信任架构道路上的最高价值起点，并描述了应优先考虑的几种共享服务。简单地说，联邦零信任战略是将政府机构引导到零信任的正确道路上，而且只是开了个头。

3）联邦零信任战略设想了一个联邦零信任架构：

支持跨联邦机构的强大身份实践；
依赖加密和应用程序测试，而非边界安全；
识别政府拥有的每一个设备和资源；
支持安全行动的智能自动化；
支持安全、稳健地使用云服务。

4）零信任战略要达成的零信任目标分为五个支柱：（分组依据是CISA (网络安全和基础设施安全局)零信任成熟度模型的五个支柱）

身份：机构工作人员使用企业范围的身份，来访问他们在工作中使用的应用程序。防网络钓鱼MFA，可保护这些人员免受复杂的在线攻击。
设备：联邦政府拥有其运营和授权供政府使用的每台设备的完整清单，并且可以检测和响应这些设备上的事件。
网络：机构在其环境中加密所有DNS请求和HTTP流量，并开始围绕其应用程序对网络进行分段。联邦政府确定了对传输中的电子邮件进行加密的可行途径。
应用程序：机构将所有应用程序视为连接到互联网的应用程序，定期对其应用程序进行严格测试，并欢迎外部漏洞报告。
数据：机构在部署利用彻底数据分类的保护方面有一条清晰、共享的路径。机构正在利用云安全服务来监控对其敏感数据的访问，并实施了企业范围的日志记录和信息共享。

为什么美国国防部的零信任架构是七大支柱，而联邦政府却是五大支柱？本质上，两者是一致的。看似消失的两个支柱——可见性和分析、自动化和编排，实际上是两类横切系统（在下图的底座中），贯穿到五大支柱（纵向系统）中。

零信任的基础：五大支柱和三大基座

5）《美国国防部零信任参考架构》仍是联邦政府零信任架构的重要参考。该战略确实完整引用了《美国国防部零信任参考架构》中的零信任原则，不再赘述。

6）联邦零信任战略的相关干系人。机构的首席财务官、首席采购官、机构领导层的其他人员，需要与其IT和安全领导层合作，以构建运营模型（operational model）来部署和维持零信任能力。

7）联邦零信任战略非常推崇对云的使用。该战略鼓励机构利用云基础设施中丰富的安全功能，该战略也多处引用云服务。

8）五大支柱目标的分解行动，如后文所述。

支柱目标1：身份

1）愿景

机构工作人员使用企业范围的身份，来访问他们在工作中使用的应用程序。防网络钓鱼MFA可保护这些人员免受复杂的在线攻击。

2）行动

机构必须为机构用户建立单点登录 (SSO) 服务，该服务可以集成到应用程序和通用平台（包括云服务）中。
机构必须在应用程序级别实施 MFA，并在可行的情况下使用企业 SSO。

对于机构工作人员、承包商和合作伙伴：防钓鱼MFA是必须的。
对于公共用户：防钓鱼MFA必须是一个选项。

机构必须采用安全的口令策略，并根据已知泄露的数据检查口令。

CISA 将为机构提供一项或多项可以私下检查口令的服务，而不会暴露这些口令。

3）关键举措

1. 企业范围的身份

2. 多因素认证，抵御网络钓鱼

3. 面向公众的身份验证

4. 使用强口令策略

支柱目标2：设备

1）愿景

联邦政府拥有它运行和授权用于政府工作的每台设备的完整清单，并且可以检测和响应这些设备上的事件。

2）行动

机构必须参与 CISA 的持续诊断和缓解(CDM) 计划。

CISA 将 CDM 计划以最小特权原则为基础，并优先考虑在基于云的基础设施中的有效运行。

机构必须确保每个人工操作的企业配置设备，都有机构选择的端点检测和响应 (EDR) 工具。

CISA 将与机构合作，填补 EDR 覆盖范围的空白。
机构必须向 CISA 提供对 EDR 数据的持续访问。

3）关键举措

盘点资产
政府范围的EDR（端点检测和响应）

支柱目标3：网络

1）愿景

机构在其环境中加密所有 DNS 请求和 HTTP 流量，并开始围绕其应用程序对网络进行分段。联邦政府确定了对传输中的电子邮件进行加密的可行途径。

2）行动

在技术支持的任何地方，机构都必须使用加密的 DNS 来解析 DNS 查询。

CISA 的保护性 DNS 程序，将支持加密的 DNS 请求。

机构必须对其环境中的所有 Web 和应用程序接口 (API) 流量，强制实施 HTTPS。

CISA 将与机构合作，将他们的 .gov 域“预加载”到网络浏览器中，使其只能通过 HTTPS 访问。

CISA 将与 FedRAMP 合作，评估MTA-STS作为加密电子邮件的可行的政府范围内解决方案，并向 OMB 提出建议。
机构必须与CISA 协商制定网络分段计划并将其提交给 OMB。

3）关键举措

加密 DNS 流量
加密 HTTP 流量
加密电子邮件流量
围绕应用程序分段网络

支柱目标4：应用

1）愿景

机构将他们的应用程序视为连接到互联网，定期对其进行严格的实证测试，并欢迎外部漏洞报告。

2）行动

机构必须运行专门的应用程序安全测试程序。
机构必须利用专门从事应用程序安全的高质量公司，进行独立的第三方评估。

CISA 和 GSA 将共同努力，使此类公司可用于快速采购。

机构必须维持有效且受欢迎的公开漏洞披露计划。

CISA 将提供一个漏洞披露平台，使机构系统所有者可以轻松地直接接收报告并与安全研究人员接触。

机构必须确定至少一个面向内部的 FISMA 中级（Moderate）应用程序，并使用企业 SSO 使其可通过公共互联网访问。
CISA 和 GSA 将共同努力，为机构提供有关其在线应用程序和其他资产的数据。

机构必须向 CISA 和 GSA 提供他们使用的任何非 .gov 主机名。

3）关键举措

应用安全测试
容易获得的第三方测试
欢迎应用漏洞报告
安全地使应用程序可访问互联网
发现可上网的应用程序

支柱目标5：数据

1）愿景

机构在部署利用彻底数据分类的保护方面有一条清晰、共享的路径。机构利用云安全服务和工具来发现、分类和保护他们的敏感数据，并实现了企业范围的日志记录和信息共享。

2）行动

OMB 将与联邦首席数据官和首席信息安全官合作，制定零信任数据安全策略和相关的实践社区。
机构必须对数据分类和安全响应进行一些初始自动化，重点是标记和管理对敏感文档的访问。
机构必须审计对商业云基础设施中任何静态加密数据的访问。
机构必须与 CISA 合作实施全面的日志记录和信息共享功能，如OMB 备忘录 M-21-31 中所述。

3）关键举措

联邦数据安全策略
自动化安全响应
审计对云中敏感数据的访问
及时获取日志

本战略的参考文件

本战略指出：一段时间以来，联邦政府一直在为过渡到零信任架构做准备。一些机构已经发布了对其他机构有帮助的架构模型：

CISA 的零信任成熟度模型：是对零信任“支柱”的高级概述，展示了机构如何发展到“高级”和“最佳”状态，并描述了 CISA 服务产品如何与这些支柱保持一致。
CISA 《云安全技术参考架构》：与美国数字服务部（United States Digital Service）和 FedRAMP 合作，为安全云架构和迁移策略提供了更详细的参考。
NIST SP 800-207《零信任架构》指南：为零信任架构的关键原则提供了共识定义和框架，同时描述了具有不同风险状况和技能集的组织可以采用的几种不同的零信任架构方法。
NIST NCCoE（国家网络安全卓越中心）已启动“实施零信任架构”计划：与行业合作伙伴合作，将 NIST SP 800-207 中的概念应用于传统企业架构。
GSA《零信任架构买家指南》：可以帮助机构确定提供与机构零信任实施相关的产品和服务的 GSA 合同工具。
《国防部零信任参考架构》：全面描述了国防部计划在其系统中执行的潜在安全功能和架构控制。

（本篇完）

阅读原文

跳转微信打开

网络安全观

安全产品终将成为服务

中国的网空能力

美军进攻性网络作战架构

网络安全的三大支柱和攻击向量

谁动了你的数据？

美国国防工业网络保护框架和启示

云隔离的梦想

美国国防部的百亿大单和上云启示

致美国总统的零信任报告

数据访问控制的未来

数据治理的三种共享范式

数据治理的三本数据秘籍

数据治理的三位数据大师

安全的未来是上下文

美国国防部Thunderdome零信任原型正式启动

《美国联邦政府零信任战略》正式版发布

CrowdStrike：零摩擦，零信任

关于零信任，CrowdStrike的发展思路是：

与零信任厂商（Zscaler、Illumio、Okta等）合作，推出联合零信任方案；

通过收购Preempt，弥补零信任身份安全；

通过收购SecureCircle，弥补零信任数据安全；

通过这两个收购，完成了对零信任领域的整体布局。

数据安全保护和治理的新方法

新一代数据安全方案应遵循以下原则：

必须意识到，解决数据访问安全挑战，不能以牺牲业务输出为代价。一个好的解决方案必须既能确保企业的安全，又不会减慢企业的速度。

6）开展持续的权限治理

美国国防部零信任实施方案：Thunderdome（雷霆穹顶）

《美国联邦政府零信任战略》