สมัครเพื่อรับการแจ้งเตือนเมื่อมีโพสต์ใหม่:สมัครรับข้อมูล

ตอนนี้ Keyless SSL รองรับโมดูลความปลอดภัยฮาร์ดแวร์ FIPS 140-2 L3 (HSM) ที่เสนอโดยผู้ให้บริการระบบคลาวด์รายใหญ่ทั้งหมด

27/03/2564

อ่านเมื่อ 3 นาทีก่อน
Keyless SSL now supports FIPS 140-2 L3 hardware security module (HSM) offerings from all major cloud providers

ในตอนนี้ คีย์เข้ารหัสส่วนตัวที่จัดเก็บไว้ในโมดูลความปลอดภัยฮาร์ดแวร์จากผู้ให้บริการระบบคลาวด์รายใหญ่ทั้งหมด สามารถถูกนำมาใช้เพื่อรักษาความปลอดภัยการเชื่อมต่อ HTTPS ภายในสภาพแวดล้อม Edge ทั่วโลกของ Cloudflare ได้แล้ว

Cloudflare สร้าง ปกป้อง และจัดการคีย์ส่วนตัว SSL/TLS มากกว่าองค์กรใด ๆ ในโลก คีย์ส่วนตัวต้องได้รับการปกป้องอย่างระมัดระวัง เนื่องจากผู้โจมตีที่เป็นเจ้าของคีย์หนึ่งสามารถแอบอ้างว่าตนเป็นไซต์ที่ถูกต้องและถอดรหัสคำขอ HTTPS ได้ หากต้องการบรรเทาความเสี่ยงนี้ Cloudflare มีขั้นตอนการจัดการคีย์ที่เข้มงวดและเลเยอร์การแยก ที่ Edge ซึ่งออกแบบมาเพื่อปกป้องคีย์ไม่ว่าจะด้วยวิธีใดก็ตาม แต่สำหรับลูกค้าส่วนน้อยที่มีนโยบายการรักษาความปลอดภัยของข้อมูลที่กำหนดตำแหน่งที่พวกเขาสามารถ (หรือไม่สามารถ) ดูแลคีย์ได้ การป้องกันเหล่านี้จะไม่ตอบโจทย์ความต้องการของตน

เราเปิดตัว Keyless SSL ครั้งแรกในปี 2014 เพื่อลูกค้าเหล่านี้ ผลิตภัณฑ์ดังกล่าวคือโปรโตคอลที่เราใช้อย่างกว้างขวางภายในเครือข่ายของเรา: TLS handshakes ทั้งหมดต่อหนึ่งวันที่จัดตั้งขึ้นที่ Cloudflare Edge ซึ่งเกิดขึ้นในกระบวนการที่ไม่สามารถเข้าถึงคีย์ส่วนตัวของลูกค้าของเราได้ ข้อมูลที่จำเป็นในการสร้างเซสชันจะถูกส่งไปยังระบบที่แยกจากกันแทน ซึ่งกำหนดให้ต้องเซ็นชื่อเข้ารหัสที่จำเป็น ในส่วนของคีย์ที่อัปโหลดหรือสร้างโดย Cloudflare นั้น เราจัดการระบบอื่นนี้ แต่ลูกค้าบางรายต้องการจัดการด้วยตนเอง

[LOGICAL DIAGRAM SHOWING PRIVATE KEYS STORED ON HSMs BEING USED FOR TLS HANDSHAKE]

