Brak centralnej bazy danych

Mam klienta, który chce zbudować stronę internetową / aplikacje mobilne / aplikacje komputerowe, które zajmują się bardzo wrażliwymi danymi (bardziej wrażliwymi niż dane bankowe / karty). Ze względu na wrażliwy charakter danych nie chcą zapisywać ich w centralnej bazie danych, ale nadal chcą, aby ich aplikacje synchronizowały się (powiedzmy, że dodałem trochę danych do mojej aplikacji mobilnej, a następnie chcę móc przejść do mojej aplikacja komputerowa i zobacz te same dane).

Nie mogę wymyślić przyjemnego, niezawodnego sposobu na zrobienie tego i nie jestem pewien, czy taki istnieje. Dlatego tu jestem. Czy ktoś wie, jak sobie poradzić z tymi danymi?

Jednym rozwiązaniem, o którym myślałem, było stworzenie bazy danych po stronie klienta dla każdej aplikacji, która w jakiś sposób zsynchronizowałaby się między aplikacjami. Widzę, że jest to bardzo niewiarygodne i robi się bałagan.

Wiele poufnych informacji jest przechowywanych w bazach danych. W rzeczywistości centralna baza danych jest prawdopodobnie najbezpieczniejszym sposobem przechowywania tych danych. Duże korporacyjne bazy danych mają mnóstwo funkcji do wykonywania takich czynności, jak szyfrowanie poufnych informacji, kontrolowanie, kto uzyskuje do nich dostęp, ograniczenie lub uniemożliwienie osobom, w tym DBA, przeglądania danych itp. Możesz mieć profesjonalnych ekspertów ds. Bezpieczeństwa monitorujących środowisko i profesjonalnych DBA nadzorujących tworzenie kopii zapasowych, więc że nie stracisz danych. Niemal na pewno znacznie łatwiej byłoby skompromitować dane przechowywane na urządzeniu mobilnym lub laptopie przypadkowego użytkownika niż przeniknąć do dobrze zaprojektowanej infrastruktury bezpieczeństwa i zagrozić właściwej centralnej bazie danych.

Możesz zaprojektować system z centralną bazą danych, która przechowuje tylko zaszyfrowane dane i przechowuje klucz prywatny użytkownika na urządzeniu użytkownika. W ten sposób, nawet jeśli centralna baza danych jest całkowicie zagrożona, dane mogą być używane tylko przez użytkownika. Oczywiście oznacza to, że nie można przywrócić danych użytkownika, jeśli zgubi on swój klucz (powiedzmy, że jedyna kopia była na telefonie, a telefon był uszkodzony). A jeśli ktoś naruszy klucz i przypuszczalnie swoje dane logowania, będzie mógł zobaczyć dane.

Musisz wykonać kopię zapasową kilku kroków i, w porozumieniu z klientem, opracować model zagrożenia . (Tak, to jest link do 600-stronicowej książki; tak, zdecydowanie polecam przeczytanie całości).

Model zagrożenia zaczyna się od zadawania pytań typu

• Dlaczego aplikacja musi przede wszystkim przechowywać te wrażliwe dane?
  • Czy w ogóle możesz go nie przechowywać?
  • Czy można go wyrzucić po krótkim czasie?
  • Czy naprawdę musi być dostępny dla więcej niż jednego urządzenia?
  • Jeśli musi być dostępny na więcej niż jednym urządzeniu, czy musi być przechowywany na więcej niż jednym urządzeniu?
• Kim są ludzie, którzy mogą zobaczyć wrażliwe dane każdego użytkownika?
  • Czy można skrócić tę listę?
• Kim są ludzie, którzy mogą mieć kontakt z poufnymi danymi każdego użytkownika podczas wykonywania swoich zadań, ale nie muszą o tym wiedzieć?
  • Czy tę listę można skrócić?
  • Czy dane mogą być dla nich niedostępne bez uszczerbku dla ich zdolności do wykonywania pracy?
  • Jeśli to nie może być niedostępne, to czy może przynajmniej stać się niezrozumiałe? (To właśnie robi szyfrowanie, w skrócie: czyni dane niezrozumiałymi.)
• Kim są ludzie, którzy chcą zobaczyć wrażliwe dane, ale nie mają pozwolenia?
  • Jakie możliwości muszą uzyskać przy danych?
  • Co chcą zrobić z danymi, gdy już je uzyskają?
  • Jak będą źli, jeśli nie dostaną tego, czego chcą?
  • Ile pieniędzy, czasu, cykli procesora i wysiłku ludzkiego są w stanie wydać?
  • Czy obchodzi ich to, czy ktoś wie , że widział dane?
  • Czy chcą uzyskać dostęp do poufnych danych określonych użytkowników , czy też zrobi to ktoś inny?
  • Co oni już wiedzą?
  • Do czego mają już dostęp?

Gdy poznasz odpowiedzi na te pytania, będziesz w znacznie lepszym miejscu, aby dowiedzieć się, co robić.

Pamiętaj, że na każdy zestaw pytań może przypadać więcej niż jedna odpowiedź, zwłaszcza na pytania dotyczące osób atakujących (osoby, które chcą poufnych danych, ale nie mogą ich mieć). Jeśli nie możesz wymyślić co najmniej pół tuzina różnych archetypowych napastników, z różnymi motywacjami, celami i zasobami, prawdopodobnie coś przegapiłeś.

Należy także pamiętać, że napastnicy, którzy powodują was (i / lub klient) najwięcej problemów, są najbardziej prawdopodobne, aby gigantyczną splash w mediach, czy ich atak się powiedzie, lub którzy mają największą ilość kruszywa szkody, prawdopodobnie są nie atakujący, którzy mogą wyrządzić największą szkodę indywidualnym użytkownikom, jeśli ich atak się powiedzie. Firma twojego klienta racjonalnie bardziej dba o zagregowane szkody, ale użytkownicy racjonalnie bardziej dbają o szkody dla siebie.

Jedną z opcji wykonania synchronizacji byłoby wykonanie połączenia peer-to-peer. Będzie to nadal wymagało centralnego serwera, ale ten serwer nie obsłuży żadnych danych.

Gdy urządzenie przechodzi w tryb online, serwer centralny otrzymuje powiadomienie o identyfikatorze użytkownika. Kiedy drugie urządzenie tego samego użytkownika przechodzi w tryb online, serwer wysyła obu urządzeniom adresy IP drugiego. Urządzenia mogą następnie wymieniać dane bezpośrednio. Zastrzeżenie: jedno urządzenie musi działać jako serwer, więc co najmniej jedno nie może znajdować się za routerem NAT.

Nie zapominaj, że będziesz potrzebował silnego uwierzytelnienia i szyfrowania zarówno dla mechanizmu powiadomień, jak i dla wymiany peer-to-peer.

Spraw, aby był to problem kogoś innego.

Przechowuj dane lokalnie w każdej aplikacji, a następnie daj użytkownikom opcję włączenia synchronizacji przy użyciu własnego konta z usługą innej firmy (Dropbox, Dysk Google itp.). Pomyśl także o zaszyfrowaniu wszelkich danych przesyłanych do usługi innej firmy (są w tym plusy i minusy).

Daje to wrażenie, że użytkownicy są właścicielami własnych danych, ponieważ muszą włączyć synchronizację danych. To sprawia, że ​​aplikacje są przydatne dla osób, które nie chcą udostępniania. Sprawia to, że ktoś inny jest odpowiedzialny (technicznie i potencjalnie prawnie) za ciągłe problemy związane z utrzymywaniem bezpieczeństwa wszystkich udostępnianych danych.

Wydaje się, że zmartwienie klienta dotyczy widoczności tych danych. pierwsze pytanie, jakie należy zadać klientowi, to czy dane zostały zaszyfrowane, gdzie można je przechowywać? Następnie zapytaj klienta, jakie rodzaje kontroli dostępu chcą wprowadzić, zanim dane będą mogły zostać odszyfrowane i przetworzone - gdzie można przechowywać klucz deszyfrujący? czy jest oddzielny klucz dla użytkownika? itp...

Jeśli klient nie chce, aby dane były nigdzie przechowywane, czy chce, aby użytkownik wprowadzał je za każdym razem?