2021年安全架构总结以及2022安全方向展望

更新背景

• 为什么更新本篇？

笔者定这个选题还是特别兴奋的。因为过去的2021年发生了众多重大安全事件。笔者这一年也成长的非常迅速，这一年也学习到了非常多的优秀的安全解决方案、攻击手法、安全架构方面的内容。所以笔者想借着三天假期时间，把笔者这一年自身成长的东西也分享给安全圈，能够让更多人看到笔者为之兴奋的东西，让大家一起兴奋、一起落地、一起成长。

笔者彼此更新的内容，都是通过自身的工作经历+工作上兴趣爱好收集的相关的内容，其中有自己落地中的一些心得体会、也有一些根据工作内容扩展出来的一些内容，笔者相信这篇内容肯定会让大家眼前一亮，原来2021年发生了这么多有趣的事情。笔者的内容主要分成两个部分，第一部分是过去的2021年笔者到底看到了什么不错的安全架构、安全攻击手法、安全技术（微软的零信任身份的安全架构升级、CrowdStrike的EDR+EPP+DLP+零信任的融合以及到底运营强在哪里、我看到的Amazon的用户驱动的安全架构、我看到的微软顶层架构的实施到底如何实施的、微软全链路数据跟踪的终态架构、API安全的漏洞到底有哪些、数据不落地的终局安全架构）；第二部分是对2022年做一个简短的安全趋势判断，等到2023年的时候笔者和大家一起来回看2022的总结和对应的安全趋势的分析。

（特此声明：此研究仅仅是个人研究行为，获取的信息也是公开情报获取）。

2021安全架构总结-身份+零信任篇

一、2021安全架构总结-身份+零信任篇

1、背景：

笔者在某威胁情报500人大群中讲过一个CASE，就是说在2019年疫情刚开始的时候，讲了一个TOP500的故事。这个故事是这样的，2019年疫情期间对云安全做调研的时候，想到了一个简单的思路，就是通过TOP500的资产主要是IP、域名、邮箱等所在的云进行调研，根据一个月的调研，笔者敏锐的发现了Azure的增长比较迅速，从10%快速增长到了35%左右，目前这个数据可能会更加的恐怖，当时看到这个数据之后，就对零信任产生了浓厚的兴趣，也就是在2018年的时候跟相关的人员一起讨论过零信任的落地方式，所以笔者也就是在2019年开始再加上之前在某游戏公司看到的商业化软件的安全技术趋势来看，针对Azure展开了为期3年多的技术分析和持续观察。其实有些时候身边的很多朋友很奇怪为啥能够了解这么多内容和观点，其实都是基于公开情报持续的分析、加上自身所在的环境、自己的思考和理解的总结提炼而成。

商业化软件攻击趋势就是笔者在2013年某家游戏公司任职的时候，当时正在实施CA Siteminder、Oracle Peoplesoft、Oracle EBS等商业化软件，那时候由于身处信息安全部，所以对这些产品进行了渗透测试，发现了众多严重的安全问题，包括Oracle Peoplesoft信息泄露、环境克隆导致的Cookie秘钥一致进而登录PS管理员漏洞、代码执行漏洞、Oracle iScript脚本SQL注入等高危漏洞，笔者当时就发现了在这些商业软件上是没有防御软件的，从2013年开始，笔者就开始关注商业化软件的攻击趋势。

2、微软面临的攻击水位

自从SolarWinds漏洞被大规模利用以来，其实针对云的攻击已经开始准备被暴露和利用，在2020年和2021年的SolarWinds背后的APT国家级威胁体一直在针对云进行各种深层次的、深入的、持续的APT攻击。下面简单回顾一下针对云的攻击：

• Microsoft 365（Azure AD） SAML2 Golden Attack

