הגדרת TLS מ-Edge לקצה העורפי (Cloud ו-Private Cloud)

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

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

האלמנט TargetEndpoint הוא המקבילה היוצאת של ProxyEndpoint. ‫TargetEndpoint פועל כלקוח HTTP מ-Edge לשירות קצה עורפי. כשיוצרים proxy ל-API, אפשר להגדיר אותו כך שישתמש באפס או יותר TargetEndpoints.

מידע נוסף:

• מידע על TLS/SSL
• שימוש ב-TLS עם Edge
• מידע על מארחים וירטואליים
• מאגרי מפתחות ומאגרי אישורים
• הפניית הגדרות של proxy ל-API

הגדרת TargetEndpoint או TargetServer

כדי להגדיר TargetEndpoint, עורכים את אובייקט ה-XML שמגדיר את TargetEndpoint. אפשר לערוך את TargetEndpoint על ידי עריכת קובץ ה-XML שמגדיר את TargetEndpoint ב-proxy ל-API, או לערוך אותו בממשק ניהול Edge.

כדי להשתמש בממשק המשתמש של Edge לניהול כדי לערוך את TargetEndpoint:

1. מתחברים לממשק ניהול Edge בכתובת https://enterprise.apigee.com.
2. בוחרים את השם של proxy ל-API שרוצים לעדכן.
3. בוחרים בכרטיסייה פיתוח.
4. בקטע Target Endpoints (נקודות קצה של יעד), בוחרים באפשרות default (ברירת מחדל).
5. באזור הקוד, מופיעה ההגדרה TargetEndpoint, בדומה לזו שבהמשך:

   <TargetEndpoint name="default">
     <Description/>
     <FaultRules/>
     <Flows/>
     <PreFlow name="PreFlow">
       <Request/>
       <Response/>
     </PreFlow>
     <PostFlow name="PostFlow">
       <Request/>
       <Response/>
     </PostFlow>
     <HTTPTargetConnection>
       <Properties/>
       <SSLInfo>
         <Enabled>true</Enabled>
         <TrustStore>ref://myTrustStoreRef</TrustStore>
       </SSLInfo>
       <URL>https://mocktarget.apigee.net</URL>
     </HTTPTargetConnection>
   </TargetEndpoint>

6. מגדירים מאגר אישורים מהימנים כמו שמתואר בהמשך בקטע מידע על הגדרת TLS עם ה-Backend.
7. מבצעים את השינויים הרצויים ושומרים את השרת הפרוקסי. אם proxy ל-API נפרס, שמירתו תגרום לפריסה מחדש שלו עם ההגדרה החדשה.

שימו לב שההגדרה של TargetEndpoint מכילה את המאפיין name. משתמשים בערך של המאפיין name כדי להגדיר את ההגדרה של ProxyEndpoint של proxy ל-API לשימוש ב-TargetEndpoint. מידע נוסף זמין במאמר בנושא הפניית הגדרות של שרת proxy ל-API.

אפשר להגדיר את TargetEndpoints כך שיפנו אל TargetServer, במקום אל כתובת ה-URL המפורשת של היעד. הגדרת TargetServer מפרידה בין כתובות URL קונקרטיות של נקודות קצה לבין הגדרות TargetEndpoint. השימוש ב-TargetServers מאפשר איזון עומסים ומעבר לגיבוי (failover) בין כמה מופעים של שרתים לקצה העורפי.

בדוגמה הבאה מוצגת הגדרה של TargetServer:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer> 

ההפניה ל-TargetServer נעשית לפי שם ברכיב <HTTPTargetConnection> בהגדרה של TargetEndpoint. אפשר להגדיר שרת יעד אחד או יותר עם שם, כמו בדוגמה הבאה.

<TargetEndpoint name="default">
  ...
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
  ...
</TargetEndpoint>

מידע נוסף זמין במאמר בנושא איזון עומסים בין שרתי בק-אנד.

מידע על הגדרת TLS עם הקצה העורפי

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

