Tunel na magistrali

Innym przypadkiem jest wykorzystanie infrastruktury teleinformatycznej drugiej firmy do połączenia segmentów własnej sieci. Przypadek nietypowy, niemniej możliwy, np. wtedy gdy firma prowadzi działalność pomocniczą wobec innej, większej firmy działającej na dodatek w rozproszeniu. Wtedy, budowa własnej infrastruktury działającej równolegle nie wydaje się rozsądna. O ile tylko taka możliwość istnieje, skorzystanie z istniejącej infrastruktury jest jak najbardziej wskazane.

Aby zapewnić całkowitą przezroczystość, na każdym styku z siecią-magistralą można zainstalować router pełniący rolę bramki VPN. Uzyskuje się wtedy całkowitą separację logiczną przy połączeniu fizycznym. Bezpieczeństwo takiego rozwiązania zależy od skuteczności technologii kryptograficznych, a ponieważ obie firmy są zazwyczaj zainteresowane bezpieczeństwem własnych sieci, instalowane są dobre, sprawdzone rozwiązania wykorzystujące silną kryptografię.

Przy projektowaniu takich połączeń należy mieć na uwadze eliminację konfliktów adresów IP i bezwzględne szyfrowanie całości komunikacji. Wtedy ruch przenoszony wewnątrz tuneli jest całkowicie nieczytelny dla firmy udzielającej pasma sieciowego swojej magistrali. Podobnie dane transferowane magistralą nie mogą być odebrane przez firmę korzystającą z tunelu. Dla zapewnienia całkowitej separacji można nawet zastosować dwa oddzielne routery "jeden za drugim".

W obu przypadkach polityki bezpieczeństwa obu firm mogą pozostać niezmienione, a ograniczenia wynikają jedynie z samej technologii tunelowania. Alternatywą dla separacji kryptograficznej jest dzierżawa nieużywanego przez "dużą" firmę segmentu sieci czy odcinka kabla bądź wiązki światłowodu - takie rozwiązanie jest najbezpieczniejsze, a jednocześnie najprostsze i najtańsze dla obu stron. Niestety, wolne połączenie fizyczne jest raczej wyjątkiem niż regułą.

Rozmyta granica

Często spotyka się wspólne wykorzystywanie jednej sieci przez dwie firmy, przy czym każda z firm eksploatuje własne serwery. Z punktu widzenia bezpieczeństwa (choć także wygody i kosztów) jest to, niestety, najgorsze z możliwych rozwiązań. Po pierwsze, obie firmy muszą pilnować, by mieć całkowicie rozdzielną adresację IP, by uniknąć konfliktów. Po drugie, muszą być wyeliminowane wszelkie konflikty adresów MAC - unikalne numery kart sieciowych to obecnie fikcja, ponieważ łatwo można je podmienić.

Na tym oczywiście nie koniec. Obie firmy będą musiały korzystać z jednego wspólnego serwera DHCP i BOOTP - chyba że jedna z tych firm zdecyduje się na statyczne adresy spoza puli DHCP. Użytkownicy systemów Microsoft Windows zauważą zapewne kłopoty z kojarzeniem nazw komputerów oraz "bałagan" w Otoczeniu Sieciowym. Pół biedy, gdy jedna firma pracuje na Novell NetWare, zaś ta druga wykorzystuje Active Directory Microsoftu. Oba serwery przy dobrej konfiguracji nie będą sobie przeszkadzały, problemy będą wtedy dotyczyły głównie stacji roboczych Windows. Natomiast kłopoty wynikające z utrzymywaniem więcej niż jednej domeny na serwerach DNS i właściwej ich konfiguracji (oddzielne uwierzytelnianie Kerberos) przez różnych administratorów urastają do poważnych problemów.

Kolejne zagadnienie to wzmożony ruch broadcast i połączenia UDP - przy łączeniu większych sieci konieczne będzie filtrowanie. Gdy firmy eksploatują różne systemy operacyjne i rozwiązania do zarządzania siecią czy usługami, możliwości konfliktów są jeszcze większe. Typowym przykładem są kłopoty z oprogramowaniem antywirusowym albo zarządzaniem serwerami wydruku (problemy powodują rozwiązania wielu producentów). Wdrożenie systemu wykrywania włamań w takim środowisku jest skrajnie trudne, jeśli nie bezsensowne ze względu na nadmiar fałszywych alarmów.

Nie bez znaczenia są konflikty pozatechniczne. Jeśli administratorzy obu firm mają dostęp do wspólnej sieci, powstaje pytanie o zakres obowiązków. Łatwo o "spychologię", która na dłuższą metę nie posłuży nikomu. Przykładowo, jak skoordynować działania w sytuacji kryzysowej, np. podczas infekcji wirusowej? Kto za to będzie odpowiadać? Kto zajmie się aktualizacją oprogramowania i kto poniesie odpowiedzialność, jeśli serwer jednej z firm zostanie skompromitowany i umożliwi atak na serwery drugiej firmy? Trudno tu mówić o wspólnym, skutecznym działaniu.

Budowanie polityki

Z przedstawionych wyżej problemów wynika, że należy dążyć do maksymalnej separacji obu sieci na jak najniższym poziomie, umożliwiając "styk" tylko tam, gdzie to absolutnie niezbędne. Liczenie na to, że w razie problemów "firmy jakoś się dogadają" jest złudne - gdy powstają problemy, nikt nie chce ponosić odpowiedzialności osobiście. Jeśli rozdzielenie obu sieci na poziomie fizycznym nie jest możliwe, należy dążyć do ich separacji na poziomie warstwy drugiej, a więc poprzez włączenie własnej sieci LAN do sieci LAN innej firmy jako jej wydzielonego segmentu VLAN. Dodatkowym zabezpieczeniem będzie taka konfiguracja sieci, by firma korzystająca z infrastruktury gościnnie mogła komunikować się wyłącznie z Internetem.

Korzystanie z jednej sieci LAN przez wiele firm z zachowaniem rozdzielności ich zasobów i usług to w praktyce zły pomysł. Z tego będą tylko kłopoty. Lepszym rozwiązaniem jest usługowe zarządzanie siecią jednej firmy przez drugą - wtedy przynajmniej kompetencje i odpowiedzialność są jasno określone. Taka współpraca może być bardzo owocna, mniejsza firma ma możliwość skorzystania z doświadczenia i wiedzy firmy większej i ma prawo spodziewać się wyższego poziomu obsługi. Wadą takiego rozwiązania jest przyjęcie zobowiązań i ograniczeń polityki bezpieczeństwa wraz z dzierżawionym sprzętem oraz całkowity dostęp działu informatyki do danych firmy. W ramach grupy kapitałowej jest to wykonalne, przy dwóch różnych firmach - niekoniecznie, ale nie jest też niemożliwe.

Przy określaniu polityki bezpieczeństwa w środowisku współdzielonym należy jasno ustalić zasady współpracy. Zamieszczona obok tabela przedstawia typowe ograniczenia założeń wynikające np. z konstrukcji sieci, a także z doświadczeń autora.