Bezpieczeństwo danych osobowych a praca zdalna

0

Placówka X korzysta z oprogramowania klient - serwer bazy danych z masą danych wrażliwych. Jak się zabezpieczyć w momencie gdy chcemy korzystać z tego programu zdalnie. Czy powinno się łączyć przez VPN i zdalny pulpit i korzystać z programu zainstalowanego w miejscu pracy - wtedy dane wrażliwe nie wychodzą poza sieć w pracy - czy może sam VPN wystarczy i program można mieć zainstalowany na komputerze z którego się łączymy i który odpytuje bazę dostępną pod konkretnym adresem w sieci w pracy. Jak rozumiem wtedy w zasadzie dane także nie wychodzą poza sieć "pracową", która zostaje rozszerzona o zdalny komputer, jednak komputer zdalny jest także podłączony do internetu, w tym przypadku przez swoją lokalną sieć domową, więc w sumie dość bezpieczną, ale jednak... poza tym dane fizycznie podróżują jednak przez tunel vpn, w przeciwieństwie do zestawu VPN + RDP, gdzie podróżują jedynie dane obrazu video...
Dodam że dane są mocno wrażliwe - są to dane medyczne.

Nie znam się za bardzo i być może nieco pomieszałem, jeśli tak proszę o wyprowadzenie z błędu i pomoc.

2

Aplikacja powinna siedzieć w sieci wewnętrznej (bez dostępu do internetu do/z). Dostęp do niej powinien być tylko z jednego wydzielonego, wewnętrznego hosta, na którego trzeba się zalogować. Ten host również nie powinien też być dostępny z zewnątrz. Dopiero kolejny host, ten dostępny z zewnątrz (tzw. bastion) powinien jedynie umożliwić "podłączenie" się do niego (wewnętrznego hosta) i tylko to i nic węcej.

Sam bastion absolutnie nie powinien "widzieć" adresacji hostów, które hostują docelową aplikację. Mało tego, trzeba założyć, że może zajść sytuacja, że admin urządzenia sieciowego np. switcha, coś pomiesza i z poziomu bastiona ta podsieć stanie się dostępna - zatem hosty hostujące aplikacje z wrażliwymi danymi powinny więc same z automatu "wycinać" nieobsługiwane sieci, a nie tylko polegać na bezpiecznym jej wydzieleniu.

Czyli ew. bezpieczny schemat winien wyglądać tak [internet] -> bastion -> host wewnętrzny -> aplikacja - ale to uproszczone, bo konfiguracji i szczegółów w tym jest pełno.

Host wewnętrzny powinien mieć możliwe najmniejsze możliwe uprawnienia użytkowania aplikacji jakie tylko istnieją - nie tylko read-only, ale wręcz ograniczony subset danych, których można używac zdalnie (specjalne konto do tego celu).

Po prostu musi być założenie, że bastion może zostać w jakis sposób przejęty, więc jest tzw. druga linia - host wewnętrzny, ten też w skrajnym przypadku (albo i nie) można przejąć, więc zawsze dostęp do docelowej aplikacji powinien być maksymalnie ograniczony.

0

Dodam że oprogramowanie nie ma serwera aplikacyjnego. Sa jedynie bezstanowe windowsowe klienty desktopowe i baza danych. Cała logika jest w klientach. Rozumiem mniej więcej to o czym piszesz @TurkucPodjadek, z tym że wydaje mi się że to jest bardziej opis pod aplikację webową. Orpgoramowanie z którego korzysta placówka to programy desktopowe i żaden komputer w sieci lokalnej, łącznie z serwerem bazy nie ma dostępu do internetu. Maszyn jest kilka, sieć jest niewwielka. Plus router, na którym skonfigurowano VPN. Chciałbym uzyskać odpowiedź w kontekście VPN i RDP. Wydaje mi się że nie ma sensu używać RDP, jeśli nie zwiększa to bezpieczeństwa, a powoduje dodatkowy narzut sieciowy.

1

@mazurro: to tak nie do końca, że RDP daje dodatkowy narzut sieciowy. Uruchom programy klasy ERP na połączeniu VPN i na RDP. Zobaczysz różnicę. Z tego co zrozumiałem, to komputer użytkownika ma aplikację kliencką (która logikę i operacje ma w sobie) i ta aplikacja łączy się do jakiegoś silnika bazy danych będącego w sieci firmowej.

RDP w tym wypadku ma też plus, że możesz zablokować pobieranie danych na komputer (np. wyłączenie kopiuj/wklej na lokalnym hoście do RDP) więc jest bezpieczniejsze. Tylko pytanie licencyjne dla RDP czy w posiadanym przez Ciebie rozwiązaniu możesz wykorzystywać to w ten sposób. Jeśli chcesz robić RDP do Windows7/10 to zgodnie z licencją - jeden dostęp RDP ale ADMINISTRACYJNY nie do codziennej pracy.

2

Dodam że oprogramowanie nie ma serwera aplikacyjnego. Sa jedynie bezstanowe windowsowe klienty desktopowe i baza danych. Cała logika jest w klientach.

Nie ma serwera aplikacyjnego? To bezstanowe klienty jak trzymają swój bezstan? W swoich bazach danych, czy w centralnej? Z tego piszesz, to średnio ogarniasz jak ta aplikacja dokładnie działa, a chcesz ją "bezpiecznie" na świat wystawić - to poważny dzwonek ostrzegawczy.

Rozumiem mniej więcej to o czym piszesz @TurkucPodjadek, z tym że wydaje mi się że to jest bardziej opis pod aplikację webową. Orpgoramowanie z którego korzysta placówka to programy desktopowe i żaden komputer w sieci lokalnej, łącznie z serwerem bazy nie ma dostępu do internetu. Maszyn jest kilka, sieć jest niewwielka. Plus router, na którym skonfigurowano VPN. Chciałbym uzyskać odpowiedź w kontekście VPN i RDP. Wydaje mi się że nie ma sensu używać RDP, jeśli nie zwiększa to bezpieczeństwa, a powoduje dodatkowy narzut sieciowy.

Klienty desktopowe i baza danych brzmi jak antypattern tutaj - więcej wektorów ataku, bo nie wiadomo ilu tych klientów jest i co one dokładnie robią. Przeglądarka internetowa (w przypadku aplikacji web) jest miliony razy bardziej sprawdzonym softem aniżeli tajemnicze "klienty desktopowe".

Jednak generalnie niczego to nie zmienia w kwestia mojej porady. Poza tym, moja porada dotyczy tak VNC, jak RDP czy SSH. Ty masz w pierwszej kolejności założyć, że ktoś z zewnątrz (nazwijmy roboczo: hacker) wskutek jakichś działań zdobędzie (w najgorszym przypadku) dokładnie takie same uprawnienia jak Ty, łączący się z zewnątrz. Rozumiesz to założenie? Wychodząc z tego założenia, nie ma tu znaczenia jakiego protokołu (do pewnego stopnia, bo oczywiście nieszyfrowane z zasady powinny być odrzucane) użyjesz i jaką masz aplikację, tylko jak zorganizujesz infrastrukturę oraz docelowe uprawnienia. Jeżeli nie jest możliwe odpowiednie przycięcie Twojego zdalnego konta tak, by nie narobiło szkód typu wyprowadzenie danych wrażliwych, to zdecydowanie nie baw się w takie rzeczy. Oczywiście mówimy tu o szczególnym nacisku na bezpieczeństwo tych danych, a nie użytkowość zdalną tego rozwiązania.

Jeszcze dopowiem jak ja coś takiego robiłem, bo miałem taki case w swojej karierze, że również miałem do czynienia z wrażliwymi bazami. Z tych baz zdalnie był mi potrzebny naprawdę pewien wycinek danych dot. jedynie mojego własnego konta, które sprawdzało działanie aplikacji i parę prostych spraw administracyjnych. Nic więcej.

Ja to rozwiązałem tak, że miałem specjalne skrypty robiące dumpa tej bazy, które ją w trakcie "anonimizowały" - wycinały prawie wszystkie dane wrażliwe (imiona, nazwiska, pesle, numery dowodów itp) i taka "zaanonimizowana" kopia bazy była odtwarzana gdzieś indziej i dopiero udostępnana w sposób jaki opisałem w poście nr 1 - niby overkill, bo żadnych ważnych danych niby nie powinna zawierać, ale miałem z tyłu głowy, że jakiś skrypt się walnie i nie wytnie danych i przeoczę tę sytuację, bo nie miałem dodatkowej automatyki, która to "weryfikowała".
W ten sposób nawet jak by się znalazł inny TurkucPodjadek, co miałby identyczne dostępy to w najgorszym przypadku dostałby się do zaanonimizowanej bazy bez żadnych danych praktycznie. To jest właśnie podejście zakładające ew. fuckup bezpieczeństwa.

Z kolei normalna (czyli z danymi wrażliwymi) baza była niemal w kompletnie odseparowanej sieci nieodstępna dla świata jakkolwiek według mojej wtedy wiedzy i testów.

0

Nie ma serwera aplikacyjnego, dokładnie - ten program został stworzony 15 lat temu przez 1 programistę, ale jest używany w wielu ośrodkach, jest bezpieczny i nigdy nie byo z nim problemu. Nie ma "swoich baz danych", tylko 1 centralna. Nie chcę wystawiać jej na świat. Chcę się do niej podłączyć z wykorzystaniem VPN, który jak rozumiem jest bezpieczny - to chyba nie jest wystawianie na świat? Klienty desktopowe to antypattern? Dlaczego? Przecież jest mnóstwo softu który tak działa. Klienty giełdowe, softy do managementu dla firm, długo by wymieniać... Z tym że w tym przypadku "serwerem" jest tylko baza, nie ma pośrednika pomiędzy. Klienty mają wpisany konfig do bazy. Zresztą w sumie ja nie widzę takiej potrzeby tak naprawdę. Wiem że jest coś takiego jak MVC, tylko że tutaj mamy wszystko zamknięte w jednej sieci - klienty + baza, i żadna z tych maszyn nie ma dostępu do internetu. Do sieci można się dostać tylko logując się do jednej z maszyn albo przez VPN.

A może z innej strony. Mamy zabezpieczoną sieć A. Podłączamy się do niej przez VPN z zewnątrz przez komputer X. Komputer X znajduje się w bezpiecznej domowej sieci LAN. Czy teraz VPN zapewnia w 100% bezpieczy przesłył danych pomiędzy A i X? Czy jest ktoś w stanie przechwycić jakikolwiek sposób te dane, zakładając że te obie sieci mają zapewniony wysoki stopień bezpieczeństwa?

@enclude: Hmm czy RDP firmowe nie wymaga uruchomienia wszystkiego na Windows serverze? Czy może można kupić licencję dla poszczególnych klientów, bez konieczności uzycia centralnego serwera z Windows server?

2

@mazurro:

Nie ma serwera aplikacyjnego, dokładnie - ten program został stworzony 15 lat temu przez 1 programistę, ale jest używany w wielu ośrodkach, jest bezpieczny i nigdy nie byo z nim problemu

Nie znam tego programu, ale po tym opisie już wiem, że nie jest bezpieczny. Jest zwyczajnie niesprawdzony na tym polu i tym bardziej nie należy go wystawiać jakkolwiek. Na pewno standardy bezpieczeństwa 15 lat temu wymiatały - niektóre języki programowania chyba jeszcze nie miały "bezpiecznych" funkcji do przesyłania zapytań do baz, a tu proszę, 1 programista zrobił i program jest bezpieczny do dziś. No albo magik, albo się ten program nieźle uchował w intranetach. Strzelam to drugie.

W dalszym ciągu polecam przeczytać moje poprzednie posty, bo wychodzisz ze błędnego założenia i jak to faktycznie są tak wrażliwe dane, to zrobisz sobie kiedyś krzywdę tym podejściem, że "program jest bezpieczny".

1
mazurro napisał(a):

@enclude: Hmm czy RDP firmowe nie wymaga uruchomienia wszystkiego na Windows serverze? Czy może można kupić licencję dla poszczególnych klientów, bez konieczności uzycia centralnego serwera z Windows server?

Tak, licencjonowane środowisko RDP wymaga środowiska Windows Server. Do tego dokupujesz Windows Server CAL (użytkownik lub urządzenie) oraz dla osób korzystających z RDP Windows Server RDS CAL (użytkownik lub urządzenie).

@mazurro: Tym o czym piszesz powinien w Twojej organizacji zająć się dział IT (a dokładniej administrator systemów i administrator sieci) skoro nie zdajesz sobie sprawy, z tego jak powinno to wyglądać prawidłowo. Z drugiej strony... podejrzewam, że komputery i bazy danych nie mają dostępu Internetu celowo, np. ktoś zdał sobie sprawę z tego, że nie jest to bezpieczne rozwiązanie. Pamiętaj, że mało programistów implementuje obecnie szyfrowanie połączenia z bazami danych a co dopiero paręnaście lat temu i należy poważnie zastanowić się nad tym co napisał @TurkucPodjadek . Może się okazać, że żeby zrobić to zgodnie ze sztuką, należało by wymienić brzegowe urządzenie na takie z WAF aby zwiększyć bezpieczeństwo.

0

@enclude Znalazłem taki wątek: https://community.spiceworks.com/topic/2136011-remote-desktop-are-we-using-it-legally. Wg niego korzystanie z RDP przez pracowników, którzy łączą się do swoich maszyn w sieci firmowej, nie do WinServera jest nie łamie postanowień licencyjnych. Czy forumowicze są w błędzie czy coś źle rozumiem?

1

@mazurro: Wątek z 2018 r. :)

Tutaj masz z oficjalnego Supportu MS: https://support.microsoft.com/pl-pl/topic/pulpit-zdalny-od%C5%82%C4%85czony-lub-nie-mo%C5%BCe-po%C5%82%C4%85czy%C4%87-si%C4%99-z-komputerem-zdalnym-lub-serwera-us%C5%82ug-pulpitu-zdalnego-serwer-terminali-kt%C3%B3ry-jest-uruchomiony-system-windows-server-2003-112c6dc3-1853-415a-31e4-d5dacfe07d92

