【TiDB 4.0 PCTA 学习笔记】- 3.8.2 TLS and TDE（TLS 和 TDE） @2班+李响

☄️ 学习与认证 经验&心得&笔记
1

课程名称：3.8.2 TLS and TDE（TLS 和 TDE）

学习时长：

60分钟

课程收获：

掌握 TLS 和 TDE 的原理和使用。

课程内容：

一、TLS

  1. What is TLS
  • TLS为传输层安全协议（也称作SSL）互联网保密通讯标准协议
  • 提供的功能
    • 加密安全的网络连接
    • 网络连接双方认证身份的机制
    • 额外校验
  • 启动TLS需生成加密密钥和证书
  • 证书是证明秘钥所有者身份的文件，通常是由可信的机构签发certificate authority （CA）
  • 认证需要三个文件
    • CA颁发的证书，验证是否是CA签发
    • 秘钥
    • 秘钥对应的由CA签发的证书
      image
  • 生成秘钥和证书的方法
    • 使用可信的证书签发机构
      生成的证书适用于公开不可信的网络中使用
    • 使用工具或OpenSSL命令生成自签名证书（工具例如：cfssl、ssl-manger）
      生产环境中使用自签名证书有一定不安全性建议咨询安全专家后使用
  1. TiDB开启TSL
  • 配置相应证书路径
    image
  • 对于MySQL5.7或更高的客户端，会自动检测并建议打卡TLS，无需额外设置
  • 通过客户端连接并检查TLS是否开启
    image
  • 强制开启TLS
    • 强制所有用户开启：在TiDB服务端设置specify–requier–secure-transport
    • 强制单个用户开启：设置require ssl
      image
    • 例子
      image

二、TLS攻击模式及防范

  1. 经过配置实现加密连接
  • 防止攻击者通过简单的监听网络攻击
    image
  1. 此加密无法解决中间人攻击
    image
  • 通过冒充TiDB转发客户端数据进行攻击
  1. 通过CA证书解决中间人攻击
    image
  • 配置相应证书路径
    image
  • 例子
    image
  • 要让TiDB证书认证，需要使用MySQL5.7.3以上版本客户端并指定ssl参数（旧版存在安全问题，及时指定了也可能会被关闭）
  1. 冒充客户端直接攻击TiDB
    image
  2. 通过配置客户端认证解决冒充客户端攻击
  • 配置相应证书路径
    image
    • TiDB打开TLS并配置
    • 为TiDB和客户端分别配置CA证书和客户端证书路径
  • 例子
    image
  1. 双向认证（mutual TLS or mTLS）
  • 通过TiDB和客户均添加认证实现
  • 配置TiDB
    image
  • 例子
    image
  1. TIDB组件间双向认证
    image
  • 配置TiDB
    image
  • 配置PD
    image
  • 配置TiKV
    image
  1. 通过以上所有方法建立全部加密连接认证
    image
    image743×225 23.2 KB
  2. 在线证书更换
  • 因证书过期或秘钥泄等问题露需要进行更换
  • 例子（直接配置新证书，服务器会自动识别并加载）
    image
  • 新证书至影响证书加载后的连接，原链接不受影响
  1. 更多的限制
  1. 使用Common name（CN）
  • 解决禁止例如客户端访问TiKV
  • 例如生成证书时填写TiDB Server作为CN
    image
  • TiDB配置
    image
  • PD配置
    image
  • TiKV配置
    image

三、Encryption-At-Rest

  1. 了解静态加密
  • 对静态数据进行加密Transparent Data Encryption（TDE）
  • 主要对存放在磁盘上的数据加密
  • 静态数据无法对内存或者网络传输的数据加密
  • TLS对网络层传输加密TDE对磁盘上数据加密，两者不重叠
  • 目前TiDB只支持对全量数据加密，并不支持对某个特定列单独加密
  1. 配置TiKV静态加密（数据保存在TiKV节点中）
    image
  • 支持不同长度的aes算法
  • 注意：秘钥越长安全度越高性能消耗越大
  • 需要配置主秘钥
    3.AWS KMS CMK as Master key
  • KMS是Key-Management Service
  • 原理是KMS服务器后端是用了（HSM）
  • 硬件中保存的加密密钥不会直接暴露出来，需要通过提供这个秘钥加解密接口使用（KMS服务访问）
  • 通过生成子加密秘钥对数据加密，从而间接使用了主秘钥
  • 因主秘钥不会暴露在HSM外，所以泄露风险低，
  • 通过使用AWS KMS获得一个安全性很高的秘钥，并且免去管理秘钥的麻烦和风险，生产环境中建议使用
  • 如果使用TiKV进程需要相应秘钥的访问权
  1. Envelope Encryption
  • Master key
    • AWS KMS key
    • 对数据秘钥进行加密
  • Data key
    • 是TiKV自行生成的随机串
    • 用来加密数据的密钥
    • 经过主秘钥加密后持久化保存在磁盘中
  • 信封加密的目的是为了秘钥滚动
    image
  1. Rotate Master Key
  • 秘钥滚动指定期更换密钥，并不能增加加密强度，而是在秘钥泄露或不知道秘钥泄露情况时，减少数据泄露量
  • 默认每7天滚动数据秘钥，无需手动操作，主秘钥需手动操作
  • 修主秘钥
    • 指定新的主秘钥（将旧的主秘钥重命名为previous-master-key）
      image
    • 重启TiKV
    • TiKV会自动检测，并用旧的主秘钥恢复数据秘钥，并用新的主秘钥加密数据秘钥且保存
    • 通过加密面板来查看加密状态
      image
    • 当重启以后所有TiKV节点都会在所有加密模块初始化完成后替换完成旧的主秘钥的访问权限
  1. Caveats
  • Core dump文件会保存所有未经加密的数据（包括TiKV使用加密密钥的明文）
    • 建议关闭core dump
  • PD也会保存少量原数据，且PD不提供静态数据加密功能
    • 用文件系统层加密解决
  • 在TiDB4.0版本中TiFlash也不支持静态数据加密
  • 由于加密模块使用了绝对路径来追踪文件的加密信息，类似storage.data-dir是不能更改的
2

同学你好，感谢参与 TiDB 4.0 课程的学习！

本篇笔记逻辑清晰、内容丰富，被评选为优质笔记，将额外获得 20 积分，并在 「TiDB 培训」分类下获得“置顶”权益，积分兑换规则将于近期开放，敬请关注！

期待您继续产出优质内容！

4

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。