Jaka jest dobra praktyka bezpieczeństwa przy przechowywaniu krytycznej bazy danych na laptopach programistów?

33

Mamy kilka danych:

  1. Programiści potrzebują repliki produkcyjnej bazy danych na swoich komputerach.
  2. Programiści mają hasło do wspomnianej bazy danych w plikach App.config.
  3. Nie chcemy, aby dane we wspomnianej bazie danych były zagrożone.

Kilka sugerowanych rozwiązań i ich wady:

  1. Szyfrowanie całego dysku. To rozwiązuje wszystkie problemy, ale obniża wydajność laptopa, a my jesteśmy start-upem, więc nie mamy pieniędzy na konie mechaniczne.
  2. Tworzenie maszyny wirtualnej z zaszyfrowanym dyskiem twardym i przechowywanie na niej bazy danych. Działa dobrze, ale nie pomaga zbytnio, ponieważ w Web.Config jest hasło.
  3. Rozwiązanie nr 2+ wymagające od programisty wpisania hasła do bazy danych za każdym razem, gdy coś uruchomi. Rozwiązuje wszystkie problemy, ale jest bardzo kłopotliwy dla programistów, którzy czasami uruchamiają aplikację kilka razy na minutę. Ponadto mamy wiele aplikacji, które łączą się z tą samą bazą danych, a implementacja ekranu hasła będzie musiała się różnić w poszczególnych.

Moje pytanie brzmi: czy istnieje jakieś wspólne rozwiązanie takiego problemu lub sugestie, jak sprawić, by którekolwiek z powyższych rozwiązań było wykonalne?

database security Svarog
źródło
26
Czy rzeczywiście zmierzyłeś wpływ szyfrowania całego dysku na wydajność? Używałem go na dość starych laptopach i nie zauważyłem żadnego znaczącego obniżenia wydajności. Nowoczesne systemy operacyjne są całkiem dobre w buforowaniu, a dyski i tak są wolne. Najgorszy wpływ ma prawdopodobnie na żywotność baterii.
5gon12eder
69
Szczerze mówiąc, nie brzmi to jak właściwe podejście. 1) Dlaczego deweloperzy potrzebują produkcyjnej bazy danych na swoich komputerach? Czy nie ma sposobu na tworzenie danych zastępczych dla bazy danych deweloperów? 2) Dlaczego hasło jest przechowywane jako zwykły tekst w pliku konfiguracyjnym? Wygląda na to, że próbujesz doprowadzić bandaida do wadliwego procesu. Być może możesz zrewidować to, co faktycznie działa na komputerach deweloperów, a także sposób przechowywania hasła do bazy danych.
Thomas Stringer,
2
Istnieją powody, dla których programiści potrzebują produkcyjnej bazy danych. Ze względów historycznych ich praca jest zbyt połączona z danymi na żywo. Wiem, że to zły pomysł, a jeśli nie znajdziemy dobrego rozwiązania, przejdziemy do fałszywych danych. Na razie staram się znaleźć dobre rozwiązanie bez tego.
Svarog,
6
Żaden użytkownik komputera MacBook Pro nie może stwierdzić z szybkości komputera, czy szyfrowanie całego dysku jest włączone, czy wyłączone na dysku SSD. Nie ma różnicy. Brak, który możesz zauważyć. Może taki, który można zmierzyć, ale nic, co jest zauważalne.
gnasher729,
5
I drugi komentarz @ gnasher729. Po wielu latach stosowania pełnego szyfrowania dysku w środowiskach regulowanych (finansowych i opiece zdrowotnej) nie musi to zauważalnie obniżać wydajności. Wiele osób porusza inne ważne kwestie, ale w środowisku HIPAA trudno jest mieć rozsądną politykę bez pełnego szyfrowania dysku, nawet jeśli bazy danych nie są umieszczone na notebookach. E-maile i inne fragmenty danych często tam trafiają. Zamień pliki ... itd ... Pełne szyfrowanie dysku nie jest odpowiednie, ale zwykle jest konieczne.
joshp,

Odpowiedzi:

100

