เกี่ยวกับ 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 ใช้ในการออกใบรับรองและตรวจสอบความถูกต้องของใบรับรอง ใบรับรองประเภทหนึ่งที่เรียกว่าใบรับรอง Self-signed ไม่จำเป็นต้องมี CA
กลุ่มใบรับรอง	บ่อยครั้งที่คุณจะไม่มีใบรับรองที่ลงชื่อโดยคีย์ส่วนตัวระดับรูทของ CA แต่คุณจะมีใบรับรองพร้อมกับใบรับรองกลางอย่างน้อย 1 รายการที่ประกอบเป็นเชน โดยทั่วไปแล้ว ใบรับรองกลางตัวสุดท้ายในเชนจะมีการรับรองโดยคีย์ส่วนตัวระดับรูทของ CA
CSR	คำขอลงชื่อใบรับรอง CSR คือไฟล์ที่สร้างขึ้นในเซิร์ฟเวอร์ TLS ตามคีย์ส่วนตัว CSR มีคีย์สาธารณะและข้อมูลอื่นๆ เช่น ชื่อ สถานที่ตั้ง และชื่อโดเมนขององค์กร CA จะลงนามใน CSR เพื่อสร้างใบรับรอง TLS โดยปกติแล้ว คุณจะสร้าง CSR เมื่อมีใบรับรองที่หมดอายุและต้องการต่ออายุ
DER	กฎการเข้ารหัสเฉพาะ รูปแบบ 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 Encrypting 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	Server Name Indication (การแสดงชื่อเซิร์ฟเวอร์) อนุญาตให้เป้าหมาย HTTPS หลายเป้าหมายแสดงจากที่อยู่ IP และพอร์ตเดียวกันได้โดยที่เป้าหมายเหล่านั้นต้องใช้ใบรับรองเดียวกัน
ใบรับรอง TLS	ไฟล์ดิจิทัลที่ระบุเอนทิตีในธุรกรรม TLS ใบรับรองหรือcertใช้เพื่อระบุเซิร์ฟเวอร์ TLS และไคลเอ็นต์ TLS ได้ ทั้งนี้ขึ้นอยู่กับการกำหนดค่า TLS
Truststore	มีใบรับรองที่เชื่อถือได้บนไคลเอ็นต์ TLS ที่ใช้ตรวจสอบใบรับรองของเซิร์ฟเวอร์ TLS ที่แสดงต่อไคลเอ็นต์ โดยทั่วไปใบรับรองเหล่านี้จะเป็นใบรับรองแบบ Self-signed หรือใบรับรองที่ไม่ได้ลงชื่อโดย CA ที่เชื่อถือได้ ในการเชื่อมต่อทางเหนือ ใบรับรองของแอปพลิเคชันไคลเอ็นต์จะจัดเก็บไว้ใน Truststore ใน Apigee Edge ซึ่งจำเป็นต่อเมื่อคุณกำหนดค่า TLS แบบ 2 ทางระหว่างไคลเอ็นต์กับ Apigee แล้วเท่านั้น ในการเชื่อมต่อ southbound ใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์จะจัดเก็บไว้ใน Truststore ใน Apigee Edge คุณจำเป็นต้องดำเนินการนี้หากต้องการยืนยันใบรับรองของแบ็กเอนด์ใน Apigee Edge ด้วยการสื่อสาร TLS แบบทางเดียวหรือ 2 ทางระหว่าง Apigee Edge กับเซิร์ฟเวอร์แบ็กเอนด์ Apigee Edge ไม่มีออบเจ็กต์ Truststore แยกต่างหาก ดังนั้น ระบบจะสร้าง Truststores เป็นออบเจ็กต์คีย์สโตร์ แต่อ้างอิงเป็น Truststore ทุกที่ที่มีการใช้งาน (เช่น ในโฮสต์เสมือน, ปลายทางเป้าหมาย, เซิร์ฟเวอร์เป้าหมาย เป็นต้น)
โฮสต์เสมือน	โฮสต์เสมือนแสดงปลายทาง Apigee API สำหรับแอปพลิเคชันไคลเอ็นต์ ซึ่งเป็นเอนทิตีที่ช่วยโฮสต์ชื่อโดเมนหลายรายการ (โดยมีการจัดการสำหรับแต่ละชื่อแยกกัน) ในเซิร์ฟเวอร์เดียว (หรือกลุ่มเซิร์ฟเวอร์) การดำเนินการนี้จะอนุญาตให้เซิร์ฟเวอร์ 1 แห่งแชร์ทรัพยากร เช่น หน่วยความจำและรอบของตัวประมวลผล โดยที่บริการทั้งหมดที่ให้มาต้องใช้ชื่อโฮสต์เดียวกัน โฮสต์เสมือนให้บริการรับส่งข้อมูล HTTP หรือ HTTPS (ที่เปิดใช้ SSL) ได้ คุณสามารถกำหนดค่าโฮสต์เสมือนที่เปิดใช้ SSL ได้ในโหมด TLS แบบทางเดียวหรือ 2 ทาง โดยจะได้รับการกำหนดค่าด้วยสิ่งต่อไปนี้ โฮสต์ (ชื่อ DNS ปลายทางของ API) อย่างน้อย 1 รายการ พอร์ต คีย์สโตร์ ชื่อแทนคีย์สำหรับระบุใบรับรองเซิร์ฟเวอร์ในคีย์สโตร์แบบไม่ซ้ำ หรือ Truststore (ใน TLS แบบ 2 ทางที่เปิดใช้การตรวจสอบสิทธิ์ไคลเอ็นต์)