คีย์เคยถูกวางไว้บนเซิร์ฟเวอร์ที่ใช้งาน gokeyless daemon แบบโอเพ่นซอร์ส ที่เราจัดเตรียมไว้เพื่อดำเนินการ handshake หรือรักษาความปลอดภัยให้กับโมดูลความปลอดภัยของฮาร์ดแวร์ (HSM) ภายในองค์กรที่เชื่อมประสานแบบ gokeyless โดยใช้โปรโตคอลมาตรฐานที่เรียกว่า PKCS#11 อย่างไรก็ตาม เนื่องจากบริการทางการเงิน การดูแลสุขภาพ สกุลเงินคริปโต และบริษัทที่มีการควบคุมอย่างเข้มงวดหรือเน้นการรักษาความปลอดภัยอื่น ๆ ได้ย้ายไปยังระบบคลาวด์ บริษัทเหล่านี้จึงไม่สามารถจัดส่งกล่องราคาแพงเหล่านี้และขอให้ Amazon, Google, IBM หรือ Microsoft จัดวางและวางซ้อนกัน

สำหรับลูกค้าเหล่านี้ โดยเฉพาะอย่างยิ่งผู้ที่มีนโยบายการรักษาความปลอดภัยของข้อมูลบังคับ FIPS 140-2 Level 3 HSM ที่ผ่านการตรวจสอบความถูกต้องแล้ว เราขอประกาศว่า ขณะนี้ Keyless SSL รองรับ HSM ที่โฮสต์บนคลาวด์ต่อไปนี้: Amazon Cloud HSM; Google Cloud HSM; IBM Cloud HSM; Microsoft Azure Dedicated HSM และ Managed HSM เรายังสนับสนุน HSM อื่น ๆ ที่ใช้มาตรฐาน PKCS#11 รวมถึงซีรีส์ต่าง ๆ เช่น nCipher nShield Connect และ Thales Luna

ภาพรวมของ HSM

HSM เป็นเครื่องจักรที่สร้างขึ้นโดยเฉพาะซึ่งทนทานต่อการงัดแงะและจุดอ่อนต่าง ๆ เช่น การโจมตีช่องด้านข้าง และปรับให้เหมาะกับการดำเนินการเข้ารหัส เช่น การลงนามและการถอดรหัส เราสามารถนำ HSM มาใช้เป็นกล่องแบบสแตนด์อโลน เป็นการ์ดส่วนขยายที่เสียบในเซิร์ฟเวอร์ หรือที่เพิ่งเกิดขึ้นคือ ใช้เป็นบริการคลาวด์

แทนการสร้างคีย์ส่วนตัวบนเซิร์ฟเวอร์และอัปโหลดไปยัง HSM ผู้ขายและผู้เชี่ยวชาญด้านความปลอดภัยมักจะแนะนำให้สร้างคีย์บนตัวอุปกรณ์เอง (และไม่มีการส่งออกไปโดยสิ้นเชิง) HSM มีการรับประกันแบบสุ่มที่ดีกว่าเซิร์ฟเวอร์ทั่วไป และใช้ความระมัดระวังเป็นพิเศษเมื่อปกป้องคีย์ในหน่วยความจำก่อนที่จะซิงโครไนซ์กับดิสก์ในสถานะที่เข้ารหัสแล้ว เมื่อจำเป็นต้องดำเนินการใดก็ตามที่ต้องใช้คีย์ส่วนตัว บริการต่าง ๆ จะใช้ไลบรารีที่ผู้จำหน่าย HSM จัดหาให้เพื่อเรียก API ที่ตรวจสอบสิทธิ์เรียบร้อยแล้วลงในอุปกรณ์

HSM และ FIPS 140-2 ระดับ 3

โดยปกติ HSM จะได้รับการตรวจสอบเทียบกับสิ่งพิมพ์ของ Federal Information Process Standard (FIPS) 140-2: Security Requirements for Cryptographic Modules ซึ่งแบ่งออกเป็น 4 ระดับ — 1 ถึง 4 — ทำหน้าที่ระบุข้อกำหนดที่เข้มงวดมากขึ้นเรื่อย ๆ เกี่ยวกับอัลกอริทึมที่ได้รับอนุมัติ ฟังก์ชันความปลอดภัย การควบคุมการเข้าถึงตามบทบาท และการป้องกันหลักฐานการงัดแงะ/ป้องกันการงัดแงะ

สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ (NIST) เผยแพร่แนวทางเหล่านี้ บริหารจัดการ 1Cryptographic Module Validation Program และเผยแพร่ฐานข้อมูลที่ค้นหาได้ของโมดูลที่ผ่านการตรวจสอบแล้ว ซึ่งรวมถึงข้อเสนอตามรายการด้านล่าง เรายังได้จัดเตรียมคำแนะนำเกี่ยวกับวิธีการใช้งานร่วมกับ Cloudflare

เริ่มต้นด้วยข้อเสนอของระบบคลาวด์

ลูกค้า Keyless SSL ที่มีอยู่ทั้งหมดสามารถใช้เทคโนโลยีนี้ได้ทันที และคุณสามารถอ่านคำแนะนำวิธีดำเนินการได้ที่ https://developers.cloudflare.com/ssl/keyless-ssl/hardware-security-modules ส่วนรหัสต้นทางรวมอยู่ที่ GitHub: https://github.com/cloudflare/gokeyless

ตัวอย่างแบบครบวงจร: Microsoft Azure Managed HSM

ทีม Azure Key Vault ของ Microsoft เปิดตัว Managed HSM ข้อเสนอนี้ได้รับการตรวจสอบ FIPS 140-2 ระดับ 3 และรวมเข้ากับบริการ Azure เช่น Azure Storage, Azure SQL และ Azure Information Protection ทั้งนี้ Managed HSM มีให้บริการในภูมิภาคต่อไปนี้: ชายฝั่งตะวันออกของสหรัฐ 2, ตอนใต้ของสหรัฐอเมริกาตอนกลาง, ยุโรปเหนือ และยุโรปตะวันตก

คำแนะนำด้านล่างนำมาจากคู่มือ Quickstart: Provision and activate a managed HSM using Azure CLI ตามด้วยคำแนะนำวิธีใช้ Managed HSM ร่วมกับ Cloudflare คำสั่งถูกรันบน Ubuntu VM ที่สร้างขึ้นในภูมิภาคเดียวกัน (ตอนใต้ของสหรัฐอเมริกาตอนกลาง) กับ HSM ตำแหน่งที่ตั้งนี้ยังเป็นที่ที่เราจะปรับใช้ Cloudflare Keyless SSL daemon

การจัดเตรียมและเปิดใช้งาน HSM

ขั้นแรก เราล็อกเข้าสู่ระบบผ่าน CLI และสร้างกลุ่มทรัพยากรสำหรับ Managed HSM ในภูมิภาคที่รองรับหนึ่งภูมิภาค โปรดทราบว่าคุณอาจได้รับคำเตือนจากคำสั่งต่าง ๆ ตามสถานะการแสดงตัวอย่างของข้อเสนอ

$ LOCATION=southcentralus; GROUPNAME=”HSMgroup”; HSMNAME=”KeylessHSM”
$ az login
$ az group create --name $GROUPNAME --location $LOCATION

ขั้นตอนถัดไป คือเราจะจัดเตรียมทรัพยากร HSM และเปิดใช้งานโดยดาวน์โหลดโดเมนความปลอดภัย ตัวอย่างด้านล่างแสดงถึงการให้สิทธิ์การเข้าถึงระดับผู้ดูแลระบบแก่ผู้ใช้ที่ลงชื่อเข้าใช้ พร้อมด้วยผู้ดูแลระบบรายอื่นที่สามารถเรียกข้อมูล OID ได้โดยดำเนินการคำสั่ง oid=$(...) เดียวกันจาก CLI ที่ผู้ใช้ล็อกเข้าสู่ระบบ

$ MYOID=$(az ad signed-in-user show --query objectId -o tsv)
$ OTHERADMIN_OID=...

$ az keyvault create --hsm-name $HSMNAME --resource-group $GROUPNAME --location $LOCATION --administrators $MYOID $OTHERADMIN_OID

Argument '--hsm-name' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
Argument '--administrators' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
{- Finished ..
  "id": "/subscriptions/.../resourceGroups/HSMgroup/providers/Microsoft.KeyVault/managedHSMs/Keyles
sHSM",
  "location": "southcentralus",
  "name": "KeylessHSM",
  "properties": {
    "createMode": null,
    "enablePurgeProtection": false,
    "enableSoftDelete": true,
    "hsmUri": "https://keylesshsm.managedhsm.azure.net/",
    "initialAdminObjectIds": [
      "$MYOID",
      "$OTHERADMIN_OID"
    ],
    "provisioningState": "Succeeded",
    "softDeleteRetentionInDays": 90,
    "statusMessage": "The Managed HSM is provisioned and ready to use.",
    "tenantId": "..."
  },
  "resourceGroup": "$GROUPNAME",
  "sku": {
    "family": "B",
    "name": "Standard_B1"
  },
  "tags": {},
  "type": "Microsoft.KeyVault/managedHSMs"
}

การดำเนินการนี้จะส่งคืน URI ที่คุณจะเพิ่มลงในไฟล์ Keyless YAML ในภายหลังเพื่อระบุตำแหน่งที่คุณจะจัดเก็บคีย์ส่วนตัว

$ HSMURI="https://keylesshsm.managedhsm.azure.net/"

คุณเตรียมการใช้งานและเปิดใช้งาน HSM แล้ว คุณต้องสร้าง VM ที่คุณจะปรับใช้ Keyless daemon สำหรับตัวอย่างนี้ เราจะสร้าง Ubuntu Xenial VM ใน Azureเมื่ออยู่ในพอร์ทัล ให้ไปที่หน้า Virtual machines และเพิ่ม VM คุณสามารถใช้กลุ่มทรัพยากรที่คุณสร้างไว้ก่อนหน้านี้สำหรับ HSM ได้ แต่เพื่อให้ได้ผลลัพธ์ที่ดีที่สุด ให้เลือกภูมิภาคเดียวกับของ HSM สำหรับ IP สาธารณะของ VM คุณจะใช้ข้อมูลนี้เพื่อเชื่อมต่อกับเซิร์ฟเวอร์จากระยะไกล

หลังจากนั้น ให้กำหนดค่า VM ของคุณเป็นคีย์เซิร์ฟเวอร์ โดยคุณต้องเพิ่ม Cloudflare Package Repository ก่อน จากนั้นให้อัปเดตรายการแพ็คเกจของระบบปฏิบัติการและติดตั้งเซิร์ฟเวอร์ gokeyless

$ openssl req -newkey rsa:2048 -nodes -keyout cert_0.key -x509 -days 365 -out cert_0.cer
$ openssl req -newkey rsa:2048 -nodes -keyout cert_1.key -x509 -days 365 -out cert_1.cer
$ openssl req -newkey rsa:2048 -nodes -keyout cert_2.key -x509 -days 365 -out cert_2.cer

$ az keyvault security-domain download --hsm-name $HSMNAME --sd-wrapping-keys ./cert_0.cer ./cert_1.cer ./cert_2.cer --sd-quorum 2 --security-domain-file $HSMNAME-SD.json

จากนั้น อัปเดตไฟล์ gokeyless YAML ก่อนเพิ่มชื่อโฮสต์ของคีย์เซิร์ฟเวอร์ ชื่อโฮสต์นี้ควรมีบันทึก DNS ที่ชี้ไปที่ VM ของคุณ, zoneID และคีย์ Origin CA API ดู zoneID และคีย์ Origin CA API ได้จากแดชบอร์ด Cloudflare นอกจากนั้น ให้ระบุ URI ที่จะชี้ไปยังไดเร็กทอรีย์ของคีย์ส่วนตัวของคุณภายใต้ private_key_stores

$ az keyvault key import --KeylessHSM

กลับไปที่พอร์ทัล Azure และเปิดพอร์ต TCP ที่จำเป็นสำหรับ Azure VM ไปที่ VM → ระบบเครือข่าย → เพิ่มกฎพอร์ตขาเข้า คุณต้องอนุญาตให้มีการรับส่งข้อมูลบนพอร์ตต้นทางใด ๆ และระบุพอร์ต 2407 เป็นพอร์ตปลายทาง

