Integrazione del firewall dell'hub di Azure Stack

È consigliabile usare un dispositivo firewall per proteggere l'hub di Azure Stack. I firewall consentono di difendersi in caso di attacchi DDOS (Distributed Denial of Service), di rilevamento delle intrusioni e di ispezione del contenuto. Possono tuttavia diventare anche un collo di bottiglia della velocità effettiva per i servizi di archiviazione di Azure, ad esempio BLOB, tabelle e code.

Se viene usata una modalità di distribuzione disconnessa, è necessario pubblicare l'endpoint AD FS. Per altre informazioni, vedere l'articolo Sull'identità di integrazione del data center.

Gli endpoint di Azure Resource Manager (amministratore), del portale di amministrazione e di Key Vault (amministratore) non richiedono necessariamente la pubblicazione esterna. Ad esempio, come provider di servizi, è possibile limitare la superficie di attacco amministrando solo l'hub di Azure Stack dall'interno della rete e non da Internet.

Per le organizzazioni aziendali, la rete esterna può essere la rete aziendale esistente. In questo scenario è necessario pubblicare gli endpoint per gestire l'hub di Azure Stack dalla rete aziendale.

Network Address Translation

Nat (Network Address Translation) è il metodo consigliato per consentire alla macchina virtuale di distribuzione (DVM) di accedere alle risorse esterne e a Internet durante la distribuzione, nonché alle macchine virtuali ERCS (Emergency Recovery Console) o all'endpoint con privilegi (PEP) durante la registrazione e la risoluzione dei problemi.

Il NAT può anche offrire un'alternativa agli indirizzi IP pubblici nella rete esterna o agli indirizzi VIP pubblici. Non è tuttavia consigliabile ricorrere a questa soluzione perché limita l'esperienza utente del tenant e aumenta il livello di complessità. Un'opzione possibile consiste in un NAT uno-a-uno che richiede comunque un indirizzo IP pubblico per ogni indirizzo IP utente nel pool. Un'altra opzione consiste in un NAT molti-a-uno che richiede una regola NAT per ogni indirizzo VIP utente per tutte le porte che un utente può usare.

Di seguito sono indicati alcuni degli svantaggi derivanti dall'uso di NAT per un indirizzo VIP pubblico:

• Il NAT comporta un sovraccarico durante la gestione delle regole del firewall perché gli utenti controllano i propri endpoint e le proprie regole di pubblicazione nello stack SDN (Software-Defined Networking). Gli utenti devono contattare l'operatore dell'hub di Azure Stack per pubblicare i propri indirizzi VIP e aggiornare l'elenco delle porte.
• Anche se l'uso del NAT limita l'esperienza utente, consente all'operatore di avere un controllo completo sulla pubblicazione delle richieste.
• Per gli scenari di cloud ibrido con Azure, tenere presente che Azure non supporta la configurazione di un tunnel VPN verso un endpoint tramite NAT.

Intercettazione SSL

È al momento consigliabile disabilitare l'intercettazione SSL (ad esempio l'offload di decrittografia) in tutto il traffico dell'hub di Azure Stack. Se questa funzionalità sarà supportata negli aggiornamenti futuri, verranno fornite indicazioni su come abilitare l'intercettazione SSL per l'hub di Azure Stack.

Scenario di firewall perimetrale

In una distribuzione perimetrale, l'hub di Azure Stack viene distribuito direttamente entro i limiti del router perimetrale o del firewall. Negli scenari di questo tipo, il firewall può trovarsi al di sopra del bordo (Scenario 1) e supportare configurazioni di tipo sia attivo-attivo che attivo-passivo oppure può fungere da dispositivo del bordo (Scenario 2) e supportare solo una configurazione di tipo attivo-attivo basata su ECMP (Equal-Cost Multi-Path) con routing BGP o statico per il failover.

Gli indirizzi IP instradabili pubblici vengono specificati per il pool di indirizzi VIP pubblici dalla rete esterna in fase di distribuzione. In uno scenario perimetrale non è consigliabile usare indirizzi IP instradabili pubblici in qualsiasi altra rete per motivi di sicurezza. Questo scenario consente a un utente di sperimentare l'esperienza cloud autonoma completa come in un cloud pubblico quale Azure.

Scenario di firewall di rete perimetrale o intranet aziendale

In una distribuzione di rete perimetrale o intranet aziendale, l'hub di Azure Stack viene distribuito in un firewall a più zone oppure tra il firewall perimetrale e il firewall di rete aziendale interno. Il traffico viene quindi distribuito tra la rete perimetrale protetta e le zone non protette, come descritto di seguito:

• Zona protetta: si tratta della rete interna che usa indirizzi IP interni o aziendali instradabili. La rete sicura può essere divisa, avere accesso internet in uscita tramite NAT sul firewall ed è in genere accessibile da qualsiasi posizione all'interno del data center tramite la rete interna. Tutte le reti dell'hub di Azure Stack devono trovarsi nella zona protetta, ad eccezione del pool di indirizzi VIP pubblici della rete esterna.
• Zona perimetrale. La rete perimetrale è la zona in cui vengono in genere distribuite app esterne o con connessione a Internet, ad esempio i server Web. In genere viene monitorato da un firewall per evitare attacchi come DDoS e intrusioni (hacking) pur consentendo il traffico in ingresso specificato da Internet. Nella zona della rete perimetrale deve risiedere solo il pool di indirizzi VIP pubblici della rete esterna dell'hub di Azure Stack.
• Zona non protetta. Per zona non protetta si intende la rete esterna, Internet. Non è consigliabile distribuire l'hub di Azure Stack nella zona non protetta.

Altre informazioni

Altre informazioni sulle porte e i protocolli usati dagli endpoint dell'hub di Azure Stack.

Passaggi successivi

Requisiti dell'infrastruttura a chiave pubblica dell'hub di Azure Stack