דף זה תורגם על ידי Cloud Translation API.

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

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

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

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

מידע נוסף:

הערות:

המאמר הזה למוצר Cloud מפרט הצפנות SSL חוקיות ל-TLS 1.2: Empirical Analysis של ערכים חוקיים עבור VirtualHost ssl_ciphers לבדיקת TLS 1.2.
החל מגרסה 4.16.01 של Edge לענן פרטי, צריך לציין כינוי מארח כשאתם יוצרים מארח וירטואלי. בגרסאות הקודמות ל-4.16.01, כינוי המארח היה אופציונלי.
השילוב של שם הכינוי של המארח ומספר היציאה של המארח הווירטואלי חייב להיות ייחודי לכל המארחים הווירטואליים בהתקנת Edge.
אם מגדירים מספר יציאה (שונה מ-80 או 443), הוא צריך להיות ייחודי ואסור לו להגדיר יציאה חופפת למארח קיים.
אם בהתקנה שלך נעשה שימוש במאזן עומסים, ומאזן העומסים אחראי לטיפול בתנועה מוצפנת, עדיין צריך ליצור את המארח הווירטואלי. עם זאת, הגדרת הרשת שלכם תקבע אם המארח הווירטואלי צריך לתמוך ב-TLS בין מאזן העומסים לבין הנתב. מידע נוסף זמין במאמר שימוש ב-TLS בהתקנה של ענן פרטי.

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

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

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

אפשר לקרוא מידע נוסף על יצירת מאגרי מפתחות ו-Truststores .Keystores ו-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>

הערה: מכיוון ש-Edge תמך במקור ב-SSL, התג שבו אתם משתמשים כדי להגדיר TLS נקרא <SSLInfo>.

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

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

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

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

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

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

הגבלות על השימוש בהפניות ל-Keystores ול-Truststore

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

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

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

Apigee ממליצה מאוד שמארחים וירטואליים ישתמשו בהפניות ל-Keystores ול-Truststores. קובצי עזר מאפשרים לשנות את מאגר המפתחות ואת ה-Truststore שמשמשים את המארח הווירטואלי בלי להפעיל מחדש את Edge Routers.

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

הגדרת הצפנות ופרוטוקולים של 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

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

ערך ברירת המחדל של האסימון 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)
החרגה של חבילות הצפנה באמצעות MD5 (!MD5)
לא כולל חבילות הצפנה שמשתמשות ב-DH (כולל DH אנונימי, DH זמני ו-DH קבוע) וגם DES משולש (!DH+3DES)
החרגה של חבילות הצפנה באמצעות חילופי מפתחות RSA ו-DES משולשים (!RSA+3DES)

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

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

עורכים את הקובץ /opt/apigee/customer/application/router.properties. אם הקובץ לא קיים, יוצרים אותו.
מגדירים את האסימון conf_load_balancing_load.balancing.driver.server.ssl.ciphers. לדוגמה, כדי לציין רק את TLSv1.2 ולהחריג חבילות הצפנה באמצעות מפתחות משותפים מראש, מוסיפים!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
```
יש לוודא שהקובץ router.properties הוא בבעלות apigee:
```
chown apigee:apigee /opt/apigee/customer/application/router.properties
```

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

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

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

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

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

אם אתם משתמשים בגרסה 4.17.01 ואילך של Edge, תוכלו להגדיר מאפייני 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

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

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

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

משתמשים בקריאה הבאה ל-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.

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

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

יוצרים את המארח הווירטואלי באמצעות Create a Virtual Host 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
```
הערה: אם מבצעים TLS דו-כיווני עם הלקוח, צריך להגדיר את <ClientAuthEnabled> לערך true ולציין את ה-Truststore באמצעות הרכיב <TrustStore>. צריך להגדיר את הלקוח בצורה נכונה ל-TLS דו-כיווני. כלומר, ל-Edge יש מאגר מהימנות שמכיל את האישור ושרשרת האישורים של הלקוח. יוצרים את ה-Truststore באמצעות התהליך שמתואר כאן: Keystores ו-Truststores.
יוצרים רשומת DNS למארח הווירטואלי שתואם לכינוי המארח.
אם יש לך שרתי proxy ל-API, צריך להוסיף את המארח הווירטואלי לרכיב <HTTPConnection> ב-ProxyEndpoint. המארח הווירטואלי מתווסף באופן אוטומטי לכל שרתי ה-proxy החדשים של ה-API.

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

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

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

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

לדוגמה:

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

יצירה ושינוי של הפניות ל-Keystore או ל-Truststore

לחלופין, אפשר להגדיר את המארח הווירטואלי להשתמש בהפניה ל-Keystore או ל-Truststore. היתרון בשימוש בהפניה הוא שאפשר לעדכן את ההפניה כך שהיא תפנה למאגר מפתחות אחר או ל-Truststore אחר, כדי לעדכן את אישור ה-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>

משתמשים בקריאה הבאה ל-API של POST כדי ליצור את קובץ העזר בשם 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

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

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

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