Witam,
zastanawiam się czemu dostęp do EZD RP jest zabezpieczony na poziomie VPN. Po co? Nie jest tu konieczny dostęp do zdalnych zasobów serwerowych (aplikacje, bazy danych), tylko jest to usługa webowa (po prostu strona internetowa). Przecież uwierzytelnianie wielopoziomowe załatwiłoby ryzyko jakiegoś niepowołanego dostępu. Tak działają banki i inne rejestry ze zdecydowanie poważniejszymi danymi. A jeśli boimy się jakiegoś ataku DDOS to może rzeczywiście zrobić to jako white list. Po prostu lista adresów IP z jakich mamy prawo wejść na stronę logowania.
O co w ogóle mi chodzi? O to że od EZD RP wymagamy ciągłości działania. Padnie internet i mimo że mamy backupowe łącze to trzeba VPN skonfigurować, znowu musi nastąpić wymiana danych, obie strony muszą coś skonfigurować. Tego nie zrobi się w 5 minut. Jako że wymaga to obustronnej konfiguracji to czasem i dnia zabraknie. A co jak padnie UTM? Zanim przyjdzie nowy to mijają dni. Jakby nie byłoby konieczności konfiguracji VPN, to podłączyłoby się jakiekolwiek urządzenie dostępowe i można byłoby dalej działać.
VPN to fajne rozwiązanie ale nie w celu dostępu do… strony internetowej i nie jak nie dotyczy połączenia oddziałów jednej firmy gdzie działy IT ze swoją ściśle współpracują, a więc wymiana informacji między nimi następuje ad-hoc, a nie za pomocą maili na których odpowiedź się czeka i czeka…
Witam
Tak sobie myślę, że ogólnie ma to sens jeśli chodzi o bezpieczeństwo danych w tym również osobowych których w EZD jest od groma. Nie jest to może najwygodniejszy sposób, dla mnie wygodniejsze były by certyfikaty w przeglądarce, jednak to w innym środowisku niż moje byłaby to uciążliwość. generalnie wydaje mi się, że możemy mieć na zapasowym łączu przygotowany tunel który w przypadku awarii podniesiemy.
Dzień dobry Panie Rafale,
Dziękuję za podzielenie się swoimi przemyśleniami.
Zgadzam się, bezpieczeństwo danych, zwłaszcza osobowych, jest kluczowe w systemie EZDRP.
Jeśli chodzi o dostęp do systemu EZD RP uprzejmie informuję, że przyjęto w zakresie wymagań dostępu do usługi SaaS EZD RP świadczonej przez NASK, że dla powyższej usługi konieczne jest bezpieczne łącze dostępowe IPSec VPN Site-2-Site. Dostęp do usługi SaaS EZD RP wymaga zestawienia bezpiecznego połączenia pomiędzy siecią komputerową instytucji a infrastrukturą serwerową Operatora EZD RP. Do tego celu wykorzystywane są:
wirtualne sieci prywatne VPN (Virtual Private Network) – umożliwiające tworzenie wydzielonych tuneli, przez które realizowana jest wymiana informacji bezpośrednio pomiędzy nadawcą i odbiorcą, za pośrednictwem sieci publicznej.
zbiór protokołów IPSec (Internet Protocol Security) – służących do implementacji bezpiecznych połączeń i wymiany kluczy szyfrowania pomiędzy komputerami
Rozumiem, że przyjęte rozwiązanie może być niezrozumiałe, ale na chwilę obecną jest ono obowiązujące. Niestety whitelist jest niezadowalającym rozwiązaniem. Jeśli chodzi o zapewnienie ciągłości działania to można podjąć odpowiednie kroki, np. polegające na przygotowaniu tunelu na zapasowym łączu i wcześniejszym skonfigurowaniu go.
Podkreślić należy, że do dostęp do EZD RP to nie jest dostęp tylko dostęp do strony internetowej. Należy również zwrócić uwagę, na szerszy problem, że jeśli jednostka straci dostęp do Internetu, to przestanie np. działać strona internetowa urzędu, dostęp do epuap, usług cyfrowych itd. - cytując klasyka “nie będzie niczego…”
Jeśli Państwa jednostka ma problem z zestawieniem łącza, zapraszam na portal zgłoszeń - z chęcią pomożemy.
A w innych systemach nie jest kluczowe bezpieczeństwo danych? np. banki, urzędy skarbowe, zus - a tam nie jest potrzebny VPN. Przy włamaniu na VPN, atakujący ma dostęp do sieci klienta. Lepszym rozwiązaniem jest MFA.
Wymienione instytucje ograniczają swoje usługi online do pewnego zakresu funkcji, takich jak zarządzanie kontem, transakcje finansowe czy kontakt z obsługą klienta, z kolei używają systemów klasy ERP całkowicie poza publicznym Internetem, głównie ze względów bezpieczeństwa w tym stosują MFA dla połączeń VPN
Jako ciekawostkę mogę dodać, że w żadnym banku nie uwierzytelnisz się nadal online kluczem sprzętowym
Patrząc na inne systemy działające online: duże sklepy internetowe(również przechowują i gromadzą dane osobowe, zamówienia, realizują płatności itp.), Microsoft Dynamics 365, Oracle ERP Cloud - jakoś nie stosują VPN.
Podczas projektowania schematu adresacji sieciowej należy uwzględnić różne scenariusze dostępu do zasobów i bezpieczeństwa. W ramach każdego projektu, zaleca się wydzielenie co najmniej trzech stref:
Strefa publiczna – przeznaczona dla usług dostępnych z zewnątrz, takich jak serwery internetowe, aplikacje publiczne lub inne zasoby, które muszą być dostępne dla szerokiego grona użytkowników.
Strefa z ograniczonym dostępem – strefa o ograniczonym dostępie, w której mogą współistnieć zasoby dostępne zarówno dla użytkowników wewnętrznych, jak i zewnętrznych, np. serwery bazy danych lub aplikacje, które wymagają bardziej zaawansowanej kontroli dostępu.
Strefa wyłączona – strefa całkowicie chroniona, przeznaczona wyłącznie do użytku wewnętrznego, zawierająca krytyczne systemy, które wymagają najwyższego poziomu zabezpieczeń i są niedostępne dla użytkowników zewnętrznych.
VPN stosuje się do strefy z ograniczonym dostępem, osobiście wdrażam gdyż stosunkowo prosto i niskim kosztem mogę osiągnąć założone cele biznesowe organizacji.
Dzięki VPN jestem w zgodzie m.in. z ISO 27001 także ITIL ale chyba nam to dopełnienie Standardów Kontroli Zarządczej C12 + C15, które to NIK każdej kontrolowanej jednostce wytyka w swoich raportach.
Niefortunnie albo fortunnie każdy na rynku przewiduje minimum 3 scenariusze jak nie ma administrator sieci w głowie tych 3 scenariuszy to powinien przejść inne szkolenia niż CCNP żeby rozjaśnić umysł chociaż na fali są także czerwone muchomory, to jak elektryk bez uprawnień bo przecież każdy wszystko zrobi co najważniejsze będzie działać xD.
Taki Uniwersytet Medyczny im. Piastów Śląskich we Wrocławiu to się w tańcu nie certoli, tylko wystawił EZD PUW, który domyślnie jest tak skonfigurowany, że chyba bym osiwiał, gdybym coś takiego wystawił world-wide: https://ezd.umw.edu.pl/
Użytkownicy gubią telefony, tokeny U2F, stosują to samo hasło w mailu co wszędzie indziej itd. Widziałem każdy z powyższych scenariuszy i obejście nim 2FA i MFA.
Ale jeżeli mamy zestawiony tunel VPN site-to-site, z IPSec-iem i filtrowaniem ruchu, regułą na FW wymagającą że przepuszczamy ruch po jednym certyfikacie z konkretnym CN, to sprzedaj mi scenariusz w którym ktoś włamuje się na VPN i ma dostęp do całej sieci. Tylko bez “są takie 0-day’e że tobie się to w głowie nie mieści”. Realny scenariusz jak to ma wyglądać.
Co do dużych systemów stosujących VPN-y - masa. 3/4 banków ma różnego typu VPN-y do komunikacji między jednostkami (najczęściej dedykowane łącza site-to-site, są tylko zaawansowanymi VPN-ami operatorów) Miejsce gdzie klient masowy ma się łączyć do systemu - tam VPN-ów się nie stosuje. Ale tam gdzie jednostka ma się łączyć do jednostki - zdecydowanie bezpieczniejszy sposób niż MFA.
Bardzo prosty scenariusz, po drugiej stronie masz serwer aplikacyjny, do którego łączą się setki jak nie tysiące użytkowników. Wystarczy zainfekować jednego klienta VPN, następnie przejmujesz serwer aplikacyjny. Z serwera aplikacyjnego możesz atakować już serwer VPN.
Kolejny scenariusz błędy konfiguracyjne VPN.
Kolejny scenariusz, jak już wspomniałeś o 0-day to dlaczego nie skorzystać, skoro producent ma opóźnienia w łataniu CVE-2024-55591, CVE-2025-24472.
Banki używają VPNów do usług wewnętrznych i raczej nie stosują VPNów dla zwykłych klientów. Żadna ceniąca się firma(aż dziwne czemu sądy - udostępniają akta sprawy, zus, urzędy skarbowe nie proponują użytkownikom VPNów), udostępniająca swoje usługi WWW dla kilka tysięcy użytkowników nie proponuje instalacji VPNów, bo nikt nie chciałby korzystać z takich usług.
EZD nie stosuje FortiClienta czy podobnego rozwiązania, ale VPN site-to-site. To zupełnie inne rozwiązanie. Te dwie luki nie mają nic wspólnego z IPSec-iem, Nie ma ani setek ani tysięcy klientów, ale tylko i wyłącznie jednego UTM-a łączącego się z drugim UTM-em, po obu stronach filtrowania ruchu. Tak wygląda tutaj konfiguracja połączenia. Sprzedaj mi jak w tym przypadku wygląda włamanie. Nie jak może wyglądać włamanie na jakiegokolwiek VPN-a.
Michal1 jak najbardziej masz rację, wręcz bezdyskusyjną rację ale tylko w kontekście bezpieczeństwa połączenia jakie daje VPN. Tego że nie da się pod nie podszyć, utracić danych logowania, narzędzia autoryzacji itp. Tylko że Ty skupiłeś się na bezpieczeństwie autoryzacji tego połączenia, a nie na samym bezpieczeństwie tego typu połączenia. VPN na potrzeby EZD RP służy do łączenia ze sobą wielu bardzo różnorodnych firm, z różnymi politykami bezpieczeństwa, z wdrożonymy różnymi systemami zabezpieczeń (wielokrotnie żadnymi - bo np. w takich Szkołach Muzycznych, które również znajdziemy na liście partnerów, na próżno u nich szukać zatrudnionego na etacie administratora systemów informatycznych, informatyka, itp. specjalisty ICT, bo najzwyklej w świecie nie mają środków na ten cel), to tworzenie z nimi wspólnej sieci (bo to efekt VPN) to totalna głupota. Tyle kampanii społecznych aby nie łączyć się z publicznymi sieciami wifi, aby nie udostępniać swojej sieci wifi komputerom spoza naszego gospodarstwa domowego, aby regularnie zmieniać klucz wifi, a tu każą nam tworzyć wspólną sieć z nieznanymi nam podmiotami…
VPN jest super, super bezpieczny, super do łączenia SWOICH fili firmy. Gdzie łączymy w całość dwie (i więcej) bezpiecznych, znanych sobie lokalizacji ale nie jako metoda autoryzacji… do systemu obiegu dokumentów.
Mówisz że login i hasło można utracić, tak samo narzędzie 2FA. A więc łatwo uzyskać nieautoryzowany dostęp do EZD RP. Rozwiązaniem wydaje się być VPN bo prócz loginu i hasła trzeba być w lokalnej sieci partnera. A czym ta sieć się legitymuje? Tak! Publicznym adresem IP. I to powinno być narzędziem autoryzacji a nie zestawianie VPN z cholera wie kim.
Ja nie ryzykuję i ten VPN mam zestawiony w VLAN na DMZ, który absolutnie nie ma dostępu do innych VLAN w mojej sieci. I nie, to nie jest rozwiązanie bo jak napisałem wielu partnerów nie ma specjalistów ICT w swoich kadrach i nie są w stanie dokonać takiej konfiguracji na swoich urządzeniach brzegowych (którymi często są routerki od operatorów) więc popatrzmy troszkę filantropijnie na to zagadnienie że wymagając VPN stwarzamy niemałe zagrożenie w śród naszych słabo rozwiniętych informatycznie partnerów.
