Nowe usługi, nowe zagrożenia

Można wyróżnić trzy rodzaje rozwiązań bezpieczeństwa związane z poziomami ryzyka wprowadzanymi przez wirtualizację: specyficzne dla wirtualizacji produkty wycinkowe (pracujące oddzielnie), tradycyjne narzędzia do zarządzania siecią i systemem (uzupełnione pewną funkcjonalnością uwzględniającą problemy hypervisora, bez możliwości wglądu w działania maszyn wirtualnych) oraz narzędzia bezpieczeństwa specyficzne problemowo (przystosowane do wirtualizacji).

Warto podkreślić, że żadne rozwiązanie nie ogranicza rozprzestrzeniania się maszyn wirtualnych poza kontrolowane środowisko centrum danych, co wiąże się z problemem zabezpieczenia przed instalacją wrogich maszyn wirtualnych na urządzeniach końcowych sieci.

Jednym z krytycznych, lecz często niedocenianym zadaniem w środowisku wirtualnym, jest kwestia bezpiecznego podniesienia komputera z trybu zawieszenia (uśpienia). Problem stanowi upewnienie się, czy maszyna, która znajdowała się w stanie uśpienia, została uaktualniona i połatana, zanim dopuści się ją do funkcjonowania w sieci wirtualnej. Realizowane jest to w różny sposób, w zależności od dostawcy rozwiązania do zarządzania wirtualizacją.

W ramach swojego programu zarządzania cyklem życia Novell na przykład utrzymuje różne stany wirtualnych serwerów w kontrolowanej hurtowni danych. System ten może zostać skonfigurowany do poddania zawieszonej maszyny wirtualnej procesowi łatania, zanim będzie mogła włączyć się do wirtualnej sieci.

Enterprise Configuration Manager for Virtualization firmy Configuresoft (zintegrowany z EDM Service Desk) może informować Service Desk o reaktywacji i porównywać zdjęcie stanu maszyny z listą kontrolną bezpieczeństwa przed reaktywacją.

Bezpieczeństwo poziomu aplikacyjnego

Nowe usługi, nowe zagrożenia

Web services i stos serwera

Kontrola wersji i konfiguracji to również duże wyzwania w przypadku SOA, a także coraz bardziej mobilnej infrastruktury aplikacyjnej wymiany komunikatów, budowanej w architekturze SOA i opartej na XML.

Aplikacje webowe stały się głównym celem ataków w ostatnich dwóch latach. Łączenie tych aplikacji i zapewnianie im dostępu do partnerskich systemów zaplecza poprzez Web Services prowokuje napastników do wykorzystywania tego kanału, jako sposobu dostania się właśnie do tych systemów zaplecza.

Firmy specjalizujące się w rozwiązaniach SOA przyznają, że występują problemy z uaktualnianiem i łataniem. Trudno dostarczyć technologię, w którą chce się wyposażyć firmy bez porozumienia z operatorami zapewniającymi im dostęp. Nawet wtedy, gdy systemy zaplecza są w pełni oparte na standardach, kontrolowanie wersji nadal stanowi problem.

Inny problem bezpieczeństwa dotyczy parserów (analizatorów składniowych), używanych w aplikacjach do translacji XML na HTTP - uniwersalny język, powszechnie akceptowany przez zapory ogniowe IP. Firmy używające parserów dostawców niezależnych powinni upewniać się, jak silne zabezpieczenia są wbudowane w same parsery. Ponadto projektanci winni wkomponowywać w cykl projektowania testy i utwardzanie bezpieczeństwa takich komponentów.

Rozwiązaniem może być np. szyfrowanie plików. Dla transmisji wiadomości SOA można zdać się na SSL (Secure Socket Layer). Można też skorzystać ze standardów szyfrowania aplikacji webowych z Open Web Application Security Project, standardów szyfrowania SOAP i innych pomocnych przy budowaniu spójnych reguł szyfrowania i uwierzytelniania, które mogą być stosowane między tymi aplikacjami.

Szyfrowanie jest niewątpliwie elementem dobrych praktyk i można tu np. wykorzystywać standardy, takie jak: Security Assertion Markup Language (SAML) oraz certyfikaty x.509, które towarzyszą wiadomości w celu zweryfikowania jej na bramie. Jednak niezamierzoną konsekwencją takiego podejścia jest zagrożenie ze strony zaszyfrowanych złośliwych ładunków HTTP, przenikających przez ochronę zapory ogniowej. Obecnie przy zaszyfrowanej wiadomości ani zapora ogniowa, ani systemy wykrywania włamań nie mają możliwości kontroli złośliwego ładunku przechodzącego przez ich porty HTTP.

