Questa pagina è stata tradotta dall'API Cloud Translation.

Configurazione dell'accesso TLS a un'API per il cloud privato

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Un host virtuale su Edge definisce i domini e le porte su cui è esposto un proxy API e, tramite , l'URL utilizzato dalle app per accedere a un proxy API.

Un host virtuale definisce inoltre se si accede al proxy API utilizzando il protocollo HTTP, oppure dal protocollo HTTPS criptato che utilizza TLS. Quando configuri un host virtuale per l'utilizzo di HTTPS TLS, devi creare un host virtuale su Edge e configurare l'host virtuale in modo che utilizzi un archivio chiavi e truststore.

Scopri di più:

di Gemini Advanced.

Note:

Questo articolo del prodotto Cloud elenca le crittografie SSL valide per TLS 1.2: Analisi empirica dei valori validi per ssl_ciphers di VirtualHost per il test di TLS 1.2.
A partire dalla versione 4.16.01 di Edge per il cloud privato, devi specificare un alias host quando la creazione di un host virtuale. Nelle versioni precedenti alla 4.16.01, l'alias host era facoltativo.
La combinazione di nome alias host e numero di porta per l'host virtuale deve essere univoca per tutti gli host virtuali nell'installazione Edge.
Se configuri un numero di porta (diverso da 80 o 443), questo deve essere univoco e non deve avere una configurazione di porta sovrapposta con un host esistente.
Se la tua installazione utilizza un bilanciatore del carico e quest'ultimo responsabile della gestione del traffico criptato, devi comunque creare l'host virtuale. Tuttavia, la configurazione di rete determinerà se l'host virtuale deve supportare o meno TLS tra il bilanciatore del carico e il router. Vedi Utilizzo di TLS in un'installazione del cloud privato per saperne di più.

Che cosa serve per creare un host virtuale

Prima di creare un host virtuale, è necessario disporre delle seguenti informazioni:

Il nome di dominio visibile al pubblico dell'host virtuale. Ad esempio, dovresti sapere se il nome visibile al pubblico è api.myCompany.com, myapi.myCompany.com e così via. Queste informazioni viene utilizzato quando crei l'host virtuale e anche quando crei il record DNS per l'host virtuale.
Per TLS unidirezionale, devi creare un archivio chiavi in cui le seguenti:
- Certificato TLS: un certificato firmato da un'autorità di certificazione (CA) oppure una catena di certificati in cui l'ultimo certificato è firmato da un'autorità di certificazione.
- Chiave privata - Edge supporta chiavi di dimensioni fino a 2048 bit. La passphrase è facoltativa.
Per TLS bidirezionale, è necessario un archivio chiavi e un archivio attendibilità per contenere del certificato del client e, facoltativamente, della catena CA del certificato. Hai bisogno del truststore anche se il certificato sia firmato da un'autorità di certificazione.

Vedi Keystores e Truststore per ulteriori informazioni sulla creazione di archivi chiavi e archivi attendibili.

Configurazione host virtuale per TLS

Per creare un host virtuale, crea un oggetto XML che definisca l'host virtuale. Il seguente oggetto XML utilizza l'elemento <SSLInfo> per definire un'istanza host per una configurazione TLS unidirezionale tramite 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>

Nota: poiché in origine Edge supportava SSL, il tag che utilizzi per il nome della funzionalità configure TLS è <SSLInfo>.

In questo esempio, l'elemento <Enabled> è impostato su true su si abilita TLS unidirezionale e gli elementi <KeyStore> e <KeyAlias> specificano l'archivio chiavi e la chiave utilizzata dalla connessione TLS.

Per attivare il TLS bidirezionale, imposta l'elemento <ClientAuthEnabled> su true e specifica un archivio attendibilità utilizzando <TrustStore> . L'archivio attendibilità contiene il certificato del client e, facoltativamente, l'autorità di certificazione del certificato o la catena di fornitura.

Scelta della modalità di specifica del nome dell'archivio chiavi e dell'archivio di attendibilità nell'host virtuale

Nell'esempio di host virtuale riportato sopra, hai specificato l'archivio chiavi utilizzando un riferimento. R riferimento è una variabile che contiene il nome dell'archivio chiavi, invece di specificare la nome dell'archivio chiavi.

