Rosnąca popularyzacja technologii wirtualizacji, zarówno w dużych, jak i małych firmach, doprowadziła do pojawienia się nowej klasy zagrożeń dla bezpieczeństwa infrastruktury IT. Administratorzy systemów wirtualizacji w data center posiadają uprawnienia kontroli niespotykane dotychczas w systemach informatycznych.

Efektywne prowadzenie działalności w otoczeniu zmiennych warunków makroekonomicznych oraz silnej konkurencji nie jest łatwym zadaniem. Sprawdzone i dotąd skuteczne modele biznesowe dezaktualizują się z czasem, w związku z czym każda organizacja, chcąc się rozwijać i zdobywać przewagę rynkową, musi poszukiwać nowych rozwiązań i chronić firmowe zasoby. Pomagają w tym zespoły CERT.

Kevin Mitnick, znany wszystkim amerykański haker, a obecnie specjalista do spraw bezpieczeństwa, w swojej książce opisuje, w jaki sposób dostawał się do biur dużych organizacji. Po włamaniu się do wewnętrznej sieci korporacji był w stanie zrobić niemal wszystko ze znajdującymi się w niej ogólnie dostępnymi danymi. Tego typu działania podejmowane są non stop. Przedstawiamy narzędzie pozwalające wzmocnić obronę przed nimi.

W poprzednich częściach cyklu skupialiśmy się głównie na domenach TE dla procesów. W tej części zajmiemy się domenami dla użytkowników oraz samymi użytkownikami SELinux. Tak się składa, że flagowym pokazem możliwości SELinux jest tzw. Play Machines, której głównym trzonem jest odpowiednio ograniczona domena dla użytkownika.

Planowanie infrastruktury IT nie jest zadaniem łatwym. Wcześniej czy później przychodzi też moment, gdy konieczna jest instalacja nowego oprogramowania w środowisku wirtualnym bądź aktualizacja używanego systemu czy też sprzętu. Jak przekonać przełożonych o konieczności zmian? Najlepiej wykonać testy pojemności naszego systemu/usługi. Podpowiadamy, jak to zrobić.

W poprzedniej części cyklu opisaliśmy, jak tworzyć własne moduły polityki SELinux. Stworzyliśmy przykład bazowej domeny w natywnym języku polityki, następnie zamieniliśmy ją na moduł polityki referencyjnej. Omówiliśmy też makra m4, za pomocą których tworzona jest polityka referencyjna, poznaliśmy definicję interfejsu i przeanalizowaliśmy makra używane przez moduł mydomain. W tej części będziemy kontynuować tworzenie modułów polityki SELinux.

Koncepcja modułu bezpieczeństwa SELinux łączy kilka elementów. W części pierwszej i drugiej cyklu artykułów skupiliśmy się na mechanizmie TE (Type Enforcement), który w niemal 90% odpowiada za funkcjonalność SELinux. Kolejnymi składowymi są mechanizm RBAC (Role Based Access Control) oraz użytkownicy.

Skuteczność modułu bezpieczeństwa systemu Linux, jakim jest SELinux, bezpośrednio zależy od jego polityki. Jedną z najważniejszych koncepcji w tej polityce jest przejście pomiędzy domenami. Koncepcja ta pojawiła się jako wymóg spójności polityki do operacji wykonywanych w systemie operacyjnym.

Skuteczność modułu bezpieczeństwa systemu Linux, jakim jest SELinux, bezpośrednio zależy od jego polityki. Pomimo że deweloperzy systemu starają się jak najlepiej przystosować dostarczaną politykę do sprawnego działania, nie są w stanie przewidzieć wszystkich zmiennych. Prędzej czy później, w miarę konfiguracji kolejnych usług systemowych, administrator systemu staje przed koniecznością wprowadzania zmian w istniejącej polityce SELinux.

W infrastrukturze IT rozróżniamy wiele systemów informatycznych, z których każdy, w zależności od poziomu poufności przetwarzanych danych, musi być odpowiednio chroniony. W przypadku integracji z usługą ADFS 3.0 możliwe jest zastosowanie dodatkowych mechanizmów zwiększających bezpieczeństwo.