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

אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info

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

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

שני סוגי הגישה האלה מוצגים בהמשך:

מידע על הגדרת אפשרויות 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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Edge לענן

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

2. Edge לענן הפרטי

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

   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?
• איך תעדכנו אישורים שפג תוקפם או שפג תוקפם בקרוב?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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