Protezione di SQL Server

Gli account e i ruoli di SQL Server svolgono una funzione critica nella protezione di Windows Server AppFabric. AppFabric utilizza le entità di SQL Server per controllare l'accesso agli archivi e alle tabelle che contengono i dati derivanti dalle operazioni di monitoraggio nonché i dati di controllo dello stato correlati al salvataggio permanente del flusso di lavoro. AppFabric non fornisce strumenti che facilitano la gestione della protezione del database. Per creare account e ruoli e per visualizzare, manipolare e assegnare le autorizzazioni appropriate agli oggetti del database, utilizzare il supporto strumenti fornito con l'installazione del database. Per SQL Server, utilizzare SQL Server Management Studio.

AppFabric utilizza gli account di accesso e i ruoli di SQL Server per gestire l'accesso a risorse quali l'archivio di salvataggi permanenti, l'archivio di monitoraggio e le stored procedure. I criteri di protezione vengono applicati tramite autorizzazioni su tabelle e stored procedure che determinano gli utenti che possono leggere, scrivere ed eseguire operazioni amministrative negli schemi di monitoraggio e salvataggio permanente. Ogni schema viene protetto con il proprio insieme di criteri di protezione.

Modalità di autenticazione di SQL Server e AppFabric

SQL Server fornice due metodi per proteggere l'autenticazione dei server di database di AppFabric:

• Autenticazione di Windows. Fornita dalla modalità di autenticazione predefinita di Windows. È la modalità di autenticazione più sicura per SQL Server. Quando viene configurata la modalità Autenticazione di Windows, SQL Server utilizza la protezione Windows per convalidare l'account e la password dell'account utente richiedente con il sistema operativo Windows.

• Autenticazione di SQL Server Fornita dalla modalità di autenticazione predefinita di SQL Server. Esiste solo per motivi di compatibilità con le versioni precedenti per applicazioni e utenti che devono accedere a SQL Server utilizzando un account utente e una password espliciti. È la modalità meno sicura.

Sebbene sia possibile utilizzare AppFabric con l'autenticazione di SQL Server, il passaggio di nomi account utente e password espliciti incorporati in una stringa di connessione di un file di configurazione non è un metodo di protezione consigliato. Si consiglia vivamente di configurare SQL Server per l'utilizzo della modalità Autenticazione di Windows ed evitare la modalità Autenticazione di SQL Server.

Se è necessario utilizzare la modalità Autenticazione di SQL Server, oppure se si utilizza un provider non SQL Server che richiede la memorizzazione delle password nella stringa di connessione, è opportuno utilizzare stringhe di connessione crittografate. AppFabric non è in grado di elaborare le sezioni crittografate di un file di configurazione, pertanto non è possibile visualizzare o aggiungere una stringa di connessione crittografata tramite gli strumenti di AppFabric.

Se è necessario proteggere i file di configurazione di un computer AppFabric crittografando parti di un file di configurazione, utilizzare lo strumento per la registrazione IIS ASP.NET (Aspnet_regiis.exe). È possibile utilizzare questo strumento per crittografare (opzione -pe) le sezioni sensibili alla protezione di un file di configurazione esternamente all'interfaccia utente di AppFabric. Qualora, successivamente, risulti necessario visualizzare o modificare tali sezioni, è possibile decrittografarle utilizzando l'opzione -pd. Decrittografando le sezioni è possibile visualizzarle negli strumenti di AppFabric, apportare modifiche, salvarle nel file di configurazione e crittografare di nuovo le sezioni tramite lo strumento esterno a AppFabric. Per ulteriori informazioni sull'utilizzo dello strumento per la registrazione IIS ASP.NET IIS, consultare ASP.NET IIS Registration Tool (Aspnet_regiis.exe) (https://go.microsoft.com/fwlink/?LinkId=169163).

Account di accesso di SQL Server

Un account di accesso di SQL Server richiede un account utente e una password per accedere al computer SQL Server. Tali requisiti vengono definiti diritto di accesso o autenticazione nella terminologia di Windows relativa alla protezione. SQL Server utilizza l'Autenticazione integrata di Windows per l'identificazione delle entità di protezione che tentano di accedere alle risorse del database AppFabric e di gestire tali risorse. Per collegarsi a SQL Server utilizzando l'autenticazione integrata di Windows, è necessario fornire l'identità di Windows con cui è in esecuzione l'applicazione. È necessario, inoltre, accertarsi che all'identità sia stato concesso l'accesso appropriato al database di SQL Server.

Per effettuare azioni di configurazione o operative nei dati o schemi di database, l'account di accesso deve essere mappato a un ruolo di SQL Server con autorizzazioni appropriate. Un ruolo di SQL Server funziona come un gruppo Windows. L'appartenenza di un account di accesso a un ruolo di SQL Server ne definisce il controllo sulle attività amministrative e sulle operazioni di database. Un account di accesso può essere membro di più ruoli di database.

Gli account di accesso di SQL Server vengono creati quando si installa AppFabric.

Ruoli di database di SQL Server

SQL Server dispone di tre tipi di ruoli di database: server, applicazione e database Per motivi di completezza, saranno discussi brevemente. AppFabric sfrutta in maniera esclusiva il modello di ruolo di database per gran parte della protezione SQL.

• Ruolo “server” di SQL Server. Un ruolo "server" di SQL Server viene definito al di fuori di eventuali archivi a livello del server. I ruoli di SQL Server sono predefiniti e non possono pertanto essere modificati nel numero o nel contenuto. Un esempio di ruolo server comune è sysadmin. L'appartenenza a questo ruolo fornisce all'account di accesso il controllo completo su tutte le operazioni del database e la possibilità di eseguire qualsiasi operazione sui dati di SQL Server in qualsiasi archivio. AppFabric non utilizza esplicitamente alcun ruolo server nel proprio modello di protezione.

• Ruolo “applicazione” di SQL Server. I ruoli applicazione sono adatti alle più complesse e personalizzate esigenze di protezione di una particolare applicazione. Un archivio può essere utilizzato da più applicazioni con l'esigenza comune di applicare la protezione per i dati all'accesso da parte di un'applicazione. AppFabric non utilizza esplicitamente alcun ruolo applicazione nel proprio modello di protezione.

• Ruolo "database" di SQL Server. AppFabric utilizza ampiamente il ruolo database. Esistono tre tipi di ruoli database: pubblico, definito dall'utente e fisso. Per motivi di completezza, saranno discussi brevemente. AppFabric sfrutta in maniera esclusiva il modello di ruolo database definito dall'utente per gran parte della protezione di SQL Server.

  Esistono tre tipi di ruoli database di SQL Server:

  • Pubblico. Il ruolo database pubblico contiene le autorizzazioni di accesso predefinite per tutti gli utenti del database. Di conseguenza, ogni account di accesso creato da AppFabric è un membro di questo ruolo.

  • Fisso. Come i ruoli "server" di SQL Server (ad esempio, sysadmin), i ruoli database fissi non possono essere modificati. Diversamente dai ruoli server, che esistono al livello del server, i ruoli database esistono al livello del database per ciascun archivio. Un esempio di ruolo database fisso è db_owner. È possibile aggiungere o rimuovere gli account utente di accesso di SQL Server per un ruolo database fisso.

  • Definito dall'utente. AppFabric crea specifici ruoli database definiti dall'utente durante l'installazione. Il programma di installazione di AppFabric non inserisce esplicitamente alcun account di Windows o account di accesso di SQL Server in tali ruoli database definiti dall'utente. È necessario aggiungere esplicitamente gli account utilizzando gli strumenti di gestione di SQL Server.

AppFabric utilizza i ruoli database di SQL Server per controllare l'accesso ai relativi archivi di dati di monitoraggio e salvataggi permanenti. Quando si inizializza un nuovo archivio di dati di monitoraggio o di salvataggi permanenti di AppFabric, diversi ruoli di protezione database definiti dall'utente vengono creati durante l'installazione. Nella tabella seguente viene mostrato il modo in cui tali ruoli vengono mappati agli account di accesso di SQL Server riportati nella sezione precedente.

Se si utilizza Active Directory, si consiglia vivamente di progettare i ruoli di protezione di AppFabric utilizzando account di dominio per semplificare la protezione tra più computer. Come amministratore di AppFabric, è possibile creare esplicitamente due account di gruppo personalizzati tramite Active Directory per i ruoli di amministratori e osservatori. Ad esempio, è possibile denominarli “DOMAIN\MyAppFabricAdmins” e “DOMAIN\MyAppFabricObservers”.   È possibile concedere quindi le autorizzazioni appropriate a entrambi i gruppi di ciascun computer aggiungendo manualmente il gruppo “DOMAIN\MyAppFabricAdmins” al gruppo LOCALHOST\AS_Administrators e il gruppo “DOMAIN\MyAppFabricObservers” al gruppo LOCALHOST\AS_Observers. Servizio di raccolta eventi e Servizio Gestione flussi di lavoro devono essere eseguiti con account di dominio membri del gruppo “DOMAIN\MyAppFabricAdmins”.

SicurezzaNota
I cmdlet di AppFabric che utilizzano SQL Server si basano su questi ruoli database di SQL Server per autenticarne le identità durante l'esecuzione.

Archiviazione database non SQL Server

I ruoli database di SQL Server sono specifici di SQL Server. Tuttavia, se non si utilizza il provider SQL Server predefinito e di sceglie di scrivere il proprio provider personalizzato, è possibile mappare la funzionalità di questi ruoli al relativo equivalente funzionale nel proprio archivio NON SQL Server.

Per gli archivi non SQL Server, per proteggere l'accesso a un archivio, è necessario includere l'ID utente e la password in una stringa di connessione. Sebbene il passaggio di ID utente e password nelle stringhe di connessione a un archivio sia consentito, ad esempio con l'autenticazione di SQL Server, non è una procedura consigliata. Se il passaggio di ID utente e password nella stringa di connessione è l'unica possibilità, fare attenzione a seguire le procedure di protezione appropriate di .NET Framework per accertarsi che le stringhe di connessione siano crittografate.

  2011-12-05