Il vantaggio di usare un riferimento è che puoi modificarne il valore per cambiare all'archivio chiavi utilizzato dall'host virtuale, di solito perché il certificato nell'archivio chiavi attuale è in scadenza nel prossimo futuro. La modifica del valore del riferimento non richiede il riavvio il router Edge.

In alternativa, puoi utilizzare un nome letterale dell'archivio chiavi nell'host virtuale. Tuttavia, se se modifichi l'host virtuale per cambiare il nome dell'archivio chiavi, devi riavviare i router perimetrali.

Restrizioni nell'utilizzo dei riferimenti ad archivi chiavi e archivi attendibili

Quando utilizzi i riferimenti agli archivi chiavi, devi tenere in considerazione le restrizioni riportate di seguito. archivi attendibili:

Puoi usare i riferimenti di archivi chiavi e archivi attendibili negli host virtuali solo se supporti SNI e si termina il protocollo SSL sui router Apigee.
Se hai un bilanciatore del carico davanti ai router Apigee e interrompi TLS sul bilanciatore del carico, non potrai usare i riferimenti di un archivio chiavi .

Modifica di un host virtuale esistente per utilizzare i riferimenti all'archivio chiavi e all'archivio chiavi

Apigee consiglia vivamente agli host virtuali di utilizzare il riferimento ad archivi chiavi e archivi attendibili. I riferimenti consentono di modificare l'archivio chiavi e l'archivio chiavi utilizzati dall'host virtuale senza dover riavviare i router perimetrali.

Se gli host virtuali sono attualmente configurati per utilizzare il nome letterale dell'archivio chiavi o un archivio attendibilità, puoi convertirli in riferimenti. Per farlo, aggiorna l'host virtuale in modo che utilizzi e riavvia i router perimetrali.

Impostazione delle crittografie e dei protocolli TLS per Edge 4.15.07 e versioni precedenti

Se utilizzi Edge versione 4.15.07 e precedenti, imposta il protocollo TLS e le crittografie utilizzata dall'host virtuale mediante i tag secondari <Ciphers> e <Protocols> del Tag <SSLInfo>. Questi tag sono descritti nella tabella di seguito.

Ad esempio:

    <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>

Il tag <Cipher> utilizza il nome Java e JSSE della crittografia. Ad esempio, per Java 8, consulta http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites.

Specifica dei protocolli e delle crittografie TLS per Edge da 4.16.01 a 4.16.09

In Edge da 4.16.01 a 4.16.09, si impostano le crittografie e i protocolli predefiniti per gli host virtuali a livello globale sul router. Queste impostazioni predefinite vengono quindi applicate a tutti gli host virtuali.

Utilizza i token per specificare i protocolli e le crittografie predefiniti:

Per specificare i protocolli predefiniti, utilizza il token conf_load_balancing_load.balancing.driver.server.ssl.protocols
Per specificare le crittografie predefinite per il router, utilizza il token conf_load_balancing_load.balancing.driver.server.ssl.ciphers

Il valore predefinito del token conf_load_balancing_load.balancing.driver.server.ssl.protocols è:

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

Questa impostazione specifica che il router supporta TLS versioni 1.0, 1.1 e 1.2. Specifica un valore di valori delimitati da spazi al token.

Il valore predefinito del token 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

Questa impostazione specifica:

È richiesta una lunghezza della chiave di almeno 128 bit (HIGH).
Escludi crittografie senza autenticazione (!aNULL)
Escludi le suite di crittografia utilizzando MD5 (!MD5)
Escludere le suite di crittografia che utilizzano il DH (inclusi DH anonimo, DH temporaneo e DH fisso) E DES triplo (!DH+3DES)
Escludi le suite di crittografia utilizzando lo scambio di chiavi RSA E il triplo DES (!RSA+3DES)

Per informazioni sulla sintassi e sui valori consentiti da questo token, consulta l'articolo sulla crittografia OpenSSL. Tieni presente che questo token utilizza i nomi crittografici OpenSSL, ad esempio AES128-SHA256 e non Nomi crittografici Java/JSSE, ad esempio TLS_RSA_WITH_AES_128_CBC_SHA256.

Per impostare il token per il router:

Modifica /opt/apigee/customer/application/router.properties . Se il file non esiste, crealo.
Imposta conf_load_balancing_load.balancing.driver.server.ssl.ciphers di accesso. Ad esempio, per specificare solo TLSv1.2 ed escludere le suite di crittografia utilizzando chiavi precondivise, aggiungi!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
```

Assicurati che il file router.properties appartenga a Apigee:

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

Riavvia il router perimetrale:

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

Verifica il valore del token:

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

Impostazione Parametri host virtuali TLS per Edge versione 4.17.01 e successive

Se utilizzi Edge versione 4.17.01 e successive, puoi impostare alcune proprietà TLS per singolo host virtuale, ad esempio il protocollo e la crittografia TLS, utilizzando il tag secondario <Properties> della <VirtualHost> del tag. Questi tag sono descritti in Riferimento alle proprietà host virtuali.

Ad esempio:

<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>

Per informazioni sulla sintassi e sui valori consentiti dal token ssl_ciphers, consulta l'articolo sulla crittografia OpenSSL. Tieni presente che questo token utilizza i nomi crittografici OpenSSL, ad esempio AES128-SHA256 e non i nomi della crittografia Java/JSSE, ad esempio TLS_RSA_WITH_AES_128_CBC_SHA256.

Creazione di un host virtuale che utilizza HTTPS

Questo esempio specifica l'archivio chiavi all'host virtuale utilizzando un riferimento. L'utilizzo di un di riferimento consente di modificare l'archivio chiavi senza dover riavviare i router.

Utilizza la seguente procedura per creare l'host virtuale:

Crea e configura un archivio chiavi denominato myTestKeystore utilizzando descritta qui: Keystores Archivi attendibili. Assicurati che l'archivio chiavi utilizzi un nome alias di myKeyAlias per il certificato e la chiave privata.

Utilizza la seguente chiamata API POST per creare il riferimento denominato keystoreref all'archivio chiavi creato in precedenza:

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

Il riferimento specifica il nome dell'archivio chiavi e il tipo di riferimento come KeyStore.

Utilizza la seguente chiamata API GET per visualizzare il riferimento:

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

Crea l'host virtuale utilizzando il pulsante Crea un API Virtual Host, dove <ms-IP> è l'indirizzo IP o nome di dominio del nodo del server di gestione.

Assicurati di specificare il riferimento dell'archivio chiavi e l'alias della chiave corretti:
```
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
```
Nota: se esegui il protocollo TLS bidirezionale con il client, quindi imposta <ClientAuthEnabled> su true e specifica il truststore utilizzando l'elemento <TrustStore>. La Il client deve essere configurato correttamente per TLS a due vie, vale a dire che Edge ha un archivio attendibilità contenente la catena di certificati e certificati del client. Crea il truststore utilizzando la procedura descritti qui: Keystores Archivi attendibili.
Crea un record DNS per l'host virtuale che corrisponda all'alias host.
Se disponi di proxy API, aggiungi l'host virtuale all'elemento <HTTPConnection> della ProxyEndpoint. L'host virtuale viene aggiunto automaticamente a tutti i nuovi proxy API.

Consulta Aggiornamento di un proxy API dopo la creazione di un host virtuale in Informazioni sugli host virtuali.

Avviso:tutti gli host virtuali vengono aggiunti automaticamente a tutti i nuovi Proxy API. Pertanto, se crei un nuovo proxy API che non deve essere accessibile tramite host virtuale specifico, è necessario modificare il proxy API per rimuovere l'host virtuale il suo ProxyEndpoint.

Dopo l'aggiornamento di un proxy API per l'utilizzo dell'host virtuale e la creazione del record DNS per l'host alias, puoi accedere al proxy API come illustrato di seguito:

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

Ad esempio:

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

Creazione e modifica dei riferimenti a un archivio chiavi o un archivio attendibili

Facoltativamente, puoi configurare l'host virtuale in modo che utilizzi un riferimento all'archivio chiavi in un archivio attendibilità. Il vantaggio di usare un riferimento è che puoi aggiornarlo con punta a un altro archivio chiavi o truststore per aggiornare il certificato TLS senza dover il router.

Ad esempio, quello mostrato di seguito è un host virtuale che utilizza un riferimento all'archivio chiavi:

<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>

Utilizza la seguente chiamata API POST per creare il riferimento denominato 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

Il riferimento specifica il nome e il tipo dell'archivio chiavi.

Utilizza la seguente chiamata API GET per visualizzare il riferimento:

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

Per modificare in un secondo momento il riferimento in modo che punti a un archivio chiavi diverso, assicurandoti che l'alias lo stesso nome, utilizza la seguente chiamata 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