1. כברירת מחדל, דפדפן Edge לא מאמת את האישור של ה-Backend. כדי להגדיר את Edge לאימות האישור, צריך ליצור מאגר אישורים מהימן.
2. משתמשים בהפניה כדי לציין את מאגר המפתחות או מאגר האישורים שמשמשים את Edge.

שני השיקולים האלה מתוארים בהמשך.

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

כשמבצעים בקשת TLS דרך TargetEndpoint או TargetServer, ‏ Edge לא מאמת כברירת מחדל את אישור ה-TLS שמתקבל משרת הקצה העורפי. המשמעות היא ש-Edge לא מאמת את הדברים הבאים:

• האישור נחתם על ידי רשות אישורים מהימנה.
• האישור בתוקף.
• באישור מופיע שם פרטי. אם יש שם נפוץ, Edge לא מאמת שהשם הנפוץ תואם לשם המארח שצוין בכתובת ה-URL.

כדי להגדיר את Edge לאימות האישור של הקצה העורפי, צריך:

1. יוצרים מאגר אישורים ב-Edge.
2. מעלים את אישור השרת או את שרשרת האישורים למאגר האישורים המהימנים. אם אישור השרת נחתם על ידי צד שלישי, צריך להעלות את שרשרת האישורים המלאה, כולל אישור ה-CA הבסיסי, אל מאגר האישורים. אין רשויות אישורים שמהימנות עליהן מובלעת.
3. מוסיפים את מאגר האישורים להגדרה של TargetEndpoint או TargetServer.

מידע נוסף זמין במאמר בנושא מאגרי מפתחות ומאגרי אישורים.

לדוגמה:

<TargetEndpoint name="default">
  …
  <HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
      <TrustStore>ref://myTrustStoreRef</TrustStore>
    </SSLInfo>
    <URL>https://myservice.com</URL>
  </HTTPTargetConnection>
  …
</TargetEndpoint>

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

בדוגמה הבאה מוצג איך להגדיר TargetEndpoint או TargetServer כדי לתמוך ב-TLS. כחלק מהגדרת TLS, מציינים truststore ו-keystore כחלק מההגדרה של TargetEndpoint או TargetServer.

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

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

המרת TargetEndpoint או TargetServer לשימוש בהפניה

יכול להיות שיש לכם הגדרות קיימות של TargetEndpoint או TargetServer שמשתמשות בשם המילולי של מאגר המפתחות ומאגר האישורים. כדי להמיר את ההגדרה של TargetEndpoint או TargetServer לשימוש בהפניות:

1. מעדכנים את ההגדרה של TargetEndpoint או TargetServer כדי להשתמש בהפניה.
2. מפעילים מחדש את מעבדי ההודעות של Edge:
   • לקוחות בענן ציבורי צריכים ליצור קשר עם התמיכה של Apigee Edge כדי להפעיל מחדש את מעבדי ההודעות.
   • לקוחות Private Cloud צריכים להפעיל מחדש את מעבדי ההודעות של Edge אחד בכל פעם.
3. מוודאים שרכיב TargetEndpoint או TargetServer פועל בצורה תקינה.

הגדרת TLS חד-כיווני לשרת הקצה העורפי

כשמשתמשים בהגדרה של TargetEndpoint, לא נדרשת הגדרה נוספת ב-Edge כדי להגדיר גישה חד-כיוונית ל-TLS מ-Edge (לקוח TLS) לשרת העורפי (שרת TLS). ההגדרה של TLS בצורה נכונה היא באחריות שרת הקצה העורפי.

צריך רק לוודא שהרכיב <URL> בהגדרה של TargetEndpoint מפנה לשירות לקצה העורפי באמצעות פרוטוקול HTTPS, ושהפעלתם TLS:

<TargetEndpoint name="default">
  …
  <HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <URL>https://myservice.com</URL>
  </HTTPTargetConnection>
  …
</TargetEndpoint>

אם אתם משתמשים ב-TargetServer כדי להגדיר את שירות הקצה העורפי, אתם צריכים להפעיל TLS בהגדרה של TargetServer:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
    <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer> 