Nie tylko nie chcesz kopii produkcyjnej bazy danych, ale może ona być nielegalna. Na przykład w Stanach Zjednoczonych nie można przenosić danych produkcyjnych ze środowiska produkcyjnego, jeśli zawierają one informacje regulowane, takie jak osobiste dane zdrowotne, dane finansowe, a nawet dane, które można wykorzystać w przypadku kradzieży tożsamości. Jeśli to zrobisz, możesz zostać ukarany grzywną, stracić swoją zgodność, a zatem zostać poddany bardziej agresywnym audytom, a nawet zostać wymieniony w pozwie.

Jeśli potrzebujesz danych w skali produkcyjnej do testowania, masz kilka opcji:

  1. Wygeneruj wszystkie fikcyjne dane. To trudniejsze niż się wydaje. Zaskakująco trudne i pracochłonne jest generowanie sensownych wyimaginowanych danych.
  2. Anonimizuj swoje dane produkcyjne. Może to być łatwiejsze, ale należy zachować ostrożność.

Dla opcji nr 2

  • W środowisku produkcyjnym autoryzowany administrator bazy danych wykonuje kopię danych produkcyjnych.
  • Wciąż w środowisku produkcyjnym ten sam autoryzowany administrator uruchamia procedurę, która anonimizuje wszystkie wrażliwe dane. W razie wątpliwości anonimizuj.
  • Tylko wtedy dane powinny zostać przeniesione do innego środowiska.
Corbin March
źródło
31
a hasło do kopii bazy danych nie powinno być takie samo jak hasło do wersji produkcyjnej .....
Lightness Races z Monicą
3
„Na przykład w Stanach Zjednoczonych nie można przenosić danych produkcyjnych ze środowiska produkcyjnego, jeśli zawierają one informacje regulowane” Co? Czy masz na to źródło? Czy nie można na przykład używać kopii zapasowych produkcyjnej bazy danych jako danych dla środowiska pomostowego lub testowania dbs na komputerach programistów?
niania
12
@nanny Nie, jeśli korzystasz z danych regulowanych. Na przykład pracowałem zgodnie z rozporządzeniem HIPAA. HIPAA stwierdza: „Podmioty objęte muszą również wdrożyć rozsądne minimalne niezbędne zasady i procedury, które ograniczają ilość chronionych informacji zdrowotnych wykorzystywanych, ujawnianych i wymaganych w określonych celach”. Minimalna niezbędna polityka jest otwarta na pewną interpretację. Nasz radca prawny zasugerował ścisłą interpretację, która zawierałaby poufne dane zawarte tam, gdzie programiści nie mogli uzyskać do nich dostępu. (Czy jest to naprawdę konieczne, aby wykonywać swoje zadania?) Ta sama ostrożność dotyczy zgodności finansowej, takiej jak PCI.
Corbin, marzec
4
@nanny Weź to jako wiadomość od nie-prawnika, ale jak rozumiem, zasady różnią się znacznie w zależności od stanu. Radca prawny, z którym pracuję, zawsze zachowuje ostrożność. Ściśle mówiąc, deweloperzy nie potrzebują rzeczywistych numerów SSN do wykonywania swoich obowiązków, więc doradca sugeruje, że te numery SSN żyją w chronionym środowisku, w którym deweloperzy nie mają do nich dostępu. Ale nie słuchaj mnie. Prawnik dbający o twoje długoterminowe interesy będzie najlepszym źródłem.
Corbin, marzec
5
Ściśle mówiąc, nie jest NIELEGALNE być nieostrożnym w stosunku do PPI, chyba że wykonujesz prace rządowe, wtedy tytuł 32 wchodzi w grę ... ale jest to poważne narażenie na odpowiedzialność cywilną. w przeciwnym razie jest to świetna odpowiedź. pozytywnie oceniany.
dwoz
9

Czy możesz przynajmniej dać programistom maszyny wirtualne w twoim centrum danych, do których mogą oni RD na tę pracę? Chociaż naprawdę powinny pracować z danymi nieprodukcyjnymi, byłoby to bezpieczniejsze, dopóki nie możesz się tam dostać, ponieważ dane nie byłyby przechowywane na łatwo kradzionych laptopach.

