<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>BYOK on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/byok/</link><description>Recent content in BYOK on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Mon, 08 Jun 2026 09:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/byok/feed.xml" rel="self" type="application/rss+xml"/><item><title>FDE 面試指南 Part 46：高規格金融業的數據無痕化與自主密鑰管理（BYOK / CMEK in GenAI）</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part46-byok-cmek-zh/</link><pubDate>Mon, 08 Jun 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part46-byok-cmek-zh/</guid><description>大多數工程師聽到「CMEK 合規」就只想到：把 Cloud KMS 打開、勾選客戶管理密鑰就完事了。 真正的挑戰在於：當 Vertex AI 向量搜索每秒發起 5,000 次 ANN 查詢、每次都要跨海解密時， 延遲從 30ms 暴增到 12 秒——合規達成了，系統卻癱瘓了。 Staff FDE 的答案是：用信封加密的 DEK/KEK 分層，讓地端 HSM 只做密鑰授權， 日常解密在 GCP Memory Enclave 裡完成，真正做到主權資安與極限性能同時成立。
面試情境 面試官： 某家公營銀行的 CISO 要求所有上傳到 Vertex AI 的 Embedding 向量和 LLM Context Cache 快照，加密密鑰必須由行內地端機房的 HSM 自主控管，絕對不能讓雲端供應商持有明文密鑰。但向量搜索的 SLA 是 P99 &amp;lt; 50ms，Context Cache 的命中率目標是 85%。你如何設計這套系統，讓合規與性能同時成立？
一、核心問題：為什麼 CMEK 在 GenAI 場景特別難 1.1 金融業的監管壓力 台灣金融監理局（FSC）、PCI DSS Level 1、以及個人資料保護法（PDPA）三重框架對金融業的加密要求達到史上最嚴格水準：
密鑰主權：加密密鑰的控制權必須留在金融機構手中，雲端供應商不得持有明文 KEK 審計可追溯：每一次密鑰使用（加密/解密/輪轉）必須留下不可竄改的操作日誌 密鑰隔離：不同業務線（個人金融、企業金融、投資銀行）的密鑰必須完全隔離 快速撤銷：監管機構要求在 15 分鐘內能夠撤銷任何密鑰的使用授權 1.</description></item></channel></rss>