TLS/SSL ทางเดียว

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

ในการกำหนดค่า TLS แบบทางเดียว แฮนด์เชคมีดังนี้

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

ภาพต่อไปนี้แสดงแฮนด์เชค TLS/SSL โดยใช้ Truststore แบบเลือกได้บนไคลเอ็นต์

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

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

• Edge เป็นเซิร์ฟเวอร์ TLS

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

• Edge เป็นไคลเอ็นต์ TLS

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

TLS สองทาง

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

ใน TLS แบบ 2 ทาง แฮนด์เชคมีดังนี้

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

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

ในสถานการณ์นี้ แฮนด์เชคมีดังนี้

• หากเซิร์ฟเวอร์ TLS ใช้ใบรับรองแบบ Self-signed หรือใบรับรองที่ไม่ได้ลงชื่อโดย CA ที่เชื่อถือได้ คุณจะต้องสร้าง Truststore บนไคลเอ็นต์ ไคลเอ็นต์มีสำเนาใบรับรองของเซิร์ฟเวอร์ใน Truststore ในระหว่างแฮนด์เชค TLS ไคลเอ็นต์จะเปรียบเทียบใบรับรองใน Truststore กับใบรับรองที่ส่งจากเซิร์ฟเวอร์เพื่อยืนยันตัวตนของเซิร์ฟเวอร์
• หากไคลเอ็นต์ TLS ใช้ใบรับรองแบบ Self-signed หรือใบรับรองที่ไม่ได้ลงชื่อโดย CA ที่เชื่อถือได้ ให้คุณสร้าง Truststore บนเซิร์ฟเวอร์ โดยเซิร์ฟเวอร์มีสำเนาใบรับรองของไคลเอ็นต์ใน Truststore ในระหว่างแฮนด์เชค 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 รองรับการใช้ 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 ขอบเขตใต้หมายถึงปลายทางปลายทางที่ Apigee ใช้ในการสื่อสารกับเซิร์ฟเวอร์แบ็กเอนด์ ดังนั้น ใน Apigee ปลายทางที่ใช้สำหรับการสื่อสารระหว่าง Apigee Edge (ผู้ประมวลผลข้อความ) และเซิร์ฟเวอร์แบ็กเอนด์จะเรียกว่า southbound ตัวประมวลผลข้อความเป็นคอมโพเนนต์ของ Apigee Edge ที่พร็อกซีคำขอ API ไปยังเซิร์ฟเวอร์เป้าหมายแบ็กเอนด์

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