מידע על TLS/SSL

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

‫Transport Layer Security ‏ (TLS), שהקודם שלו הוא Secure Sockets Layer ‏ (SSL), הוא טכנולוגיית האבטחה הסטנדרטית ליצירת קישור מוצפן בין שרת אינטרנט לבין לקוח אינטרנט, כמו דפדפן או אפליקציה. קישור מוצפן מבטיח שכל הנתונים שעוברים בין השרת ללקוח יישארו פרטיים. כדי להשתמש ב-TLS, הלקוח שולח בקשה מאובטחת לשרת באמצעות פרוטוקול HTTPS המוצפן, במקום פרוטוקול HTTP הלא מוצפן.

‫Edge תומך ב-TLS חד-כיווני וב-TLS דו-כיווני גם בפריסה בענן וגם בפריסה מקומית (לגרסאות נתמכות של TLS, אפשר לעיין בתוכנות נתמכות וגרסאות נתמכות). פרוטוקול TLS חד-כיווני מאפשר ללקוח TLS לאמת את הזהות של שרת TLS. לדוגמה, אפליקציה שפועלת בטלפון Android (לקוח) יכולה לאמת את הזהות של ממשקי Edge API (שרת).

‫Apigee תומך גם בצורה חזקה יותר של אימות באמצעות TLS דו-כיווני או TLS של לקוח. בדרך כלל מטמיעים TLS דו-כיווני כדי לשפר את האבטחה מקצה לקצה ולהגן על הנתונים מפני התקפות מצד הלקוח, כמו התחזות ללקוח או התקפות מסוג 'אדם באמצע'. ב-TLS דו-כיווני, הלקוח מאמת את הזהות של השרת, ואז השרת מאמת את הזהות של הלקוח.

מונחים שקשורים ל-TLS

לפני שמגדירים TLS, חשוב להכיר את המונחים והמושגים הבאים:

מונח	הגדרה
CA	רשות אישורים. גורם מהימן, כמו Symantec או VeriSign, שמשמש להנפקת אישורים ולאימות האותנטיות של אישור. סוג אחד של אישור, שנקרא אישור עם חתימה עצמית, לא דורש רשות אישורים.
שרשרת אישורים	לרוב לא יהיה לכם אישור שחתום על ידי המפתח הפרטי הבסיסי של רשות האישורים. במקום זאת, יש לך אישור עם אישור ביניים אחד או יותר שיוצרים שרשרת. בדרך כלל, אישור הביניים האחרון בשרשרת נחתם על ידי המפתח הפרטי הבסיסי של ה-CA.
CSR	בקשה לחתימת אישור. בקשת חתימה על אישור (CSR) היא קובץ שנוצר בשרת TLS על סמך המפתח הפרטי. בקובץ ה-CSR מופיע המפתח הציבורי ומידע נוסף כמו שם הארגון, המיקום ושם הדומיין. רשות האישורים חותמת על ה-CSR כדי ליצור אישור TLS. בדרך כלל יוצרים CSR כשאישור תוקף פג ואתם רוצים לחדש אותו.
DER	כללי קידוד מובחנים. פורמט DER הוא פורמט בינארי של אישור, במקום פורמט PEM של ASCII. לפעמים יש לו סיומת ‎ .der, אבל לרוב יש לו סיומת ‎ .cer. הדרך היחידה להבחין בין קובץ DER‏ ‎ .cer לבין קובץ PEM‏ ‎ .cer היא לפתוח את הקובץ בעורך טקסט ולחפש את ההצהרות BEGIN ו-END. אפשר לקודד את כל סוגי האישורים והמפתחות הפרטיים בפורמט DER. בדרך כלל משתמשים ב-DER בפלטפורמות Java.
כינוי למפתח	כינוי של מפתח מזהה באופן ייחודי רשומה במאגר המפתחות (אישור TLS ומפתח פרטי תואם) במאגר המפתחות. ב-Apigee Edge KeyAlias נקרא alias כשמעלים את האישור או המפתח למאגרי המפתחות באמצעות ממשק המשתמש או ה-API.
Keystore	מאגר מפתחות הוא מאגר שמכיל אישור TLS אחד או יותר ומפתח פרטי תואם שמשמש לזיהוי הישות במהלך לחיצת יד ב-TLS בין לקוח לשרת. בחיבור צפונה, הנתב פועל כשרת והאישור שלו מאוחסן במאגר המפתחות ב-Apigee Edge. בחיבור דרומה, מעבד ההודעות פועל כלקוח ושרת הקצה העורפי פועל כשרת. אישור הלקוח והמפתח הפרטי שלו מאוחסנים במאגר המפתחות ב-Apigee Edge.
P7B	בדרך כלל, הפורמט PKCS #7 או P7B מאוחסן בפורמט Base64 ASCII ויש לו סיומת קובץ ‎ .p7b או ‎ .p7c. אישורי P7B מכילים הצהרות -----BEGIN PKCS7----- ו------END PKCS7-----. קובץ P7B מכיל רק אישורים ואישורים של שרשרת, ולא את המפתח הפרטי.
PEM	פורמט PEM (דואר עם פרטיות משודרגת) הוא פורמט ASCII מבוסס-טקסט, שהוא קידוד Base64 של פורמט 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 יש עותק של המפתח הציבורי של השרת.
חומרי עזר	ההפניות מספקות רמת הפניה עקיפה למאגרי מפתחות, ולכן שינויים במאגרי מפתחות לא מחייבים עדכון של המארח הווירטואלי, כל עוד נשמרים אותה הפניה ואותו שם מפתח. כך תוכלו לבצע את השינויים האלה בעצמכם ולצמצם את התלות בצוות התמיכה של Apigee.
תעודה בחתימה עצמית	אישור שלא נחתם על ידי רשות אישורים מהימנה. המנפיק והנושא זהים, והם חתומים באמצעות המפתח הפרטי שתואם למפתח הציבורי שהם מכילים.
SNI	Server Name Indication (אינדיקציה של שם השרת). מאפשר להציג כמה יעדי HTTPS מאותה כתובת IP ומאותו יציאה בלי לדרוש מהיעדים האלה להשתמש באותו אישור.
אישור TLS	קובץ דיגיטלי שמזהה ישות בעסקת TLS. אפשר להשתמש באישור, או ב-cert, כדי לזהות את שרת ה-TLS ואת לקוח ה-TLS, בהתאם להגדרת ה-TLS.
Truststore	מכיל אישורים מהימנים בלקוח TLS שמשמשים לאימות האישור של שרת TLS שמוצג ללקוח. בדרך כלל מדובר באישורים בחתימה עצמית או באישורים שלא נחתמו על ידי רשות אישורים מהימנה. בחיבור צפונה, האישורים של אפליקציית הלקוח מאוחסנים במאגר האישורים המהימנים ב-Apigee Edge. המאפיין הזה נדרש רק אם הגדרתם TLS דו-כיווני בין הלקוח לבין Apigee. בחיבור southbound, האישורים של שרת הקצה העורפי מאוחסנים במאגר האישורים ב-Apigee Edge. הפעולה הזו נדרשת אם רוצים לאמת את האישור של הקצה העורפי ב-Apigee Edge בתקשורת TLS חד-כיוונית או דו-כיוונית בין Apigee Edge לבין שרת הקצה העורפי. ל-Apigee Edge אין אובייקט נפרד של truststore. לכן, מאגרי האישורים נוצרים כאובייקט של מאגר מפתחות, אבל הם נקראים מאגר אישורים בכל מקום שבו הם נמצאים בשימוש (לדוגמה, במארח וירטואלי, בנקודות קצה של יעד, בשרתי יעד וכו').
מארח וירטואלי	מארח וירטואלי מייצג את נקודת קצה ל-API של Apigee עבור אפליקציות לקוח. זוהי ישות שמסייעת באירוח של כמה שמות דומיינים (עם טיפול נפרד בכל שם) בשרת אחד (או במאגר שרתים). כך שרת אחד יכול לשתף את המשאבים שלו, כמו זיכרון ומחזורי מעבד, בלי שכל השירותים שמוגדרים בו ישתמשו באותו שם מארח. מארח וירטואלי יכול להציג תנועה מסוג HTTP או HTTPS (עם SSL). אפשר להגדיר מארח וירטואלי עם SSL במצב TLS חד-כיווני או דו-כיווני. ההגדרות שלו הן: כינוי מארח אחד או יותר (שם DNS של נקודת קצה ל-API). יציאה מאגר מפתחות כינוי המפתח שמזהה באופן ייחודי אחד מאישורי השרת במאגר המפתחות. אופציונלי, מאגר אישורים (ב-TLS דו-כיווני, שבו מופעל אימות לקוח).

TLS/SSL חד-כיווני

באיור הבא מוצג תהליך לחיצת היד של TLS/SSL לאימות חד-כיווני בין לקוח TLS לבין שרת TLS:

בתצורת TLS חד-כיוונית, לחיצת היד מתבצעת באופן הבא:

• הלקוח שולח בקשה לסשן לשרת.
• השרת מגיב עם אישור שמכיל את המפתח הציבורי שלו. האישור הזה מגיע ממאגר המפתחות של השרת, שמכיל גם את המפתח הפרטי של השרת. המפתח הפרטי אף פעם לא נשלח ללקוח.
• באישור חתום, הלקוח משתמש במאגר אישורים מהימן שמכיל אישורי שרת ומפתחות ציבוריים כדי לאמת ששרשרת האישורים חתומה על ידי רשות אישורים (CA) מהימנה.
• הלקוח והשרת מחליפים עוד כמה הודעות כדי לאמת את המפתחות.
• הלקוח מתחיל העברת נתונים ב-TLS עם השרת.

באיור הבא מוצג תהליך לחיצת היד של TLS/SSL באמצעות מאגר אישורים אופציונלי בלקוח:

אם שרת ה-TLS משתמש באישור בחתימה עצמית או באישור שלא חתום על ידי רשות אישורים מהימנה, צריך ליצור מאגר אישורים בלקוח. הלקוח מאכלס את מאגר האישורים שלו באישורי שרת ובמפתחות ציבוריים שהוא סומך עליהם. כשהלקוח מקבל אישור, הוא מאומת מול האישורים במאגר האישורים שלו.

ב-TLS חד-כיווני, Edge יכול להיות השרת או הלקוח באופן הבא:

• Edge כשרת TLS

  ‫Edge הוא השרת שמארח את נקודת הקצה של TLS, כאשר נקודת הקצה של TLS תואמת ל-proxy ל-API שנפרס במארח וירטואלי. הלקוח הוא אפליקציה שמנסה לגשת ל-proxy ל-API. בתרחיש הזה, ל-Edge יש את מאגר המפתחות שמכיל את האישור ואת המפתח הפרטי.

• ‫Edge כלקוח TLS

  ‫Edge פועל כלקוח שניגש לשירות לקצה העורפי. במקרה הזה, שירות הקצה העורפי תואם לשרת שמארח נקודת קצה של TLS. לכן לשרת העורפי יש מאגר מפתחות שמכיל את האישור והמפתח הפרטי שלו.

TLS דו-כיווני

באיור הבא מוצג תהליך הלחיצת יד של TLS/SSL לאימות TLS דו-כיווני בין לקוח לשרת:

בלחיצת יד של TLS דו-כיוונית:

• גם ללקוח וגם לשרת יש מאגרי מפתחות משלהם. מאגר המפתחות של הלקוח מכיל את האישור והמפתח הפרטי שלו, ומאגר המפתחות של השרת מכיל את האישור והמפתח הפרטי שלו.
• שרת ה-TLS מציג את האישור שלו ללקוח ה-TLS כדי לאמת את עצמו. לאחר מכן, הלקוח מאמת את הזהות של השרת לפני שהוא שולח את האישור שלו לשרת.
• לקוח ה-TLS מציג את האישור שלו לשרת ה-TLS כדי לאמת את עצמו מול השרת.

באיור הבא מוצג תהליך לחיצת היד של TLS באמצעות מאגר אישורים אופציונלי:

בתרחיש הזה, תהליך לחיצת היד הוא כזה:

• אם השרת של TLS משתמש באישור בחתימה עצמית או באישור שלא נחתם על ידי רשות אישורים מהימנה, צריך ליצור מאגר אישורים בלקוח. ללקוח יש עותק של אישור השרת במאגר האישורים שלו. במהלך לחיצת היד של TLS, הלקוח משווה את האישור במאגר האישורים המהימנים שלו לאישור שנשלח מהשרת כדי לאמת את הזהות של השרת.
• אם הלקוח של TLS משתמש באישור בחתימה עצמית או באישור שלא חתום על ידי רשות אישורים מהימנה, צריך ליצור מאגר אישורים בשרת.בשרת יש עותק של האישור של הלקוח במאגר האישורים שלו. במהלך לחיצת היד של TLS, השרת משווה את האישור במאגר האישורים שלו לאישור שנשלח מהלקוח כדי לאמת את הזהות של הלקוח.

הלקוח, השרת או שניהם יכולים להשתמש בחנות אישורים.

ב-TLS דו-כיווני, Edge יכול להיות השרת או הלקוח, באופן הבא:

• Edge כשרת

  ‫Edge הוא השרת שמארח את נקודת הקצה של TLS, כאשר נקודת הקצה של TLS תואמת ל-API proxy. הלקוח הוא אפליקציה שמנסה לגשת ל-proxy ל-API. בתרחיש הזה, ל-Edge יש מאגר מפתחות שמכיל את האישור והמפתח הפרטי, ונדרש מאגר מהימן שמכיל את האישור של הלקוח ואת שרשרת רשות האישורים.

• Edge כלקוח

  ‫Edge פועל כלקוח שמקבל גישה לשירות בקצה העורפי. במקרה הזה, שירות הקצה העורפי תואם לשרת שמארח את נקודת הקצה של TLS. לכן, לשרת העורפי יש מאגר מפתחות שמכיל את האישור והמפתח הפרטי שלו.

  ב-Edge צריך גם להגדיר מאגר מפתחות שמכיל את האישור שנדרש כדי לאמת את עצמו מול שירות לקצה העורפי, ובאופן אופציונלי גם מאגר אישורים מהימנים שמכיל את האישור משרת הבק-אנד אם השרת משתמש באישור בחתימה עצמית או באישור שלא נחתם על ידי רשות אישורים מהימנה.

חשוב לזכור ש-Edge גמיש מספיק כדי לתמוך ב-TLS דו-כיווני, לא משנה איך תבחרו להגדיר אותו.

תמיכה ב-SNI

‫Edge תומך בשימוש ב-Server Name Indication ‏ (SNI) מ-API proxies ל-Edge, כאשר Edge פועל כשרת TLS, ומ-Edge לנקודות קצה של יעד, כאשר Edge פועל כלקוח TLS, בהתקנות בענן ובענן פרטי.

עם SNI, שהוא הרחבה של TLS/SSL, אפשר להציג כמה יעדי HTTPS מאותה כתובת IP ומאותו פורט בלי שהיעדים האלה יצטרכו להשתמש באותו אישור.

מידע על הפעלת SNI בהתקנה מקומית זמין במאמר בנושא שימוש ב-SNI עם Edge.

צפונה ודרומה

ב-Apigee, המונח 'צפונה' מתייחס לנקודת קצה ל-API שמשמשת אפליקציות לקוח להפעלת ה-proxy ל-API. בדרך כלל, הנתב הוא נקודת הכניסה ב-Apigee Edge, והוא מטפל בבקשות הנכנסות ל-Apigee Edge. לכן ב-Apigee, נקודת הקצה שמשמשת לתקשורת בין אפליקציית הלקוח לבין Apigee Edge (הנתב) נקראת northbound.

ב-Apigee, המונח 'דרום' מתייחס לנקודת היעד ש-Apigee משתמש בה כדי לתקשר עם שרת הקצה העורפי. לכן ב-Apigee, נקודת הקצה שמשמשת לתקשורת בין Apigee Edge (מעבד ההודעות) לבין שרת הקצה העורפי נקראת southbound. מעבד ההודעות הוא רכיב של Apigee Edge שמשמש כ-proxy לבקשות API לשרתי יעד של קצה עורפי.

באיור הבא מוצגים חיבורים צפונה ודרומה ב-Apigee Edge: