การเข้ารหัสและ Key Management: KMS, HSM และ BYOK

การจัดการกุญแจเข้ารหัส (encryption key management) คือการดูแลกุญแจเข้ารหัสตลอดอายุการใช้งาน ตั้งแต่สร้าง เก็บ ใช้ เปลี่ยน จนถึงเลิกใช้ กุญแจคือค่าลับที่ใช้ล็อกและปลดล็อกข้อมูลที่เข้ารหัส ใครมีกุญแจก็อ่านข้อมูลนั้นได้ บทความนี้อธิบายคำสามคำที่มักปรากฏด้วยกัน คือ KMS (บริการจัดการกุญแจ) HSM (อุปกรณ์ฮาร์ดแวร์เฉพาะที่เก็บกุญแจและทำงานเข้ารหัสอยู่ภายในตัวอุปกรณ์) และ BYOK (การที่องค์กรสร้างกุญแจเอง แล้วนำไปใช้ในบริการ cloud) พร้อมอธิบายว่าทั้งสามอย่างทำงานร่วมกันอย่างไร รวมถึงการเลือกว่าใครเป็นผู้ถือกุญแจ

ทำไมกุญแจสำคัญกว่าอัลกอริทึม

อัลกอริทึมเข้ารหัส (สูตรคำนวณที่ใช้แปลงข้อมูลให้อ่านไม่ได้) ที่แข็งแรงอย่าง AES (มาตรฐานการเข้ารหัสที่ใช้กันแพร่หลาย) เปิดเผยต่อสาธารณะ และมีนักวิจัยจำนวนมากตรวจสอบแล้ว ดังนั้นสิ่งที่ปกป้องข้อมูลไม่ใช่ความลับของอัลกอริทึม แต่เป็นความลับของกุญแจ ถ้ากุญแจถูกขโมย หรือถูกเก็บไว้ติดกับข้อมูลที่มันปกป้อง การเข้ารหัสก็แทบไม่ช่วยอะไร ถ้ากุญแจหาย ข้อมูลจะกู้คืนไม่ได้ การจัดการกุญแจมีไว้ป้องกันทั้งสองกรณีนี้

วงจรชีวิตของกุญแจ

NIST SP 800-57 Part 1 คือแนวทางด้านการจัดการกุญแจของ NIST (สถาบันมาตรฐานและเทคโนโลยีของสหรัฐอเมริกา) เนื้อหาครอบคลุมบริการความปลอดภัยที่การเข้ารหัสให้ได้ อัลกอริทึมและชนิดกุญแจที่ควรใช้ วิธีปกป้องกุญแจแต่ละชนิด และงานต่าง ๆ ในการจัดการกุญแจ ฉบับสมบูรณ์ที่ใช้อยู่ตอนนี้คือ Revision 5 (ฉบับแก้ไขครั้งที่ 5) ซึ่งประกาศเมื่อเดือนพฤษภาคม 2020 ส่วน Revision 6 มีฉบับร่างแรกที่เปิดรับความเห็น ประกาศเมื่อ 5 ธันวาคม 2025 และปิดรับความเห็นเมื่อ 5 กุมภาพันธ์ 2026 ณ วันที่ 27 ตุลาคม 2026 หน้าเว็บของ NIST ที่เราอ่านยังไม่แสดงฉบับสมบูรณ์ของ Revision 6 จึงควรถือว่ายังเป็นฉบับร่าง

กุญแจแต่ละชุดผ่านขั้นตอนหลักเหล่านี้:

• สร้าง: สร้างกุญแจจากตัวสร้างค่าสุ่มที่เชื่อถือได้ โดยควรสร้างภายใน KMS หรือ HSM
• เก็บ: เก็บไว้ในที่ที่มีการป้องกัน ห้ามฝังในซอร์สโค้ด เอกสารภายใน หรือข้อความแชต
• ใช้: อนุญาตเฉพาะบุคคลและระบบที่ระบุชื่อไว้ และบันทึก log ทุกครั้งที่ใช้
• เปลี่ยน (rotate): เปลี่ยนกุญแจตามรอบเวลา และเปลี่ยนทันทีเมื่อสงสัยว่ากุญแจรั่ว
• เลิกใช้และทำลาย: หยุดใช้กุญแจ และลบก็ต่อเมื่อไม่มีข้อมูลใดต้องใช้กุญแจนั้นอีก

KMS และ HSM ทำงานร่วมกันอย่างไร

KMS คือระบบที่สร้างกุญแจ เก็บกุญแจ และควบคุมว่าใครใช้ได้ แอปพลิเคชันไม่ต้องถือกุญแจเอง แต่ส่งข้อมูลไปให้ KMS ช่วยเข้ารหัสหรือถอดรหัส ส่วน HSM คืออุปกรณ์ที่ออกแบบมาเพื่อสร้างและเก็บกุญแจ และทำงานเข้ารหัสอยู่ภายในตัวอุปกรณ์เอง กุญแจจึงไม่ออกมานอกอุปกรณ์ในรูปที่อ่านได้ ทั้งสองอย่างทำงานร่วมกัน เพราะ KMS ของ cloud หลายรายเก็บกุญแจไว้ใน HSM ตัวอย่างเช่น AWS ระบุว่ากุญแจของ AWS KMS ได้รับการปกป้องด้วย HSM ที่ผ่านการตรวจสอบรับรองตามมาตรฐาน FIPS 140-3 Security Level 3 (อธิบายในหัวข้อถัดไป)

ระบบส่วนใหญ่ใช้ envelope encryption (การเข้ารหัสสองชั้น) คือมีกุญแจสองระดับ ระดับแรกคือกุญแจข้อมูล (data key) ใช้เข้ารหัสข้อมูลจริง ระดับที่สองคือ KMS key (กุญแจหลัก) ใช้เข้ารหัสกุญแจข้อมูลอีกชั้นหนึ่ง และไม่เคยออกจาก KMS ในรูปที่อ่านได้ KMS ส่งกุญแจข้อมูลให้แอปสองแบบ คือแบบอ่านได้และแบบถูกเข้ารหัส แอปใช้แบบอ่านได้เข้ารหัสข้อมูล แล้วทิ้งแบบอ่านได้ทันที และเก็บเฉพาะแบบถูกเข้ารหัสไว้ข้างข้อมูล ภายหลังเมื่อต้องอ่านข้อมูล แอปส่งกุญแจข้อมูลแบบถูกเข้ารหัสไปให้ KMS ถอดรหัส KMS จะถอดให้เฉพาะผู้เรียกที่ได้รับอนุญาต ดังนั้นกุญแจหลักจึงอยู่ในที่เดียวที่มีการเฝ้าระวังอย่างเข้มงวด

ใครถือกุญแจ: BYOK และ HYOK

BYOK หมายถึงองค์กรสร้างกุญแจเองในสภาพแวดล้อมของตน ซึ่งมักเป็น HSM ขององค์กรเอง แล้วนำเข้าไปในบริการกุญแจของผู้ให้บริการ cloud ผู้ให้บริการแต่ละรายอธิบายแนวทางนี้ใกล้เคียงกัน AWS ระบุว่า เมื่อใช้กุญแจที่นำเข้า องค์กรยังต้องรับผิดชอบกุญแจนั้นอยู่ ขณะที่ AWS KMS ใช้สำเนาของกุญแจ ส่วน Azure Key Vault อธิบายการย้ายกุญแจจาก HSM ที่ติดตั้งในองค์กรเอง (on-premises) โดยกุญแจไม่เคยอยู่นอก HSM ในรูปที่อ่านได้ และระหว่างย้ายถูกปกป้องด้วยกุญแจที่อยู่ใน HSM ของ Azure Key Vault ข้อควรระวังคือผู้ให้บริการยังมีสำเนาที่ใช้งานได้ BYOK จึงเปลี่ยนแค่ว่าใครเป็นผู้สร้างกุญแจ ไม่ได้เปลี่ยนว่าใครใช้กุญแจนั้นได้

HYOK (hold your own key คือการเก็บกุญแจไว้กับตนเองเท่านั้น) ไปไกลกว่านั้น กุญแจอยู่นอก cloud บริการ cloud ต้องส่งทุกคำขอเข้ารหัสหรือถอดรหัสไปให้ตัวจัดการกุญแจ (key manager) ที่องค์กรดูแลเอง AWS เรียกแบบของตนว่า external key store (ที่เก็บกุญแจภายนอก) ถ้าตัดการเข้าถึงตัวจัดการกุญแจนั้น AWS จะใช้กุญแจไม่ได้ และข้อมูลที่เข้ารหัสด้วยกุญแจเหล่านั้นจะถอดรหัสไม่ได้ ถ้ากุญแจสูญหายถาวร ข้อมูลก็กู้คืนไม่ได้ AWS เองเตือนว่าวิธีนี้เพิ่มภาระการดำเนินงาน เพิ่มความเสี่ยงด้านความพร้อมใช้งาน (ระบบอาจใช้ไม่ได้) และความหน่วง (ตอบสนองช้าลง) AWS ยังระบุว่าสำหรับงานส่วนใหญ่ ต้นทุนเหล่านี้มากกว่าประโยชน์ด้านความปลอดภัยที่คาดไว้ วิธีนี้ยังเปลี่ยนหน้าที่ระหว่างลูกค้ากับผู้ให้บริการ ดูได้ใน Cloud shared responsibility model

ตัวเลือกที่พบบ่อยมีดังนี้ เรียงจากควบคุมน้อยและทำงานน้อย ไปจนควบคุมมากและทำงานมาก

• กุญแจที่ผู้ให้บริการเป็นเจ้าของ: ง่ายที่สุด แต่องค์กรเปลี่ยนนโยบายของกุญแจหรือตรวจสอบการใช้งานไม่ได้ (นี่คือวิธีที่ AWS อธิบาย AWS owned key ผู้ให้บริการรายอื่นอาจต่างออกไป)
• กุญแจแบบองค์กรจัดการเอง (customer managed key) ใน KMS บน cloud: องค์กรกำหนดนโยบายการเข้าถึง รอบการเปลี่ยนกุญแจ และการลบ รวมทั้งตรวจสอบการใช้งานได้
• BYOK: องค์กรสร้างกุญแจแล้วนำเข้า ส่วนผู้ให้บริการยังมีสำเนาที่ใช้งานได้
• HYOK หรือ external key store: กุญแจไม่เข้าไปอยู่กับผู้ให้บริการเลย องค์กรดูแลตัวจัดการกุญแจเอง และรับความเสี่ยงด้านความพร้อมใช้งาน

FIPS 140-3: คำว่า "ผ่านการรับรอง" หมายถึงอะไร

FIPS 140-3 คือมาตรฐานของรัฐบาลสหรัฐฯ ว่าด้วยความปลอดภัยของโมดูลเข้ารหัส (cryptographic module) โมดูลเข้ารหัสหมายถึงฮาร์ดแวร์หรือซอฟต์แวร์ที่ทำงานเข้ารหัส เช่น HSM NIST ระบุว่ามาตรฐานนี้ประกาศใช้เมื่อเดือนมีนาคม 2019 และมีผลวันที่ 22 กันยายน 2019 มาตรฐานนี้อ้างถึง ISO/IEC 19790:2012 ซึ่งกำหนดระดับความปลอดภัยไว้สี่ระดับ ผู้ผลิตจึงมักระบุระดับ เช่น Level 3

การรับรองใช้กับโมดูลหนึ่งรุ่นโดยเฉพาะ ห้องปฏิบัติการเป็นผู้ทดสอบ และรายชื่อจะอยู่ในฐานข้อมูลของ CMVP (โปรแกรมตรวจรับรองโมดูลเข้ารหัสของสหรัฐฯ) เมื่อผู้ผลิตบอกว่า "ผ่าน FIPS" ให้ขอเลขที่ใบรับรอง และตรวจว่าโมดูลและเวอร์ชันในรายการตรงกับที่ใช้จริง CMVP ระบุว่า การรับรองตาม FIPS 140-3 อยู่ในรายการ Active (รายการที่ยังใช้ได้) เป็นเวลา 5 ปี ส่วน FIPS 140-2 ซึ่งเป็นฉบับเก่า CMVP ระบุว่าหน่วยงานของรัฐสหรัฐฯ ยอมรับการรับรองฉบับนี้ได้ถึง 21 กันยายน 2026 หลังจากนั้นใบรับรองจะย้ายไปรายการ Historical (รายการเก่า) ซึ่งใช้ต่อได้เฉพาะในระบบที่มีอยู่แล้ว วันที่นี้ผ่านไปแล้ว ดังนั้นควรตรวจว่าผลิตภัณฑ์ที่จะซื้อยังอาศัยใบรับรอง FIPS 140-2 อยู่หรือไม่

การจัดการกุญแจกับการเข้ารหัสยุคหลังควอนตัม

การจัดการกุญแจต้องเตรียมรับ post-quantum cryptography (PQC คือการเข้ารหัสแบบใหม่ที่ออกแบบให้ทนต่อคอมพิวเตอร์ควอนตัมในอนาคต) ด้วย ฉบับร่าง Revision 6 ของ SP 800-57 Part 1 เพิ่มอัลกอริทึมยุคหลังควอนตัม และอธิบายกุญแจที่ใช้ตกลงกุญแจ (key establishment คือการทำให้สองฝ่ายมีกุญแจใช้ร่วมกัน) แยกจากกุญแจที่ใช้เก็บกุญแจ (key storage) ควรถามผู้ผลิต KMS และ HSM ว่ามีแผนรองรับ PQC หรือไม่ และมีวิธีเพิ่มอัลกอริทึมใหม่โดยไม่ต้องเปลี่ยนฮาร์ดแวร์หรือไม่ อ่านเพิ่มที่ PQC คืออะไร และ Crypto-agility และ CBOM

ข้อผิดพลาดที่พบบ่อย

• เก็บกุญแจในซอร์สโค้ด ไฟล์ตั้งค่า หรือไดรฟ์ที่แชร์ร่วมกัน: ใครอ่านที่เก็บโค้ด (repository) หรือไดรฟ์นั้นได้ ก็อ่านกุญแจได้
• ใช้กุญแจชุดเดียวกับทุกอย่างและไม่เคยเปลี่ยน: ถ้ารั่วครั้งเดียว ข้อมูลทั้งหมดก็ถูกเปิดได้
• เข้าใจว่า BYOK คือควบคุมได้เต็มที่: ผู้ให้บริการยังมีสำเนากุญแจที่ใช้งานได้
• ไม่มีวิธีกู้กุญแจที่ทดสอบแล้ว: ถ้ากุญแจหายหรือถูกลบ ข้อมูลก็หายไปด้วย โดยเฉพาะกุญแจที่นำเข้าและ HYOK
• รับคำว่า "ผ่าน FIPS" โดยไม่ตรวจ: ใบรับรองต้องครอบคลุมโมดูลและเวอร์ชันที่ใช้จริง
• ให้บัญชีบริการ (service account) ไหนก็เรียก KMS ได้: บัญชีบริการคือบัญชีที่โปรแกรมใช้ ไม่ใช่คน การใช้กุญแจควรให้สิทธิ์เท่าที่จำเป็น (least privilege) และต้องมี log

ขั้นแรกที่ทำได้ทันที

• ทำรายการกุญแจ: จดว่ากุญแจแต่ละชุดอยู่ที่ไหน ปกป้องข้อมูลอะไร และใครเป็นเจ้าของ
• ย้ายกุญแจออกจากโค้ดและไฟล์ตั้งค่า: ไปไว้ใน KMS หรือบริการที่มี HSM รองรับอยู่เบื้องหลัง
• แยกกุญแจตามวัตถุประสงค์: ใช้กุญแจคนละชุดสำหรับงานคนละอย่าง และตั้งรอบการเปลี่ยนกุญแจสำหรับกุญแจที่สำคัญที่สุด
• ทดสอบการกู้คืน: ลองกู้จากข้อมูลสำรอง โดยทำตามขั้นตอนที่จดไว้เท่านั้น
• จำกัดและบันทึกการใช้กุญแจ: ให้เฉพาะบุคคลและบัญชีบริการที่ระบุชื่อ ดูแนวทางใน บัญชีที่ไม่ใช่คนและ service account
• เลือก BYOK หรือ HYOK ตามข้อกำหนดจริง: จดเหตุผลไว้ก่อนเริ่มใช้ทั้งสองแบบ

หากต้องการดูว่าการจัดการกุญแจเข้ากับมาตรการความปลอดภัยอื่นขององค์กรอย่างไร ลองใช้ แบบประเมินตนเอง

ขอบเขตและความถูกต้อง

เราอ่านแหล่งข้อมูลเมื่อ 27 ตุลาคม 2026 หน้าของ AWS และ Azure อธิบายเฉพาะผู้ให้บริการสองรายนี้ รายอื่นอาจใช้ชื่อเรียกและมีข้อจำกัดต่างออกไป สถานะของ NIST SP 800-57 Part 1 Revision 6 และของใบรับรอง FIPS 140-2 เปลี่ยนได้ ก่อนอ้างอิงควรตรวจที่ csrc.nist.gov อีกครั้ง บทความนี้เป็นข้อมูลทั่วไป ไม่ใช่คำแนะนำด้านกฎหมายหรือด้านการปฏิบัติตามกฎระเบียบ

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• NIST SP 800-57 Part 1 Rev. 5: แนวทางจัดการกุญแจฉบับสมบูรณ์ปัจจุบัน (พฤษภาคม 2020)
• NIST SP 800-57 Part 1 Rev. 6 (initial public draft): ฉบับร่างเดือนธันวาคม 2025 และสิ่งที่เสนอเปลี่ยน
• NIST CMVP: FIPS 140-3 standards: วันที่ประกาศและวันที่มีผล และความเกี่ยวข้องกับ ISO/IEC 19790
• NIST Cryptographic Module Validation Program: รายการ Active และ Historical และการเปลี่ยนผ่านจาก FIPS 140-2
• AWS KMS overview: KMS ปกป้องอะไร และข้อความเรื่องการรับรอง HSM
• AWS KMS: key types and key hierarchy: กุญแจแต่ละประเภท (customer managed, AWS managed, AWS owned) และ data key
• AWS KMS: importing key material (BYOK): สิ่งที่องค์กรยังต้องรับผิดชอบ
• AWS KMS: external key stores: แนวทาง HYOK ข้อแลกเปลี่ยน และความรับผิดชอบร่วมกัน
• Azure Key Vault: bring your own key specification: กุญแจย้ายจาก HSM ในองค์กรอย่างไร