เกี่ยวกับ TLS/SSL

คุณกําลังดูเอกสาร Apigee Edge
ดูเอกสารประกอบเกี่ยวกับ Apigee X

Transport Layer Security (TLS) ซึ่งก่อนหน้านี้คือ Secure Sockets Layer (SSL) เป็นเทคโนโลยีความปลอดภัยมาตรฐานสําหรับการสร้างลิงก์ที่เข้ารหัสระหว่างเว็บเซิร์ฟเวอร์และไคลเอ็นต์เว็บ เช่น เบราว์เซอร์หรือแอป ลิงก์ที่เข้ารหัสจะดูแลให้ข้อมูลทั้งหมดที่ส่งระหว่างเซิร์ฟเวอร์และไคลเอ็นต์ยังคงเป็นส่วนตัว หากต้องการใช้ TLS ไคลเอ็นต์จะส่งคําขอที่ปลอดภัยไปยังเซิร์ฟเวอร์โดยใช้โปรโตคอล HTTPS ที่เข้ารหัสแทนโปรโตคอล HTTP ที่ไม่เข้ารหัส

Edge รองรับ TLS แบบทางเดียวและ TLS แบบ 2 ทิศทางทั้งในระบบคลาวด์และการทําให้ใช้งานได้ภายในองค์กร (สําหรับ TLS เวอร์ชันที่รองรับ โปรดดูซอฟต์แวร์ที่รองรับและเวอร์ชันที่รองรับ) TLS แบบทางเดียวช่วยให้ไคลเอ็นต์ TLS ยืนยันตัวตนของเซิร์ฟเวอร์ TLS เช่น แอปที่เรียกใช้ในโทรศัพท์ Android (ไคลเอ็นต์) จะยืนยันตัวตนของ Edge API (เซิร์ฟเวอร์) ได้

นอกจากนี้ Apigee ยังรองรับการตรวจสอบสิทธิ์อย่างเข้มงวดโดยใช้ TLS แบบ 2 ทางหรือไคลเอ็นต์ โดยปกติแล้วคุณจะใช้ TLS แบบ 2 ทางเพื่อยกระดับความปลอดภัยจากต้นทางถึงปลายทางและปกป้องข้อมูลของคุณจากการโจมตีไคลเอ็นต์ เช่น การปลอมแปลงไคลเอ็นต์หรือการโจมตีแบบแทรกกลางของบุคคลภายนอก ใน TLS แบบ 2 ทาง ไคลเอ็นต์จะยืนยันตัวตนของเซิร์ฟเวอร์ ตามด้วยเซิร์ฟเวอร์ที่ยืนยันตัวตนของไคลเอ็นต์

คําศัพท์เกี่ยวกับ TLS

คุณควรทําความคุ้นเคยกับคําและแนวคิดที่สําคัญต่อไปนี้ก่อนกําหนดค่า TLS:

คำศัพท์	คำจำกัดความ
แคนาดา	ผู้ออกใบรับรอง หน่วยงานที่เชื่อถือได้ เช่น Symantec หรือ VeriSign ใช้เพื่อออกใบรับรองและทําการตรวจสอบความน่าเชื่อถือของใบรับรอง ใบรับรองประเภทหนึ่งซึ่งเรียกว่าใบรับรองที่ลงชื่อด้วยตนเองไม่ต้องใช้ CA
ชุดใบรับรอง	บ่อยครั้งที่คุณจะไม่มีใบรับรองที่ลงชื่อโดยคีย์ส่วนตัวของ CA แต่จะมีใบรับรองของคุณพร้อมกับใบรับรองกลางอย่างน้อย 1 ใบที่รวมกันเป็นเชน โดยทั่วไปใบรับรองกลางรายการสุดท้ายจะลงนามด้วยคีย์ส่วนตัวของ CA
CSR	คําขอลงชื่อในใบรับรอง CSR คือไฟล์ที่สร้างขึ้นบนเซิร์ฟเวอร์ TLS โดยอิงตามคีย์ส่วนตัว CSR มีคีย์สาธารณะและข้อมูลอื่นๆ เช่น ชื่อ ตําแหน่ง และชื่อโดเมนขององค์กร CA จะลงชื่อใน CSR เพื่อสร้างใบรับรอง TLS โดยปกติแล้ว คุณจะสร้าง CSR เมื่อมีใบรับรองที่หมดอายุและต้องการต่ออายุ
เดอร์	กฎการเข้ารหัสที่โดดเด่น รูปแบบ DER คือไฟล์ไบนารีของใบรับรอง ไม่ใช่รูปแบบ ASCII PEM บางครั้งอาจมีนามสกุลไฟล์เป็น .der แต่มักมีนามสกุลไฟล์เป็น .cer วิธีเดียวที่จะแยกความแตกต่างระหว่างไฟล์ DER .cer กับไฟล์ PEM .cer คือการเปิดไฟล์ดังกล่าวในตัวแก้ไขข้อความ แล้วมองหาคําสั่ง BEGIN และ END ใบรับรองและคีย์ส่วนตัวทุกประเภทเข้ารหัสได้ในรูปแบบ DER โดยปกติ DER จะใช้กับแพลตฟอร์ม Java
ชื่อแทนคีย์	ชื่อแทนคีย์จะระบุรายการคีย์สโตร์ที่ไม่ซ้ํากัน (ใบรับรอง TLS และคีย์ส่วนตัวที่เกี่ยวข้อง) ในคีย์สโตร์ ใน Apigee Edge KeyAlias จะเรียกว่า alias เมื่อคุณอัปโหลดใบรับรอง/คีย์ไปยังคีย์สโตร์โดยใช้ UI หรือ API
คีย์สโตร์	คีย์สโตร์คือที่เก็บที่มีใบรับรอง TLS อย่างน้อย 1 รายการและคีย์ส่วนตัวที่เกี่ยวข้องซึ่งใช้ในการระบุเอนทิตีระหว่างแฮนด์เชค TLS ระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ ในการเชื่อมต่อแบบไม่ตรง เราเตอร์จะทําหน้าที่เป็นเซิร์ฟเวอร์และจัดเก็บใบรับรองไว้ในคีย์สโตร์ใน Apigee Edge ในการเชื่อมต่อ southbound ตัวประมวลผลข้อความจะทําหน้าที่เป็นไคลเอ็นต์และเซิร์ฟเวอร์แบ็กเอนด์ทําหน้าที่เป็นเซิร์ฟเวอร์ ระบบจะจัดเก็บใบรับรองไคลเอ็นต์และคีย์ส่วนตัวไว้ในคีย์สโตร์ใน Apigee Edge
P7B	โดยทั่วไปแล้ว รูปแบบ PKCS #7 หรือ P7B จะจัดเก็บในรูปแบบ Base64 ASCII และมีนามสกุลไฟล์เป็น .p7b หรือ .p7c ใบรับรอง P7B มีคําสั่ง -----BEGIN PKCS7----- และ -----END PKCS7----- ไฟล์ P7B มีเฉพาะใบรับรองและใบรับรองเชนเท่านั้น ไม่ใช่คีย์ส่วนตัว
PEM	รูปแบบ Privacy Enhanced Mail (PEM) คือรูปแบบ ASCII แบบข้อความที่เป็นการเข้ารหัส Base64 ของรูปแบบ Distinguished Encoding Rules (DER) ของไบนารี ใบรับรอง PEM จะเปิดได้ในเครื่องมือแก้ไขข้อความใดก็ได้ และเนื้อหาของใบรับรองจริงจะคั่นด้วยคําสั่ง -----BEGIN CERTIFICATE----- และ -----END CERTIFICATE----- ซึ่งเป็นไปตามรูปแบบ X.509 ในการจัดเก็บใบรับรอง เชนใบรับรอง หรือคีย์ส่วนตัว หากใบรับรองหรือคีย์ส่วนตัวไม่ได้กําหนดโดยไฟล์ PEM คุณจะแปลงไฟล์นั้นเป็นไฟล์ PEM ได้โดยใช้ยูทิลิตีต่างๆ เช่น OpenSSL
PKCS #12/PFX	รูปแบบ PKCS #12 หรือ PFX คือรูปแบบไบนารีสําหรับจัดเก็บใบรับรองของเซิร์ฟเวอร์ ใบรับรองกลาง และคีย์ส่วนตัวในไฟล์ที่เข้ารหัสได้ไฟล์เดียว โดยปกติแล้วไฟล์ PFX จะมีนามสกุลอย่างเช่น .pfx และ .p12 แต่โดยทั่วไปจะใช้ไฟล์ PFX ในเครื่อง Windows เพื่อนําเข้าและส่งออกใบรับรองและคีย์ส่วนตัว
คีย์ส่วนตัว	ใช้บนเซิร์ฟเวอร์ TLS เพื่อถอดรหัสข้อมูล มีเพียงเซิร์ฟเวอร์ TLS เท่านั้นที่มีคีย์ส่วนตัว ซึ่งไม่มีการแชร์กับไคลเอ็นต์ TLS
คีย์สาธารณะ	ใช้เพื่อเข้ารหัสข้อมูลที่ส่งจากไคลเอ็นต์ TLS ไปยังเซิร์ฟเวอร์ TLS คีย์สาธารณะรวมอยู่ในใบรับรอง ไคลเอ็นต์ TLS ทั้งหมดจะมีสําเนาของคีย์สาธารณะของเซิร์ฟเวอร์
ข้อมูลอ้างอิง	การอ้างอิงระบุระดับทางอ้อมสําหรับคีย์สโตร์ ดังนั้น การเปลี่ยนแปลงคีย์สโตร์ไม่จําเป็นต้องมีการอัปเดตโฮสต์เสมือนตราบใดที่มีการอ้างอิงและชื่อแทนคีย์เดียวกัน การดําเนินการนี้ช่วยให้คุณให้บริการการเปลี่ยนแปลงเหล่านี้ด้วยตนเองและลดทรัพยากร Dependency กับทีมสนับสนุนของ Apigee ได้
ใบรับรอง Self-signed	ใบรับรองที่ไม่มีการลงชื่อโดย CA ที่เชื่อถือได้ ผู้ออกบัตรและเรื่องเหมือนกัน ลงนามด้วยคีย์ส่วนตัวที่ตรงกับคีย์สาธารณะที่มีอยู่
SNI	การแสดงชื่อเซิร์ฟเวอร์ อนุญาตเป้าหมาย HTTPS หลายรายการให้แสดงจากที่อยู่และพอร์ต IP เดียวกัน โดยไม่ต้องมีเป้าหมายเหล่านั้นใช้ใบรับรองเดียวกัน
ใบรับรอง TLS	ไฟล์ดิจิทัลที่ระบุเอนทิตีในธุรกรรม TLS ใบรับรองหรือ cert จะใช้เพื่อระบุเซิร์ฟเวอร์ TLS และไคลเอ็นต์ TLS ได้โดยขึ้นอยู่กับการกําหนดค่า TLS
Truststore	มีใบรับรองที่เชื่อถือได้ในไคลเอ็นต์ TLS ที่ใช้ตรวจสอบใบรับรองของเซิร์ฟเวอร์ TLS ที่แสดงในไคลเอ็นต์ โดยทั่วไป ใบรับรองเหล่านี้เป็นใบรับรองที่ลงชื่อด้วยตนเองหรือใบรับรองที่ไม่ได้ลงนามโดย CA ที่เชื่อถือได้ ในการเชื่อมต่อแบบเหนือ ระบบจะจัดเก็บใบรับรองแอปพลิเคชันของไคลเอ็นต์ไว้ใน Truststore ใน Apigee Edge ซึ่งจะจําเป็นต่อเมื่อคุณกําหนดค่า TLS แบบ 2 ทางระหว่างไคลเอ็นต์กับ Apigee เท่านั้น ในการเชื่อมต่อ southbound ใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์จะเก็บไว้ใน Truststore ใน Apigee Edge จําเป็นต้องระบุหากต้องการยืนยันใบรับรองแบ็กเอนด์ใน Apigee Edge ในการสื่อสาร TLS แบบทางเดียวหรือ 2 ทางระหว่าง Apigee Edge และเซิร์ฟเวอร์แบ็กเอนด์ Apigee Edge ไม่มีออบเจ็กต์ Truststore แยกต่างหาก ดังนั้น ระบบจะสร้าง Truststore เป็นออบเจ็กต์คีย์สโตร์ แต่อ้างอิงเป็น Truststore ทุกที่ที่ใช้ (เช่น ในโฮสต์เสมือน, ปลายทางปลายทาง, เซิร์ฟเวอร์เป้าหมาย ฯลฯ)
โฮสต์เสมือน	โฮสต์เสมือน แสดงปลายทางของ Apigee API สําหรับแอปพลิเคชันไคลเอ็นต์ ซึ่งเป็นเอนทิตีที่ช่วยในโฮสต์ชื่อโดเมนหลายรายการ (โดยการจัดการแต่ละชื่อแยกกัน) ในเซิร์ฟเวอร์เดียว (หรือพูลของเซิร์ฟเวอร์) ซึ่งจะช่วยให้เซิร์ฟเวอร์ 1 เครื่องแชร์ทรัพยากรได้ เช่น หน่วยความจําและรอบโปรเซสเซอร์ โดยไม่ต้องให้บริการทั้งหมดในการใช้ชื่อโฮสต์เดียวกัน โฮสต์เสมือนสามารถให้บริการการจราจรของข้อมูล HTTP หรือ HTTPS (เปิดใช้งาน SSL) คุณสามารถกําหนดค่าโฮสต์เสมือนที่เปิดใช้ SSL ในโหมด TLS แบบทางเดียวหรือสองทาง โดยกําหนดค่าด้วยสิ่งต่อไปนี้ ชื่อแทนอย่างน้อย 1 รายการ (ชื่อ DNS ปลายทาง API) พอร์ต คีย์สโตร์ ชื่อแทนคีย์เพื่อระบุใบรับรองเซิร์ฟเวอร์ที่ไม่ซ้ํากันในคีย์สโตร์ เลือก Truststore (ใน TLS แบบ 2 ทางที่เปิดใช้การตรวจสอบสิทธิ์ไคลเอ็นต์)

TLS/SSL ทางเดียว

รูปต่อไปนี้แสดงแฮนด์เชค TLS/SSL สําหรับการตรวจสอบสิทธิ์แบบทางเดียวระหว่างไคลเอ็นต์ TLS กับเซิร์ฟเวอร์ TLS

ในการกําหนดค่า TLS แบบทางเดียว แฮนด์เชคจะเป็นดังนี้

• ไคลเอ็นต์จะส่งคําขอเซสชันไปยังเซิร์ฟเวอร์
• เซิร์ฟเวอร์จะตอบสนองด้วยใบรับรองซึ่งมีคีย์สาธารณะ ใบรับรองนี้มาจากคีย์สโตร์ของเซิร์ฟเวอร์ ซึ่งประกอบด้วยคีย์ส่วนตัวของเซิร์ฟเวอร์ด้วย ระบบจะไม่ส่งคีย์ส่วนตัวไปยังไคลเอ็นต์
• สําหรับใบรับรองที่ลงชื่อ ไคลเอ็นต์จะส่งคําขอไปยังผู้ออกใบรับรอง (CA) เพื่อตรวจสอบสิทธิ์ใบรับรอง
• ไคลเอ็นต์และเซิร์ฟเวอร์แลกเปลี่ยนข้อความอีกหลายข้อความเพื่อตรวจสอบคีย์
• ไคลเอ็นต์จะเริ่มโอนข้อมูล TLS กับเซิร์ฟเวอร์

