fbpx

Podkast 22T23 SWG – Secure Web Gateway

Więcej miejsc do posłuchania:

Spotify

WERSJA TEKSTOWA

Cześć, witam Cię w dzisiejszym odcinku mojego podkastu. Dzisiejszy temat Security Web Gateway. Co to jest i po co się go stosuje? Chodzi przede wszystkim o zabezpieczenie komunikacji webowej. Czyli jeśli mamy jakiś nasz system webowy lokalnie albo w chmurze to potrzebujemy go zabezpieczyć. Najlepiej by było, gdyby można go było zabezpieczyć, dlatego, że będziemy mieć to środowisko rozproszone i chcemy chronić naszych użytkowników przed atakami związanymi z przeglądarkami www. Żeby to zrobić stosuje się dwa rodzaje podejść.

Pierwsze podejście dotyczy środowiska on-premise czyli takiego lokalnego i są to funkcjonalności, które są najczęściej uruchamiane na Firewallu. Mamy użytkownika wewnątrz i jego ruch przechodzi przez Firewalla, który następnie gdzieś ten ruch dalej przekazuje i na funkcjonalności tego Firewalla bazujemy uruchamiając Security Web Gateway. To jest pierwszy scenariusz.

Drugi scenariusz jest taki, że mamy użytkownika zdalnego, czyli gdzieś on pracuje sobie przez internet, częściowo lub całkowicie przez VPN-a i potrzebujemy ten ruch do zasobów www zabezpieczyć. Tutaj mamy możliwość zastosowania Gateway w postaci chmurowej, czyli mamy konfigurację na urządzeniu końcowym, które kieruje odpowiedni ruch lub cały ruch www w zależności od naszej polityki na tego Gatewaya webowego i na nim uruchamiamy co najmniej podstawową funkcjonalność filtrowania url. Zabezpieczamy się przed takimi atakami jak Phishingi, które się podszywają pod znane strony, jeśli oczywiście w naszej bazie reputacyjnej, z której korzystamy, czyli to rozwiązanie Web Gatewaya korzysta z takiej bazy reputacyjnej, która zawiera taki zestaw groźnych url-i. To jest jakby pierwszy, podstawowy tryb wykorzystania Security Web Gateway.

Drugi tryb, czy takie dodatkowe funkcjonalności to są możliwości rozszerzenia o analizowanie ściągania plików, analizowanie malware, czy ściągany dany kontent z danej strony nie jest malwarem. Czyli chronienie tego użytkownika naszego korporacyjnego w taki sposób, że najpierw sprawdzamy co on próbuje ściągnąć. Jeśli to jest ok, zgodne z naszą polityką – nie stanowi zagrożenia, wtedy wysyłamy taki plik na urządzenie końcowe. Jest to bez wątpienia zalecany obszar zabezpieczenia, ponieważ wiele ataków bazuje na atakach webowych i stosując tego typu rozwiązania mamy dodatkową warstwę ochrony dla tego typu ruchu.

Może jeszcze dwa słowa rozwinięcia warto powiedzieć na temat tego, w jaki sposób można kierować ten ruch web przez takiego Gatewaya. Ponieważ mówimy tutaj o wybranej grupie ruchu, czyli przede wszystkim o ruchu http i https to trzeba w jakiś sposób powiedzieć urządzeniu końcowemu, że ma udawać się nie do systemu, który jest bezpośrednio w linku, tylko do tego Gatewaya, który jakby w imieniu tego klienta będzie ten ruch przetwarzał i będzie go jednocześnie weryfikował. Mamy tutaj oczywiście opcje związane z VPN-em, jeśli to jest użytkownik zdalny, to używamy jego klienta końcowego i polityki kierowania ruchem, które można na tym kliencie zastosować, tak, żeby kierować ruch do naszego Gatewaya w zakresie tego ruchu http i https. Możemy oczywiście stosując te zaawansowane funkcjonalności używać tego typu kierowania ruchu od wewnątrz, czyli jeśli mamy użytkownika w firmie. Tutaj mamy łatwiejszą sytuację, ponieważ zakładamy najczęściej w takim środowisku, że cały ruch, który idzie od naszej sieci firmowej przechodzi przez naszego Firewalla lub Klaster Firewalli.

Jeżeli natomiast myślimy o czymś więcej, czy o tych bardziej zaawansowanych funkcjonalnościach niż url filtering, to jest tu jeszcze jedno zagadnienie, czyli deszyfracja ruchu TLS. Ponieważ podstawowy zakres, czyli url-e możemy odczytać zarówno w jednej jak i w drugiej formie, czyli w https jak i w http. Natomiast kontentu już zawartości tej strony już w przypadku https lub TLS nie możemy odczytać, chyba że odszyfrujemy tą komunikację. Tylko jak ją odszyfrować w sposób, który jest niezauważalny? Tutaj jest typowy problem, związany z technologią TLS, czyli jeśli mamy nasz zasób, do którego ktoś się łączy i mamy klucz prywatny i certyfikat, który możemy zastosować na urządzeniu deszyfrującym, czy offloaderze SSL czy takim właśnie Gatewayu bezpieczeństwa dla www. Jest to do zrealizowania w sposób niezauważalny dla użytkownika końcowego. Natomiast, jeśli chcielibyśmy inne zasoby, do których nie mamy dostępu, ale chcemy filtrować dla naszych użytkowników końcowych, to tutaj zacznie być problem, jeśli chcemy ten ruch deszyfrować, Dlatego, że możemy spowodować konfigurację takiego pośrednika, czyli nasz Gateway będzie w imieniu klienta odpytywał dany serwer końcowy po TLSie i to jest jak najbardziej możliwe. Natomiast nasza końcówka, czyli klient odpytując naszego Gatewaya i uważając, że to jest jego serwer docelowy, załóżmy, że jest to np wyszukiwarka Google, standardowo jest szyfrowana, to dostanie błąd certyfikatu. Chyba, że będziemy to otwierać na zasadzie terminala, jakiegoś okna, do którego będzie mógł wpisywać ten użytkownik. Jest to z kolei mniej użyteczne. Najczęściej to co ja widzę w praktyce – funkcjonalności Security Web Gatewaya są stosowane w zakresie Web Filteringu bo one są łatwe i przezroczyste dla użytkownika końcowego i nie wymagają żadnej dodatkowej reakcji z nim. Natomiast już deszyfrowanie wprowadza dodatkowe problemy powodujące wątpliwości u użytkownika końcowego a to z kolei powoduje, że zaczynają się pytania do IT, do administratorów a tego chcemy unikać, bo nie o to chodzi, żeby budować nowe rozwiązania czy funkcjonalności zabezpieczeń generujące więcej pracy. Chodzi o to, żeby mieć tej pracy mniej.

Jeżeli chodzi o funkcjonalność to przede wszystkim url filtering plus pewne opcje, jeśli nasz scenariusz wykorzystania i użycia na to pozwala, ale to zdecydowanie w którym kierunku rekomendacje dobrych praktyk bezpieczeństwa idą to dodawanie tego typu rozwiązań jak Security Web Gateway do naszych rozwiązań. Zwłaszcza w środowiskach mieszanych, hybrydowych, chmurowo -lokalnych tego typu rozwiązania są coraz bardziej popularne i są wdrażane. Na dziś to tyle, dziękuję Ci za uwagę i do usłyszenia już za tydzień.

Autor: Darek Koralewski

Od początku swojej kariery, czyli od 2004 roku, zajmuję się sieciami komputerowymi ze szczególnym uwzględnieniem ich bezpieczeństwa oraz sieciami programowalnymi. Mam na swoim koncie całą listę certyfikatów różnych producentów, dwa najważniejsze to te poświadczające najwyższy poziom wiedzy eksperckiej z zakresu rozwiązań Aruba ClearPass ACCX#901 oraz z projektowania sieci opartych o rozwiązania Aruba ACDX#1255. Więcej informacji możesz znaleźć na moich portalach społecznościowych.