Panoramica del supporto HTTPS per Microsoft Connected Cache

Questo articolo illustra come configurare il supporto HTTPS per i nodi della cache Connected Cache for Enterprise ed Education.

Panoramica

Con la versione a disponibilità generale di Microsoft Connected Cache for Enterprise, le organizzazioni possono ora configurare i nodi della cache per la distribuzione del contenuto tramite HTTPS. Questo miglioramento consente a Cache connessa di supportare il recapito sicuro delle applicazioni Win32 gestite Intune e, per la prima volta, del contenuto di Microsoft Teams, che richiedono entrambi il trasporto HTTPS. Tutti gli altri tipi di contenuto continueranno a essere recapitati tramite HTTP.

Poiché più servizi Microsoft e editori di terze parti adottano modelli di recapito solo HTTPS, l'abilitazione di HTTPS nel nodo della cache garantisce una compatibilità continua e prestazioni ottimali. Senza il supporto HTTPS, i client che richiedono URL sicuri ignorano la cache connessa e il fallback al recapito dei contenuti tramite le reti di distribuzione di contenuti basate sul cloud, con conseguente aumento dell'utilizzo della larghezza di banda e riduzione dell'efficienza di memorizzazione nella cache.

Per abilitare il recapito HTTPS, gli amministratori devono generare una richiesta di firma del certificato dal computer host, firmarla usando un'autorità di certificazione attendibile e importare di nuovo il certificato firmato nel computer host. Nelle pagine seguenti sono disponibili istruzioni di configurazione guidate e script per gli ambienti Windows e Linux per semplificare questo processo.

Vantaggi dell'abilitazione del supporto HTTPS

L'abilitazione del supporto HTTPS nel nodo Cache connessa garantisce che l'organizzazione rimanga compatibile con i requisiti di recapito dei contenuti Microsoft in continua evoluzione e trae vantaggio da una maggiore sicurezza e prestazioni. I vantaggi principali includono:

• Accesso al contenuto di Microsoft Teams: il contenuto di Microsoft Teams è disponibile solo tramite HTTPS. Senza il supporto HTTPS, Cache connessa non può memorizzare nella cache o distribuire questo contenuto, con conseguente download diretto dal cloud.

• Recapito continuo delle app Win32 gestite da Intune: Microsoft Intune presto imporrà il recapito solo HTTPS per tutte le applicazioni Win32 gestite. I nodi della cache senza supporto HTTPS verranno ignorati e i client torneranno al recapito della rete CDN. La data di imposizione è TBD, ma una volta impostata, i clienti riceveranno una notifica con largo anticipo e avranno tempo sufficiente per adattarsi.

• Riduzione del consumo di larghezza di banda e maggiore efficienza dei costi: memorizzando nella cache il contenuto HTTPS in locale, Cache connessa riduce al minimo la dipendenza dalle reti CDN basate sul cloud, riducendo i costi in uscita e preservando la larghezza di banda di rete, in particolare negli ambienti con vincoli di larghezza di banda.

• Miglioramento del comportamento di sicurezza e conformità: HTTPS garantisce la distribuzione crittografata e autenticata del contenuto, allineandosi ai criteri di sicurezza aziendali e ai requisiti normativi. Protegge da manomissioni, intercettazioni e rappresentazione.

• Supporto facile per il fallback e il doppio protocollo: Cache connessa supporta il recapito SIA HTTP che HTTPS. Se HTTPS non è configurato o ha esito negativo, i client torneranno automaticamente al recapito della rete CDN. Questa funzionalità a doppio protocollo garantisce l'accesso ininterrotto al contenuto senza influire sulle prestazioni di download o sul recapito peer-to-peer (P2P) tramite Ottimizzazione recapito (DO).

Dal supporto solo HTTP a HTTPS

In precedenza, se un client richiedeva contenuto tramite un URL HTTPS, Cache connessa non poteva elaborare la richiesta perché non supportava la gestione dei certificati TLS o l'ascolto sulla porta 443. Di conseguenza, il client ignora immediatamente la cache e recupera il contenuto direttamente dalla rete CDN.

Anche se la cache connessa in precedenza assicurava il recapito sicuro tramite meccanismi come la convalida hash e la protezione avanzata dei contenitori, questi metodi non potevano soddisfare i requisiti dei server di pubblicazione che passano al recapito solo HTTPS. Di conseguenza, La cache connessa supporta ora HTTPS per mantenere la compatibilità con gli standard di pubblicazione in continua evoluzione e per garantire l'accesso continuo sia ai tipi di contenuto esistenti che a nuovi tipi di contenuto.

