Du har två alternativ:
-
Kryptografisk kontroll. Med detta kan endast de användare som känner till lösenordet dekryptera data. Nackdelen är att användaren måste gå in dekrypteringslösenordet varje gång de kommer åt data. En rapport måste innehålla en lösenordsparameter som användaren som kör rapporten fyller i med lösenordet för dataåtkomst. Applikationen måste begära lösenordet från användaren. Webbplatser måste begära lösenord från besökaren. Och så vidare och så vidare
-
Åtkomstkontroll. Datan krypteras med en nyckel som SQL Server själv har tillgång till (i slutändan går ekryptionskedjan ända upp till Service Master Key och denna krypteras med DPAPI). Detta ger dig inget större skydd än att bevilja och neka SELECT skulle ge dig:är åtkomst kontroll, inte kryptografisk kontroll. Ett sådant schema skyddar endast mot oavsiktlig förlust av media (någon hittar en disk med din databas, eller så tappar du en bärbar dator med databasen på). Du kan uppnå samma sak med Transparent Data Encryption eller kryptering på filnivå (BitLocker ).
Det vanliga datakrypteringsscenariot är att kryptera data med en symmetrisk nyckel och sedan kryptera den symmetriska nyckeln med en asymmetrisk nyckel (vanligtvis den privata nyckeln till ett certifikat). Den asymmetriska nyckeln krypteras sedan i sin tur med ett lösenord, och detta lösenord måste presenteras när man försöker komma åt data. Den primära orsaken till denna tvånivåinriktning är lösenordsbyte:när ett lösenord eller en privat nyckel äventyras krypteras den symmetriska nyckeln med en annan asymmetrisk nyckel eller så krypteras den asymmetriska nyckeln med ett annat lösenord. På så sätt har åtkomstlösenordet ändrats utan att det krävs omkryptering av all data . Om åtkomsten skulle beviljas direkt till den symmetriska nyckeln skulle en lösenordskompromiss möjligen kräva att all data krypteras om. , möjliga terabyte data.
Där de två scenarierna jag presenterade skiljer sig åt är om den asymmetriska nyckeln också är ekrypterad med databashuvudnyckeln eller inte. Fall 1) är det inte, fall 2) är det. Allt detta förklaras i krypteringshierarkin .