Considerazioni sulla protezione per Notification Services

Notification Services implementa la protezione tramite i ruoli del database e account utente del database limitati. In questo argomento vengono descritti il modello di protezione di Notification Services e le procedure consigliate per migliorare la protezione delle applicazioni di Notification Services.

Modello di protezione di Notification Services

Notification Services dispone di un motore che esegue provider di eventi hosted, generatori e server di distribuzione. Può inoltre includere applicazioni client che inviano eventi o gestiscono sottoscrizioni.

Gli account di accesso utilizzati dal motore e dalle applicazioni client si basano sull'autenticazione di Windows o su quella di SQL Server per accedere a SQL Server. L'accesso al database viene concesso tramite account utente del database, quindi le autorizzazioni necessarie per i database dell'istanza e delle applicazioni vengono concesse attraverso l'appartenenza ai ruoli del database di Notification Services.

Nella figura seguente vengono illustrati i ruoli del database che forniscono le autorizzazioni necessarie per ogni componente del motore, per un provider di eventi non hosted e per un'interfaccia per la gestione delle sottoscrizioni.

Le autorizzazioni del database vengono assegnate ai ruoli del database. Gli utenti del database per i singoli componenti ottengono le autorizzazioni necessarie tramite l'appartenenza al ruolo corretto:

• Gli account utilizzati dai provider di eventi ottengono le autorizzazioni attraverso l'appartenenza al ruolo del database NSEventProvider. L'host del provider di eventi esegue provider di eventi hosted. I provider di eventi non hosted sono applicazioni indipendenti.
• Gli account utilizzati dai generatori ottengono le autorizzazioni attraverso l'appartenenza al ruolo del database NSGenerator.
• Gli account utilizzati dai server di distribuzione ottengono le autorizzazioni attraverso l'appartenenza al ruolo del database NSDistributor.
• Gli account utilizzati dalle interfacce per la gestione delle sottoscrizioni ottengono le autorizzazioni attraverso l'appartenenza al ruolo del database NSSubscriberAdmin.

Se un motore esegue provider di eventi hosted, generatori e server di distribuzione, il relativo account può ottenere tutte le autorizzazioni necessarie tramite il ruolo del database NSRunService.

Per informazioni sull'implementazione della protezione per Notification Services, vedere Protezione di Notification Services.

Account aggiuntivi per le azioni condizionali

In Microsoft SQL Server 2005, Notification Services include una nuova funzionalità per le regole di sottoscrizione. Le regole guidate dagli eventi e quelle pianificate possono ora utilizzare le azioni condizionali, che consentono ai sottoscrittori di definire sottoscrizioni più complete specificando clausole di query definite dall'utente.

Poiché le sottoscrizioni basate su azioni condizionali consentono l'utilizzo di clausole di query definite dall'utente, i dati disponibili per la query devono essere limitati. Per questo motivo, è necessario definire un utente del database per l'esecuzione delle azioni condizionali. L'utente del database deve poter eseguire esclusivamente query nelle tabelle e nelle viste che contengono dati di input.

Il generatore attiva le regole contenenti azioni condizionali. Tuttavia, alle query con azioni condizionali vengono applicati ulteriori vincoli tramite l'utente del database specificato. L'utente del database viene specificato quando si definisce un'applicazione di Notification Services.

Per ulteriori informazioni sulle azioni condizionali, vedere Definizione di azioni condizionali.

Autorizzazioni di Windows

Oltre alle autorizzazioni per il database, alcuni componenti richiedono anche altre autorizzazioni di Windows:

• L'account utilizzato per eseguire il motore di Notification Services deve essere un membro del gruppo di Windows SQLServer2005NotificationServicesUser$ComputerName. Ciò consente l'accesso ai file binari di Notification Services utilizzati per l'esecuzione del servizio. Se per eseguire il motore si utilizza il servizio Windows NS$instanceName, Notification Services aggiunge l'account del servizio al gruppo SQLServer2005NotificationServicesUser$ComputerName al momento della registrazione dell'istanza.
  Per qualsiasi altro componente che richieda l'accesso ai file binari di Notification Services può essere necessaria l'appartenenza al gruppo SQLServer2005NotificationServicesUser$ComputerName. Gli assembly e le risorse di Notification Services si trovano nella cache di assembly globale (GAC) e sono disponibili anche senza l'appartenenza al gruppo.
• I provider di eventi richiedono in alcuni casi autorizzazioni per cartelle e altri database. Ad esempio, un provider di eventi di monitoraggio del file system necessita dell'accesso in lettura a un file XSD (XML Schema Definition) che descrive lo schema dell'evento e l'accesso per operazioni di lettura e modifica per la cartella in cui vengono memorizzati i file degli eventi. I provider di eventi di SQL Server necessitano dell'accesso alle tabelle o alle viste del database utilizzate come origini degli eventi.
• Per i server di distribuzione sono necessarie autorizzazioni per recapitare le notifiche al servizio di recapito, ad esempio un server SMTP (Simple Mail Transfer Protocol), SMS (Short Message Service), un server Web o il file system. I server di distribuzione che utilizzano il formattatore del contenuto XSLT devono inoltre disporre dell'accesso ai file XSLT.

