Condividi tramite

Raccomandazioni per la distribuzione RPC su HTTP

  • Articolo

Questa sezione illustra le procedure consigliate e le configurazioni di distribuzione consigliate per ottenere la massima sicurezza e prestazioni quando si usa RPC su HTTP. Le varie configurazioni trovate qui si applicano a diverse organizzazioni in base a varie dimensioni, budget e requisiti di sicurezza. Ogni configurazione fornisce anche considerazioni sulla distribuzione utili per determinare quali sono i migliori per uno scenario specifico.

Per informazioni sugli scenari RPC con volume elevato su HTTP, vedere Bilanciamento del carico RPC Microsoft.

Le raccomandazioni seguenti si applicano a tutte le configurazioni:

  • Usare le versioni di Windows che supportano RPC su HTTP v2.
  • Inserire IIS nel computer che esegue il proxy RPC in modalità IIS 6.0.
  • Non consentire l'accesso anonimo alla directory virtuale proxy RPC.
  • Non abilitare mai la chiave del Registro di sistema AllowAnonymous.
  • Rendere rpc su client HTTP usare CertificateSubjectField (vedere RpcBindingSetAuthInfoEx per altre informazioni) per verificare che il proxy RPC connesso sia il proxy RPC previsto.
  • Configurare la chiave del Registro di sistema ValidPorts per contenere solo computer a cui i client RPC tramite HTTP si connetteranno.
  • Non usare caratteri jolly nella chiave ValidPorts ; in questo modo può risparmiare tempo, ma una macchina completamente imprevista può adattarsi anche al carattere jolly.
  • Usare SSL nei client RPC su HTTP. Se le linee guida definite in queste sezioni vengono seguite, il client RPC su HTTP non sarà in grado di connettersi senza usare SSL.
  • Configurare RPC su client HTTP per usare crittografia RPC oltre all'uso di SSL. Se il client RPC su HTTP non può raggiungere il KDC, può usare solo Negotiate e NTLM.
  • Configurare i computer client per l'uso di NTLMv2. Impostare la chiave del Registro di sistema LMCompatibilityLevel su 2 o versioni successive. Per altre informazioni sulla chiave LMCompatibilityLevel, vedere msdn.microsoft.com.
  • Eseguire una web farm di computer proxy RPC con la configurazione descritta in precedenza.
  • Distribuire un firewall tra Internet e il proxy RPC.
  • Per prestazioni ottimali, configurare IIS per inviare una risposta breve per i codici di errore non riusciti. Poiché il consumer della risposta IIS è un processo automatizzato, non è necessario inviare spiegazioni descrittive al client; verranno semplicemente ignorati dal client RPC tramite HTTP.

