מידע על 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	אינדיקציה של שם השרת. מאפשר להציג כמה יעדי HTTPS מאותה כתובת IP ומאותו יציאה בלי לדרוש מהיעדים האלה להשתמש באותו אישור.
אישור TLS	קובץ דיגיטלי שמזהה ישות בעסקה ב-TLS. אפשר להשתמש באישור, או ב-cert, כדי לזהות את שרת ה-TLS ואת לקוח ה-TLS, בהתאם להגדרת ה-TLS.
Truststore	מכיל אישורים מהימנים בלקוח TLS שמשמשים לאימות אישור של שרת TLS שמוצג ללקוח. בדרך כלל מדובר באישור בחתימה עצמית או באישור שלא נחתם על ידי רשות אישורים (CA) מהימנה. בחיבור צפונה, האישורים של אפליקציית הלקוח מאוחסנים במאגר האישורים המהימנים ב-Apigee Edge. המאפיין הזה נדרש רק אם הגדרתם TLS דו-כיווני בין הלקוח לבין Apigee. בחיבור southbound, האישורים של שרת הקצה העורפי מאוחסנים במאגר האישורים ב-Apigee Edge. הפעולה הזו נדרשת אם רוצים לאמת את האישור של הקצה העורפי ב-Apigee Edge בתקשורת TLS חד-כיוונית או דו-כיוונית בין Apigee Edge לבין שרת הקצה העורפי. ל-Apigee Edge אין אובייקט נפרד של מאגר אישורים. לכן, מאגרי האישורים נוצרים כאובייקט של מאגר מפתחות, אבל הם נקראים מאגר אישורים בכל מקום שבו הם נמצאים בשימוש (למשל, במארח וירטואלי, בנקודות קצה של יעד, בשרתי יעד וכו').
מארח וירטואלי	מארח וירטואלי מייצג את נקודת הקצה של Apigee API עבור אפליקציות לקוח. זו ישות שעוזרת באירוח של כמה שמות דומיינים (עם טיפול נפרד בכל שם) בשרת אחד (או במאגר שרתים). כך שרת אחד יכול לשתף את המשאבים שלו, כמו זיכרון ומחזורי מעבד, בלי שכל השירותים שמוגדרים בו יצטרכו להשתמש באותו שם מארח. מארח וירטואלי יכול להציג תנועה מסוג 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 תואמת ל-API proxy שנפרס במארח וירטואלי. הלקוח הוא אפליקציה שמנסה לגשת ל-API Proxy. בתרחיש הזה, 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. הלקוח הוא אפליקציה שמנסה לגשת ל-API Proxy. בתרחיש הזה, ל-Edge יש מאגר מפתחות שמכיל את האישור והמפתח הפרטי, ונדרש מאגר מהימן שמכיל את האישור של הלקוח ואת שרשרת רשות האישורים.

• Edge כלקוח

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

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

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

תמיכה ב-SNI

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

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

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

צפונה ודרומה

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

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

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