更新背景
“黎明将至”，本篇文章的封面真切的体现了笔者现在的真实心情。笔者在去年选择从发展如日中天的云安全，快速“切换赛道”来到了“广义办公安全”（混合办公），经过这段时间的落地和打磨，笔者觉得端、网、云协同办公时代已经悄然成为了今年的热门话题。多年安全厂商发布SASE+终端安全+“零信任”+云安全+云原生安全的产品和解决方案，详见《2021年安全架构总结以及2022安全方向展望》六大预测的内容。笔者的目的还是继续让“混合办公”安全的落地快速往前推进，继续让这个趋势往更大的范围传播和落地，并且笔者也坚信自己在这条路上越走越远。
其实笔者身边依然有一些非常好的朋友，觉得从云安全转向办公安全会不会趋势踩错了。其实笔者当时的思考是已经在云上的客户层面，窥得办公安全的苗头了，再加上当时根据2-3年的持续跟进业界发展，已经从技术趋势角度和疫情的情况下深刻感受到”混合办公“的未来已至。另外笔者在众多次跟钱磊和自化老板身上的多次深度汇报中得到了答案，其实两位老板构思了一个宏大的全局视角”混合办公“的未来版图，笔者也从两位老板深不见底的思维和体系中窥得部分观点，通过目前业界最前沿的技术趋势进行展现，让整个宏大的”混合办公“安全呼之欲出的展现给安全业界、企业、政府、金融等行业。推动着”混合办公“安全技术的快速往前发展和迭代发展。
笔者还是非常兴奋的，因为在”黑暗中”呆了很长时间（比喻，请勿对号入座^_^），终于看到一缕阳光射入，撕开了口子，而且这个口子在不久的将来会越来越亮，这种兴奋感在中年男人身上是非常难得，非常少见的。笔者也是觉得这么多年坚持追求技术，最终的归属原来就是云安全、应用安全、数据安全、攻防技术等等技术栈在“混合”办公场景下成了生命之源泉。当然笔者还是非常理智的对待自己有点控制不住的心情，但是笔者真正为之坚守的初心也许只有这一次的重塑安全的机会了。
笔者废话不多说，开始徐徐展开这幅精美的技术“画卷”。
（特此声明：此研究仅仅是个人研究行为，获取的信息也是公开情报获取，笔者从不吹嘘别人做的到位（毕竟漏洞也多的离谱^_^），仅仅是一种合理的思考问题的方法和逻辑，实现到位才是最关键的）。
**关键词：”云平台攻击“、”大一统零信任“、”身份安全“、”TPM+零信任结合技术点“、”端网云一体系化办公安全体系“、”混合办公“终局、”零信任驱动业务变革“、“全链路数据跟踪”、“数据不落盘”、“单点对抗能力提升安全水位”。
**
备注：对于大家都了解的SASE、以及零信任相关的内容就不做过多阐述。核心聚焦理想的“端到端零信任”架构设计落地方式。
混合办公安全-业务和基础设施架构分析（端网云端到端架构）：偏单点
一、混合办公-业务和基础设施架构分析
1、背景：
笔者多次啰嗦说自己跟进了好几年的云安全、身份安全、零信任等技术，但是实际还是只有云安全有一些文章的输出。本次还是重点输出跟办公安全相关的身份安全、”端到端零信任“安全的深层次的代码级设计思路。
2、业务场景和规模：
笔者还是根据之前的思路和逻辑，先讲清楚整个组织的情况，不过这次不是电商了，是云+软件+操作系统的一家虚拟大型公司SmartSoft（请勿对号入座，如有雷同纯属巧合）。
SmartSoft是一家美国上市公司，业务规模是市值2.5W亿美金，年收入2000亿美金，拥有100W+员工和外包生态合作伙伴外包，旗下业务包括操作系统、TOP的云厂商、元宇宙等业务。全球合作伙伴数量超过50W家，包括中国、印度、韩国等国家，其中云上生态合作伙伴超过约10W家，使用SmartSoft的企业用户+个人用户数量达到了15亿+。下图是微软的，可以大概参考和理解一下这个SmartSoft的复杂度。4700亿封邮件、6300亿次认证/月，下面是一些IT安全相关的数据规模CSEO（Microsoft Core Services Engineering and Operations）负责内部IT，微软内部IT规模（30种不同的操作系统、50万Linux主机、每月40万设备登录微软Corp网络、每天发生200亿安全事件）。
Source来源：https://www.microsoft.com/security/blog/2019/11/04/further-enhancing-security-microsoft/
3、组织架构：
关键点：安全是独立业务，直接汇报CEO，为整个SmartSoft安全负责，保障SmartSoft业务的正常运作的基础上，增加收入，SmartSoft CEO还是要求安全收入来体现更多价值。目前SmartSoft安全收入将近200亿美金/每年。
SmartSoft为了应对复杂的安全挑战，专门成立了SICM（安全、身份、合规和安全管理）部，直接汇报SmartSoft CEO。SICM安全总裁为了应对庞大的体系划分了合理的组织架构，SICM安全总裁下设云安全副总裁、身份安全副总裁、拉通全局的CSO副总裁。这三者的关系是，配合SICM总裁一起落地Zero Trust Architecture架构，这个思路也得到了SmartSoft CEO的高度认可，SmartSoft CEO在各种会议上讲业务的时候，安全都是最核心的底座。继续回来做云安全副总裁、身份安全副总裁的相关职责，身份是SmartSoft最核心的安全架构设计和防线，后续会讲到这一点。身份是整个SmartSoft最核心的核心基础组件，拉通云、操作系统、游戏、元宇宙、生态合作伙伴、Supply Chain供应链合作伙伴等等统一，后面详细展开这个逻辑。另外云安全副总裁主要负责SmartSoft全球前三云的安全，保证云底座的安全，由于国家级威胁体的对云的深入了解，倒逼云安全开始逐步增强纵深防御能力，例如其中一点身份要和新发布的操作系统进行绑定让身份+TPM进行整合（后面会介绍结合点），为了应对突如其来的攻击，必须要构建强大的堡垒和壁垒来抵御攻击。所以云安全副总裁会逐步跟操作系统副总裁、身份副总裁和SICM总裁一起落地整个安全体系。
4、基础设施架构解决的问题：
在阿里八年多了，学会的最终的经验就是做这件事到底解决什么问题？客户是谁？为什么需要这个？讲完规模、组织架构之后开始思考这几个问题？其实作为”背锅侠“架构师（国内）来说，思考方式非常重要，笔者自己也简单总结几个原则：安全第一性原理，到底为了解决问题而选择的方式；广度深度的深入经验，八年调岗了多个岗位，沉淀了大量实战经验；竞品分析，通过竞品分析了解领先的公司到底在做什么，结合到自己在看业界其他人最终落地拿到结果。（后续有机会会专门讲一下安全架构的思考逻辑）。
前面相信读者已经看到了，SmartSoft包含的操作系统包括Windows、Linux、MacOS、IOS、安卓等操作系统。这么复杂的操作系统上面还有对应的供应链，包括浏览器、操作系统内置的软件、员工安装的软件、研发开发工具（Solarwinds事件）、研发脚本等等。
这么复杂的终端环境下SmartSoft面临四个风险：
资产管理是SmartSoft的核心策略，理论上要通过管理所有员工的设备才能访问SmartSoft的相关业务。这里面有各种不确定的资产版本管理问题，SmartSoft的定义叫做Unmanaged（未管理）起来的资产。其实SmartSoft就管理两种状态，一种叫Unmanaged和Managed两个状态。后续再做安全能力的时候，必须终端是Managed而且是注册过的可信设备才能访问SmartSoft的统一登录。
SmartSoft这么复杂、这么多系统也经历了例如SolarWinds的这种供应链的攻击，造成了相应的内部部分核心代码遭到泄露，所以终端的攻击检测非常重要。包括操作系统漏洞、配置风险、提权、操作系统漏洞利用、被横向移动作为跳板、访问Chrome(Windows、MacOS)、Safari（MacOS）等0day和xday的利用、被钓鱼攻击利用Payload加载C&C木马。最核心的还是被利用了相关漏洞撕破边界而导致的被攻击风险。这里面的风险包括例如Microsoft Defender在Mac、Linux和Windows上做了相应的保护。第五个部分来详细展开。
在SmartSoft历史的攻击来看，大部分是想窃取云和操作系统的代码，便于国家级威胁体的后续动作。但是对于被攻击的终端来看有两个盲区，第一个就是在终端上到底包含了哪些数据（代码、凭证、账号、密码、架构图、企业内部组织架构）等确实不清晰。第二个盲区就是针对接入SmartSoft Corp网络的IOS和安卓等手机操作系统并无特别的防护手段，导致后续的数据泄露和被作为跳板机作为进入网络的核心边界突破口。
数据安全问题其实是分成两个部分第一个部分是Insider Threat内部威胁导致的数据泄露，例如恶意和别有用心的员工去窃取相应的数据达到自己的目的（变现、跳槽、自己创业等）。第二个部分是就是因为黑客攻击导致的个人范围内的数据泄露和作为跳板窃取企业的数据数据。目前有一个很明显的趋势，由于全球疫情的原因，很多员工都开始了居家办公模式，很多人的笔记本就会长时间连接到公司网络通过VPN，或者通过账号登录了企业相关的应用系统，就会造成相应的攻击面。
针对用户的网络->ISP网络->云端网络->云端网络内部风险来看，用户网络->ISP网络是属于SmartSoft的盲区，这个盲区可能会经过各个国家的网络，包括地缘政治原因，例如经过一些不可控国家。ISP->云端网络这块也有可能会被劫持到，因为ISP也在全球都有，ISP极有可能被不可控国家进行监控。云端网络->云端网络内部是自己自主可控的，风险较小。
这里的应用也是分2个层面的，第一个层面就是给企业用户接入的应用（单体应用、WEB应用、移动和桌面程序、守护进程和后端程序四类），第二个就是SmartSoft自身的应用（云控制台、生态合作伙伴、SaaS ERP Dynamics 365、SaaS DevOps、SaaS文件）。是应用就面临着RCE漏洞、SSRF漏洞、IDOR（Insecure Direct Object References）漏洞以及API越权漏洞。SSRF漏洞在云场景下是非常要命的一种攻击手法，通过SSRF可以获取到临时的STS Token进而窃取此Role角色拥有的权限进行横向移动攻击。对于IDOR和API越权漏洞来说更是难上加难，需要对业务的设计非常了解，权限设计非常合理才能完全避免掉这些漏洞，对于SmartSoft来说最为核心的Graph API也曾出现过漏洞（CVE-2021-42306：这个漏洞就是Graph服务的servicePrincipalAPI函数的keyCredential函数泄露的SIGN签名方式的私钥泄露，在keyCredential中支持两个模式一个是X509CertAndPassword SIGN的私钥签名，一个是AsymmetricX509Cert公钥的Verify模式）。对于这两种方式的攻击场景在身份中详细介绍。
其实大家对于传统的攻防风险和数据泄露风险都有很多了解，其实相信身份攻击的风险会更加有趣一些。这块也重点提一下，针对身份的攻击，笔者在之前的文章中也总结过一些。以身份构建的核心基础设施安全提升水位，已经明显在美国拜登的总统令中开始推进，而且速度非常迅速，要在3-4年完成安全水位的提升，留给我们的时间不多了。
身份的风险在于获取到一个合法的身份之后可以利用这个身份做太多的事情，身份攻击依然成为了一个新的撕开企业边界的新攻击面。身份的攻击包括Password Sparying攻击、Account Takeover攻击、钓鱼攻击。其实这些还是传统的攻击手法，由于SmartSoft的核心地位，针对它的身份攻击已经提升到了绕过MFA（软硬令牌、SMS认证、YubiKey等FIDO2认证、WebAuthn）、绕过设备认证、绕过TPM等现实中出现的攻击手法了（后面会介绍1-2个绕过的漏洞），虽然通过TPM、设备认证、MFA通过身份衍生和覆盖到终端上这一点来看，保护云平台的安全的核心点，已经逼到了终端安全上，通过终端安全->网络->云端->应用->数据的真正端到端的攻防体系。
云本身有非常多的存储，包括云块存储：Azure Blob、AWS S3存储；云数据库Azure SQLServer、AWS Aurora；大数据：AWS Redshift、Azure Synapse；还有各种NFS相关的存储。其实在云存储上出现的漏洞也是非常多的，包括著名的Azure ChaosDB Cosmos漏洞、Azure Blob和AWS S3的数据泄露更是多到吓人。云端安全云产品提供的安全功能导致的数据泄露也是不断被爆出，云产品自身的漏洞也不断爆出（可参考小飞侠的公众号的这篇文章：https://mp.weixin.qq.com/s/Ggrms8Wlm-4UeBwPIfbIYw）。
通过统一身份认证以及鉴权之后，其实还有另外一个云端的真正的“数据不落盘”解决方案。就是通过RBI和VDI的方式来在远端访问数据，这样可以让数据保存在RBI和VDI上。从这半年的针对RBI和VDI的攻击分析来看，有几个重要的攻击面，先简单写一下。
RBI攻击面，先从RBI的架构来看首先是使用统一身份认证SSO系统进行身份认证，认证过后使用Chrome浏览器工具进行执行，执行载体在Docker容器上，容器在弹性ECS上，弹性ECS在物理机只上，其实核心的架构就是这样的。只不过在实现上有很多人做的很到位而已。例如AWS可能采用Firecracker多租户模式来做、Azure可能会Hypervisor容器来做、Google可能选择gVisor来做、也许还会有其他厂商选择Kata Container来做。技术选型很多，RBI的核心是安全容器的隔离。这个里面RBI有几个重要的攻击面，身份的攻击前面已经讲到了，第二个攻击面就是浏览器本身存在相关的漏洞，包括Chrome的文件逃逸、Chrome漏洞、执行相关的命令、SSRF Meta（Docker特性漏洞，AWS、Azure、自建容器在AWS、Azure、Google等云上无一幸免）到STS Token等漏洞就会控制相应的容器，如果容器隔离没有做好，就会导致直接进行网络渗透、Docker逃逸、Docker利用ECS提权等漏洞进而控制整个RBI系统。
针对VDI的攻击其实早在好几年前就开始研究了，那个系统就叫Citrix，Citrix是最早一批做VDI的厂商。笔者针对VDI的攻击简单总结几句，之前Citrix VDI系统大部分是没有MFA的（不像今天MFA大范围支持DUO等MFA），也就是说可以通过账号登录Citrix，而Citrix VDI本身有太多的设计缺陷了，包括AD域控的渗透、内网的横向移动（网络隔离太不到位）、Citrix VDI自身也出现了非常多的漏洞（比较著名的就是CVE-2019-19781通杀漏洞，影响面巨大）。核心逻辑还是通过VDI这个边界口子进行横向的渗透，获取到最核心的域控权限，然后再往云上进行横向移动，最终进而控制整个混合云。
另外一个趋势就是美国由于SaaS非常发达，很多员工的数据全部大部分都在存储SaaS、企业内部SaaS和各种SaaS系统（HR、财务）等，其实也就证明了个人的账号拥有非常多的个人和企业数据，重点的还是企业数据，通过个人这个点可以大范围”一键“获取大量企业数据。一个人或者账号导致的风险已经越来越大了，例如一个开发拥有的SaaS（例如Lapsus$组织近期的Github和Azure DevOps的代码）泄露、云SaaS DropBox企业文件泄露、企业办公SharePoint文档泄露、企业邮件泄露、企业组织信息泄露、企业共享磁盘数据泄露等等事件，治理难度越来越大。
5、基础设施架构设计和实现：
相信大家看到了这个规模之后，心里肯定会想这么复杂、这么庞大的体量下到底如何设计，是一个非常头疼的问题。下面我们就来拆开讲一下SmartSoft到底是如何落地这个架构的。
客户端的安全设计SmartSoft根据风险设计了两套的防御体系，包括终端对抗安全体系和数据安全对抗体系。针对终端对抗体系来说：
资产管理：应对资产不全风险，通过设备管理MDM、设备注册等方式来解决数据资产不全的风险问题；
Defender防御：通过Defender的漏洞管理模块（评估安全状态分、缓解零日漏洞、漏洞补丁）、网络安全防御（Windows防火墙联动、防火墙日志查看）、攻击面削减（下载的可执行程序、运行混淆的脚本、）、Hunting能力（通过上传日志到服务端进行Hunting和Investigation）、受控文件夹保护（预防勒索和其他手法窃取有价值的数据）、AV防病毒、行为阻止（白名单体系）、终端安全基线等水位；
EDR检测：信息采集做检测覆盖ATT&CK、告警运营、事件Hunting、应急响应、海量分析师分析事件产出报告另外还可以使用SmartSoft的专家模式来做更深入的服务；
MDM设备管理：可信设备注册（Unmanaged和Managed）、远程设备管理（包含删除丢失设备）、合规性检测（满足端的零信任）、VPN管理、终端保护、条件访问、管理应用和应用保护。
通过EDR、Defender、MDM来解决攻防风险；
数据安全对抗体系：解决数据资产不可知和数据外泄安全风险（1月1日的文章再次粘贴到这里一方面是数据全链路跟踪和管控，一个是终端的外发渠道管理）：
数据全链路跟踪和管控：
SmartSoft企业面临的数据流转的问题，数据是没有边界的，数据会在任何地方进行流传，这些流转包括终端（BYOD设备、托管设备、手持设备、笔记本、PAD等）、云端（微软自身的产品Office365）、SaaS产品（SalesForces、Box）、混合云（Google、AWS、Azure）、On-Permise（线下Office）等，在这么复杂的链路上如何做好数据安全保护是一个非常难得问题，微软由于其自身的Office优势、云的优势、Office 365、SharePoint、OneNotes、Teams等的全套链路，导致它提出了一套创新的解决方案。
笔者经过大量的文档阅读，总结和抽象了对应的观点（Label And Classification Policy Built In The Files And Protection、Monitoring、Tracing By Everywhere）：
微软信息保护的目标就是所有的微软数据都会被分类、分级并且被保护的。在这个目标下微软是如何实现的。首先架构大图有了之后，肯定有一张产品大图来贯穿这个目标的，下面这个图就是贯穿目标的大图：第一步是知道数据在哪里，理解数据的态势；第二步就是保护数据应用加密、访问限制来进行控制；第三步就是保护数据防止丢失，检测数据行为和保护敏感数据；第四步就是进行数据的治理。
在这个顶层治理框架下它是如何实现目标的：Azure针对上面的目标拆成了三个部分，包括Office 365 IP保护、Windows IP保护、Azure IP保护三个部分，分别对应Office 365应用、Windows设备、第三方设备和On-Permises部分。
然后是具体的产品实现落地方式：首先微软每月有1500万的文件/邮件保护的数量，通过上面不同的IP保护产品来做。首先通过分类分级客户端打标，策略下发和自动化的分类分级策略来定义文件的策略，文件流传到云端、Office 365、SharePoint线下和SharePoint Online、Teams等的时候都可以针对这个文件的标记进行处理，而且也可以针对文件的内容进行特定的加密策略。另外笔者认为一点还不错的就是跟RMS（Rights Managements）权限管理系统和Azure AD零信任身份体系进行打通，通过文件分享到其他云的时候，可以通过本地终端等设备打开的时候进行身份认证、身份认证完之后进行权限认证、权限认证之后进行文件解密操作，最终被有权限的经过身份认证的人打开，而且文件还受到屏幕水印、打印控制等的限制，最终完成基于文件标签的信息保护体系，最终实现SmartSoft的数据安全目标。
有了大图就看一下产品落地细节：
定位：DLP 可以监视和保护处于非活动状态的文件、使用的文件以及跨 Microsoft 365 服务、Windows 10、Windows 11 和 macOS (Catalina 10.15 及更高版本的) 设备、本地文件共享和本地 SharePoint 的文件；
范围：Exchange Online电子邮件、SharePoint Online 站点、OneDrive帐户、Teams 聊天和通道消息、Microsoft Cloud App Security、Windows 10、Windows 11 和 macOS 设备、本地存储库、元数据；
渠道：检测渠道、上传到云端服务，或通过不允许的浏览器访问、复制至其他应用、复制到 USB 可移动媒体、拷贝到网络共享、复制到远程会话；
覆盖文件类型：PowerPoint 文件、Excel 文件、PDF 文件等
操作行为动作：视觉标记：页眉、页脚和水印、元数据：以纯文本添加到文件和电子邮件头。为电子邮件添加了敏感度的页脚，用于所有收件人，用来指示它适用于不应在组织外部发送的常规业务数据。电子邮件头中的嵌入元数据，邮件头数据使电子邮件服务可以检查标签，或防止在组织外部发送。
部署方式Agent：经典客户端、统一标签客户端、Office内置标签
功能：手动标记、默认标签、推荐或自动标记、强制标记、用户为标签定义的权限、对标签的多语言支持、应用信息、保护Office栏、视觉标记作为标签操作（页眉、页脚、水印）、Powershell标记、跟踪受保护的文档、吊销受保护的文档；
零信任+RMS：Login.Microsoftonline.com认证登录获取身份，通过RMS来进行授权；云端（SaaS+Cloud App Security: Microsoft Defender for Cloud Apps ）：集成SaaS API（Box、Salesforce等）进行DLP策略的延展；同时集成Defender For Endpoint做联动；
SDK：MIP SDK、RMS Client等提供给生态集成；Azure Information Protection unified labeling scanner扫描微软内部文件；
扫描方法：Microsoft 365深入内容分析（而不只是简单的文本扫描）检测敏感项目。内容按以下方法进行分析：关键字的主数据匹配、正则表达式评估、内部函数验证和与主要数据匹配接近的辅助数据匹配。此外，DLP 还使用机器学习算法和其他方法来检测与 DLP 策略匹配的内容。
最终再看一下MIP的SDK实现如何分配给生态合作伙伴的，微软MIP提供了对应的SDK，通过SDK可以让生态厂商例如Veritas、Digital Guardian、ForcePoint、Varonis等来利用MIP SDK来对文件API：文件打Label、更新Label等级、MSG标记；保护API：加密文档、解密文档；策略API：读取、写入和删除标签和保护信息的一些安全策略；
微软最终的安全体系是实现Gartner所定义的Cybersecurity Mesh产品联动。微软自己定义为Localized Intelligence。这个可以看到微软做产品的一个愿景和最终的大图，用来联动On Permises、Cloud、Mobile、DLP、分类分级、AD、UEBA、威胁情报、Malware保护和对应的DLP分类分级等。
核心的数据流转还是在企业内部、云端、SaaS进行的管控和流转，另外还是需要更多的渠道管控能力的。例如SmartSoft采取的六类渠道：邮件管控、WEB HTTP/HTTPS、打印、云端软件、可删除设备以及局域网LAN的覆盖。当然这里面覆盖的点可能达到几百个，后续有机会再深入这个链路。
针对用户的网络->ISP网络->云端网络->云端网络内部风险来看，SmartSoft还是做的非常到位的。在用户网络->ISP网络之间采用链路加密TLS方式，在ISP和云端网络之间也采用TLS加密方式，在云端网络和云端网络内部自己可控的网络采用两层加密方式，物理链路层面使用MacSEC加密底层通信网络，在4层采用和七层采用TLS等加密方式，保证在整个网络中传输的每一个数据都是加密的。
根据风险重点解决2问题：漏洞问题和数据安全问题：
**漏洞问题解决方案如下：
**
前面介绍到SmartSoft SCIM安全部为了增加营收和企业自身内部以及生态统一的安全水位采用了SaaS认证的统一身份登录服务系统，然后通过统一身份登录服务接入外部用户应用、SmartSoft内部应用（云、操作系统、游戏等等）、SmartSoft外部生态、供应链厂商、第三方、客户、用户等全部接入。其实漏洞不是最关键的，最关键的还是要保证利用这个漏洞不能真正窃取到用户的数据，一旦窃取到用户的数据可能一个漏洞级别很低的都会导致巨大的数据泄露风险。核心问题一定要SDL、数据安全、合规、隐私绑定到一起，通过SDL来撬动合规要求、隐私要求控制的转化、消化和落地。SDL其实只是一个工具，是用来解决数据安全、隐私、合规的一个通道，它本身的价值在于解决业务问题，解决了业务合规的问题，那就是帮助业务快速得到了提升，减少了踩坑。
理想的状态是GDPR、PCI-DSS等合规需求发布->拆分细则->拆到原子能力->中间技术人员参与转化成技术语言->技术点和需求->技术点DEMO->技术点融合->解决方案解决一类细则->SDL覆盖（100%覆盖）->完成闭环->满足合规->赢得业务跟业务一起发展。
从SmartSoft自身和给客户以及生态企业的应用架构来看，基本上都是采用前后端分离架构。
前端框架：前端采用JS框架Angular、Vue.js、Ember.js、Durandal.jsReact框架以及Next.js、Gatsby.js框架来布局页面和对应的后台请求；
手机框架：IOS、安卓前台；
操作系统：应用程序Windows、Linux、Mac等；
Node框架：Electron、Express Node应用
后端：JAVA、Python、.NET C#等基本上全部采用的是API架构，API架构采用上面说的应用身份和用户身份来构建两层的访问逻辑。核心其实就是通过受限用户以受限的应用身份获取对应的数据，详细细节参考下文。
身份安全治理
通过接入的SSO使用身份来做统一的接入，使用RBAC来做权限的限制，具体的实现在身份安全方案中赘述。
SmartSoft针对所有的API进行了身份限制、鉴权和IDOR的漏洞治理，同时还通过iFX注入框架，注入后端API中采集对应的调用信息，最终把这些调用链路信息透传到Cloud SIEM Kusto中，进行分析，发现API相关的异常、信息泄露等问题。
SmartSoft创新性的提出了Data Security Runtime Protection（DSRP）的框架，通过.NET C#注入技术，注入到了前端、中间件、应用程序中，核心目标有两个一个是做到数据链路追踪，一个是为了做GDPR、PCI-DSS、HIPAA等隐私和合规的要求，做到通过DSRP框架解决方案来落地数据不可见的目标。并且通过SDLC安全开发生命周期推进DSRP的推进和落地，并且在过程中沉淀了对应的解决数据安全问题的方案和能力，最终落地框架来解决更多的GDPR、PCI-DSS、HIPAA关注的隐私控制落地的能力。
由于身份是本文的最核心观点，所以单独一个小节来整理和总结。
关于云端云安全相关的安全设计，可以参考之前《鸟哥谈云安全》的众多文章，此处不再赘述。
云端数据泄露风险，目前已经成为了SmartSoft的重中之重，用户数据是生存的根本，如果客户数据泄露一次，也许跟用户、跟企业CEO建设的信任就会逐步降低。解决云端数据泄露风险的最核心本质就是端、网、云、云端、应用、权限等的全链路跟踪，溯源和SmartSoft最擅长的Security Development Lifecycle（SDLC）来真正闭环，详情请参考应用安全部分说明。
混合办公安全-身份贯穿端到端安全（核心）
**身份是新边界，身份驱动业务变革，身份也是业务构成的关键（本文的点睛之笔来源Nuke金将军），**因为身份而导致的业务变革数不胜数。后续会讲1个SmartSoft遭遇的国家级威胁体黑客攻击的窃取代码的例子，贯穿透彻全文，其实思来想去这个例子只是解决了数据安全的问题，并没有很好的体现业务，在文章最后简单一笔带过一个生态交付的CASE，来呼应这句话点睛之笔。
首先前面分崩离析的讲解了网络安全、云端安全、终端安全、RBI&VDI等内容，但是还是分散的，本小节重点讲解一下如何通过身份和一个最近SmartSoft遭遇国家级威胁体攻击来窃取代码案例来进行整体的打穿链路。
**1、在正式讲解CASE之前，还是简单同步一下身份的认证逻辑：
**
A、通过浏览器访问https://login.smartsoftxxxx.com/common/oauth2/v2.0/authorize终结点；
B、浏览器的用户输入账号密码进行登录，并且授予对应的访问权限发送到认证终结点；
C、认证终结点通过之后返回对应的Token；
D、浏览器使用在HTTP Header中的Authorization头调用Web API；
E、WEB API确认Token的有效性、失效时间、权限等，确认通过之后返回数据；
F、通过短的失效时间之后Token过期；
G、浏览器重新发起登录请求，在用户浏览器的Session有效期内刷新另外，这个时候攻击就出现了，也就是说在终端上是可以拥有这个浏览器的Session的，也就是Cookie重放攻击^_^；
H、认证终结点返回新令牌给到浏览器；
I、浏览器再通过新的令牌访问后台Web API；
OAuth2应用授权这里目前还是SmartSoft最大的攻击利用点，通过Client ID和Client Secret可以用来以应用身份获取令牌，通常这个令牌的权限较大，对SmartSoft来说存在巨大的攻击面风险。
SAML2其实是被国家级威胁体用来攻击的非常爽的工具手法，完美绕过MFA。当然SmartSoft也知道和发现这种攻击手法，针对ADFS的Golden SAML2攻击手法也增加了对抗。但是目前还是存在一个较大的攻击面，就是SmartSoft SSO单点登录支持除了ADFS SAML2认证之外，还包括Github、Salesforce等SaaS的认证方式，如果能够拿到对应的SAML2认证私钥进行SAML2 Response的推送认证攻击，就会导致可以登录SmartSoft任意的Github、SalesForce、Dropbox等应用。这个风险SmartSoft后续也需要进行持续的增强和提升。
目前SmartSoft支持包括SMS短信认证、Device设备认证、SmartCard硬件USB认证、Software Token软令牌认证、Windows Hello认证、跟操作系统绑定的TPM认证方式。下面简单说几句话说一下MFA的绕过手法。绕过SMS短信认证包括劫持短信网关、修改账号手机进行认证绕过；Device设备认证绕过通过认证协议缺陷来注册和骗过设备认证进而发放PRT主令牌；SmartCard目前没找到很好的绕过手段、Software Token软令牌攻击方式还是主要是通过推送消息让用户进行授予登录权限的暴力手段；通过TPM来进行保护零信任身份，最终历史上也存在终端被突破进而被绕过的漏洞。
PRT+TPM认证关键点：
PRT是操作系统Windows 10或更高版本、Windows Server 2016 及更高版本、iOS 和 Android 设备上 Azure AD 身份验证的认证凭证。通过PRT可以认证响应操作系统的身份，签发JWT Token进而登录SmartSoft SSO单点登录平台；
A、发送挑战请求，通过Post 终结点发送grant_type=srv_challenge请求：
B、返回Nonce响应；
C、发送对应的登录请求来获取JWT Token
D、输入账号密码；
E、最终反馈PRT主令牌：
F、TPM跟存储两个核心变量用来生成PRT：
G、通过Mimikatz获取到了Context和Derived Key
H、最终利用Context和Derived Key签出PRT主令牌：
**核心签出的核心代码如下：**通过derived_key、context、nonce来签出JWT PRT Token，进而用于后面的认证逻辑；
`def authenticate_with_prt(self, prt, context, derived_key=None, sessionkey=None):` `"""` `Authenticate with a PRT and given context/derived key` `"""` `# If raw key specified, use that` `if not derived_key and sessionkey:` `context, derived_key = self.calculate_derived_key(sessionkey, context)` `secret = derived_key.replace(' ','')` `sdata = binascii.unhexlify(secret)` `headers = {` `'ctx': base64.b64encode(binascii.unhexlify(context)).decode('utf-8') #.rstrip('=')` `}` `if not '_' in prt:` `prt = base64.b64decode(prt+('='*(len(prt)%4))).decode('utf-8')` `nonce = self.get_prt_cookie_nonce()` `if not nonce:` `return False` `payload = {` `"refresh_token": prt,` `"is_primary": "true",` `"request_nonce": nonce` `}` `cookie = jwt.encode(payload, sdata, algorithm='HS256', headers=headers).decode('utf-8')` `return self.authenticate_with_prt_cookie(cookie)` `def calculate_derived_key(self, sessionkey, context=None):` `"""` `Calculate the derived key given a session key and optional context using KBKDFHMAC` `"""` `label = b"AzureAD-SecureConversation"` `if not context:` `context = os.urandom(24)` `else:` `context = binascii.unhexlify(context)` `backend = default_backend()` `kdf = KBKDFHMAC(` `algorithm=hashes.SHA256(),` `mode=Mode.CounterMode,` `length=32,` `rlen=4,` `llen=4,` `location=CounterLocation.BeforeFixed,` `label=label,` `context=context,` `fixed=None,` `backend=backend` `)` `if len(sessionkey) == 44:` `keybytes = base64.b64decode(sessionkey)` `else:` `keybytes = binascii.unhexlify(sessionkey)` `derived_key = kdf.derive(keybytes)` `# This is not ideal but further code expects it as hex string` `return binascii.hexlify(context).decode('utf-8'), binascii.hexlify(derived_key).decode('utf-8')`
条件访问核心是通过设备安全、实时风险、应用程序状态，来决策能否访问后端应用和数据、是否需要开启MFA和禁止访问后端应用和数据。
SmartSoft通过设备安全状态包括漏洞、托管状态、基线水位、安装风险软件、告警是否处理完成等200+条件来进行判断；
A、通过Azure RBAC来控制对云的细粒度访问，包括条件、访问行为和规则；
例如：
`(` `(` `!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})` `)` `OR`` (` `@Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name]` `StringEquals 'blobs-example-container'` `)``)`
最终的结果就是：以下条件包含“读取 Blob”操作。 该表达式检查容器名称是否为 blobs-example-container。
B、通过Azure AD RBAC来控制对SmartSoft服务的访问：
例如SharePoint Online相关的读取和写入权限、Exchange Online的读取邮件的权限、Azure AD的用户读取和写入、目录读取和写入等200+个细颗粒度的权限控制。
2、国家级威胁体代码窃取模拟案例
首先国家级威胁体进行目标推演：核心是拿到SmartSoft的云（包括SSO登录代码、Intune终端管理代码、SmartSoft安全代码）和操作系统的代码。
利用自研的ASM（攻击面管理）工具进行边界探测，发现重要的核心云业务的托管SaaS AD存在用户猜测漏洞，通过踩点发现了大量SmartSoft的用户；
通过网络流量大数据、NSA类似量子注入技术等手段获取到了账号密码，在登录过程中遇到了MFA的强力阻断，因为单点技术的对抗而提升水位的案例极其稀少，国家级威胁体进行了MFA的强力研究，目前假设是国家级威胁体利用NSA类似的量子注入技术获取到了SmartSoft的一个账号权限比较高的办公PC。因为账号权限相对比较高，这个中等管理员的PC（WIN11）上通过TPM来进行保护账号，国家级威胁体通过CloudAP+Roadrecon最终在本地PC上获取到了PRT主令牌，最终绕过MFA进行了登录；
通过PRT主令牌登录之后，访问了Azure DevOps SaaS服务VisualStudio服务，访问了其中SmartSoft的相关代码，但是由于代码权限的设计，国家级威胁体只拿到了少量的部分代码，任务以失败而告终。但从泄露的少量代码中，能否发现新的攻击面我们拭目以待。
3、“端到端零信任”驱动业务变革
既然提到了”零信任“是会导致业务变革的核心点，那就简单描述一下其中的一个业务是如何通过身份来管理的：
A、SmartSoft为了给客户提供操作系统安装、软件安装、云产品售卖服务，为渠道商、三方合作伙伴、云生态公司搭建了统一身份认证平台，所有的人都通过统一的认证之后访问不同的业务系统，完成SmartSoft收入的90%都是这些人贡献的目标；
B、渠道商、三方合作伙伴、云生态公司利用已有的权限来访问SmartSoft的客户列表，通过受限制权限的有限访问，来挖掘更多的潜在客户和本土客户；
C、挖掘到客户之后，这些人通过SmartSoft在统一身份的应用中学习Workshop、交付文档、SOP指南等，让这些人可以利用自己的渠道去让客户成单；
D、客户下单之后，通过财务系统上报SmartSoft，SmartSoft通过这个平台来让售后工程师在所在的城市中进行上门安装、调试、售后服务等；
E、客户安装完成之后也可以通过反馈到这个系统中，其实就是通过统一身份认证的多个系统中完成业务交付和流转动作，保持业务的持续、高效、快速的数字化运营方式产生商业价值。安全是最核心的底座，这也是SmartSoft CEO的一致对外理念灌输。
混合办公安全-“三年”技术落地趋势推演
1、打通终端安全、身份安全、应用安全和数据安全全链路安全，通过身份来串联和落地“端到端零信任”。让终端安全状态上报“端到端零信任“大脑，让身份、权限来决策和条件访问应用系统里面保存的数据。
2、通过解决数据安全问题来撬动基础设施安全、应用安全的变革和解决方案的沉淀，让应用安全、基础设施安全、数据安全达到融合状态，互相绑定减少数据安全泄露的影响。
3、沉淀应用安全解决方案Data Security Runtime Protection（DSRP），注入中间件、应用等完成数据安全合规和安全诉求。
4、升级SSO到强MFA对抗，最终跟操作系统（TPM）进行融合，让对抗升级到能防御国家级威胁体攻击。
5、混合办公应用推到互联网，接受互联网的洗礼，让“端到端零信任”对抗升级。
混合办公安全-总结
本文主要有几个核心观点再次总结抽象：
1、“端到端零信任”是从操作系统TPM->终端安全->身份安全->应用安全->数据安全的一个联动的、集成的、紧密结合的端到端的安全体系。
2、数据安全需要跟基础设施安全（应用安全SDLC、基础设施安全）进行绑定：核心路径是GDPR、PCI-DSS等合规需求发布->拆分细则->拆到原子能力->中间技术人员参与转化成技术语言->技术点和需求->技术点DEMO->技术点融合->解决方案解决一类细则->SDL覆盖（100%覆盖）->完成闭环->满足合规->赢得业务跟业务一起发展。
3、“端到端零信任”终究还是有最核心的对抗技术的，通过这个最核心的攻防对抗技术（例如TPM和身份的绑定）来达到提升国家安全水位的目标。
4、“端到端零信任”终究还是需要跟可信TPM进行打通，跟底层操作系统打通保护最核心的认证。
5、SmartSoft为了提升云安全的水位，被国家级威胁体步步紧逼把安全扩展到了终端操作系统上，在操作系统层面展开了激烈的对抗。
6、让终端安全状态上报“端到端零信任“大脑，让身份、权限来决策和条件访问应用系统里面保存的数据，完成大一统联动串联。
7、形成纵深防御体系（拿到账号密码需要过MFA、MFA过了需要设备认证、设备认证过了还需要条件访问，条件访问过了还需要过权限和管理员授权）+单点对抗体系（TPM+身份融合核心点对抗技术）。
8、最核心的还是身份是新边界，身份驱动业务变革，身份也是业务构成的关键技术。
“端到端零信任”攻防发展到何处激烈程度、笔者和众多伙伴们的落地结果如何，我们拭目以待。
本文行文仓促，后续还会有更多版本的迭代和改进，期待读者可以一起讨论其中问题并一起落地真正的“端到端零信任”架构，通过3-5年可以让国家安全关基水位提升。
再次感谢读者您的耐心阅读。
本文完！！！