Zabezpieczanie poufnych danych od programistów

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.

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.

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).

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.

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.

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ć.

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.

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.

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.