Nie należy zapominać, że te połączenia prowadzą prosto do serwerów partnerów biznesowych, która to ścieżka może być wykorzystana przez specjalnie "skrojone" wiadomości XML i przejęte parsery (zob. ramka Podstawowe zagrożenia SOA).

Według ekspertów, sieci z tożsamością federacyjną będą odgrywały zasadniczą rolę w zarządzaniu wiadomościami zawierającymi zlecenia kontroli referencji, przechodzącymi przez wiele systemów należących do wielu właścicieli w ramach SOA. A tak na marginesie, IDC przewiduje, że wydatki na inicjatywy SOA w roku 2011 osiągną kwotę 14 mld USD.

Bezpieczeństwo warstwy mobilnej

Architektura SOA powiązana jest wielokrotnie z urządzeniami mobilnymi. Telefony komórkowe są często używane przez pracowników jako narzędzie dostępu do poczty elektronicznej i innych funkcji.

Mobilność przede wszystkim powinna być obsługiwana z wykorzystaniem szyfrowania. Ochrona urządzeń mobilnych (laptopów czy urządzeń BlackBerry) jest dużo bardziej dojrzała niż środki bezpieczeństwa dla wirtualizacji i SOA. Jest to szczególnie widoczne w przypadku zarządzania punktami końcowymi sieci z wykorzystaniem systemu kontroli dostępu do sieci NAC (Network Access Control).

W swej podstawowej formie NAC wymusza stosowanie obowiązującej polityki bezpieczeństwa w urządzeniach próbujących podłączyć się do sieci. Systemy NAC ustalają stan bezpieczeństwa urządzenia i - opierając się na tych ustaleniach - podejmują decyzje o dostępie do sieci. Stan urządzenia można określić w prosty sposób, np. przez uwierzytelnienie rozpoznanego użytkownika, lub złożony: m.in. przez skanowanie systemu klienckiego w celu wyznaczenia np. ustawień konfiguracyjnych czy poziomu zainstalowanych łatek. Opierając się na tak zdefiniowanym stanie bezpieczeństwa, system NAC decyduje, jaki zakres dostępu (włącznie z odmową) można przyznać urządzeniu.

Pod uwagę mogą być brane także zmiany, które pojawiły się w urządzeniu po tym, jak uzyskało gwarancję dostępu. Niezależnie od tego, czy użytkownik stanowi zagrożenie świadomie czy nieświadomie, urządzenie może stać się zagrożeniem dla sieci po uzyskaniu dostępu, kiedy nowe procesy uaktywnią się: mogą wtedy propagować nowe złośliwe kody lub działania przekształcające komputer w napastnika. Bardziej wymyślne systemy NAC są w stanie wykrywać tego rodzaju zdarzenia i wyzwalać reguły polityki nie tylko wtedy, gdy urządzenie podłącza się do sieci.

Z zarządzaniem bezpieczeństwem punktów końcowych jest też łączone szyfrowanie (np. Symantec dołącza do zestawu zabezpieczeń punktów końcowych sieci szyfrowanie w punkcie końcowym). Gartner ocenia, że platformy bezpieczeństwa punktów końcowych sieci stworzą w roku 2009 rynek o wartości 3,6 mld USD.

Podstawowe zagrożenia dla bezpieczeństwa sieci dotyczące SOA

  • Zagrożenia związane z zawartością, wykorzystujące wiadomości XML jako nośnik. Są to ataki na aplikacje webowe, cross-site scripting, SQL Injection itp.
  • Nadużywanie lub niewłaściwe używanie XML w celu zmanipulowania samego protokołu XML - specjalnie zmodyfikowana XPath może narażać dokumenty XML i źródła danych (atak XPath injection, wykorzystujący legalne struktury w złych intencjach, w tym wypadku używający cross-site scripting w wiadomościach XPath).
  • Manipulowanie strukturą XML i komponentami infrastruktury XML. Typowe cele ataków: parsery, interpretatory, silniki przetwarzania (zarówno open source, jak i closed source).
  • Ataki na infrastrukturę SOA skierowane na routery zawartości, uwierzytelnianie, silniki SAML, serwery certyfikatów i inne komponenty.

TOP 200