מחסנים

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

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

מידע נוסף:

מידע על מאגרי מפתחות ו-Truststores

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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