ASPIRE

Google的BeyondCorp安全模型学习

=Start=

缘由：

因为工作需要，了解一下「办公网络的整体安全建设」。

正文：

参考解答：

Google在2014年之前就预测到互联网和内网的安全性是一样危险的，因为：

1）一旦内网边界被突破，攻击者就很容易访问到企业内部应用。
2）现在的企业越来越多采用移动和云技术，边界保护变得越来越难。所以干脆一视同仁，不外区分内外网，用一致的手段去对待。

这种访问模式要求客户端是受控的设备，并且需要用证书来访问。访问又通过认证服务器、访问代理以及单点登录等手段，由访问控制引擎统一管理，不同用户、不同资源有不同的访问权限控制，对于用户所处位置则没有要求。

员工设备，包括笔记本电脑和手机，都要登录设备清单服务，在服务中保存一段时间的信任信息和设备快照。员工被赋予不同的信任级别，保证他们能以最小权限履行职责，既减少了运维开支，又改善了设备可用性。谷歌BeyondCorp计划的目标，就是从员工和设备怎样访问内部应用出发，改善企业安全环境。

与传统的边界安全模型不同，BeyondCorp不是以用户的物理登录地点或来源网络作为访问服务或工具的判定标准，其访问策略是建立在设备信息、状态和关联用户的基础上，更偏向用户行为和设备状态的分析。

我认为的BeyondCorp的几个关键点在于：零信任模型（设备清单数据库、设备证书、用户和组数据库、基于802.1x的Radius做网络层的访问控制、基于访问代理的强制加密、SSO、访问控制引擎）

在我看来BeyondCorp的核心理念就在于：All access to enterprise resources is fully authenticated, fully authorized, and fully encrypted based upon device state and user credentials.

参考链接：

=END=

Docker

,
,

《 “Google的BeyondCorp安全模型学习” 》 有 26 条评论

  4. 各种网络攻击杀伤链(The Cyber Kill Chain is making us dumber)
    https://theobsidiantower.com/2017/07/18/03853cdb10695731c8bb15518c0ceb58a5fe428d.html
    `
    Recon: It didn’t perform recon, it randomly generated a target IP and launched the exploit at port 80.
    Weaponization: lol
    Delivery: yes! Here we could have stopped it though websites generally like to be accessible.
    Exploitation: sure
    Installation: Code Red didn’t ‘install’ itself and could be removed via a reboot.
    C&C: Nope, preprogrammed actions depending on the data (spreading, ddos on fixed IP addresses, sleeping)
    Actions on objectives: For a worm I guess this is the spreading/ddos/sleeping part and can be denied.
    `

    回复

  9. 从BeyondCorp说起
    https://www.sec-un.org/%E4%BB%8Ebeyondcorp%E8%AF%B4%E8%B5%B7/
    `
    我的看法是，BeyondCorp及与之核心关联的理念和技术可能是推动整个安全行业在未来5-10年里发展乃至革命的基础和核心。

    Google将BeyondCorp项目的目标设定为“让所有Google员工从不受信任的网络中不接入VPN就能顺利工作”。尽管听起来像是要解决远程接入的安全问题，BeyondCorp实际上是抛弃了对本地内网的信任，进而提出了一个新的方案，取代基于网络边界构筑安全体系的传统做法。

    在这个新方案中，Google平等对待位于外部公共网络和本地网络的设备，在默认情况下都不会授予任何特权。用户必须1）使用由公司提供且持续管理的设备，2）通过身份认证，且3）符合访问控制引擎中的策略要求，才能4）通过专门的访问代理5）访问特定的公司内部资源。相应的，为了保证用户获得流畅的资源访问体验，Google主要完成了：1）准确识别设备；2）准确识别用户；3）移除对网络的信任；4）通过面向互联网的访问代理提供内部应用和工作流；5）实现基于已知设备和用户的访问控制，并动态更新设备和用户信息。

    原本假设的信任并不存在，需要贯彻“最小特权原则”。
    `

    回复

  11. 基于上下文的安全访问：谷歌公布BeyondCorp最佳实践
    https://paper.tuisec.win/detail/791b715c1616302
    http://www.aqniu.com/learn/35844.html

    谷歌如何保护6万员工的设备安全
    http://www.aqniu.com/learn/24493.html
    `
    访问控制最简单的解决方案是二元的：网络访问要么放行，要么拒绝。这办法太粗糙了，无法适应现代商业文化中最大化用户生产力和创造性的需要。细粒度的访问控制，可以让用户在需要的时候访问需要的东西，是更适应现代商业的一种模式。

    谷歌自己约6.1万人的全球员工身上，就用的是此类访问控制模型——分层访问( Tiered Access )。

    分层访问模型中的“层”，是应用到公司不同服务上的敏感层级。谷歌只分了4层：不受信任的；基本访问；特权访问；高特权访问。选4层是一种在太多(让系统过于复杂)和太少(又回到了分层方法试图改进的二元访问控制状态)之间的权衡。
    `

    回复

  14. 零信任安全的4W1H
    https://mp.weixin.qq.com/s/yBzdo9qHacTajQFNpmjvpQ
    `
    零信任安全（或零信任网络、零信任架构、零信任）最早由约翰.金德维格（John Kindervag）在2010年提出，约翰.金德维格当时是著名研究机构Forrester的首席分析师。

    如今8年过去了，零信任安全已逐步被业界所认可，各组织机构的CIO、CISO们也言必称零信任了，特别是2017年Google基于零信任构建的BeyondCorp项目成功完成，零信任俨然已成为安全界的新宠。

    WHAT：零信任安全是什么？
    1. 应该始终假设网络充满威胁。
    2. 外部和内部威胁每时每刻都充斥着网络。
    3. 不能仅仅依靠网络位置来建立信任关系。
    4. 所有设备、用户和网络流量都应该被认证和授权。
    5. 访问控制策略应该是动态的基于尽量多的数据源进行计算和评估。

    WHY：为什么需要零信任安全？
    首先，从安全态势的角度来看，大数据时代网络安全威胁比以往任何时候都更加复杂和险恶，业界一致认为，目前网络安全架构的薄弱环节正是身份安全基础设施的缺失，有数据显示，部署了成熟IAM系统的企业，其安全事件下降了50%。根据《2018 insider threat report》显示，内部威胁是造成数据泄露的第二大原因。往往因为非授权访问、雇员犯错、外包员工犯错等等原因，导致 “合法用户”可以非法访问特定的业务和数据资源，造成组织内部数据泄漏。造成数据泄露的第一大原因是外部黑客攻击，但是显然攻击者并没有什么非常高明的技术。根据美国最大的移动运营商Verizon报告分析指出，81%的黑客成功利用了偷来的口令或者弱口令，就轻而易举地获得了数据的访问权限，成功窃取数据。
    其次，从企业数字化转型和IT环境的演变来看，云计算、移动互联的快速发展导致传统内外网边界模糊，企业无法基于传统的物理边界构筑安全基础设施，只能诉诸于更灵活的技术手段来对动态变化的人、终端、系统建立新的逻辑边界，通过对人、终端和系统都进行识别、访问控制、跟踪实现全面的身份化，这样身份就成为了网络安全新的边界，以身份为中心的零信任安全成为了网络安全发展的必然趋势。

    WHO：谁对零信任安全负责？
    在零信任架构下，IAM是安全基础和核心架构，如果企业还是和以前一样，仅仅将IAM视为业务基础架构，势必导致IAM的建设和运维降级为普通的IT项目，难以发挥IAM及零信任安全在企业数字化转型过程中的安全支撑作用。根据企业的具体职责分工情况，零信任项目的负责人可能由首席信息官（CIO）、首席安全官（CSO）、甚至首席执行官（CEO）亲自担任，无论如何，关键点在于，此责任人必须在企业内拥有较高的权力，确保能推动各部门共同建设和发挥IAM的安全支撑作用。

    WHEN：什么时候引入零信任安全？
    企业进行全新的基础设施规划或迁移时，需要由内至外的基于零信任进行整体安全架构设计和规划，细致梳理人员、数据、系统、应用的逻辑边界及安全需求，制定符合企业安全策略的全面的应用级、功能接口级和数据级访问控制机制，切不可在基础设施建设完毕后再叠加零信任。
    对于尚无基础设施转型计划的企业来说，实施部分零信任安全实践也未尝不可，但企业必须意识到，这个过程难以一蹴而就，毕竟Google建设BeyondCorp耗时也超过六年，一种可能的实施方案是基于现代身份管理平台建设应用级的访问控制，确保应用访问的身份识别、授权策略的统一。

    HOW：如何实现零信任安全？
    1. 以身份为中心（合法身份@可信设备）
    2. 业务安全访问（→可信接入网关）
    3. 动态访问控制（基于安全策略、用户属性、环境属性、其他风险因子等，对此次访问进行授权判定，得到一个信任等级，最终根据评估得出的信任等级分配用户一个最小访问权限）
    `

    回复

  19. CSS干货直击：腾讯无边界访问控制体系建设
    https://mp.weixin.qq.com/s/V-42z3H5-oLIvHQ00oV87g
    `
    “零信任”概念是在2010年由Forrester提出，谷歌BeyondCorp项目做了全世界第一个落地，谷歌BeyondCorp方案的目的就是为了让员工在不安全的网络下安全地访问公司。作为腾讯，很多年前已经关注到了这块IT基础建设和基础架构方面的变化。

    我们知道无论腾讯也好，互联网公司也好，非互联网公司也好，之前企业网络架构通常是重边界的架构，会把各种安全防御措施、网络隔离措施、安全设备堆在边界上，这样做通常有两种结果：一是如果遇到比较严重APT攻击，一旦突破边界，内部没有足够的安全检测机制和有效防御机制；二是如果内部业务比较复杂，整个IT在内部管理策略和管理成本是非常高的。基于此安全和效率的问题，我们看到了零信任网络架构的价值。

    无边界访问控制体系概述
    无边界访问控制场景
    　　终端安全管理
    　　　　硬件——硬件资产信息收集、合规准入、日常硬件资产盘点
    　　　　系统——统一病毒/木马防护、漏洞补丁集中管理分发
    　　　　软件——配置/服务加固、存储外设开关、禁用高危端口/服务、屏蔽非白名单设备外联
    　　　　用户——PC端通过入域且通过域帐号登录、移动端使用多因素认证
    　　　　数据——企业云盘、DLP、可信设备、数据全周期追溯
    　　　　行为——重点业务/操作日志埋点记录、多日志关联、日常行为基线建设

    　　无缝网络接入
    　　　　终端&网关「联动」，使用「短连接」方式，「数据包」级别加密（可以做到细粒度控制的同时，提升使用体验）

    　　多维度访问控制（设备识别、身份验证、进程审核）
    　　　　基于身份控制——销售人员访问销售系统、开发人员访问代码系统
    　　　　基于目标控制——运维系统只被指定应用访问、内网OA只被特定浏览器访问
    　　　　基于状态控制——恶意进程(非白名单进程)无法访问后台系统、含高危漏洞的浏览器无法访问后台系统

    无边界访问控制—设备可信、用户可信、应用可信
    `

    回复

  20. Google的安全机制
    https://mp.weixin.qq.com/s/PlrPBMRejmaROkR0oLvtuw
    https://ai.googleblog.com/2016/03/lessons-learned-while-protecting-gmail.html
    https://elie.net/static/files/lessons-learned-while-protecting-gmail/lessons-learned-while-protecting-gmail.pdf
    `
    在网络安全领域，gmail邮箱的双因子认证被业内奉为第一大难题，它让多少网络安全从业者捶胸顿足，垂头丧气。Google的安全机制也被全世界的网络安全研究者专门研究，下面我将结合个人的经历谈谈我眼中的Google的安全机制，因本人水平有限，若有不对之处，敬请斧正。

    Gmail诞生于2004年，到2016年时，已经拥有了9亿的Gmail用户。Gmail提出了五大威胁：钓鱼邮件、恶意代码（附件识别）、账户劫持、网页攻击（XSS）与垃圾邮件。

    总之，为了保证Gmail的安全，Gmail团队用上了安全审计、线性分类、静态分析、反病毒、加密、深度学习、模糊测试、分布式拒绝服务防御、动态执行、内容安全策略、自动转义。还有最后一招，奖励机制，通过奖励最优秀的黑客、最优秀的漏洞，来弥补自身。（it’s worth it@!）

    笔者认为：Gmail已经开始，通过学习Gmail用户登录、使用等在谷歌网站上的一切网络行为，来捕捉、探测、感知、学习、防御，而利用深度学习技术，这些行为都将是自动化的，也就是说，谷歌的安全策略是：一切从用户中来，一切到用户中去，一切都是自动化转变的过程。

    风起于青萍之末，舞于松柏之下，止于草莽之间，信息革命正蓬勃发展，智能革命又方兴未艾，科技作为第一是生产力，带来的科技革命应了那句话——运动是绝对的，变化是世界永恒的主题。人类只有不断地深度学习，才能够永立潮头。不学习本身是个伪命题，每个人都在用脑，用脑就是在学习，当代社会，人与人之间比的不是谁学得更多，而是谁学的更深，谁学的效率更高。在这个信息爆炸的年代，填鸭式的学习只会令人反感，取而代之的将是主动式、引导式、思考式的深度学习方式。
    `

    回复

  22. Microsoft 零信任
    https://www.microsoft.com/zh-cn/security/business/zero-trust
    `
    # 零信任原则
    * 进行显式验证 – Verify explicitly
    始终基于所有可用数据点进行身份验证和授权，包括用户身份、位置、设备运行状况、服务或工作负载、数据分类以及异常情况。
    Always authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and anomalies.

    * 使用最少特权访问 – Use least privileged access
    通过即时和最小可用访问权限(JIT/JEA)、基于风险的自适应策略以及数据保护来限制用户的访问，以帮助保护数据并保障生产力。
    Limit user access with just-in-time and just-enough-access (JIT/JEA), risk-based adaptive polices, and data protection to help secure both data and productivity.

    * 假定泄露 – Assume breach
    最小化泄漏影响半径并对访问权限进行分段。验证端到端加密，并使用分析获取可见性，促进威胁检测并增强防御。
    Minimize blast radius and segment access. Verify end-to-end encryption and use analytics to get visibility, drive threat detection, and improve defenses.

    # 零信任定义
    Instead of assuming everything behind the corporate firewall is safe, the Zero Trust model assumes breach and verifies each request as though it originates from an open network. Regardless of where the request originates or what resource it accesses, Zero Trust teaches us to “never trust, always verify.” Every access request is fully authenticated, authorized, and encrypted before granting access. Micro segmentation and least privileged access principles are applied to minimize lateral movement. Rich intelligence and analytics are utilized to detect and respond to anomalies in real time.
    零信任模型假定泄露（而不是假定公司防火墙背后的所有内容均安全）并将每个请求都视为源自开放网络。零信任教导我们，无论请求源自何处或不管访问何种资源，都应坚守“永不信任，始终验证”的原则。每个访问请求在授予访问之前都应进行完全身份验证、授权和加密。应用微分段和最少特权访问原则以最大限度地减少横向迁移。利用丰富的智能和分析进行检测并及时响应异常情况。
    `

    回复

  23. Transparency in the shadowy world of cyberattacks
    https://blog.google/outreach-initiatives/public-policy/transparency-in-the-shadowy-world-of-cyberattacks/
    `
    在 2009年 的极光行动（Project Aurora）之后，Google从此事中学到的一些经验和采取的实际行动：

    Security has to be built in, not just bolted on. 原生/内建安全，而非外挂式的安全。

    Aurora showed us that we (and many in the industry) were doing cybersecurity wrong. Security back then was often “crunchy on the outside, chewy in the middle.” Great for candy bars, not so great for preventing attacks. We were building high walls to keep bad actors out, but if they got past those walls, they had wide internal access. 如果仅依赖于边界防御，当边界防御被突破时，对攻击者而言内部访问即将畅通无阻。

    The attack helped us recognize that our approach needed to change–that we needed to double down on security by design. 需要加倍重视设计的安全性。

    1. P0团队用来挖掘漏洞
    After Aurora, we launched an entire team called Project Zero to find and promptly disclose previously undiscovered, zero-day vulnerabilities in our own and other companies’ software, raising the security bar for everyone.

    2. TAG团队用来应对高端的威胁/攻击
    And today, Google’s Threat Analysis Group, or TAG, works to counter a range of persistent threats from government-backed attackers to commercial surveillance vendors to criminal operators. TAG does regular public disclosures of foreign state actor attacks, including doing the difficult work of attribution.

    3. BeyondCorp企业内部的零信任落地
    So we launched an internal initiative called BeyondCorp, which pioneered the concept of zero trust and defense in depth and allowed every employee to work from untrusted networks without the use of a VPN. Today, organizations around the world are taking this same approach, shifting access controls from the network perimeter to the individual and the data.
    `

    回复

  24. Scaling BeyondCorp with AI-Assisted Access Control Policies (利用人工智能辅助访问控制策略扩展BeyondCorp)
    https://security.googleblog.com/2023/10/scaling-beyondcorp-with-ai-assisted.html
    `
    In July 2023, four Googlers from the Enterprise Security and Access Security organizations developed a tool that aimed at revolutionizing the way Googlers interact with Access Control Lists – SpeakACL. This tool, awarded the Gold Prize during Google’s internal Security & AI Hackathon, allows developers to create or modify security policies using simple English instructions rather than having to learn system-specific syntax or complex security principles. This can save security and product teams hours of time and effort, while helping to protect the information of their users by encouraging the reduction of permitted access by adhering to the principle of least privilege.
    2023 年 7 月，来自企业安全和访问安全组织的四位谷歌人开发了一款工具–SpeakACL，旨在彻底改变谷歌人与访问控制列表交互的方式。该工具在谷歌内部的安全与人工智能黑客马拉松比赛中荣获金奖，允许开发人员使用简单的英语指令创建或修改安全策略，而无需学习特定系统的语法或复杂的安全原理。这可以为安全和产品团队节省数小时的时间和精力，同时通过鼓励遵守最小特权原则减少允许的访问，帮助保护用户的信息。

    # BeyondCorp 的访问控制政策

    Google requires developers and owners of enterprise applications to define their own access control policies, as described in BeyondCorp: The Access Proxy. We have invested in reducing the difficulty of self-service ACL and ACL test creation to encourage these service owners to define least privilege access control policies. However, it is still challenging to concisely transform their intent into the language acceptable to the access control engine. Additional complexity is added by the variety of engines, and corresponding policy definition languages that target different access control domains (i.e. websites, networks, RPC servers).
    谷歌要求企业应用程序的开发者和所有者定义自己的访问控制策略，如 BeyondCorp：访问代理》中所述。我们在降低自助式 ACL 和 ACL 测试创建的难度方面进行了投资，以鼓励这些服务所有者定义最少权限的访问控制策略。但是，要将他们的意图简明扼要地转化为访问控制引擎可接受的语言，仍然具有挑战性。各种引擎和相应的策略定义语言针对不同的访问控制域（如网站、网络、RPC 服务器），增加了额外的复杂性。

    To adequately implement an access control policy, service developers are expected to learn various policy definition languages and their associated syntax, in addition to sufficiently understanding security concepts. As this takes time away from core developer work, it is not the most efficient use of developer time. A solution was required to remove these challenges so developers can focus on building innovative tools and products.
    要充分实施访问控制策略，服务开发人员除了要充分理解安全概念外，还要学习各种策略定义语言及其相关语法。由于这需要占用开发人员的核心工作时间，因此不能最有效地利用开发人员的时间。我们需要一个解决方案来解决这些难题，以便开发人员能够专注于开发创新工具和产品。

    # Making it Work 使其发挥作用

    We built a prototype interface for interactively defining and modifying access control policies for the BeyondCorp access control engine using the PaLM 2 Large Language Model (LLM). using the PaLM 2 Large Language Model (LLM). We used Google Colab to provide the model with a diverse, highly variable, dataset using in-context learning and fine-tuning. In-context learning allows the model to learn from a dataset of examples that are relevant to the task at hand, which we provided via few-shot learning. Fine-tuning allows the model to be adapted to a specific task by adjusting its parameters. Tuning the model with a diverse labeled dataset that we curated for this task allowed us to improve its ability to generate ACLs that are both syntactically accurate and adhered to the principle of least privilege.
    我们利用 PaLM 2 大型语言模型（LLM）为 BeyondCorp 访问控制引擎构建了一个交互式定义和修改访问控制策略的界面原型。我们利用谷歌 Colab，通过上下文学习和微调，为模型提供了一个多样化、高度可变的数据集。上下文学习允许模型从与当前任务相关的示例数据集中学习，我们通过少量学习提供了这一数据集。微调可以通过调整参数使模型适应特定任务。利用我们为该任务策划的多样化标签数据集对该模型进行调整，可以提高其生成 ACL 的能力，使其既能保证语法准确，又能遵守最小特权原则。

    With SpeakACL, and other tools leveraging AI in security, it is always recommended to take a conservative approach with the autonomy you give an AI agent. To ensure our model outputs are correct & safe to use, we combined our tool with existing safeguards that exist at Google for all access policy modifications:
    对于 SpeakACL 以及其他利用人工智能进行安全防护的工具，我们始终建议对人工智能代理的自主权采取保守的态度。为了确保我们的模型输出正确、使用安全，我们将我们的工具与谷歌现有的保障措施相结合，用于所有访问策略的修改：

    Request LGTM from a teammate to ensure that the intent of the proposed change is correct.
    要求队友提供 LGTM，以**确保所提修改的意图是正确的**。

    Automated Risk Assessment occurs on proposed security policy at Google.
    对谷歌提出的安全政策进行**自动风险评估**。

    Manual Review by Security Engineers is performed on changes not assessed as low risk to ensure compliance with security policies and guidelines.
    **由安全工程师对未评估为低风险的变更进行人工审查，以确保符合安全政策和准则**。

    Linting, unit tests, and integration tests ensure that the access control language syntax is correct, and that the change does not break any expected access or permit unexpected access.
    林汀测试、单元测试和集成测试可确保访问控制语言的语法正确无误，**确保更改不会破坏任何预期访问或允许意外访问**。

    # Looking to the future 展望未来

    While progress in AI is impressive, it is crucial we as an industry continue to prioritize safety while navigating the landscape. Other than adding checks to syntactically and semantically verify access policies produced by our model, we also designed safeguards for sensitive information disclosure, data leaking, prompt injections, and supply chain vulnerabilities to make sure our model is performing at the highest level of security.
    虽然人工智能的进步令人印象深刻，但作为一个行业，我们在驾驭人工智能的同时，必须继续将安全性放在首位。除了增加检查以从语法和语义上验证模型生成的访问策略外，我们还针对敏感信息披露、数据泄露、提示注入和供应链漏洞设计了保障措施，以确保我们的模型以最高的安全级别运行。
    `

    回复

  25. 百度零信任架构落地经验分享——7层零信任方案
    https://mp.weixin.qq.com/s/5utSjmXrh5enrAvJmJLFvQ
    `
    1. 概要
    为了提升内网的健壮度、简化内部复杂的端口策略，百度近几年启动了零信任架构的探索，并于近期完成了办公网7层零信任的落地工作。落地零信任网关会通常会遇到几个关键问题，比如技术方案上，需要保证网关的稳定性、请求的响应延迟；运营方案上，要设计灰度流程，解决来自业务线的阻力、跟业务线建立信任感等等。
    然而，百度零信任架构落地的难度不止于此。任何问题一旦达到一定规模，解决的难度就会直线上升。按照最极端的情况考虑，百度零信任架构需要支持数万员工同时在线办公、接入数万个业务系统、收敛数十万条端口策略，因此难度很大。项目组最终克服诸多建设困难，对上述问题进行拆解、一一击破，成功完成了办公网7层零信任的实施，并取得了不错的落地效果。
    考虑到上述经验具备可复制的特点，项目组对办公网7层零信任落地过程进行了完整的总结。本文会按照项目背景、产品设计、系统架构设计、运营和灰度方案、常见问题处置手册几个章节，详细讲解落地方案。如有疑问，请在百度安全公众号下留言咨询。

    2. 背景介绍
    Forrester分析师John Kindervag在2010年提出了零信任架构的理念，经过十余年的发展该理念已被广泛接受，技术方案也相对成熟。目前零信任分为这几种流派：

    1. 解决办公安全问题
    （1）提供SaaS化的零信任网关服务
    （2）提供身份服务和账号风控能力
    （3）提供私有化部署完整解决方案(准入、零信任网关、桌管等能力)

    2. 解决IDC微隔离问题，基于云原生方案或者SDN方案进行细粒度控制
    百度近几年也开启了零信任建设的探索，从风险程度和投入产出比考虑，我们目前聚焦在办公网零信任架构的实现上。在启用零信任架构之前，百度办公网到生产网的访问控制策略主要依赖4层控制能力。由于百度内部业务体量庞大而且需求多样化，经过十几年的积累，当前的访问控制策略已经变得难以维护，因此不得不采取一些折中策略。在这个场景下，一旦办公网被入侵，攻击者就可以对生产网海量开放业务发起攻击，并可能进一步造成数据泄露等安全风险。
    经过调研，我们发现零信任架构可以提供如下安全能力：

    （1）加密访问: 提供透明的加密访问能力
    （2）认证鉴权: 提供透明的SSO认证能力，以及域名级别访问控制能力
    （3）操作审计: 谁在什么时间点请求了哪个内网服务
    （4）安全防护: 提供WAF能力、用户异常访问动作序列等风控能力
    （5）数据防泄露: 检测响应里是否有敏感数据，对文件进行标记

    因此，结合风险现状和零信任的安全价值，我们认为目前最好的方案就是建设办公网零信任网关，收敛绝大多数访问入口，并根治这个安全风险。

    3. 零信任建设规划

    在设计项目目标时候需要兼顾安全目标(比如业务覆盖率)、业务体验(比如稳定性)和用户侧的体验(比如访问是否卡顿)。从公司现状出发，项目组将办公网零信任最终目标制定为:
    1. 业务功能: 提供便捷的、稳定的使用体验，允许在公网使用零信任系统
    2. 稳定性: 办公类业务系统全部发布到零信任网关，能够支撑全员同时在线办公，全年无重大线上事故
    3. 安全能力: 已接入的业务系统完成加固，包括HTTPS、最小化访问权限、WAF防护、风控能力等等

    4. 项目方案

    4.1 技术方案选型
    零信任的核心功能是流量代理，给每一个请求赋予用户身份信息。从用户流量来看，百度办公网主要流量为7层请求(比如Web浏览器)，次要流量为4层请求(比如MySQL、SSH)，因此一个完整的零信任方案需要同时支持4、7层的流量代理。目前百度采用的是混合零信任架构方案，通过两种代理方案分别解决不同的安全问题、扬长避短。

    4.2 业务场景分析
    本文重点讲解7层方案，针对建设目标，我们设计出办公网7层零信任系统最小化功能集合

    4.3 关键组件
    根据我们调研情况，甲乙方绝大多数7层零信任网关都是基于OpenResty方案实现。百度办公网7层零信任网关采用持安零信任产品，也是基于上述架构。对于百度而言，采用商业产品ROI更高，同时可以撬动外部资源推进项目建设，更快的解决安全风险。

    5. 项目难点分析
    对于百度而言，落地零信任有如下几个关键困难：
    1. 首先是工程架构方面。百度的零信任架构需要支撑数万员工同时在线办公、接入数万个域名；对于在线协同编辑文档、定点抢会议室几个场景，对连接数和访问延迟都有较高的要求。
    2. 其次是用户体验方面。大部分员工并不知道零信任是什么，产品流程设计上需要对用户透明，否则用户体验和运营成本会很高。
    3. 最后是业务沟通接入方面。百度存在大量无人维护的历史业务，经常会有找不到负责人的情况；对于内部重要的业务，需要做好实际风险控制，并与业务方建立信任感。

    6. 难点一: 工程架构设计
    我们将工程架构设计难题拆解为网关高可用方案、参数调优、业务接入方式几块，下面我们来挨个探讨。

    7. 难点二: 用户体验
    考虑到所有办公业务系统都需要接入零信任，在产品流程设计上需要对用户透明，尽可能让用户感知不到零信任的存在。对于业务管理员，也尽量只提供简单、主要的功能，否则用户体验和运营成本会很高。

    8. 难点三: 业务接入沟通
    百度内部有较多无负责人或者处于维护状态的业务系统，一旦出现问题无法及时处理；对于ERP、知识库等重要业务系统，出现问题将是全员级别的故障。考虑到任何线上的系统都会出现问题，所以我们一定要做好兜底安全措施和风险控制方案，下面我们来挨个进行探讨。

    9. 常见业务兼容性问题和解决方案
    这里我们总结了常见的业务兼容性问题和解决方案，供大家查询使用

    10. 写在最后
    对于多数公司来说，7层流量要远远多于4层流量，因此优先建设7层零信任网关通常是投入产出比最高的选择。当我们把流量入口收敛到零信任网关，可以很好的缓解内网攻击面庞大、漏洞修复成本较高的问题。另外，接入零信任网关的业务，每个请求都会有用户的身份信息，即使发生了攻击行为也可以很快的定位出攻击者盗用的身份，并进行应急处置。
    百度目前还在零信任落地的第一阶段，未来我们还会继续发布后续阶段的落地经验，请大家留意公众号后续的文章。如有疑问，欢迎大家在公众号留言咨询，如在北京可约现场交流。
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注