Du har to alternativer:
-
Kryptografisk kontrol. Med dette kan kun de brugere, der kender adgangskoden, dekryptere dataene. Ulempen er, at brugeren skal indtaste dekrypteringsadgangskoden, hver gang de får adgang til dataene. En rapport skal indeholde en adgangskodeparameter, som brugeren, der kører rapporten, udfylder med adgangskoden til dataadgang. Ansøgningen skal anmode brugeren om adgangskoden. Websteder skal anmode om adgangskode fra besøgende. Og så videre og så videre
-
Adgangskontrol. Dataene er krypteret med en nøgle, som SQL Server selv har adgang til (i sidste ende går ekkryptionskæden helt op til Service Master Key og denne krypteres ved hjælp af DPAPI). Dette giver dig ingen større beskyttelse end at give og nægte SELECT ville give dig:er adgang kontrol, ikke kryptografisk kontrol. En sådan ordning beskytter udelukkende mod utilsigtet tab af medier (nogen finder en disk med din database, eller du mister en bærbar computer med databasen på). Du kan opnå det samme ved at bruge Transparent datakryptering eller kryptering på filniveau (BitLocker ).
Det almindelige datakrypteringsscenarie er at kryptere dataene med en symmetrisk nøgle og derefter kryptere den symmetriske nøgle med en asymmetrisk nøgle (normalt den private nøgle til et certifikat). Den asymmetriske nøgle er så igen krypteret med en adgangskode, og denne adgangskode skal præsenteres, når man forsøger at få adgang til data. Den primære årsag til denne indirektion på to niveauer er ændring af adgangskode:når en adgangskode eller en privat nøgle kompromitteres, bliver den symmetriske nøgle genkrypteret med en anden asymmetrisk nøgle, eller den asymmetriske nøgle krypteres igen med en anden adgangskode. På denne måde er adgangskoden ændret uden at kræve en genkryptering af alle data . Hvis adgangen vil blive givet direkte til den symmetriske nøgle, vil en adgangskodekompromis muligvis kræve genkryptering af alle data , mulige terabyte data.
Hvor de to scenarier, jeg præsenterede, adskiller sig, er, om den asymmetriske nøgle også er eknrypteret med databasens hovednøgle eller ej. Tilfælde 1) er det ikke, tilfælde 2) er det. Dette er alt sammen forklaret i Krypteringshierarki .