Jak mogę zapobiec przypadkowemu wtargnięciu z produkcyjną bazą danych?


31

Niedawno miałem programistę przypadkowo próbującą przywrócić bazę danych do produkcji, kiedy powinien był przywrócić kopię tymczasową. Jest to łatwe, biorąc pod uwagę, że nazwy db są podobne, tzn. CustomerName_Staging kontra CustomerName_Production.

Idealnie byłoby mieć je na całkowicie osobnych polach, ale jest to kosztowne i, ściśle mówiąc, nie zapobiega temu samemu, jeśli użytkownik połączy się z niewłaściwym polem.

Sam w sobie nie stanowi to problemu z bezpieczeństwem - był to właściwy użytkownik pracujący z bazą danych pomostowych, a jeśli trzeba wykonać prace nad produkcyjną bazą danych, to również on. Chciałbym mieć przedstawiciela ds. Rozmieszczania, który rozwiałby te obawy, ale zespół nie jest na to wystarczająco duży.

Chciałbym usłyszeć porady dotyczące praktyki, konfiguracji i kontroli, jak temu zapobiec.


25
Programiści nie powinni mieć dostępu do zapisu do produkcyjnych baz danych, a najlepiej żadnego dostępu.
Michael Hampton

12
@MichaelHampton - To ja i on. Jestem również programistą. Co sugerujesz?
Chris B. Behrens,

10
Oddzielne konta użytkowników dla każdej roli (dev vs ops / DBA). I mnóstwo ostrożności.
Michael Hampton

2
Radzę, abyś miał swoje środowisko produkcyjne w osobnym pudełku. W przeciwnym razie przemieszczanie i produkcja muszą współdzielić zasoby - dysk, procesor itp. - a jeśli przemieszczanie zmonopolizuje zasób, może ucierpieć środowisko produkcyjne.
Thorbjørn Ravn Andersen

1
Po prostu miej osobne hasła użytkownika / hasła do tych baz danych.
neutrinus

Odpowiedzi:


32

Jeśli robisz to często, zautomatyzuj to. A ponieważ oboje jesteście programistami, pisanie kodu powinno być w waszej sterówce. :) Poważnie ... ale automatyzując, możesz robić takie rzeczy jak:

  • Sprawdź, czy przywracasz na odpowiednim serwerze (tzn. Nie przywracasz dev -> prod)
  • Sprawdź, czy jest to właściwy „typ” bazy danych (w twoim przypadku „inscenizacja” i „produkcja”)
  • Dowiedz się, które kopie zapasowe chcesz przywrócić automatycznie, przeglądając tabele kopii zapasowych w msdb

I tak dalej. Ogranicza Cię tylko wyobraźnia.


1
To ciekawy pomysł ... mamy już kod zarządzający przywracaniem bazy danych (do testów automatycznych). Mogliśmy umieścić warstwę abstrakcji pomiędzy tym, co tylko wskazywało na inscenizację, aby przywrócenie do produkcji było zupełnie innym procesem ...
Chris B. Behrens

11
Teraz myślisz o portalach. :)
Ben Thul,

4
W przypadku zautomatyzowanych zadań, które wpływają na produkcję, lubię dodawać w kroku ręcznym, który wymaga od użytkownika wpisania słowa „produkcja”, aby zmniejszyć prawdopodobieństwo, że myślą, że patrzy np. Na ekwiwalent etapowy.
Joe Lee-Moyet

2
Odrzuciłem głos, ponieważ domyślnie nikt nie powinien mieć dostępu do produkcji. Musisz mieć specjalny proces, aby pobrać hasło prod. Jest to niewygodne, ale naprawdę minimalne.
OliverS,

1
@BenThul Dodanie innego konta w celu uzyskania dostępu do produktu i uczynienie go jeszcze jednym niedogodnym jest nadal dla mnie właściwym rozwiązaniem. Biznesowa potrzeba nie polega na tym, aby DEV zaoszczędził 2 minuty, ale na przywróceniu bazy danych, którą można idealnie przenieść na konto prod.
OliverS,

32

Nie zgadzam się z założeniem pytania - chodzi o bezpieczeństwo - ale nie zgadzam się również z tym, że automatyzacja sama uratuje ten dzień. Zacznę od problemu:

Nie powinieneś być w stanie przypadkowo zrobić nic do produkcji!

Obejmuje to przypadkowe wykonywanie zautomatyzowanych czynności.

Mylisz bezpieczeństwo systemu z pojęciami typu „kto może robić co”. Twoje konta programistyczne powinny mieć możliwość zapisywania tylko na swoich kopiach, serwerze kontroli wersji i bazie danych deweloperów. Jeśli potrafią czytać / zapisywać dane produkcyjne, mogą zostać zhakowane i wykorzystane do kradzieży danych klientów lub (jak wykazano) mogą zostać przypisane do utraty danych klientów.

Musisz zacząć od uporządkowania przepływu pracy.

  • Twoje konta programistów powinny mieć możliwość zapisywania własnych kopii, kontroli wersji i być może przejścia z kontroli wersji do środowiska testowego.

  • Użytkownicy kopii zapasowych powinni mieć możliwość tylko odczytu z produkcji i zapisu w magazynie kopii zapasowych (który powinien być odpowiednio chroniony).

  • Wszelkie inne operacje odczytu / zapisu podczas produkcji powinny wymagać specjalnego i niewygodnego uwierzytelnienia. Nie powinieneś być w stanie wślizgnąć się w to ani zapomnieć, że jesteś zalogowany. Fizyczna kontrola dostępu jest tutaj przydatna. Karty inteligentne, przełączniki typu „uzbrajanie” konta, dostęp do dwóch klawiszy jednocześnie.

    Dostęp do produkcji nie powinien być czymś, co trzeba robić każdego dnia. Większość pracy powinna odbywać się na platformie testowej, a wdrażanie poza godzinami pracy w produkcji po dokładnej analizie. Trochę niedogodności cię nie zabije.

Automatyzacja jest częścią rozwiązania.

Nie jestem ślepy na fakt, że pełne przetworzenie (przesyłanie do VCS, sprawdzanie zasięgu, pobieranie do serwera testowego, uruchamianie automatycznych testów, ponowne uwierzytelnianie, tworzenie kopii zapasowej, pobieranie z VCS) to długi proces.

Właśnie tam może pomóc automatyzacja, zgodnie z odpowiedzią Bena. Istnieje wiele różnych języków skryptowych, które znacznie ułatwiają wykonywanie niektórych zadań. Tylko upewnij się, że nie ułatwiasz robienia głupot. Twoje kroki związane z ponownym uwierzytelnieniem powinny być nadal wyraźne (a jeśli niebezpieczne), powinny być niewygodne i trudne do zrobienia bez zastanowienia.

Ale sama automatyzacja jest gorsza niż bezużyteczna. Pomoże ci to w popełnieniu większych błędów przy mniejszym przemyśleniu.

Odpowiedni dla zespołów każdej wielkości.

Zauważyłem, że wskazujesz wielkość swojego zespołu. Jestem jednym facetem i narażam się na to, ponieważ wypadek zajmuje tylko jedna osoba. Jest narzut, ale warto. W efekcie powstaje znacznie bezpieczniejsze i znacznie bardziej bezpieczne środowisko programistyczne i produkcyjne.


2
Ponadto jedną rzeczą, którą lubię, jest używanie dwóch nazwanych kont na użytkownika. Jedno dotyczy zwykłego logowania użytkownika, operacji, codziennej pracy itp., Podczas gdy drugie konto (zwykle z pewnym przyrostkiem, takim jak + lub podkreślenie) ma pełne prawa do prod i dev, których wymaga użytkownik. W ten sposób użytkownik musi podjąć aktywną decyzję, aby naciskać na prod, a nie na dev. Jest to podobne do opisanego powyżej punktu 3, ale nie wymaga znacznej dodatkowej infrastruktury ani wydatków w celu wykazania wartości.
user24313,

3
Ważne jest również, aby unikać przyzwyczajania się do robienia czegokolwiek innego niż konserwacja produktu na koncie prod. W tym celu upewnij się, że prod nie widzi kodu źródłowego, nie może uruchomić IDE itp.
Eric Lloyd

Gdzie znajdę jedno z tych urządzeń z dwoma kluczami i jednocześnie z USB?
Lilienthal

Coś jeszcze, co może pomóc, to w pełni zautomatyzowane (jedno lub dwa kliknięcia) procedury w fazie testowej i programistycznej, ale nie w pełni zautomatyzowane wdrożenia produkcyjne. Jak sugerujesz, konieczność ręcznego zdalnego sterowania w skrzyni, aby zrobić coś z produkcją, ale nie z innymi środowiskami, to znacząca różnica w wygodzie. (Wciąż możesz wykonać skrypt i wykonać ten krok we wszystkich środowiskach; mam na myśli to, że musisz ręcznie odpalić wykonanie wspomnianych skryptów do produkcji). Oczywiście można to zrobić oprócz rodzaju uwierzytelnienia procedury, które polecasz.
jpmc26

1
@Lilienthal To była metafora teatru o wysokim bezpieczeństwie, ale można emulować te tanie ataki USB na każdego programistę, a następnie sprawdzać automatyzację co najmniej dwóch ich numerów seryjnych podczas uruchamiania niebezpiecznych rzeczy. W większych zespołach możesz zalogować się, aby zobaczyć, kto przeszkadza w produkcji i pociągnąć odpowiedzialnych ludzi, gdy wszystko pójdzie nie tak.
Oli

12

Jeden z moich współpracowników ma ciekawe podejście do tego. Jego terminalna kolorystyka produkcji jest niezrównana . Szary i różowy i trudny do odczytania, co teoretycznie ma zapewnić, że cokolwiek napisze, naprawdę zamierza napisać.

Twój przebieg może się różnić ... i prawdopodobnie nie muszę mówić, że sam w sobie nie jest kuloodporny. :)


2
Używam również dużego czerwonego koloru tła na połączeniach terminali / baz danych z serwerami produkcyjnymi, a także jasnych czerwonych tapet dla administratorów na PC ...
Falco

Tak, myślałem o tym. Spraw, aby produkcyjny samochód strażacki był czerwony ...
Chris B. Behrens

Kolorowanie pomaga. Tak jak w IDE.
Thorbjørn Ravn Andersen

1

Programiści nie powinni znać hasła do produkcyjnej bazy danych. Hasło prod powinno być losowe i niezapomniane - coś w rodzaju wyniku mashingu klawiatury ( Z^kC83N*(#$Hx). Twoje hasło dev może być $YourDog'sNamelub correct horse battery stapleczy cokolwiek innego.

Jasne, możesz dowiedzieć się, jakie jest hasło, zwłaszcza jeśli jesteś małym zespołem, patrząc na plik konfiguracyjny aplikacji klienta. To jedyne miejsce, w którym powinno istnieć hasło prod. To gwarantuje, że będziesz musiał podjąć celowy wysiłek, aby uzyskać hasło prod.

(Jak zawsze powinieneś mieć kopie zapasowe w punkcie czasowym dla produkcyjnej bazy danych. Na przykład w MySQL zarchiwizuj dzienniki binarne jako kopie przyrostowe. W przypadku PostgreSQL zarchiwizuj dzienniki z wyprzedzeniem. To jest twoja ostatnia szansa dla wszelkiego rodzaju katastrofy, samookaleczenia lub inne).


Nie mogę w pełni się z tym zgodzić, ponieważ w każdym realistycznym dużym środowisku zdarzają się dość regularne przypadki, w których programiści / administratorzy potrzebują dostępu do produkcyjnej bazy danych. Na pewno w idealnym świecie z bezbłędnym systemem tak się nie powinno stać, ale w większości systemów wiem, że musisz ręcznie naprawić niektóre krytyczne dane produkcyjne ... Więc jestem z Oli, logowanie do produkcji powinno być niewygodne, ale wykonalne
Falco

1
@Falco To właśnie sugeruję. Niewygodne, ale wykonalne.
200_success

Problem z twoim podejściem polega tylko na tym, że jeśli istnieje konieczność, a produkcja jest ograniczona, liczy się czas. Więc twoi deweloperzy powinni wiedzieć, gdzie znaleźć hasło i uzyskać je szybko. Jeśli będą musieli zapytać, przeszukaj repozytorium i pliki konfiguracyjne i spróbuj stracić cenny czas = pieniądze. Wolę więc mieć hasło w miejscu, w którym wszyscy wiedzą, gdzie szukać, ale nadal jest niewygodne, ale w razie potrzeby szybkie
Falco

2
@Falco Ponieważ środowiska prod powinny ściśle odzwierciedlać środowiska deweloperów, plik konfiguracyjny znalazłby się w analogicznym miejscu na serwerze prod, jak na maszynach deweloperskich. Każdy kompetentny programista powinien wiedzieć, gdzie szukać, a jeśli nie wie, gdzie szukać, to chcesz tego opóźnienia - właśnie po to, aby zapobiec uszkodzeniom typu określonego w pytaniu.
200_success

Brak znajomości haseł nie utrudnia wypadków. Wręcz przeciwnie, motywuje to do wyszukiwania hasła tylko raz, a następnie programista może zacząć korzystać z historii bash lub nawet utworzyć alias do połączenia z bazą danych. A potem wypadki są bardziej prawdopodobne.
k0pernikus

0

Krótka odpowiedź to RBAC - kontrola dostępu oparta na rolach.

Twoje uprawnienia do wszystkich środowisk muszą być różne - i tak denerwujące, jak rzeczy takie jak UAC, potrzebujesz ich: szczególnie w środowiskach PROD.

Jest NIGDY powód dla deweloperów mieć bezpośredni dostęp do prod - niezależnie od tego jak mała organizacja / zespół. Twój „Dev” może również nosić czapki „Stage” i „Prod”, ale musi mieć różne dane uwierzytelniające i procesy, aby trafić w różne środowiska.

Czy to denerwujące? Absolutnie. Ale czy to [pomaga] zapobiega rozbijaniu środowiska? Absolutnie.


0

Szybkie i proste rozwiązanie: użyj dwóch różnych kont użytkowników, jednego do normalnej pracy programistycznej, który ma dostęp tylko do bazy danych programowania, i innego do faktycznej pracy na produkcyjnej bazie danych, z pełnym dostępem do niej. W ten sposób będziesz musiał aktywnie zmienić konto, którego używasz, zanim będziesz mógł wprowadzić jakiekolwiek zmiany w produkcji, co powinno wystarczyć, aby zapobiec przypadkowym błędom.

To samo podejście można zastosować, jeśli masz dwie witryny lub dwa serwery lub dwa całe środowiska: jedno konto użytkownika do programowania bez dostępu (lub przynajmniej bez zapisu ) do produkcji, inne konto użytkownika do pracy w systemie produkcyjnym ( s).


Jest to to samo podejście, co administrator systemu posiadający standardowe konto nieadministracyjne do rutynowej pracy (czytanie wiadomości e-mail, surfowanie po Internecie, śledzenie biletów, ewidencja czasu pracy, pisanie dokumentacji itp.) Oraz odrębne konto pełnego administratora, z którego można korzystać podczas faktycznego działania na serwerach i / lub Active Directory.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.