Procedure consigliate per l'utilizzo dei Servizi Web XML nativi
Questa caratteristica verrà rimossa a partire da una delle prossime versioni di Microsoft SQL Server. Evitare di utilizzare questa caratteristica in un nuovo progetto di sviluppo e prevedere interventi di modifica nelle applicazioni in cui è attualmente implementata.
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 da utilizzare nelle soluzioni aziendali. Scopo di queste indicazioni è contribuire a ottenere i seguenti risultati:
Proteggere l'installazione di SQL Server quando si utilizzano i servizi Web XML nativi.
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.
Procedure consigliate per la sicurezza
Per la distribuzione dei servizi Web XML nativi, attenersi alle procedure consigliate per la sicurezza indicate di seguito:
Utilizzo dell'autenticazione Kerberos.
Limitazione delle autorizzazioni di connessione agli endpoint a utenti o gruppi specifici.
Utilizzo di Secure Socket Layer per lo scambio di dati sensibili.
Utilizzo di un firewall per proteggere SQL Server.
Verifica della disabilitazione dell'account Guest di Windows sul server.
Controllo e aggiornamento dello stato degli endpoint in base alle esigenze.
Utilizzo, in tutti i casi possibili, dei valori predefiniti degli endpoint, che garantiscono la protezione.
Utilizzo dell'autenticazione Kerberos
Quando si utilizza CREATE ENDPOINT (Transact-SQL) per la creazione di endpoint, selezionare AUTHENTICATION=KERBEROS o AUTHENTICATION = INTEGRATED per consentire l'utilizzo della sicurezza 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 sicurezza grazie all'utilizzo di caratteristiche 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.
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 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.
.gif "Nota importante") 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).
Utilizzo di Secure Socket Layer per lo scambio di dati sensibili
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 sicurezza.
Per ulteriori informazioni, vedere Configurazione di un certificato per l'utilizzo con SSL.
Utilizzo di un firewall per proteggere SQL Server
Per garantire la massima sicurezza, è 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 sicurezza per un'installazione di SQL Server.
Verifica della disabilitazione dell'account Guest di Windows sul 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 disabilitazione o all'attivazione di un account utente locale nella Guida di Windows.
Controllo e aggiornamento dello stato degli endpoint in base alle esigenze
Quando si crea un endpoint tramite CREATE ENDPOINT (Transact-SQL), lo stato predefinito viene arrestato 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 arrestare 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
Nota
Una volta disabilitato, l'endpoint può essere riavviato solo dopo aver riavviato il 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, in tutti i casi possibili, dei valori predefiniti degli endpoint, che garantiscono la protezione
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.
Procedure consigliate per le prestazioni
Per la distribuzione dei servizi Web XML nativi, attenersi alle procedure consigliate per le prestazioni indicate di seguito:
Utilizzo di scenari di distribuzione appropriati.
Considerazione dell'utilizzo di risorse server aggiuntive durante la pianificazione di soluzioni SOAP.
Configurazione dell'opzione WSDL indicata per le proprie le esigenze.
Utilizzo di scenari di distribuzione appropriati
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 caratteristiche e l'overhead aggiuntivo di SQL Server 2005 Reporting Services. 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).
Considerazione dell'utilizzo di risorse server aggiuntive durante la pianificazione di soluzioni SOAP
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.
Configurazione dell'opzione WSDL indicata per le proprie esigenze
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 Microsoft Visual 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.