在SolarWinds攻击中，笔者看到了针对微软云的一种非常高级的攻击手法，那就是针对Microsoft 365的SAML2 Golden攻击手法。这种攻击手法有几个亮点：UNC2452（FireEye命名APT国家级威胁体）的攻击路径从线下混合云的On-Permises或者IDC机房获取到本地ADFS的权限并且获取Token-Signin登录证书（通过ADFSDump来获取PrivateKey和Encrypted Token Signing Key）->利用ADFSpoof伪造用户登录凭据->利用Burp等工具来进行重放攻击->从线下ADFS获取登录到Microsoft 365、Azure AD、Azure的SAML2登录Response协议请求->登录成功。

大家可以看到这里还比较懵，为什么会出现这样的漏洞？上面讲完了基本的攻击手法之后，来看看最根源的问题在哪里？Microsoft是一个庞大的生态，支持复杂的生态登录体系来进行打通，SAML2是一个非常用户身份认证和授权的标准协议，通过SAML2打通微软生态身份提供商（IDP）到可以登录微软相关各种服务提供商的登录链路（SP）。自然而然有对应身份服务提供商IDP相关的SAML2登录私钥都将会是一个重大的威胁，通过获取IDP SAML2（ADFS自然也是一个IDP）的私钥就可以登录到Microsoft（Azure AD、Azure）。

另外这个漏洞还有一个极其重要的额外影响，通过SAML2登录的账号可以Bypass MFA多因素认证、就算用户密码修改了也不会影响SAML2 Golden登录、获取到IDP私钥之后可以在任意地方进行构造请求、重要的是IDP私钥更新的频率不是特别的高。所以后果就是Azure在SolarWinds的攻击中被窃取了Azure 组件的一个小子集(服务、安全、身份的子集)、Intune 组件的一个小子集、Exchange 组件的一个小子集的相关代码。其实笔者还未看到有人分析国家级威胁体UNC2452获取这些代码的逻辑，今天笔者首次也简单纰漏一下，如果读者已知道，请不要吐槽。Azure其实是作为国外云的TOP2云厂商，自然得到了政府、金融、军队等高敏感行业的青睐，再加上Microsoft自身的生态包括Office、SharePoint、Teams、Windows操作系统等，让Azure的份额逐步的快速覆盖和提升。所以在此规模下针对Azure云平台、云服务的攻击是非常重要的，所以国家级威胁体获取的第一部分Azure组件包括服务、安全、身份的子集，因为身份更是Azure基础设施中的关键基础设施，自然Azure AD的代码更受攻击者的锤炼，安全更不用说了，如果国家级威胁体想要攻击Azure必然需要绕过各种的检测手段。第二部分Intune泄露的子集也是比较重要的一块，因为Intune主要是微软提供给客户的MDM工具，很多TOP 500强都在用Intune甚至微软支持的生态VMWare Airwatch等来进行设备管理，因为在Azure如果没有经过设备认证的话是无法登录的，这一层是获取到密码之后也必须要突破掉的，所以国家级威胁体要获取Intune的源代码，来寻找对应的漏洞进行MFA的Bypass和设备认证和管理的缺陷来管理大批量的设备。第三部分就是Exchange的代码子集了，Exchange最近两年漏洞频发，事发原因主要还是因为Exchange主要是各大企业邮件入口，具有较高的价值。所以综合判断，国家级威胁体获取这三部分的代码，是为了发动更大的攻击而做的准备。

• 针对云平台的攻击升级

首先看一下Mandiant针对SolarWinds国家级威胁体发布的公告的几点：自2020年以来，多个技术解决方案、服务和经销商公司被入侵（证明攻击范围已经扩展到了企业重要供应链链路、托管服务和技术解决方案供应链）、获取到权限后利用云攻击下游企业、使用更多的猥琐的招数来Bypass微软的机制（包括IP地址跟被攻击企业的重合、MFA推送使得用户点击等）；

下面来具体看看攻击手法：

针对Azure攻击环境的高级攻击手法包括：利用获取的技术解决方案、服务和经销商的供应链公司的托管权限（Managed Services Providers），利用Azure Run Commands功能来执行对应的命令执行动作。通过Azure Run Commands来执行对应的Stage1和Stage2阶段的攻击Payload，进而通过MSP来进行入侵下游企业的目的。有读者肯定奇怪到底如何下发？其实两个步骤，第一步需要获取Azure对应的账号、密码和对应的MFA，然后通过az vm run-command来进行对应的Payload下发，进而达到数据窃取的目标。

• 针对API安全攻击的升级

• 国家级威胁体的ATT&CK TTPS（来源Mandint）

ATT&CK Tactic Category	Techniques
Resource Development	Acquire Infrastructure (T1583) Virtual Private Server (T1583.003) Compromise Infrastructure (T1584) Stage Capabilities (T1608) Link Target (T1608.005) Obtain Capabilities (T1588) Digital Certificates (T1588.004)
Initial Access	Phishing (T1566) Spearphishing Attachment (T1566.001) Spearphishing Link (T1566.002) External Remote Services (T1133) Valid Accounts (T1078) Trusted Relationship (T1199)
Execution	User Execution (T1204) Malicious Link (T1204.001) Malicious File (T1204.002) Command and Scripting Interpreter (T1059) PowerShell (T1059.001) Windows Command Shell (T1059.003) JavaScript (T1059.007) Scheduled Task/Job (T1053) Scheduled task (T1053.005) Windows Management Instrumentation (T1047)
Persistence	Boot or Logon Autostart Execution (T1547) Registry Run Keys / Startup Folder (T1547.001) Shortcut Modification (T1547.009) Scheduled Task/Job (T1053) Scheduled task (T1053.005) External Remote Services (T1133) Valid Accounts (T1078)
Privilege Escalation	Process Injection (T1055) Access Token Manipulation (T1134) Token Impersonation/Theft (T1134.001) Boot or Logon Autostart Execution (T1547) Shortcut Modification (T1547.009) Valid Accounts (T1078) Scheduled Task (T1053) Scheduled task (T1053.005)
Defence Evasion	Process Injection (T1055) Access Token manipulation (T1145) Indicator Removal on Host (T1070) Hide Artifacts (T1564) Hidden window (T1564.003) Indicator Removal on Host (T1070) Clear Windows Event Logs (T1070.001) File Deletion (T1070.004) Timestomp (T1070.006) Obfuscated Files or information (T1027) Indicator Removal from Tools (T1027.005) Virtualization/Sandbox Evasion (T1497) System Checks (T1497.004) Modify Registry (T1112) Deobfuscate/Decode Files or Information (T1140) Reflective Code Loading (T1620) Valid Accounts (T1078)
Credential Access	OS Credential Dumping (T1003) NTDS (T1003.003) Keylogging (T1003.001)
Discovery	System Information Discovery (T1082) File and Directory Discovery (T1083) Account Discovery (T1087) Local Account (T1087.001) Domain Account (T1087.002) System Network Configuration Discovery (T1016) Virtualization/Sandbox Evasion (T1497) System Checks (T1497.001) System Owner/User Discovery (T1033) System network Connections Discovery (T1049) Network Service Scanning (T1046) Process Discovery (T1057) System Service Discovery (T1007) Permission Groups Discovery (T1069) Software Discovery (T1518) Query Registry (T1012)
Lateral Movement	Remote Services (T1021) Remote Desktop Protocol (T1021.001) SSH (T1021.004)
Collection	Archive Collected Data (T1560) Archive via Utility (T1560.001) Data from Information Repositories (T1213) Sharepoint (T1213.002) Input Capture (T1056) Keylogging (T1056.001)
Command and Control	Web Service (T1102) Application Layer Protocol (T1071) Web Protocols (T1071.001) DNS (T1071.004) Encrypted Channel (T1573) Asymmetric Cryptography (T1573.002) Non-Application layer Protocol (T1095) Non-Standard Port (T1571) Ingress Tool Transfer (T1105)
Exfiltration	Data Transfer Size Limits (T1030)
Impact	Service Stop (T1489)
Discovery	System Network Configuration Discovery (T1016)

3、身份/零信任的安全架构升级（终态打通身份、应用、数据、操作系统等）

其实不仅仅是微软遭受了攻击，包括PingIdentity、Okta等SSO都遭受了各种攻击，所以针对零信任的攻击笔者敏锐的观察到未来一年会越来越频繁。

微软的零信任之前讲过很多内容了，今天就不展开更多花哨的大图来讲解了，就重点讲一下Azure面对零信任攻击的体系化解决方案：

• 用户身份认证升级：记得2019年年底2020年初的时候，整个身份认证的层面还仅仅是账号密码等手段，因为疫情的攻击的增加和复杂度的增加，导致很多厂商进行了升级，最直接的就是Azure支持MFA认证，而最典型的就是Intune的身份认证体系，利用账号密码登录Azure之后需要绕过Intune、短信等MFA认证方式（这里其实有一个很有趣的点，就是很多公司为了节约成本，会买Microsoft E3的License，因为E3的License安全性相对来说较低，所以从这个点来看想要高强度的安全需要砸下去很多的金钱才能达到相应的安全水位），Intune还仅仅是微软自己的设备认证，同期微软还是支持VMWare AirWatch、Jamf Pro等。最高级的一个终态方案就是跟Windows生态打通，通过Trusted Launch可以在云上使用vTPM保护Windows Server，增强Rootkit对抗成本、可信启动、验证底层云平台的可信链路传递以及提供对应的Azure远程证明能力。Windows 11的发布（如下图）就是Azure已经悄悄支持的远程证明的操作系统。Windows 11远程证明的最主要目的就与Azure远程证明服务进行整合，这说明能够在让客户访问对应服务之前验证客户的身份和安全状况。举个例子来说一台带有TPM和安全启动的Windows 11机器可以通知Azure AD针对机器上的安全选项进行配置，也就是说让终端访问应用程序/数据/服务之前生成一个证明令牌，然后才可以访问对应的服务。最终达到零信任跟身份、应用、数据、操作系统本身的融合。另外一个值得说的就是Azure内部也使用了微软的Azure AD+零信任的解决方案，Azure内部使用的逻辑是这样的，Azure和微软自身的员工和生态（Supply Chain）提供商登录应用必须强制开启手机验证码MFA，这是一层基本的防御手段；第二层如果是Azure的管理员访问Azure的应用必须使用Redmond的硬件USB Key来进行登录Azure后台管理，也就是说普通的手机MFA验证是无法访问后台管理业务的，另外一个变态的点，笔者在公开的一篇Paper中看到，Azure登录管理员控制台还需要对应的特权管理终端类似我们的堡垒机，特权管理终端（Privileged Access Workstation PAW）也需要支持RedMond硬件验证，笔者从攻击者视角发现RedMond的攻击难度还是相对比较大的，因为前提是攻破证书服务认证体系才可以，所以可想其难度。

2021安全架构总结-安全架构落地篇

一、2021安全架构总结-安全架构落地篇-顶层设计->产品设计->技术实现

笔者在2021年也发生了一些职责上的变化，从云安全开始扩展技术栈到云化办公安全体系，所以笔者也会重点讲一下云化办公安全体系相关的内容。

1、顶层设计

