הגדרת גישת TLS ל-API עבור הענן הפרטי

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

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

מארח וירטואלי גם מגדיר אם ניתן לגשת לשרת ה-proxy של ה-API באמצעות פרוטוקול HTTP, או באמצעות פרוטוקול HTTPS המוצפן שמשתמש ב-TLS. כשמגדירים מארח וירטואלי לשימוש ב-HTTPS וב- TLS, יוצרים מארח וירטואלי ב-Edge ומגדירים שהמארח הווירטואלי ישתמש במאגר מפתחות ו- Truststore.

מידע נוסף:

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

מה צריך כדי ליצור מארח וירטואלי

לפני שיוצרים מארח וירטואלי, צריך לספק את הפרטים הבאים:

• שם הדומיין שגלוי לכולם של המארח הווירטואלי. לדוגמה, צריך לדעת אם השם שגלוי לכולם הוא api.myCompany.com, myapi.myCompany.com, וכו'. המידע הזה משמש ליצירת המארח הווירטואלי וגם כשיוצרים את רשומת ה-DNS עבור מארח וירטואלי.
• לפרוטוקול TLS חד-כיווני, יש ליצור מאגר מפתחות שבו מאגר המפתחות כולל הבאים:
  • אישור TLS – אישור שחתום על ידי רשות אישורים (CA), או שרשרת אישורים שבה האישור האחרון חתום על ידי רשות אישורים.
  • מפתח פרטי – Edge תומך בגדלי מפתחות של עד 2,048 ביט. ביטוי סיסמה הוא אופציונלי.
• ל-TLS דו-כיווני צריך מאגר מפתחות, וצריך מאגר אמון שיכיל את האישור של הלקוח, ובאופן אופציונלי, גם שרשרת ה-CA של האישור. צריך את ה-Truststore גם אם האישור חתום על ידי CA.

למידע נוסף, ראו Keystores ו- Truststores – מידע נוסף על יצירת מאגרי מפתחות ומאגרים של אמינות (Truststores).

הגדרת מארח וירטואלי ל-TLS (אבטחת שכבת התעבורה)

כדי ליצור מארח וירטואלי, יוצרים אובייקט XML שמגדיר את המארח הווירטואלי. אובייקט ה-XML הבא משתמש ברכיב <SSLInfo> כדי להגדיר מארח להגדרת TLS חד-כיוונית ב-HTTPS:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>apiTLS.myCompany.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9006</Port>
    <OCSPStapling>off</OCSPStapling>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>ref://myTestKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
</VirtualHost>

בדוגמה זו, הרכיב <Enabled> מוגדר כ-true כשמפעילים TLS חד-כיווני, והרכיבים <KeyStore> ו-KeyAlias> מציינים את מאגר המפתחות והמפתח המשמשים את חיבור TLS.

כדי להפעיל TLS דו-כיווני, צריך להגדיר את הרכיב <ClientAuthEnabled> כ- true, וציון ה-Truststore באמצעות <TrustStore> לרכיב מסוים. ה-Truststore מחזיק באישור של הלקוח, ובאופן אופציונלי, גם את ה-CA של האישור. או שרשרת אספקה.

מחליטים איך לציין את השם של מאגר המפתחות ושל מאגר האישורים במארח הווירטואלי

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

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

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

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

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

• אפשר להשתמש בהפניות של מאגר מפתחות ומאגרי אמון במארחים וירטואליים רק אם יש תמיכה ב-SNI וב- כשמסיימים את ה-SSL בנתבי Apigee.
• אם יש מאזן עומסים מול נתבי Apigee, ומסיימים את השימוש ב-TLS אז לא ניתן להשתמש בהפניות של מאגר מפתחות ומאגרי אמון המארחים.

שינוי מארח וירטואלי קיים כך שישתמש בהפניות למאגר המפתחות ולמאגר ה-Truststore

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

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

הגדרת הצפנות והפרוטוקולים של TLS ל-Edge 4.15.07 ודגמים קודמים

אם אתם משתמשים ב-Edge גרסה 4.15.07 ומטה, אתם צריכים להגדיר את פרוטוקול TLS ואת הצפנים. בשימוש של המארח הווירטואלי באמצעות תגי הצאצא <Ciphers> ו-<Protocols> של תג <SSLInfo>. התגים האלה מתוארים בטבלה הבאה.

לדוגמה:

    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>myTestKeystore</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>false</ClientAuthEnabled>
            <KeyStore>myTestKeystore</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <Ciphers>
                <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</Cipher>
                <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</Cipher>
            </Ciphers>
            <Protocols>
                <Protocol>TLSv1.2</Protocol>
            </Protocols>
        </SSLInfo>
   </SSLInfo>

התג <Cipher> משתמש את שם ה-Java וה-JSSE של ההצפנה. לדוגמה, עבור Java 8 ראה http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites.

ציון הצפנות והפרוטוקולים של TLS עבור Edge מגרסה 4.16.01 עד 4.16.09

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

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

• כדי לציין את הפרוטוקולים שמוגדרים כברירת המחדל, צריך להשתמש באסימון conf_load_balancing_load.balancing.driver.server.ssl.protocols
• כדי לציין את הצפנים שמוגדרים כברירת המחדל של הנתב, משתמשים באסימון conf_load_balancing_load.balancing.driver.server.ssl.ciphers

ערך ברירת המחדל של האסימון conf_load_balancing_load.balancing.driver.server.ssl.protocols היא:

conf_load_balancing_load.balancing.driver.server.ssl.protocols=TLSv1 TLSv1.1 TLSv1.2

ההגדרה הזו מציינת שהנתב תומך ב-TLS בגרסאות 1.0, 1.1 ו-1.2. ציון רשימת ערכים מופרדת ברווחים באסימון.

ערך ברירת המחדל של האסימון conf_load_balancing_load.balancing.driver.server.ssl.ciphers היא:

conf_load_balancing_load.balancing.driver.server.ssl.ciphers=HIGH:!aNULL:!MD5:!DH+3DES:!RSA+3DES

ההגדרה הזו מציינת:

• נדרש אורך מפתח של 128 ביט לפחות (HIGH).
• החרגת צופנים ללא אימות (!aNULL)
• החרגה של סטים של אלגוריתמים להצפנה (cipher suite) באמצעות MD5 (!MD5)
• לא כולל סטים של אלגוריתמים להצפנה (cipher suite) באמצעות DH (כולל DH אנונימיות, DH זמניות ו-DH קבוע) וגם DES משולש (!DH+3DES)
• החרגה של סטים של אלגוריתמים להצפנה (cipher suite) באמצעות החלפת מפתחות RSA וגם טריפל DES (!RSA+3DES)

למידע נוסף על התחביר והערכים המותרים על ידי האסימון הזה, ראו הצפנה של OpenSSL. שים לב שהאסימון הזה משתמש בשמות ההצפנה של OpenSSL, כמו AES128-SHA256, ולא ב- שמות הצפנה של Java/JSSE, כמו TLS_RSA_WITH_AES_128_CBC_SHA256.

כדי להגדיר את האסימון של הנתב:

1. עריכה של /opt/apigee/customer/application/router.properties חדש. אם הקובץ לא קיים, יוצרים אותו.
2. הגדרת conf_load_balancing_load.balancing.driver.server.ssl.ciphers ב-Assistant. לדוגמה, כדי לציין TLSv1.2 בלבד ולהחריג סטים של אלגוריתמים להצפנה (cipher suite) באמצעות מפתחות משותפים מראש, add!PSK:

   conf_load_balancing_load.balancing.driver.server.ssl.protocols=TLSv1.2
   conf_load_balancing_load.balancing.driver.server.ssl.ciphers=HIGH:!aNULL:!MD5:!DH+3DES:!RSA+3DES:!PSK

3. יש לוודא שהקובץ router.properties נמצא בבעלות apigee:

   chown apigee:apigee /opt/apigee/customer/application/router.properties

4. מפעילים מחדש את נתב Edge:

   /opt/apigee/apigee-service/bin/apigee-service edge-router restart

5. בודקים את ערך האסימון:

   /opt/apigee/apigee-service/bin/apigee-service edge-router configure -search conf_load_balancing_load.balancing.driver.server.ssl.ciphers

ההגדרה פרמטרים של מארח וירטואלי ב-TLS ל-Edge גרסה 4.17.01 ואילך