Brian Knoblauch
źródło
brzmi to bardziej jak komentarz, patrz Jak odpowiedzieć
gnat
5
@gnat, ta odpowiedź może być krótka, ale jest to bardzo dobra sugerowana alternatywa.
Nie bądź takim pedantem, @gnat ... to dobra odpowiedź.
dwoz
@ dan1111 To jest problem. To nie jest odpowiedź. To alternatywa. To sprawia, że ​​jest to komentarz, a nie odpowiedź.
corsiKa
2
@ corsiKa, odpowiedzi kwestionujące przesłankę pytania są dozwolone i często są bardzo dobrymi odpowiedziami. Zobacz problem XY: meta.stackexchange.com/questions/66377/what-is-the-xy-problem . Bardziej szczegółowe odpowiedzi mogą być lepsze, ale to wciąż odpowiedź.
8

Jeśli to możliwe, zmień sposób pracy.

Jak zauważyli inni:

  • Wykorzystywanie danych produkcyjnych do programowania nie jest dobrą praktyką.
  • Przechowywanie hasła w postaci zwykłego tekstu nie jest dobrą praktyką.

Oba z nich narażają Cię na znaczne ryzyko i należy je zmienić, jeśli to możliwe. Powinieneś przynajmniej poważnie ocenić, jaki byłby koszt wprowadzenia tych zmian. Jeśli jest to zależność zewnętrzna, której nie możesz zmienić, zastanów się nad podniesieniem tej kwestii w odniesieniu do każdego, kto ma taką moc.

Jednak w prawdziwym świecie zmiana tego może być niemożliwa. Zakładając, że to, co robisz, jest legalne, być może będziesz musiał żyć z tym porozumieniem (przynajmniej tymczasowo).

Jeśli jest to naprawdę konieczne, wystarczy wykonać szyfrowanie całego dysku.

Biorąc pod uwagę ryzyko, musisz użyć najlepszej dostępnej opcji bezpieczeństwa i to wszystko. Jeśli jest hit wydajności, żyj z nim. Jest to koszt pracy z wrażliwymi danymi.

Gdybym był twoim klientem, nie byłbym pod wrażeniem, że zdecydowałeś się nie używać najlepszej dostępnej opcji bezpieczeństwa z moimi danymi, ponieważ spowodowało to nieznaczne spowolnienie laptopów.


źródło
1
„Nie idealne rozwiązanie” należy zmienić na „całkowicie głupi pomysł” IMO
Darkhogg,
@Darkhogg, masz rację, powinno być silniejsze. Edytowane. Nie posunąłbym się tak daleko, jak „całkowicie głupi”, nie wiedząc, jak wrażliwa jest ta aplikacja. W praktyce ryzyko kompromisu jest bardzo, bardzo niskie w przypadku korzystania z pełnego szyfrowania dysku, więc można zrobić z tego zbyt wiele ze względów bezpieczeństwa.
Zgadzam się z pierwszym punktem, ale nie drugim. Jeśli nie przechowujesz hasła w postaci zwykłego tekstu, gdzie je przechowujesz (1) zaszyfrowany tekst lub (2) mózg. Jeśli (1), to gdzie przechowujesz hasło do szyfru (wykryto nieskończoną pętlę). Jeśli (2), to mam nadzieję, że lubisz budzić się o 2:00 rano i wpisać hasło, aby ponownie uruchomić usługę.
emory
1

Odpowiedź Corbina Marcha jest całkiem dobra, dodam tylko dodatkowy szczegół, że generalnie masz dwie klasy danych w produkcyjnej bazie danych: metadane systemu / aplikacji; oraz dane użytkownika klienta / dane transakcyjne. Ten ostatni NIGDY nie powinien być używany w środowisku programistycznym „takim, jakim jest”.

Rzeczywiście bardzo rzadko potrzebujesz rzeczywistych informacji o kliencie produkcyjnym, aby opracowywać.

Jeśli jednak problem, który opisuje OP w tym przypadku, dotyczy poufnych danych handlowych lub w inny sposób wysoce zastrzeżonych danych systemowych, które nie obejmują danych klientów, jest to wymagane przez programistów ... podejście do bezpieczeństwa musi obejmować schemat, który nie ma hasło db przechowywane gdzieś w postaci tekstu jawnego w pliku zasobów. Musi istnieć mechanizm, na przykład, aby ponownie wygenerować codzienne hasło, które nie jest przechowywane na dysku.

dwoz
źródło
5
client user data/transactional data... should NEVER be used in a development environment "as is." - Brzmi dla mnie niewykonalnie. Problemy programistyczne związane z produkcją związane z danymi konkretnego klienta byłyby nierozwiązywalne w ramach tego porozumienia. Ponadto rzeczywiste dane na żywo są niezwykle przydatne z punktu widzenia testowania. Działania prywatyzacyjne lub anonimowe powinny koncentrować się wyłącznie na danych, które są specjalnie regulowane.
Robert Harvey,
@RobertHarvey, jest to niewykonalne tylko wtedy, gdy nie można odtworzyć problemu produkcyjnego w środowisku deweloperskim. Myślę, że przez całą moją karierę (długą) mogę liczyć na kilka palców, ile razy odpowiednio oczyszczone dane testowe nie były wystarczające do odtworzenia błędu produkcyjnego. „Zastrzeżone informacje biznesowe” wykraczają daleko poza numery SSN i ​​numery CC!
dwoz
4
Ale jeśli zamierzasz pójść tą drogą, będziesz mieć ludzi IT, którzy nie mogą wykonywać swojej pracy, ponieważ nie mają dostępu administracyjnego do wszystkiego. Przyznaję, że powoduje to potencjalne problemy Snowdena, ale nie widzę realnej alternatywy poza zatrudnieniem osób, którym można zaufać. Sarbanes Oxley i HIPAA bardzo ściśle określają, jakiego rodzaju dane należy sekwestrować i nie obejmują one „wszystkich danych produkcyjnych”, co nie jest dalekie. To powiedziawszy, nie sądzę, aby jakiekolwiek dane produkcyjne kiedykolwiek istniały na laptopach w roamingu.
Robert Harvey,
1
-1 dla NIGDY. Twoje bardziej dopracowane komentarze są lepsze niż odpowiedź; powinieneś je w to edytować.
1
@ dan1111 możemy się zgodzić, aby się nie zgodzić. Dane klienta „takie, jakie są”, NIGDY NIGDY nie powinny być wykorzystywane w systemach deweloperskich. Zawsze należy go zdezynfekować. Nie wierzysz w to, ponieważ jeszcze nie ugryzła cię ta wściekła mangusta ... i tak to jest, kiedy to się stanie. Wściekły, szalony gryzoń, który zamierza pobrać twoją krew. Posłuchaj mojej rady, unikaj wściekłej mangusty.
dwoz
1

Nie podajesz, która baza danych i które środowisko.

Jeśli możesz korzystać ze zintegrowanych zabezpieczeń, baza danych nie będzie dostępna bez zalogowania jako ten użytkownik. Tak, jeśli dane znajdują się na twardym dysku, można je zhakować, ale jest to obrona pierwszego poziomu.

App.config sprawia, że ​​myślę, że może to być .NET. Umieść config w pendrivie i przeczytaj go z pendrive'a. Jeśli dysk nie jest obecny, wpisz hasło użytkownika.

Czy istnieje sposób na przechowywanie hasła w pamięci przy jego pierwszym wprowadzeniu i odczytaniu przez wszystkich. Znowu nie podajesz środowiska. Pliki mapowane w pamięci

W przypadku niektórych TDE można przechowywać klucz na oddzielnym urządzeniu, aby dostarczały go tylko po uruchomieniu serwera bazy danych.

paparazzo
źródło
0

Jedną z możliwych opcji jest wykonanie kopii bazy danych i przeszukanie tej kopii za pomocą skryptu, aby uzyskać inne dane niż te, które są aktualnie w produkcji. Nie skończysz z tymi samymi danymi co produkcja Ale będziesz miał taką samą skalę.

Jason Crosby
źródło
wydaje się to tylko powtórzyć punkt poczyniony i wyjaśniony w najlepszej odpowiedzi około tygodnia temu
komara