מחסנים

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

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

מידע נוסף:

מידע על מאגרי מפתחות ומאגרי אישורים

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

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

    ב-TLS חד-כיווני, כשלקוח מתחבר לנקודת הקצה של TLS בשרת, מאגר המפתחות של השרת מציג ללקוח את האישור של השרת (אישור ציבורי). הלקוח מאמת את האישור באמצעות רשות אישורים (CA), כמו Symantec או VeriSign.

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

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

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

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

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

שימוש באישור ובמפתח של תקופת הניסיון בחינם של Apigee בענן

לכל הארגונים בתקופת הניסיון בחינם ב-Cloud, ‏ Apigee מספק אישור ומפתח לתקופת ניסיון בחינם. ארגונים בתקופת ניסיון בחינם יכולים להשתמש באישור ובמפתח שמוגדרים כברירת מחדל כדי לבדוק ממשקי API, ואפילו להעביר ממשקי API לסביבת הייצור.

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

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

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

ההבדלים בין ענן לבין ענן פרטי

בגרסת הענן של Edge ובגרסאות Private Cloud 4.18.01 ואילך יש יכולות מורחבות לעבודה עם מאגרי מפתחות ומאגרי אישורים שלא זמינות בגרסאות Private Cloud 4.17.09 ואילך. לדוגמה, אתם יכולים:

  • שימוש בממשק המשתמש של Edge ליצירת מאגרי מפתחות ומאגרי אישורים
  • שימוש בקבוצה חדשה של ממשקי API לניהול מאגרי מפתחות ומאגרי אישורים

כשעובדים עם מאגרי מפתחות ומאגרי אישורים, חשוב להשתמש בקטע הנכון במסמכי התיעוד: