Sicurezza RPC su HTTP

RPC su HTTP offre tre tipi di sicurezza oltre alla sicurezza RPC standard, il che comporta la protezione RPC sul traffico HTTP una sola volta da RPC e quindi protetto tramite il meccanismo di tunneling fornito da RPC su HTTP. Per una descrizione dei meccanismi di sicurezza RPC standard, vedere Sicurezza. Il meccanismo di tunneling RPC su HTTP aggiunge la normale sicurezza RPC nel modo seguente:

• Fornisce sicurezza tramite IIS (disponibile solo per RPC su HTTP v2).
• Fornisce la crittografia SSL e la verifica del proxy RPC (autenticazione reciproca). Disponibile anche solo in RPC su HTTP v2.
• Fornisce restrizioni sulla deviazione a livello di proxy RPC che consente ai computer nella rete server di ricevere RPC tramite chiamate HTTP.

Ognuna di queste tre funzionalità di sicurezza è descritta in modo più dettagliato nelle sezioni seguenti.

Autenticazione IIS

RPC su HTTP può sfruttare il normale meccanismo di autenticazione di IIS. La directory virtuale per il proxy RPC può essere configurata usando il nodo Rpc nel sito Web predefinito nello snap-in MMC IIS:

IIS può essere configurato per disabilitare l'accesso anonimo e richiedere l'autenticazione per la directory virtuale per il proxy RPC. A tale scopo, fare clic con il pulsante destro del mouse sul nodo Rpc e selezionare Proprietà. Selezionare la scheda Sicurezza directory e fare clic sul pulsante Modifica nel gruppo Autenticazione e Controllo di accesso, come illustrato di seguito:

Sebbene sia possibile usare RPC su HTTP anche quando la directory virtuale proxy RPC consente l'accesso anonimo, Microsoft consiglia vivamente di disabilitare l'accesso anonimo a tale directory virtuale per motivi di sicurezza. Invece, per RPC su HTTP abilitare l'autenticazione di base, l'autenticazione integrata di Windows o entrambi. Tenere presente che solo RPC su HTTP v2 è in grado di eseguire l'autenticazione con il proxy RPC che richiede l'autenticazione di base o integrata di Windows; RPC su HTTP v1 non sarà in grado di connettersi se l'accesso anonimo non è consentito è disabilitato. Poiché RPC su HTTP v2 è l'implementazione più sicura e affidabile, usando una versione di Windows che la supporta migliorerà la sicurezza delle installazioni.

Nota

Per impostazione predefinita, la directory virtuale proxy RPC è contrassegnata per consentire l'accesso anonimo. Tuttavia, il proxy RPC per RPC su HTTP v2 rifiuta le richieste non autenticate per impostazione predefinita.

 

Crittografia del traffico

RPC su HTTP può crittografare il traffico tra il client RPC su HTTP e il proxy RPC con SSL. Il traffico tra il proxy RPC e RPC su server HTTP viene crittografato usando i normali meccanismi di sicurezza RPC e non usa SSL (anche se viene scelto SSL tra il client e il proxy RPC). Ciò è dovuto al fatto che tale parte del traffico si sposta all'interno della rete di un'organizzazione e dietro un firewall.

Il traffico tra il client RPC su HTTP e il proxy RPC, che in genere viaggia su Internet, può essere crittografato con SSL oltre a quale meccanismo di crittografia è stato scelto per RPC. In questo caso, il traffico su Internet della route diventa crittografato in modo doubly. La crittografia del traffico tramite il proxy RPC fornisce una difesa secondaria, nel caso in cui il proxy RPC o altri computer nella rete perimetrale siano compromessi. Poiché il proxy RPC non è in grado di decrittografare il livello di crittografia secondario, il proxy RPC non ha accesso ai dati inviati. Per altre informazioni, vedere RPC over HTTP Deployment Consigli . La crittografia SSL è disponibile solo con RPC su HTTP v2.

Limitazione di RPC su chiamate HTTP a determinati computer

La configurazione di sicurezza di IIS è basata su intervalli di porte e computer consentiti. La funzionalità di utilizzo di RPC su HTTP è controllata da due voci del Registro di sistema nel computer che esegue IIS e il proxy RPC. La prima voce è un flag che attiva/disattiva la funzionalità proxy RPC. Il secondo è un elenco facoltativo di computer a cui il proxy può inoltrare chiamate RPC.

Per impostazione predefinita, un client che contatta il proxy RPC per eseguire il tunneling rpc su chiamate HTTP non può accedere ad alcun processo del server RPC, ad eccezione dei processi rpc su server HTTP in esecuzione nello stesso computer del proxy RPC. Se il flag ENABLED non è definito o impostato su un valore zero, IIS disabilita il proxy RPC. Se il flag ENABLED è definito e impostato su un valore diverso da zero, un client può connettersi a RPC su server HTTP nel computer che esegue IIS. Per consentire al client di eseguire il tunneling a un processo RPC su server HTTP in un altro computer, è necessario aggiungere una voce del Registro di sistema all'elenco di RPC su server HTTP del computer IIS.

I server RPC non possono accettare RPC su chiamate HTTP, a meno che non abbiano richiesto specificamente RPC di rimanere in ascolto su RPC su HTTP.

Nell'esempio seguente viene illustrato come configurare il Registro di sistema per consentire ai client di connettersi ai server in Internet:

HKEY_LOCAL_MACHINE\
   Software\Microsoft\Rpc\RpcProxy\Enabled:REG_DWORD
   Software\Microsoft\Rpc\RpcProxy\ValidPorts:REG_SZ

La voce ValidPorts è una voce REG_SZ contenente un elenco di computer a cui il proxy RPC IIS è autorizzato a inoltrare le chiamate RPC e le porte da usare per connettersi ai server RPC. La voce REG_SZ assume il formato seguente: Rosco:593; Rosco:2000-8000; Data*:4000-8000.

In questo esempio IIS può inoltrare RPC su chiamate HTTP al server "Rosco" sulle porte da 593 e 2000 a 8000. Può anche inviare chiamate a qualsiasi server il cui nome inizia con "Data". Si connetterà alle porte da 4000 a 8000. Inoltre, prima di inoltrare il traffico a una determinata porta sul server RPC su HTTP, il proxy RPC esegue uno scambio di pacchetti speciale con il servizio RPC in ascolto su tale porta per verificare che sia disposto ad accettare richieste su HTTP.

Per un esempio basato su queste impostazioni di esempio, se un servizio RPC è in ascolto sulla porta 4500 sul server "Data1", ma non ha chiamato una delle funzioni RpcServerUseProtseq* con ncacn_http, rifiuterà la richiesta. Questo comportamento offre una protezione aggiuntiva per i server in ascolto su una porta aperta a causa di un errore di configurazione; a meno che il server non abbia richiesto specificamente di rimanere in ascolto su RPC su HTTP, non riceverà chiamate provenienti dall'esterno del firewall.

Le voci nella chiave ValidPorts devono corrispondere esattamente al server RPC su HTTP richiesto dal client (non fa distinzione tra maiuscole e minuscole). Per semplificare l'elaborazione, il proxy RPC non esegue la canonizzazione del nome fornito dal client RPC su HTTP. Pertanto, se il client richiede rosco.microsoft.com e in ValidPorts contiene solo Rosco, il proxy RPC non corrisponderà ai nomi, anche se entrambi i nomi possono fare riferimento allo stesso computer. Inoltre, se l'indirizzo IP di Rosco è 66.77.88.99 e il client chiede 66.77.88.99, ma la chiave ValidPorts contiene solo Rosco, il proxy RPC rifiuterà la connessione. Se un client può richiedere rpc su server HTTP in base al nome o all'indirizzo IP, inserire entrambi nella chiave ValidPorts .

Nota

Sebbene RPC sia abilitato per IPv6, il proxy RPC non supporta gli indirizzi IPv6 nella chiave ValidPorts . Se si usa IPv6 per connettere il proxy RPC e rpc su server HTTP, è possibile usare solo i nomi DNS.

 

IIS legge le voci del Registro di sistema Enabled e ValidPorts all'avvio. Inoltre, RPC su HTTP rilegge il contenuto della chiave ValidPorts circa ogni 5 minuti. Se la voce ValidPorts viene modificata, le modifiche vengono implementate entro 5 minuti.

RPC su HTTP v1: il servizio WEB deve essere arrestato e riavviato usando Internet Service Manager per i nuovi valori nelle voci del Registro di sistema da implementare.