Configurazione del certificato TLS

Per stabilire una connessione HTTPS sicura, Cache connessa deve presentare un certificato TLS valido ai dispositivi client. Anziché generare e distribuire certificati internamente o affidarsi a certificati autofirmati, che rappresentano rischi operativi e di sicurezza, Connected Cache usa un modello basato su CSR per i motivi seguenti:

• Sicurezza e attendibilità: il metodo CSR consente a Cache connessa di generare una coppia di chiavi pubblica/privata in locale e importare un certificato firmato da un'autorità di certificazione (CA) attendibile. Il rinvio della firma della CA al cliente garantisce che il certificato sia verificabile dai dispositivi client usando gli archivi attendibili della CA preinstallati.

• Compatibilità aziendale: molte organizzazioni gestiscono già la propria infrastruttura PKI. Il modello CSR consente agli amministratori IT di firmare i certificati usando le autorità di certificazione attendibili esistenti, garantendo un'integrazione senza problemi con i criteri di sicurezza aziendali.

• Evitare l'esposizione di chiavi private: generando la coppia di chiavi nel nodo della cache e non esportando mai la chiave privata, il modello CSR garantisce che il materiale crittografico sensibile rimanga sicuro e locale nel nodo della cache.

Manutenzione del certificato TLS

I certificati TLS usati dai nodi di Microsoft Connected Cache richiedono una manutenzione continua per garantire la distribuzione sicura ininterrotta del contenuto. Sono inclusi il monitoraggio della validità del certificato, il rinnovo dei certificati in scadenza e la revoca o la disabilitazione dei certificati quando necessario.

Rinnovare i certificati in scadenza

Per rinnovare un certificato, non è necessario rigenerare la richiesta csr (passaggio 1). È consigliabile firmare nuovamente la richiesta csr esistente (passaggio 2) e importare il certificato risultante usando il comando import (passaggio 3). Se il processo di firma può essere automatizzato, creare uno script che firma e importa in base a una cadenza regolare.

Disabilitare il supporto HTTPS

Se il recapito HTTPS non è più necessario o viene revocato un certificato, eseguire lo script di disabilitazione specificato nel computer host della cache connessa.

Lo script rimuoverà la configurazione HTTPS nel contenitore, ma non eliminerà il certificato, la coppia di chiavi o la richiesta csr dal nodo della cache.

Questa azione ripristina il recapito solo HTTP di Cache connessa. I contenuti che richiedono HTTPS (ad esempio Microsoft Teams, Intune app Win32) non verranno più memorizzati nella cache e verranno restituiti al recapito della rete CDN.

Criteri di conservazione dei certificati

• I certificati attivi vengono conservati per la durata della loro validità.
• I certificati inattivi (scaduti o revocati) vengono conservati per 18 mesi dopo la disattivazione a scopo di controllo e conformità.

Questo criterio è in linea con gli standard di sicurezza e privacy interni di Microsoft e garantisce la tracciabilità dell'utilizzo dei certificati nelle distribuzioni aziendali.

Miglioramenti futuri

Monitorare lo stato del certificato

Cache connessa offre visibilità su tutti i certificati TLS attivi e inattivi tramite il portale di Azure. Ogni voce del certificato include:

• Nome dominio
• Autorità di certificazione emittente (CA)
• Date di emissione e scadenza
• ID identificazione personale

Gli amministratori devono esaminare regolarmente questo elenco per assicurarsi che i certificati rimangano validi e attendibili. La cache connessa genera avvisi quando un certificato si avvicina alla scadenza.

Automazione della firma del certificato

Sebbene l'automazione possa sembrare ideale, Cache connessa non è ancora in grado di eseguire in modo sicuro la firma del certificato per conto dell'organizzazione a causa dei vincoli seguenti:

• Gestione delle credenziali: per automatizzare la firma del certificato è necessario che La cache connessa archivi e gestisse le credenziali per l'accesso alle CA aziendali o pubbliche. Ciò introduce rischi di sicurezza significativi, soprattutto perché La cache connessa viene eseguita in un ambiente Linux in contenitori.

• Modelli PKI aziendali diversi: le aziende usano un'ampia gamma di configurazioni ca, tra cui modelli locali, basati sul cloud e ibridi. L'automazione della firma richiede la connessione alla cache per supportare tutte le varianti, il che è poco pratico e soggetto a errori.

• Principio di sicurezza dei privilegi minimi: la delega della firma all'amministratore IT garantisce che solo il personale autorizzato possa approvare e distribuire i certificati, riducendo la superficie di attacco.

Passaggi successivi