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

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

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

1. גישה לשרתי ה-API של לקוחות ה-API. שימוש במארחים וירטואליים ב-Edge Router כדי להגדיר TLS.
2. גישה לשירותים לקצה העורפי באמצעות Edge. שימוש בנקודות קצה ושרתי יעד במעבד ההודעות של 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>

מידע על הגדרת הרכיבים <KeyStore> ו-<TrustStore>

בדוגמה של המארח הווירטואלי שלמעלה, מאגר המפתחות ו-Truststore מצוינים באמצעות references, בצורה הבאה:

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

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

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

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

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

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

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

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

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

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

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

הגבלות על השימוש בהפניות למאגרי מפתחות ול-Truststore

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

• אפשר להשתמש בהפניות של מאגר מפתחות ו-Truststore במארחים וירטואליים רק אם סוגרים את ה-TLS (אבטחת שכבת התעבורה) בנתבי Apigee.

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

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

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

1. Edge for Cloud

   כדי לשנות את המארח הווירטואלי לשימוש בהפניה למאגר המפתחות, צריך לעבוד עם התמיכה של 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 באמצעות הפניה עם האלמנט <TrustStore>.

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

מידע על הגדרת TLS (אבטחת שכבת התעבורה)

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

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

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

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

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

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

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

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

מתי התוקף של האישור פג

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

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

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

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

כשפג התוקף של אישור ב-Truststore ואתם משתמשים בהפניה ל-Truststore:

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

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

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

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

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