Prosty CRUD - jak go dobrze zabezpieczyć

Trafiłem na dość teoretycznie dość proste zlecenie, klient jest trenerem osobistym / fizjoterapeutą / ortopedą, czymś tam jeszcze, generalnie prowadzi sesje z ludźmi i klika w wordzie ich przebieg i zalecenia czy też rozpisuje im trening przed kolejną sesją i potem wysyła to mailem. Chciałby mieć do tego dedykowany system, czyli zamiast w wordzie, klika coś w aplikacji, a jego klient ma w tej aplikacji swoje konto, więc w domu może się zalogować w domu i zobaczyć historię treningów czy też znaleźć najnowsze zalecenia, itp.

Generalnie, prosty jak budowa cepa CRUD, który można zaimplementować w jeden weekend, tyle, że w grę wchodzi przechowywanie danych osobowych (imię, nazwisko, email, potencjalnie jakieś dane zdrowotne). Z tego względu pytanie, czy warto? Czy potencjalne kary sprawiają, że trzeba do ceny doliczyć kilka zer?
Pod względem samego bezpieczeństwa, powiedzmy że system i baza danych mają silne hasła, które nie wpadną w niepowołane ręce, a komunikacja server-client i client-user odbywa się poprzez HTTPS. Dodatkowo całość jest zabezpieczona przed najpopularniejszymi atakami i kod został sprawdzony przez jakieś Veracode, Defendboty czy coś podobnego. Czy atak i wyciek danych osobowych z aplikacji, która ma 100~ użytkowników jest realny? Druga sprawa, co jeszcze zrobić by móc spać spokojnie? Jakieś sprawdzone materiały na temat bezpieczeństwa aplikacji webowych są mile widziane. A może jakieś kruczki prawne, bądź po prostu umowa sformułowana w ten sposób, że jako programista dostarczam jedynie aplikację, ale nie odpowiadam za to co się z nią później dzieje?

Jeszcze dodałbym pytanie jak to najlepiej wdrożyć aby pozbyć się całego security związanego z OSem itd.

No wiecie, aby zamiast jakiegoś VPSa z czystym OSem i całym tym overheadem dot. utrzymania, to mieć coś praktyczniejszego i przerzucić security na vendora

nie wiem, może te AWS Lambdy czy Funkcje rozwiązują ten problem?

jest tu jakiś chmurer? :D

Wczoraj z ciekawości przeglądałem książki o bezpieczeństwie aplikacji webowych. Sugeruję od nich zacząć. Sam chcę się zabrać za coś w tym temacie, tylko ciągle czasu brakuje :/ Nowoczesne frameworki często zabezpieczają przed popularnymi atakami, więc sporo rzeczy masz z głowy, jeśli nie popełniłeś jakichś błędów autentykacji / autoryzacji. Ale sam jestem ciekaw co mają do powiedzenia inni.

Pogadaj z prawnikiem. Spisz odpowiednie umowy. Będą konieczna zgody rodo itp ale to już ten koleś powinien mieć jak trzyma to w wordach. Poza mocnymi hasłami mozesz wprowadzić podwójne sprawdzenie przy logowaniu albo utrzymywanie haseł wywalić na zewnątrz do usługi Azure albo aws

@WeiXiao:

Security of the cloud – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the AWS compliance programs. To learn about the compliance programs that apply to AWS Lambda, see AWS Services in Scope by Compliance Program.

Security in the cloud – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.

https://docs.aws.amazon.com/lambda/latest/dg/lambda-security.html

Muszę to doczytać, ale brzmi jak coś co by mi pomogło

A po co w takiej aplikacji przechowywać dane osobowe? Rozumiem, że dane osobowe po stronie fizjoterapeuty są potrzebne (i ma je sobie w Wordzie), ale przesyłanie ich przez apkę mija się z celem -- można oprzeć wszystko o jakieś nicki i po sprawie? W końcu on i tak się z tymi pacjentami musi spotykać...

@koszalek-opalek:
Nie bardzo to widzę - przychodzi pacjent na pierwszą wizytę, trzeba mu założyć konto i podać mu dane logowania. Rozumiem, że nie chcemy tutaj maila ani nic osobistego, czyli generujemy nick typu misUszatek93, a mój klient w notesie sobie robi wpis, że ten misUszatek93 to tak naprawdę Jan Kowalski. W trakcie wizyty mój klient wyszukuje w systemie misa uszatka i prowadzi dalej wizytę, robiąc jakieś notatki dla niego. No i po wizycie Jan Kowalski loguje się z domu jako misUszatek93.

Oczywiście zamiast misia uszatka można tutaj wygenerować jakiś prosty login typu 12345, ale nie zmienia to faktu że pewnie każdy wolałby się logować podająć np. swój adres email niż losowy ciąg cyfr, no a mój klient będzie musiał prowadzić osobny system który mapuje loginy do prawdziwych ludzi

#Edit

Teoretycznie, aplikacja po stronie mojego klienta może być desktopowa z lokalną bazą danych pacjentów. Wtedy zostaje możliwość wyszukania konkretnego pacjenta po imieniu i nazwisku, a na zdalnym serwerze trzymane są identyfikatory pacjentów, które też słuzą im do logowania do systemu.

A nie możesz wykorzystać OAuth/OpenId, żeby użytkownicy mogli się logować kontem Google (albo GitHubem ;) )?

@Charles_Ray:
Wtedy i tak muszę ten email w swojej bazie danych trzymać, a email to chyba też dane osobowe?

email może podlegać pod rodo, jeśli po adresie email można jednoznacznie określić osobę, więc i tak i nie :)

Też mi się tak wydawało, więc opcja z OAuth i logowaniem z Google nie wchodzi w grę. Chyba, ze trzymać w bazie tylko hash emaila, teoretycznie dałoby się to w ten sposób zaimplementować logowanie, o ile się nie myle.

Druga opcja to tak jak wspomnialem:

• desktopowa aplkacja z lokalną bazą danych, w której trzymam dane osobowe (imię, nazwisko) wraz z identyfikatorem użytkownika czyli jego loginem
• zdalny serwer, obsługujacy logowanie oraz przechowujący te notatki dla pacjentów, z tym że tutaj identyfikatorem jest wcześniej wspomniany ID
• aplikacja webowa, gdzie użytkownik loguje się przez wspomniany ID i ma dostęp do swoich danych

W ten sposób dane osobowe znajdują się jedynie na lokalnym komputerze mojego klienta, przez siec przesyłam oczywiście dane z sesji (wizyty lekarskiej) konkretnego pacjenta, ale nie są one nigdzie podpisane imieniem i nazwiskiem, a jedynie identyfikatorem. Teoretycznie ma to sens i jest na pewno bezpieczniejsze niż trzymanie danych osobowych na zdalnym serwerze, pytanie czy w praktyce coś mi nie umknęło? :)

Mam wrażenie, że popadasz w jakąś paranoje. Jak byś się nie starał to i tak najsłabsze ogniwo każdego systemu znajduje się między fotelem a monitorem i to ono najczęściej zawodzi. Przede wszystkim zadbaj o aspekt prawny cała reszta zgonie ze sztuką.
Identyfikator musisz jednoznacznie powiązać z danymi klienta co już jest dla RODO wystarczające.

@UglyMan:

Przede wszystkim zadbaj o aspekt prawny cała reszta zgonie ze sztuką.

Co dokładnie rozumiesz przez aspekt prawny?

@AngryProgrammer: Odpowiednio spisana umowa - jak wyciekną dane z winy użytkownika to żeby ciebie nie pociągnął do odpowiedzialności. To, że nie odpowiadasz za serwer gdzie to stoi i jak ktoś tam się włamie i wyciągnie bazę to tez nie twoja wina. Poza tym klient powinien zadbać o odpowiednie regulaminy, klauzule rodo (łącznie z tym, komu przekazuje dane - np logowanie, system mailingowy) itp. Techniczne należy wykonać zgodnie ze sztuką reszta to problem biurokracji i prawników.l

UglyMan napisał(a):

Identyfikator musisz jednoznacznie powiązać z danymi klienta co już jest dla RODO wystarczające.

O aspekcie prawnym masz rację, ale jednoznaczne powiązanie nie musi podpadać pod RODO...

Ale co z tym RODO? Pokazujesz płachtę rodo, user w ciemno wyraża zgody i jechane? Czy Ty na jakiś audyt bezpieczeństwa się szykujesz?

@Charles_Ray:
RODO to jedna sprawa, obawiam się co jak z jakiegoś powodu wszelkie zabezpieczenia nie wystarczą, albo zrobie jakiś głupi błąd w implementacji / konfiguracji i te dane użytkowników się dostaną w niepowołane ręce.

ja nie wiem co to za podejście w tym temacie do security, wręcz na zasadzie "a po co"

Może inaczej zadam pytanie, zapomnijmy o próbach nie przechowywania danych osobowych w aplikacji, powiedzmy że trzymam w bazie imie, nazwisko, email i dane medyczne konkretnej osoby. Użytkownik loguje się z dowolnego miejsca i ma dostęp do tych danych (oczywiście tylko do swoich). Skończyłem implementacje "logiki biznesowej" i co dalej?

• sama implementacja logowania to głównie framework z którego korzystam, aczkolwiek pewnie warto to mocno otestować integracyjnie
• powiedzmy, że wdrażam wszystko na AWSa, wygląda na to że security na poziomie OS jest tam ogarnięte
• secuity bazy danych, za pewne również AWS albo inny cloud provider, ze swojej strony zarówno tu jak i w poprzednim punkcie dostarczam mocne hasło
• konfiguruje HTTPS w komunikacji frontend - backend oraz frontend - użytkownik
• skanuje kod jakimś Veracode albo podobnym wynalazkiem, żeby upewnić się że nie ma oczywistych luk bezpieczeństwa w samym kodzie
• RODO - tutaj wystarczy, że dodaje komunikat na stronie że ów aplikacja przetwarza dane osobowe? czy potrzebuje jakieś prawne zezwolenia by to robić?

O co jeszcze warto zadbać zanim aplikacja trafi na produkcje?

Np. czy nie wystawiasz bazy na świat, czy aplikacja korzysta z użytkownika technicznego zamiast admina. Na AWS są spoko ogarnięte te security groupy

Czy nie wystawiasz bazy na świat

Czy baza będzie zaszyfrowana

Czy połączenie z bazą będzie bezpieczne (po SSL, certyfikaty itd)

Czy połączenie z backendem będzie bezpieczne (to samo)

Od klienta teź możesz wymagać przedstawienia się certyfikatem

Czy sekrety na pewno są sekretami i nie wyciekają gdzieś bokiem przy przepychaniu z Vaulta np. do konfiguracji/środowiska

Czy nie wyciekasz wrażliwych informacji np. w logach aplikacji

Jeśli już nawet wrzucisz w jakieś chmury i kontenery to upewnij się, że używasz m.in. bezpiecznych obrazów - było jakiś czas temu głośno o tym, że nieco ponad połowa przebadanych obrazów z Docker Hub miała krytyczne podatności :)

Jak już się upewnisz, że bazowe obrazy są bezpieczne to upewnij się, że Twoje customowe nie wprowadzają furtki

No i jeszcze był nawet taki temat jakiś czas temu na forum - co, jak komuś wycieknie token, nie wyloguje się itd.

Co do RODO, z uwagi na to że przetwarzasz specjalne kategorie danych (dane medyczne), spoczywają na twoim zleceniodawcy dodatkowe obowiązki (art 9 RODO - wymienia szczególne warunki które muszą być spełnione żeby takie dane przetwarzać). Z uwagi na małą skalę omija cię art 29 RODO (powołanie inspektora danych osobowych), ale to może się zmienić jeśli ten CRUDzik się rozrośnie. Jeśli będziesz również operatorem tego systemu, to musicie sporządzić sobie umowę o powierzeniu przetwarzania danych osobowych. Nie zapomnijcie też o prawie do bycia zapominanym i prawie do dostępu do danych. Dobrze mieć też jakiś dokument analizy ryzyka jako dupochron.

