Czemu wykonywanie kopii zapasowych to już za mało? Backup Encryption – SQL Server Security

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.

Najbardziej istotną rzeczą jest zbieranie właściwych danych i przechowywanie ich w odpowiedni sposób.

Takie słowa padły w podcasie Mała Wielka Firma dotyczącym uczenia maszynowego (MWF 185: Sztuczna inteligencja w małej firmie ? Vladimir Alekseichenko). W pełni się z tym zgadzam. Uważam, że ten zdanie idealnie tutaj pasuje, a na pewno jego druga część. Przechowywanie w odpowiedni sposób. Trzeba spojrzeć na proces przechowywania w szerszym, pełnym kontekście. Również na zabezpieczanie kopii tych danych.

Kiedyś mówiono, że dzielimy ludzi na tych, którzy robią kopie lub robić dopiero będą. Czas się zmieniły i powiedzenie te powinno ewaluować do formy – ludzi dzielimy na tych, którzy szyfrują kopie lub dopiero szyfrować będą.

Szyfrować ale jak?

Począwszy od SQL Server 2014, SQL Server ma możliwość szyfrowania danych podczas tworzenia kopii zapasowej. Implementacja rozwiązania jest dość prosta. Potrzebujemy tylko kilku kroków, aby przygotować naszą instancje SQL Server do korzystania z Backup Encryption. Po pierwsze tworzymy w bazie master klucz Database Master Key oraz certyfikat lub klucz asymetryczny.

Backup Encryption - klucze i certyfikaty

Następnie, bardzo ważne jest, aby wykonać kopię zapasową certyfikatu lub klucza asymetrycznego. Bez certyfikatu lub klucza asymetrycznego nie można przywrócić kopii zapasowej, co powoduje uniemożliwienie użycia pliku kopii zapasowej. Bezpieczne miejsce przechowywania kopii certyfikatu lub klucza musi być poza miejscem składowania kopii zapasowych.

Wszelkie użyte hasła do kluczy i certyfikatów należy składować również w bezpiecznym miejscu.

Mając certyfikat, posiadając kopie klucza DMK i certyfikatu można przejść od razu do wykonania pierwszej szyfrowanej kopii bazy danych.

Instrukcja różni się tylko sekcją ENCRYPTION, gdzie wskazujemy certyfikat. Również definiujemy jeden z dostępnych algorytmów AES 128, AES 192, AES 256, lub 3DES. Najlepszym wyborem na tą chwile jest użycie szyfrowania AES 256. Co prawda silniejsze szyfrowanie wymaga więcej mocy procesora przy szyfrowania, ale także większej mocy procesora w przypadku prób złamania szyfru. Reasumując jest to na tą chwilę najbezpieczniejszy wybór.

Przywracanie kopii

Przywracanie zaszyfrowanej kopii zapasowej nie wymaga żadnych parametrów szyfrowania w instrukcji RESTORE. Wymaga tylko, aby certyfikat lub klucz asymetryczny używany do szyfrowania pliku kopii zapasowej był dostępny w instancji gdzie baza danych będzie przywracana. Dlatego tak ważne jest zadbanie o kopie zapasowe kluczy i certyfikatów.

Trochę liczb i wykresów

Backup Encryption - czas wykonywania backupu
Bez szyfrowania
[sec]
Z szyfrowaniem
[sec]
1 223,141 235,485
2 228,342 227,079
3 223,391 238,125
AVG 224,958 233,563

 

Backup Encryption - szybka kopia zapasowa
Bez szyfrowania
[MB/sec]
Z szyfrowania
[MB/sec]
 1 211,125 208,712
2 212,559 200,031
3 210,886 207,442
AVG 211,523 205,395

 

Backup Encryption - porównanie wykonywanej kopii zapasowej
  Bez szyfrowania
[MB]
Z szyfrowania
[MB]
1 13164,52 13169,9

Bez dwóch zdań, szyfrowany backup trwa dłużej, waży więcej. Jednak uważam, że to nie wielka cena, jaką trzeba ponieść, aby spać spokojnie.

Podsumowanie

Jeśli w Twojej firmie jeszcze nie szyfrujecie kopii to dobry czas, aby zacząć. Być może w Twojej firmie nigdy nie wydarzy się taka sytuacja jak w River City Media, ale jak to mówią przezorny, ubezpieczony. 

Z pasją poświęcam czas na zdobywanie wiedzy w zakresie szeroko rozumianej Data Platform. Zachwycony językiem skryptowym Windows PowerShell. Swoją wiedzę, doświadczenia i spostrzeżenia opisuję na blogu.

2 Comments

Leave a Reply

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *