Zabezpieczanie poufnych danych od programistów

61

Mam uruchomioną aplikację korporacyjną, która korzysta zarówno z magazynów danych MySQL, jak i MongoDB . Mój zespół programistów ma dostęp SSH do maszyny w celu wykonywania wydań aplikacji, konserwacji itp.

Niedawno podniosłem ryzyko w firmie, gdy użytkownicy zaczęli przechowywać bardzo wrażliwe dane w aplikacji, że programiści mają pośredni dostęp do tych danych, co spowodowało trochę burzy, więc teraz zostałem zobowiązany do zabezpieczenia danych, aby nie były dostępny.

Dla mnie nie wydaje się to możliwe, ponieważ jeśli aplikacja ma dostęp do bazy danych, to programista z dostępem do maszyny i źródła aplikacji zawsze będzie mógł uzyskać dostęp do danych.

Clinton Bosch
źródło
30
Użytkownicy powinni przechowywać poufne dane tylko w postaci zaszyfrowanej. Nie powinno być wielkiego problemu, jeśli programiści mogą uzyskać dostęp do zaszyfrowanej formy, o ile pasujące klucze są odpowiednio chronione przed nimi.
MSalters,
3
@Clinton Czy masz oddzielne zespoły administracyjne i programistyczne? Administrator serwera zawsze może odczytać dane, a szyfrowanie nie pomaga, ponieważ mogą łatwo uzyskać klucz.
CodesInChaos,
14
Szczerze mówiąc, jest to skomplikowana sprawa, a robienie tego w odpowiedni sposób wymaga dużej wiedzy specjalistycznej w zakresie bezpieczeństwa danych. Nawet jeśli dokładnie wiesz, co robić, spotkasz się ze sprzeciwem biznesowym, blokadami politycznymi i technicznymi. Zdecydowanie sugeruję skorzystanie z usług konsultanta ds. Bezpieczeństwa danych. Wiedzą nie tylko, co tu zrobić, ale kierownictwo zwykle daje większą wiarygodność, gdy osoba trzecia każe im się zmienić. Wyższe kierownictwo zasadniczo nie przykłada tak dużej wagi do tego, co mówią im wewnętrzni eksperci.
wałek klonowy
3
Może warto zapytać o wymianę stosu zabezpieczeń informacji. Jest kilka powiązanych informacji na temat tego pytania
paj28,
23
Dlaczego ludzie dotykają serwera i wdrażają kod?
Wyatt Barnett,

Odpowiedzi:

89

Bezpieczeństwo nie jest magiczną różdżką, którą można machać pod koniec projektu, należy ją rozważyć i wbudować od pierwszego dnia. To nie jest przykręcenie, to konsekwentne stosowanie szeregu rozwiązań zastosowanych iteracyjnie i sprawdzonych regularnie jako część całego systemu, który jest tak silny, jak najsłabsze ogniwo.

Na obecnym etapie oznaczyłeś problem bezpieczeństwa, który jest dobrym pierwszym krokiem. Teraz musisz zdefiniować co najmniej:

  • Jakie dane próbujesz chronić?
  • Przed kim chcesz chronić te dane?
  • Kto faktycznie potrzebuje dostępu do czego (i kiedy)?
  • Jaki jest wpływ prawny / finansowy / biznesowy tych danych na bezpieczeństwo?
  • Jakie są prawne / finansowe / biznesowe potrzeby osoby / grupy mającej dostęp do danych?
  • Jaki budżet jest skłonny przeznaczyć na strategię „bądź bezpieczny, bądź bezpieczny”, jeśli wcześniej nie był to wymóg biznesowy?
  • Jakiego dostępu potrzebuje system do danych?
  • Na czym polega ten proces i systemy, na których opiera się ta aplikacja?
  • Co zrobiono, aby zabezpieczyć te środowiska?
  • Kto będzie odpowiedzialny za jego wdrożenie i przegląd całego procesu?

Dopóki nie poznasz wszystkich tych szczegółów, naprawdę nie masz z czym pracować. Informacje te określą, jakie łagodzenie tych zagrożeń możesz (i nie możesz) zastosować i dlaczego.

Być może najlepszą rzeczą jest uznanie, że nie masz niezbędnego doświadczenia i że najlepiej byłoby przyprowadzić kogoś nowego z tym doświadczeniem. Dość często słyszę odpowiedź, że nie ma budżetu - jeśli zostanie to uznane za naprawdę ważne, budżet zostanie znaleziony.

James Snell
źródło
33
Whoa ... to sprawia, że ​​bezpieczeństwo brzmi ... nietrywialnie. (Przepraszam za sarkazm; widziałem wielu ludzi zaskoczonych tym.)
Paul Draper,
4
Wierzę, że wiele osób uważa, że ​​istnieje magiczne make-application-securepolecenie, które wystarczy wykonać.
TMH,
27

Masz rację. Jeśli aplikacja ma dostęp do treści przechowywanych na komputerach korporacyjnych bez każdorazowego przekazywania przez użytkownika dodatkowych informacji , programiści, opiekunowie, administratorzy systemów itp. Usługodawcy mogą uzyskać dostęp do tych treści. Jest to zasadniczo nieuniknione i stanowi główne źródło niepewności (Edward Snowden był sysadminem i miał specjalne przywileje ponad „ściśle tajne”, ponieważ po prostu nie ma sposobu, aby ich nie udzielić).

Jedynym sposobem na uniknięcie tego jest wymaganie od użytkownika podania informacji, które nigdy nie trafiają na komputery korporacyjne. Jest to żmudne i podatne na błędy, ponieważ nikt prawdopodobnie nie pamięta wystarczającej ilości informacji, aby stworzyć bezpieczną barierę dostępu, dlatego ludzie natychmiast zaczną przechowywać swoje dane uwierzytelniające w miejscu, które następnie stanie się nowym celem ataku (i prawdopodobnie słabszy cel niż ten, który utrzymujesz). Ale jeśli chcesz zgodnie z prawdą twierdzić, że „Nasi pracownicy nie są fizycznie w stanie uzyskać dostępu do treści naszych użytkowników”, jest to jedyny sposób.

(Należy również zauważyć, że taki model biznesowy wydaje się być politycznie nie do utrzymania. Firmy zostały zmuszone do wycofania się z działania przez służby bezpieczeństwa za próbę zrobienia tego dokładnie. Rozumiem, że udzielanie gwarancji prywatności ma wartość biznesową, ale nie może mieć więcej wartość biznesowa niż podstawowy cel pozostania w biznesie).

Kilian Foth
źródło
6
Możliwe jest zaprojektowanie sprzętu w taki sposób, aby fizycznie niemożliwy był dostęp do niektórych danych bez utworzenia trwałego zapisu takiego dostępu, który nie mógłby zostać zniszczony bez współpracy wielu niezależnych osób i który nawet przy takiej współpracy nie mógłby zostać zniszczony bez pozostawiania wyraźnych dowodów na celowe zniszczenie. Aktualizacja takich systemów, aby sprostać zmieniającym się wymaganiom, jest jednak zwykle bardzo droga w porównaniu z aktualizacją systemów bezpieczeństwa opartych na oprogramowaniu.
supercat,
5
Masz rację, całkowicie zapomniałem wspomnieć o audytowalności jako możliwej alternatywie dla hostingu bez wiedzy. Jest to nieco łatwiejsze do osiągnięcia i często wystarczające dla uzasadnienia biznesowego.
Kilian Foth,
Twój ostatni akapit. Czy masz na myśli historie typu LavaBit? Jestem zmieszany.
jpmc26,
1
@ superuper Musisz także zaufać, że twórcy sprzętu zmusili go do robienia tego, co powiedzieli.
user253751,
2
@immibis: To prawda, ale chciałbym, aby projektowanie i produkcja bezpiecznego sprzętu mogły być kontrolowane przez wiele niezależnych osób. Co więcej, w konwencjonalnym systemie „podstępny” fragment kodu mógłby coś zrobić, a następnie usunąć się bez śladu, ale jeśli kawałek bezpiecznego sprzętu nie powinien mieć zapisywalnego magazynu kontrolnego, coś takiego byłoby niemożliwe. Albo podstępny kod musiałby znajdować się na stałe w magazynie kontrolnym, albo magazyn kontrolny musiałby mieć trwale okablowane środki modyfikacji, z których każdy byłby wykrywalny po fakcie.
supercat
15

Masz w zasadzie rację; niektórzy programiści zawsze będą potrzebować dostępu do danych Live, choćby po to, aby zdiagnozować problemy z produkcją. Najlepsze, co możesz zrobić, to ograniczyć potencjalne szkody poprzez zmniejszenie liczby zaangażowanych osób.

With great power comes great ... opportunity to really, *really* foul things up. 

Wielu programistów nie będzie chciało tej odpowiedzialności, a inni, po prostu nie będą „gotowi” na jej przyjęcie, a więc nie powinni.

Pytanie: Dlaczego Twój Development zespół występów na żywo wersje ?
Sugerowałbym, że potrzebujesz „zespołu” do zarządzania wydaniami (nawet jeśli jest to tylko podzbiór Twojego zespołu, a także reprezentacji biznesowej do podejmowania codziennych „decyzji”, takich jak „Go / No-Go”)? To wyeliminowałoby wiele „potrzeby”, by programiści mogli dotykać czegokolwiek na żywo.

Czy masz jakieś umowy o zachowaniu poufności między deweloperami a firmą? Jest ciężki, ale może mieć pewne zalety.

Phill W.
źródło
Co nadal nie powstrzyma zdeterminowanego złoczyńcy przed ukryciem tylnego wejścia w aplikacji, ale zmniejsza szansę, która sprawia, że ​​złodziej.
Jan Hudec
Tak, nie jest to cały zespół programistów, ale zespół zarządzający podzbiorem / wydaniami. Z pewnością mamy w umowie o pracę klauzulę dotyczącą węszenia wokół danych, których nie powinieneś być, jest to przestępstwo, które można odrzucić.
Clinton Bosch
@JanHudec Zwłaszcza, że ​​po dodaniu kodu aplikacja pozostawia ślady w kontroli wersji.
CodesInChaos
@CodesInChaos: Dobry programista może sprawić, że backdoor wygląda jak uczciwy błąd. Będziesz ich podejrzewał, ale nigdy nie wytoczysz im sprawy. Ale tak, to kolejna linia obrony.
Jan Hudec
@Jan: Dlatego wszystkie zmiany w kodzie powinny zostać przejrzane i podpisane przed dopuszczeniem do gałęzi wydania.
SilverlightFox,
9

Problem polega na tym, że programiści mają dostęp do systemów. Jeśli potrzebują danych produkcyjnych do debugowania, zrób zrzut bazy danych, w którym usuwane są wszystkie poufne informacje. Następnie programiści mogą pracować z tym zrzutem.

Wdrożenie nowej wersji nie powinno wiązać się z żadnym programistą - zadaniem czysto administracyjnym, a nawet lepiej - zadaniem całkowicie automatycznym. Pamiętaj także, że wydawanie i wdrażanie to dwa bardzo różne zadania. Jeśli Twój proces nie jest tego świadomy, zmień to odpowiednio.

SpaceTrucker
źródło
1
Nie potrzebujemy danych produkcyjnych z debugowania, mamy do tego zdezynfekowany zrzut danych, ale czasami wdrożenie wymaga różnych migracji danych itp., Które są prowadzone przez niektórych programistów w zespole zarządzania wydaniami (ale nadal są programistami)
Clinton Bosch
2
@ClintonBosch Zatem nie rozdzieliłeś wyraźnie roli administratorów i programistów. Kolejne pytanie, które powinieneś sobie zadać, brzmi: w jaki sposób upewnimy się, że wydane oprogramowanie zostanie faktycznie wdrożone? Będziesz musiał podpisać się w momencie wydania i zezwalać tylko na wdrażanie podpisanych pakietów na produkcji. Również automatyzacja jest twoim przyjacielem. Migracje nie powinny wymagać żadnych ręcznych kroków.
SpaceTrucker,
4
@ClintonBosch Zidentyfikuj, które pola danych są wysoce poufne i zaszyfruj je. Upewnij się, że wprowadziłeś zabezpieczenia systemu operacyjnego, aby mieć dostęp do identyfikatorów użytkowników, którzy czytają plik klucza, aby upewnić się, że nikt inny niż użytkownik aplikacji nie robi tego. Nie podawaj programistom hasła użytkownika aplikacji. Spraw, aby sudo uzyskało prawa do produkcji i zapisało swoje działania. Jest to prawdopodobnie najbezpieczniejszy sposób, aby upewnić się, że opiekujesz się kilkoma osobami, które miałyby dostęp i aby nie mogły przypadkowo lub przypadkowo zobaczyć danych, których nie powinny.
wałek klonowy
6

Zasada nr 1 bezpieczeństwa: jeśli ktoś ma dostęp do informacji, ma dostęp do tych informacji

Ta tautologia jest denerwująca, ale to prawda. Jeśli dasz dostęp osobie fizycznej, ma ona dostęp do danych. Dla użytkowników oznacza to zwykle kontrolę dostępu, ale dla programistów ... cóż ... to oni muszą napisać kontrolę dostępu.

Jeśli jest to dla Ciebie poważny problem (i wygląda na to, że tak jest), rozważ wbudowane zabezpieczenia oprogramowania. Częstym wzorem jest projektowanie bezpiecznego oprogramowania warstwowo. Na najniższej warstwie zaufany zespół programistów projektuje oprogramowanie, które zarządza najbardziej nagą kontrolą dostępu. To oprogramowanie jest sprawdzane i weryfikowane przez jak najwięcej osób. Każdy, kto projektuje ten kod, ma dostęp do wszystkiego, więc zaufanie jest niezbędne.

Następnie programiści mogą zbudować bardziej elastyczną kontrolę dostępu na górnej warstwie podstawowej. Ten kod wciąż musi być V & Vd, ale nie jest tak rygorystyczny, ponieważ zawsze możesz polegać na warstwie podstawowej, aby pokryć najważniejsze elementy.

Wzór rozciąga się na zewnątrz.

