Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. info
Transport Layer Security (TLS), il cui predecessore è Secure Sockets Layer (SSL), è la tecnologia di sicurezza standard per stabilire un link criptato tra un server web e un client web, ad esempio un browser o un'app. Un link criptato garantisce che tutti i dati trasmessi tra il server e il client rimangano privati. Per utilizzare TLS, un client invia 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 supportate di TLS, consulta Software e versioni supportate). 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ù avanzata che utilizza TLS bidirezionale o client. In genere, implementi TLS a due vie 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, dopodiché il server verifica l'identità del client.
Terminologia TLS
Prima di configurare TLS, devi conoscere 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 convalidarne l'autenticità. Un tipo di certificato, chiamato autofirmato, non richiede un'autorità di certificazione. |
|
Catena di certificati |
Spesso non è disponibile un certificato firmato dalla chiave privata principale dell'autorità di certificazione. 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 della CA radice. |
|
CSR |
Richiesta di firma del certificato. Un CSR è un file generato sul server TLS in base alla chiave privata. Il 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 file .der, ma spesso ha un'estensione file .cer. L'unico modo per capire la differenza tra un file .cer DER e un file .cer PEM è aprire il file in un editor di testo e cercare le istruzioni |
| Alias chiave |
Un alias 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 memorizzato nell'archivio chiavi di Apigee Edge. Nella connessione southbound, il Message Processor acts as the client e il server di backend agisce come server. Il certificato client e la relativa chiave privata sono memorizzati nell'archivio chiavi di Apigee Edge. |
| P7B |
Il formato PKCS #7 o P7B viene solitamente archiviato in formato ASCII Base64 e ha un'estensione di file .p7b o .p7c. I certificati P7B contengono istruzioni |
|
PEM |
Il formato Privacy Enhanced Mail (PEM) è un formato ASCII basato su testo che è una codifica Base64 del formato binario Distinguished Encoding Rules (DER). I certificati PEM
possono essere aperti in qualsiasi editor di testo e i contenuti effettivi del certificato sono delimitati
dalle istruzioni
È conforme al formato X.509 per la memorizzazione di un certificato, una catena di certificati o una chiave privata. Se il certificato o la chiave privata non è definito da un file PEM, puoi convertirlo in un file PEM utilizzando utilità come OpenSSL. |
| PKCS #12/PFX | Il formato PKCS #12 o PFX è un formato binario per l'archiviazione del certificato del server, di eventuali certificati intermedi e della chiave privata in un unico file criptabile. I file PFX di solito hanno estensioni come .pfx e .p12. I file PFX vengono in genere utilizzati su macchine 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 |
Utilizzato 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 indirizzamento indiretto per i keystore. Pertanto, le modifiche ai keystore non richiedono un aggiornamento dell'host virtuale, a condizione che vengano mantenuti lo stesso riferimento e lo stesso alias chiave. In questo modo puoi applicare queste modifiche in autonomia e ridurre le dipendenze dal team di assistenza Apigee. |
|
Certificato autofirmato |
Un certificato non firmato da un'autorità di certificazione 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ù target HTTPS dallo stesso indirizzo IP e dalla stessa porta senza richiedere che questi target utilizzino lo stesso certificato. |
|
Certificato TLS |
Un file digitale che identifica una persona giuridica 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. In genere, si tratta di certificati autofirmati o certificati non firmati da una CA attendibile. Nella connessione in uscita, i certificati dell'applicazione client vengono archiviati nell'archivio attendibile di Apigee Edge. Questo è obbligatorio solo se hai configurato un TLS bidirezionale tra il client e Apigee. Nella connessione in uscita, i certificati del server di backend vengono memorizzati nell'archivio attendibile di Apigee Edge. Questo è necessario se vuoi verificare il certificato del backend in Apigee Edge in una 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 oggetti keystore, ma a cui viene fatto riferimento come truststore ovunque vengano utilizzati (ad esempio in host virtuali, endpoint target, server target e così via). |
| Host virtuale |
L'host virtuale rappresenta l'endpoint dell'API Apigee per le applicazioni client. Si tratta di un'entità che consente di ospitare più nomi di dominio (con gestione separata di ciascun nome) su un singolo server (o pool di server). In questo modo, un server può condividere le proprie risorse, come memoria e cicli di elaborazione, senza richiedere a tutti i servizi forniti di utilizzare lo stesso nome host. Un host virtuale può gestire il traffico HTTP o HTTPS (abilitato SSL). 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 relativa 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 del server e chiavi pubbliche per convalidare che la catena di certificati sia firmata da un'autorità di certificazione (CA) attendibile.
- Il client e il server scambiano altri messaggi per convalidare le chiavi.
- Il client avvia il trasferimento dei dati TLS con il server.
La figura seguente mostra il protocollo di handshake TLS/SSL che utilizza un truststore facoltativo sul client:
Se il server TLS utilizza un certificato autofirmato o un certificato non firmato da un'autorità di certificazione attendibile, crea un truststore sul client. Il client compila il proprio truststore con i certificati e le chiavi pubbliche dei server che considera attendibili. Quando il client riceve un certificato, il certificato 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, che corrisponde a un proxy API impiegato su un host virtuale. Il client è un'app che tenta di accedere al proxy API. In questo scenario, Edge ha l'archivio chiavi contenente il certificato e la chiave privata.
-
Edge come client TLS
Edge agisce come 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 il protocollo di handshake TLS/SSL per l'autenticazione TLS bidirezionale tra un client e un server:
In TLS bidirezionale, l'handshake è il seguente:
- Sia il client sia il server hanno 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 inviare il proprio certificato al server.
- Il client TLS presenta il proprio certificato al server TLS per autenticarsi al server.
La figura seguente mostra l'handshake TLS con un truststore facoltativo:
In questo scenario, l'handshake è il seguente:
- Se il server TLS utilizza un certificato autofirmato o un certificato non firmato da un'autorità di certificazione attendibile, crea un archivio di attendibilità sul client. Il client ha una copia del certificato del server nel truststore. Durante il handshake TLS, il client confronta il certificato nel suo truststore con quello inviato dal server per verificare l'identità del server.
- Se il client TLS utilizza un certificato autofirmato o un certificato non firmato da un'autorità di certificazione attendibile, devi creare un server.Il server ha una copia del certificato del client nel suo archivio di attendibilità. Durante il handshake TLS, il server confronta il certificato nel suo truststore con quello inviato dal client per verificare l'identità del client.
Il client, 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, che corrisponde a un proxy API. Il client è un'app che tenta di accedere al proxy API. In questo scenario, Edge ha un keystore contenente il certificato e la chiave privata e richiede un truststore contenente il certificato e la catena CA del client.
-
Edge come client
Edge agisce come 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 archivio chiavi contenente il certificato necessario per convalidarsi al servizio di backend e, facoltativamente, un archivio attendibile contenente il certificato del server di backend se il server utilizza un certificato autofirmato o un certificato non firmato da un'autorità di certificazione attendibile.
L'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 target, dove Edge funge da client TLS, sia nelle installazioni Cloud che Private Cloud.
Con SNI, un'estensione di TLS/SSL, è possibile pubblicare più target HTTPS dallo stesso indirizzo IP e dalla stessa porta senza che questi debbano utilizzare lo stesso certificato.
Per informazioni su come attivare SNI per un'installazione on-premise, consulta Utilizzare SNI con Edge.
In uscita e in entrata
In Apigee, northbound si riferisce all'endpoint API utilizzato dalle applicazioni client per invocare il proxy API. In genere, il router è il punto di contatto in Apigee Edge e gestisce le richieste in entrata. Pertanto, in Apigee, l'endpoint utilizzato per la comunicazione tra l'applicazione client e Apigee Edge (router) è denominato northbound.
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 southbound. Il Message Processor è un componente di Apigee Edge che esegue il proxy delle richieste API ai server di destinazione del backend.
La figura seguente illustra le connessioni northbound e southbound per Apigee Edge:
