คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ
Apigee X info
Transport Layer Security (TLS) ซึ่งมี Secure Sockets Layer (SSL) เป็นรุ่นก่อนหน้าเป็นเทคโนโลยีความปลอดภัยมาตรฐาน
สำหรับการสร้างลิงก์ที่เข้ารหัสระหว่างเว็บเซิร์ฟเวอร์กับเว็บไคลเอ็นต์ เช่น เบราว์เซอร์หรือ
แอป ลิงก์ที่เข้ารหัสช่วยให้มั่นใจได้ว่าข้อมูลทั้งหมดที่ส่งผ่านระหว่างเซิร์ฟเวอร์กับไคลเอ็นต์จะยังคงเป็น
ส่วนตัว หากต้องการใช้ TLS ไคลเอ็นต์จะส่งคำขอที่ปลอดภัยไปยังเซิร์ฟเวอร์โดยใช้โปรโตคอล HTTPS ที่เข้ารหัสแทนโปรโตคอล HTTP ที่ไม่ได้เข้ารหัส
Edge รองรับ TLS ทางเดียวและ TLS สองทางทั้งในการติดตั้งใช้งานในระบบคลาวด์และในองค์กร (สำหรับ TLS เวอร์ชันที่รองรับ โปรดดู ซอฟต์แวร์และเวอร์ชันที่รองรับ) TLS ทางเดียวช่วยให้ไคลเอ็นต์ TLS ยืนยันตัวตนของเซิร์ฟเวอร์ TLS ได้ เช่น แอปที่ทำงานบนโทรศัพท์ Android (ไคลเอ็นต์) สามารถยืนยันตัวตนของ Edge APIs (เซิร์ฟเวอร์) ได้
นอกจากนี้ Apigee ยังรองรับการตรวจสอบสิทธิ์ในรูปแบบที่เข้มงวดมากขึ้นโดยใช้ TLS แบบ 2 ทางหรือ TLS ของไคลเอ็นต์ โดยปกติแล้ว คุณจะใช้ TLS แบบ 2 ทางเพื่อเพิ่มการรักษาความปลอดภัยตั้งแต่ต้นจนจบและปกป้องข้อมูลจากการโจมตีของไคลเอ็นต์ เช่น การปลอมแปลงไคลเอ็นต์หรือการโจมตีแบบ Man-in-the-Middle ใน TLS แบบ 2 ทาง ไคลเอ็นต์จะยืนยัน ตัวตนของเซิร์ฟเวอร์ จากนั้นเซิร์ฟเวอร์จะยืนยันตัวตนของไคลเอ็นต์
คำศัพท์ TLS
คุณควรทำความคุ้นเคยกับคำศัพท์และแนวคิดสำคัญต่อไปนี้ก่อนกำหนดค่า TLS
|
คำศัพท์ |
คำจำกัดความ |
|---|---|
|
CA |
ผู้ออกใบรับรอง หน่วยงานที่เชื่อถือได้ เช่น Symantec หรือ VeriSign ซึ่งใช้ในการออกใบรับรองและตรวจสอบ ความถูกต้องของใบรับรอง ใบรับรองประเภทหนึ่งที่เรียกว่าใบรับรองที่เจ้าตัวเซ็นเองไม่จำเป็นต้องมี CA |
|
ชุดใบรับรอง |
บ่อยครั้งที่คุณจะไม่มีใบรับรองที่ลงนามโดยคีย์ส่วนตัวรูทของ CA แต่คุณมีใบรับรองพร้อมกับใบรับรองระดับกลางอย่างน้อย 1 รายการที่สร้างเป็นห่วงโซ่ โดยปกติแล้ว ใบรับรองระดับกลางสุดท้ายในห่วงโซ่จะได้รับการลงนามด้วยคีย์ส่วนตัวรูทของ CA |
|
CSR |
คำขอลงนามใบรับรอง CSR คือไฟล์ที่สร้างขึ้นในเซิร์ฟเวอร์ TLS โดยอิงตามคีย์ส่วนตัว CSR มีคีย์สาธารณะและข้อมูลอื่นๆ เช่น ชื่อ สถานที่ตั้ง และชื่อโดเมนขององค์กร CA จะลงนามใน CSR เพื่อสร้างใบรับรอง TLS โดยปกติแล้ว คุณจะสร้าง CSR เมื่อมีใบรับรองที่หมดอายุและต้องการต่ออายุ |
| DER |
กฎการเข้ารหัสที่แตกต่าง รูปแบบ DER เป็นรูปแบบไบนารีของใบรับรองแทน
รูปแบบ PEM ของ ASCII บางครั้งจะมีนามสกุลไฟล์เป็น .der แต่ส่วนใหญ่จะมีนามสกุลไฟล์เป็น .cer วิธีเดียวที่จะบอกความแตกต่างระหว่างไฟล์ .cer ของ DER กับ
ไฟล์ .cer ของ PEM คือการเปิดไฟล์ในเครื่องมือแก้ไขข้อความและค้นหาสถานะ |
| นามแฝงของคีย์ |
ชื่อแทนคีย์จะระบุรายการคีย์สโตร์ (ใบรับรอง TLS และคีย์ส่วนตัวที่เกี่ยวข้อง) ในคีย์สโตร์โดยไม่ซ้ำกัน
ใน Apigee Edge |
|
ที่เก็บคีย์ |
ที่เก็บคีย์คือที่เก็บที่มีใบรับรอง TLS อย่างน้อย 1 รายการและ คีย์ส่วนตัวที่เกี่ยวข้องซึ่งใช้เพื่อระบุเอนทิตีระหว่างแฮนด์เชค TLS ระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ ในการเชื่อมต่อขาขึ้น เราเตอร์จะทำหน้าที่เป็น เซิร์ฟเวอร์และใบรับรองจะจัดเก็บไว้ในที่เก็บคีย์ใน Apigee Edge ในการเชื่อมต่อขาออก Message Processor จะทำหน้าที่เป็นไคลเอ็นต์ และเซิร์ฟเวอร์แบ็กเอนด์จะทำหน้าที่เป็นเซิร์ฟเวอร์ ใบรับรองไคลเอ็นต์ และคีย์ส่วนตัวจะจัดเก็บไว้ในคีย์สโตร์ใน Apigee Edge |
| P7B |
โดยปกติแล้วรูปแบบ PKCS #7 หรือ P7B จะจัดเก็บในรูปแบบ Base64 ASCII และมีนามสกุลไฟล์เป็น .p7b หรือ .p7c ใบรับรอง P7B มีคำสั่ง |
|
PEM |
รูปแบบ Privacy Enhanced Mail (PEM) เป็นรูปแบบ ASCII ที่อิงตามข้อความซึ่งเป็นการเข้ารหัส Base64
ของรูปแบบ Distinguished Encoding Rules (DER) แบบไบนารี ใบรับรอง PEM
สามารถเปิดได้ในเครื่องมือแก้ไขข้อความใดก็ได้ และเนื้อหาใบรับรองจริงจะคั่น
ระหว่างข้อความ
โดยเป็นไปตามรูปแบบ X.509 สำหรับจัดเก็บใบรับรอง เชนใบรับรอง หรือคีย์ส่วนตัว หากใบรับรองหรือรหัสส่วนตัวไม่ได้กำหนดโดยไฟล์ PEM คุณสามารถแปลง เป็นไฟล์ PEM ได้โดยใช้ยูทิลิตี เช่น OpenSSL |
| PKCS #12/PFX | รูปแบบ PKCS #12 หรือ PFX เป็นรูปแบบไบนารีสำหรับจัดเก็บใบรับรองเซิร์ฟเวอร์ ใบรับรอง ระดับกลาง และคีย์ส่วนตัวไว้ในไฟล์ที่เข้ารหัสได้ไฟล์เดียว โดยปกติแล้วไฟล์ PFX จะมีนามสกุล เช่น .pfx และ .p12 โดยปกติแล้วจะใช้ไฟล์ PFX ในเครื่อง Windows เพื่อนำเข้าและส่งออกใบรับรองและคีย์ส่วนตัว |
|
คีย์ส่วนตัว |
ใช้ในเซิร์ฟเวอร์ TLS เพื่อถอดรหัสข้อมูล มีเพียงเซิร์ฟเวอร์ TLS เท่านั้นที่มีคีย์ส่วนตัว โดยจะไม่มีการแชร์กับไคลเอ็นต์ TLS |
|
คีย์สาธารณะ |
ใช้เพื่อเข้ารหัสข้อมูลที่ส่งจากไคลเอ็นต์ TLS ไปยังเซิร์ฟเวอร์ TLS คีย์สาธารณะจะรวมอยู่ในใบรับรอง ไคลเอ็นต์ TLS ทั้งหมดมีสำเนาคีย์สาธารณะของเซิร์ฟเวอร์ |
| ข้อมูลอ้างอิง | การอ้างอิงจะให้ระดับการเปลี่ยนเส้นทางสำหรับที่เก็บคีย์ ดังนั้นการเปลี่ยนแปลงที่เก็บคีย์จึงไม่จำเป็นต้องอัปเดตโฮสต์เสมือนตราบใดที่ยังคงใช้การอ้างอิงและนามแฝงคีย์เดียวกัน ซึ่งจะช่วยให้คุณทำการเปลี่ยนแปลงเหล่านี้ได้ด้วยตนเองและลดการพึ่งพา ทีมสนับสนุนของ Apigee |
|
ใบรับรองแบบ Self-signed |
ใบรับรองที่ไม่ได้ลงนามโดย CA ที่เชื่อถือได้ ผู้ออกและเรื่องเหมือนกัน โดยลงนามด้วยคีย์ส่วนตัวที่ตรงกับคีย์สาธารณะที่มีอยู่ |
|
SNI |
การระบุชื่อเซิร์ฟเวอร์ อนุญาตให้แสดงเป้าหมาย HTTPS หลายรายการจากที่อยู่ IP และพอร์ตเดียวกันโดยไม่ต้องกำหนดให้เป้าหมายเหล่านั้นใช้ใบรับรองเดียวกัน |
|
ใบรับรอง TLS |
ไฟล์ดิจิทัลที่ระบุเอนทิตีในธุรกรรม TLS ใบรับรองหรือ cert ใช้เพื่อระบุเซิร์ฟเวอร์ TLS และไคลเอ็นต์ TLS ได้ ทั้งนี้ขึ้นอยู่กับการกำหนดค่า TLS |
|
Truststore |
มีใบรับรองที่เชื่อถือได้ในไคลเอ็นต์ TLS ที่ใช้เพื่อตรวจสอบใบรับรองของเซิร์ฟเวอร์ TLS ที่แสดงต่อไคลเอ็นต์ โดยปกติแล้ว ใบรับรองเหล่านี้จะเป็นใบรับรองแบบ Self-signed หรือใบรับรองที่ไม่ได้ลงนามโดย CA ที่เชื่อถือได้ ในการเชื่อมต่อขาขึ้น ระบบจะจัดเก็บใบรับรองของแอปพลิเคชันไคลเอ็นต์ ไว้ใน Truststore ใน Apigee Edge ต้องระบุแอตทริบิวต์นี้เฉพาะในกรณีที่คุณกำหนดค่า TLS แบบ 2 ทางระหว่างไคลเอ็นต์กับ Apigee ในการเชื่อมต่อขาออก ระบบจะจัดเก็บใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์ ไว้ใน Truststore ใน Apigee Edge ต้องระบุ หากต้องการยืนยันใบรับรองของแบ็กเอนด์ใน Apigee Edge ในการสื่อสาร TLS ทางเดียวหรือ สองทางระหว่าง Apigee Edge กับเซิร์ฟเวอร์แบ็กเอนด์ Apigee Edge ไม่มีออบเจ็กต์ Truststore แยกต่างหาก ดังนั้น truststore จึงสร้างขึ้นเป็นออบเจ็กต์ที่เก็บคีย์ แต่จะอ้างอิงเป็น truststore ทุกที่ที่ใช้ (เช่น ในโฮสต์เสมือน จุดสิ้นสุดเป้าหมาย เซิร์ฟเวอร์เป้าหมาย ฯลฯ) |
| โฮสต์เสมือน |
โฮสต์เสมือน แสดงถึงปลายทาง API ของ Apigee สำหรับแอปพลิเคชันไคลเอ็นต์ ซึ่งเป็นเอนทิตีที่ช่วยในการ โฮสต์ชื่อโดเมนหลายรายการ ( โดยมีการจัดการชื่อแต่ละชื่อแยกกัน) ในเซิร์ฟเวอร์เดียว (หรือกลุ่มเซิร์ฟเวอร์) ซึ่งช่วยให้เซิร์ฟเวอร์หนึ่งแชร์ทรัพยากรของตนได้ เช่น หน่วยความจำและรอบการประมวลผล โดยไม่ต้องกำหนดให้บริการทั้งหมดใช้ชื่อโฮสต์เดียวกัน โฮสต์เสมือนจะแสดงการรับส่งข้อมูล HTTP หรือ HTTPS (ที่เปิดใช้ SSL) ก็ได้ คุณกำหนดค่าโฮสต์เสมือนที่เปิดใช้ SSL ได้ในโหมด TLS ทางเดียวหรือสองทาง โดยมีการกำหนดค่าดังนี้
|
TLS/SSL ทางเดียว
รูปภาพต่อไปนี้แสดงการแฮนด์เชค TLS/SSL สำหรับการตรวจสอบสิทธิ์ทางเดียวระหว่างไคลเอ็นต์ TLS และเซิร์ฟเวอร์ TLS
ในการกำหนดค่า TLS ทางเดียว แฮนด์เชคจะเป็นดังนี้
- ไคลเอ็นต์ส่งคำขอเซสชันไปยังเซิร์ฟเวอร์
- เซิร์ฟเวอร์จะตอบกลับด้วยใบรับรองที่มีคีย์สาธารณะ ใบรับรองนี้ มาจากคีย์สโตร์ของเซิร์ฟเวอร์ ซึ่งมีคีย์ส่วนตัวของเซิร์ฟเวอร์ด้วย ระบบจะไม่ส่งคีย์ส่วนตัว ไปยังไคลเอ็นต์
- สำหรับใบรับรองที่ลงนาม ไคลเอ็นต์จะใช้ Truststore ที่มีใบรับรองเซิร์ฟเวอร์และคีย์สาธารณะ เพื่อตรวจสอบว่ากลุ่มใบรับรองลงนามโดยผู้ออกใบรับรอง (CA) ที่เชื่อถือได้
- ไคลเอ็นต์และเซิร์ฟเวอร์จะแลกเปลี่ยนข้อความอีกหลายรายการเพื่อตรวจสอบคีย์
- ไคลเอ็นต์เริ่มการโอนข้อมูล TLS กับเซิร์ฟเวอร์
รูปต่อไปนี้แสดงการแฮนด์เชค TLS/SSL โดยใช้ Truststore ที่ไม่บังคับในไคลเอ็นต์
หากเซิร์ฟเวอร์ TLS ใช้ใบรับรองแบบ Self-signed หรือใบรับรองที่ไม่ได้ลงนามโดย CA ที่เชื่อถือได้ คุณจะต้องสร้าง Trust Store ในไคลเอ็นต์ ไคลเอ็นต์จะป้อนข้อมูลลงใน Truststore ด้วย ใบรับรองเซิร์ฟเวอร์และคีย์สาธารณะที่เชื่อถือ เมื่อไคลเอ็นต์ได้รับใบรับรอง ระบบจะตรวจสอบใบรับรองขาเข้ากับใบรับรองใน Truststore
ใน TLS ทางเดียว Edge จะเป็นเซิร์ฟเวอร์หรือไคลเอ็นต์ก็ได้ ดังนี้
-
Edge เป็นเซิร์ฟเวอร์ TLS
Edge คือเซิร์ฟเวอร์ที่โฮสต์ปลายทาง TLS ซึ่งปลายทาง TLS จะสอดคล้องกับพร็อกซี API ที่ ติดตั้งใช้งานในโฮสต์เสมือน ไคลเอ็นต์คือแอปที่พยายามเข้าถึงพร็อกซี API ใน สถานการณ์นี้ Edge มีคีย์สโตร์ที่มีใบรับรองและคีย์ส่วนตัว
-
Edge เป็นไคลเอ็นต์ TLS
Edge ทำหน้าที่เป็นไคลเอ็นต์ที่เข้าถึงบริการแบ็กเอนด์ ในกรณีนี้ บริการแบ็กเอนด์ จะสอดคล้องกับเซิร์ฟเวอร์ที่โฮสต์ปลายทาง TLS ดังนั้นเซิร์ฟเวอร์แบ็กเอนด์จึงมีที่เก็บคีย์ ซึ่งมีใบรับรองและคีย์ส่วนตัว
TLS แบบ 2 ทาง
รูปภาพต่อไปนี้แสดงการแฮนด์เชค TLS/SSL สำหรับการตรวจสอบสิทธิ์ TLS แบบ 2 ทางระหว่างไคลเอ็นต์และเซิร์ฟเวอร์
ใน TLS แบบ 2 ทาง แฮนด์เชคจะมีลักษณะดังนี้
- ทั้งไคลเอ็นต์และเซิร์ฟเวอร์มีที่เก็บคีย์ของตัวเอง Keystore ของไคลเอ็นต์มีใบรับรองและคีย์ส่วนตัว ส่วน Keystore ของเซิร์ฟเวอร์มีใบรับรองและคีย์ส่วนตัว
- เซิร์ฟเวอร์ TLS จะแสดงใบรับรองต่อไคลเอ็นต์ TLS เพื่อตรวจสอบสิทธิ์ของตัวเอง จากนั้นไคลเอ็นต์จะยืนยันตัวตนของเซิร์ฟเวอร์ก่อนที่จะส่งใบรับรองไปยังเซิร์ฟเวอร์
- ไคลเอ็นต์ TLS จะแสดงใบรับรองต่อเซิร์ฟเวอร์ TLS เพื่อตรวจสอบสิทธิ์ตัวเองกับเซิร์ฟเวอร์
รูปภาพต่อไปนี้แสดงการแฮนด์เชค TLS โดยใช้ Truststore ที่ไม่บังคับ
ในสถานการณ์นี้ การแฮนด์เชคจะเป็นดังนี้
- หากเซิร์ฟเวอร์ TLS ใช้ใบรับรองแบบ Self-signed หรือใบรับรองที่ไม่ได้ลงชื่อโดย CA ที่เชื่อถือได้ คุณจะต้องสร้าง Trust Store ในไคลเอ็นต์ ไคลเอ็นต์มีสำเนาใบรับรองของเซิร์ฟเวอร์ใน Truststore ในระหว่างแฮนด์เชค TLS ไคลเอ็นต์จะเปรียบเทียบใบรับรองใน Truststore กับใบรับรองที่ส่งจาก เซิร์ฟเวอร์เพื่อยืนยันตัวตนของเซิร์ฟเวอร์
- หาก ไคลเอ็นต์ TLS ใช้ใบรับรองแบบ Self-signed หรือใบรับรองที่ไม่ได้ลงชื่อโดย CA ที่เชื่อถือได้ คุณจะต้องสร้าง Trust Store ในเซิร์ฟเวอร์ โดยเซิร์ฟเวอร์จะมีสำเนาใบรับรองของไคลเอ็นต์ใน Trust Store ในระหว่างการแฮนด์เชค TLS เซิร์ฟเวอร์จะเปรียบเทียบใบรับรอง ใน Truststore กับใบรับรองที่ส่งจากไคลเอ็นต์เพื่อยืนยัน ตัวตนของไคลเอ็นต์
ไคลเอ็นต์ เซิร์ฟเวอร์ หรือทั้ง 2 อย่างสามารถใช้ Truststore ได้
ใน TLS แบบ 2 ทาง Edge จะเป็นเซิร์ฟเวอร์หรือไคลเอ็นต์ก็ได้ ดังนี้
-
Edge เป็นเซิร์ฟเวอร์
Edge คือเซิร์ฟเวอร์ที่โฮสต์ปลายทาง TLS ซึ่งปลายทาง TLS จะสอดคล้องกับพร็อกซี API ไคลเอ็นต์คือแอปที่พยายามเข้าถึงพร็อกซี API ในสถานการณ์นี้ Edge มีคีย์สโตร์ที่มีใบรับรองและคีย์ส่วนตัว และต้องมี Truststore ที่มีใบรับรองของไคลเอ็นต์และเชน CA
-
Edge ในฐานะไคลเอ็นต์
Edge ทำหน้าที่เป็นไคลเอ็นต์ที่เข้าถึงบริการแบ็กเอนด์ ในกรณีนี้ บริการแบ็กเอนด์ จะสอดคล้องกับเซิร์ฟเวอร์ที่โฮสต์ปลายทาง TLS ดังนั้นเซิร์ฟเวอร์แบ็กเอนด์จึงมีที่เก็บคีย์ ซึ่งมีใบรับรองและคีย์ส่วนตัว
นอกจากนี้ Edge ต้องกำหนดคีย์สโตร์ที่มีใบรับรองที่จำเป็นต่อการตรวจสอบตัวเองกับ บริการแบ็กเอนด์ และอาจกำหนด Truststore ที่มีใบรับรองจากเซิร์ฟเวอร์แบ็กเอนด์หาก เซิร์ฟเวอร์ใช้ใบรับรองแบบ Self-signed หรือใบรับรองที่ไม่ได้ลงนามโดย CA ที่เชื่อถือได้
สิ่งสำคัญที่ควรทราบคือ Edge มีความยืดหยุ่นเพียงพอที่จะรองรับ TLS แบบ 2 ทาง ไม่ว่าคุณจะเลือกกำหนดค่าอย่างไรก็ตาม
การรองรับ SNI
Edge รองรับการใช้การระบุชื่อเซิร์ฟเวอร์ (SNI) จากพร็อกซี API ไปยัง Edge ซึ่ง Edge ทำหน้าที่เป็นเซิร์ฟเวอร์ TLS และจาก Edge ไปยังปลายทางเป้าหมาย ซึ่ง Edge ทำหน้าที่เป็นไคลเอ็นต์ TLS ทั้งในการติดตั้งใช้งาน Cloud และ Private Cloud
SNI เป็นส่วนขยายของ TLS/SSL ซึ่งช่วยให้แสดงเป้าหมาย HTTPS หลายรายการจากที่อยู่ IP และพอร์ตเดียวกันได้โดยไม่ต้องกำหนดให้เป้าหมายเหล่านั้นใช้ใบรับรองเดียวกัน
ดูข้อมูลเกี่ยวกับการเปิดใช้ SNI สำหรับการติดตั้งในองค์กรได้ที่ การใช้ SNI กับ Edge
มุ่งหน้าไปทางเหนือและใต้
ใน Apigee คำว่า "ขาขึ้น" หมายถึงปลายทาง API ที่แอปพลิเคชันไคลเอ็นต์ใช้เพื่อเรียกใช้พร็อกซี API โดยปกติแล้ว เราเตอร์จะเป็นจุดแรกเข้าใน Apigee Edge และจะจัดการคำขอขาเข้าที่ส่งไปยัง Apigee Edge ดังนั้นใน Apigee ปลายทางที่ใช้สำหรับการสื่อสารระหว่าง แอปพลิเคชันไคลเอ็นต์กับ Apigee Edge (เราเตอร์) จึงเรียกว่าขาขึ้น
ใน Apigee คำว่า "ขาออก" หมายถึงปลายทางเป้าหมายที่ Apigee ใช้เพื่อสื่อสารกับเซิร์ฟเวอร์แบ็กเอนด์ ดังนั้นใน Apigee ปลายทางที่ใช้สำหรับการสื่อสารระหว่าง Apigee Edge (Message Processor) กับเซิร์ฟเวอร์แบ็กเอนด์จึงเรียกว่าขาออก Message Processor เป็นคอมโพเนนต์ของ Apigee Edge ที่ทำหน้าที่เป็นพร็อกซีคำขอ API ไปยังเซิร์ฟเวอร์เป้าหมายในแบ็กเอนด์
รูปต่อไปนี้แสดงการเชื่อมต่อขาเข้าและขาออกสำหรับ Apigee Edge
