Podziel się opinią o serwisie

reklama

IBM

Strefa IBM System x


Strefa IBM System x"..."Zarządzanie infrastruktura IT w obecnej chwili pochłania znaczną część budżetu IT. W odpowiedzi na tą sytuację IBM dołącza do serwerów IBM System x® system do zarządzania IBM Systems Director®, który oferuje obszerny zbiór narzędzi ułatwiających administrację.
Zapraszamy do strefy »

popularne komentowane nowości

Biblioteka Wiedzy poleca

Sprzedaż z pełnym wsparciem

Wdrożenie w Banku Pekao SA nowoczesnego systemu wspierającego sprzedaż pozwoliło na zwiększenie efektywności sprzedażowej pracowników i zmniejszenie...
pobierz »

Dynamiczna kostka: moc wirtualizacji w olsztyńskim RCI

Niższe rachunki za energię, wysoka wydajność i zwiększona dostępność systemu - to korzyści w obszarze IT jakie Uniwersytet Warmińsko Mazurski uzyskał...
pobierz »

Raport o internetowych zagrożeniach bezpieczeństwa

"Internet Security Threat Report" - kolejna edycja znanego raportu firmy Symantec zawierającego globalny przegląd stanu bezpieczeństwa w Internecie....
pobierz »

Więcej bezpłatnych raportów w serwisie
powiększ tekst >
ARCHIWUM

Jak zabezpieczyć środowisko wirtualne

8 czerwca 2010

Marcin Marciniak
Zapewnienie bezpieczeństwa środowisku wirtualizowanemu wydaje się proste - wystarczy powielić rozwiązania typowe dla infrastruktury klasycznej. Tymczasem, wirtualizowane środowisko różni się od klasycznego i należy wziąć to pod uwagę.

Jeszcze kilka lat temu do ochrony sieci z powodzeniem wystarczyła zapora oraz system detekcji intruzów, który wychwytywał pierwsze symptomy niepokojącego ruchu. W tym czasie większość ataków przychodziła z zewnątrz, zatem wystarczyło zablokowanie ich na zaporze sieciowej. Obecnie większość ataków, które mają na celu zdobycie informacji, wykonywane jest od wewnątrz, przy pomocy złośliwego oprogramowania instalowanego w wielostopniowym procesie drive-by. Z kolei ataki z zewnątrz kierowane są głównie przeciw aplikacjom webowym, wykorzystując błędy takie jak SQL Injection i Cross-Site Scripting.

Ochrona jest zbyt daleko

Zapora sieciowa, nawet wyposażona w system detekcji intruzów, nie ochroni całego środowiska w dostateczny sposób. Aby ochrona była optymalna, należy dostosować ją do każdej z aplikacji z osobna. W typowym rozwiązaniu wiąże się to z bardzo skomplikowaną listą reguł, gdy cały ruch z wielu maszyn miałby być filtrowany w jednym miejscu. Jednym z poważniejszych błędów jest korzystanie z pojedynczego interfejsu sieciowego po stronie serwera dla wielu maszyn wirtualnych bez tagowania VLAN.

Polityka powinna iść za maszyną

Środowisko wirtualizowane wiąże się z przenoszeniem maszyn między fizycznymi serwerami, często także między centrami przetwarzania danych zlokalizowanymi w różnych miejscach. Niekiedy przeniesienie maszyny wiąże się ze zmianą założeń polityki bezpieczeństwa. Taką zmianę, po pierwsze, należy uwzględnić, po drugie, firma musi posiadać środowisko, które wymusi nowe założenia tej polityki. Wymaganą elastyczność bardzo trudno zapewnić tradycyjnymi metodami, gdyż ochrona za pomocą zapór i systemów sieciowego DLP znajduje się zbyt daleko od chronionych zasobów.

Obszar na dysku

