Implementazione di connessioni protette in ADOMD.NET
Quando si implementa una connessione in ADOMD.NET, il metodo di sicurezza utilizzato per la connessione dipende dal valore della proprietà ProtectionLevel della stringa di connessione utilizzata quando si chiama il metodo Open di AdomdConnection.
Alla proprietà ProtectionLevel sono associati quattro livelli di sicurezza, ovvero non autenticato, autenticato, firmato e crittografato. Nella tabella seguente vengono descritti i diversi livelli di sicurezza.
[!NOTA]
Se si sceglie di utilizzare il pool di connessioni al database, quest'ultimo non sarà in grado di gestire la sicurezza poiché per il pool di connessioni al database è necessario che la stringa di connessione sia identica alle connessioni del pool. È pertanto necessario gestire la sicurezza in un altro punto.
Livello di sicurezza |
Valore di ProtectionLevel |
---|---|
|
None |
|
Connect |
|
Pkt Integrity oppure PktIntegrity |
|
Pkt Privacy oppure PktPrivacy |
Non tutti i livelli di sicurezza sono tuttavia disponibili per tutti i tipi di connessioni:
Una connessione TCP può utilizzare uno qualsiasi dei quattro livelli di sicurezza. Se utilizzata con la sicurezza integrata di Windows, una connessione TCP rappresenta infatti il metodo più protetto per connettersi a un'origine dati analitici.
Una connessione HTTP può essere solo autenticata. La proprietà ProtectionLevel deve essere impostata pertanto su Connect.
Una connessione HTTPS può essere solo crittografata. La proprietà ProtectionLevel deve essere impostata pertanto su Pkt Privacy o su PktPrivacy.
Protezione di connessioni TCP
Per una connessione TCP, la proprietà ProtectionLevel supporta tutti i quattro livelli di sicurezza, come illustrato nella tabella seguente.
Valore di ProtectionLevel |
Utilizzo con una connessione TCP |
Risultati |
---|---|---|
None |
Sì |
Specifica di una connessione non autenticata. Il provider richiede un flusso TCP, ma all'utente che effettua la richiesta del flusso non viene applicata alcuna forma di autenticazione. |
Connect |
Sì |
Specifica di una connessione autenticata. Il provider richiede un flusso TCP e successivamente il contesto di sicurezza relativo all'utente che effettua la richiesta del flusso viene autenticato nel server.
Dopo l'esito positivo o negativo dell'autenticazione, il contesto di sicurezza utilizzato per autenticare la connessione viene eliminato. |
Pkt Integrity oppure PktIntegrity |
Sì |
Specifica di una connessione firmata. Il provider richiede un flusso TCP e successivamente il contesto di sicurezza relativo all'utente che effettua la richiesta del flusso viene autenticato nel server.
|
Pkt Privacy oppure PktPrivacy |
Sì |
Specifica di una connessione crittografata.
Il provider richiede un flusso TCP e successivamente il contesto di sicurezza relativo all'utente che effettua la richiesta del flusso viene autenticato nel server.
|
Utilizzo della sicurezza integrata di Windows per la connessione
La sicurezza integrata di Windows rappresenta il modo migliore di stabilire e di proteggere una connessione a un'istanza di Analysis Services. Nella sicurezza integrata di Windows le credenziali di sicurezza, ad esempio un nome utente o una password, non vengono rivelate durante il processo di autenticazione. Per stabilire l'identità, viene invece utilizzato l'ID di sicurezza del processo attualmente in esecuzione. Per la maggior parte delle applicazioni client, tale ID di sicurezza rappresenta l'identità dell'utente attualmente connesso.
Per utilizzare la sicurezza integrata di Windows, per la stringa di connessione è necessario specificare le impostazioni seguenti:
La proprietà Integrated Security non deve essere impostata su alcun valore o deve essere impostata su SSPI.
[!NOTA]
La sicurezza integrata di Windows è disponibile solo per le connessioni TCP poiché le connessioni HTTP devono utilizzare l'impostazione Basic per la proprietà Integrated Security.
La proprietà ProtectionLevel deve essere impostata su Connect, Pkt Integrity o su Pkt Privacy.
Protezione di connessioni HTTP
Per proteggere esternamente comunicazioni HTTP con un'origine dati analitici, è possibile utilizzare HTTPS e SSL (Secure Sockets Layer).
Poiché un provider XMLA utilizza solo connessioni HTTP protette, una connessione HTTP in ADOMD.NET deve essere firmata, come illustrato nella tabella seguente.
Valore di ProtectionLevel |
Utilizzo con HTTP o HTTPS |
---|---|
None |
No |
Connect |
HTTP |
Pkt Integrity oppure PktIntegrity |
No |
Pkt Privacy oppure PktPrivacy |
HTTPS |
Apertura di una connessione HTTP protetta
Nell'esempio seguente viene illustrato come utilizzare ADOMD.NET per aprire una connessione HTTP per il database di esempio AdventureWorksAS di Analysis Services:
Public Function GetAWEncryptedConnection( _
Optional ByVal serverName As String = "https:\\localhost\isapy\msmdpump.dll") _
As AdomdConnection
Dim strConnectionString As String = ""
Dim objConnection As New AdomdConnection
Try
' To establish an encrypted connection, set the
' ProtectionLevel setting to PktPrivacy.
strConnectionString = "DataSource=" & serverName & ";" & _
"Catalog=AdventureWorksAS;" & _
"ProtectionLevel=PktPrivacy;"
' Note that username and password are not supplied here.
' The current security context is used for authentication
' purposes.
objConnection.ConnectionString = strConnectionString
objConnection.Open()
Catch ex As Exception
objConnection = Nothing
Throw ex
Finally
' Return the encrypted connection.
GetAWEncryptedConnection = objConnection
End Try
End Function