Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. info
Transport Layer Security (TLS), il cui predecessore è Secure Sockets Layer (SSL), è la tecnologia di sicurezza standard
per stabilire un collegamento criptato tra un server web e un client web, ad esempio un browser o un'app. Un collegamento criptato garantisce che tutti i dati che passano tra il server e il client rimangano privati. Per utilizzare TLS, un client effettua una richiesta sicura al server utilizzando il protocollo
HTTPS criptato, anziché il protocollo HTTP non criptato.
Edge supporta TLS unidirezionale e TLS bidirezionale sia in un deployment cloud che on-premise (per le versioni di TLS supportate, vedi Software e versioni supportati). TLS unidirezionale consente al client TLS di verificare l'identità del server TLS. Ad esempio, un'app in esecuzione su uno smartphone Android (client) può verificare l'identità delle API Edge (server).
Apigee supporta anche una forma di autenticazione più efficace che utilizza TLS bidirezionale o client. In genere, implementi TLS bidirezionale per migliorare la sicurezza end-to-end e proteggere i tuoi dati dagli attacchi client, come lo spoofing del client o gli attacchi man-in-the-middle. In TLS bidirezionale, il client verifica l'identità del server, seguito dalla verifica dell'identità del client da parte del server.
Terminologia TLS
Prima di configurare TLS, devi avere familiarità con i seguenti termini e concetti importanti:
|
Termine |
Definizione |
|---|---|
|
CA |
Autorità di certificazione. Un'entità attendibile, come Symantec o VeriSign, utilizzata per emettere certificati e per convalidare l'autenticità di un certificato. Un tipo di certificato, chiamato certificato autofirmato, non richiede un'autorità di certificazione. |
|
Catena di certificati |
Spesso non avrai un certificato firmato con la chiave privata radice della tua CA. Invece, hai il tuo certificato insieme a uno o più certificati intermedi che formano una catena. L'ultimo certificato intermedio della catena è in genere firmato dalla chiave privata radice della CA. |
|
CSR |
Richiesta di firma del certificato. Una richiesta CSR è un file generato sul server TLS in base alla chiave privata. La richiesta CSR contiene la chiave pubblica e altre informazioni, come il nome, la località e il nome di dominio dell'organizzazione. La CA firma la CSR per creare un certificato TLS. In genere, generi una CSR quando hai un certificato scaduto e vuoi rinnovarlo. |
| DER |
Distinguished Encoding Rules. Il formato DER è una forma binaria di un certificato anziché
il formato PEM ASCII. A volte ha un'estensione .der, ma spesso ha un'estensione .cer. L'unico modo per distinguere un file .cer DER da un file .cer PEM è aprire il file in un editor di testo e cercare le istruzioni |
| Alias della chiave |
Un alias di chiave identifica in modo univoco una voce dell'archivio chiavi (certificato TLS e chiave privata corrispondente) nell'archivio chiavi.
In Apigee Edge |
|
Keystore |
Un keystore è un repository che contiene uno o più certificati TLS e una chiave privata corrispondente utilizzata per identificare l'entità durante un handshake TLS tra un client e un server. Nella connessione in uscita, il router funge da server e il relativo certificato viene archiviato nel keystore in Apigee Edge. Nella connessione in uscita, il processore di messaggi funge da client e il server di backend funge da server. Il certificato client e la relativa chiave privata vengono archiviati nell'archivio chiavi di Apigee Edge. |
| P7B |
Il formato PKCS #7 o P7B viene in genere memorizzato in formato ASCII Base64 e ha un'estensione
di file .p7b o .p7c. I certificati P7B contengono le istruzioni |
|
PEM |
Il formato PEM (Privacy Enhanced Mail) è un formato ASCII basato su testo che è una codifica Base64
del formato binario DER (Distinguished Encoding Rules). I certificati PEM
possono essere aperti in qualsiasi editor di testo e il contenuto effettivo del certificato è delimitato
tra le istruzioni
È conforme al formato X.509 per l'archiviazione di un certificato, una catena di certificati o una chiave privata. Se il certificato o la chiave privata non sono definiti da un file PEM, puoi convertirli in un file PEM utilizzando utilità come OpenSSL. |
| PKCS #12/PFX | Il formato PKCS #12 o PFX è un formato binario per archiviare il certificato del server, eventuali certificati intermedi e la chiave privata in un unico file crittografabile. I file PFX di solito hanno estensioni come .pfx e .p12. I file PFX vengono in genere utilizzati sui computer Windows per importare ed esportare certificati e chiavi private. |
|
Chiave privata |
Utilizzato sul server TLS per decriptare i dati. Solo il server TLS ha la chiave privata, che non viene condivisa con i client TLS. |
|
Chiave pubblica |
Utilizzata per criptare i dati inviati da un client TLS a un server TLS. La chiave pubblica è inclusa nel certificato. Tutti i client TLS hanno una copia della chiave pubblica del server. |
| References | I riferimenti forniscono un livello di indirezione per i keystore, pertanto le modifiche al keystore non richiedono un aggiornamento dell'host virtuale, a condizione che vengano mantenuti lo stesso riferimento e lo stesso alias della chiave. In questo modo, puoi gestire autonomamente queste modifiche e ridurre le dipendenze con il team di assistenza Apigee. |
|
Certificato autofirmato |
Un certificato non firmato da una CA attendibile. L'emittente e il soggetto sono identici; sono firmati con la chiave privata corrispondente alla chiave pubblica che contengono. |
|
SNI |
Indicazione nome server. Consente di pubblicare più destinazioni HTTPS dallo stesso indirizzo IP e dalla stessa porta senza richiedere che utilizzino lo stesso certificato. |
|
Certificato TLS |
Un file digitale che identifica un'entità in una transazione TLS. Un certificato, o cert, può essere utilizzato per identificare il server TLS e il client TLS, a seconda della configurazione TLS. |
|
Truststore |
Contiene certificati attendibili su un client TLS utilizzati per convalidare il certificato di un server TLS presentato al client. Questi certificati sono in genere autofirmati o non firmati da una CA attendibile. Nella connessione inbound, i certificati dell'applicazione client vengono archiviati nel truststore in Apigee Edge. Questo è obbligatorio solo se hai configurato un TLS bidirezionale tra il client e Apigee. Nella connessione southbound, i certificati del server di backend sono archiviati nel truststore in Apigee Edge. Questo è necessario se vuoi verificare il certificato del backend in Apigee Edge nella comunicazione TLS unidirezionale o bidirezionale tra Apigee Edge e il server di backend. Apigee Edge non ha un oggetto truststore separato. Pertanto, i truststore vengono creati come oggetto keystore, ma vengono indicati come truststore ovunque vengano utilizzati (ad esempio in host virtuali, endpoint di destinazione, server di destinazione e così via). |
| Host virtuale |
Host virtuale rappresenta l'endpoint API Apigee per le applicazioni client. È un'entità che aiuta a ospitare più nomi di dominio ( con gestione separata di ogni nome) su un singolo server (o pool di server). Ciò consente a un server di condividere le proprie risorse, come memoria e cicli del processore, senza richiedere che tutti i servizi forniti utilizzino lo stesso nome host. Un host virtuale può gestire il traffico HTTP o HTTPS (con SSL abilitato). Un host virtuale abilitato per SSL può essere configurato in modalità TLS unidirezionale o bidirezionale. È configurato con quanto segue:
|
TLS/SSL unidirezionale
La figura seguente mostra l'handshake TLS/SSL per l'autenticazione unidirezionale tra un client TLS e un server TLS:
In una configurazione TLS unidirezionale, l'handshake è il seguente:
- Il client invia una richiesta di sessione al server.
- Il server risponde con un certificato, che contiene la sua chiave pubblica. Questo certificato proviene dall'archivio chiavi del server, che contiene anche la chiave privata del server. La chiave privata non viene mai inviata al client.
- Per un certificato firmato, il client utilizza un truststore contenente certificati server e chiavi pubbliche per verificare che la catena di certificati sia firmata da un'autorità di certificazione (CA) attendibile.
- Il client e il server si scambiano diversi altri messaggi per convalidare le chiavi.
- Il client inizia il trasferimento dei dati TLS con il server.
La figura seguente mostra l'handshake TLS/SSL utilizzando un truststore facoltativo sul client:
Se il server TLS utilizza un certificato autofirmato o un certificato non firmato da un'autorità di certificazione attendibile, devi creare un truststore sul client. Il client popola il proprio truststore con i certificati server e le chiavi pubbliche di cui si fida. Quando il client riceve un certificato, quello in entrata viene convalidato in base ai certificati nel truststore.
In TLS unidirezionale, Edge può essere il server o il client come segue:
-
Edge come server TLS
Edge è il server che ospita l'endpoint TLS, dove l'endpoint TLS corrisponde a un proxy API di cui è stato eseguito il deployment in un host virtuale. Il client è un'app che tenta di accedere al proxy API. In questo scenario, Edge dispone dell'archivio chiavi contenente il certificato e la chiave privata.
-
Edge come client TLS
Edge funge da client che accede a un servizio di backend. In questo caso, il servizio di backend corrisponde al server che ospita un endpoint TLS. Pertanto, il server di backend ha un keystore che contiene il certificato e la chiave privata.
TLS bidirezionale
La figura seguente mostra l'handshake TLS/SSL per l'autenticazione TLS bidirezionale tra un client e un server:
In TLS bidirezionale, l'handshake è il seguente:
- Il client e il server hanno entrambi i propri keystore. L'archivio chiavi del client contiene il certificato e la chiave privata, mentre l'archivio chiavi del server contiene il certificato e la chiave privata.
- Il server TLS presenta il proprio certificato al client TLS per autenticarsi. Il client verifica quindi l'identità del server prima di inviargli il certificato.
- Il client TLS presenta il proprio certificato al server TLS per autenticarsi sul server.
La figura seguente mostra l'handshake TLS utilizzando un truststore facoltativo:
In questo scenario, l'handshake è il seguente:
- Se il server TLS utilizza un certificato autofirmato o un certificato non firmato da una CA attendibile, devi creare un truststore sul client. Il client ha una copia del certificato del server nel truststore. Durante l'handshake TLS, il client confronta il certificato nel truststore con il certificato inviato dal server per verificare l'identità del server.
- Se il client TLS utilizza un certificato autofirmato o un certificato non firmato da una CA attendibile, crea un truststore sul server.Il server ha una copia del certificato del client nel proprio truststore. Durante l'handshake TLS, il server confronta il certificato nel truststore con il certificato inviato dal client per verificare l'identità del client.
Il client o il server o entrambi possono utilizzare un truststore.
In TLS bidirezionale, Edge può essere il server o il client come segue:
-
Edge come server
Edge è il server che ospita l'endpoint TLS, dove l'endpoint TLS corrisponde a un proxy API. Il client è un'app che tenta di accedere al proxy API. In questo scenario, Edge ha un archivio chiavi contenente il certificato e la chiave privata e richiede un archivio attendibile contenente il certificato del client e la catena CA.
-
Edge come client
Edge funge da client che accede a un servizio di backend. In questo caso, il servizio di backend corrisponde al server che ospita l'endpoint TLS. Il server di backend ha quindi un keystore che contiene il certificato e la chiave privata.
Edge deve anche definire un keystore che contenga il certificato necessario per convalidarsi nel servizio di backend e, facoltativamente, un truststore contenente il certificato del server di backend se il server utilizza un certificato autofirmato o un certificato non firmato da una CA attendibile.
La cosa importante da ricordare è che Edge è abbastanza flessibile da supportare TLS bidirezionale indipendentemente da come decidi di configurarlo.
Supporto SNI
Edge supporta l'utilizzo di Server Name Indication (SNI) dai proxy API a Edge, dove Edge funge da server TLS, e da Edge agli endpoint di destinazione, dove Edge funge da client TLS, sia nelle installazioni Cloud che Private Cloud.
Con SNI, un'estensione di TLS/SSL, è possibile pubblicare più destinazioni HTTPS dallo stesso indirizzo IP e dalla stessa porta senza richiedere che queste destinazioni utilizzino lo stesso certificato.
Per informazioni sull'attivazione di SNI per un'installazione on-premise, consulta Utilizzo di SNI con Edge.
Direzione nord e sud
In Apigee, northbound si riferisce all'endpoint API utilizzato dalle applicazioni client per richiamare il proxy API. In genere, il router è il punto di ingresso in Apigee Edge e gestisce le richieste in entrata ad Apigee Edge. Pertanto, in Apigee, l'endpoint utilizzato per la comunicazione tra l'applicazione client e Apigee Edge (router) è denominato inbound.
In Apigee, southbound si riferisce all'endpoint di destinazione utilizzato da Apigee per comunicare con il server di backend. Pertanto, in Apigee, l'endpoint utilizzato per la comunicazione tra Apigee Edge (Message Processor) e il server di backend è denominato in uscita. Il processore di messaggi è un componente di Apigee Edge che funge da proxy per le richieste API ai server di destinazione backend.
La seguente figura illustra le connessioni in uscita e in entrata per Apigee Edge:
