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.
źródło
Odpowiedzi:
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.
źródło
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
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.
źródło
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.
źródło
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.
źródło
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?
źródło