读零信任网络：在不可信网络中构建安全系统19Google的BeyondCorp
https://img2024.cnblogs.com/blog/3076680/202408/3076680-20240813141550038-1842662899.png1. 概述
1.1. 基于用户身份而不是网络位置的访问控制体系，用于控制对应用、数据和服务的访问
1.2. Google的全新网络安全模型完全抛弃了特权网络的概念，访问授权仅仅依赖于用户和设备的凭证，而与用户和设备地点的网络位置无关，用户无论利用公司内网、家庭网络还是酒店或咖啡店的网络，都不会影响访问哀求的授权结果
1.3. 在新的安全模型中，全部对企业资源的访问都要基于设备状态和用户凭证举行认证、授权和加密，并且可以针对不同的企业资源举行细粒度的访问控制
1.4. BeyondCorp由许多相互协作的组件构成，通过这些组件之间的协作，确保只有经过严格认证的设备和用户才气被授权访问所需的企业应用
1.5. 当需要在不同的策略中做出权衡和选择时，务必把零信任的核心动机和设计原则牢记于心
2. 安全地识别设备
2.1. 利用设备清单库和设备证书安全地标识和追踪全部受控设备
2.2. 设备清单库
[*]2.2.1. 利用了“受控设备”的概念，即由企业采购并妥善管理的设备
[*]2.2.2. 只有“受控”设备才气访问企业应用
[*]2.2.3. 以设备清单库为底子的设备追踪和采购流程是BeyoundCorp安全模型的基石之一
[*]2.2.4. BeyondCorp会追踪全部受控设备，在设备的生命周期内发生的任何变更都会被记录下来，这些信息被连续监控和分析追踪，同时提供给BeyondCorp的其他组件
[*]2.2.5. 只要建立起元设备清单库，就能够掌握访问企业应用资源的全部设备信息
2.3. 设备身份
[*]2.3.1. 全部受控设备都要具备唯一的标识，用于索引设备清单库里相关设备的信息
[*]2.3.2. 为每台设备签发专用的设备证书是其中一种实现方式
[*]2.3.3. 只有在设备清单库中登记在册且信息正确的设备才可以获得设备证书，这些证书需要生存在硬件或软件模式的可信平台模块（TPM）中，或者生存在可靠的系统证书数据库中
[*]2.3.4. 设备自身以及设备证书的存储方式是否安全可靠需要举行验证，只有被认为足够安全的设备才气被归类为受控设备
[*]2.3.5. 当证书定期更新时，也需要重新验证设备的安全可靠性
[*]2.3.6. 验证通过的设备，其安装的证书就可以用于后续的企业应用访问过程
[*]2.3.7. 虽然证书可以唯一地标识设备，但仅凭设备证书并不能获得访问权限，证书只是获取该设备相关信息的一把钥匙
3. 安全地识别用户
3.1. 单点登录（SSO）系统是BeyondCorp的集中式用户认证流派，它负责对哀求访问企业资源的用户举行双因子认证，用户认证需要利用用户数据库和群组数据库
3.2. 用户认证成功之后，SSO系统会生成短时令牌，它可以作为特定资源访问授权过程的一部分
4. 访问署理
4.1. Google的全部企业应用都通过面向互联网的访问署理开放给外部和内部客户端，该署理对客户端和企业应用之间的通信数据举行强制加密处置惩罚
4.2. 访问署理可以基于每一个应用举行设置，同时提供了很多通用特性
[*]4.2.1. 全局访问可达、负载均衡、访问控制检查、应用安全检查以及抗拒绝服务攻击等
[*]4.2.2. 完成访问控制检查后，访问署理将访问哀求转发给后端应用
5. 实施基于清单库的访问控制
5.1. 随着时间的推移，授予某个用户或设备的访问权限级别也可能会发生变化
5.2. BeyondCorp能够通过查询多个不同的数据源，动态推断用户或设备的信任等级
5.3. 信任等级是后续访问控制引擎执行授权判定的关键参考信息
[*]5.3.1. 如果某个设备没有安装最新的操作系统安全补丁，那么其信任等级会被低落
[*]5.3.2. 某一类特定设备，比如特定型号的移动电话或平板电脑，可以被分配特定的信任等级
[*]5.3.3. 重新的地理位置访问企业应用的某个用户，会被分配不同的信任等级
[*]5.3.4. BeyondCorp同时利用了静态规则和启发式动态规则来确定用户或设备的信任等级
5.4. 授权的判定因素
[*]5.4.1. 用户的信息、用户地点的群组、设备证书以及设备清单库中获取的设备属性
[*]5.4.2. 用户和设备的信任等级
[*]5.4.3. 如果有必要，访问控制引擎也可以执行基于地理位置的访问控制
[*]5.4.3.1. 访问控制引擎还可以通过不同的方式来限制应用程序的各部分
6. 利用和扩展GFE
6.1. GFE（Google前端）
6.2. 为了评估策略，传统的做法是在每个后端应用上集成设备信任评估服务，但是这种做法会显着低落产物安装和更换的效率
6.3. 通过前端的访问署理提供集中化的策略强制执行机制，用来处置惩罚粗粒度的企业安全策略
6.4. BeyondCorp利用Google现有的前端（GFE）架构作为访问策略强制执行的逻辑中心
[*]6.4.1. 由于全部的访问哀求都汇集到这个逻辑中心举行处置惩罚，所以自然就可以在此底子上扩展GFE的功能，比如自助服务开通、认证、授权和集中式日志记录等
6.5. 访问署理通过引入认证和授权策略处置惩罚机制对GFE举行了扩展
[*]6.5.1. 访问署理需要对发起访问哀求的用户和设备举行认证，才气做出正确的授权判定
[*]6.5.2. 访问署理集成Google的身份提供者服务完成用户身份认证
[*]6.5.2.1. 访问署理支持多种第三方认证机制（包括OpenID Connect、OAuth等）也支持一些定制化协议
[*]6.5.3. 访问署理完成用户认证之后，将用户凭证的相关信息从访问哀求中去除，然后再将访问哀求转发至后端服务
[*]6.5.3.1. 确保后端服务无法通过访问署理重放访问哀求（或用户凭证）
[*]6.5.3.2. 访问署理对后端服务透明
>6.5.3.2.1. 后端服务可以在访问代理的数据流之上叠加自身的认证逻辑，并且也避免了将不必要的Cookie和用户凭证暴露给后端业务
[*]6.5.4. 集中的访问控制列表（ACL）引擎，支持远程过程调用服务（PRC）查询
[*]6.5.5. 专用的访问控制列表表现语言，使其同时兼顾可读性和可扩展性
[*]6.5.6. BeyondCorp的做法是由访问署理完成集中式的粗粒度应用访问授权，由后端应用各自实现自身的细粒度授权
[*]6.5.7. 后端应用把访问控制逻辑委托给前端执行
[*]6.5.7.1. 后端应用需要适当的机制来确保前端访问署理转发的访问流量简直已经通过了认证和授权检查
[*]6.5.7.2. 后端应用接收到的只是在加密通道中传输的HTTP哀求
[*]6.5.8. BeyondCorp接纳了Google内部开发的认证和加密框架LOAS（Low Overhead Authentication System，低开销认证系统），它可以支持访问署理和后端应用之间的双向认证和通信加密
[*]6.5.9. 后端能够信任访问署理在访问哀求中插入的任何元数据（通常以HTTP消息头的形式）
[*]6.5.9.1. 在反向署理和后端应用之间利用自定义协议额外插入元数据并不是什么新方法
[*]6.5.9.2. 访问署理和后端应用的双向认证机制可以确保元数据的不可欺骗性
[*]6.5.10. BeyondCorp就是接纳这种方式实现了设备信任等级向后端应用的通报，后端应用可以根据信任等级举行相应的处置惩罚
7. 多平台设备认证面对的挑衅
7.1. 准确地识别设备至少需要以下两个组件
[*]7.1.1. 某种形式的设备标识
[*]7.1.2. 可以跟踪任何指定设备最新状态的设备清单库
7.2. 以适当的设备信任替代基于网络位置的信任，所以每个设备都必须有一个一致的、不可克隆的标识，关于设备安装的软件、所属用户和位置的相关信息必须整合到设备清单库中
7.3. 台式机和笔记本电脑利用X.509证书，对应的私钥存储在操作系统的证书库中
[*]7.3.1. 密钥的安全存储是当代操作系统的尺度功能，它确保通过访问署理与服务器通信的命令行工具（以及保卫进程）能够匹配正确的设备标识
[*]7.3.2. 由于TLS要求客户端提供拥有私钥的暗码学证实，而且设备标识存储在诸如可信平台模块（Trusted Platform Module, TPM）这类安全硬件中，因此就能确保设备标识的不可欺骗性且不可克隆性
7.4. 移动设备的认证可以不依赖证书
[*]7.4.1. 移动操作系统本身就可以提供安全性高的设备标识
[*]7.4.2. IOS设备可以利用Vender标识符（identifierForVender,IDFV）
[*]7.4.3. 安卓设备可以利用企业移动管理软件（EMM）提供的设备ID
8. 迁移到BeyondCorp
8.1. Google投入了大量资源分阶段地举行迁移，在不影响公司生产力的环境下，成功地将大批网络用户迁移到了BeyondCorp
8.2. 摆设无特权网络
[*]8.2.1. 该网络虽然利用私有地点空间，但是其用户体验与外部网络非常相似
[*]8.2.2. 无特权网络只提供互联网访问、受限的底子网络服务（如DNS、DHCP和NTCP等）以及Puppet这类设置管理服务
[*]8.2.3. Google办公地区中的全部客户端设备都被分配到这个无特权网络，对无特权网络与Google其他网络的访问通过严格的ACL举行限制
8.3. 工作流迁移赋能
[*]8.3.1. Google的全部应用都要迁移到BeyondCorp，并最终通过访问署理举行访问
[*]8.3.2. 在特权网络中直接访问，在外网可以通过VPN访问
[*]8.3.3. 在特权网络中直接访问，在外网和无特权网络中通过访问署理访问
[*]8.3.4. 在外网、特权网络和无特权网络均通过访问署理访问
8.4. 减少VPN的利用
[*]8.4.1. 积极劝阻用户利用VPN
[*]8.4.2. 只有经证实确有需要的用户才气利用VPN访问
[*]8.4.3. 监控VPN的利用，如果用户在一段时期内未利用过VPN，就取消其VPN访问权限
[*]8.4.4. 监控VPN的利用，如果用户在一段时期内未利用过VPN，就取消其VPN访问权限
8.5. 流量分析管道
[*]8.5.1. 只有确信（或靠近确信）用户的工作流都可以从无特权网络中获取到，才气将用户迁移至无特权网络
[*]8.5.2. 从公司的每个交换机中采集网络流的样本，作为流量分析管道的输入
[*]8.5.3. 基于ACL分析无特权网络与公司其他网络之间的网络流量，识别命中ACL的流量
[*]8.5.4. 对于没有命中ACL的“逃逸”流量，将其关联到特定的工作流和/或特定的用户（特定的设备）上
[*]8.5.5. 逐步解决这些“逃逸”流量的问题，以使它们能够在BeyondCorp环境下工作
8.6. 模拟无特权网络
[*]8.6.1. 作为增补，除了通过交换机采样流量并举行流量分析外，我们还利用安装在Google用户设备上的流量监视器，模拟了整个公司的无特权网络举动
[*]8.6.2. 流量监视器有两种工作模式
[*]8.6.2.1. 日志记录模式
>8.6.2.1.1. 捕获“逃逸”流量，但仍允许上述流量流出设备
[*]8.6.2.2. 强制执行模式
>8.6.2.2.1. 捕获和丢弃“逃逸”流量8.7. 迁移策略
[*]8.7.1. 根据工作职责、（和/或）工作流程、（和/或）地理位置识别潜在的可迁移候选人聚集
[*]8.7.2. 在日志记录模式下运行模拟器，识别连续30天合格流量大于99.9%的用户和设备
[*]8.7.3. 如果在这段时间内用户和设备的合格流量大于99.99%，则为这些用户和设备启动强制执行模式
[*]8.7.3.1. 如有必要，用户可以将模拟器恢复到日志记录模式
[*]8.7.4. 强制执行模式成功运行30天后，将其记录在设备清单库中
[*]8.7.5. 如果用户和设备在可迁移对象候选人聚集中，并且在模拟器强制执行模式下成功工作了30天，就可以把用户和设备迁移到无特权网络了
8.8. 豁免处置惩罚
[*]8.8.1. 允许用户在迁移过程中哀求临时豁免
[*]8.8.2. 维护一个未完成BeyondCorp赋能、尚未达到迁移尺度的工作流列表
[*]8.8.3. 用户可以搜索该工作流列表，经过审批后，将他们自身以及设备标注为特定工作流的活跃用户
[*]8.8.4. 该工作流完成BeyondCorp赋能之后，相关用户会收到通知，并再次进入可迁移候选人名单
9. 经验教导
9.1. 沟通
[*]9.1.1. 安全底子设施的根本性改变可能会对整个公司的生产力产生负面影响，因此与用户充分沟通这种改变带来的影响、可能出现的问题以及可能的调停措施十分紧张
[*]9.1.2. 沟通不足可能导致的问题
[*]9.1.2.1. 问题发生时，用户感到惊讶和疑惑
[*]9.1.2.2. 调停措施效果差
[*]9.1.2.3. IT支持人员的工作超出负荷
[*]9.1.3. 过度沟通可能导致的问题
[*]9.1.3.1. 不愿改变的用户会倾向于高估变化带来的影响，并企图寻求不必要的豁免
[*]9.1.3.2. 当出现有伤害的变化时，用户会认为是正常征象
[*]9.1.3.3. Google的企业底子设施在许多互不相关的方面同时开展工作，用户很轻易将应用访问相关的问题与其他正在举行的项目问题混淆，这也会低落调停措施的效率，增长技术支持人员的工作负荷
9.2. 工程师需要支持
[*]9.2.1. 迁移能否成功很大程度上取决于团队在访问署理上设置后端服务的难易程度，因此后端服务的设置上线应当以减轻开发人员的开发负担为目标，要把异常环境的出现维持在最低限度
[*]9.2.2. 沙箱在大部分环境下都非常有用，比如在对X.509证书或底层TLS库举行重大变更之后，需要确保客户端TLS毗连能成功举行时，可以利用沙箱举行验证
9.3. 数据质量和相关性
[*]9.3.1. 资产管理的数据质量问题非常关键，它可能会导致用户设备无意中失去对企业资源的访问权限
[*]9.3.2. 拼写错误、标识错误和信息丢失都是常见的数据质量问题，导致此类问题出现的原因有很多，可能是采购团队接收资产并将其添加至系统时的人为失误，也可能是制造商工作流程的失误
[*]9.3.3. 改进工作流程，并增长自动输入验证功能，以便于在数据录入时发现并减少人为错误
[*]9.3.4. 准确的信任评估需要设备清单库提供高精度的数据，这会迫使人们高度关注设备清单库中的数据质量
[*]9.3.5. 零信任架构设备信任评估使数据的精确性达到前所未有的水平，也带来了一定的安全价值
9.4. 稀疏数据集
[*]9.4.1. 设备清单库的上游数据源不一定有重叠的设备标识符
[*]9.4.1.1. 新设备大概有资产标签，但是没有主机名
[*]9.4.1.2. 在设备生命周期的不同阶段，硬盘序列号可能与不同的主板序列号相关联
[*]9.4.1.3. MAC地点可能发生冲突
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]