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

בדוגמה הזו:

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

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

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

<KeyStore>myKeystore</KeyStore>
<TrustStore>myTruststore</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).

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

סוג ההגדרה	איך מעדכנים או מחליפים אישור	שימוש / השפעה
הפניה (מומלץ)	מאגר מפתחות: יוצרים מאגר מפתחות חדש עם שם חדש וכינוי עם אותו שם כמו הכינוי הישן. מאגר אישורים: יוצרים מאגר אישורים עם שם חדש. שם הכינוי לא משנה. הערה: אם אישור הוא חלק משרשרת, צריך ליצור קובץ יחיד שמכיל את כל האישורים ולהעלות אותו לכינוי יחיד, או להעלות את כל האישורים בשרשרת בנפרד למאגר האישורים המהימנים באמצעות כינוי שונה לכל אישור.	מעדכנים את ההפניה כך שתצביע על החנות החדשה. אין צורך לפנות לתמיכה של Apigee. ללא זמן השבתה.
משתנה זרימה	מאגר מפתחות: יוצרים מאגר מפתחות חדש עם שם חדש וכינוי עם אותו שם או שם חדש. מאגר אישורים: יוצרים מאגר אישורים עם שם חדש.	מעבירים את משתנה התהליך המעודכן בכל בקשה עם שם החנות החדשה. אין צורך לפנות לתמיכה של Apigee. ללא זמן השבתה.
ישיר	שיטה 1: יצירת חנות חדשה (מומלץ כדי למנוע השבתה) יוצרים מאגר מפתחות או מאגר אישורים חדש עם שם חדש ומעלים את האישור החדש (ואת המפתח הפרטי אם יוצרים מאגר מפתחות).	מעדכנים את נקודת הקצה או את הגדרות שרת היעד כדי לציין ישירות את שם החנות החדש, ואז פורסים מחדש את proxy ל-API. אין צורך לפנות לתמיכה של Apigee.
ישיר	שיטה 2א: עדכון במקום (מחיקה ויצירה מחדש) מוחקים את מאגר המפתחות או את מאגר האישורים ויוצרים אותו מחדש עם אותו שם.	בקשות ל-API ייכשלו במהלך חלון הזמנים של המחיקה והיצירה מחדש. מעבדי ההודעות שומרים במטמון חנויות שצוינו ישירות, ולכן הם לא יזהו אוטומטית את האישור המעודכן. צריך לפנות אל Cloud Customer Care כדי להפעיל מחדש את המעבדים של ההודעות.
ישיר	שיטה 2ב: עדכון במקום (העלאה של מאגר האישורים) במקרה של truststores בלבד, מעלים אישור חדש ישירות ל-truststore הקיים.	מעבדי הודעות שומרים במטמון חנויות שצוינו ישירות, ולכן הם לא יזהו את האישור החדש באופן אוטומטי. צריך לפנות אל Cloud Customer Care כדי להפעיל מחדש את המעבדים של ההודעות.