Procedure consigliate per l'utilizzo dei Servizi Web XML nativi

Articolo
12/15/2008

In questo argomento vengono illustrate alcune procedure consigliate da tenere in considerazione nelle fasi di pianificazione e valutazione dei Servizi Web XML nativi di SQL Server 2005 da utilizzare nelle soluzioni aziendali. Scopo di queste indicazioni è contribuire a:

Proteggere l'installazione di SQL Server quando si utilizzano i Servizi Web XML nativi di SQL Server 2005.
Migliorare le prestazioni dell'installazione di SQL Server proponendo linee guida per l'utilizzo, che consentiranno di decidere se per una gestione efficace dell'applicazione è opportuno utilizzare i Servizi Web XML nativi di SQL Server 2005.

Procedure consigliate per la protezione

Per la distribuzione dei Servizi Web XML nativi di SQL Server 2005 tenere presenti le indicazioni seguenti delle procedure consigliate per la protezione:

Utilizzare l'autenticazione Kerberos.
Limitare le autorizzazioni di connessione agli endpoint a utenti o gruppi specifici.
Utilizzare Secure Socket Layer per lo scambio di dati riservati.
Utilizzare un firewall per proteggere l'installazione di SQL Server.
Verificare che l'account Guest di Windows sia disattivato sul server.
Controllare e aggiornare lo stato degli endpoint a seconda dei casi.
Utilizzare valori predefiniti per gli endpoint in tutti i casi possibili.

Utilizzo dell'autenticazione Kerberos

Quando si esegue CREATE ENDPOINT per la creazione di endpoint, selezionare AUTHENTICATION=KERBEROS o AUTHENTICATION = INTEGRATED per attivare la protezione integrata di Windows in Kerberos e utilizzare quest'ultimo come tipo di autenticazione in un endpoint. La prima opzione consentirà di utilizzare esclusivamente Kerberos come modalità di autenticazione dell'endpoint. Con la seconda l'endpoint supporterà sia l'autenticazione NTLM che quella Kerberos.

Ai fini dell'autenticazione, il protocollo Kerberos garantisce una maggior protezione grazie all'utilizzo di funzionalità incorporate, quali l'autenticazione reciproca, che prevede l'autenticazione dell'identità di server e client.

Quando si utilizza l'autenticazione Kerberos, SQL Server deve associare un nome SPN (Service Principal Name) all'account in cui viene eseguito. Per ulteriori informazioni, vedere Registrazione di nomi SPN Kerberos utilizzando Http.sys.

Limitazione delle autorizzazioni di connessione agli endpoint a utenti o gruppi specifici

Dopo aver creato gli endpoint necessari per la distribuzione, per proteggerli è necessario impostare le autorizzazioni di connessione tramite istruzioni Transact-SQL quali GRANT CONNECT e ALTER ON ENDPOINT. Durante l'assegnazione di autorizzazioni di connessione, concedere le autorizzazioni esclusivamente agli utenti specifici o al gruppo specifico riservato per l'accesso agli endpoint in SQL Server.

È in genere opportuno limitare le autorizzazioni in modo da consentire solo a singoli utenti di connettersi agli endpoint. È consigliabile non concedere l'accesso al ruolo public, ma comprendere il modello di autorizzazioni per SQL Server prima di scegliere. Tale modello consente di controllare in modo razionale l'accesso agli endpoint.

Importante:
Il ruolo public è uno ruolo speciale del database a cui appartiene ogni utente di SQL Server e include le autorizzazioni predefinite di accesso per tutti gli utenti che accedono al database. Questo ruolo di database rappresenta un ruolo predefinito incorporato in SQL Server e viene utilizzato per concedere l'accesso a tutti, in modo simile alle autorizzazioni Everyone o Authenticated Users di Windows. È quindi necessario utilizzarlo con particolare cautela durante la configurazione delle autorizzazioni in SQL Server.

Il ruolo public è uno ruolo speciale del database a cui appartiene ogni utente di SQL Server e include le autorizzazioni predefinite di accesso per tutti gli utenti che accedono al database. Questo ruolo di database rappresenta un ruolo predefinito incorporato in SQL Server e viene utilizzato per concedere l'accesso a tutti, in modo simile alle autorizzazioni Everyone o Authenticated Users di Windows. È quindi necessario utilizzarlo con particolare cautela durante la configurazione delle autorizzazioni in SQL Server.

Per ulteriori informazioni, vedere GRANT Endpoint Permissions (Transact-SQL).

Utilizzo di Secure Socket Layer per lo scambio di dati riservati

Il protocollo SSL (Secure Sockets Layer) offre il supporto per la crittografia e la decrittografia dei dati tramite un'interfaccia socket TCP/IP (combinazione di indirizzo IP e numero di porta TCP) protetta. Per disporre della crittografia SSL con gli endpoint SQL Server, è necessario configurare dapprima un certificato.

Quando si registra un certificato per la porta SSL predefinita 443, tenere presente che lo stesso certificato potrebbe essere condiviso anche da altre applicazioni. È ad esempio possibile che la stessa porta venga utilizzata anche per l'hosting del traffico SSL di Internet Information Services (IIS) e che pertanto questa configurazione possa interessare gli utenti di IIS. La condivisione della porta SSL e dei relativi certificati può inoltre presentare implicazioni relativamente alla protezione.

Per ulteriori informazioni, vedere Configurazione di un certificato per l'utilizzo con SSL.

Utilizzo di un firewall per proteggere l'installazione di SQL Server

Per garantire la massima protezione, è consigliabile utilizzare un firewall con i Servizi Web XML nativi di SQL Server 2005. Durante l'impostazione degli endpoint, accertarsi che i numeri di porta TCP utilizzati per l'accesso HTTP siano protetti tramite firewall. Non è infatti consigliabile utilizzare una configurazione di rete in cui client Internet possano accedere direttamente a un'installazione di SQL Server e che non disponga della protezione tramite firewall. Per ulteriori informazioni, vedere Considerazioni sulla protezione per un'installazione di SQL Server.

Verifica dell'attivazione dell'account Guest di Windows sul server

L'account Guest è un account utente incorporato incluso nella maggior parte delle versioni di Microsoft Windows. Per impostazione predefinita, è disattivato in e attivato in e .

Per ridurre il rischio di attacchi di superficie durante l'utilizzo degli endpoint, è opportuno verificare che l'account Guest sia disattivato sul server in cui viene eseguito SQL Server. Per ulteriori informazioni, vedere l'argomento "Per disattivare o attivare un account utente locale" nella Guida in linea di Windows.

Controllo e aggiornamento dello stato degli endpoint a seconda dei casi

Quando si crea un endpoint tramite CREATE ENDPOINT, lo stato predefinito viene interrotto a meno che non viene avviato in modo esplicito specificando STATE = STARTED. Per controllare lo stato di un endpoint esistente, utilizzare ALTER ENDPOINT e specificare una delle opzioni STOPPED, STARTED e DISABLED.

Utilizzare ad esempio le istruzioni seguenti per avviare o interrompere l'endpoint sql_endpoint creato in precedenza:

ALTER ENDPOINT sql_endpoint STATE=STARTED

ALTER ENDPOINT sql_endpoint STATE=STOPPED

Se non si prevede di utilizzarli, è inoltre opportuno disattivare gli endpoint o eliminare metodi Web specifici in un endpoint oppure l'endpoint stesso.

Nell'esempio seguente viene illustrata la disattivazione di un endpoint:

ALTER ENDPOINT sql_endpoint STATE=DISABLED

[!NOTA] Un endpoint disattivato può essere riavviato solo dopo il riavvio del servizio SQL Server (MSSQLServer).

Per eliminare un metodo Web da un endpoint, utilizzare un'istruzione simile a quella seguente:

ALTER ENDPOINT sql_endpoint

FOR SOAP

(

DROP WEBMETHOD 'SayHello'

)

Per eliminare un endpoint, utilizzare DROP ENDPOINT.

Utilizzo di valori predefiniti per gli endpoint in tutti i casi possibili

Quando si crea o si modifica un endpoint utilizzando CREATE ENDPOINT o ALTER ENDPOINT, vengono applicate le impostazioni predefinite delle opzioni riportate di seguito a meno che non ne vengano definite altre in modo esplicito:

BATCHES = DISABLED
Transact-SQL La modalità batch è disattivata per l'endpoint.
LOGIN_TYPE = WINDOWS
Agli utenti degli endpoint è consentita solo l'autenticazione Windows.

A meno che non sia necessario modificare queste impostazioni per supportare accesso o funzionalità che si ritiene necessarie per la distribuzione dell'applicazione, è consigliabile utilizzare i valori predefiniti in tutti i casi possibili.

Per informazioni sulla scelta di un algoritmo di crittografia, vedere Scelta di un algoritmo di crittografia.

Procedure consigliate per le prestazioni

Per la distribuzione dei Servizi Web XML nativi di SQL Server 2005 tenere presenti le indicazioni seguenti delle procedure consigliate per le prestazioni:

Utilizzare gli scenari di distribuzione appropriati.
Considerare l'utilizzo di risorse server aggiuntive durante la pianificazione di soluzioni SOAP.
Configurare l'opzione WSDL appropriata a seconda delle esigenze.

Utilizzo degli scenari di distribuzione appropriati

I Servizi Web XML nativi di SQL Server 2005 sono adatti a scenari con i requisiti seguenti:

L'applicazione in uso restituisce o richiede dati XML.
L'applicazione si basa principalmente sulle stored procedure per la regola business.
Nell'ambito della soluzione aziendale si desidera integrare un'applicazione per un servizio Web ospitato da SQL Server con altre applicazioni di servizi Web per raggiungere gli obiettivi di un'architettura orientata ai servizi (Service Oriented Architecture, SOA).
Si desidera individuare un'alternativa caratterizzata da prestazioni migliori per la soluzione SQLXML di livello medio che consenta di distribuire contestualmente servizi Web sullo stesso server.
Si desidera creare e pubblicare un report statico per un sito Web Intranet in cui il ricco set di funzionalità e l'overhead aggiuntivo di SQL Server 2005 Reporting Services (SSRS) possono comportare requisiti aggiuntivi.

Analogamente, è consigliabile non utilizzare i Servizi Web XML nativi di SQL Server 2005 in scenari con i requisiti seguenti:

L'applicazione viene utilizzata per inserire o recuperare dati BLOB (Binary Large Object), ad esempio valori binaryimage o text elevati.
L'applicazione richiede l'elaborazione delle transazioni in tempo reale e tempi di risposta critici per le strategie aziendali.
SQL Server viene utilizzato congiuntamente ad altre applicazioni a elevato utilizzo delle risorse di elaborazione, quali le applicazioni TPC Benchmark C (TPC-C).

Utilizzo di risorse server aggiuntive durante la pianificazione di soluzioni SOAP

Per un'adeguata pianificazione della capacità, tenere presente che, a differenza di quelle del protocollo Tabular Data Stream (TDS), le prestazioni del protocollo SOAP variano a seconda dell'applicazione e possono comportare un ulteriore overhead delle risorse del server. Nel corso dei test preliminari di SQL Server 2005 eseguiti dal team di prodotto di SQL Server, l'intervallo di attesa per l'accesso basato su SOAP è risultato dal 20 al 30% superiore rispetto a quello per l'accesso basato su TDS in scenari in cui venivano restituiti documenti XML di grandi dimensioni.

Configurazione dell'opzione WSDL appropriata a seconda delle esigenze

Prima di distribuire i Servizi Web XML nativi di SQL Server 2005 è opportuno determinare l'opzione WSDL appropriata da utilizzare per supportare tutti i client e i sistemi operativi necessari nell'ambito della soluzione.

Per garantire la massima interoperabilità in ambienti eterogenei in cui i client di servizi Web includono sistemi operativi non Windows, utilizzare il documento WSDL semplice. Per gli ambienti basati solo su sistemi operativi Windows in cui si intende sviluppare con Microsoft Visual Studio 2005, è possibile utilizzare il documento WSDL predefinito per accedere al complesso supporto dei tipi incluso in Visual Studio 2005.

In alcune circostanze, per garantire l'interoperabilità con client SOAP di terze parti è necessario un formato WSDL personalizzato. Per ulteriori informazioni, vedere Implementazione di supporto WSDL personalizzato.

Vedere anche

Condividi tramite