W tym wpisie będę ponownie poruszać się po obszarach bezpieczeństwa i ograniczania dostępu do danych. Mowa konkretnie będzie o Row-Level Security, który umożliwia nadawanie uprawnień do konkretnych wierszy w zależności np:
Słyszałeś o firmie River City Media? Ja nie słyszałbym gdyby nie zasłynęła z faktu, że na początku 2017 roku przyczyniła się prawdopodobnie do największego wycieku danych. Największego, bo mowa o 1,4 miliarda emaili wraz z imionami, nazwiskami, adresami zamieszkania oraz adresami IP. Wszystko to przez przypadkowe udostępnienie kopii zapasowej. Można powiedzieć zdarza się, błąd, nie popełnia ich tylko ten, kto nic nie robi. Jednak z takich incydentów trzeba wyciągać wnioski i uczyć się jak jeszcze lepiej chronić swoje dane i dane „swoich” firm.
Ponownie kontynuuje tematykę Always Encrypted. W tym wpisie chce pokazać, co dokładniej jest wykonywane w momencie kliknięcia Finish kreatora który omawiałem ostatnio. Myślę, że można z tego wyciągnąć całkiem ciekawe wnioski.
W poprzednim wpisie przedstawiłem podstawowe pojęcia związane z technologią z Always Encrypted. Wszystko to po to, aby w tym wpisie przejść przez kreator umożliwiający implementacje tego rozwiązania.
Kreator umożliwia stworzenie wymaganych klucze i skonfigurowane szyfrowanie dla wybranych kolumn. Również dla kolumn które wypełnione są już danymi. Sporo to upraszcza, bo jednak dużo większym wyzwaniem jest implementacja nowego rozwiązania dla istniejących systemów w organizacji niż wykonywanie tego samego dla nowych projektów.
Always Encrypted nowa funkcja dostarczona z SQL Server 2016, szyfruję dane w zdefiniowanych kolumnach. W odróżnieniu od TDE lub Cell Level Encryption te rozwiązanie kompleksowe, ponieważ szyfruję dane w spoczynku, w pamięci oraz podczas transmisji. Szyfrowanie i odszyfrowanie następuję dopiero po stronie klienta, w aplikacji końcowej. Z względu, na specyfikę działania Always Encrypted wymaga zastosowania odpowiedniego sterownika po stronie aplikacji klienckiej.