รูปต่อไปนี้แสดงแฮนด์เชค TLS/SSL โดยใช้ Truststore ที่ไม่บังคับในไคลเอ็นต์

หากเซิร์ฟเวอร์ TLS ใช้ใบรับรองแบบ Self-signed หรือใบรับรองที่ไม่ได้ลงนามโดย CA ที่เชื่อถือได้ คุณจะต้องสร้าง Truststore บนไคลเอ็นต์ ไคลเอ็นต์จะเติมข้อมูลในที่เก็บเซิร์ฟเวอร์และใบรับรองสาธารณะที่ไคลเอ็นต์เชื่อถือ เมื่อไคลเอ็นต์ได้รับใบรับรอง ใบรับรองขาเข้าจะถูกตรวจสอบกับใบรับรองใน Truststore ของใบรับรอง

ใน TLS ทางเดียว Edge อาจเป็นเซิร์ฟเวอร์หรือไคลเอ็นต์ได้ดังนี้

• ใช้เป็นเซิร์ฟเวอร์ TLS

  Edge คือเซิร์ฟเวอร์ที่โฮสต์ปลายทาง TLS โดยที่ปลายทาง TLS สอดคล้องกับพร็อกซี API ที่ใช้งานได้กับโฮสต์เสมือน ไคลเอ็นต์คือแอปที่พยายามเข้าถึงพร็อกซี API ในสถานการณ์นี้ Edge มีคีย์สโตร์ที่มีใบรับรองและคีย์ส่วนตัว

• บันทึกเป็นไคลเอ็นต์ TLS

  Edge ทําหน้าที่เป็นไคลเอ็นต์ที่เข้าถึงบริการแบ็กเอนด์ ในกรณีนี้ บริการแบ็กเอนด์จะสอดคล้องกับเซิร์ฟเวอร์ที่โฮสต์ปลายทาง TLS ดังนั้น เซิร์ฟเวอร์แบ็กเอนด์จะมีคีย์สโตร์ที่มีใบรับรองและคีย์ส่วนตัว

TLS แบบสองทาง

รูปต่อไปนี้แสดงแฮนด์เชค TLS/SSL สําหรับการตรวจสอบสิทธิ์ TLS แบบ 2 ทางระหว่างไคลเอ็นต์และเซิร์ฟเวอร์

ใน TLS แบบ 2 ทาง แฮนด์เชคจะเป็นดังนี้

• ทั้งไคลเอ็นต์และเซิร์ฟเวอร์มีคีย์สโตร์ของตัวเอง คีย์สโตร์ของไคลเอ็นต์มีใบรับรองและคีย์ส่วนตัว ส่วนคีย์สโตร์ของเซิร์ฟเวอร์มีใบรับรองและคีย์ส่วนตัว
• เซิร์ฟเวอร์ TLS จะแสดงใบรับรองแก่ไคลเอ็นต์ TLS เพื่อตรวจสอบสิทธิ์ตัวเอง จากนั้นไคลเอ็นต์จะยืนยันตัวตนของเซิร์ฟเวอร์ก่อนส่งใบรับรองไปยังเซิร์ฟเวอร์
• ไคลเอ็นต์ TLS จะแสดงใบรับรองของตนไปยังเซิร์ฟเวอร์ TLS เพื่อตรวจสอบสิทธิ์ตัวเองกับเซิร์ฟเวอร์

รูปต่อไปนี้แสดงแฮนด์เชค TLS โดยใช้ Truststore ที่ไม่บังคับ

ในสถานการณ์นี้ แฮนด์เชคจะเป็นดังนี้

• หากเซิร์ฟเวอร์ TLS ใช้ใบรับรองแบบ Self-signed หรือใบรับรองที่ไม่มีการลงชื่อโดย CA ที่เชื่อถือได้ คุณจะต้องสร้าง Truststore บนไคลเอ็นต์ client มีสําเนาใบรับรอง server ใน Truststore ในระหว่างแฮนด์เชค TLS นั้น client จะเปรียบเทียบใบรับรองใน Truststore กับใบรับรองที่ส่งจาก server เพื่อยืนยันตัวตนของ server
• หากไคลเอ็นต์ TLS ใช้ใบรับรองแบบ Self-signed หรือใบรับรองที่ไม่มีการลงชื่อโดย CA ที่เชื่อถือได้ คุณจะต้องสร้าง Truststore บนเซิร์ฟเวอร์ เซิร์ฟเวอร์จะมีสําเนาของใบรับรองไคลเอ็นต์ใน Truststore ในระหว่างแฮนด์เชค TLS นั้น เซิร์ฟเวอร์จะเปรียบเทียบใบรับรองในที่เก็บที่เชื่อถือได้กับใบรับรองที่ส่งจากไคลเอ็นต์เพื่อยืนยันตัวตนของไคลเอ็นต์

ไคลเอ็นต์หรือเซิร์ฟเวอร์หรือทั้งสองอย่างสามารถใช้ Truststore

ใน TLS แบบ 2 ทาง Edge อาจเป็นเซิร์ฟเวอร์หรือไคลเอ็นต์ได้ดังนี้

