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

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

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

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

מידע נוסף:

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

הגדרת TargetEndpoint או TargetServer

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

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

1. מתחברים לממשק המשתמש לניהול Edge בכתובת https://enterprise.apigee.com.
2. בוחרים את השם של שרת ה-API של שרת ה-API שרוצים לעדכן.
3. לוחצים על הכרטיסייה פיתוח.
4. בקטע Target Endpoints, בוחרים באפשרות ברירת מחדל.
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. אם שרת ה-API של ה-API נפרס, השמירה שלו תגרום לפריסה שלו מחדש עם ההגדרה החדשה.

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

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

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

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

הגדרת מאגר מהימנות (Truststore) כדי להפעיל אימות אישורים

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

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

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

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

למידע נוסף, אפשר לקרוא על Keystores ו-Truststores.

לדוגמה:

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

שימוש בהפניה ל-Keystore או ל-Truststore

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

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

הפניות ל-Keystores ול-Truststores ב-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. אם יצרת מאגר מהימנות,השתמש בקריאה הבאה ל-API של POST כדי ליצור את ההפניה בשם 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, בוחרים באפשרות APIs.
   3. בוחרים את השם של שרת ה-API של שרת ה-API שרוצים לעדכן.
   4. לוחצים על הכרטיסייה פיתוח.
   5. בקטע Target Endpoints, בוחרים באפשרות ברירת מחדל.
   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. שומרים את שרת ה-API של שרת ה-API. אם שרת ה-API של ה-API נפרס, הוא יישמר שוב ושוב לפי ההגדרה החדשה.

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

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

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

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

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

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

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

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

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

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

2. משתמשים בקריאה הבאה ל-API של POST כדי ליצור את קובץ העזר בשם 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 ולהעלות את האישור ואת רשת ה-CA, כפי שמתואר כאן: Keystores and Truststores. בדוגמה הזו, אם צריך ליצור שם ל-Truststore, הוא הוא myTrustStore.

4. אם יצרת מאגר מהימנות,השתמש בקריאה הבאה ל-API של POST כדי ליצור את ההפניה בשם 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, בוחרים באפשרות APIs.
   3. בוחרים את השם של שרת ה-API של שרת ה-API שרוצים לעדכן.
   4. לוחצים על הכרטיסייה פיתוח.
   5. בקטע Target Endpoints, בוחרים באפשרות ברירת מחדל.
   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. שומרים את שרת ה-API של שרת ה-API. אם שרת ה-API של ה-API נפרס, הוא יישמר שוב ושוב לפי ההגדרה החדשה.

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

הפעלת SNI

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

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