连接支付、电子发票或其他外部服务时，您会把该服务核发的密钥或凭证提供给 Kanorio。这些资料一旦外流，他人就可能以您的名义收款、开立文件或调用服务，因此 Kanorio 采用独立的保管机制处理，而不是和一般网站资料一起存放。
本页说明这套机制的设计原则：密钥如何加密、如何隔离、谁能存取、如何留存记录，以及删除后的处理。关于哪些功能需要提供密钥、要到哪里获取，请见各功能的设置说明。
Kanorio 采用云端服务普遍使用的信封加密（Envelope Encryption），把“加密资料的密钥”和“保护这把密钥的主密钥”分开管理：
这样的分层意味着：即使数据库或备份被取得，没有密钥管理服务的授权也无法解开任何一组密钥。
每组密钥加密时都会绑定它所属的网站与用途。密文若被复制到其他网站，或内容遭到篡改，解密时的完整性验证就会失败，系统会直接拒绝使用。不同网站之间的密钥无法互相挪用。
少数密钥是由 Kanorio 产生、需要您设置到自己的系统中（例如用来验证通知来源的签名密钥）。这类密钥拥有者与管理员可以再次查看，每次查看都会留下记录。
这些记录只记录“谁、何时、为了什么”，不包含密钥内容本身。
Kanorio 负责保管您提供的密钥；密钥本身的核发、撤销与权限范围，则由核发它的服务商管理。建议您：
看不到。Kanorio 的管理后台与客服工具都没有查看密钥的功能，存储后画面上只会显示遮罩。密钥只在系统替您执行收款、退款、开立文件等动作的当下自动解密，过程不经人手，每一次取用都会留下记录。
要说明的是，Kanorio 必须能解开密钥，才能代您调用金流与发票服务，因此这不是"连 Kanorio 都无法解开"的设计。我们把这项能力限缩到最小：解密只能通过 Google Cloud 密钥管理服务进行，权限只授予执行服务的系统账号，每一次解密在 Google Cloud 端也会另外留下记录。
数据库只保存加密后的密钥，以及同样经过加密的资料密钥。要解开它们，必须取得密钥管理服务的授权，单靠数据库或备份无法还原任何一组密钥。
请不要。客服不需要、也不会向您索取任何密钥。设置遇到问题时，请描述画面上的错误信息，并提供网站名称与服务名称即可。
先到核发密钥的服务商后台撤销并重新产生，旧的一组就会失效。接着回 Kanorio 填入新密钥并测试连接。若怀疑是 Kanorio 账号被他人登录，请同时阅读安全问题处理。
密钥分层管理依循 NIST SP 800-57 的密钥管理建议，资料以业界通用的 AES-256-GCM 加密并验证完整性。主密钥交由 Google Cloud 密钥管理服务保管，其密码模块通过 FIPS 140-2 验证，这也是大型云端服务保护客户密钥的常见做法。