Najtrudniejsze, rzeczywiście sztuka projektowania tych systemów jest to, jak zbudować każdą warstwę, dzięki czemu programiści mogą w dalszym ciągu rozwijać i debugowania przy jednoczesnym zapewnieniu firmę z bezpieczeństwem można oczekiwać. W szczególności musisz zaakceptować fakt, że debugowanie wymaga więcej przywilejów, niż myślisz, że powinno, a próba zablokowania tego spowoduje bardzo złych programistów.

Jako rozwiązanie poboczne rozważ utworzenie „bezpiecznych” baz danych do celów testowych, w których programiści mogą zerwać wszystkie mechanizmy bezpieczeństwa i przeprowadzić poważne debugowanie.

Ostatecznie zarówno Ty, jak i programiści musicie zrozumieć kluczową zasadę bezpieczeństwa: Całe bezpieczeństwo to równowaga między bezpieczeństwem a użytecznością. Państwo musi uderzyć własnego balansu jako firmy. System nie będzie idealnie bezpieczny i nie będzie doskonale użyteczny. Ta równowaga prawdopodobnie wzrośnie nawet w miarę rozwoju Twojej firmy i / lub zmiany wymagań programistów. Jeśli jesteś otwarty na tę rzeczywistość, możesz ją rozwiązać.

Cort Ammon
źródło
3

Skonfiguruj dwa wdrożenia aplikacji, które również korzystają z oddzielnych wdrożeń bazy danych. Jednym z nich jest wdrożenie produkcyjne, a drugie wdrożenie testowe.

Wdrożenie testowe powinno zawierać tylko dane testowe. Mogą to być albo dane fantastyczne, które zostały stworzone w tym celu, albo kopia danych produkcyjnych, które zostały zanonimizowane, aby uniemożliwić programistom znalezienie prawdziwych osób i podmiotów stojących za danymi.

Philipp
źródło
Tak, właśnie taki mamy scenariusz. Ale w pewnym momencie ktoś musi popracować nad środowiskiem produkcyjnym, aby ułatwić wdrożenie / migrację danych
Clinton Bosch
3

W dwóch firmach finansowych programiści nie mieli dostępu do maszyn produkcyjnych. Wszystkie żądania modyfikacji maszyn produkcyjnych musiały przejść proces zatwierdzania za pomocą skryptu i zostały zatwierdzone przez kierowników. Zespół programistów zakończył faktyczne wdrożenia. Zakładam, że ten zespół był tylko pracownikami i przeszedł sprawdzenie przeszłości. Nie mieli też wiedzy programistów, więc prawdopodobnie nie mogliby węszyć, gdyby chcieli. Oprócz tego szyfrowałbyś wszystkie wpisy bazy danych za pomocą tajnego klucza przechowywanego w zmiennych środowiskowych. Nawet jeśli bazy danych wyciekły publicznie, nikt nie mógł ich odczytać. Klucz ten można dodatkowo zabezpieczyć hasłem (PBKDF), więc tylko kierownictwo może go odblokować. Twój system może wymagać hasła wykonawczego podczas rozruchu (lub bardziej prawdopodobne, że zostanie przekazany programistom lub menedżerowi programistów). Zasadniczo strategia polega na rozproszeniu wiedzy, tak aby u jednej osoby nie istniała masa krytyczna wymaganej wiedzy i istnieją kontrole i salda. W ten sposób Coca-Cola chroni swoją formułę. Szczerze mówiąc, niektóre z tych odpowiedzi to kopie.

Chloe
źródło
-1

MongoDB ma ograniczoną kontrolę bezpieczeństwa i zależy od bezpiecznego środowiska. Wiązanie z konkretnym adresem IP i portem (i ssl od 2.2) oraz surowe uwierzytelnianie - to oferuje. MYSQL dodaje GRANT o ON db.t TO ... Dane w spoczynku nie są szyfrowane, a ssl nie jest domyślnie używany. Utwórz ogrodzenie. Dostęp tylko do odczytu dla programistów do plików dziennika związanych z aplikacją powinien wystarczyć do debugowania. Zautomatyzuj cykl życia aplikacji.

Ansible pomógł nam zautomatyzować standardowe operacje (wdrażanie, uaktualnianie, przywracanie) w wielu środowiskach z jednym dzierżawcą, przy użyciu odrębnych zaszyfrowanych skarbców do przechowywania wrażliwych zmiennych środowiskowych, takich jak hosty, porty i poświadczenia. Jeśli każde repozytorium może być odszyfrowane tylko przy użyciu różnych ról i tylko na hoście bastionu, dla zarejestrowanych operacji, wówczas inspekcja zapewnia akceptowalne bezpieczeństwo. Jeśli udzielasz SSH, użyj selinux, aby uniknąć manipulacji kluczem, użyj hosta bastionu z uwierzytelnianiem ldap / kerberos do administracji i używaj sudo mądrze.

bbaassssiiee
źródło