• บังคับใช้ในฐานะเซิร์ฟเวอร์

  Edge คือเซิร์ฟเวอร์ที่โฮสต์ปลายทาง TLS โดยที่ปลายทาง TLS สอดคล้องกับพร็อกซี API ไคลเอ็นต์คือแอปที่พยายามเข้าถึงพร็อกซี API ในสถานการณ์นี้ Edge มีคีย์สโตร์ที่มีใบรับรองและคีย์ส่วนตัว และต้องใช้ Truststore ที่มีใบรับรองและห่วงโซ่ของไคลเอ็นต์

• ยอมรับในฐานะลูกค้า

  Edge ทําหน้าที่เป็นไคลเอ็นต์ที่เข้าถึงบริการแบ็กเอนด์ ในกรณีนี้ บริการแบ็กเอนด์จะสอดคล้องกับเซิร์ฟเวอร์ที่โฮสต์ปลายทาง TLS เซิร์ฟเวอร์แบ็กเอนด์จึงมีคีย์สโตร์ที่มีใบรับรองและคีย์ส่วนตัว

  นอกจากนี้ Edge ยังต้องกําหนดคีย์สโตร์ที่มีใบรับรองที่จําเป็นต่อการตรวจสอบตนเองกับบริการแบ็กเอนด์ หรือจะเลือก Truststore ที่มีใบรับรองจากเซิร์ฟเวอร์แบ็กเอนด์ก็ได้ หากเซิร์ฟเวอร์ใช้ใบรับรอง Self-signed หรือใบรับรองที่ไม่ได้ลงนามโดย CA ที่เชื่อถือได้

สิ่งสําคัญที่ควรจําก็คือ Edge มีความยืดหยุ่นมากพอที่จะรองรับ TLS แบบ 2 ทางได้ ไม่ว่าคุณจะเลือกกําหนดค่าแบบใดก็ตาม

การสนับสนุน SNI

Edge รองรับการใช้ Server Name Indication (SNI) จากพร็อกซี API ไปยัง Edge โดย Edge จะทําหน้าที่เป็นเซิร์ฟเวอร์ TLS และจาก Edge ไปยังปลายทางเป้าหมาย โดย Edge จะทําหน้าที่เป็นไคลเอ็นต์ TLS ทั้งในการติดตั้งในระบบคลาวด์และ Private Cloud

SNI ซึ่งเป็นส่วนขยายของ TLS/SSL สามารถแสดงเป้าหมาย HTTPS หลายรายการออกจากที่อยู่ IP และพอร์ตเดียวกัน โดยไม่ต้องใช้เป้าหมายเหล่านั้นเพื่อใช้ใบรับรองเดียวกัน

ดูข้อมูลเกี่ยวกับการเปิดใช้ SNI สําหรับการติดตั้งภายในองค์กรได้ที่การใช้ SNI ร่วมกับ Edge

ไปทางเหนือและใต้

ใน Apigee ส่วนทิศเหนือหมายถึงจุดสิ้นสุดของ API ที่แอปพลิเคชันไคลเอ็นต์ใช้เพื่อเรียกใช้ API พร็อกซี โดยทั่วไป เราเตอร์คือจุดแรกเข้าใน Apigee Edge และจะจัดการกับคําขอที่เข้ามาใหม่ไปยัง Apigee Edge ดังนั้น ใน Apigee ปลายทางที่ใช้สําหรับการสื่อสารระหว่างแอปพลิเคชันไคลเอ็นต์และ Apigee Edge (Router) จะเรียกว่า northbound

ใน Apigee ส่วน "divbounde" จะหมายถึงปลายทางปลายทางที่ Apigee ใช้ในการสื่อสารกับเซิร์ฟเวอร์แบ็กเอนด์ ดังนั้น ใน Apigee ปลายทางที่ใช้สื่อสารระหว่าง Apigee Edge (ตัวประมวลผลข้อความ) และเซิร์ฟเวอร์แบ็กเอนด์จะเรียกว่า southbound Message Processor เป็นคอมโพเนนต์ของ Apigee Edge ซึ่งพร็อกซี API จะส่งคําขอไปยังเซิร์ฟเวอร์เป้าหมายแบ็กเอนด์

รูปต่อไปนี้แสดงการเชื่อมต่อแบบเหนือและใต้สําหรับ Apigee Edge