Dostęp według Intelligent Application Gateway – cz. I

Autor: Barbara Wróbel

Opublikowano: 14 lutego 2008

Zawartość strony

	Wstęp
	Idea dostępu
	Przykładowa aplikacja
	Podsumowanie
	Przeczytaj pozostałe części tego artykułu

Wstęp

Serwer ISA już od kilku lat jest odpowiedzią Microsoft na rosnące potrzeby zapewnienia bezpieczeństwa sieci. Pozwala zarówno na określenie dostępu użytkowników na zewnątrz, jak i na kontrolowany dostęp do wybranych elementów w sieci wewnętrznej poprzez mechanizm publikacji. Zapewnia również bardzo specyficzny rodzaj dostępu, jakim jest połączenie VPN. Firewall ten, rozwijany począwszy od wersji 2000, obecnie doczekał się wersji 2006, a już trwają prace nad najnowszą wersją o kodowej nazwie Nitrogen.

Nie jest to jednak jedyny produkt tak ściśle dedykowany kwestiom związanym z bezpieczeństwem. Dzięki zakupowi technologii firmy Whale Communications powstał inny, równoległy produkt stanowiący uzupełnienie ISA na gruncie zapewniania bezpiecznych połączeń klientów z zewnątrz – Intelligent Application Gateway 2007 (IAG). Produkt ten jest ściśle powiązany z ISA, czego dowodem są powstające w „magiczny” sposób, po użyciu kreatorów IAG reguły po stronie ISA. W uproszczeniu można powiedzieć, że IAG to sposób na upakowanie reguł ISA w tunelu SSL. W wielu materiałach IAG jest określany, przede wszystkim, jako sposób na uzyskanie tunelu SSL VPN. Metoda na przezwyciężenie niedoskonałości standardowych połączeń VPN, takich, jak chociażby konieczność otwarcia w zaporach napotkanych na drodze pewnego zestawu portów i protokołów. Dodatkowo IAG eliminuje potrzebę konfigurowania przez zwykłego użytkownika samego połączenia VPN.

Ale IAG to coś więcej niż tylko tunel. To spojrzenie na bezpieczny dostęp pod różnymi kątami, czego wynikiem jest ochrona całego procesu na kilku etapach. Wspomniane tu etapy prześledzimy poniżej. I tu jeszcze dodatkowa uwaga do następnej sekcji artykułu dotyczącej idei dostępu, która jest troszkę zagmatwana. Aby łatwiej było przez nią przebrnąć na dole sekcji "Idea dostępu" zamieszczam obrazujący ją diagram (rys. 9.).

Do początku strony

Idea dostępu

Podstawowym pojęciem, jakim operujemy w przypadku IAG jest tzw. trunk. Kryje się pod nim połączenie typu http lub https. Połączenie takie może być tworzone na podstawie jednego z czterech szablonów:

• Basic trunk – pozwala na dostęp do pojedynczej aplikacji internetowej;
• Portal trunk – umożliwia stworzenie portalu skupiającego wiele aplikacji;
• Webmail trunk – wykorzystywany przy publikacji aplikacji pocztowych za pośrednictwem WWW, takich, jak np. OWA;
• Redirect http to https trunk – automatycznie przekierowuje połączenia http do https. Nawet gdy użytkownik w adresie portalu wpisze http, połączenie zostanie automatycznie zamienione na połączenie https.

Tworzymy je, wybierając połączenie http/https i następnie „New trunk”.

Rys. 1. Idea dostępu.

Kreator przeprowadzi nas poprzez wybór takich ustawień, jak adres IP nowego połączenia, użyty certyfikat, metoda uwierzytelniania czy też tzw. endpoint policies, o których więcej w dalszej części artykułu.

Spośród przedstawionych rodzajów połączeń najbardziej elastycznym i najszerszym jest portal trunk. Pozwala on w jednym miejscu skupić wszystkie aplikacje, jakie użytkownik będzie wykorzystywał.

Spektrum mogących tu wystąpić aplikacji jest dość szerokie i obejmuje następujące rodzaje:

• Built-in Services – usługi wbudowane w IAG np. file access;
• Web applications – aplikacje oparte na http/https i interfejsie WWW, np. OWA;
• Client/server and legacy applications – aplikacje nie wykorzystujące połączeń http/https, np.: telnet, ftp, Microsoft Outlook. Aplikacje te są obsługiwane przez tzw. SSL Wrapper;
• Browser-Embedded Applications – aplikacje w początkowym stadium połączenia wykorzystujące interfejs WWW, np. Terminal Services Web Client, Citrix NFuse. Aplikacje te są obsługiwane przez tzw. SSL Wrapper.

Rys. 2. Zawartość aplikacji.

Aplikacje, jak widać, są dość zróżnicowane, ale mechanizm dostępu do nich na serwerze IAG generalnie jest wspólny. Żądanie dostępu do danej aplikacji za pośrednictwem tunelu SSL dociera do serwera IAG. Tam następuje przekierowanie do konkretnego serwera znajdującego się w sieci wewnętrznej. Brzmi nieco znajomo? Powinno. Jest tu wykorzystywana podstawowa zasada publikacji znana z serwera ISA. Nie zapominajmy albowiem, że IAG i ISA tworzą dość nierozerwalny duet, bez którego IAG praktycznie nie mógłby funkcjonować. Każdy portal, aplikacja stworzona w IAG znajduje swoje odbicie w odpowiadających jej regułach w ISA. Możemy się o tym łatwo przekonać, zaglądając do konsoli ISA.

Rys. 3. Konsola ISA.

Reguły widoczne na rysunku 3. stworzone zostały właśnie za pośrednictwem IAG.

Przede wszystkim jednak IAG wprowadza szereg rozszerzeń możliwości serwera ISA. Jednym z nich jest zaawansowana kontrola na poziomie aplikacji. IAG zawiera zbiór wbudowanych filtrów dedykowanych poszczególnym aplikacjom. Ich zadaniem jest zapewnienie bezpieczeństwa z uwzględnieniem specyficznych potrzeb danej aplikacji. Wykorzystywane są tu dwa rodzaje inspekcji: negatywna i pozytywna. Negatywna pozwala wyeliminować zagrożenia związane ze znanymi już exploitami. Pozytywna chroni również przed tymi, które są nowe. Przy publikacji automatycznie stosowane są obie inspekcje. Jeżeli dane połączenie nie jest wyeliminowane poprzez inspekcję negatywną i jednocześnie będzie zgodne z odpowiednimi filtrami inspekcji pozytywnej, połączenie będzie dozwolone.

Inspekcja aplikacji to pierwszy z zastosowanych mechanizmów bezpieczeństwa. Drugi tworzy grupę działań, które koncentrują się na samym kliencie. I głównie na tym właśnie obszarze działań skupimy się w tym artykule.

Klient po uruchomieniu portalu przechodzi szereg testów, na podstawie których zostaje zakwalifikowany do jednej z dwóch grup:

• Klientów domyślnych;
• Klientów uprzywilejowanych.

Czym te grupy się charakteryzują najlepiej widzimy po wejściu na danym portalu w sekcji „Security & Networking” do „Advanced trunk configuration”, a następnie przejściu do zakładki „Session”:

Rys. 4. Wejście do sekcji „Security & Networking” do „Advanced trunk configuration”.

Jak widać pierwsza (określona w sekcji u góry po prawej - „Default Session Settings”) jest o wiele bardziej restrykcyjna, przez co zalecana jest głównie w miejscach o obniżonym stopniu bezpieczeństwa, np. stanowiska typu kiosk. Wymusza ona między innymi określone ograniczenia czasowe dla sesji (domyślne automatyczne wylogowanie po 60 minutach) czy też zapewnia, że po zamknięciu sesji nastąpi usunięcie wszystkich śladów obecności tejże sesji, np. cookie czy historię. Odpowiedzialny jest za to tzw. Attachment Wiper.

Uwaga! Ustawienie czasu nieaktywności na 0 jest równoważne nieograniczonemu czasowi trwania sesji.

Ustawienia grupy drugiej, umieszczone w sekcji „Privileged Session Settings” niosą ze sobą o wiele mniejsze ograniczenia.

To do jakiej grupy (uprzywilejowanej czy też nie) klient zostanie zakwalifikowany, odbywa się na podstawie spełnienia lub nie tzw. „Endpoint policies”, które można zobaczyć po lewej stronie u dołu na powyższym rysunku. Przypisanie do pierwszej grupy następuje po spełnieniu podstawowych reguł dostępu określonych w polu „Session Access Policy”. Przypisanie do grupy uprzywilejowanej następuje zarówno po spełnieniu polisy w polu „Session Access Policy”, jak i w polu „Privileged Endpoint Policy”.

Obie polisy można wybrać z listy polis predefiniowanych lub stworzyć nową polisę. Zrobimy to po kliknięciu przycisku „Edit policies”, a następnie po wybraniu „Add…”. Poniżej na przykład widzimy polisę, która zweryfikuje czy system operacyjny klienta to Vista. Jeśli potem wybierzemy tę polisę w polu „Privileged Endpoint Policy”, tylko klienci z systemem Vista zyskają status uprzywilejowanych. Dodatkowo tak utworzoną polisę, możemy zaopatrzyć w komentarz wyjaśniający użytkownikowi powody jego braku dostępu. Należy go wpisać w widocznej poniżej gałęzi „General”.

Rys. 5. Polisa weryfikująca system operacyjny klienta.

„Endpoint Policies” mogą być tworzone w trybie edytora graficznego, jak również w trybie zaawansowanego edytora skryptów, który pozwala na tworzenie bardziej skomplikowanych polis.

Uwaga! Po przełączeniu się jednak do trybu skryptu (przycisk „Edit as scrpit”) nie jest możliwy powrót do trybu graficznego dla danej polisy.

Obojętnie, który z trybów konfiguracji wybierzemy, możliwości ich zastosowań są dość zróżnicowane. Poprzez polisy możemy np. określić restrykcje związane z zaporą, oprogramowaniem antywirusowym, systemem operacyjnym czy też rodzajem przeglądarki.

Na szczególną uwagę zasługuje tu zwłaszcza jedna polisa związana z certyfikatami. Po wyposażeniu klientów w certyfikaty możemy zyskać pewność, że tylko klienci posiadający je, będą mogli korzystać z poziomu uprzywilejowania na portalu. W tym celu należy na znanej już zakładce „Session” posłużyć się opcją „Use Endpoint Certification”. Dodatkowo w sekcji „Endpoint Policies” wybieramy w polu „Privileged Endpoint Policy” polisę „Is Certified Endpoint”.

Rys. 6. Polisa związana z certyfikatami.

Uwaga! Polisy „Is Certified Endpoint” nie można wybrać w polu „Session Access Policy”. Dzieje się tak dlatego, że polisa ta dotyczy użytkownika, a co za tym idzie sprawdzana jest dopiero po zalogowaniu danego użytkownika. A jeśli spojrzymy na diagram poniżej tej sekcji artykułu widzimy, że polisy dotyczące „Session Access Policy” są wykonywane przed zalogowaniem użytkownika.

Pomyślne przejście powyższych testów to pierwszy etap na drodze do uruchomienia aplikacji. Drugi poziom to kontrola dostępu do konkretnej już aplikacji. We właściwościach każdej aplikacji możemy również określić uprawnienia użytkownika względem aplikacji. Można to zrobić po wejściu na zakładkę Authorization. A uprawnienia są następujące:

• Allow – użytkownik może uruchomić aplikację;
• View – użytkownik widzi aplikację, lecz nie może jej uruchomić;
• Deny – użytkownik ma całkowicie odebrany dostęp do aplikacji – w przypadku domyślnej strony portalu IAG, nawet jej nie widzi.

Uwaga! Mechanizmy uwierzytelniania, którymi się tu posłużymy muszą być wcześniej skonfigurowane. Można to zrobić, wybierając w menu „Admin” pozycję „Authentication and User/Group Servers…”.

Rys. 7. Proces uruchomienia aplikacji.

Na poziomie aplikacji można również zastosować dodatkowo endpoint policies. Jest to do przeprowadzenia we właściwościach aplikacji na zakładce „General”. Jeśli klient nie będzie zgodny z polisą, wskazaną w polu „Access”, wtedy w zależności od wyboru opcji „Grayed” lub „Invisible”, aplikacja będzie nieaktywna do wyboru lub zupełnie niewidoczna na portalu.

Rys. 8. Możliwość kontroli dostępu do konta przez administratora.

Widzimy na rysunku nr 8., że administrator może kontrolować dostęp klienta jeszcze na jednym poziomie. A mianowicie dla aplikacji typu portal trunk Built-In Services, Web Applications, and Browser-Embedded Applications oraz Webmail and Basic trunks może pozbawić go prawa do downloadu, uploadu plików, czy też może ograniczyć dostęp do szczególnie newralgicznych części aplikacji, jak np. obszary administracyjne („Restricted Zone”). Jak widać, wszystkie te czynności można również kontrolować poprzez odpowiednie endpoint policies.

Chyba spojrzeliśmy już na wszystkie strategiczne, dla uzyskania dostępu przez klienta, kroki inwigilacji. Ścieżka, którą użytkownik musi przejść, by móc skorzystać z aplikacji, jest dość długa. Ale tym samym, dzięki temu administrator ma znaczną kontrolę nad tym jaki dostęp jest użytkownikowi przyznany i na jakich zasadach. Ale nie oszukujmy się, o to przecież zwykle administratorowi chodzi.

Teraz pora na obiecany na początku diagram, który w graficznej formie pozwoli nam prześledzić poszczególne ścieżki tego małego labiryntu.

Rys. 9. Diagram obrazujący ideę dostępu.

Do początku strony

Przykładowa aplikacja

Zobaczmy teraz na krótkim przykładzie konfiguracji OWA w Exchange 2007, jak to wszystko działa w praktyce. W tym celu w konfiguracji portalu, w gałęzi połączeń https, wybieramy przycisk „Add”, aby uruchomić kreatora tworzenia nowej aplikacji.

Rys. 10. Tworzenie nowej aplikacji.

Jako typ aplikacji wybieramy Microsoft Outlook Web Access 2007. Od tej pory IAG w czasie konfiguracji posłuży się predefiniowanym dla OWA szablonem aplikacji.

Rys. 11. Wybieranie typu aplikacji.

Następne kroki kreatora obejmą:

• Określenie nazwy aplikacji;
• Ewentualne określenie endpoint policies, jeśli mają być inne od domyślnych;
• Wpisanie adresu serwera, na którym aplikacja jest zainstalowana;
• Wskazanie sposobu uwierzytelniania – czy będzie to uwierzytelnianie oparte na przykład o AD, RADIUS a może jeszcze inne;
• Określenie parametrów linków na portalu.

Uwaga! Aby jakiekolwiek zmiany mogły wejść w życie, muszą zostać zatwierdzone poprzez wybór z menu „File”->”Activate…”.

Ustawienia utworzonej w ten sposób aplikacji mogą być potem dodatkowo dokonfigurowane w jej właściwościach. Możemy tam na przykład określić uprawnienia konkretnych użytkowników i grup do aplikacji, czego nie byliśmy w stanie zrobić w powyższym kreatorze. Możemy też włączyć szyfrowanie plików cookie czy też określić na zakładce „General” tzw. prerequisite applications. Pod tym terminem kryją się aplikacje, które będą uruchamiane równolegle z daną aplikacją. Mogą to jednak być tylko aplikacje typu „Client/Server and Legacy Applications”. Praktycznym przykładem wykorzystania tej opcji jest, na przykład, aplikacja mapująca potrzebne zasoby „Local Driver Mapping”, by z tych zasobów mogła potem korzystać nasza aplikacja główna.

Do początku strony

Podsumowanie

Podsumowując, zauważmy jeszcze, że po stronie klienta zalogowanie do aplikacji odbywa się z wykorzystaniem mechanizmu Single sign-on, dzięki któremu klient nie musi po raz drugi wpisywać swoich danych uwierzytelniających. Wykorzystywane są te, które podał, logując się do portalu IAG.

Do początku strony

Przeczytaj pozostałe części tego artykułu

• Dostęp według Intelligent Application Gateway – cz. II

Do początku strony