Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. informazioni
TLS (Transport Layer Security), il cui predecessore è SSL (Secure Sockets Layer), è 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 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 criptato HTTPS anziché il protocollo non criptato HTTP.
Edge supporta TLS unidirezionale e TLS bidirezionale sia in un deployment su cloud che in un deployment on-premise (per le versioni di TLS supportate, vedi Software supportato e versioni supportate). TLS unidirezionale consente al client TLS di verificare l'identità del server TLS. Ad esempio, un'app eseguita su un telefono Android (client) può verificare l'identità delle API Edge (server).
Apigee supporta anche una forma di autenticazione più efficace mediante TLS a due vie, o client. In genere implementi TLS bidirezionale per migliorare la sicurezza end-to-end e proteggere i tuoi dati da attacchi client come lo spoofing dei client o attacchi man-in-the middle. Nel protocollo TLS bidirezionale, il client verifica l'identità del server seguito dal server che verifica l'identità del client.
Terminologia TLS
Prima di configurare TLS, dovresti conoscere i seguenti termini e concetti importanti:
|
Termine |
Definizione |
|---|---|
|
Canada |
Autorità di certificazione. Un'entità attendibile, come Symantec o VeriSign, è stata utilizzata per emettere certificati e convalidarne l'autenticità. Un tipo di certificato, chiamato autofirmato, non richiede una CA. |
|
Catena di certificati |
Spesso non si dispone di un certificato firmato dalla chiave privata radice della CA. Al contrario, hai il tuo certificato, insieme a uno o più certificati intermedi che formano una catena. L'ultimo certificato intermedio nella catena è in genere firmato dalla chiave privata radice della CA. |
|
CSR |
Richiesta di firma del certificato. Una richiesta di firma del certificato è 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 richiesta di firma del certificato per creare un certificato TLS. In genere, quando hai un certificato scaduto e vuoi rinnovarlo, in genere viene generato un CSR. |
| DER |
Regole di codifica Distinguite. Il formato DER è una forma binaria di certificato anziché il formato ASCII PEM. A volte il file ha un'estensione .der, ma spesso l'estensione .cer è .cer. L'unico modo per distinguere 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, |
|
Archivio chiavi |
Un archivio chiavi è un repository che contiene uno o più certificati TLS e una chiave privata corrispondente, che viene utilizzata per identificare l'entità durante un handshake TLS tra un client e un server. Nella connessione northbound, il router agisce come server e il suo certificato viene archiviato nell'archivio chiavi in Apigee Edge. Nella connessione a sud, il processore di messaggi agisce come client e il server di backend agisce come server. Il certificato client e la relativa chiave privata sono archiviati nell'archivio chiavi in Apigee Edge. |
| P7B |
Il formato PKCS #7 o P7B è solitamente memorizzato in formato ASCII Base64 e ha un'estensione
del file .p7b o .p7c. I certificati P7B contengono istruzioni |
|
PEM |
Il formato PEM (Privacy Ottimizzata) è un formato ASCII basato su testo che corrisponde alla codifica Base64 del formato binario DN (Distinguined 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, di una catena di certificati o di una chiave privata. Se il certificato o la chiave privata non è definita 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 criptato. I file PFX in genere hanno estensioni come .pfx e .p12. I file PFX vengono generalmente utilizzati su computer Windows per importare ed esportare certificati e chiavi private. |
|
Chiave privata |
Utilizzato sul server TLS per decriptare i dati. Solo il server TLS dispone della chiave privata e non è 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 dispongono di una copia della chiave pubblica del server. |
| References | I riferimenti forniscono un livello di indirezione per gli archivi chiavi; pertanto, le modifiche all'archivio chiavi non richiedono un aggiornamento dell'host virtuale, purché vengano mantenuti lo stesso riferimento e lo stesso alias chiave. In questo modo, puoi gestire autonomamente queste modifiche e ridurre le dipendenze con il team di assistenza di 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ù target HTTPS sullo stesso indirizzo IP e sulla stessa porta, senza richiedere l'utilizzo dello stesso certificato da parte di queste destinazioni. |
|
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. |
|
Archivio attendibilità |
Contiene certificati attendibili su un client TLS utilizzato per convalidare il certificato di un server TLS presentato al client. In genere questi sono certificati autofirmati o non firmati da una CA attendibile. Sulla connessione northbound, i certificati dell'applicazione client vengono archiviati nell'archivio attendibilità in Apigee Edge. Questa operazione è obbligatoria solo se hai configurato un protocollo TLS a due vie tra il client e Apigee. Nella connessione in direzione sud, i certificati del server di backend sono archiviati nell'archivio di attendibilità in Apigee Edge. Questo campo è obbligatorio se vuoi verificare il certificato del backend in Apigee Edge tramite comunicazione TLS unidirezionale o bidirezionale tra Apigee Edge e il server di backend. Apigee Edge non ha un oggetto truststore separato. Pertanto, gli archivi trust vengono creati come oggetto archivio chiavi, ma vi viene fatto riferimento come archivio attendibilità ovunque venga utilizzato (ad esempio nell'host virtuale, negli endpoint di destinazione, nei server di destinazione e così via). |
| Host virtuale |
L'host virtuale rappresenta l'endpoint API Apigee per le applicazioni client. Si tratta di un'entità che aiuta a ospitare più nomi di dominio (con una gestione separata di ogni nome) su un singolo server (o pool di server). Ciò consente a un server di condividere le proprie risorse, ad esempio i cicli di memoria e processore, senza richiedere che tutti i servizi forniti utilizzino lo stesso nome host. Un host virtuale può gestire traffico HTTP o HTTPS (con supporto 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 contenente 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 archivio attendibilità 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 molti altri messaggi per convalidare le chiavi.
- Il client avvia il trasferimento di dati TLS con il server.
La figura seguente mostra l'handshake TLS/SSL mediante un archivio attendibilità facoltativo sul client:
Se il server TLS utilizza un certificato autofirmato o non firmato da una CA attendibile, puoi creare un archivio di attendibilità sul client. Il client compila l'archivio attendibilità con certificati server e chiavi pubbliche che considera attendibili. Quando il client riceve un certificato, quest'ultimo viene convalidato in base ai certificati nel suo archivio attendibilità.
Nel TLS unidirezionale, Edge può essere il server o il client, come segue:
-
Edge come server TLS
Perimetrale è 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 ha l'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 archivio chiavi contenente 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:
Nel protocollo TLS a due vie, l'handshake è il seguente:
- Sia il client che il server hanno i propri archivi chiavi. 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 l'autenticazione. Il client verifica quindi l'identità del server prima di inviare il certificato al server.
- Il client TLS presenta il proprio certificato al server TLS per autenticare se stesso al server.
La figura seguente mostra l'handshake TLS mediante un archivio di attendibilità facoltativo:
In questo scenario, l'handshake è il seguente:
- Se il server TLS utilizza un certificato autofirmato o non firmato da una CA attendibile, crea un archivio attendibilità sul client. Il client ha una copia del certificato del server nel suo archivio attendibilità. Durante l'handshake TLS, il client confronta il certificato nel suo archivio attendibilità con l'invio del certificato dal server per verificare l'identità del server.
- Se il client TLS utilizza un certificato autofirmato o non firmato da una CA attendibile, crea un archivio di attendibilità sul server.Il server dispone di una copia del certificato del client nel proprio archivio di attendibilità. Durante l'handshake TLS, il server confronta il certificato nel suo archivio attendibilità con l'invio del certificato dal client per verificare l'identità del client.
Il client, il server o entrambi possono utilizzare un archivio di attendibilità.
Nel TLS bidirezionale, Edge può essere il server o il client, come indicato di seguito:
-
Edge come server
L'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 attendibilità contenente il certificato e la catena CA del client.
-
Inquadra il cliente
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 archivio chiavi che contiene il certificato e la chiave privata.
Edge deve inoltre definire un archivio chiavi che contenga il certificato necessario per la convalida al servizio di backend e, facoltativamente, un archivio attendibilità contenente il certificato del server di backend se il server utilizza un certificato autofirmato o un certificato non firmato da una CA attendibile.
È importante ricordare che Edge è sufficientemente 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 agisce come client TLS, sia nelle installazioni di cloud che di cloud privato.
Con SNI, che è un'estensione di TLS/SSL, più destinazioni HTTPS possono essere pubblicate dallo stesso indirizzo IP e dalla stessa porta senza che queste destinazioni utilizzino lo stesso certificato.
Per informazioni sull'abilitazione di SNI per un'installazione on-premise, consulta Utilizzo di SNI con Edge.
In direzione nord e sud
In Apigee, il senso nord 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) è indicato come northbound.
In Apigee, il verso sud 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 (processore di messaggi) e il server di backend è indicato come southbound. Il processore di messaggi è un componente di Apigee Edge che esegue il proxy delle richieste API ai server di destinazione del backend.
La figura seguente illustra le connessioni in direzione nord e sud per Apigee Edge:
