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

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

בקטע הזה נסביר איך להגדיר TLS לתעבורה משרת proxy ליעד.

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

יעד יכול להיות מיוצג על ידי אובייקט XML כמו זה שבהמשך:

<HTTPTargetConnection>
    <Properties/>
    <URL>https:myTargetAddress</URL>
    <SSLInfo>
        <Enabled>true</Enabled>
        <Enforce>true</Enforce>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <Protocols>myProtocols</Protocols>
        <Ciphers>myCipher</Ciphers>
    </SSLInfo>
</HTTPTargetConnection>

האזור בהגדרת נקודת הקצה של היעד שמשנים כדי להגדיר TLS מוגדר על ידי התג <SSLInfo>. משתמשים באותו תג <SSLInfo> כדי להגדיר נקודת קצה של יעד או שרת יעד.

למידע על רכיבי הצאצא של <SSLInfo>, ראו הגדרת TLS/SSL TargetEndpoint.

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

רכיב תיאור
<Enabled> אפשר להשתמש בבלוק <SSLInfo> גם ל-TLS/SSL חד-כיווני וגם ל-TLS/SSL דו-כיווני.

אם הערך הוא true, <Enabled> מציין שצריך להשתמש בחסימה <SSLInfo>. אם הערך הוא false, המערכת מתעלמת מהחסימה <SSLInfo>.

ערך ברירת המחדל של <Enabled> הוא true אם <URL> מציין את פרוטוקול HTTPS, ו-false אם <URL> מציין את פרוטוקול HTTP.
<Enforce>

אכיפה של SSL מחמיר בין Apigee לבין הקצה העורפי של היעד.

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

אם לא מוגדר ערך, או אם הערך הוא false, התוצאה של חיבורים לשרתי קצה בעורף עם אישורים בעייתיים תלויה בהגדרה של <IgnoreValidationErrors> (ראו בהמשך). תגובה של הצלחה (2xx) יכולה להתרחש בתנאים מסוימים, אם הערך של <IgnoreValidationErrors> מוגדר ל-true.
<ClientAuthEnabled>

המאפיין הזה מאפשר TLS דו-כיווני (שנקרא גם TLS הדדי או mTLS) בין Apigee לבין לקוח ה-API, או בין Apigee לבין קצה העורפי של היעד.

כדי להפעיל TLS דו-כיווני, בדרך כלל צריך להגדיר חנות אישורים ב-Apigee וחנות אישורים.
<KeyStore> מאגר מפתחות שמכיל מפתחות פרטיים שמשמשים לאימות לקוח יוצא
<KeyAlias> הכינוי שצוין כשמעלים אישור ומפתח פרטי למאגר המפתחות.
<TrustStore> מאגר מפתחות שמכיל אישורים מהימנים של שרתים.
<IgnoreValidationErrors>

מציין אם המערכת מתעלמת משגיאות אימות. אם מערכת ה-Backend משתמשת ב-SNI ומחזירה אישור עם שם נושא (DN) שלא תואם לשם המארח, אין אפשרות להתעלם מהשגיאה והחיבור נכשל.

הערה: אם הערך של <Enforce> הוא true, המערכת מתעלמת מהערך של <IgnoreValidationErrors>.
<Ciphers>

הצפנות נתמכות ל-TLS/SSL יוצא. אם לא מציינים צפנים, כל הצפנים שזמינים ל-JVM יהיו מותרים.

כדי להגביל את הצפנות, מוסיפים את הרכיבים הבאים עם רשימה של הצפנות נתמכות:

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>
<Protocols>

פרוטוקולים נתמכים ל-TLS/SSL יוצא. אם לא מציינים פרוטוקולים, כל הפרוטוקולים שזמינים ל-JVM מורשים.

כדי להגביל פרוטוקולים, צריך לציין אותם באופן מפורש. לדוגמה, כדי לאפשר רק TLS v1.2 או TLS v1.3:

<Protocols>
 <Protocol>TLSv1.2</Protocol>
 <Protocol>TLSv1.3</Protocol>
</Protocols>

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

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

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

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

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

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

כדי לשנות את ערך ההפניה, לא צריך לפנות אל Cloud Customer Care.

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

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

אם מציינים ישירות את השם של מאגר המפתחות או truststore, צריך לפנות אל Cloud Customer Care.

אפשרות שלישית היא להשתמש במשתני זרימה:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אם מדובר בחנות אישורים, יוצרים חנות אישורים עם שם חדש.

 מעדכנים את ההפניה למאגר המפתחות או למאגר האישורים.

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

אם מדובר בחנות אישורים, יוצרים חנות אישורים עם שם חדש.

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

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

אם מאגר המפתחות משמש ל-TLS דו-כיווני (שנקרא גם Mutual TLS או mTLS) בין Apigee לבין שירות לקצה העורפי, צריך לפנות Cloud Customer Care כדי להפעיל מחדש את מעבדי הבקשות.
ישיר אם משתמשים רק במאגר האישורים, מעלים אישור חדש למאגר האישורים. כדי להפעיל מחדש את המעבדים של ההודעות, צריך לפנות אל Cloud Customer Care.