Share via

Scelta della posizione in cui applicare la sicurezza

  • Articolo

I compromessi sono intrinseci nell'applicazione della sicurezza. Un database può essere una posizione naturale per mettere la logica di sicurezza, dato che in definitiva i dati sono la cosa più importante da proteggere. Tuttavia, questa operazione ha implicazioni significative sulle prestazioni. L'applicazione della sicurezza nel database può essere molto costosa, ridimensiona in modo non ottimale ed è inflessibile.

Applicazione della sicurezza nel livello intermedio

La regola generale da seguire con le applicazioni multilivello scalabili che usano COM+ è che, quando possibile, è consigliabile applicare la sicurezza dettagliata nell'applicazione COM+ al livello intermedio. In questo modo è possibile sfruttare completamente i servizi scalabili forniti da COM+. Applicare l'autenticazione al database solo quando è assolutamente necessario e valutare completamente le implicazioni sulle prestazioni di questa operazione.

La situazione ottimale consiste nel proteggere le tabelle di database in modo che l'applicazione COM+ sia in grado di accedervi con la propria identità. Il database deve solo autenticare l'applicazione COM+ e considerarlo attendibile per autenticare e autorizzare correttamente i client che accederanno ai dati. I vantaggi di questo approccio sono i seguenti:

  • Consente il pool di connessioni tra tutti i client, perché le connessioni sono completamente generiche.
  • In genere ottimizza l'accesso ai dati, spesso un punto di soffocamento problematico durante il ridimensionamento delle applicazioni.
  • Può ridurre al minimo il sovraccarico della logica per l'applicazione della sicurezza, in particolare se è possibile usare la sicurezza dichiarativa basata su ruoli.
  • Può offrire una grande flessibilità in un criterio di sicurezza. È possibile configurarlo e riconfigurarlo facilmente, come descritto in Sicurezza basata su ruoli Amministrazione istration.

Tuttavia, come illustrato in Progettazione efficace dei ruoli, mentre i ruoli possono essere applicati in modo semplice ed efficace ad alcune relazioni tra dati utente, non sono una soluzione universale per le decisioni relative all'accesso alla sicurezza.

Applicazione della sicurezza nel database

Nonostante la preferenza a applicare la sicurezza a livello intermedio, esistono diversi motivi per applicare la sicurezza nel database, ad esempio:

  • Non hai una scelta, forse per motivi legacy o forse perché la decisione non è semplicemente nelle tue mani.
  • Il database è accessibile da un'ampia gamma di applicazioni e la relativa sicurezza non può essere configurata in base a una singola applicazione.
  • Un database può essere protetto in modo prevedibile. Se si mantengono dati critici per l'organizzazione in un database, è possibile disegnare un carro stretto intorno a esso e aiutare a controllare chi riesce a vederlo.
  • L'autenticazione dei client originali nel database consente la registrazione dettagliata di chi ha eseguito le operazioni nel database.
  • Alcuni dati sono associati in modo innato a determinati utenti e la logica di prendere decisioni di accesso estremamente dettagliate potrebbe essere eseguita in modo più efficiente nel database stesso, vicino ai dati.

Quando si ha il lusso di progettare la sicurezza del database e l'applicazione COM+ in parallelo, la maggior parte di questi problemi riguarda le caratteristiche dei dati stessi e la sua relazione con gli utenti che vi accedono. Con i dati accessibili da categorie stimabili di utenti, è efficiente controllare l'accesso nel livello intermedio usando i ruoli. Con i dati strettamente associati a classi di utenti molto piccole, tali relazioni devono essere spesso espresse con i dati stessi e pertanto è necessario applicare una certa sicurezza nel database.

Implicazioni sulle prestazioni dell'applicazione della sicurezza nel database

Se si autenticano o autorizzano gli utenti nel database, è necessario propagare l'identità utente al database per supportare questa operazione. Se il database considera attendibile l'applicazione di livello intermedio a tale scopo, è possibile passare le informazioni di sicurezza utente nei parametri. In caso contrario, la chiamata al database deve essere effettuata con l'identità dell'utente, ovvero l'applicazione server deve rappresentare il client. Ciò può avere implicazioni sulle prestazioni, ad esempio le seguenti:

  • La rappresentazione del client può essere molto più lenta rispetto all'esecuzione della chiamata direttamente nell'identità dell'applicazione. Per altri dettagli, vedere Rappresentazione client e delega.
  • Non è possibile eseguire il pool di una connessione di database eseguita con un'identità utente specifica.
  • L'aggiunta di logica nel database stesso comporta il rischio di creare un collo di bottiglia di ridimensionamento.

Scenari di base per la protezione dei dati nelle applicazioni multilivello

Sicurezza delle applicazioni multilivello