מידע על 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, חשוב להכיר את המונחים והמושגים החשובים הבאים:

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

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

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

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

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

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

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

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

• הגדרה כשרת ה-TLS (אבטחת שכבת התעבורה)

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

• אות כלקוח TLS

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

TLS דו-כיווני

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

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

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

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

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

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

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

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

• סימון כשרת

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

• סימון כלקוח/ה

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

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

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

תמיכה ב-SNI

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

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

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

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

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

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

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