logrotate不支持加密，需通过postrotate脚本分步实现轮转、压缩、加密；必须禁用nocompress避免与默认compress冲突，并在postrotate中用gzip -c与gpg管道加密后立即删除明文文件。
logrotate 本身不提供加密功能，所谓“加密归档”其实是分步实现的：先轮转、再压缩、最后加密，全部靠 postrotate 脚本串起来。关键不是加功能，而是控制执行时机和流程顺序——必须在日志已重命名但尚未被删时操作，且不能和 logrotate 自带的 compress 冲突。
禁用默认压缩，手动接管全流程
logrotate 的 compress 选项会自动调用 gzip 并加 .gz 后缀，如果你后续再用 gpg 加密 audit.log.1.gz，就可能出错或留下未加密副本。所以第一步是明确关掉它：
- 配置中必须写 nocompress（不能只不写 compress，默认可能继承全局设置）
- 如果想调试方便，可加 delaycompress，但它会让 .1 文件明文多留一轮，加密前得主动清理
- auditd 若自身启用了
max_log_file_action = rotate+compress，也得先关掉，避免双压缩覆盖
在 postrotate 中完成压缩+加密+清理
postrotate 是唯一安全的操作窗口：此时 audit.log 已被重命名为 audit.log.1，原文件为空且正由 auditd 继续写入新内容。你可以放心处理 .1 文件：
- 用
gzip -c流式压缩，避免生成中间明文文件 - 管道直连
gpg --batch --yes --encrypt --recipient 'audit-key'，输出加密后文件（如.1.gz.gpg） - 加密成功后立即
rm /var/log/audit/audit.log.1，不留明文残留 - 务必检查返回值：
|| exit 1或开头加set -e，失败时不继续，防止日志裸奔
确保 GPG 环境可靠无交互
logrotate 默认以 root 运行，但 gpg 可能因环境缺失找不到密钥：
- 确认密钥已导入：
gpg --list-keys --homedir /root/.gnupg，recipient 名必须完全匹配 UID - 不要用带密码短语的私钥——无法无交互解密；若必须，需配
gpg-agent和--pinentry-mode loopback，运维成本陡增 - 必要时显式指定 keyring 路径：
--homedir /root/.gnupg，避免依赖 $HOME - 国外 VPS 场景下，建议提前测试网络和磁盘 I/O 对加密延迟的影响，NVMe 环境下 AES-256-CBC + RSA-4096 混合加密 CPU 开销约 +15%
归档路径与权限要同步设计
加密后的文件不能随便放，要考虑访问控制和解密便利性：
- 输出路径建议和原日志同目录（如
/var/log/audit/audit.log.1.gz.gpg），避免跨分区或 NFS 导致权限/性能问题 - 新文件属主应为 root:root，权限设为 0600，防止非授权读取
- 解密脚本最好和归档逻辑配套，例如：
gpg --decrypt audit.log.1.gz.gpg | gunzip -c，验证流程闭环 - 如需长期合规存档，可配合 HashiCorp Vault 或 AWS KMS 托管加密密钥，定期轮换降低泄露风险
