Procedure consigliate per l'utilizzo dei Servizi Web XML nativi

Quando si utilizza CREATE ENDPOINT (Transact-SQL) per la creazione di endpoint, selezionare AUTHENTICATION=KERBEROS o AUTHENTICATION = INTEGRATED per consentire l'utilizzo della protezione integrata di Windows in Kerberos come tipo di autenticazione di un endpoint. La prima opzione consente di utilizzare esclusivamente Kerberos come modalità di autenticazione dell'endpoint. La seconda opzione consente all'endpoint di supportare sia l'autenticazione NTLM, sia quella Kerberos.

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

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

Dopo aver creato gli endpoint necessari per la distribuzione, per proteggerli è necessario impostare le autorizzazioni di connessione agli endpoint tramite istruzioni Transact-SQL quali GRANT CONNECT e ALTER ON ENDPOINT. Quando si assegnano le autorizzazioni di connessione, concedere le autorizzazioni esclusivamente agli utenti specifici o al gruppo specifico a cui è riservato 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 e di interpretare invece correttamente il modello delle autorizzazioni per SQL Server. L'utilizzo di tale modello consente, infatti, di controllare in maniera appropriata l'accesso agli endpoint.

Importante

Il ruolo public è un ruolo di database speciale a cui appartiene ogni utente di SQL Server e include le autorizzazioni di accesso predefinite per tutti gli utenti in grado di accedere al database. Dal momento che si tratta di un ruolo predefinito incorporato di SQL Server, che viene utilizzato per concedere l'accesso a tutti gli utenti (in modo simile alle autorizzazioni Everyone o Authenticated Users di Windows), è necessario utilizzarlo con cautela durante la configurazione delle autorizzazioni in SQL Server.

Per ulteriori informazioni, vedere GRANT - autorizzazioni per endpoint (Transact-SQL).

Il protocollo SSL (Secure Sockets Layer) fornisce 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 di SQL Server, è necessario innanzitutto configurare 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. È possibile, ad esempio, 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 a livello di protezione.

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

Per garantire la massima protezione, è consigliabile utilizzare i servizi Web XML nativi protetti da un firewall. Quando si impostano gli endpoint, accertarsi che i numeri di porta TCP utilizzati per l'accesso HTTP siano protetti dal firewall. Non è infatti consigliabile utilizzare una configurazione di rete in cui i client Internet possano accedere direttamente a un'installazione di SQL Server e che non sia protetta da un firewall. Per ulteriori informazioni, vedere Considerazioni sulla protezione per un'installazione di SQL Server.

L'account Guest è un account utente predefinito incluso nella maggior parte delle versioni di Microsoft Windows. Per impostazione predefinita, è disabilitato in Windows Server 2003 e abilitato in Windows 2000 Server e Windows NT Server 4.0.

Per ridurre il rischio di attacchi di superficie durante l'utilizzo degli endpoint, accertarsi che l'account Guest sia disabilitato sul server in cui viene eseguito SQL Server. Per ulteriori informazioni, vedere l'argomento relativo alla disattivazione o all'attivazione di un account utente locale nella Guida di Windows.

Quando si crea un endpoint tramite CREATE ENDPOINT (Transact-SQL), lo stato predefinito viene interrotto a meno che non venga avviato in modo esplicito specificando STATE = STARTED. Per controllare lo stato di un endpoint esistente, utilizzare ALTER ENDPOINT (Transact-SQL) per specificare STOPPED, STARTED o 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, è opportuno disabilitare gli endpoint o eliminare metodi Web specifici in un endpoint oppure l'endpoint stesso.

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

ALTER ENDPOINT sql_endpoint STATE=DISABLED

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.

Quando si crea o si modifica un endpoint utilizzando CREATE ENDPOINT oppure 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

  La modalità batchTransact-SQL è disabilitata per l'endpoint.

• LOGIN_TYPE = WINDOWS

  Agli utenti degli endpoint è consentita solo l'autenticazione di Windows.

A meno che non sia necessario modificare le impostazioni per supportare l'accesso o la funzionalità ritenuti necessari per la distribuzione dell'applicazione, è consigliabile utilizzare le impostazioni predefinite di queste opzioni, se possibile.

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

I servizi Web XML nativi sono adatti a scenari che presentano i seguenti requisiti:

• L'applicazione restituisce o utilizza dati XML.

• L'applicazione si basa principalmente sulle stored procedure per la logica di business.

• Nell'ambito della soluzione aziendale si desidera integrare un'applicazione di servizi Web 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) o versioni successive potrebbero richiedere requisiti aggiuntivi.

Analogamente, è consigliabile non utilizzare i servizi Web XML nativi in scenari con i seguenti requisiti:

• L'applicazione viene utilizzata per inserire o recuperare dati BLOB (Binary Large Object), quali valori binaryimage o text di grandi dimensioni.

• L'applicazione richiede l'elaborazione delle transazioni in tempo reale e tempi di risposta critici.

• SQL Server viene utilizzato in combinazione con altre applicazioni con un elevato carico di elaborazione, quali le applicazioni TPC Benchmark C (TPC-C).

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

Prima di distribuire i servizi Web XML nativi è 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 dei servizi Web includono sistemi operativi diversi da Windows, utilizzare il formato WSDL semplice. Per gli ambienti basati esclusivamente su sistemi operativi Windows in cui lo sviluppo viene eseguito con MicrosoftVisual Studio 2005, è possibile utilizzare il formato 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.