Usługi terminalowe obsługują dwa jednoczesne połączenia zdalne z komputerem. Nie ma potrzeby licencji dostępu klienta usług terminalowych (TS CAL) dla tych połączeń.
Zezwalająca na więcej niż dwóch połączeń administracyjnych lub wielu połączeń użytkowników należy zainstalować rolę usługi terminalowe i mieć odpowiednie licencje TS CAL.

Codzienna praca nie jest dostępem administracyjnym. Moim zdaniem, opinia na forum Spiceworks jest błędna. I nie ryzykowałbym.

0

@enclude Hmmm ten cytat w żaden sposób nie wskazuje jednoznacznie na to że nie można tego robić. To się odnosi do połączeń zdalnych do Windows Servera, nie do zwykłych komputerów.

1

@mazurro: Dobrze, masz rację, mój cytat nie daje odpowiedzi na nurtujące Ciebie pytanie, więc sięgnę do postanowień licencyjnych, które instalując system zaakceptowałeś.
Otóż, skrócony wyciąg: https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/UseTerms_Retail_Windows_10_Polish.htm

  1. Prawa do instalacji i używania. [...]

c.Ograniczenia. Producent urządzenia, osoba lub firma instalująca oprogramowanie oraz Microsoft zastrzegają sobie wszelkie prawa (w tym prawa wynikające z ustaw o ochronie własności intelektualnej) nieudzielone w sposób wyraźny na mocy niniejszej umowy. Przykładowo niniejsza Umowa nie daje Licencjobiorcy żadnego prawa, aby: [...]

(v) wykorzystywać oprogramowanie jako oprogramowanie serwera lub używać go na potrzeby hostingu treści komercyjnych, udostępniać oprogramowanie jednocześnie wielu użytkownikom do korzystania w sieci, instalować oprogramowanie na serwerze i umożliwiać użytkownikom zdalny dostęp lub instalować oprogramowanie na urządzeniu do użytku wyłącznie przez użytkowników zdalnych;

Jednakże, kawałek dalej masz zapis:

d. Możliwości korzystania z oprogramowania przez wielu użytkowników. [...]

(v) Dostęp zdalny. Nie częściej niż raz na 90 dni Licencjobiorca może określić jednego użytkownika, fizycznie korzystającego z licencjonowanego urządzenia, jako użytkownika licencjonowanego. Licencjonowany użytkownik może uzyskać dostęp do licencjonowanego urządzenia z dowolnego innego urządzenia za pośrednictwem technologii zdalnego dostępu. Inni użytkownicy (jeden naraz) mogą uzyskiwać dostęp do licencjonowanego urządzenia z innego urządzenia za pośrednictwem technologii zdalnego dostępu, ale jedynie na urządzeniach posiadających oddzielną licencję na uruchamianie tej samej lub nowszej wersji tego oprogramowania.

Należy to rozumieć, że jeden użytkownik może korzystać z RDP. Użytkownika do sprzętu można przypisać nie częściej niż co 90 dni. Jednak, że jakakolwiek pomoc obcej osoby (np. admin logujący się do komputera aby rozwiązać problem) według mnie jest już złamaniem terminu 90 dniowego. Oprócz tego osoba łącząca się musi mieć tę samą lub nowszą wersję systemu operacyjnego (pytanie czy Windows 10 wystarczy czy powinna być ta sama lub nowsza jego kompilacja - według mnie, to drugie).

Aby było to zrobione zgodnie ze sztuką, należałoby wdrożyć Windows Server i usługę terminalową RDS. Wtedy nie byłyby potrzebne takie dywagacje.

0

@enclude Ok, czyli licencja samego Windowsa. I teraz jestem ciekaw jak to wygląda w praktyce, ponieważ wydaje mi się że miejsc pracy podobnych do tego o którym mówię jest w Polsce (i innych krajach też, chociaż koszty licencji i sprzętu są dla polskich firm bardziej obciążające niż dla zachodnich) trochę, a koszt sprzętu i licencjito jest wydatek nawet kilunastu tysięcy złotych.

1

@mazurro: być może, jednak na szczęście ja pracuję w takim miejscu gdzie zrozumiałe jest postępowanie zgodnie z zaleceniami producenta oprogramowania.
Sama licencja W2019 SRV to 4,2k netto (z czego możesz postawić dwie maszyny wirtualne), CAL na 5 osób ~1k netto i RDS CAL na 5 szt. też podobnie. Sprzęt za 6 już kupisz nowego Towera który większości firm wystarczy. Jak będziesz kupował OEM wersje oprogramowania, to w 10k zamkniesz się z większością kosztów. Oczywiście + wdrożenie.

1 użytkowników online, w tym zalogowanych: 0, gości: 1