מידע על TLS/SSL

אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info

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

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

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

מונחים בנושא TLS

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

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

• Edge בתור הלקוח

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

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

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

תמיכה ב-SNI

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

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

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

לכיוון צפון ולכיוון דרום

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

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

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