Spis treści:
-
-
- Podstawowe koncepcje stosowane obecnie w IT
- Rodzaje luk i ryzyk cyberbezpieczeństwa
- Przykładowe luki i ryzyka techniczne
- Dobre praktyki
Nawet najlepsi inżynierowie IT, specjaliści ds. cyberbezpieczeństwa oraz najdroższe skanery podatności nie zabezpieczają w 100% przed incydentami. W tym artykule przyjrzymy się najczęstszym zagrożeniom czyhającym na systemy ICT w organizacjach.
Skanery podatności nie mogą zastąpić myślenia i zdrowego rozsądku. Specjaliści ds. cyberbezpieczeństwa często działają według schematów, podczas gdy hakerzy są bardziej innowacyjni i nieprzewidywalni. Ponadto dział odpowiedzialny za bezpieczeństwo infrastruktury IT często nie funkcjonuje w organizacji tak, jak należy, gdyż jest technicznie lub organizacyjnie „ubezwłasnowolniony”.
Podstawowe koncepcje stosowane obecnie w IT
Obserwując rozwój technologii informacyjnych, można zauważyć, że obecnie stosowane są w IT następujące koncepcje:
- centralizacja;
- standaryzacja;
- wirtualizacja;
- automatyzacja.
Koncepcja centralizacji stosowana jest na wielu poziomach IT, od centralnego zarządzania stacjami roboczymi, urządzeniami mobilnymi użytkowników, poprzez centralne zarządzanie serwisami internetowymi i aplikacjami mobilnymi, po centra danych i tak dalej. Jedną z istotnych kwestii w obrębie centralizacji jest również koncepcja zintegrowanego systemu informacyjnego, która powinna obejmować całą architekturę systemów informatycznych w przedsiębiorstwie wraz z interfejsami międzysystemowymi w celu zaspokojenia wszystkich potrzeb informacyjnych firmy.
Koncepcja standaryzacji dotyczy zarówno sprzętu, oprogramowania, baz danych, jak i wdrażania standardów zarządzania IT takich jak normy ISO, standardy NIST, dobre praktyki ITIL itp. W nowej ustawie o krajowym systemie cyberbezpieczeństwa (dalej: uoksc) mowa o m.in. certyfikacji osób, sprzętu IT. Standaryzacja w IT nabiera więc coraz większego znaczenia.
Koncepcja wirtualizacji dotyczy zarówno wirtualizacji serwerów, jak i produktów i usług IT. To, co kiedyś było produktem (np. MS Office), obecnie stało się usługą ICT oferowaną w chmurze. Filmy czy muzykę na nośnikach elektronicznych zastąpił streaming audio i wideo. Wirtualizacja produktów i usług spowodowała powstanie nowego bytu, jakim są e-usługi. Do tychże możemy zaliczyć wszystkie rozwiązania informatyczne z „e” na początku: e-mail, e-commerce, e-bok, e-banking, e-administracja, e-government czy prężnie rozwijające się ostatnio e-military. Wirtualizacja produktów i usług powoduje nowe zagrożenia w cyberprzestrzeni. Aby im sprostać, niezbędne jest wdrażanie całego pakietu zabezpieczeń, który nie może sprowadzać się tylko do kwestii technicznych, ale również organizacyjno-prawnych i systemowych.
Ostatnia z wymienionych koncepcji – automatyzacja – to zastępowanie pracy manualnej działaniem systemów, które wykonują zadania samodzielnie, powtarzalnie i bez udziału człowieka według ściśle określonych schematów (Robotic Process Automation, RPA).
Rodzaje luk i ryzyk cyberbezpieczeństwa
Luki w systemach IT można podzielić na trzy główne kategorie:
- techniczne;
- organizacyjne;
- systemowe.
Luki techniczne odnoszą się oczywiście do podatności w naszej infrastrukturze IT. Organizacyjne wynikają z kolei z błędnej struktury organizacyjnej, co powoduje, że cyberbezpieczeństwo w firmie nie działa tak, jak powinno. Jeśli coś jest niepoprawnie zaprojektowane (niezgodnie ze standardami zarządzania albo standardami technicznymi) – niezależnie od tego, czy mówimy o systemie informatycznym, czy strukturze organizacyjnej – to nie będzie poprawnie działać.
Luki systemowe są związane przede wszystkim z łamaniem podstawowych zasad cyberbezpieczeństwa, co może docelowo prowadzić do powstania luk technicznych. Przykładem jest sytuacja, gdy system informatyczny zlokalizowany w wewnętrznej sieci LAN zostaje bezpośrednio udostępniony w publicznym internecie poprzez otwarcie odpowiednich portów, bez zastosowania właściwej segmentacji i kontroli ruchu. Takie rozwiązanie zwiększa ekspozycję systemu na zagrożenia i powinno zostać ujęte w analizie ryzyka.
Przykładowe luki i ryzyka techniczne
Systemy ICT, serwisy internetowe, extranetowe i aplikacje mobilne podłączone bezpośrednio do publicznej sieci internet mają najwyższy poziom ryzyka cybernetycznego. Dlatego to na tego typu lukach technicznych skupimy się w dalszej części artykułu.
BRAK SPÓJNEJ WIZJI
Liczba systemów informatycznych, w szczególności w dużych firmach, wymaga opracowania Zintegrowanego Systemu Informacyjnego (dalej: ZSI), który powinien obejmować wszystkie systemy biznesowe oraz interfejsy pomiędzy nimi. Tylko taka wizja umożliwia dodawanie w sposób logiczny i zaplanowany kolejnych systemów do tej architektury. ZSI należy rozwijać zgodnie z koncepcją open architecture, gdzie każdy kolejny system jest jak element puzzli, którego miejsce jest z góry znane. Chaotyczny rozwój architektury systemów oraz mnogość wielokierunkowych interfejsów powodują luki bezpieczeństwa oraz obniżają poziom ciągłości działania. Bez holistycznego spojrzenia na cały układ powiązań międzysystemowych wynikających z przepływów informacyjnych nie da się bezpiecznie zarządzać całą architekturą, w której systemy frontendowe muszą być powiązane z backendowymi. Zgodnie z zasadą Pareta przy dobrze zaprojektowanej architekturze systemów biznesowych właściwie za pomocą czterech z nich (dobrze zintegrowanych ze sobą) można obsłużyć praktycznie 80% przepływów związanych z podstawową działalnością przedsiębiorstwa. Mowa o:
- wielomodułowym systemie ERP, który powinien stanowić jądro ZSI;
- systemie elektronicznego obiegu dokumentów;
- hurtowni danych + business intelligence;
- systemie CMS do obsługi serwisów internetowych i extranetowych.
Reszta systemów biznesowych obsługuje zazwyczaj ok. 20% przepływów, które są związane ze specyfiką działalności przedsiębiorstwa. Do tego oczywiście dochodzi cała gama oprogramowania systemowego, sieciowego, stacji roboczych czy rozwiązań bezpieczeństwa.
SKOMPLIKOWANA INFRASTRUKTURA
Z obserwacji audytorskich wynika, że zjawisko tworzenia tzw. protez informatycznych – dużej liczby skryptów, interfejsów, małych programików, które są wykorzystywane do realizacji różnego rodzaju zadań – wynika przede wszystkim z braku wdrożonego narzędzia analitycznego w postaci tematycznej hurtowni danych wraz z business intelligence. Bez tego z czasem powstaje cała sieć powiązań, mająca służyć wymianie danych, które powinny spływać do hurtowni i dalej być prezentowane za pomocą systemu BI.
Takie skomplikowanie infrastruktury jest podatne na awarie i przerwanie ciągłości działania procesów biznesowych (w tym tych dla organizacji krytycznych). Co za tym idzie, poprawne zaprojektowanie architektury systemów wraz z narzędziem analitycznym jest bardzo istotne z punktu widzenia bezpieczeństwa informacji. Wraz ze wzrostem liczby systemów i zależności technicznych wspierających proces biznesowy rośnie liczba potencjalnych punktów awarii i scenariuszy ryzyka, dlatego należy dążyć do racjonalnego ograniczania zbędnej złożoności architektury. Organizacje powinny również znać zależności pomiędzy procesami biznesowymi, systemami, usługami i aktywami ICT. Jest to istotne m.in. z punktu widzenia realizacji wymagań DORA i NIS 2 dotyczących identyfikacji aktywów, zależności, ryzyka i ciągłości działania.
BŁĘDY PROJEKTOWE
Nie bez powodu w normie ISO 27001 określono, że na cyberbezpieczeństwo należy zwracać uwagę już na etapie projektowania. Źle zaprojektowany serwis internetowy będzie miał luki, których usunięcie może się okazać trudne bez przeprojektowania całego systemu. Przykładem może być np. wymieszanie stron internetowych z extranetowymi. Zgodnie z dobrymi praktykami bezpieczeństwa informacji i ciągłości działania serwis internetowy powinien być oddzielnym bytem względem extranetu. Powód jest prosty – jeśli zaatakowany zostanie serwis internetowy np. banku, to klient nadal będzie mógł używać extranetu w postaci systemu bankowości elektronicznej. W dodatku na stronie głównej tego serwisu extranetowego będzie można umieścić komunikat o awarii serwisu internetowego lub odwrotnie.
Serwisów extranetowych może być wiele i możemy je podzielić na extranet dla: klientów, dostawców i inwestorów. Wszystkie powinny być podlinkowane pod witrynę internetową organizacji, tworząc corporate business portal. Jednym z błędów w projektowaniu takich rozwiązań jest np. przesyłanie danych z formularzy internetowych bezpośrednio do systemu CMS wykorzystywanego do zarządzania extranetem. W ten sposób dane bez żadnej autoryzacji trafiają do bazy danych serwisu extranetowego lub na jego serwer plików. To problem, gdyż wszystko, co przesłane z internetu, należy traktować jako potencjalne zagrożenie, które może skutkować wyciekiem. A w witrynach extranetowych przetwarzane są przecież dane osobowe klientów, dostawców, inwestorów, dziennikarzy lub innych osób.
BRAK WALIDACJI
Jeśli pola na formularzu internetowym nie są walidowane, to ktoś może próbować ataku SQL injection. Jeśli dane z takiego formularza nie trafiają do systemu CMS przeznaczonego do obsługi witryny internetowej, lecz do tego zajmującego się serwisami extranetowymi, to ilość danych osobowych podlegających atakowi jest znacznie większa. Dlatego dla obu typów serwisów należy wykorzystywać odrębne systemy CMS.
RECAPTCHA
Skoro już mowa o formularzach internetowych, należy wspomnieć o mechanizmach ograniczających automatyzację niepożądanych działań, takich jak reCAPTCHA lub inne mechanizmy ochrony przed botami. Brak takiego zabezpieczenia może ułatwiać automatyczne próby logowania, masowe wysyłanie formularzy lub inne formy nadużycia aplikacji. Nie oznacza to jednak, że sam brak reCAPTCHA musi poskutkować atakiem DDoS. Ochrona przed takim naruszeniem wymaga zastosowania odpowiednich mechanizmów na poziomie aplikacji, infrastruktury, sieci i – w razie potrzeby – operatora telekomunikacyjnego. Należy również kontrolować limity liczby i wielkości przesyłanych danych, aby ograniczać ryzyko przeciążenia systemu, bazy danych lub magazynu plików. W przypadku integracji CMS-u z CRM-em, systemem EOD lub innymi rozwiązaniami workflow nieprawidłowe dane lub nadmierny ruch mogą dodatkowo obciążać backend i spowalniać obsługę prawidłowych zgłoszeń. Redundantna infrastruktura, load balancing oraz współpraca z dostawcą łącza telekomunikacyjnego mogą zwiększać odporność na przeciążenia i wybrane scenariusze DDoS, ale nie zastępują kompleksowej ochrony przed tym zagrożeniem.
ZAŁĄCZNIKI PLIKOWE
Zagrożeniem może się także okazać brak zdefiniowanych liczb, formatów oraz wielkości załączników, jeśli użytkownicy mogą przesyłać pliki za pomocą formularzy internetowych lub extranetowych. Może to powodować ataki w postaci przesyłania plików wykonywalnych lub innych zawierających złośliwe oprogramowanie, a także przepełnienia systemu, bazy danych, folderu na serwerze plików.
Implementacja dobrze działającego mechanizmu skanowania załączników jest dosyć skomplikowana i pracochłonna. Co za tym idzie, jest to chyba jedna z najczęstszych luk dotycząca serwisów internetowych, bo wdrożenie takiego rozwiązania bez serwera plików w architekturze witryny jest praktycznie niemożliwe. Jak bowiem skanować w „locie” wszystkie załączniki – a następnie podejrzane pliki umieszczać w kwarantannie, a te czyste w innych folderach – jeśli spływają one bezpośrednio do bazy danych systemu CMS? Dodatkowo, jeśli jakiś plik został usunięty ze względu na to, że zawierał szkodliwe oprogramowanie, to należy powiadomić o tym fakcie klienta, który wgrał dany plik. A następnie poprosić o ponowne dostarczenie – już bez szkodliwego oprogramowania – w formie elektronicznej lub innej.
W niektórych firmach takie załączniki trafiają najpierw do bazy danych CMS-u, a potem są przesyłane dalej za pomocą serwera pocztowego do backendu – systemu CRM, EOD lub innych rozwiązań typu workflow. Nie rozwiązuje to jednak problemu, bo w CMS-ie pozostają nieprzeskanowane pliki, które mogą zawierać złośliwe oprogramowanie. Ponadto serwer pocztowy nie powinien być wykorzystywany do integracji systemów informatycznych. Tak przesłane dane trzeba bowiem później ręcznie przepisywać np. do CRM-u. W systemie pocztowym trudno ponadto zaimplementować sensowne uprawnienia dla użytkowników, bo pliki muszą spływać na zbiorczą skrzynkę, do której ma dostęp wielu odbiorców.
Dochodzą również kwestie wygody – jeśli klient (zgodnie z wymaganiami rodo) poprosi o usunięcie jego danych, to kasowanie wszystkich maili i załączników z takiej zbiorczej skrzynki będzie zwyczajnie uciążliwe. Z kolei w przypadku systemu EOD problem może się okazać inny – na podstawie e-maila trudne będzie automatyczne i poprawne zadekretowanie danej wiadomości w procesie workflow do określonego użytkownika. Co za tym idzie, ktoś będzie musiał te wiadomości przydzielać ręcznie, co jest dosyć pracochłonne.
BRAK SEPARACJI NA POZIOMIE DOMEN
Zgodnie z dobrymi praktykami architekturę domen i dostępności usług należy projektować z uwzględnieniem ich przeznaczenia oraz poziomu ekspozycji. Publicznie dostępne serwisy internetowe i wybrane usługi extranetowe mogą być hostowane w przestrzeni domenowej dostępnej z internetu, natomiast zasoby intranetowe powinny być odpowiednio odseparowane od publicznej sieci i dostępne wyłącznie za pośrednictwem kontrolowanych mechanizmów dostępu. Kluczowe znaczenie ma nie sama nazwa domeny, lecz właściwa segmentacja, kontrola dostępu, konfiguracja DNS oraz separacja ruchu sieciowego.
Częstym błędem w tym przypadku jest tzw. zawijanie ruchu, czyli łączenie się ze stronami intranetowymi poprzez przeglądarkę internetową z zewnątrz, a nie wewnątrz sieci. W ten sposób ruch niepotrzebnie jest „zawijany” z otwartego internetu do zamkniętego intranetu. Prowadzi to do braku separacji ruchu sieciowego. Skrajnym przykładem tego zagrożenia może być sytuacja, gdy do intranetowego modułu administracyjnego, służącego do zarządzania platformą zakupową, prowadzi ten sam URL, który dostawcy zewnętrzni wykorzystują do logowania w extranecie i składania ofert. Jest to przykład braku separacji ruchu na tej samej domenie, która jest jednocześnie wykorzystywana publicznie (w internecie) i wewnętrznie (w intranecie).
„BRUDNE” DANE W BAZACH
Jakość danych w systemach backendowych ma istotne znaczenie z punktu widzenia uwierzytelniania. Proces ten polega zazwyczaj na porównaniu danych logowania zadeklarowanych przez użytkownika ze wzorcem zapisanym w backendzie. Jeśli więc tam znajdują się „brudne dane” klientów lub zduplikowane rekordy, to użytkownik może mieć problem z zalogowaniem się na swoje indywidualne konto lub też łatwo będzie się podszyć pod jego tożsamość, logując na inne konto tego samego klienta. „Brudne dane” użytkowników powodują również niejednoznaczne relacje pomiędzy tabelami, ponieważ nie można ich ze sobą połączyć za pomocą unikalnego numeru użytkownika. Jeśli ten sam użytkownik ma wiele kont w systemie, to istnieje ryzyko, że ktoś inny zaloguje się na jedno z nich i uzyska dostęp do informacji na nim zgromadzonych. Problem ten występuje np. w przypadku, gdy użytkownikowi umożliwia się logowanie do systemu za pomocą różnych identyfikatorów – raz PESEL-em, innym razem po numerze umowy czy dowodu osobistego. Jeden użytkownik powinien mieć jeden identyfikator w systemie i na jego podstawie powinny być wykonane relacje w systemach backendowych. Wykorzystanie różnych identyfikatorów może powodować bowiem brak spójności danych użytkownika.
LOGOWANIE PRZEZ SOCIAL MEDIA
Wykorzystanie zewnętrznego dostawcy tożsamości lub logowania za pośrednictwem mediów społecznościowych nie jest samo w sobie niebezpieczne. Ryzyko zależy m.in. od poziomu zaufania do dostawcy tożsamości, sposobu konfiguracji federacji, ochrony tokenów i sesji oraz zastosowania MFA. Szczególną uwagę należy zwrócić na możliwość przejęcia konta u dostawcy tożsamości i na konsekwencje dla systemów zintegrowanych. Bezpieczne wdrożenie powinno się opierać na odpowiednim modelu uwierzytelniania i autoryzacji, zasadzie minimalnych uprawnień oraz monitorowaniu zdarzeń bezpieczeństwa.
DOSTĘP VS. UPRAWNIENIA
Można odnieść wrażenie, że często pojęcia „dostęp” oraz „uprawnienia” są traktowane jak synonimy. Tymczasem w języku angielskim nie bez powodu mamy dwa różne słowa – oznaczające wyłącznie dostęp „access” oraz „permissions” lub „privileges” dotyczące uprawnień w systemie. W niektórych systemach użytkownik, uzyskując dostęp, automatycznie dostaje uprawnienia do wszystkich funkcji systemu biznesowego. Jest to oczywiście niezgodne z zasadą minimalnych uprawnień. Złamanie każdej generalnej zasady określonej np. w normie ISO 27002 lub standardzie NIST SP 800-53 zawsze powoduje lukę bezpieczeństwa. Pozostaje jedynie udowodnić, że można ją wykorzystać od strony technicznej. Przy okazji należy wspomnieć, że kolejnym problemem w wielu systemach informatycznych – nawet najbardziej znanych producentów – jest brak możliwości wygenerowania z systemu do pliku listy uprawnień wszystkich ról lub użytkowników. A przecież jest to praktycznie niezbędne do przeprowadzenia przeglądu uprawnień, który – zgodnie z normą ISO 27001 – powinien być wykonywany regularnie. Wspomniany dokument nie określa wprost ram czasowych, natomiast wskazane jest, że uprawnienia użytkowników powinny być cyklicznie przeglądane i weryfikowane. Przy dużej liczbie użytkowników niezbędny jest ponadto zrzut danych do arkusza kalkulacyjnego, aby ten proces przeprowadzić skutecznie.
BRAK ZABEZPIECZEŃ W SYSTEMIE CMS
Specyfiką systemów CMS jest to, że udostępniają one treści z określonych folderów, które wyświetlają się w internecie. Jeśli użytkownik wysyła załączniki (np. CV), to pliki te też trafiają do folderów w CMS-ie lub na dyski sieciowe. Dostęp do obu typów katalogów nie może być więc identyczny. Wiąże się to z prostym faktem – foldery, z których publikowana jest zawartość stron www, mogłyby zostać upublicznione w internecie np. przez roboty wyszukiwarki Google’a. W związku z tym niezbędne jest dokładne pilnowanie folderów, do których trafiają pliki przesyłane przez użytkowników, aby nie zostały one przypadkowo upublicznione.
UDOSTĘPNIANIE PANELI ADMINISTRACYJNYCH
Model hybrydowy, w ramach którego niektóre funkcjonalności systemów są rozwijane przez pracowników firmy, a inne przez zewnętrznych dostawców, jest obecnie chyba najpopularniejszy w przedsiębiorstwach. W takim wypadku dostawcy muszą mieć zapewniony bezpieczny dostęp do infrastruktury firmy. Najczęściej stosuje się wtedy bezpośrednie łącza site-to-site lub dostęp za pomocą VPN-u – podobnie jak to ma miejsce w przypadku pracowników. Niektóre firmy jednak idą na skróty i udostępniają w internecie strony www z panelami do logowania dla swoich dostawców. W dodatku pozwalają, aby te witryny indeksowały się w wyszukiwarce Google. Znane są również przypadki udostępniania panelu do logowania do własnej domeny. Jest to niebezpieczne rozwiązanie, gdyż umożliwia próby ataków lub testowania loginów i haseł przez boty. Jeśli już ktoś chce udostępniać taki panel administracyjny swoim dostawcom, to powinien na stronie do logowania ustawić parametry no index i no follow, aby strony nie można było wyszukać w wyszukiwarce firmy Google. Ogólnie brak rejestru domen i subdomen, centralnego zakupu nowych domen przez jedną komórkę organizacyjną w firmie oraz brak weryfikacji tego, co pracownicy wyświetlają w internecie, jest jednym z najczęstszych błędów, który powoduje wiele różnych luk bezpieczeństwa. Należy również pamiętać, by zainwestować w centralny rejestr certyfikatów SSL kupowanych dla naszych domen.
BRAK ŚRODOWISK I UŻYTKOWNIKÓW TESTOWYCH
Przeprowadzenie testów penetracyjnych na środowisku produkcyjnym wiąże się z ryzykiem zakłócenia działania usług. Co za tym idzie, istotne jest zapewnienie odpowiednio odseparowanych środowisk deweloperskich, testowych i produkcyjnych oraz bezpiecznych kont testowych. ISO/IEC 27001 nie nakazuje jednak, aby każdy system biznesowy miał dokładnie trzy określone środowiska ani aby każde z nich działało na osobnej subdomenie. Zakres separacji powinien wynikać z architektury, potrzeb procesu wytwarzania oraz oceny ryzyka. Jeżeli w testach wykorzystywane są dane rzeczywiste, w szczególności dane osobowe, należy zastosować odpowiednie środki ochrony, takie jak anonimizacja lub pseudonimizacja, zgodnie z wymaganiami prawnymi i przyjętymi zasadami bezpieczeństwa. Środowiska testowe i szkoleniowe powinny być odpowiednio odseparowane od produkcji i nie powinny niepotrzebnie zwiększać ekspozycji organizacji na internet.
LINKI I ELEMENTY INTERAKTYWNE W E-MAILACH
Wysyłanie linków z systemów płatności za faktury lub innych elementów interaktywnych, które przenoszą użytkownika na strony www, jest jednym z częstych błędów, w szczególności w firmach z branży użyteczności publicznej (dostawcy prądu, gazu, wody, usług telekomunikacyjnych). Takie działania nie zagrażają bezpośrednio bezpieczeństwu firmy, tylko jej klientowi.
NIEAUTORYZOWANE KONTA POCZTOWE
Poczta elektroniczna może być bezpiecznym kanałem komunikacji, jeżeli zastosowano odpowiednie mechanizmy ochrony, jednak sama transmisja e-mail nie zapewnia automatycznie pełnej poufności i autentyczności wiadomości. Należy rozróżnić szyfrowanie transmisji, np. TLS, od szyfrowania treści wiadomości end-to-end. Istotnymi zagrożeniami pozostają również e-mail spoofing oraz możliwość podszywania się pod nadawcę. Dlatego organizacje powinny stosować m.in. mechanizmy zabezpieczające SPF, DKIM i DMARC, a także odpowiednie techniki uwierzytelniania użytkowników. Szczególnej kontroli wymagają wiadomości przychodzące z adresów, które nie zostały wcześniej zweryfikowane lub nie odpowiadają uzgodnionym kanałom komunikacji.
BRAK SZYFROWANIA E-MAILI
W przypadku przesyłania załączników zawierających dane osobowe lub inne informacje poufne należy zastosować środki ochrony adekwatne do poziomu ryzyka. Może to oznaczać szyfrowanie pliku, zastosowanie bezpiecznego kanału wymiany dokumentów lub zabezpieczenie załącznika hasłem, przy czym hasło powinno być przekazane innym kanałem. Przepisy rodo nie ustanawiają ogólnego obowiązku zabezpieczania każdego załącznika hasłem – wymagają natomiast zastosowania odpowiednich środków technicznych i organizacyjnych adekwatnych do ryzyka. W przypadku danych o podwyższonym poziomie poufności bezpieczny portal typu e-BOK lub system bankowości elektronicznej może zapewniać lepszą kontrolę dostępu, uwierzytelniania, retencji i audytowania niż zwykła poczta elektroniczna. W takich systemach transmisja powinna być chroniona za pomocą aktualnych mechanizmów TLS.
Warto również dodać, że 26 czerwca 2026 r. Ministerstwo Cyfryzacji opublikowało rekomendację Pełnomocnika Rządu ds. Cyberbezpieczeństwa dotyczącą ograniczenia ryzyk przy wysyłaniu e maili nieszyfrowanymi kanałami. Jest ona skierowana przede wszystkim do podmiotów krajowego systemu cyberbezpieczeństwa (ksc).
Ministerstwo zaleca przede wszystkim:
- szyfrowanie transmisji pocztowej za pomocą TLS – problemem jest sytuacja, w której e-mail może być przesyłany otwartym tekstem;
- wyłączenie przestarzałych i słabych algorytmów kryptograficznych;
- prawidłową konfigurację serwerów pocztowych, w szczególności tak, aby następowała weryfikacja certyfikatów TLS;
- konfigurację rekordów PTR w DNS – czyli prawidłowe powiązanie adresu IP serwera pocztowego z jego nazwą domenową;
- ograniczenie ryzyka ataku Man-in-the-Middle (MitM) i przechwycenia korespondencji;
- podniesienie poziomu bezpieczeństwa systemów informacyjnych podmiotów ksc.
Ponadto w aplikacjach extranetowych wiadomość wpada do systemu informatycznego – np. CMS-u, skąd można ją dalej przesyłać za pomocą workflow do systemów backendowych, np. CRM-u, EOD lub innych. Oznacza to, że nie przechodzą one przez indywidualne konta pracowników lub grupy mailingowe, zatem unikamy nadmiernego gromadzenia danych osobowych na skrzynkach personelu oraz problemów z retencją tych danych oraz ich anonimizacją.
UWIERZYTELNIANIE UŻYTKOWNIKÓW
Stosowanie wielu identyfikatorów użytkownika w różnych systemach może utrudniać zarządzanie tożsamością i spójnością danych. Warto zapewnić jednoznaczny, stabilny identyfikator techniczny użytkownika oraz odpowiednie mapowanie identyfikatorów biznesowych, takich jak numer umowy czy inne dane referencyjne. Nie oznacza to jednak, że identyfikator techniczny używany w bazie danych musi być jednocześnie tym używanym przez użytkownika podczas logowania ani że autoinkrementacja jest zawsze najbezpieczniejszym rozwiązaniem. W zależności od architektury można stosować np. UUID lub inne odpowiednio chronione identyfikatory. Należy również pamiętać, że zastosowanie dwóch metod uwierzytelniania nie oznacza automatycznie wzrostu ryzyka o 100%. Jeżeli są to dwa niezależne czynniki, np. hasło i token lub klucz sprzętowy, mamy do czynienia z MFA, które co do zasady zwiększa odporność na przejęcie konta. Jeżeli natomiast są to jedynie alternatywne sposoby logowania oparte na tym samym czynniku, ich wpływ na ryzyko należy ocenić indywidualnie.
DOSTĘP DO INTERNETU Z POMINIĘCIEM STREFY DMZ
Klasyczny błąd pójścia na skróty z pominięciem zasad cyberbezpieczeństwa – byleby było szybko i tanio. Jako przykład możemy podać jedną z dużych polskich firm, która udostępniła prosty formularz internetowy i podłączyła go bezpośrednio do centralnej bazy danych klientów, by ci mogli samodzielnie aktualizować dane. Co prawda rozwiązanie to zabezpieczyła za pomocą wygasającego po jakimś czasie tokenu, ale nie miało to znaczenia, gdyż jednocześnie otworzyła porty w swojej sieci LAN, udostępniając tym samym całą wspomnianą bazę. Zabrakło ponadto konieczności uwierzytelnienia się przed edycją swoich danych osobowych.
ZBYT WIELE SYSTEMÓW
Wdrażanie kolejnych systemów na frontendzie, jeśli mamy „bałagan” na backendzie, będzie powodował luki bezpieczeństwa, chociażby związane z uwierzytelnieniem użytkowników, o których była wcześniej mowa. Ze względu na presję biznesową często, jeszcze zanim zakończy się jedna zmiana i proces konsolidacji danych np. w przypadku fuzji dwóch banków lub firm, wdrażane są kolejna modyfikacja, nowe systemy informatyczne, serwisy internetowe czy aplikacje mobilne dla klientów. Wymusza to na dziale IT tworzenie różnego rodzaju rozwiązań tymczasowych, które potem pozostają już na stałe, co powoduje coraz większe komplikowanie się architektury systemów i zjawisko permanentnej zmiany. W ten sposób nie da się dokończyć jednego wdrożenia i po nim posprzątać, gdyż „na już” trzeba wdrażać kolejne systemy na istniejącej „prowizorce”. Z czasem takich tymczasowych obejść przybywa, co powoduje luki bezpieczeństwa.
Nie można zakładać, że każdy system musi mieć identyczny model identyfikatorów. Kluczowe jest jednak zapewnienie jednoznacznego powiązania tożsamości użytkownika pomiędzy systemami oraz właściwego zarządzania cyklem życia kont, uprawnień i danych referencyjnych.
NIEWŁAŚCIWE WYKORZYSTYWANIE SYSTEMÓW
Zasadniczo systemy informatyczne możemy podzielić na trzy grupy:
- transakcyjne, które służą do rejestracji transakcji (rekordów), np. systemy ERP, CRM, billing, które mają wbudowane raporty tworzone zasadniczo tylko z danych znajdujących się w bazie danych danego systemu informatycznego;
- pracy grupowej, np. systemy EOD służące do przepływu pracy pomiędzy użytkownikami zgodnie ze zdefiniowanymi schematami przebiegu procesów biznesowych;
- analityczne, np. hurtownie danych + BI, których zadaniem jest tworzenie multiraportów na podstawie danych pochodzących z wielu różnych systemów informatycznych.
Każdy z powyższych służy więc do zupełnie innych zastosowań. Co prawda w systemach transakcyjnych też często wbudowany jest moduł workflow, ale służy do obsługi prostych procesów – np. akceptacji transakcji, wniosków urlopowych czy zakupowych – a nie do masowego zarządzania dokumentami takimi jak faktury czy pisma od klientów. System informatyczny to nie jest kombajn, który służy do wszystkiego. Jest przeznaczony do ściśle określonych zastosowań, które wynikają z jego architektury technicznej. Niektóre firmy niestety tego nie rozumieją i np. w ERP, czyli w module workflow systemu transakcyjnego, tworzą cały rozbudowany system obiegu faktur. Poza „zaśmiecaniem” takiego rozwiązania i pompowaniem do niego tysięcy niepotrzebnych danych oraz plików, co powoduje problemy wydajnościowe, rozwiązanie takie ma również wiele luk bezpieczeństwa. Zdarza się, że firmy mają profesjonalne systemy EOD, które wykorzystują do obsługi tylko prostych procesów wewnętrznych (np. akceptacja wniosków urlopowych czy zakupowych), podczas gdy małe moduły workflow w ERP czy systemie billingowym przetwarzają miliony faktur i pism od klientów.
KLIENT TAK CHCIAŁ
Ostatni przykład powstawania luk bezpieczeństwa wiąże się z ignorowaniem podstawowych zasad cyberbezpieczeństwa i to nie tylko przez pracowników, ale również dostawców zewnętrznych. Często naciski ze strony działu sprzedaży lub samego klienta powodują, że pewne rozwiązania tworzy się szybko i jak najmniejszym kosztem, i tym samym ignorowane są kwestie cyberbezpieczeństwa. Często tę samą funkcjonalność można zrobić na trzy sposoby i różnym nakładem finansowym. O tym, które rozwiązanie jest poprawne, powinny decydować aspekty ochrony infrastruktury. Jeśli wybór następuje na podstawie innych kryteriów, to często dochodzi do realizacji rozwiązań, które mają luki od samego początku ich stworzenia.
Dobre praktyki
Powyższa lista, choć długa, nie wyczerpuje wszystkich ryzyk i luk cyberbezpieczeństwa w infrastrukturze IT organizacji. Niezależnie od wybranego zagrożenia konkluzja może być jednak zbliżona – podstawą cyfrowego bezpieczeństwa każdej firmy powinny być zdrowy rozsądek, budowa struktur i środowisk od podstaw (bez pomijania choćby najbardziej prozaicznych etapów) oraz chęć do inwestowania w sprawdzone i pewne rozwiązania. Koszty potencjalnych problemów mogą bowiem się okazać wielokrotnie wyższe niż wysiłek niezbędny, by im zapobiec.
Autor
Marek Prasoł
Autor jest absolwentem studiów podyplomowych na kierunku aplikacje internetowe i mobilne. Posiada m.in. certyfikat audytora wiodącego ISO 27001, audytora wiodącego ISO 22301, ITIL oraz specjalisty ds. rodo. W przeszłości zajmował się wdrażaniem oraz audytowaniem zarówno systemów informatycznych, serwisów internetowych, aplikacji mobilnych, jak również systemów zarządzania bezpieczeństwa informacji – ISO 27001, zarządzania ryzykiem – ISO 31000, zarządzania ciągłością działania – ISO 22301 oraz zarządzania jakością usług ICT – ISO 20000 dla czołowych firm w Polsce.