Consigli per la protezione

Nelle sezioni riportate di seguito vengono forniti consigli per la protezione del motore di Notification Services, delle interfacce per la gestione delle sottoscrizioni, dei provider di eventi personalizzati, dei protocolli di recapito personalizzati e di altre applicazioni personalizzate.

Motore di Notification Services

Quando si distribuisce un'istanza di Notification Services, è consigliabile considerare i consigli sulla protezione seguenti per il motore di Notification Services:

• Configurare il motore in modo che utilizzi l'autenticazione di Windows per l'accesso al database.

• Eseguire il motore con un account di dominio o locale con privilegi di basso livello. Non utilizzare l'account Sistema locale, Servizio locale o Servizio di rete o altri account del gruppo Administrators.
  È tuttavia possibile che un protocollo di recapito richieda privilegi aggiuntivi per l'account con cui viene eseguito il servizio. Se, ad esempio, si inviano notifiche utilizzando il servizio SMTP di Internet Information Services (IIS) locale, l'account con cui viene eseguito il motore deve essere membro del gruppo Administrators locale (i privilegi di amministratore non sono indispensabili quando si inviano notifiche tramite un servizio SMTP in un computer remoto).

• Quando si distribuisce un'istanza di Notification Services, assicurarsi che tutti i motori dispongano solo delle autorizzazioni necessarie.
  Per le distribuzioni a server singolo, il motore esegue tutti i provider di eventi hosted, i generatori e i server di distribuzione dell'istanza. L'account utilizzato dal motore deve ottenere le autorizzazioni necessarie per il database attraverso l'appartenenza al ruolo del database NSRunService.
  Per le distribuzioni con scalabilità orizzontale, limitare le autorizzazioni dei singoli motori. Ad esempio, se un motore esegue solo provider di eventi, limitare le autorizzazioni del database concesse all'account del motore impostandolo come membro del ruolo del database NSEventProvider e non concedendo all'account altre autorizzazioni per il database o il server. Non utilizzare il ruolo NSRunService, a meno che il motore non esegua tutti i componenti.

  [!NOTA] Per configurare i componenti eseguiti dal motore, specificare il nome di sistema di ogni provider di eventi hosted, generatore e server di distribuzione durante la definizione di un'applicazione.

• Se i componenti del motore di Notification Services e il Motore di database di SQL Server si trovano in server distinti, assicurarsi che il protocollo TCP/IP o Named Pipes sia attivato per il Motore di database. Per migliorare il livello di protezione del Motore di database, la maggior parte dei protocolli di rete è disattivata per impostazione predefinita.

• Assicurarsi che gli account di accesso siano associati a password complesse. Per ulteriori informazioni sulle password complesse, vedere l'argomento relativo alla creazione di password complesse nella documentazione di Microsoft Windows.

• Assicurarsi che tutto il codice eseguito dal motore, ad esempio i provider di eventi personalizzati, i formattatori del contenuto e i protocolli, provenga da un'origine attendibile. Notification Services presuppone che il codice specificato nella configurazione dell'istanza e nella definizione dell'applicazione, utilizzato per creare e aggiornare l'istanza di Notification Services, provenga da un'origine attendibile. Quando si definiscono le applicazioni, utilizzare il nome dell'assembly completo per garantire il caricamento dell'assembly corretto.

• Notification Services non è in grado di convalidare i campi dell'intestazione del protocollo. Pertanto, se l'applicazione utilizza informazioni sul sottoscrittore, sul dispositivo del sottoscrittore o sulle sottoscrizioni in un campo del protocollo, convalidare l'input dell'utente o utilizzare valori definiti dall'applicazione, anziché valori definiti dall'utente. Per esempi di dati dannosi specificati dall'utente, vedere Attacco intrusivo nel codice SQL.

• Proteggere tutte le cartelle contenenti file di configurazione o dati dell'applicazione. Per ulteriori informazioni sulla protezione di file e cartelle, vedere Protezione di file e cartelle.

Hosting del motore di Notification Services

In genere, il motore di Notification Services è un servizio Windows NS$instanceName che viene creato quando si registra l'istanza di Notification Services. È tuttavia possibile ospitare il motore in un'applicazione anziché utilizzare il servizio Windows.

Il motore si connette al Motore di database ed esegue l'istanza di Notification Services. Se si decide di ospitare il motore di Notification Services, assicurarsi di proteggere i file e i valori binari di origine.

Per ulteriori informazioni sull'hosting del motore, vedere Hosting del motore di Notification Services.

Interfacce per la gestione delle sottoscrizioni

