Powszechna "webizacja"

Wielu programistów w firmach zadaje sobie pytanie: jak zapewnić bezpieczeństwo nowych aplikacji bazodanowych? Uważają oni, że interfejs webowy nie jest właściwy dla wszystkich aplikacji i oprogramowanie tworzone bez takich interfejsów jest dużo wydajniejsze i bezpieczniejsze. Można się zgodzić z tym, że Web nie jest najlepszym wyborem dla aplikacji w sytuacji, gdy można projektować programy działające w izolowanej infrastrukturze. Jednak cały świat zmierza w kierunku Web 2.0 i aplikacje, które obecnie jeszcze nie korzystają z tej technologii, jutro - z dużym prawdopodobieństwem - będą musiały.

Użytkownik oczekuje możliwości dostępu do aplikacji za pośrednictwem przeglądarki lub usługi webowej bez względu na to, jakiego komputera używa - PC, smartfonu, tableta itp. Oddzielne interfejsy i VPNy nie mogą tu stanowić przeszkody - jeżeli aplikacja nie jest łatwo osiągalna na webie, to nie będzie używana lub zostanie zepchnięta na margines.

Zobacz również:

• Wyjaśniamy czym jest SD-WAN i jakie są zalety tego rozwiązania
• Palo Alto wzywa pilnie użytkowników jej zapór sieciowych, aby jak najszybciej zaktualizowali zarządzające nimi oprogramowanie

To nie oznacza, że aplikacje powinny być w sposób prosty udostępniane na webie, zwłaszcza, jeżeli sama aplikacja nie jest webowa. Może to działać jedynie na krótką metę. Aktualne technologie - tradycyjnej wirtualizacji czy bram aplikacyjnych - są rozwiązaniami tymczasowymi. W przyszłości, aby przetrwać na rynku, aplikacja musi być zaprojektowana w technice webowej od podstaw. Można się zgodzić z tym, że aplikacja jest szybsza i działa lepiej, kiedy dostęp do niej nie wymaga interfejsu webowego, ale w dłuższej perspektywie argument ten traci na znaczeniu.

Urządzenia konsumenckie w przedsiębiorstwie

Administratorzy odpowiedzialni za bezpieczeństwo w przyszłości będą mieli pod swoją kontrolą coraz więcej urządzeń osobistych, a coraz mniej komputerów. Tempo wprowadzania smartfonów i iPad’ów do organizacji jest znacznie szybsze niż wdrażania nowych rozwiązań do ochrony. W wieli przypadkach administratorzy nawet nie będą mieli okazji do kontrolowania tych urządzeń.

I nie sprowadza się to tylko do braku możliwości kontrolowania minimalnych wymagań na złożoność hasła - mogą oni nawet nie wiedzieć, czy użytkownicy w ogóle używają haseł. Co więcej, nie będą mogli kontrolować stanu łatek czy obecności Trojanów, a także instalowania zapór ogniowych lub oprogramowania ochronnego w tych urządzeniach. Można zakładać, że niezarządzane urządzenia nie mogą mieć dostępu do najbardziej krytycznych czy istotnych informacji, ale życie podpowiada coś innego. Uświadamianie użytkowników, aby przestrzegali reguł polityki bezpieczeństwa w posługiwaniu się urządzeniami osobistymi to słaby substytut sprawowania na nimi kontroli.

Ochrona z tokenem

Web i wszystkie odmiany cloud (prywatne, publiczne, hybrydowe, itd.) wymagać będą wprowadzenia mechanizmu jednokrotnego logowania (SSO) do różnych technik komputerowych, chociaż nigdy nie będzie on funkcjonował tak niezawodnie, jak w ramach sieci prywatnej. Użytkownicy będą wymagać pełnego zakresu dostępu poprzez jednokrotne logowania z tokenem + hasło/login.

Będzie to niezbędne również w systemach, których się nie kontroluje. Można to zrealizować korzystając z standardów federacyjnych opartych na webie bram w chmurach i metasystemów tożsamości, opartych na "domniemanym zaufaniu" (claims-based identity metasystem). Zamiast problemów z protokołami uwierzytelniania i dostatecznie silnymi hasłami, szersze zastosowanie powinna znaleźć ochrona oparta na tokenach SAML (Security Assertion Markup Language).

Hakerzy w roll squatterów

W przeszłości profesjonalni włamywacze dostawali się do pomieszczeń firmy, gdzie przechowywano pieniądze, kradli je i szybko opuszczali miejsce przestępstwa. Obecnie zadamawiają się tam na długo, wykorzystując zaawansowane techniki persistent threats. Celem takich ataków jest kradzież własności intelektualnej i sekretów firmy. Przestępca chce uzyskać za darmo coś, co stanowi o wartości firmy i użyć tego do własnych celów lub sprzedać konkurencji.

Na dobre może zagnieździć się w organizacji i poznać wszystkie główne hasła. Jeżeli zostanie przyłapany na gorącym uczynku, niekoniecznie zaprzestanie swoich działań. A to dlatego, że nie musi - działając z kraju, w którym takie praktyki nie są z sprzeczne z prawem. Usunięcie go z systemu organizacji bez istotnego obniżenia poziomu wydajności systemu informatycznego może okazać się trudne.

Zmierzch strefy zdemilitaryzowanej

DMZ (De-Militarized Zone) zawsze była "porowata", co teraz przyznaje się już oficjalnie. Przestępcy przełamują ją przejmując legalne desktopy użytkowników i z nich zaczynają eksplorować system. Przesyłają wszystko co im potrzeba przez port 443, używając szyfrowania AES, tak więc nie można ich działań podejrzeć wprost.

Zamiast tworzyć jedną czy dwie nieszczelne granice, bardziej celowe staje się tworzenie precyzyjnych, izolowanych domen bezpieczeństwa. Jeżeli stacje robocze nie muszą komunikować się z innymi, to nie należy im tego umożliwiać. Większość serwerów też nie musi komunikować się i też nie należy do tego dopuszczać. Większość administratorów niekoniecznie musi mieć połączenia z każdym serwerem, itp.

W trakcie budowania systemu ochrony należy określić wszystkie niezbędne połączenia i zablokować pozostałe, używając list kontrolnych dostępu, routerów, zapór ogniowych, proxy, IPsec i każdego innego mechanizmu, który może być użyty w tym celu.

Co dla osób zajmujących się bezpieczeństwem oznacza pojawianie się wyżej wymienionych trendów? Przede wszystkim konieczność stałego śledzenie rozwoju ataków webowych i ryzyka, jakie ze sobą wnoszą. Muszą również bliżej zapoznać się z takimi zagadnieniami, jak: WS-Federation, WS-Trust, SOAP, SAML i uwierzytelnianiem opartym na domniemanym zaufaniu.