אם אתם משתמשים ב-Edge מגרסה 4.17.01 ואילך, אפשר להגדיר כמה מאפייני TLS מארח וירטואלי יחיד, כמו פרוטוקול TLS וצפן, באמצעות תג הצאצא <Properties> של <VirtualHost> התיוג. התגים האלה מתוארים בחומר העזר בנושא נכס מארח וירטואלי.

לדוגמה:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>apiTLS.myCompany.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9006</Port>
    <OCSPStapling>off</OCSPStapling>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>ref://myTestKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
    <Properties>
        <Property name="proxy_read_timeout">50</Property>
        <Property name="keepalive_timeout">300</Property>
        <Property name="proxy_request_buffering">off</Property>
        <Property name="proxy_buffering">off</Property>
        <Property name="ssl_protocols">TLSv1.2 TLSv1.1</Property>
        <Property name="ssl_ciphers">HIGH:!aNULL:!MD5:!DH+3DES:!kEDH</Property>
    </Properties>
</VirtualHost>

למידע על התחביר והערכים שמותרים על ידי האסימון ssl_ciphers, ראו הצפנה של OpenSSL. שים לב שהאסימון הזה משתמש בשמות ההצפנה של OpenSSL, כמו AES128-SHA256, ולא שמות ההצפנה של Java/JSSE, כמו TLS_RSA_WITH_AES_128_CBC_SHA256.

יצירת מארח וירטואלי שמשתמש ב-HTTPS

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

כדי ליצור את המארח הווירטואלי, מבצעים את התהליך הבא:

1. יוצרים ומגדירים מאגר מפתחות בשם myTestKeystore באמצעות התהליך שמתואר כאן: מאגרי מפתחות Truststores מוודאים שמאגר המפתחות משתמש בשם חלופי של myKeyAlias בשביל האישור והמפתח הפרטי.

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

   curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
     -d '<ResourceReference name="keystoreref">
       <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/keystoreref -u uname:password
   

3. יוצרים את המארח הווירטואלי באמצעות האפשרות יצירת ממשק API של מארח וירטואלי, שבו <ms-IP> היא כתובת ה-IP או שם הדומיין של הצומת של שרת הניהול.

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

   curl -X POST -H "Content-Type:application/xml" \
     http://<ms-IP>:8080/v1/o/{org_name}/environments/{env_name}/virtualhosts \
     -d '<VirtualHost  name="newTLSTrustStore2">
       <HostAliases>
         <HostAlias>apiTLS.myCompany.com</HostAlias>
       </HostAliases>
       <Interfaces/>
       <Port>9005</Port>
       <OCSPStapling>off</OCSPStapling>
       <SSLInfo>
         <Enabled>true</Enabled>
         <ClientAuthEnabled>false</ClientAuthEnabled>
         <KeyStore>ref://keystoreref</KeyStore>
         <KeyAlias>myKeyAlias</KeyAlias>
       </SSLInfo>
     </VirtualHost>' \
     -u email:password

4. יוצרים רשומת DNS למארח הווירטואלי שתואם לכתובת החלופית של המארח.

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

   למידע נוסף, כדאי לעיין בקטע עדכון של שרת proxy ל-API לאחר יצירת מארח וירטואלי ב- מידע על מארחים וירטואליים

אחרי שמעדכנים את שרת ה-proxy ל-API כדי להשתמש במארח הווירטואלי, ויוצרים את רשומת ה-DNS למארח אפשר לגשת לשרת ה-proxy ל-API כמו שמוצג בהמשך:

https://apiTLS.myCompany.com/v1/{project-base-path}/{resource-path}

לדוגמה:

https://apiTLS.myCompany.com/v1/weather/forecastrss?w=12797282

יצירה ושינוי של קובצי עזר למאגר מפתחות או למאגר מפתחות

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

לדוגמה, למטה מוצג מארח וירטואלי שמשתמש בהפניה למאגר המפתחות:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>apiTLS.myCompany.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9006</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>ref://keystoreref</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
</VirtualHost>

משתמשים בקריאה הבאה ל-POST API כדי ליצור את קובץ העזר שנקרא keystoreref:

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

בחומר העזר מופיעים השם של מאגר המפתחות והסוג שלו.

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

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

כדי לשנות מאוחר יותר את ההפניה כך שתפנה למאגר מפתחות אחר, ולוודא שהכינוי כולל אותו שם, השתמשו בקריאת ה-PUT הבאה:

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