מידע על 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 (לקוח) יכולה לאמת את הזהות של ממשקי API של Edge (שרת).

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

הסברים על TLS

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

מונח	הגדרה
קנדה	רשות אישורים. ישות מהימנה, כמו Symantec או VeriSign, שימשה להנפקת אישורים ולאימות האישורים. סוג אחד של אישור, שנקרא אישור בחתימה עצמית, לא מחייב CA.
שרשרת אישורים	לעיתים קרובות לא יהיה לכם אישור שנחתם על ידי המפתח הפרטי של רשות האישורים ברמה עליונה. במקום זאת, יש לכם את האישור שלכם יחד עם אישור ביניים אחד או יותר שיוצרים שרשרת. אישור הביניים האחרון בשרשרת חתום בדרך כלל על ידי המפתח הפרטי ברמה הבסיסית של רשות האישורים.
נציג שירות לקוחות	בקשה לחתימה על אישור. CSR הוא קובץ שנוצר בשרת ה-TLS על סמך המפתח הפרטי. נציג שירות הלקוחות מכיל את המפתח הציבורי ומידע אחר, כגון שם הארגון, המיקום ושם הדומיין. רשות האישורים חותמת על ה-CSR כדי ליצור אישור TLS (אבטחת שכבת התעבורה). לרוב, יוצרים CSR כאשר יש אישור שפג תוקפו ורוצים לחדש אותו.
צילום	כללי קידוד ייחודיים. פורמט DER הוא סוג בינארי של אישור במקום פורמט ASCII PEM. לפעמים סיומת הקובץ היא .der אבל לעיתים קרובות סיומת הקובץ שלו היא .cer. הדרך היחידה להבדיל בין קובץ DER .cer לבין קובץ PEM .cer היא לפתוח את הקובץ בעורך טקסט ולחפש את ההצהרות של BEGIN ו-END. ניתן לקודד את כל סוגי האישורים והמפתחות הפרטיים בפורמט DER. DER משמש בדרך כלל עם פלטפורמות Java.
כינוי מפתח	כינוי מפתח מזהה באופן ייחודי ערך של מאגר מפתחות (אישור TLS ומפתח פרטי תואם) במאגר המפתחות. ב-Apigee Edge, KeyAlias נקרא alias כשמעלים את האישור/מפתח לחנויות המפתחות באמצעות ממשק המשתמש או ה-API.
מאגר מפתחות	מאגר מפתחות הוא מאגר שמכיל אישור TLS אחד או יותר ומפתח פרטי תואם, המשמש לזיהוי הישות במהלך לחיצת יד ב-TLS בין לקוח לשרת. בחיבור הצפון, הנתב פועל בתור השרת והאישור שלו מאוחסן במאגר המפתחות ב-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.
אישור בחתימה עצמית	אישור שלא חתום על ידי רשות אישורים מהימנה. המנפיק והנושא זהים. הם חתומים במפתח הפרטי שתואם למפתח הציבורי שהם כוללים.
SNI	שם השרת. המדיניות מאפשרת להציג כמה יעדי HTTPS מאותה כתובת IP ויציאה, בלי להשתמש ביעדים האלה באותו אישור.
אישור TLS	קובץ דיגיטלי שמזהה ישות בעסקת TLS (אבטחת שכבת התעבורה). אפשר להשתמש באישור או באישור כדי לזהות את שרת ה-TLS ולקוח ה-TLS, בהתאם לתצורת TLS.
Truststore	מכיל אישורים מהימנים בלקוח TLS המשמש לאימות האישור של שרת TLS המוצג ללקוח. האישורים האלה הם בדרך כלל אישורים בחתימה עצמית או אישורים שאינם חתומים על ידי CA מהימן. בחיבור הנורמלי, האישורים של אפליקציית הלקוח מאוחסנים ב-Trust Store ב-Apigee Edge. פעולה זו נדרשת רק אם הגדרת TLS דו-כיווני בין הלקוח לבין Apigee. בחיבור היציב, האישורים של שרת הקצה העורפי מאוחסנים בחנות מהימנה ב-Apigee Edge. צריך לעשות זאת אם רוצים לאמת את האישור של הקצה העורפי ב-Apigee Edge בתקשורת חד-כיוונית או דו-כיוונית של TLS בין Apigee Edge לבין השרת העורפי. ל-Apigee Edge אין אובייקט נפרד של חנות מהימנה. לכן, החנויות המהימנות נוצרות כאובייקט של מאגר מפתחות, אבל מפנות אליהן כמאגר מהימנות בכל מקום שבו משתמשים בהן (לדוגמה, במארח וירטואלי, בנקודות קצה (endpoint), בשרתי יעד וכו').
מארח וירטואלי	מארח וירטואלי מייצג את נקודת הקצה ל-API של Apigee לאפליקציות של הלקוח. היא ישות שעוזרת לארח שמות דומיינים מרובים (עם טיפול נפרד לכל שם) בשרת אחד (או מאגר שרתים אחד). כך אפשר לאפשר לשרת אחד לשתף את המשאבים שלו, למשל מחזורי זיכרון ומעבדים, בלי לדרוש מכל השירותים שבהם נעשה שימוש באותו שם מארח. מארח וירטואלי יכול להציג תנועה מסוג HTTP או HTTPS (תומך ב-SSL). ניתן להגדיר מארח וירטואלי תומך SSL במצב TLS חד-כיווני או דו-כיווני. הוא מוגדר באופן הבא: מארח אחד או יותר (שם DNS של נקודת קצה ל-API). נמל מאגר מפתחות כינוי מפתח לזיהוי ייחודי של אחד מאישורי השרת ב-Keystore. אופציונלי: מאגר מהימנות (ב-TLS דו-כיווני, שבו מופעל אימות לקוח).

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

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

בתצורה של TLS חד-כיווני, לחיצת היד מתבצעת כך:

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

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

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

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

• קצה כשרת TLS

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

• קצה כלקוח TLS

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

TLS דו-כיווני

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

ב-TLS דו-כיווני, לחיצת היד מתבצעת כך:

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

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

בתרחיש הזה, לחיצת היד מתבצעת כך:

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

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

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

• הגדרה כשרת

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

• קצה כלקוח

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

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

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

תמיכה ב-SNI

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

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

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

צפון ודרום

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

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

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