首先要讲透云化办公的安全体系，其实重要的分解步骤还是要从顶层设计->战略执行->战术落地->持续运营的体系化打发。笔者今天分享一下微软办公安全的顶层设计。首先上一张大图，是微软面临的威胁、团队、安全产品和对应的顶层设计。首先微软的IT数字化转型团队就是微软CSEO（Microsoft Core Service Engineering and Operations）团队目前已更名为Microsoft’s Digital Transformation数字化转型团队，微软的IT部门目前正在进行数字化转型的动作。先看来看一下整个微软的IT规模：内部支持30+种不同的操作系统、大概50W+ Linux主机提供服务、每月40W+设备登录微软企业Corp网络、这个规则的网络下大概每天发生200亿的安全事件。为了应对这些安全事件，CSEO团队设计了1600+不同的支持供应链、安全、财务、人力资源等的产品和工具，其中安全的将近50+产品，其中主要包括（Password Management、OneIdentity、JIT Access、MyAccess、Geneva、Jarvis、JumpBox、Kusto、PilotFish等等等），其中把这些工具分成了六大类别，包括身份、遥测数据、风险管理、评估、设备安全、信息保护。

从下图可以看到风险管理主要是：

• 风险管理：目标是所有的互联网攻击面接口是合规的、Tier 1主要的服务具备韧性（配套的安全服务：业务响应和公关管理、合规、企业风险治理和风险管理、安全教育和培训、安全应急响应、安全标准和默认配置安全）
• 安全保障：目标是提升云安全能力（配套的安全服务：基础设施和应用安全、新兴安全产品、外部评估、红蓝军对抗、渗透测试、供应链安全）
• 身份管理：目标是保护管理员、消除密码，身份认证，访问管理，身份治理要简洁（配套的安全服务：管理员角色服务、认证、证书管理、凭证管理）
• 设备健康：目标是进化终端保护、只允许健康的设备访问、零信任网络（配套的安全服务：终端保护、钓鱼保护、SAW HRE、漏洞管理、虚拟化）
• 数据&遥测：目标是通过用户异常行为进行检测威胁（配套的安全服务：
  
  
  数据智能、安全智能平台、安全监控、威胁情报）
• 信息保护：目标是所有的微软数据都被分类、分级并且被保护的（配套的安全服务：DLP、内部威胁检测）

2、产品逐层落地

在讲解产品逐层落地之前还是先看一下企业面临的数据流转的问题，数据是没有边界的，数据会在任何地方进行流传，这些流转包括终端（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零信任身份体系进行打通，通过文件分享到其他云的时候，可以通过本地终端等设备打开的时候进行身份认证、身份认证完之后进行权限认证、权限认证之后进行文件解密操作，最终被有权限的经过身份认证的人打开，而且文件还受到屏幕水印、打印控制等的限制，最终完成基于文件标签的信息保护体系，最终实现微软的目标。

有了大图就看一下产品落地细节：

• 定位：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分类分级等。

二、2021安全架构总结-安全架构落地篇-客户需求驱动的安全架构

笔者在调研Amazon安全架构的时候，发现了一个颠覆三观的一个认知。从Amazon办公安全体系大家是不是看懂了些什么？先上个大图感受一下，然后笔者在分享一下观点。相信读者看到图应该能看到了。AWS办公安全体系还挺有特色的，基本上重点都是在客户关心的一些点上发力。其实笔者在2021年看到这个特点，还是比较震惊的，其实也可以想象到，AWS的PPT从来都是讲客户关心的问题，很少有体系化，这个特点跟微软形成鲜明对比。

AWS办公安全架构几个特点的从客户角度驱动的就是应用安全中有几个微创新，第一个特点应用安全上的一些微创新是在研发部门里面设置VIP业务和个人，针对VIP业务和个人开展更多定制化审核。另外在AWS的应用也是分级的，例如代码审核、渗透测试、安全测试必须强制执行。但是应用安全有对应的应用风险分类分级，并且在Anvil中可以定义和自动化的识别哪些需要代码审核和渗透测试以及安全测试。如果应用安全级别较低，可以通过采用低级别的策略，例如采用外部20+供应商进行代码审核、渗透测试等。所有的威胁建模、代码审核、渗透测试、安全测试的所有安全问题必须修复，或者按照风险接受的流程来走对应的风险接受的逻辑，并且有管理层的参与。第二点就是客户驱动关心客户角度的包括客户反馈/沟通/消息的回复和审核机制、针对AWS Gov政府云Region的独立安全运营设计MVP客户，针对STP行业中的龙头企业设置MVP Oncall方案，设计内部安全产品的时候从对客户售卖的角度来思考问题和架构等等从客户视角需求来构建的安全体系。

最后再说一下AWS的创新和安全规划迭代思路：

• 6页纸&OnePage文化：取消PPT文化，安全设计和对应的解决方案，细节的安全技术设计全部采用Word，直接对Word来分析逻辑；同时通过OnePage一页纸方法提前投放产品到市场看客户反馈、看客户需求、然后不断进行迭代；

• 安全规划思路：安全规划的未来的全部依靠目前遇到的一些问题来反推，例如SIEM的更新和架构升级来源目前一线员工的声音，这些一线员工带来真正的问题，输入给战略层，战略规划一线人员比例很大，这样可以给到管理者很好的输入。通过一线员工输入的声音和问题，来提出对应的解决方案，解决方案参考的是业界方案，但不完全照抄，而且按照自己的情况分解。

2021安全架构总结-数据不落地安全架构升级

一、2021安全架构总结-数据不落地安全架构升级

笔者今年看到一个大的安全架构创新就是针对Amazon（仅仅是多渠道沟通了解，未做验证，仅从安全架构考虑）的架构进行了一些了解，事实到底如何笔者也觉得需要更多考证和反馈，但是笔者觉得如果是真的话，那Amazon的办公安全还是非常领先的。

首先上一张通过分析的大图：核心思路就是先定义基本的安全策略，包括隐私策略、数据分类分级策略、加密策略等，具体实现上在本地瘦终端上不存数据真正把数据存储在云端而不落地本地磁盘，最终把对应的数据存储到云端上，另外云端的代码和文档都会有对应的Cloud9 IDE在云端开发，通过Quip进行文档的SaaS化协同；另外针对这些应用的数据安全不落地上采用对应的产品来保证，例如MidWay-Auth是类似Azure零信任的一套员工身份管理体系、BehavioSec是采集应用对应的鼠标、屏幕等动作来发现异常行为和AI监工、应用存储到云上之后使用Cloud TAG来给资源打上对应的Label，针对这些Label可以设计不同的数据安全策略，例如AWS S3 Bucket上Label是Top Secrets则增加更强的身份认证和对应的加密保护等。另外在应用安全上也会针对应用采用统一的安全框架，把应用中保存的数据存储到S3上，针对S3采用Maice来进行对应的自动化数据安全分析等；最后数据结构化存储和非结构化存储的数据安全，非结构化的包括SageMarker Ground Truth做到分类分级，同时利用Amazon Mechanical Turk来进行对应的人工分类分级（50W供应商），光一个分类分级就做到了这种体量，同时分类分级还支持内部员工的标记和AWS Marketplace部分的供应商来做。针对数据存储还包括S3、DynamoDB、Redshift等，不过从分析角度来看Amazon针对RDS、Aurora、DynamoDB、Redshift的数据安全体系还是存储安全、传输安全、Label资源标记等，针对数据表的分类分级等数据安全能力还在逐步完善当中。（参考Oracle Vault Label安全：https://www.oracle.com/database/technologies/security/label-security-factors.html） 

• 安全目标：Humans and Data Don't Mix（任何数据分离，减少人员手工和通过系统接触数据的机会）；
  
• 安全策略：包含隐私策略、数据分类分级策略，会非常细致，而且所有后续的动作都来源这些策略，策略的重要性是能够执行；
• 终端安全：终端理论上要求不落盘任何数据。采用的是Amazon的瘦客户端，其实也是对应的笔记本和对应的相关设备；
• 云端DevOps：采用Anvil追踪应用安全需求（根据数据分类分级策略来设计对应的应用安全审核落地）、Cloud9 IDE（Amazon所有的代码必须要在云端进行编写）；TestRail和Quip是对应的测试和文档协同，采用内部云、开发云的情况来分析；
• 生产应用：MidAuthWay、BehavioSec（采集鼠标、剪切板等信息来查看员工的对应的行为，为UEBA做输入）、Cloud Tag打标签；
• 数据存储：非结构化的（根据标签、存储所有文件在S3上利用SageMaker Ground Truth来进行分类分级，并且分类分级打标签有三级逻辑，第一级Amazon Mechanical Turk 50W供应商、第二级内部IT和员工打标签、第三级是AWS Marketplace也有对应的厂商来进行）、结构化的包括数据库Amazon Aurora/DynamoDB和大数据的Redshift等；
• 最终解决的问题：代码/文档/非公开等级的数据不落盘、UEBA行为检测异常文件和行为、利用应用安全体系+自动化来减少人手工、登录系统、查询应用等造成的数据泄露。

2021安全架构总结-终端安全大融合篇

一、2021安全架构总结-终端安全大融合篇

笔者2021年选择了扩展自己的技术栈，同时也被阿里办公安全团队自化老师的宏大愿景而吸引，选择了办公安全。笔者还是非常感恩能来到这个团队，经过这个团队不到半年的打磨和梳理，笔者也看到了阿里办公安全在云化办公体系上的打磨和沉淀，由于会牵扯到内部策略，后续跟团队老板商量择机发布阿里巴巴办公安全体系框架，还是一张非常宏伟的蓝图和规划，并且当下阶段也做到了比较领先的水位。

今天不讲阿里办公安全的趋势，今天只讲外部看到的包括Gartner和CrowdStrike近期的布局来看。从下面的图可以看到EPP、MDM、EDR、MTD还是在不同的分散的终端上进行独立的发展，而Gartner在2019年也敏锐的发现了未来肯定是统一的终端管理、统一的安全能力，并且是跨平台、跨能力集成的一套整体的解决方案。

来源：Licensed for Distribution（https://extralink.com/PartnerZone/GartnerEndpointEvolution.pdf）

第一个趋势其实目前从CrowdStrike的角度来看他们的端还是在分散框架编写的，其实现在业界有很多企业开始统一开发框架、跨平台进行采集、跨平台的安全能力设计融合了。而且另外一个重要的趋势就是除了EDR、EPP、MDM、MTD进行统一的融合之外，DLP数据安全能力也开始成为内生于终端安全的能力了。所以未来肯定是一个端包含以上能力，这就对开发能力提出了巨大的挑战，而且需要持续的投入和跟进才能达到对应的产出。

第二个趋势就是MacOS的端的需求开始急剧加速，需要在MacOS上开发出EDR、EPP、DLP、MDM能产品能力，这个市场是一个开拓者的市场，相信未来2-3年会有大批的玩家和厂商入场。

第三点趋势就是数据采集之后的数据价值的挖掘，包括Humio数据采集能力等，详细的内容可以参考《网络安全观的CrowdStrike：零摩擦、零信任》文章，但是笔者仅有工作带来的更远一点的想法，除了网络安全观公众号提出的XDR、自动化编排、日志管理等能力之外，笔者观察到的是EPP、EDR、XDR、DLP的融合，更远一步的就是除了融合之外的开发框架的统一。这块阿里办公安全还是稍微走在了前面，在框架选择、协议设计、一体化框架、数据化分层运营、数据链路体系化跟踪上做到了一些较强的能力。最后再分享一笔者看到的CrowdStrike应对Microsoft Exchange 0DAY的精彩逻辑：在2021年3月4日，微软补丁日发布了Exchange 0day的升级补丁，由此引起的腥风血雨也在世界各地上演，看CrowdStrike是如何运营这个事件的。

• 发现攻击：从2021年2月28日星期日开始，Falcon OverWatch的威胁狩猎团队（号称3000人的团队）看到了新的入侵的初步迹象。威胁狩猎观察到一个未知的攻击者在未经授权访问的情况访问多个客户环境中的主机上运行Microsoft Exchange应用程序池的情况，第一时间CrowdStrike团队开始通知受影响的组织。Falcon Complete团队立即开始深入调查该威胁的性质，进行最终的定性；

• 初始化访问：CrowdStrike Falcon控制台的初始检测显示了一个可疑的命令行，与常见的webshells行为一致；

• 定为被攻击程序：通过威胁图谱，OverWatch将"W3WP.EXE"进程标记为恶意的，因为观察到此进程试图利用名为 "MSExchangeOWAAppPool "的Exchange应用程序池来创建执行的命令，最终被Falcon代理自动阻止；

• EDR数据调查：Falcon代理提供了丰富的端点检测和响应（EDR）遥测数据，对每个端点的行为提供了关键的洞察力。CS的端点活动监控（EAM）应用程序使Falcon Complete团队和Falcon平台客户能够实时搜索这些执行数据，并迅速调查和确定入侵的程度，通过EAM数据发现了磁盘写入的数据，这个里面可以看到对应的Meta，根据Meta可以做对应的规则；

• 离线下载文件：Falcon Complete通过终端窗口的实时响应工具（Real Time Response tool）分析这些文件，下载这些文件进行进一步的离线分析；

• 内存提取Payload：通过OverWatch团队的内存dump工具，提取IIS Post的内容，最终确定了漏洞利用Payload和黑客团体攻击的详细的情况。

• 复制其他客户：完成最终响应并且同步规则到其他的客户，由于是SaaS版，第一时间客户就具备了防御此次Exchange 0day攻击的防御能力。

• 参考：https://www.crowdstrike.com/blog/falcon-complete-stops-microsoft-exchange-server-zero-day-exploits/
  

2022安全展望

笔者终于在6个小时内完成了上面的内容，自己在梳理的过程中还是又学习到了非常多的点。作为最后的一个小节，笔者在2022年年初也大胆预测一下：

1、云上攻击会越来越深入，影响越来越大：从上面的内容可以看出针对云上的攻击者，越来越多的国家级威胁体开始研究和攻击，所以云平台、云产品的安全会在2022年被更多的曝光，云的攻击逐步开始深入，包括WIZ多次报告微软等云平台漏洞，国家级威胁体也多次利用云特性漏洞攻击，国家级威胁体开始随着客户的迁移而把攻击转移到云端，云特性漏洞攻击会成为主流攻击趋势，2022我们拭目以待；

2、终端安全新赛道：终端安全上的MacOS安全成为新的安全赛道，安全厂商需要加速投入力度；终端安全EDR、EPP、DLP进入融合时代，今年CrowdStrike的趋势明显感觉这个趋势更加明显；

3、办公安全市场开始崛起成为元年：办公安全市场国内体系化打法较少，爆发时间窗口很快来到，入局者需加速布局和看透潜在办公安全市场。

4、API泄露数据超过万亿条：API安全问题暴露过多过大，由于业务快速发展导致API安全慢于API业务发展，导致API数据泄露问题越来越多；

5、安全产品联动增多：安全产品进入Cybersecurity Mesh联动阶段和平台化阶段，单点产品能力逐步开始融合安全平台，包括SASE、CNAPP、Gartner Cybersecurity Mesh等大的平台；

6、安全产品云原生化增强：安全产品平台逐步开始Cloud Native云原生安全能力快速发展，未来安全产品、云安全、云、云原生的边界逐步模糊;

最后感谢各位读者的阅读，感谢很多朋友一直以来的支持和帮助，我们2022年一起进步、提升。一起铸造看得见的安全未来。

（全文完谢谢您的阅读！）

原文始发于微信公众号（鸟哥谈云安全）：2021年安全架构总结以及2022安全方向展望