尧图建网站 尧图建网站 YAOTU WEB BUILD 免费咨询
ARTICLE DETAIL

资讯详情

深耕网站建设与建站编程的一线实战洞察。

最小权限原则落地:pgsodium两大安全角色keyiduser与keymaker权限完全指南

最小权限原则落地:pgsodium两大安全角色keyiduser与keymaker权限完全指南 最小权限原则落地pgsodium两大安全角色keyiduser与keymaker权限完全指南【免费下载链接】pgsodiumModern cryptography for PostgreSQL using libsodium.项目地址: https://gitcode.com/gh_mirrors/pg/pgsodiumpgsodium是一个基于 libsodium 的 PostgreSQL 现代加密扩展内置pgsodium_keyiduser与pgsodium_keymaker两套嵌套安全角色帮你把最小权限原则直接落到数据库权限体系里——应用账号只给低权限角色管理账号才给高权限角色密钥最小化暴露。为什么 pgsodium 的安全角色值得新手关注在 PostgreSQL 里做加密最常见的失误不是算法选错而是权限给多了一个普通业务账号能直接读到原始密钥字节等于把保险箱的钥匙放在了门口。pgsodium 的设计思路很直接服务器根密钥在shared_preload_libraries加载后常驻内存永远不会暴露给 SQL 层数据库用户只能看到两种东西密钥 IDUUID或原始字节密钥二者权限严格分级分级由两个内置角色实现pgsodium_keyiduser低权限和pgsodium_keymaker高权限。这就是最小权限原则在加密扩展里的标准落地方式应用账号只需要能用 key id 加解密就永远不该拿到原始密钥的访问权。角色层级一张图看懂权限嵌套三个角色都是扩展安装时自动创建的NOLOGIN只供 GRANT层级关系是层层包含角色权限级别典型使用场景pgsodium_keyiduser低权限面向用户的业务应用账号pgsodium_keyholder中权限可操作原始密钥字节需要直接持有密钥的中间层pgsodium_keymaker高权限密钥管理、建库初始化、轮换密钥嵌套关系为pgsodium_keymaker→pgsodium_keyholder→pgsodium_keyiduser即高权限角色自动拥有低权限角色的全部能力。角色创建逻辑见扩展脚本 extension/pgsodium--1.1.1--1.2.0.sql其中第 231~233 行完成了嵌套授权GRANT pgsodium_keyholder TO pgsodium_keymaker; GRANT pgsodium_keyiduser TO pgsodium_keymaker; GRANT pgsodium_keyiduser TO pgsodium_keyholder;keyiduser业务应用账号的黄金选择pgsodium_keyiduser的核心特征是只能通过密钥的 UUID 调用加密函数永远拿不到原始密钥字节。它被授予执行的函数都是 key id 版本例如crypto_secretbox/crypto_secretbox_open按 key id 加解密crypto_aead_ietf_encrypt/decrypt按 key id 版本crypto_auth、crypto_auth_verify按 key id 版本crypto_secretbox_noncegen、randombytes_buf等随机数函数同时对表权限做了收紧式处理只保留对pgsodium.valid_key视图的 SELECT仅能看到密钥的元数据如 id、类型、过期时间看不到密钥材料本身。这一约束在 extension/pgsodium--3.0.4--3.0.5.sql 中实现第 13~21 行先回收全部表权限再只授予valid_key的 SELECT。适用场景90% 的业务应用账号。官方示例 example/encrypted_column.sql 就是标准做法CREATE ROLE auser; GRANT pgsodium_keyiduser TO auser; GRANT USAGE ON SCHEMA pgsodium TO auser;之后该账号即可通过 key id 完成加解密但尝试读原始密钥会直接报权限不足。keymaker密钥管理员专属的高权限角色pgsodium_keymaker是面向密钥管理操作的角色能力包括读写pgsodium.key、pgsodium.decrypted_key等密钥管理表INSERT/UPDATE/DELETE 全权限执行derive_key、各类keygen、crypto_box_new_keypair等原始密钥操作作为pgsodium.create_key()这类 SECURITY DEFINER 函数的属主负责创建新密钥。一句话原则面向用户的数据库账号永远不要授予pgsodium_keymaker。它适合授予 DBA 的运维账号或初始化脚本使用。函数属主与授权的演变过程可参考 extension/pgsodium--3.0.4--3.0.5.sql。最快配置方法三步给应用账号配好权限以创建业务账号为例最小权限配置只需三步第 1 步创建角色或直接使用已有应用账号CREATE ROLE app_user LOGIN PASSWORD ...;第 2 步授予低权限角色与 schema 使用权GRANT pgsodium_keyiduser TO app_user; GRANT USAGE ON SCHEMA pgsodium TO app_user;第 3 步如需创建密钥用 DBA 身份操作不要用 app_user-- 以管理员身份执行 SELECT * FROM pgsodium.create_key();得到的密钥 UUID 交给应用应用即可用 key id 版本函数加解密——整个过程应用账号全程接触不到任何原始密钥。 需要给应用加解密透明列加密TCE能力时同样只需keyiduser角色因为 TCE 内部走的就是 key id 通道。自检清单如何验证权限配对了pgsodium 自带一套回归测试来校验角色权限矩阵位于 test/pgsodium_schema.sql里面有两类值得借鉴的自检思路角色嵌套检查——确认keyiduser是keymaker的成员SELECT is_member_of(pgsodium_keyiduser, pgsodium_keymaker);表权限矩阵检查——确认keyiduser对valid_key视图只有 SELECT而keymaker才有写权限SELECT table_privs_are(pgsodium, valid_key, pgsodium_keyiduser, {SELECT}); SELECT table_privs_are(pgsodium, key, pgsodium_keymaker, {DELETE,INSERT,SELECT,UPDATE});日常运维时把这两类查询当作权限体检跑一遍就能确认最小权限原则没有被后续手工 GRANT 破坏。小结权限分配决策树业务应用账号 →pgsodium_keyiduser✅默认选择需要直接操作原始密钥字节 →pgsodium_keyholder谨慎建密钥、换密钥、管表 →pgsodium_keymaker仅管理员任何账号都不该顺带拿到高权限角色——给多少就只给多少pgsodium 把最小权限原则做成了开箱即用的内置角色应用侧只暴露 key id管理侧才碰原始密钥这正是 PostgreSQL 加密方案里最推荐的角色划分方式。【免费下载链接】pgsodiumModern cryptography for PostgreSQL using libsodium.项目地址: https://gitcode.com/gh_mirrors/pg/pgsodium创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表