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

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

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

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

גרסאות TLS שלא נתמכות:‏ Apigee לא תומך בשימוש ב-TLS 1.0 או ב-TLS 1.1. אם משתמשים בפרוטוקולים האלה בהגדרת נקודת הקצה של היעד, נקודת הקצה של היעד ב-Apigee מחזירה את השגיאה messaging.adaptors.http.flow.SslHandshakeFailed.

מידע על הגדרת אפשרויות 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>, ראו הגדרת TargetEndpoint של TLS/SSL.

בטבלה הבאה מתוארים רכיבי ההגדרה של 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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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