怎样使用Python和Cryptography库对自动化脚本中的敏感配置进行加密？-Python教程-PHP中文网

fernet.encrypt()只接受bytes，须用'rb'模式读取文件；加密结果需base64编码存储；密钥须独立安全存储且不可硬编码；多文件加密应复用密钥而非salt；解密后才可解析为json。

怎样使用python和cryptography库对自动化脚本中的敏感配置进行加密？

Fernet.encrypt() 只接受 bytes，传 str 会直接报错

自动化脚本里读配置文件（如 config.json、.env）时，常习惯用 open(path, 'r') 得到字符串，然后直接喂给 Fernet.encrypt() —— 这必然触发 TypeError: data must be bytes。

根本原因是 Fernet 是二进制安全的加密器，不处理编码/解码逻辑。哪怕你读的是纯文本，也必须以 'rb' 模式打开，得到原始 bytes：

with open('config.json', 'rb') as f:
    raw_data = f.read()  # ← 必须是 bytes
cipher = Fernet(key)
encrypted = cipher.encrypt(raw_data)  # ← 才能过

别用 .encode('utf-8') 补救：如果文件本身含 BOM、混合编码或二进制内容（比如 base64 字段），.encode() 会静默损坏数据
别用 str(encrypted) 或 encrypted.decode() 存储：加密结果含不可见字节，强转字符串会破坏结构，后续 decrypt() 必报 InvalidToken
存储加密结果时，统一用 base64.urlsafe_b64encode(encrypted).decode('ascii') 转成安全字符串；解密前再 base64.urlsafe_b64decode(...) 回 bytes

密钥不能硬编码，也不能和配置文件放一起

把 key = b'gAAAAAB...' 写死在脚本里，等于把保险柜钥匙焊死在柜门上。更糟的是，若把密钥文件（如 secret.key）和加密后的 config.json.enc 放同一目录，攻击者拿到目录就全盘皆输。

正确做法是分离存储 + 权限控制：

密钥存独立路径，比如 Path(__file__).parent / '..' / 'keys' / 'prod.key'，且该目录不纳入部署包
Linux/macOS 下设权限：chmod 600 keys/prod.key；Windows 下禁用继承权限，仅保留当前用户读取
加载时加存在性校验：if not key_path.exists(): raise FileNotFoundError("密钥文件缺失")
绝不用环境变量传完整密钥（易被 ps aux 或日志泄露），可用环境变量指定密钥路径

批量加密多个配置文件时，复用密钥但别复用 salt

crypto skill

提供飞书加密群聊摘要、合约地址反查、热门代币统计、KOL分析及链上代币数据查询的综合加密社区服务。

下载

你可能想用同一个密码派生密钥（PBKDF2）加密 dev.env.enc、prod.env.enc、db.yaml.enc —— 这没问题，Fernet 允许密钥复用。但注意：如果每次调用都用新 salt（比如 secrets.token_bytes(16)），那每个文件的派生密钥都不同，根本没法统一解密。

所以关键点是：salt 必须固定且随密钥一起保存，而不是每次加密都重生成。

生成密钥时，用固定 salt + 高迭代数（≥100000）派生：PBKDF2(..., salt=b'static_16byte_salt', iterations=100000)
或者更简单：直接用 Fernet.generate_key() 生成一次密钥，存为 secret.key，所有配置文件共用它
切勿为每个文件生成新密钥——管理成本爆炸，且脚本启动时无法动态决定用哪个密钥解哪份配置

加密后配置无法直接被 configparser / json.load 读取

加密不是“隐藏”，而是彻底改变数据形态。你不能再把 config.json.enc 当作 JSON 文件传给 json.load()，否则会报 JSONDecodeError 或乱码。

必须在加载配置前插入解密环节：

# 加载并解密配置
with open('config.json.enc', 'rb') as f:
    encrypted = f.read()
decrypted_bytes = cipher.decrypt(encrypted)
config_dict = json.loads(decrypted_bytes.decode('utf-8'))  # ← 此时才是合法 JSON

不要在解密后做多余操作：比如用 str.replace() 清理空白、或用 ast.literal_eval() 解析——这些都会破坏原始结构
如果配置含非 UTF-8 编码（如 GBK 的旧系统配置），解密后需用对应编码 .decode('gbk')，而非默认 utf-8
异常要捕获 InvalidToken（密钥错/数据损）、UnicodeDecodeError（编码不匹配）、json.JSONDecodeError（原始配置本身就不合法）

真正麻烦的不是加解密动作本身，而是密钥生命周期管理：生成、存储、加载、轮换、销毁。少一个环节，整个链路就裸奔。尤其当脚本跑在 CI/CD 或容器里时，secret.key 的挂载方式、权限传递、是否进镜像，每一个都得亲手核对。