Home > Bazy danych > Bezpieczeństwa kopiowania danych podczas prac programistycznych

Bezpieczeństwa kopiowania danych podczas prac programistycznych

Programując nową wersję aplikacji, często zaczynamy od zrobienia kopii aktualnej wersji systemu produkcyjnego. To kusząca idea, jednak należy pamiętać o pewnych zasadach bezpieczeństwa z tym związanych. Idee jest kusząca – ponieważ budując nowe funkcjonalności testujemy je w warunkach zbliżonych do produkcyjnych. Dzięki temu łatwiej jest wyłapać błędy związane z wydajności i łatwiej jest przeprowadzać testy.

Robiąc kopię bazy danych, należy pamiętać o pewnych zasadach bezpieczeństwa. Gdy kopia danych systemu ma być używana do celów deweloperskich – to należy zniszczyć wszystkie wrażliwe dane w bazie: imiona i nazwiska, hasła, adresy, numery telefonów. Taka kopia danych może być bowiem użyta na laptopach programistów, lub na słabiej zabezpieczonych systemach. Warto więc wypracować pewne procedury w tym zakresie.

Kilka lat temu zaproponowałem następującą procedurę: po wykonaniu kopii wszystkie imiona, hasła, adresy, nazwy i temu podobne dane zostaną zniszczone. Są trzy typy niszczenia.

Niszczenie tekstów i nazw własnych. Dla każdego znaku w ciągu znaków powinien zostać wylosowany inny znak. Czyli na przykład, gdy w bazie danych był ciąg znaków “Antoni Jakubiak” to mógł zostać zastąpiony “Xhkkia Uksbtlka”. Dzięki temu podczas testowania systemu widzimy ciągi znaków na ekranie, i zajmują one mniej więcej tyle samo miejsca co prawdziwe dane. Jest to rozwiązanie nieco lepsze, od kasowania danych lub losowania nowych danych w całości gdyż testuje się wygodniej.

Niszczenie adresów e-mail jest szczególnie ważne. Po pierwsze, adresy e-mail naszych użytkowników nie powinny się gdzieś zgubić. Po drugie, gdy nasz system wysyła e-mail automatycznie, to głupio by były żeby wyszły one z testowego systemy do prawdziwego użytkownika: “Kupiłeś sokowirówkę – obciążyliśmy twoją kartę kredytową”. Uważam, że najlepiej jest zastąpić wszystkie adresy e-mail występujące w bazie danych – własnym adresem e-mail. Podoba sprawa dotyczy numerów telefonów, szczególnie gdy nasz system dzwoni lub automatycznie wysyła SMSy. Gorzej, jeżeli adres e-mail jest polem unikalnym – na przykład loginem. Wtedy trzeba się napracować w stylu: update auth set email=concat(‘mój.adres.email+dev’||next_val(‘jakaś.tam.sekwencja’)||’@gmail.com’. Z całą pewnością jednak warto!

Niszczenie haseł. Hasła w bazie danych zwykle są jakoś zaszyfrowane, jednak ich kradzież, szczególnie połączona z kradzieżą loginu lub e-mail, będzie kompromitująca. Uważam, że hasła najlepiej jest po prostu skasować. W testowej kopii systemu można też ustawić wszystkim użytkownikom jednakowe hasła – jednak lepiej je po prosu skasować zupełnie. Testerzy systemu założą sobie po prostu nowe hasło w procedurze jego odzyskiwania. Oczywiście, jeżeli wcześniej zmieniliśmy adresy e-mail.

Napisanie takiej procedury dobremu programiście znającemu system zajmie na pewno mniej, niż dzień roboczy. Warto, żeby była to procedura półautomatyczna, lub żeby w jakiejś dokumentacji programistycznej systemu została ona zapisana. Warto pilnować, by taka procedura była przestrzegana. Ogólnie, warto pamiętać o tym by pilnować backupów systemu.

Categories: Bazy danych Tags:
  1. September 7th, 2009 at 08:53 | #1

    Warto dodac ze niszczenie o ktorym mowa wypada zrobic na miejscu – kopiowanie i przenoszenie bazy danych z imionami, nazwiskami, adresami jest niezgodne z prawem (patrz ustawa o ochronie danych os). Oczywiscie najlepiej o tym powinny wiedziec firmy ktore posiadaja taka baze.

  2. September 7th, 2009 at 13:30 | #2

    Widzę, że poradnik napisałeś dla władców z wykop.pl ;)
    Co do samych porad: to powinien być standard…ale wiadomo jak się mają standardy programowania ;)

  3. September 7th, 2009 at 14:43 | #3

    @matipl nie napisałem nic nowego. To kilka szybkich myśli które generują koszty. Dokładnie jak ubezpieczenia.

  4. September 7th, 2009 at 20:48 | #4

    Myślę, że dzięki tej liście przynajmniej parę polskich projektów stanie się bardziej bezpiecznych. Zatrzymałbym się przy temacie e-maili, bowiem nie raz już widziałem zwrotki od test@test.pl czy foo@bar.com. Używając np. Springa dobrze jest mieć beana, który w czasie testów wysyła e-maile jedynie do ludzi z własnej firmy, ew. z wcześniej zdefiniowanej whitelisty adresów z różnych serwerów.

  1. No trackbacks yet.

Subscribe without commenting