Le interfacce per la gestione delle sottoscrizioni consentono agli utenti di sottoscrivere un'applicazione di notifica e creare sottoscrizioni. Le interfacce per la gestione delle sottoscrizioni ottengono le autorizzazioni per i database dell'istanza e delle applicazioni attraverso l'appartenenza al ruolo del database NSSubscriberAdmin.

Quando si sviluppa un'interfaccia per la gestione delle sottoscrizioni, è consigliabile considerare i consigli di protezione seguenti:

• Prima di aggiungere, eliminare o modificare i dati dei sottoscrittori e delle sottoscrizioni, verificare l'identità del sottoscrittore e quindi associarla a un ID del sottoscrittore.
• Tutti gli utenti e le applicazioni il cui account appartiene al ruolo del database NSSubscriberAdmin (o con autorizzazioni effettive più elevate) possono modificare i dati dei sottoscrittori e delle sottoscrizioni. Non concedere autorizzazioni non necessarie e proteggere il nome utente e la password utilizzati dalle interfacce per la gestione delle sottoscrizioni.
• Non archiviare informazioni riservate in formato testo, ad esempio nomi utente e password utilizzati per le connessioni al database da parte dell'applicazione. Utilizzare Data Protection Application Programming Interface (DPAPI) per crittografare le informazioni riservate e quindi memorizzarle nel Registro di sistema.
• Se l'applicazione deve utilizzare informazioni riservate per identificare l'utente, ad esempio il codice fiscale, è possibile associare all'utente un ID non riservato e utilizzare una tabella di ricerca nel database per recuperare le informazioni riservate.

Le interfacce per la gestione delle sottoscrizioni sono spesso applicazioni Web. Per informazioni sulle opzioni di protezione delle applicazioni ASP.NET, vedere Distribuzione di un'interfaccia di gestione delle sottoscrizioni.

Provider di eventi personalizzati

I provider di eventi inviano dati degli eventi alle applicazioni di Notification Services. È possibile sviluppare provider di eventi personalizzati, hosted o non hosted, per le proprie applicazioni. Quando si sviluppa un provider di eventi personalizzato, è consigliabile considerare i consigli di protezione seguenti:

• Assicurarsi che i provider di eventi utilizzino il ruolo del database NSEventProvider per inviare gli eventi.
• Qualsiasi utente o applicazione può inviare eventi se dispone di un nome di provider di eventi valido e di un account appartenente al ruolo del database NSEventProvider o a un ruolo con autorizzazioni effettive superiori nel database dell'applicazione. Non concedere autorizzazioni non necessarie e proteggere il nome utente e la password utilizzati dai provider di eventi non hosted.
• Non memorizzare le informazioni riservate, quali nomi utente e password, in formato testo. Utilizzare DPAPI per crittografare le informazioni sensibili e quindi archiviarle nel Registro di sistema.
• Proteggere tutti i file e i valori binari di origine dei componenti personalizzati.

I provider di eventi hosted personalizzati inviano gli eventi nel contesto dell'host del provider di eventi. Non è necessario fornire credenziali di protezione nel codice del provider di eventi hosted per inviare gli eventi. Il consiglio seguente è valido in particolare per i provider di eventi hosted:

• Durante la creazione dell'applicazione, nella definizione dell'applicazione vengono fornite informazioni sul provider di eventi hosted. Notification Services considera attendibili tutte le informazioni incluse nella definizione dell'applicazione. Utilizzare il nome dell'assembly completo per garantire il caricamento dell'assembly corretto.

I provider di eventi non hosted vengono eseguiti al di fuori del contesto dell'applicazione di Notification Services. Il consiglio seguente è valido in particolare per i provider di eventi non hosted:

• I provider di eventi non hosted non vengono considerati attendibili da Notification Services in modo esplicito. È necessario specificare le credenziali di protezione nel codice del provider di eventi non hosted. L'account specificato deve essere in grado di accedere all'istanza di Motore di database e l'account utente del database associato deve essere membro del ruolo di database NSEventProvider nei database dell'istanza e delle applicazioni.

Protocolli di recapito personalizzati

I protocolli di recapito personalizzati vengono eseguiti nel contesto del motore di Notification Services. Analogamente a tutti i componenti personalizzati, è consigliabile proteggere i file e i valori binari di origine per proteggere le informazioni riservate.

Oggetti NMO (Notification Services Management Objects)

Se si utilizzano gli oggetti NMO (Notification Services Management Objects) per configurare le istanze di Notification Services, definire applicazioni o sviluppare applicazioni amministrative, assicurarsi di proteggere i file di origine e binari. I file contenenti i database dell'istanza e delle applicazioni possono contenere informazioni riservate quali i nomi di server, i nomi utente e le password.

Per ulteriori informazioni sui metadati dell'istanza e delle applicazioni e su altri file, vedere Protezione di file e cartelle.

Vedere anche

Concetti

Protezione di Notification Services

Altre risorse

Considerazioni relative alla protezione di SQL Server
Distribuzione di Notification Services

Guida in linea e informazioni

Assistenza su SQL Server 2005