עם זאת, אם רוצים ש-Edge יאמת את אישור ה-Backend, צריך ליצור truststore שמכיל את אישור ה-Backend או את שרשרת האישורים. לאחר מכן מציינים את מאגר האישורים בהגדרה של TargetEndpoint:

<TargetEndpoint name="default">
  …
  <HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
      <TrustStore>ref://myTrustStoreRef</TrustStore>
    </SSLInfo>
    <URL>https://myservice.com</URL>
  </HTTPTargetConnection>
  …
</TargetEndpoint>

או בהגדרה של TargetServer:

<TargetServer name="target1">
  <Host>mockserver.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
    <Enabled>true</Enabled>
    <TrustStore>ref://myTrustStoreRef</TrustStore>
  </SSLInfo> 
</TargetServer>

כדי להגדיר TLS חד-כיווני:

1. אם רוצים לאמת את אישור ה-backend, צריך ליצור מאגר אישורים מהימן ב-Edge ולהעלות את אישור ה-backend או את שרשרת ה-CA, כמו שמתואר במאמר Keystores and Truststores. בדוגמה הזו, אם צריך ליצור truststore, צריך לתת לו את השם myTrustStore.

2. אם יצרתם מאגר אישורים,משתמשים בקריאה הבאה ל-API מסוג POST כדי ליצור את ההפניה בשם myTrustStoreRef למאגר האישורים שיצרתם למעלה:

   curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
     -d '<ResourceReference name="myTrustStoreRef">
       <Refers>myTrustKeystore</Refers>
       <ResourceType>KeyStore</ResourceType>
     </ResourceReference>' -u email:password
   

3. משתמשים בממשק המשתמש של Edge Management כדי לעדכן את ההגדרה של TargetEndpoint עבור שרת ה-API (או, אם מגדירים את שרת ה-API ב-XML, עורכים את קובצי ה-XML של השרת):
   1. מתחברים לממשק המשתמש לניהול Edge בכתובת https://enterprise.apigee.com.
   2. בתפריט של ממשק המשתמש לניהול Edge, בוחרים באפשרות APIs.
   3. בוחרים את השם של proxy ל-API שרוצים לעדכן.
   4. בוחרים בכרטיסייה פיתוח.
   5. בקטע Target Endpoints (נקודות קצה של יעד), בוחרים באפשרות default (ברירת מחדל).
   6. באזור הקוד, עורכים את הרכיב <HTTPTargetConnection> כדי להוסיף את הרכיב <SSLInfo>. חשוב לציין את ההפניה הנכונה למאגר האישורים ולהגדיר את <Enabled> לערך true:

      <TargetEndpoint name="default">
        …
        <HTTPTargetConnection>
          <SSLInfo>
            <Enabled>true</Enabled>
            <TrustStore>ref://myTrustStoreRef</TrustStore>
          </SSLInfo>
          <URL>https://myservice.com</URL>
        </HTTPTargetConnection>
        …
      </TargetEndpoint>

   7. שומרים את ה-proxy ל-API. אם proxy ל-API נפרס, שמירתו תגרום לפריסה מחדש שלו עם ההגדרה החדשה.

הגדרת TLS דו-כיווני לשרת הקצה העורפי

אם רוצים לתמוך ב-TLS דו-כיווני בין Edge (לקוח TLS) לבין שרת הקצה העורפי (שרת TLS):

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

שימוש בכינוי המפתח כדי לציין את אישור מאגר המפתחות

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

אופציונלי: אתם יכולים להגדיר את Edge כך שישתמש באישור שצוין על ידי המאפיין <KeyAlias>. כך אפשר להגדיר מאגר מפתחות יחיד לכמה אישורים, ואז לבחור את האישור שרוצים להשתמש בו בהגדרת TargetServer. אם Edge לא מוצא אישור עם כינוי שמתאים ל-<KeyAlias>, הוא משתמש בפעולה שמוגדרת כברירת מחדל של בחירת האישור הראשון במאגר המפתחות.