Maszyny wirtualne, w odróżnieniu od serwera pracującego bezpośrednio na sprzęcie, posiadają więcej niż jeden stan, w którym można wpływać na ich zawartość. Gdy serwer pracujący bezpośrednio na sprzęcie jest wyłączony, z nielicznymi wyjątkami dostęp do niego jest niemożliwy. Dla porównania, wyłączona maszyna wirtualna to kilka plików lub zestaw bloków na współdzielonych dyskach. Jeśli nie stosuje się odpowiednich procedur i narzędzi kontroli, taką maszynę w stanie wyłączenia można zmodyfikować. Podobna zmiana w przypadku tradycyjnej infrastruktury wymagałaby wizyty intruza w serwerowni. W środowisku wirtualnym może to umożliwić trywialny błąd administratora związany z ustawieniem uprawnień. Wynika stąd konieczność opracowania procedur oraz założeń polityki bezpieczeństwa - maszyny wirtualne należy kontrolować przed każdym uruchomieniem.

Tymczasowe łatanie dziury

Dzisiejsze ataki charakteryzują się dużą szybkością - niejednokrotnie od opublikowania informacji o luce do ataków upływają zaledwie godziny. Z drugiej strony, aplikacje biznesowe nie zawsze mogą być aktualizowane tak szybko, dlatego powstaje rozziew między możliwościami aktualizacji a potrzebami zapewnienia bezpieczeństwa. Chociaż systemy detekcji intruzów potrafią chronić podatne aplikacje przed atakami, nie zawsze mogą to zrobić w optymalny sposób. Ideałem jest ochrona, która sama rozpoznaje podatności danego systemu (na przykład, sprawdzając jego stan aktualizacji), a następnie odpowiednio dostosowuje swoją ochronę. Gdy cała procedura związana z wdrożeniem łaty zostanie wykonana, system stwierdzi, że dla danego systemu nie jest już potrzebna ochrona przed lukami, które ta łata usuwała. Ma to kolosalne znaczenie, gdy w tym samym wirtualizowanym środowisku pracuje wiele systemów o różnym stopniu aktualizacji i podatności. Niekiedy firma może stać przed ważną decyzją związaną z koniecznością eksploatacji aplikacji, w której luki w bezpieczeństwie są już powszechnie znane, ale nadal nie można zaaplikować odpowiednich łat. Wtedy narzędzia ochronne, które potrafią selektywnie blokować ataki, dają szansę na bezpieczną eksploatację aplikacji do czasu jej aktualizacji.

Zapora podąży za serwerem
W środowisku wirtualizowanym można zrealizować bardzo ciekawą koncepcję ochrony, która zakłada filtrowanie ruchu przez zaporę uruchomioną razem z aplikacją w osobnej maszynie wirtualnej. Rozwiązanie takie ma wiele zalet. Po pierwsze, dzięki odpowiedniej konfiguracji interfejsów sieciowych, nie ma możliwości, by do aplikacji dostał się ruch niefiltrowany przez zaporę. Po drugie, reguły ochrony wymuszane na zaporze sieciowej można dostroić do danej aplikacji, nie przejmując się innymi zasobami, których dana zapora nie chroni - oznacza to lepszą optymalizację. Oznacza to na przykład brak inspekcji i ochrony przed atakami, które dotyczą innej platformy sprzętowej - po co chronić serwer pracujący pod kontrolą systemu Linux przed podatnościami dotyczącymi Windows i odwrotnie. Po trzecie, zapora taka może być przenoszona razem z maszyną wirtualną, w której pracuje aplikacja - gdy maszyna wirtualna przechodzi do nowego hosta, razem z nią przechodzi także zapora, która ją chroni.

Tekst pochodzi z serwisu Computerworld
Wystaw ocenę:
    Średnia ocena (liczba głosów: 0)
wydrukuj wydrukuj wyslij do znajomegowyślij do znajomego rss

Komentarze

Redakcja securitystandard.pl - bezpieczeństwo IT , aktualnosci, porady, produkty nie ponosi odpowiedzialności za wypowiedzi Internautów opublikowane na stronach serwisu oraz zastrzega sobie prawo do redagowania, skracania bądź usuwania komentarzy zawierających treści zabronione przez prawo, uznawane za obraźliwie lub naruszające zasady współżycia społecznego. Osoby zamieszczające wypowiedzi naruszające prawo lub prawem chronione dobra osób trzecich mogą ponieść z tego tytułu odpowiedzialność karną lub cywilną.

Ten artykuł nie ma jeszcze żadnych komentarzy. Twój może być pierwszy...