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

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

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

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

כך נראים שני סוגי הגישה:

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

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

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

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

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

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

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

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

• ‫myKeystoreRef הוא הפניה שמכילה את השם של מאגר המפתחות. בדוגמה הזו, שם מאגר המפתחות הוא myKeystore.
• ‫myTruststoreRef הוא הפניה שמכילה את השם של מאגר האישורים. בדוגמה הזו, השם של מאגר האישורים הוא myTruststore.

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

• ללקוחות Cloud: כדי לשנות את הערך של ההפניה, לא צריך לפנות לתמיכה של Apigee Edge.
• ללקוחות Private Cloud: שינוי הערך של ההפניה לא מחייב הפעלה מחדש של רכיבי Edge, כמו Routers ו-Message Processors.

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

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

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

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

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

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

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

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

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

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

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

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

1. Edge for the Cloud

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

2. Edge for the Private Cloud

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

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

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

אם יש לכם חשבון בתשלום של Edge for 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>.

מידע נוסף זמין במאמר בנושא הגדרת מארחים וירטואליים ל-Cloud.

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

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

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

אפשרויות להגדרת ענן וענן פרטי (Private Cloud)

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

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

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

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

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

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

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

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

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

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

אם תעודה בחנות מהימנות פגה, ואתם משתמשים בהפניה לחנות מהימנות, אתם:

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

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

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

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

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