משתמשי Edge for Public Cloud צריכים לפנות אל התמיכה של Apigee Edge כדי להפעיל את התכונה הזו.

הגדרת TLS דו-כיווני

כדי להגדיר TLS דו-כיווני:

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

2. משתמשים בקריאה הבאה ל-POST API כדי ליצור את ההפניה בשם myKeyStoreRef למאגר המפתחות שיצרתם למעלה:

   curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
   -d '<ResourceReference name="myKeyStoreRef">
       <Refers>myTestKeystore</Refers>
       <ResourceType>KeyStore</ResourceType>
   </ResourceReference>' -u email:password
   

   ההפניה מציינת את השם של מאגר המפתחות ואת סוג ההפניה כ-KeyStore.

   כדי לראות את ההפניה, משתמשים בקריאה הבאה ל-API מסוג GET:

   curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/myKeyStoreRef /
   -u email:password
   

3. אם רוצים לאמת את האישור של השרת העורפי, צריך ליצור חנות מהימנות ב-Edge ולהעלות את האישור ואת שרשרת רשויות האישורים, כמו שמתואר כאן: Keystores and Truststores. בדוגמה הזו, אם צריך ליצור חנות מהימנות, צריך לתת לה את השם myTrustStore.

4. אם יצרתם מאגר אישורים,משתמשים בקריאה הבאה ל-API מסוג POST כדי ליצור את ההפניה בשם myTrustStoreRef למאגר האישורים שיצרתם למעלה:

   curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
   -d '<ResourceReference name="myTrustStoreRef">
       <Refers>myTrustKeystore</Refers>
       <ResourceType>KeyStore</ResourceType>
   </ResourceReference>' -u email:password
   

5. משתמשים בממשק המשתמש של Edge Management כדי לעדכן את ההגדרה של TargetEndpoint עבור שרת ה-API (או, אם מגדירים את שרת ה-API ב-XML, עורכים את קובצי ה-XML של השרת):
   1. מתחברים לממשק ניהול Edge בכתובת https://enterprise.apigee.com.
   2. בתפריט של ממשק המשתמש לניהול Edge, בוחרים באפשרות APIs.
   3. בוחרים את השם של proxy ל-API שרוצים לעדכן.
   4. בוחרים בכרטיסייה פיתוח.
   5. בקטע Target Endpoints (נקודות קצה של יעד), בוחרים באפשרות default (ברירת מחדל).
   6. באזור הקוד, עורכים את הרכיב <HTTPTargetConnection> כדי להוסיף את הרכיב <SSLInfo>. חשוב לציין את חנות המפתחות הנכונה ואת הכינוי של המפתח, ולהגדיר את הרכיבים <Enabled> ו-<ClientAuthEnabled> לערך true:

      <TargetEndpoint name="default">
        ...
        <HTTPTargetConnection>
          <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeyStoreRef</KeyStore>
            <KeyAlias>myKey</KeyAlias>
          </SSLInfo>
          <URL>https://myservice.com</URL>
        </HTTPTargetConnection>
        ...
      </TargetEndpoint>

   7. שומרים את ה-proxy ל-API. אם proxy ל-API נפרס, שמירתו תגרום לפריסה מחדש שלו עם ההגדרה החדשה.

מידע נוסף על האפשרויות שזמינות ב-<TargetEndpoint>, כולל שימוש במשתנים כדי לספק ערכים של TargetEndpoint <SSLInfo>, זמין במאמר הפניה להגדרת proxy ל-API.

הפעלת SNI

‫Edge תומך בשימוש ב-Server Name Indication‏ (SNI) ממעבדי הודעות כדי לטרגט נקודות קצה ב-Apigee Edge for Cloud ובפריסות של Private Cloud.

ב-Edge for the Private Cloud, כדי לשמור על תאימות לאחור עם שרתים עורפיים קיימים, Apigee משביתה את SNI כברירת מחדל. אם ה-backend של היעד מוגדר לתמיכה ב-SNI, אפשר להפעיל את התכונה הזו. מידע נוסף מופיע במאמר בנושא שימוש ב-SNI עם Edge.