Do powyższych rzeczy dodam również regularną rotację sekretów, na AWSie stosunkowo łatwo to zrobić z Secrets Managerem (ma integrację z RDSem). I poczytać o shared responsibility model - w każdym serwisie AWS bierze na sobie część ryzyka, ale chyba nigdy całe.

https://firebase.google.com

Edit: Może faktycznie użyć loginu i trzymać dane w Google Sheets lub Excel przez ich API?

Jeśli jesteś firmą to najlepiej spółkę założyć ta któ®a obsługuje taką aplikację lub która sprzedaje. Możesz zabezpieczyś się technicznie, mieć RODO itd ale w razie jak wyciekną dane czy coś to kara będzie nałożona na spółkę a nie na osobę prywatną. Wtedy spółka upadnie a powstanie nowa. No bo moze nie było to z twojej winy (programisty) ale ktoś kozła ofiarnego szukać musi. Warto też i od tej strony sie zabezpieczyć.

Jednym z warunków przetwarzania danych osobowych jest ich celowość. Czy nie da się pozbyć tych danych? Dieta i trening nie zależą od nazwiska. Za dane osobowe według tych nowomodnych kryteriów, czyli PII uważane są wszystkie dane, które pozwalają na określenie kim użytkownik jest, lub skontaktować się z nim. Mając do ogarnięcia serwis, który ma takie dane przetwarzać nie brał bym się za to bez prawnika, czy innego zioma od RODO, bo potencjalne kary są dotkliwe.
Technicznie - skorzystałbym z gotowej usługi do uwierzytelniania użytkowników, takiej jak FireBase, czy Auth0. Wypychasz w ten sposób sporą część roboty i ryzyka poza własny scope i pozostaje ci poprawne interpretowanie JWT, co też ciężko schrzanić mając gotowe biblioteki. Oczywiście podstawa to szyfrowanie danych in transit and at rest. Czyli całość ruchu przez SSL + szyfrowanie bazy danych. Ja szedłbym w chmurę, bo tam masz usługi zarządzane, więc znowu odpada ci odpowiedzialność za prawidłowe skonfigurowanie serwera pod DB, czy przygotowanie obrazu do node'a w k8s. W sensie - jak wyciekną dane, a to ty nie wrzuciłeś poprawek systemu, to twoja wina. Jak jest to odpowiedzialność dostawcy usług chmurowych, to jego.

@piotrpo: tak technicznie rzecz biorąc to nie do końca masz rację.
Jeśli ja jestem Twoim klientem, Ty trzymasz dane na jakimś AWS czy czymkolwiek innym, a następnie (w wyniku błędu po stronie AWS) moje dane wyciekną, to ja (oraz różne instytucje) się do Ciebie zgłaszają z pretensjami. Bo mnie średnio interesuje, kto dał ciała - ja moje dane powierzyłem Tobie i to od Ciebie one wypłynęły. To jest podobnie jak z remontem - zamawiasz budowlańca do remontu łazienki, a on bierze podwykonawcę od hydrauliki. I jak ten hydraulik coś spieprzy i chata się zaleje, to raczej nie przyjmiesz od budowlańca wyjaśnień w stylu "ale to nie ja, tylko człowiek robiący dla mnie hydraulikę, więc sam go sobie ścigaj".

Co najwyżej fakt, że wyciek danych nie jest z Twojej winy, ale z powodu np. tego nieszczęsnego AWS może mieć wpływ na łagodniejszy wymiar kary, a także masz możliwość odbicia piłeczki i domagania się od AWS pokrycia szkód, które z ich winy poniosłeś. Tymi szkodami mogą właśnie być kary, które musiałeś zapłacić, uszczerbek na wizerunku, chwilowy przestój itp.

@cerrato Masz rację - klient zgłasza się do ciebie, ty zgłaszasz się do urzędu odpowiedzialnego za ochronę danych, różnica jest dalej. Np. z takim Auth0 możesz podpisać umowę z przeniesieniem odpowiedzialności za część, która oni obsługują. Jak pokazują przykłady implementacji, przechowywanie haseł w sposób bezpieczny też nie jest takie uber oczywiste dla wszystkich i wygodniej powierzyć to komuś, kto nie będzie ich trzymał czystym tekstem w bazie - nie można schrzanić czegoś, czego nie robisz. Jeżeli uda ci się pozbyć wszystkiego co może wyciec z własnych serwisów, to z automatu odpada ci tłumaczenie się, że coś wyciekło, podobnie jak okresowe przeglądy systemu pod kątem zakresu przetwarzania danych. Czy masz powód, czy usuwasz je jak przestają być potrzebne (powodzenia...), czy użytkownik ma prawo wglądu i korekty, czy właściwie chronisz je przed utratą. Dlatego chmura i usługi zarządzalne są tak wygodne - nie potrzebujesz armii ludków od wgrywania poprawek, konfiguracji bazy danych, hardeningów, nethost scannów, utrzymywania klastra pod kontenery. Oczywiście nadal odpowiadasz za wszystko, ale że mało w tym wszystkim robisz, to realnie mniej zje...psujesz i za mniej odpowiadasz. Jasne, że nadal da się wystawić niezabezpieczony endpoint GET ./users/all, albo umożliwić dostęp do DB z całej sieci, bo nie było wiadomo jak konkretnie ustawić tego firewalla, ale też nie przesadzajmy - jeżeli masz o bezpieczeństwie chociaż podstawowe pojęcie to tego nie zrobisz. Czyli podsumowując, na podstawie mojego skromnego doświadczenia - wszystko co "moje" do kontenerów, żadnych VM'ek, bazy kolejki, cache, AIM, WAF do usług zarządzalnych. Problem pojawia się dopiero jak przechowujesz naprawdę poufne dane, bo do niedawna chmura była wyklęta, ale to też się zmieniło w dużej mierze i na poważniejszych rynkach masz już jakieś government cloud.

Jeżeli uda ci się pozbyć wszystkiego co może wyciec z własnych serwisów, to z automatu odpada ci tłumaczenie się, że coś wyciekło

No właśnie nie - bo nadal to Twoja usługa, Twoja aplikacja. To, czy to wyciekło z serwera w Twoim pokoju, z wykupionego VPS czy z jakiejś chmury to jest sprawa wtórna. Najważniejsze jest to, że ja - jako klient, wykupiłem u Ciebie jakąś usługę, przekazałem Tobie swoje dane, a teraz one latają po internecie. I mnie - jako klienta - nie interesuje, czy to skopałeś Ty, czy jakiś Twój podwykonawca, firma od serwerów czy syn kuzyna sąsiada. Ja dałem Tobie moje dane, a teraz jest wyciek - więc ja mam do Ciebie pretensje. A Ty możesz co najwyżej takie same pretensje mieć do operatora chmury, co nie zmienia faktu, że tymi danymi Ty zarządzałeś, Ty je ode mnie pobrałeś, Ty jesteś administratorem i Ty za nie odpowiadasz.

Ale mnie, jako dostawcę usługi mało obchodzi co ty (jako użytkownik) myślisz. Moim celem jest uniknięcie kary w wysokości iluś tam procent rocznych przychodów nałożonych przez regulatora. Jeżeli masz umowę z dostawcą usług, że on odpowiada za utrzymanie bezpieczeństwa jakiejś usługi (np. bazy danych), to pokazujesz tę umowę regulatorowi i zaczyna on ścigać np. Amazona a nie ciebie.

A kto jest administratorem danych - Ty, czy tamta firma?

Oczywiście ja i to do mnie przyjdzie regulator z batem. Ale mam dobre papiery, żeby wykazać należytą staranność. Te dane wyciekają przez jakiś ludzki błąd. Wszystko co piszę wyżej ma na celu powiedzenie regulatorowi, że owszem, jest mi przykro, ale tu mam usługę, której dostawca stwierdza, że ma działać, a nie zadziałała.