赞
踩
2.2.3.1. 通过这种方式,有足够的理由确信设备运行的软件经过了审核并且是安全的
2.2.3.2. 记录设备上次重新加载镜像的时间可以在一定程度上决定设备的可信程度
2.3.1.1. 即便重新为设备加载镜像也无法擦除
2.3.4.1. 典型做法是通过私有CA为每台设备签发单独的设备证书,进行网络通信时,设备必须提交此证书
2.4.2.1. 必须考虑设备证书私钥的安全存储问题
2.4.3.1. 攻击者一旦提权就可以轻易获取私钥
2.4.4.1. 比简单的权限控制方案好一些
2.4.4.2. 可能存在一些易用性问题
2.4.4.2.1. 必须提供口令或其他凭证才能解密和使用私钥
2.4.4.2.2. 对于服务器认证的场景它就很不适用了
2.4.4.2.2.1. 无法做到每次软件重启时都要求人工交互
2.4.5.1. 这些设备[通常被称为硬件安全模块(HSM)或可信平台模块(TPM)]提供可以执行加密操作的安全区域
2.4.5.2. 加密处理器暴露为数不多的应用程序编程接口(API)用于生成非对称加密密钥,确保私钥永远不会离开安全模块
2.4.5.3. 操作系统也不能直接访问安全模块存储的私钥,因此它很难被窃取
2.4.6.1. 既然对身份标识的本地安全存储都需要谨慎防护以免被窃取,证书的生成和签发就更不应掉以轻心
2.4.6.2. 如果从企业的安全需求来看,设备的初始证书签发和安装极其敏感,那就必须在证书签署流程中引入人工干预环节,杜绝流程上的隐患
2.5.1.1. 一般认为安全操作员是可信任的
2.5.1.2. 这一人工操作确保初始身份标识可信
2.5.2.1. 完全取决于系统的安全等级
2.6.2.1. 一个TOTP口令只能使用一次,所以TOTP验证失败是一个重要的安全事件,可以杜绝安全隐患
2.6.3.1. 人工干预
2.6.3.1.1. 在相对静态的基础设施或终端用户设备的场景中,人工干预是一种简单安全的方案
2.6.3.1.2. 对于自动化的基础设施场景而言,人工干预不是一个好的选择
2.6.3.2. 资源管理器
2.6.3.2.1. 在某种程度上属于特权系统,其具备对基础设施的系统进行扩大或缩减的能力,并且整个基础设施的可用性也极大地依赖这类资源管理系统
2.6.3.2.2. 通过资源管理器可以直接或间接地对新证书的签发进行授权
2.6.3.2.3. 在容器化环境中,这类职责可能由资源调度器承担
2.6.3.3. 镜像或设备
2.6.3.3.1. 可考虑将身份凭证直接“烧制”到设备镜像中
2.6.3.3.2. 不建议将这种方案作为首选,因为这种方案过度依赖镜像库,并且保护和周期性地刷新镜像将变得复杂且具有风险
2.6.3.3.3. 可以利用HSM或TPM来提供与硬件关联的设备证书,这种方案比直接将凭证“烧制”到设备镜像中稍好
2.6.3.3.4. 但过度依赖TPM来实现设备证书的签发仍然不是最理想的方案
2.6.3.3.5. 特别是需要兼顾云端系统的部署时,其局限性就很明显了
2.6.4.1. 镜像中的密钥(或TPM中注册的密钥)
2.6.4.2. 正确的IP地址
2.6.4.3. 合法的TOTP(通过资源管理器生成)
2.6.4.4. 匹配的证书属性(如匹配的证书CN)
2.6.5.1. 攻击者无法访问待部署的主机,顶多对可用性进行一些攻击
2.6.5.2. 即便设备镜像被盗用也无法完成证书请求,因为资源管理器会进一步验证镜像部署的主机以及签名请求的其他属性
3.5.2.1. O字段用于表示环境
3.5.2.2. OU字段用于表示主机的角色
3.6.1.1. 私钥被攻破的情况是一种糟糕的场景,应该不惜一切代价进行规避
3.6.2.1. 使用口令对私钥进行加密仅适用于面向用户的设备
3.6.2.2. 在数据中心场景,这种方案并不奏效,因为解密私钥需要口令并考虑其安全存储,或通过某种安全机制传输密钥口令到服务器,这样一来,保证口令的安全变得和保护私钥一样重要
3.6.3.1. 可以通过硬件生成密钥对并且将私钥保存在安全存储区内,安全存储区的私钥是禁止直接读取的,只能通过HSM提供的接口请求其使用私钥来进行指定的运算
3.6.3.2. 这种基于硬件安全存储的私钥保护机制非常安全,不易被盗
3.7.2.1. 这个方案的核心是私钥,私钥是基于软件的,如果被盗,那么整个设备认证体系将成为无本之木
3.7.3.1. 密钥如此之长,不可能将其写下来或记住
3.7.3.2. 密钥可以被下载和安装,因此,一般不由用户随身携带,在设备认证的场景中,密钥应该始终和设备在一起
4.1.3.1. 可以避免暴露过多接口以及直接对私钥的读取
4.1.3.2. 即便是操作系统,也无从获取安全密钥
4.1.4.1. 在零信任安全中,通过TPM实现设备认证是一个极佳的实践
4.3.1.1. 要求TPM创建一个全新的非对称密钥对,使用公钥对AES密钥进行加密,然后使用SRK对私钥进行加密
4.3.1.2. 解密数据时,首先通过TPM解密中间密钥的私钥,并用它解密AES密钥,然后再使用AES密钥解密原始数据
4.3.2.1. 如果仅仅为了满足“密钥只能通过相应的设备进行解密”这一目标,则并不需要采用中间密钥方案
4.4.3.1. 方案只能防止攻击者直接从磁盘读取密钥
4.4.3.2. 无法避免攻击者提权后直接从内存读取解密后的密钥
4.4.3.3. 攻击者甚至可能调用TPM的接口直接进行加解密操作
4.5.4.1. 这些散列值序列可以用于证明系统的配置或状态是合法的
4.5.5.1. 可以确保只允许经过授权的软件配置解密数据,这可以通过在使用TPM加密数据时,传递一组已知的PCR数据值作为参数来实现
4.5.5.2. 被“封印”的数据只能通过封印它的TPM进行解密,并且解密时PCR的取值必须匹配
4.5.5.3. 由于PCR的取值无法修改或回滚,因此可以使用TPM“封印”技术确保加密数据不仅仅绑定到当前设备,还能绑定到特定的软件配置和版本
4.5.5.4. 可以有效地防止攻击者通过设备访问权限来获取私钥,因为只有未被修改的软件才能解锁这些数据
4.6.3.1. 每个TPM都有唯一的密钥对
4.6.3.2. EK的私钥仅存在于TPM内,因此即便是操作系统也无法对其进行访问
4.6.4.1. 这个“引用”包含了当前的PCR取值列表,并且使用EK进行签名
4.6.4.2. 远端系统可以通过这些信息对主机身份(因为EK对于每个TPM都是唯一的)和对应的软件状态/配置(因为PCR的取值不能被修改)进行确证
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。