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

คุณกําลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X info

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

Edge รองรับ TLS แบบ 1 ทิศทางและ TLS แบบ 2 ทิศทางทั้งในระบบคลาวด์และการติดตั้งใช้งานในสถานที่ (ดู TLS เวอร์ชันที่รองรับได้ที่ซอฟต์แวร์และเวอร์ชันที่รองรับ) TLS แบบ 1 ทิศทางช่วยให้ไคลเอ็นต์ 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	กฎการเข้ารหัสที่โดดเด่น รูปแบบ DER คือรูปแบบไบนารีของใบรับรองแทนรูปแบบ ASCII PEM บางครั้งจะมีนามสกุลไฟล์เป็น .der แต่มักจะมีนามสกุลไฟล์เป็น .cer วิธีเดียวที่จะแยกความแตกต่างระหว่างไฟล์ .cer ของ DER กับไฟล์ .cer ของ PEM คือเปิดไฟล์ในเครื่องมือแก้ไขข้อความแล้วมองหาคำสั่ง BEGIN และ END ใบรับรองและคีย์ส่วนตัวทุกประเภทสามารถเข้ารหัสในรูปแบบ DER ได้ โดยปกติแล้ว DER จะใช้กับแพลตฟอร์ม Java
ชื่อแทนคีย์	ชื่อแทนคีย์เป็นตัวระบุที่ไม่ซ้ำกันของรายการคีย์สโตร์ (ใบรับรอง TLS และคีย์ส่วนตัวที่เกี่ยวข้อง) ในคีย์สโตร์ ใน Apigee Edge KeyAlias จะเรียกว่า alias เมื่อคุณอัปโหลดใบรับรอง/คีย์ไปยังคีย์สโตร์โดยใช้ UI หรือ API
Keystore	คีย์สโตร์เป็นที่เก็บซึ่งมีใบรับรอง TLS อย่างน้อย 1 รายการและคีย์ส่วนตัวที่เกี่ยวข้อง ซึ่งใช้ในการระบุเอนทิตีระหว่างการจับมือ TLS ระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ ในการเชื่อมต่อไปทางฝั่งไคลเอ็นต์ เราเตอร์จะทําหน้าที่เป็นเซิร์ฟเวอร์และใบรับรองจะจัดเก็บไว้ในคีย์สโตร์ใน Apigee Edge ในการเชื่อมต่อขาออก โปรแกรมประมวลผลข้อความจะทำหน้าที่เป็นไคลเอ็นต์และเซิร์ฟเวอร์แบ็กเอนด์จะทำหน้าที่เป็นเซิร์ฟเวอร์ ใบรับรองไคลเอ็นต์และคีย์ส่วนตัวจะจัดเก็บไว้ในคีย์สโตร์ใน 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 เป็นรูปแบบไบนารีสำหรับจัดเก็บใบรับรองเซิร์ฟเวอร์ ใบรับรองกลาง และ<2ce> คีย์ส่วนตัวในไฟล์ที่เข้ารหัสได้ไฟล์เดียว ไฟล์ PFX มักจะมีนามสกุล เช่น .pfx และ .p12 โดยทั่วไปไฟล์ PFX จะใช้ในเครื่อง Windows เพื่อนำเข้าและส่งออกใบรับรองและคีย์ส่วนตัว
คีย์ส่วนตัว	ใช้บนเซิร์ฟเวอร์ TLS เพื่อถอดรหัสข้อมูล มีเพียงเซิร์ฟเวอร์ TLS เท่านั้นที่มีคีย์ส่วนตัว ซึ่งจะไม่แชร์กับไคลเอ็นต์ TLS
คีย์สาธารณะ	ใช้เพื่อเข้ารหัสข้อมูลที่ส่งจากไคลเอ็นต์ TLS ไปยังเซิร์ฟเวอร์ TLS คีย์สาธารณะจะรวมอยู่ในใบรับรอง โปรแกรมไคลเอ็นต์ TLS ทั้งหมดจะมีสำเนาคีย์สาธารณะของเซิร์ฟเวอร์
ข้อมูลอ้างอิง	การอ้างอิงจะให้ระดับการสื่อให้เข้าใจสำหรับคีย์สโตร์ ดังนั้นการเปลี่ยนแปลงคีย์สโตร์จึงไม่จำเป็นต้องอัปเดตโฮสต์เสมือน ตราบใดที่มีการคงการอ้างอิงและอีเมลแทนของคีย์ไว้ ซึ่งจะช่วยให้คุณทําการเปลี่ยนแปลงเหล่านี้ด้วยตนเองได้และลดการพึ่งพาทีมสนับสนุนของ Apigee
ใบรับรองที่ลงนามด้วยตนเอง	ใบรับรองที่ CA ที่เชื่อถือไม่ได้ลงนาม ผู้ออกใบรับรองและบุคคลที่ระบุจะเหมือนกัน โดยลงนามด้วยคีย์ส่วนตัวที่ตรงกับคีย์สาธารณะที่มี
SNI	การระบุชื่อเซิร์ฟเวอร์ อนุญาตให้แสดงเป้าหมาย HTTPS หลายรายการจากที่อยู่ IP และพอร์ตเดียวกันได้โดยไม่ต้องกำหนดให้เป้าหมายเหล่านั้นใช้ใบรับรองเดียวกัน
ใบรับรอง TLS	ไฟล์ดิจิทัลที่ระบุตัวตนในธุรกรรม TLS ใบรับรองหรือ cert สามารถใช้เพื่อระบุเซิร์ฟเวอร์ TLS และไคลเอ็นต์ TLS ได้ ทั้งนี้ขึ้นอยู่กับการกำหนดค่า TLS
Truststore	มีใบรับรองที่เชื่อถือได้ในไคลเอ็นต์ TLS ซึ่งใช้ในการตรวจสอบใบรับรองของเซิร์ฟเวอร์ TLS ที่แสดงต่อไคลเอ็นต์ โดยปกติแล้วใบรับรองเหล่านี้จะเป็นใบรับรองแบบ Self-signed หรือใบรับรองที่ CA ที่เชื่อถือไม่ได้ลงนาม ในการเชื่อมต่อขาออก ใบรับรองของแอปพลิเคชันไคลเอ็นต์จะจัดเก็บไว้ในที่เก็บข้อมูลที่เชื่อถือใน Apigee Edge ขั้นตอนนี้จำเป็นเฉพาะในกรณีที่คุณกำหนดค่า TLS แบบ 2 ทางระหว่างไคลเอ็นต์กับ Apigee เท่านั้น ในการเชื่อมต่อขาออก ระบบจะจัดเก็บใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์ไว้ในที่เก็บข้อมูลที่เชื่อถือใน Apigee Edge ซึ่งจำเป็นต้องทำหากคุณต้องการยืนยันใบรับรองของแบ็กเอนด์ใน Apigee Edge ในการสื่อสาร TLS แบบ 1 ทิศทางหรือ 2 ทิศทางระหว่าง Apigee Edge กับเซิร์ฟเวอร์แบ็กเอนด์ Apigee Edge ไม่มีออบเจ็กต์ Truststore แยกต่างหาก ดังนั้น ระบบจึงสร้างที่เก็บข้อมูลเชื่อถือเป็นออบเจ็กต์คีย์สโตร์ แต่อ้างอิงเป็น "ที่เก็บข้อมูลเชื่อถือ" ในทุกที่ที่ใช้ (เช่น ในโฮสต์เสมือน จุดสิ้นสุดเป้าหมาย เซิร์ฟเวอร์เป้าหมาย ฯลฯ)
โฮสต์เสมือน	โฮสต์เสมือนแสดงถึงปลายทาง Apigee API สําหรับแอปพลิเคชันไคลเอ็นต์ ซึ่งเป็นเอนทิตีที่จะช่วยโฮสต์ชื่อโดเมนหลายรายการ (โดยจัดการแต่ละชื่อแยกกัน) ในเซิร์ฟเวอร์ (หรือกลุ่มเซิร์ฟเวอร์) เดียว ซึ่งช่วยให้เซิร์ฟเวอร์หนึ่งแชร์ทรัพยากร เช่น หน่วยความจำและรอบการทำงานของโปรเซสเซอร์ได้โดยไม่ต้องกำหนดให้บริการทั้งหมดที่ใช้ชื่อโฮสต์เดียวกัน โฮสต์เสมือนสามารถให้บริการรับส่งข้อมูล HTTP หรือ HTTPS (เปิดใช้ SSL) คุณกำหนดค่าโฮสต์เสมือนที่เปิดใช้ SSL ได้ในโหมด TLS แบบ 1 ทางหรือ 2 ทาง โดยกำหนดค่าด้วยสิ่งต่อไปนี้ รายการแทนชื่อโฮสต์อย่างน้อย 1 รายการ (ชื่อ DNS ของปลายทาง API) พอร์ต คีย์สโตร์ ชื่อแทนคีย์เพื่อระบุใบรับรองเซิร์ฟเวอร์รายการใดรายการหนึ่งในคีย์สโตร์โดยไม่ซ้ำกัน ร้านค้าที่เชื่อถือ (ไม่บังคับ) (ใน TLS แบบ 2 ทางที่เปิดใช้การตรวจสอบสิทธิ์ไคลเอ็นต์)

TLS/SSL แบบ 1 ทิศทาง

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

ในการกำหนดค่า TLS แบบ 1 ทิศทาง แฮนด์เชคจะมีลักษณะดังนี้

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

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

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

ใน TLS แบบ 1 ทิศทาง 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 ในไคลเอ็นต์ ไคลเอ็นต์มีสำเนาใบรับรองของเซิร์ฟเวอร์ในคลังความน่าเชื่อถือ ในระหว่างการจับมือ TLS ไคลเอ็นต์จะเปรียบเทียบใบรับรองในคลังความน่าเชื่อถือกับใบรับรองที่ส่งจากเซิร์ฟเวอร์เพื่อยืนยันตัวตนของเซิร์ฟเวอร์
• หากไคลเอ็นต์ TLS ใช้ใบรับรองแบบ Self-signed หรือใบรับรองที่ CA ที่เชื่อถือไม่ได้ลงนาม คุณจะต้องสร้าง Trust Store ในเซิร์ฟเวอร์ โดยเซิร์ฟเวอร์จะมีสำเนาใบรับรองของไคลเอ็นต์ใน Trust Store ในระหว่างการจับมือ TLS เซิร์ฟเวอร์จะเปรียบเทียบใบรับรองในคลังความน่าเชื่อถือกับใบรับรองที่ส่งจากไคลเอ็นต์เพื่อยืนยันตัวตนของไคลเอ็นต์

ไคลเอ็นต์หรือเซิร์ฟเวอร์หรือทั้ง 2 อย่างสามารถใช้ที่เก็บข้อมูลเชื่อถือได้

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

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

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

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

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

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

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

การรองรับ SNI

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

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

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

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

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

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

รูปภาพต่อไปนี้แสดงการเชื่อมต่อขาเข้าและขาออกของ Apigee Edge