View a markdown version of this page

Scrivi il codice della funzione di CloudFront connessione per la convalida reciproca del protocollo TLS (viewer) - Amazon CloudFront

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Scrivi il codice della funzione di CloudFront connessione per la convalida reciproca del protocollo TLS (viewer)

CloudFront Le funzioni di connessione consentono di scrivere JavaScript funzioni leggere per la convalida dei certificati MTL e la logica di autenticazione personalizzata. Il codice Connection Function può convalidare i certificati client, implementare regole di autenticazione specifiche del dispositivo, gestire scenari di revoca dei certificati e allow/deny prendere decisioni per le connessioni TLS nelle edge location di tutto il mondo. CloudFront

Le funzioni di connessione forniscono un modo efficace per estendere la convalida CloudFront dei certificati integrata con la tua logica aziendale. A differenza delle funzioni di richiesta e risposta dello spettatore che elaborano i dati HTTP, le funzioni di connessione operano a livello TLS e hanno accesso alle informazioni sui certificati, agli indirizzi IP dei client e ai dettagli di connessione TLS. Ciò le rende ideali per l'implementazione di modelli di sicurezza zero-trust, sistemi di autenticazione dei dispositivi e politiche di convalida dei certificati personalizzate che vanno oltre la convalida PKI standard.

Il codice Connection Function viene eseguito in un ambiente sicuro e isolato con tempi di avvio inferiori al millisecondo e può essere scalato per gestire milioni di connessioni al secondo. Il runtime è ottimizzato per i carichi di lavoro di convalida dei certificati e fornisce un'integrazione integrata CloudFront KeyValueStore per le operazioni di ricerca dei dati in tempo reale, consentendo scenari di autenticazione sofisticati come la revoca dei certificati, il controllo degli elenchi e la convalida degli elenchi consentiti dei dispositivi.

Per aiutarti a scrivere un codice di Connection Function efficace, consulta i seguenti argomenti. Per esempi di codice completi e tutorial dettagliati, consulta le sezioni dedicate ai tutorial di questa guida ed esplora gli esempi di Connection Function disponibili nella console. CloudFront

CloudFront Casi d'uso e scopi della funzione di connessione

Prima di scrivere la CloudFront Connection Function, stabilite attentamente il tipo di logica di convalida o autenticazione del certificato da implementare. Le funzioni di connessione sono progettate per casi d'uso specifici che richiedono una convalida personalizzata oltre al controllo standard dei certificati PKI. La comprensione del caso d'uso consente di progettare un codice efficiente che soddisfi i requisiti di sicurezza mantenendo al contempo prestazioni ottimali.

I casi d'uso comuni delle funzioni di connessione includono:

  • Gestione della revoca dei certificati: implementa politiche personalizzate per la gestione dei certificati revocati, inclusi periodi di tolleranza per la rotazione dei certificati, eccezioni di rete attendibili per i dispositivi interni o scenari di accesso di emergenza in cui i certificati revocati potrebbero richiedere un accesso temporaneo.

  • Supporto MTL opzionale: gestisci le connessioni MTL e non MTLS con politiche di autenticazione diverse, consentendo di fornire una sicurezza avanzata per i client che supportano i certificati mantenendo la compatibilità con i client legacy.

  • IP-based autenticazione: combina la convalida dei certificati con i controlli dell'indirizzo IP del client per una maggiore sicurezza, ad esempio limitando l'accesso da specifiche aree geografiche, reti aziendali o intervalli IP dannosi noti.

  • Multi-tenant convalida del certificato: implementa regole di convalida specifiche del tenant in cui si applicano autorità di certificazione o criteri di convalida diversi in base all'emittente del certificato del cliente o agli attributi dell'oggetto.

  • Time-based controllo degli accessi: applica restrizioni basate sul tempo in cui i certificati sono validi solo in orari, finestre di manutenzione o periodi lavorativi specifici, anche se il certificato stesso non è scaduto.