Gli obiettivi di base del proxy RPC da una prospettiva di sicurezza, prestazioni e gestibilità sono i seguenti:

  • Specificare un singolo punto di ingresso per RPC tramite traffico HTTP nella rete del server. La presenza di un singolo punto di ingresso per RPC sul traffico HTTP in una rete server offre due vantaggi principali. Prima di tutto, poiché il proxy RPC si trova in Internet, la maggior parte delle organizzazioni isola tali computer in una rete speciale denominata rete perimetrale non attendibile che è separata dalla normale rete organizzativa. I server in una rete perimetrale non attendibile sono molto gestiti, configurati e monitorati per poter resistere agli attacchi da Internet. Meno computer in una rete perimetrale non attendibile, è più semplice configurare, gestire, monitorare e mantenere sicuri i computer. In secondo luogo, poiché una singola Web farm con proxy RPC installati può essere eseguita in qualsiasi numero di server RPC su HTTP che risiedono nella rete aziendale, è molto opportuno separare il proxy RPC dal server RPC su HTTP e avere il proxy RPC in una rete perimetrale non attendibile. Se il proxy RPC si trova nello stesso computer del server RPC su HTTP, le organizzazioni saranno costrette a inserire tutti i server back-end in una rete perimetrale non attendibile, che renderebbe molto più difficile mantenere sicura la rete perimetrale non attendibile. La separazione del ruolo del proxy RPC e del server RPC tramite HTTP consente alle organizzazioni di mantenere il numero di computer in una rete perimetrale non attendibile gestibile e quindi più sicura.
  • Fungere da fuse di sicurezza per la rete del server. Il proxy RPC è progettato come un fusibile esplorabile per la rete del server, se si verifica un errore nel proxy RPC, viene semplicemente disattivato e quindi protegge il server RPC reale tramite HTTP. Se le procedure consigliate descritte in questa sezione sono state seguite finora, il traffico RPC su HTTP viene crittografato con crittografia RPC oltre a SSL. La crittografia RPC stessa è tra il client e il server, non tra il client e il proxy. Ciò significa che il proxy non capisce e non può decrittografare il traffico RPC ricevuto. Comprende solo alcune sequenze di controllo inviate dal client che gestiscono l'istituzione della connessione, il controllo del flusso e altri dettagli di tunneling. Non ha accesso ai dati inviati dal client RPC tramite HTTP al server. Inoltre, il client RPC su HTTP deve eseguire l'autenticazione indipendente sia nel proxy RPC che nel server RPC tramite HTTP. Ciò fornisce la difesa in profondità. Se il computer proxy RPC viene compromesso, a causa di un errore di configurazione o di una violazione della sicurezza di un certo tipo, i dati che passano sono ancora sicuri dalla manomissione. Un utente malintenzionato che otterrebbe il controllo del proxy RPC può interrompere al massimo il traffico, ma non leggerlo o manometterlo. Questo è il luogo in cui viene eseguito il ruolo di fuse del proxy RPC: è utilizzabile senza la sicurezza del traffico RPC su HTTP compromesso.
  • Distribuire alcuni controlli di accesso e decrittografia tra più computer che eseguono proxy RPC in una Web farm. Funzionando bene in una Web farm, il proxy RPC consente alle organizzazioni di scaricare la decrittografia SSL e alcuni dei controlli di accesso, liberando così una maggiore capacità nel server back-end per l'elaborazione. L'uso di una Web farm di computer proxy RPC consente anche a un'organizzazione di aumentare la capacità di resistere agli attacchi Denial of Service (DoS) aumentando la capacità nei server front-end.

All'interno delle linee guida impostate finora, le organizzazioni hanno ancora scelte. Ogni organizzazione ha scelte e compromessi tra inconvenienti utente, sicurezza e costi:

  • Usare l'autenticazione di base o l'autenticazione integrata di Windows per eseguire l'autenticazione nel proxy RPC? RPC su HTTP supporta attualmente solo NTLM: non supporta Kerberos. Inoltre, se è presente un proxy HTTP o un firewall tra il client RPC su HTTP e il proxy RPC che inserisce il pragma tramite l'intestazione HTTP, l'autenticazione NTLM non funzionerà. In caso contrario, le organizzazioni possono scegliere tra l'autenticazione Basic e NTLM. Il vantaggio dell'autenticazione di base è che è più veloce e semplice e quindi offre meno opportunità per gli attacchi denial of service. Ma NTLM è più sicuro. A seconda delle priorità di un'organizzazione, può scegliere Basic, NTLM o consentire agli utenti di scegliere tra i due. Se viene scelto solo uno, è consigliabile disattivare l'altro dalla directory virtuale proxy RPC per ridurre il rischio di attacco.
  • Usare lo stesso set di credenziali sia per il proxy RPC che per il server RPC tramite HTTP oppure usare credenziali diverse per ognuna? Il compromesso per questa decisione è tra praticità e sicurezza dell'utente. Pochi utenti vogliono immettere più credenziali. Tuttavia, se si verifica una violazione della sicurezza in una rete perimetrale non attendibile, la presenza di set separati di credenziali per il proxy RPC e il server RPC su HTTP offre una protezione aggiuntiva. Si noti che se vengono usate credenziali separate e un set di credenziali è le credenziali di dominio dell'utente, è consigliabile usare le credenziali di dominio dell'utente per il server RPC su HTTP e non per il proxy RPC.