אפשרויות להגדרת TLS

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

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

1. גישה לשרתי API דרך לקוחות API. שימוש במארחים וירטואליים ב-Edge נתב להגדרת TLS.
2. גישה לשירותים לקצה העורפי באמצעות Edge. שימוש בנקודות קצה וביעד שרתים במעבד ההודעות של קצה כדי להגדיר TLS.

אלו שני סוגי הגישה:

מידע הגדרת אפשרויות TLS במארח וירטואלי או בשרת יעד/נקודת קצה (endpoint) יעד

אובייקט XML יכול לייצג מארח וירטואלי באמצעות:

<VirtualHost name="secure">
    ...
    <SSLInfo> 
        <Enabled>true</Enabled> 
        <ClientAuthEnabled>true</ClientAuthEnabled> 
        <KeyStore>ref://myKeystoreRef</KeyStore> 
        <KeyAlias>myKeyAlias</KeyAlias> 
        <TrustStore>ref://myTruststoreRef</TrustStore> 
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
    </SSLInfo>
</VirtualHost>

האזור של המארח הווירטואלי שאותו משנים כדי להגדיר TLS מוגדר על ידי התג <SSLInfo>. אתם משתמשים את אותו תג <SSLInfo> כדי להגדיר נקודת הקצה (endpoint) או שרת היעד של היעד.

הטבלה הבאה מתארת את רכיבי התצורה של TLS שמשמשים את התג <SSLInfo>:

<CommonName wildcardMatch="true">*.myhost.com</CommonName>

מידע על ההגדרה של &lt;KeyStore&gt; ו-<TrustStore> רכיבים

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

<KeyStore>ref://myKeystoreRef</KeyStore>
<TrustStore>ref://myTruststoreRef</TrustStore>

ב-Apigee מומלץ מאוד להשתמש תמיד בהפניות ל-Keystore ולמאגר האישורים. א' הפניה היא משתנה שמכיל את השם של מאגר המפתחות או ה-Truststore, שמציין את השם של מאגר המפתחות באופן ישיר. בדוגמה הזו:

• myKeystoreRef הוא קובץ עזר שמכיל את השם של מאגר מפתחות. בדוגמה הזו, השם של מאגר המפתחות הוא myKeystore.
• myTruststoreRef הוא קובץ עזר שמכיל את השם של ב-Truststore. בדוגמה הזו, השם של ה-Truststore הוא myTruststore.

כשפג התוקף של האישור, צריך לעדכן את המארח הווירטואלי או את שרת היעד/שרת היעד כך: לציין את ה-Keystore או ה-Truststore שמכילים את האישור החדש. היתרון של הפניה הוא אפשר לשנות את הערך של קובץ העזר כדי לשנות את מאגר המפתחות או ה-Truststore בלי שתצטרכו שינוי המארח הווירטואלי או נקודת הקצה (endpoint)/שרת היעד עצמו:

• ללקוחות Cloud: שינוי הערך של קובץ העזר לא מחייב צריך לפנות לתמיכה של Apigee Edge.
• ללקוחות 'ענן פרטי': שינוי הערך של קובץ העזר לא תצטרכו להפעיל מחדש את רכיבי Edge, כמו נתבים ומעבדי הודעות.

לחלופין, אפשר לציין את השם של מאגר המפתחות ואת השם של ה-Truststore באופן ישיר:

<KeyStore>myKeystore</KeyStore>
<TrustStore>myTruststore</TrustStore> 

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

אפשרות שלישית, לנקודות קצה (endpoints) או לשרת יעד בלבד, היא להשתמש במשתני זרימה:

<KeyStore>{ssl.keystore}</KeyStore>
<TrustStore>{ssl.truststore}</TrustStore> 

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

הגבלות על השימוש הפניות ל-Keystores ו-Truststore

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

• אפשר להשתמש בהפניות של מאגר מפתחות ומאגרי אמון במארחים וירטואליים רק אם לסיים את השימוש ב-TLS בנתבים של Apigee.

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

אם המארח הווירטואלי הקיים משתמש בשם מילולי של מאגר מפתחות או מאגר אמון

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

1. קצה לקצה לענן

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

2. קצה לקצה לענן הפרטי

   כדי להמיר את המארח הווירטואלי לשימוש בהפניה:

   1. מעדכנים את המארח הווירטואלי כדי להשתמש בהפניה.
   2. מפעילים מחדש את הנתבים.
   מידע נוסף מופיע בקטע 'שינוי מארח וירטואלי כך שישתמש בהפניות ל-Keystore ו-Truststore' בהגדרת גישת TLS API לענן הפרטי לקבלת מידע נוסף.

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

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

אובייקט XML שמגדיר את המארח הווירטואלי באמצעות אישור תקופת הניסיון בחינם של Apigee והמפתח משמיט את <KeyStore> ו-<KeyAlias>, ומחליפים אותם ב- רכיב <UseBuiltInFreeTrialCert>, כפי שמוצג בהמשך:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>myapi.apigee.net</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
    </SSLInfo>
    <UseBuiltInFreeTrialCert>true</UseBuiltInFreeTrialCert>
</VirtualHost>

גם אם אתם מבצעים TLS דו-כיווני, עדיין צריך להגדיר את הרכיב <ClientAuthEnabled> כ- true, ומציינים מאגר אמון באמצעות הפניה עם הרכיב <TrustStore>.

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

מידע על הגדרת TLS

יש שני גורמים עיקריים שקובעים את אופן השימוש ב-TLS (אבטחת שכבת התעבורה):

• האם אתם לקוחות של Edge Cloud או Private Cloud?
• איך בכוונתך לעדכן אישורים שפג תוקפם או שתוקפם עומד לפוג?

הגדרת התצורה בענן ובענן פרטי אפשרויות

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

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

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

טיפול באישורים שהתוקף שלהם פג

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

כשפג תוקף אישור

ב-Edge, יש לשמור אישורים באחד משני מקומות:

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

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

1. יצירת מאגר מפתחות חדש.
2. מעלים את האישור החדש למאגר המפתחות החדש באמצעות אותו שם חלופי כמו ב- מאגר המפתחות הישן.
3. מעדכנים את קובץ העזר במארח הווירטואלי או בשרת היעד/בנקודת הקצה של היעד כדי להשתמש בגרסה החדשה מאגר מפתחות.

כשפג התוקף של אישור בחנות מהימנה, ומשתמשים בהפניה truststore, אתם:

1. יצירת מאגר אמון חדש.
2. צריך להעלות את האישור החדש ל-Truststore החדש. הכינוי לא חשוב ל-Truststores. הערה: אם אישור הוא חלק משרשרת, צריך ליצור קובץ יחיד שכוללים את כל האישורים, ומעלים את הקובץ הזה לכתובת אימייל חלופית אחת, או מעלים את כל האישורים רשת בנפרד ל-Truststore באמצעות כינוי שונה לכל אישור.
3. מעדכנים את קובץ העזר במארח הווירטואלי או בשרת היעד/בנקודת הקצה של היעד כדי להשתמש בגרסה החדשה ב-Truststore.

סיכום של שיטות לעדכון התוקף אישור

השיטה שבה משתמשים כדי לציין את השם של מאגר המפתחות וה-Truststore במארח הווירטואלי או יעד שרת היעד/שרת היעד קובע את האופן שבו מתבצע עדכון האישור. אתם יכולים להשתמש:

• קובצי עזר
• שמות ישירים
• משתני זרימה

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