Le funzioni di connessione vengono CloudFront eseguite dopo aver eseguito la convalida standard del certificato (verifica della catena di fiducia, controlli di scadenza e convalida della firma) ma prima che venga stabilita la connessione TLS. Questa tempistica offre la flessibilità di aggiungere criteri di convalida personalizzati beneficiando al contempo della convalida dei certificati integrata. CloudFront La tua funzione riceve i risultati della convalida standard e può prendere decisioni informate sull'opportunità o meno di consentire o negare la connessione in base a criteri standard e personalizzati.

Quando progettate la vostra Connection Function, considerate le implicazioni prestazionali della logica di convalida. Le funzioni hanno un limite di esecuzione di 5 millisecondi, pertanto le operazioni complesse devono essere ottimizzate per aumentare la velocità. KeyValueStore Utilizzatele per ricerche rapide dei dati anziché per calcoli complessi e strutturate la logica di convalida in modo che i certificati non validi falliscano rapidamente.

CloudFront Connection Function, struttura degli eventi e formato della risposta

CloudFront Le funzioni di connessione ricevono una struttura degli eventi diversa rispetto alle funzioni di richiesta e risposta dello spettatore. Invece dei request/response dati HTTP, le funzioni di connessione ricevono informazioni sul certificato e sulla connessione che è possibile utilizzare per prendere decisioni di autenticazione.

Struttura degli eventi per le funzioni di connessione

Le funzioni di connessione ricevono un oggetto evento che contiene informazioni sul certificato e sulla connessione. La struttura degli eventi della funzione è illustrata di seguito:

{ "clientCertificate": { "certificates": { "leaf": { "serialNumber": "string", "issuer": "string", "subject": "string", "validity": { "notBefore": "string", "notAfter": "string" }, "sha256Fingerprint": "string", "ocspEndpoint": "string", "san": "string", "spki": "string", "sanHex": "string" }, "intermediates": [ { "serialNumber": "string", "issuer": "string", "subject": "string", "validity": { "notBefore": "string", "notAfter": "string" }, "sha256Fingerprint": "string", "ocspEndpoint": "string", "san": "string", "spki": "string", "sanHex": "string" } ] } }, "clientIp": "string", "endpoint": "string", "distributionId": "string", "connectionId": "string" }

Di seguito è riportato un esempio della struttura dell'oggetto dell'evento:

{ "clientCertificate": { "certificates": { "leaf": { "serialNumber": "00:9e:2a:af:16:56:e5:47:25:7d:2e:38:c3:f9:9d:57:fa", "issuer": "C=US, O=Ram, OU=Edge, ST=WA, CN=mTLS-CA, L=Snoqualmie", "subject": "C=US, O=Ram, OU=Edge, ST=WA, CN=mTLS-CA, L=Snoqualmie", "validity": { "notBefore": "2025-09-10T23:43:10Z", "notAfter": "2055-09-11T00:43:02Z" }, "sha256Fingerprint": "_w6bJ7aOAlGOj7NUhJxTfsfee-ONg_xop3_PTgTJpqs=", "ocspEndpoint": "http://ocsp.example.com", "san": "DNS:api.example.com,DNS:www.example.com,URI:urn:example:client:123,IP Address:192.168.1.100,email:alejandro_rosalez@example.com", "spki": "30820122300d06092a864886f70d01010105000382010f003082010a0282010100b8efe87db798500320936...", "sanHex": "3058820f6170692e6578616d706c652e636f6d820f7777772e6578616d706c652e636f6d8619..." }, "intermediates": [ { "serialNumber": "00:d4:04:a5:fd:cb:20:37:54", "issuer": "C=US, O=Example Corp, CN=Example Root CA", "subject": "C=US, O=Example Corp, CN=Example Intermediate CA", "validity": { "notBefore": "2024-01-01T00:00:00Z", "notAfter": "2034-01-01T23:59:59Z" }, "sha256Fingerprint": "3a8c6b...", "ocspEndpoint": "http://ocsp.example.com/intermediate", "san": "DNS:ca.example.com,URI:urn:ca:intermediate:001", "spki": "30820122300d06092a864886f70d01010105000382010f003082010a0282010100b389dd513b0f1f14cac1...", "sanHex": "302b820e63612e6578616d706c652e636f6d..." } ] } }, "clientIp": "192.0.2.1", "endpoint": "d3lch071jze0cb.cloudfront.net", "distributionId": "E1NXS4MQZH501R", "connectionId": "NpvTe1925xfj24a67sPQr7ae42BIq03FGhJJKfrQYWZcWZFp96SIIg==" }

