Sekcje

Przejdź na skróty do treści. | Przejdź do nawigacji


Baza wiedzy Publikacje Zasady umieszczania systemów w DMZ - przykładowa dokumentacja

Zasady umieszczania systemów w DMZ - przykładowa dokumentacja

Poniżej udostępniamy przykładową dokumentację określającą sposób umieszczania systemów w strefie DMZ (dokumentacja ta może być bezpłatnie wykorzystana w firmie / instytucji, jednak dokumentu nie można odsprzedawać / dystrybuować dalej).

Aby otrzymać bezpłatnie dokumentację zasady umieszczania systemów w DMZ
- w formie edytowalnej (.doc)
prosimy o przesłania takiej prośby na adres:

dokumentacja@securitum.pl z podaniem nazwy firmy/organizacji.

0. Wstęp

Strefa sieciowa DMZ, to strefa o obniżonym poziomie zaufania ze względu na bezpieczeństwo. W sieci tej systemy udostępniane są poprzez publiczne adresy IP. Z tego powodu, usługi działające w DMZ znacznie bardziej narażone na ataki niż systemy znajdujące się wewnątrz sieci (tj. w LAN).

Istotą strefy DMZ od strony bezpieczeństwa jest jej separacja od wewnętrznych systemów (to znaczy uniemożliwienie nawiązywania połączeń ze strefy DMZ do systemów wewnętrznych). W razie ewentualnego naruszenia bezpieczeństwa na serwerze znajdującym się w DMZ, ogranicza się propagację ataku do sieci LAN.

1.     Ogólne zasady dotyczące DMZ

  • komunikacja nawiązywana ze strefy DMZ do wewnątrz LAN powinna być zabroniona (w szczególnych przypadkach dozwolone są wyjątki – patrz dalsza część dokumentu),
  • można wyróżnić kilka stref DMZ z różnymi zasadami komunikacji sieciowej (patrz dalsza część dokumentu),
  • w pewnych przypadkach logika biznesowa systemu IT wymaga przepływu danych z DMZ do LAN – w dalszej części dokumentu wskazano sposoby możliwości realizacji tego zadania,
  • strefa DMZ może być być odseparowana od LAN:
  •  w sposób fizyczny (wydzielenie infrastruktury sieciowej na potrzeby DMZ:  switche, serwery, routery, itp.)
  •  w sposób logiczny (odpowiednie reguły w systemie lub systemach typu firewall)

2.     Modele komunikacji DMZ do LAN

W pewnych przypadkach może zajść konieczność komunikacji – transferu danych - z DMZ o LAN. W takich przypadkach można rozważać kilka scenariuszów realizacji tego typu komunikacji (każdy z opisanych poniżej scenariuszy posiada opisane zarówno swoje wady jak i zalety):

Okresowe połączenia z LAN – realizowane przez uruchamiany cyklicznie program znajdujący się w LAN.

Połączenie w tym przypadku następuje z sieci LAN do DMZ. Komunikacja z DMZ do LAN pozostaje zamknięta.

  • Zalety rozwiązania: wysokie bezpieczeństwo
  • Wady rozwiązania: brak komunikacji on-line

Połączenie do LAN z wykorzystaniem mechanizmu web services.

Jest to rozwiązanie pośrednie pomiędzy bezpośrednim otwarciem portu a zamknięciem komunikacji z DMZ do LAN. W LAN nasłuchuje na wybranym porcie mechanizm web service (np. SOAP), który dodatkowo zapewnia filtrowanie danych przychodzących z DMZ pod względem bezpieczeństwa. Mechanizm taki zazwyczaj musi być przygotowany w sposób dedykowany oraz wykonuje on translację komunikatów web services na komunikaty akceptowane przez docelowy system. Warto zwrócić uwagę, że mechanizm web services to po prostu przesyłanie odpowiednio zdefiniowanych komunikatów XML protokołem http(s).

  • Zalety rozwiązania: możliwość komunikacji on-line DMZ -> LAN, możliwość filtrowania komunikacji po stronie web services, niska podatność na bezpośrednie ataki na usługę (dobrze przygotowany web service stanowi pewnego rodzaju bramkę filtrującą).
  • Wady rozwiązania: wymagane otworzenie portu (protokół http(s) z DMZ do LAN).

Połączenie z wykorzystaniem mechanizmu MQ (message queue).

Rozwiązanie stosowane w systemach klasy enterprise zapewniające komunikację on-line przy jednoczesnym braku konieczności zezwolenia na nawiązywanie połączeń z DMZ do LAN. Przykłady implementacji to MSMQ, ActiveMQ, WebSphere MQ.

  • Zalety rozwiązania: wysokie bezpieczeństwo, komunikacja on-line
  • Wady rozwiązania: największy nakład czasowy na zaimplementowanie tego typu komunikacji (dość nietypowa komunikacja asynchroniczna).

Bezpośrednie połączenie z DMZ na wybrany port (porty) w LAN.  

Metody tej – o ile jest to możliwe – powinno się unikać. Jeśli jednak zostanie ona wykorzystana, należy:

  • konfigurować tylko w ten sposób systemy, które nie są dostępne publicznie dla wszystkich użytkowników Internetu (dostęp tylko do bardzo ograniczonej i kontrolowanej grupy osób – np. tylko dla pracowników),
  • otwierać minimalną liczbę portów z DMZ do LAN,
  • w miarę możliwości konfigurować dostęp do LAN tylko w trybie read-only,
  • w miarę możliwości nie zapewniać dostępu do krytycznych danych,
  • monitorować dostęp do portu w LAN (kiedy następowało połączenie, ewentualnie jakie operacje były wykonywane w ramach połączenia),
  • zweryfikować wewnętrznie lub zewnętrznie poziom bezpieczeństwa oferowany przez system dostępny w DMZ – również z komponentem znajdującym się w LAN (np. poprzez realizację testów penetracyjnych),
  • instalować aktualizacje bezpieczeństwa oprogramowania zarówno w części DMZ oraz LAN,
  • uwaga: nie można udostępniać portu z LAN bezpośrednio do Internetu (np. poprzez wykorzystanie mechanizmu port forwarding).

 

  • Zalety rozwiązania: największa szybkość wdrożenia
  • Wady rozwiązania: najmniejsze bezpieczeństwo.

3.     Kilkustopniowy DMZ

W systemach wielowarstwowych oraz wymagających komunikacji z LAN (np. web), w celu zwiększenia bezpieczeństwa, można zastosować dwie lub więcej stref DMZ.

  • W pierwszej strefie znajduje się komponent do którego następują bezpośrednie połączenia z Internetu (często jest on najbardziej narażony na ataki – np. jest to aplikacja webowa).  Strefa ta nie ma możliwości połączeń z LAN, ma za to możliwość połączenia do strefy kolejnej (gdzie znajduje się przykładowo baza danych obsługująca system).
  • Do strefy drugiej nie ma bezpośredniego dostępu z Internetu. Strefa ta komunikuje się z kolei z LAN za pomocą odpowiedniego mechanizmu (patrz punkt 2 powyżej).
  • Mechanizm można rozszerzać wg schematu poniżej (np. pierwsza strefa: serwer http, druga strefa: serwer aplikacyjny, trzecia strefa: serwer bazodanowy).

4.     Liczba firewalli

W systemach o podwyższonych wymaganiach dotyczących bezpieczeństwa, przy budowach stref DMZ z dostępem do LAN zalecane jest wykorzystanie dwóch firewalli, różnych producentów. Pierwszy z firewalli chroni dostęp do DMZ (połączenia z Internetu do DMZ), drugi z kolei chroni połączenia z DMZ do LAN).

  • Zalety rozwiązania: wyższe bezpieczeństwo od podstawowej architektury z jednym firewallem – mniejsza szansa na wystąpienie jednakowych podatności w samym firewallu, mniejsza szansa na takie same błędy konfiguracyjne na obu urządzeniach
  • Wady rozwiązania: wyższe koszty – również administracyjne

