Bezpieczeństwo rządowych stron - analiza

Zespół zadaniowy ds. ochrony portali rządowych opublikował wytyczne. Trudno stwierdzić, że to najlepsze rekomendacje, jakie można było przy okazji zaistniałych ataków wypracować.

Dokument przygotowany przez CERT.GOV.PL przypomina o elementarzu bezpieczeństwa IT. To ważne, ale chyba nie wystarczające. Przejdźmy jednak do treści dokumentu.

Błędne założenia dotyczące bezpieczeństwa

Minister Boni instruuje urzędników, jak chronić rządowe portale

Minister Administracji i Cyfryzacji przekazał resortom wytyczne w zakresie ochrony portali informacyjnych administracji publicznej. Oto ich lista:

  • Podpisując umowy na prowadzenie portali, administracja państwowa ma stosować zapisy pozwalające na wdrażanie systemów eliminacji ruchu anonimizowanego, możliwość całkowitego filtrowania ruchu dotyczącego określonych typów pakietów lub całych protokołów, wprowadzenie odpowiedzialności firmy hostującej za zapewnienie ciągłości działania powierzonego serwisu, użycie mechanizmów automatycznego przełączania wersji witryn w zależności od poziomu wysycenia łącza oraz obciążenia serwera.
  • Wytyczne zalecają też wdrożenie procedur bezpieczeństwa w zakresie korzystania przez pracowników administracji publicznej z poczty elektronicznej. Zalecane jest m.in. zablokowanie dostępu do kont pocztowych przez internet. Jeśli pracownik musi mieć dostęp do poczty poza biurem, powinno być zastosowane łącze VPN.
  • Zaleca się też zachowanie szczególnej ostrożności przy otwieraniu załączników.
  • Administratorzy systemów pocztowych powinni wdrożyć rozwiązania zabezpieczające oparte o kaskady oprogramowania antywirusowego, silne mechanizmy antyspamowe, filtrowanie i blokowanie wysyłanej i odbieranej poczty według zdefiniowanych warunków.
Jako niezbędne wskazane jest w nim ustanowienie stałych kontaktów - jak rozumiem, przez administratorów w domenie gov.pl - z Rządowym Zespołem Reagowania na Incydenty Komputerowe CERT.GOV.PL. Otóż stałe kontakty z tym zespołem istnieją od dawna. Zespół zainstalował w sieciach podmiotów administracji państwowej w ciągu kilku ostatnich lat kilkadziesiąt sond systemu ARAKIS-GOV. Nie dałoby się tego zrobić bez ustanowienia kontaktów z opiekunami tych systemów. Pytanie brzmi raczej: Jak wyglądają te kontakty i czy rekomendacja nie powinna wskazywać na sposoby ich poprawy?

Zobacz również:

  • IDC CIO Summit – potencjał drzemiący w algorytmach
  • Cyberwojna trwa na Bliskim Wschodzie

Pomysły na filtrowanie ruchu sprowadzające się do kontroli aktywności internautów to grube nieporozumienie. To są kwestie dotyczące prawa do prywatności. Propozycja z wytycznych stanowi oczywisty atak na te prawa! Z pewnością skrytykują to organizacje pozarządowe. Zrobiła to już np. Fundacja Panoptykon. W warstwie technicznej też nie wygląda to najlepiej. Jeśli ktoś założył, że zebrane naprędce pomysły co do eliminacji takiego ruchu coś tu pomogą, to się grubo myli. Ataki, jakie wystąpiły, można przeprowadzić bez "ruchu anonimizowanego" i część z nich takimi właśnie była. Dodatkowo "wymuszenie ciągłej aktualizacji tych mechanizmów" to w praktyce apel o ciągły projekt badawczo-rozwojowy. Czy ktoś sobie z tego zdaje sprawę?

Apelowanie zaś o wprowadzenie możliwości "całkowitego filtrowania ruchu dotyczącego określonych typów pakietów lub całych protokołów" jest raczej niepotrzebne. Trudno sobie wyobrazić, aby w domenie gov.pl nie było takiej możliwości, to jedna z podstawowych funkcji zarządzania infrastrukturą dołączenia do internetu. Co gorsza, filtrowanie tego ruchu na urządzeniach znajdujących się bezpośrednio w infrastrukturze atakowanych nie spowoduje uniknięcia problemów, jakich doświadczyły serwery rządowe. Może być raczej powodem kolejnych kłopotów administratorów, jeśli urządzenia te przestaną działać w wyniku przeciążenia.

Szlaban na ataki hakerów

Pomysł przerzucenia odpowiedzialności za zapewnienie ciągłości działania na firmy hostujące i operatorów to sprytny zabieg, ale raczej z dziedziny zamiatania pod dywan. I, niestety, nic nie da. W rzeczywistości ataki nie znikną, bo większość hostujących firm sobie z nimi nie poradzi. Po prostu nie specjalizują się w tym. Chyba lepiej jednak poważnie porozmawiać z operatorami telekomunikacyjnymi, np. w ramach istniejącego Abuse-Forum, co można w takiej sytuacji zrobić. Chwilowe zwiększenie przepustowości, wykorzystanie mechanizmu "blackholingu", dołączanie się do więcej niż jednego operatora czy skorzystanie z usług przetwarzania w chmurze to tylko niektóre z pomysłów, jakie mogłyby pomóc. Zdecydowanie brakuje ich w zestawie wytycznych. To naprawdę dziwne w sytuacji, kiedy właśnie problem blokady serwisów był najbardziej dokuczliwy i najbardziej kojarzony z atakami.

Kolejnym przypadkom mają zapobiec dalsze rekomendacje. Pomysł z automatycznym - lub na żądanie - przełączeniem wersji witryn jest słuszny. Zachęcałbym jednak do unikania przełączania na informację "przerwa techniczna". Warto doprowadzić do tego, żeby serwis "statyczny" był zawsze dostępny w takiej konfiguracji, która maksymalnie redukuje możliwość skutecznego ataku. Dobrym pomysłem jest także wprowadzenie usługi rozkładającej ruch.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200