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

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

שרת ה-proxy ל-API מתפקד כמיפוי של נקודת קצה (endpoint) זמינה לציבור אל השירות לקצה העורפי. מארח וירטואלי מגדיר את האופן שבו שרת ה-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) או לערוך אותו דרך ממשק המשתמש של ניהול Edge.

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

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 באמצעות הקצה העורפי.
7. מבצעים את השינויים ושומרים את שרת ה-Proxy. אם שרת ה-proxy ל-API נפרס, הוא נשמר תפרס אותו מחדש עם ההגדרה החדשה.

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

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

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

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

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

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

ראו איזון עומסים בשרתים עורפיים.

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

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

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

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

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

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

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

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

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

מידע נוסף זמין במאמר Keystores and Truststores.

לדוגמה:

<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 ממליץ מאוד להשתמש בהפניה למאגר המפתחות Truststore בהגדרה של TargetEndpoints או TargetServer. היתרון בשימוש בקובץ עזר צריך רק לעדכן את ההפניה כדי להפנות למאגר מפתחות אחר או למאגר זהויות אחר (Truststore) מעדכנים את אישור ה-TLS.

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

המרה של TargetEndpoint או TargetServer לשימוש בקובץ עזר

יכול להיות שיש לכם הגדרות קיימות של TargetEndpoint או TargetServer ש משתמש בשם המילולי של מאגר המפתחות ו-Truststore. כדי להמיר את נקודת הקצה (TargetEndpoint) או את ההגדרה של TargetServer כדי להשתמש בקובצי עזר:

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

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

כשמשתמשים בהגדרה של נקודת קצה (TargetEndpoint), הגדרה של גישת TLS חד-כיוונית מ-Edge (לקוח TLS) לשרת הקצה העורפי (שרת TLS) לא נדרשת הגדרה נוספת ב-Edge. זה כן עד לשרת העורפי כדי להגדיר 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 יאמת את אישור הקצה העורפי, צריך ליצור מאגר אמון שמכיל את הקצה העורפי של האישור או את שרשרת האישורים. לאחר מכן מציינים את ה-Truststore ההגדרה של נקודת הקצה (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. אם רוצים לאמת את האישור לקצה העורפי, צריך ליצור מאגר אמון ב-Edge ולהעלות את האישור העורפי או את שרשרת ה-CA, כפי שמתואר Keystores ו-Truststores בדוגמה הזו, אם צריך ליצור מאגר אישורים, נותנים לו שם myTrustStore.

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

   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 כדי לעדכן את ההגדרה של TargetEndpoint לשרת ה-proxy של ה-API (או, אם הגדרת את ה-proxy ל-API ב-XML, צריך לערוך את קובצי ה-XML של ה-Proxy:
   1. מתחברים לממשק המשתמש של ניהול Edge בכתובת https://enterprise.apigee.com.
   2. בתפריט Edge management UI, בוחרים באפשרות APIs.
   3. בוחרים את השם של ה-Proxy ל-API שרוצים לעדכן.
   4. לוחצים על הכרטיסייה פיתוח.
   5. בקטע Target Endpoints, בוחרים באפשרות default.
   6. באזור הקוד, עורכים את הרכיב <HTTPTargetConnection> כדי מוסיפים את הרכיב <SSLInfo>. חשוב לציין את ההפניה הנכונה ל-Truststore ולהגדיר את <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 ואת המפתח הפרטי.
• אם רוצים לתקף את האישור בקצה העורפי, יוצרים מאגר נתונים ל-Truststore ב-Edge שמכיל את שרשרת האישורים ו-CA שקיבלתם משרת הקצה העורפי.
• כדי להגדיר, מעדכנים את נקודת הקצה (TargetEndpoint) של כל שרתי ה-proxy ל-API שפונים לשרת הקצה העורפי גישה באמצעות TLS.

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

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

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

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

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

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

1. יוצרים את מאגר המפתחות ב-Edge ומעלים את האישור והמפתח הפרטי באמצעות התהליך שמתואר כאן: Keystores and Truststores. בדוגמה הזו, יוצרים מאגר מפתחות בשם 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.

   תוכלו להשתמש בקריאה הבאה ל-GET API כדי להציג את קובץ העזר:

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

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

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

   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 כדי לעדכן את ההגדרה של TargetEndpoint לשרת ה-proxy של ה-API (או, אם הגדרת את ה-proxy ל-API ב-XML, צריך לערוך את קובצי ה-XML של ה-Proxy:
   1. מתחברים לממשק המשתמש של ניהול Edge בכתובת https://enterprise.apigee.com.
   2. בתפריט Edge management UI, בוחרים באפשרות 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>, כולל שימוש במשתנים כדי לספק ערכי <SSLInfo> של TargetEndpoint, ראו מידע על הגדרות של שרת proxy ל-API.

הפעלת SNI

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

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