5.     Umieszczanie systemów w DMZ

A.     Dokumentacja

Każde umieszczenie systemu w strefie DMZ należy dokumentować, zawierając następujące informacje:

  • nazwa systemu oraz jego właściciel,
  • wybór strefy DMZ (patrz punkt: Grupowanie systemów poniżej),
  • przydzielone adresy IP
  • sposób dostępu do DMZ z sieci Internet (publiczny, tylko po logowaniu, tylko przy dostępie przez VPN, itp.),
  • sposób komunikacji z LAN (jedna z wcześniej wskazanych metod), wraz ze szczegółami dozwolonej komunikacji (np. otwarte porty),
  • sposób komunikacji z innymi strefami DMZ,
  • planowany czas życia systemu.

Dokumentację tą należy analizować raz na kwartał oraz wprowadzać odpowiednie zmiany w DMZ (np. usuwać niewykorzystywane systemy / reguły w systemach firewall, decydować o systemach tymczasowych, itp.).

B.     Grupowanie systemów

Potencjalnie jest możliwość umieszczania wszystkich systemów wymagających dostępu z Internetu w jednej strefie DMZ, jednak w praktyce nie zaleca się takiej konfiguracji. Zaleca się w tym przypadku wydzielenie osobnych stref DMZ zgodnych z wykorzystaniem biznesowym systemów. Np. w jednej strefie DMZ znajdują się aplikacje webowe (lub każda aplikacja webowa posiada swoją strefę), w jeszcze innej serwery poczty, DNS, itp. Tego typu działanie dodatkowo ogranicza oddziaływanie ataku na jedną strefę – na strefy pozostałe. Przed uruchomieniem nowego systemu należy rozważyć w której z obecnych stref DMZ należy go umieścić (lub wydzielić nową strefę).

C.     Hardening

Systemy dostępne w DMZ należy dodatkowo dobezpieczyć w stosunku do domyślnej konfiguracji. Przynajmniej zrealizowane powinny być następujące czynności:

  • ograniczenie dostępnych publicznie portów TCP/UDP do minimum,
  • zapewnienie odpowiedniej jakości haseł dostępowych,
  • zapewnienie dostępu administracyjnego tylko protokołami szyfrowanymi,
  • weryfikację aktywnych kont systemowych / aplikacyjnych,
  • wprowadzenie odpowiednich procedur wgrywania aktualizacji oprogramowania systemowego (np. systemu operacyjnego) jak i usługowego (np. silnika bazodanowego),
  • w miarę możliwości ograniczenie zdalnego dostępu administracyjnego tylko do określonej puli adresów IP lub poprzez VPN,
  • w przypadku konfiguracji nietypowego / niestandardowego komponentu (np. aplikacji) – realizacja wewnętrznego lub zewnętrznego testu penetracyjnego,
  • jeśli w systemie przetwarzane są dane osobowe – zapewnienie zgodności z Ustawą o Ochronie Danych Osobowych.

D.     Przechowywanie krytycznych danych w strefie DMZ.

Dane krytyczne, to dane stanowiące bardzo wysoką wartość dla Firmy (np. dane klientów, kontraktów, itp).

Krytycznych danych nie powinno przechowywać się w strefie DMZ.  Dane tego typu powinny być transferowane do LAN lub do innej specjalnie wydzielonej strefy - w odpowiedni sposób (patrz odpowiednia część niniejszego dokumentu).

W przypadku gdy tego typu dane znajdują się w strefie DMZ należy ograniczyć do niego publiczny dostęp z Internetu (np. dostęp tylko przez VPN, ograniczony do zaufanych osób). 

-- Michał Sajdak, Securitum

Nawigacja
 
Darmowy magazyn o ITsec

zine
Subskrybuj RSS:
RSS