Formato di risposta di Connection Functions

La funzione di connessione deve restituire un oggetto di risposta che indichi se consentire o negare la connessione. Utilizza i metodi di supporto per prendere decisioni sulla connessione:

function connectionHandler(connection) { // Helper methods to allow or deny connections if (/* some logic to determine if function should allow connection */) { connection.allow(); } else { connection.deny(); } }

A differenza delle funzioni di richiesta e risposta del visualizzatore, le funzioni di connessione non possono modificare le richieste o le risposte HTTP. Possono solo consentire o negare la connessione TLS.

CloudFront Funzioni di connessione, funzionalità JavaScript di runtime.

CloudFront Le funzioni di connessione utilizzano il JavaScript runtime CloudFront Functions 2.0, che fornisce un ambiente sicuro e ad alte prestazioni ottimizzato specificamente per i carichi di lavoro di convalida dei certificati. Il runtime è progettato per iniziare in meno di millisecondi e gestire milioni di esecuzioni simultanee sulla rete edge globale. CloudFront

L'ambiente di runtime include un supporto linguistico completo: JavaScript

  • Supporto ECMAScript 2020 (ES11): JavaScript funzionalità moderne tra cui il concatenamento opzionale (?.) e coalescenza nulla (??)

  • Built-in oggetti: JavaScript oggetti standard come Object, Array, JSON, Math e Date

  • Registrazione della console: utilizza console.log () per il debug e il monitoraggio delle decisioni di convalida dei certificati. I log sono disponibili in tempo reale durante i test e possono aiutare a risolvere i problemi della logica di convalida in fase di sviluppo

  • KeyValueStore integrazione: accesso nativo CloudFront KeyValueStore per operazioni di ricerca dei dati ultraveloci, che consente il controllo in tempo reale della revoca dei certificati, la convalida della lista consentita del dispositivo e il recupero della configurazione specifica del tenant

Le funzioni di connessione sono ottimizzate per scenari di convalida dei certificati ad alte prestazioni. Il runtime gestisce automaticamente la gestione della memoria, la raccolta dei dati inutili e la pulizia delle risorse per garantire prestazioni costanti su milioni di connessioni simultanee. Tutte le operazioni sono progettate per essere deterministiche e veloci, con KeyValueStore ricerche che in genere vengono completate in microsecondi.

L'ambiente di runtime è completamente isolato tra le esecuzioni delle funzioni, garantendo che non vi siano fughe di dati tra le diverse connessioni client. L'esecuzione di ogni funzione inizia con uno stato pulito e non ha accesso ai risultati di esecuzione precedenti o ai dati del client provenienti da altre connessioni.

CloudFront Metodi e API di supporto per le funzioni di connessione

CloudFront Le funzioni di connessione forniscono metodi di supporto specializzati progettati per semplificare le decisioni di convalida dei certificati e migliorare l'osservabilità. Questi metodi sono ottimizzati per il flusso di lavoro di convalida della connessione e si integrano perfettamente con i sistemi di registrazione e monitoraggio CloudFront delle connessioni.

  • connection.allow () — Consente il proseguimento della connessione TLS. Questo metodo segnala CloudFront di completare l'handshake TLS e consentire al client di stabilire la connessione. Usalo quando la convalida del certificato viene superata e qualsiasi logica di autenticazione personalizzata è soddisfatta

  • connection.deny (): nega la connessione TLS e termina l'handshake. Questo metodo chiude immediatamente la connessione e impedisce il flusso di traffico HTTP. Il client riceverà un errore di connessione TLS. Usalo per certificati non validi, autenticazione fallita o violazioni delle policy

  • connection.log CustomData () — Aggiunge dati personalizzati ai log di connessione (fino a 800 byte di UTF-8 testo). Questo metodo consente di includere i risultati della convalida, i dettagli del certificato o le motivazioni decisionali nei registri di CloudFront connessione per il monitoraggio della sicurezza, il controllo della conformità e la risoluzione dei problemi

Questi metodi forniscono un'interfaccia chiara e dichiarativa per prendere decisioni sulla connessione e registrare le informazioni pertinenti per il monitoraggio e il debug. Lo allow/deny schema garantisce che l'intento della funzione sia chiaro e che CloudFront possa ottimizzare la gestione della connessione in base alla decisione dell'utente. I dati di registrazione personalizzati sono immediatamente disponibili nei registri di CloudFront connessione e possono essere utilizzati con strumenti di analisi dei log per il monitoraggio della sicurezza e le informazioni operative.

Chiama sempre connection.allow () o connection.deny () prima del completamento della funzione. Se non viene chiamato nessuno dei due metodi, CloudFront negherà la connessione per impostazione predefinita come precauzione di sicurezza.

CloudFront Integrazione della funzione di connessione KeyValueStore

CloudFront Le funzioni di connessione possono essere utilizzate CloudFront KeyValueStore per eseguire ricerche di dati ultraveloci per scenari di convalida dei certificati. KeyValueStore è particolarmente potente per Connection Functions perché fornisce un accesso ai dati globale ed eventualmente coerente con tempi di ricerca in microsecondi in tutte le edge location. CloudFront Ciò lo rende ideale per la gestione degli elenchi di revoca dei certificati, degli elenchi consentiti dei dispositivi, delle configurazioni dei tenant e di altri dati di convalida che devono essere accessibili durante gli handshake TLS.

KeyValueStore l'integrazione è progettata specificamente per flussi di lavoro di convalida delle connessioni ad alte prestazioni:

  • kvs Handle.exists (key) — Controlla se esiste una chiave nel file KeyValueStore senza recuperarne il valore. Questo è il metodo più efficiente per scenari di convalida binaria come il controllo della revoca dei certificati, in cui è sufficiente sapere se il numero di serie del certificato è presente in un elenco di revoche

  • kvs Handle.get (key) — Recupera un valore dagli scenari di convalida più KeyValueStore complessi. Usalo quando hai bisogno di accedere ai dati di configurazione, alle regole di convalida o ai metadati associati a un certificato o a un identificatore del dispositivo

KeyValueStore le operazioni sono asincrone e devono essere utilizzate con la sintassi. async/await KeyValueStore Ha un limite di dimensione totale di 10 MB e supporta fino a 10 milioni di coppie chiave-valore. KeyValueStore alla fine i dati sono coerenti in tutte le edge location, con gli aggiornamenti che in genere si propagano in pochi secondi.

Per prestazioni ottimali, struttura le KeyValueStore chiavi per ridurre al minimo le operazioni di ricerca. Utilizza i numeri di serie dei certificati come chiavi per un semplice controllo di revoca o crea chiavi composite che combinano l'hash dell'emittente e il numero di serie per ambienti con più CA. Considera i compromessi tra complessità e KeyValueStore capacità delle chiavi durante la progettazione della struttura dei dati.

Usa async e await

Le funzioni di connessione supportano le operazioni asincrone utilizzando la async/await sintassi, essenziale quando si lavora con operazioni o altre attività asincrone. KeyValueStore Lo async/await schema garantisce che la funzione attenda il completamento delle KeyValueStore ricerche prima di prendere decisioni sulla connessione, mantenendo al contempo le caratteristiche ad alte prestazioni richieste per l'elaborazione dell'handshake TLS.

Un async/await uso corretto è fondamentale per le funzioni di connessione perché le KeyValueStore operazioni, sebbene molto veloci, sono comunque operazioni di rete che richiedono il coordinamento tra l'infrastruttura distribuita. CloudFront Il runtime gestisce automaticamente la risoluzione delle promesse e garantisce che la funzione venga completata entro il limite di esecuzione di 5 millisecondi.

Esempio: Funzione di connessione asincrona con KeyValueStore
import cf from 'cloudfront'; async function connectionHandler(connection) { const kvsHandle = cf.kvs(); // Async operation to check KeyValueStore for certificate revocation const isRevoked = await kvsHandle.exists(connection.clientCertificate.certificates.leaf.serialNumber); if (isRevoked) { // Log the revocation decision with certificate details connection.logCustomData(`REVOKED_CERT:${connection.clientCertificate.certificates.leaf.serialNumber}:${connection.clientCertificate.certificates.leaf.issuer}`); console.log(`Denying connection for revoked certificate: ${connection.clientCertificate.certificates.leaf.serialNumber}`); return connection.deny(); } // Log successful validation for monitoring connection.logCustomData(`VALID_CERT:${connection.clientCertificate.certificates.leaf.serialNumber}`); console.log(`Allowing connection for valid certificate: ${connection.clientCertificate.certificates.leaf.serialNumber}`); return connection.allow(); }

Usa sempre async/await quando KeyValueStore chiami metodi o altre operazioni asincrone. Il runtime di Connection Function gestisce automaticamente la risoluzione delle promesse e garantisce il corretto flusso di esecuzione entro i rigidi vincoli temporali dell'elaborazione dell'handshake TLS. Evita di utilizzare .then () o pattern di callback, poiché async/await forniscono una gestione degli errori più pulita e prestazioni migliori nell'ambiente Connection Function.

Quando si progettano funzioni di connessione asincrone, strutturate il codice per ridurre al minimo il numero di KeyValueStore operazioni ed eseguitele il prima possibile nella logica di convalida. Ciò garantisce le massime prestazioni e riduce il rischio di problemi di timeout durante i periodi di traffico elevato. Prendi in considerazione la possibilità di raggruppare i controlli di convalida correlati e di utilizzare il KeyValueStore metodo più efficiente (exists () vs get ()) per il tuo caso d'uso.

Esempi di codici delle funzioni di connessione

Gli esempi seguenti illustrano i modelli comuni delle funzioni di connessione per diversi scenari di convalida. Utilizzate questi esempi come punti di partenza per le vostre implementazioni di Connection Function.

Esempio: Convalida del certificato del dispositivo

Questo esempio convalida i numeri di serie dei dispositivi e i campi dell'oggetto del certificato per dispositivi IoT, console di gioco e altri scenari di autenticazione dei client:

async function connectionHandler(connection) { // Custom validation: check device serial number format const serialNumber = connection.clientCertificate.certificates.leaf.serialNumber; if (!serialNumber.startsWith("DEV")) { connection.logCustomData(`INVALID_SERIAL:${serialNumber}`); return connection.deny(); } // Validate certificate subject contains required organizational unit const subject = connection.clientCertificate.certificates.leaf.subject; if (!subject.includes("OU=AuthorizedDevices")) { connection.logCustomData(`INVALID_OU:${subject}`); return connection.deny(); } // Allow connection for valid devices connection.logCustomData(`VALID_DEVICE:${serialNumber}`); return connection.allow(); }

Questa funzione esegue più controlli di convalida oltre alla convalida standard dei certificati, tra cui il formato del numero di serie del dispositivo e la verifica dell'unità organizzativa.

Esempio: MTL opzionali con autenticazione mista

Questo esempio gestisce connessioni MTL e non MTLS con politiche di autenticazione diverse:

async function connectionHandler(connection) { if (connection.clientCertificate) { // mTLS connection - enhanced validation for certificate holders const subject = connection.clientCertificate.certificates.leaf.subject; connection.logCustomData(`MTLS_SUCCESS:${subject}:${connection.clientIp}`); console.log(`mTLS connection from: ${subject}`); return connection.allow(); } else { // Non-mTLS connection - apply IP-based restrictions const clientIp = connection.clientIp; // Only allow non-mTLS from specific IP ranges if (clientIp.startsWith("203.0.113.") || clientIp.startsWith("198.51.100.")) { connection.logCustomData(`NON_MTLS_ALLOWED:${clientIp}`); console.log(`Non-mTLS connection allowed from: ${clientIp}`); return connection.allow(); } connection.logCustomData(`NON_MTLS_DENIED:${clientIp}`); return connection.deny(); } }

Questa funzione offre una maggiore sicurezza per i client con certificati mantenendo la compatibilità con i client legacy provenienti da intervalli IP affidabili.