บันทึกการเปลี่ยนแปลง จากนั้นไปที่แดชบอร์ด Cloudflare เพื่ออัปโหลดใบรับรอง SSL ของคุณ คุณควรเห็น “Upload Keyless SSL Certificate” ในส่วน Edge Certificates ของแท็บ SSL/TLS ป้อนข้อมูลลงในช่องข้อมูลที่มีป้ายกำกับเซิร์ฟเวอร์คีย์ ชื่อโฮสต์ในไฟล์ YAML, พอร์ตเซิร์ฟเวอร์คีย์ โดย 2407 เป็นพอร์ตเริ่มต้น และวางใบรับรอง SSL

$ apt-get update
$ echo 'deb http://pkg.cloudflare.com/ Xenial main' |
sudo tee /etc/apt/sources.list.d/cloudflare-main.list
$ curl -C - https://pkg.cloudflare.com/pubkey.gpg | sudo apt-key
$ apt-get update
$ apt-get install gokeyless

หลังจากนั้น คุณพร้อมที่จะทดสอบแล้ว! เรียกใช้ curl -v https://zone.com และตรวจสอบว่า TLS handshake เสร็จเรียบร้อยแล้ว

$ vim /etc/keyless/gokeyless.yaml
$ service gokeyless start

Microsoft Azure Dedicated HSM

นอกเหนือจากข้อเสนอ Managed HSM ซึ่งขณะนี้อยู่ในรุ่นตัวอย่างสำหรับสาธารณะแล้ว ลูกค้า Azure ยังสามารถกำหนดค่า Edge ของ Cloudflare เพื่อใช้คีย์ที่จัดเก็บไว้ในข้อเสนอ Dedicated HSM ของ Microsoft โดยอิงกับ SafeNet Luna Network HSM 7 รุ่น A790 ซีรีส์

Azure Dedicated HSM ได้รับการตรวจสอบกับทั้ง FIPS 140-2 ระดับ 3 และ eIDAS Common Criteria EAL4+ แล้ว ซึ่งหลังจากทำตามคำแนะนำในการปรับใช้ HSM ลูกค้าควรปฏิบัติตามคำแนะนำ Keyless SSL เฉพาะของ Azure ที่นี่

Amazon Web Services (AWS) Cloud HSM

AWS CloudHSM ยังให้ HSM ที่ผ่านการตรวจสอบความถูกต้อง FIPS 140-2 ระดับ 3 เพื่อจัดเก็บคีย์ส่วนตัวของคุณ

AWS Terraform Provider อย่างเป็นทางการตอนนี้รองรับ aws_cloudhsm_v2_cluster ซึ่งเป็นเวอร์ชันที่ Cloudflare รองรับ หลังจากเตรียมใช้งานคลัสเตอร์ AWS CloudHSM ลูกค้าควรปฏิบัติตามคำแนะนำ Keyless SSL เฉพาะของ AWS ที่นี่

Google Cloud HSM

Google Cloud HSM ใช้ Cloud KMS ของ GCP เป็นส่วนหน้า และอนุญาตให้โฮสต์คีย์ใน HSM ที่ผ่านการตรวจสอบความถูกต้อง FIPS 140-2 ระดับ 3 นอกจากนี้ Google ยังเสนอความสามารถในการโฮสต์ HSM ของคุณเองในพื้นที่ที่ Google จัดเตรียมไว้ให้ ขอแนะนำให้คุณติดต่อตัวแทนบัญชี GCP เพื่อขอข้อมูลเพิ่มเติมเกี่ยวกับตัวเลือกนี้

เมื่อคีย์ริงและคีย์ถูกสร้างขึ้นภายใน HSM แล้ว ลูกค้าควรปฏิบัติตามคำแนะนำ Keyless SSL เฉพาะของ Google Cloud ที่นี่ ดูรายละเอียดเพิ่มเติมเกี่ยวกับการใช้คีย์แบบอสมมาตรร่วมกับ GCP KMS ได้จากที่นี่

IBM Cloud

IBM Cloud HSM 7.0 ให้ความสามารถ HSM ที่ตรวจสอบความถูกต้อง FIPS 140-2 ระดับ 3 ข้อเสนอนี้อิงตามซีรีส์ SafeNet Luna A750

หลังจากเตรียมการใช้ HSM แล้ว ลูกค้าควรอ้างอิงถึงคำแนะนำ Keyless SSL เฉพาะของ IBM ที่นี่

รับความช่วยเหลือและร่วมแสดงความคิดเห็น

HSM มีความสามารถในการป้องกันคีย์ที่แข็งแกร่ง แต่การตั้งค่าและปรับใช้งานอาจซับซ้อน หากคุณต้องการความช่วยเหลือเมื่อปรับใช้งาน HSM บนผู้ให้บริการระบบคลาวด์ของคุณ เราขอแนะนำให้เริ่มต้นด้วยช่องทางการสนับสนุนของผู้บริการ

อย่างไรก็ตาม หากคุณต้องการความช่วยเหลือเมื่อกำหนดค่า HSM ให้ทำงานกับ Edge ของ Cloudfare หรือต้องการแสดงความคิดเห็นเกี่ยวกับกระบวนการ คุณควรติดต่อทีมวิศวกรรมโซลูชันของคุณโดยตรง ซึ่งจะแนะนำให้คุณติดต่อกับผู้เชี่ยวชาญ Keyless SSL ของ Cloudflare อีกทอดหนึ่ง

เราปกป้องเครือข่ายของทั้งองค์กร โดยช่วยลูกค้าสร้างแอปพลิเคชันรองรับผู้ใช้อินเทอร์เน็ตทั่วโลกได้อย่างมีประสิทธิภาพ เพิ่มความรวดเร็วของการใช้เว็บไซต์หรือแอปพลิเคชันอินเทอร์เน็ต จัดการการโจมตีแบบ–DDoS ป้องปรามบรรดาแฮกเกอร์ และช่วยเหลือคุณตลอดเส้นทางสู่ Zero Trust

เข้าไปที่ 1.1.1.1 จากอุปกรณ์ใดก็ได้เพื่อลองใช้แอปฟรีของเราที่จะช่วยให้อินเทอร์เน็ตของคุณเร็วขึ้นและปลอดภัยขึ้น

หากต้องการศึกษาข้อมูลเพิ่มเติมเกี่ยวกับภารกิจของเราเพื่อปรับปรุงการใช้งานอินเทอร์เน็ต เริ่มได้จากที่นี่ หากคุณกำลังมองหางานในสายงานใหม่ ลองดูตำแหน่งที่เราเปิดรับ
Security Week (TH)Keyless SSL (TH)Product News (TH)

ติดตามบน X

Patrick R. Donahue|@prdonahue
Dina Kozlov|@dinasaur_404
Cloudflare|@cloudflare

โพสต์ที่เกี่ยวข้อง

29 เมษายน 2567 เวลา 13:00

Resumo das interrupções da internet no primeiro trimestre de 2024

O primeiro trimestre de 2024 começou com algumas interrupções na internet. Talvez o mais interessante seja que os problemas de RPKI, DNS e DNSSEC estavam entre os problemas técnicos que interromperam a conectividade dos assinantes em vários provedores de rede...

29 เมษายน 2567 เวลา 13:00

2024년 1분기 인터넷 중단 사고 요약

2024년 1분기는 인터넷 중단 사고가 여러 차례 발생하면서 시작되었습니다. 가장 흥미로웠던 사실은 RPKI, DNS, DNSSEC 문제가 여러 네트워크 공급자의 가입자 연결을 방해한 기술적 문제 중 하나였다는 것입니다...