Dobre praktyki Terraform i OpenTofu – projektowanie sieci w chmurze

Terraform jest jednym z najpopularniejszych rozwiązań do zarządzania infrastrukturą jako kod (Infrastructure as Code, IaC). Dzięki swojej elastyczności i możliwości obsługi różnych środowisk chmurowych oraz on-premise pozwala na automatyczne tworzenie, modyfikowanie i zarządzanie infrastrukturą. W połączeniu z odpowiednimi zasadami projektowania Terraform staje się kluczowym elementem skutecznego tworzenia i zarządzania siecią w chmurze. W tym artykule omówimy dobre praktyki Terraform oraz skupimy się na aspektach projektowania sieci w chmurze, co pomoże nam stworzyć niezawodne i bezpieczne środowisko.

Omówimy aż 9 zasad, które w praktyczny sposób pokażą, jak podejść do segmentacji sieci, ochrony usług wystawionych do internetu, a także jak zabezpieczyć ruch sieciowy i zapewnić bezpieczne połączenia między lokalnymi i chmurowymi zasobami. Dzięki zastosowaniu tych wskazówek projektowanie infrastruktury stanie się bardziej przemyślane i przyszłościowe, co pozwoli na lepsze zarządzanie zasobami i ich rozwój.

Dobre praktyki Terraform, czyli jak projektować efektywnie i bezpiecznie

Projektowanie infrastruktury chmurowej z użyciem narzędzi takich jak Terraform i OpenTofu to proces, który wymaga szczególnej uwagi, aby zapewnić nie tylko stabilność, ale również wysoki poziom bezpieczeństwa, skalowalność i efektywne zarządzanie zasobami. Dobrze zaplanowana i zaimplementowana infrastruktura jest kluczem do minimalizowania ryzyka oraz maksymalizowania wydajności operacyjnej w dynamicznym środowisku chmurowym. Poniżej wyróżniliśmy aż 9 zasad, które warto stosować przy projektowaniu sieci chmurowej.

1. Przepuszczaj tylko niezbędny ruch sieciowy pomiędzy usługami

Jedną z kluczowych zasad bezpieczeństwa jest ograniczanie ruchu sieciowego do absolutnego minimum. W praktyce oznacza to, iż powinieneś zezwalać na ruch sieciowy między usługami tylko wtedy, gdy jest to niezbędne do ich działania. Ta zasada minimalizuje ryzyko nieautoryzowanego dostępu oraz zmniejsza powierzchnię potencjalnych ataków.

Mówimy tutaj o jednej z technik segmentacji sieci na poziomie firewalla. Każdy dostawca oferuje nam różne rodzaje firewalli, które mogą nam w tym pomóc:

2. Korzystaj z NATowania, jeżeli usługa z adresem prywatnym musi komunikować się z internetem

Jeśli aplikacja lub usługa działa na prywatnym adresie IP, ale potrzebuje dostępu do zasobów internetowych, zastosowanie tzw. bramy NAT, czyli NAT Gateway jest najlepszą praktyką. Tego typu konfiguracja pozwala na komunikację z zewnętrznymi usługami bez ujawniania prywatnych adresów IP.

W dużym uproszczeniu NAT Gateway używamy, aby umożliwić instancjom w prywatnych sieciach na dostęp do internetu, na przykład bez ujawniania ich prywatnych adresów IP. Możemy też użyć bramy NAT, aby umożliwić naszym instancjom prywatnej sieci wysyłanie ruchu wychodzącego do internetu, jednocześnie uniemożliwiając internetowi nawiązanie połączeń z tymi instancjami.

Zdecydowanie dodatkowym plusem jest to, iż możemy użyć bramy NAT do komunikacji między sieciami, choćby w sytuacji, jeżeli obie sieci mają pokrywające się zakresy CIDR.

Za przykład takiej usługi, która może posiadać adres prywatny i jednocześnie musi komunikować się z internetem, możemy uznać kontenery uruchamiane w Kubernetes, który jest skonfigurowany właśnie z taką podsiecią prywatną. Kontenery muszą przy tym pobierać obrazy z publicznych repozytoriów. Aby to zrobić, potrzebują dostępu do internetu. NET Gateway pozwala na pobieranie tych obrazów bez ujawniania adresu IP naszego klastra kubernetesowego.

Chcesz zrozumieć, jak tworzyć infrastrukturę z Terraform i OpenTofu w AWS, Azure, Google Cloud?

Sprawdź TF Maestro!

3. Używaj narzędzi do monitorowania i logowania ruchu sieciowego

Monitorowanie ruchu sieciowego jest najważniejsze dla szybkiego wykrywania anomalii i potencjalnych zagrożeń. Monitorowanie pozwala przede wszystkim na wczesne wykrywanie nietypowych lub podejrzanych działań w ramach naszej sieci, takich jak np. Ataki DDoS. Jednocześnie analiza ruchu sieciowego może nam też pomóc w identyfikowaniu np. wąskich gardeł, opóźnień i różnych problemów z wydajnością. Każdy z dostawców oferuje nam kilka usług, dzięki którym możemy kompleksowo zadbać o monitoring i logowanie ruchu sieciowego.

4. Zabezpiecz usługi wystawione do internetu

Usługi wystawione do internetu, czyli te posiadające publiczny adres IP są szczególnie narażone na ataki – od ataków DDoS, do typowych ataków na aplikacje webowe, takie jak np. Cross-site scripting.

Każdy z dostawców chmurowych znów oferuje nam kilka rozwiązań, dzięki którym możemy zadbać o obronę naszych aplikacji przed atakami DDoS, przykładowo usługa AWS Shield czy Azure DDoS Protection. Ochronę przed innymi atakami zapewniają natomiast np. AWS WAF, Azure WAF czy Google Cloud Armor, który jednocześnie ma w sobie zarówno ochronę przed atakami DDoS, jak i przed pozostałymi.

Istnieją także popularne alternatywne rozwiązania od firm zewnętrznych, które również oferują nam takie możliwości. Jedne z najbardziej popularnych alternatyw to Akamai i Imperva czy Cloudflare. Zapewniają nam one bardzo podobne funkcjonalności, co wspomniane rozwiązania chmurowe. Będą dla nas dobrym wyborem, na przykład w sytuacji, gdy nasze usługi nie znajdują się u jednego dostawcy chmurowego.

5. Zapewnij bezpieczne połączenie między lokalnymi i chmurowymi zasobami

Kolejna dobra praktyka projektowania sieci w chmurze to zapewnienie bezpiecznego połączenia między lokalnymi i chmurowymi zasobami. No i tutaj sprawdza się usługa VPN. Każdy z dostawców chmurowych ma swoją własną VPN-ową usługę i ona umożliwia nam właśnie ustanowienie szyfrowanego połączenia VPN-owego między lokalnym środowiskiem a zasobami w chmurze.

Załóżmy, iż mamy jakiś serwer u innego dostawcy chmurowego, np. Digital Ocean i chcemy go skomunikować w bezpieczny sposób z przykładowo chmurą Google, gdzie posiadamy jakieś inne usługi. Wtedy możemy skorzystać z rozwiązania Google Cloud VPN. W przypadku AWS będzie to AWS VPN, a w przypadku Azure — Azure VPN Getway.

6. Zadbaj o to, aby sieć była łatwo skalowalna

Skalowalność sieci jest kluczowa, szczególnie w dynamicznie rozwijających się środowiskach produkcyjnych. Warto używać sieci VPC w trybie custom. Kiedy rozpoczynamy swój pierwszy projekt, zaczynamy wtedy od tej domyślnej sieci, czyli sieci default. Sieć w trybie default jest automatycznie tworzona. Automatycznie tworzą się tam również podsieci oraz odpowiadające im trasy podsieci. Choć sieci w trybie automatycznym, czyli te defaultowe, mogą być użyteczne na początkowym etapie, to jednak sieć VPC w trybie custom dużo lepiej sprawdza się w większości środowisk produkcyjnych, dlatego, iż mamy dużo większą władzę nad tym, jak ta sieć będzie skonfigurowana.

7. Zdefiniuj duży zakres adresów IP

Przemyślane planowanie zakresów adresów IP jest najważniejsze dla skalowalności. W tabeli poniżej widzisz maski, które definiują nam, ile adresów IP będzie znajdowało się w naszej sieci. Liczba adresów IP w takiej sieci z maską 8 jest bardzo duża i w większości przypadków nie będzie potrzeby, aby skorzystać z tego rodzaju maski. Natomiast może mieć ona zastosowanie w sytuacji, gdy np. jesteśmy dostawcami usług internetowych. Wtedy faktycznie ta większa ilość adresów IP będzie nam potrzebna.

Następnie mamy maskę 16. Jest ona stosowana też w dosyć dużych lokalnych sieciach, jej użycie zależy więc od tego, jak duża jest nasza firma i ile będziemy potrzebowali tych usług aplikacji.

Kolejna maska to 24 i ta maska to wybór zwykle nieco mniejszych firm. Jako ostatnia jest maska 30. Jest ona najczęściej używana do połączeń między routerami. Daje nam bardzo małą liczbę adresów, bo tak naprawdę mamy tylko dwa adresy IP. Przykładowo dla dwóch routerów na jednej i na drugiej końcówce.

8. Zadbaj o segmentację sieci

Dziel sieci na prywatne i publiczne podsieci w zależności od potrzeb bezpieczeństwa. Segmentacja pozwala na lepsze zarządzanie i ograniczanie dostępu do zasobów. W jaki sposób możemy o to zadbać?

Podzielenie podsieci na adresy IP prywatne i publiczne

Pierwszym ze sposobów, w jaki możemy podejść do segmentacji sieci to podzielenie podsieci na adresy IP prywatne i publiczne. Oznacza to tyle, iż usługi, które muszą być dostępne z internetu, powinny znaleźć się w publicznej podsieci. Natomiast te usługi, które posiadają prywatny adres IP, nie potrzebują dostępu do internetu i będą znajdować się w prywatnej podsieci.

Per środowisko

Kolejny sposób, w jaki możemy podejść do segmentacji sieci to per środowisko. Czyli możemy stworzyć podsieć dedykowaną usługom produkcyjnym bądź testowym lub deweloperskim.

Per typ aplikacji

Następny sposób to podział per typ aplikacji. W tym podejściu sieć będzie segmentowana na podstawie aplikacji usług, które będą się tam znajdować. Czyli możemy zrobić podsieć przeznaczoną tylko dla baz danych bądź np. tylko dla serwerów aplikacji webowych.

Per poziom krytyczności usługi

I ostatni z bardziej popularnych sposobów to podział per poziom krytyczności usługi. I w tym podejściu dokonujemy segmentacji na poziomie usług. Czyli inna podsieć jest dla usług podstawowych, druga dla bardziej krytycznych i trzecia dla tych najbardziej krytycznych usług. Przykładowo do usług podstawowych możemy zaliczyć np. serwery DNS, do usług bardziej krytycznych możemy zaliczyć np. serwery aplikacji webowych, a do tych najbardziej krytycznych np. bazy danych.

9. Zaplanuj i udokumentuj konwencję nazewniczą przed tworzeniem sieci

Dobrze przemyślana konwencja nazewnicza pozwala na łatwiejsze zarządzanie i przyszłe modyfikacje infrastruktury. Dlaczego jest to takie ważne? Ponieważ w sytuacji, gdy nie podejdziemy w przemyślany sposób do zaprojektowania nazewnictwa naszych usług w perspektywie czasu i w sytuacji, gdy będziemy chcieli np. migrować pewne usługi, może pojawić się problem. Dlatego powinniśmy się upewnić, iż nasze konwencje nazewnicze są przede wszystkim proste, intuicyjne i łatwe do zrozumienia. Co to oznacza? Oznacza to tyle, iż administratorzy i inni użytkownicy nie będą mieli większego problemu w zrozumieniu celu każdego z tych zasobów, ponieważ będzie on dobrze opisany poprzez nazwę tego zasobu.

Dla przykładu weźmy firmę, która nazywa się TF Maestro. Posiada ona oddział np. HR-owy, Security, R&D i środowiska: PROD, STAGE, DEV i TEST. Jak mogłaby przykładowo wyglądać taka konwencja nazewnicza dla usług sieciowych w tym przypadku?

Oto jak w prosty i zrozumiały sposób możemy nazwać kilka usług:

VPC: Co składa się na tę nazwę? TF Maestro, czyli nazwa naszej firmy, następnie security — dział, który zarządza tą siecią w VPC (bądź ta sieć w VPC jest utworzona na projekcie dla Security). Następnie PROD, czyli środowisko, VPC – typ zasobu oraz 01 jako numeracja, która jest to sieć VBC.

Podsieć: Co się tutaj zmienia? Jedynie typ zasobu zmieniliśmy z VPC na Subnet.

Firewall: TF Maestro, Security i PROD już omówiliśmy, dalej przechodzimy do typu zasobu. Widzimy tutaj FW jako skrót od Firewall. Następnie opisujemy regułę firewall-ową: Internal TCP 80 allow rule, możemy wywnioskować, iż ta reguła firewall-owa dotyczy ruchu wewnętrznego i przepuszcza nam ruch dla protokołu TCP na porcie 80.

Terraform dobre praktyki — wnioski

Podsumowując, projektowanie sieci w chmurze z wykorzystaniem Terraform i OpenTofu wymaga nie tylko przemyślanego podejścia, ale także wdrożenia szeregu dobrych praktyk. Kluczowymi aspektami są: ograniczanie ruchu sieciowego do niezbędnego minimum, stosowanie bram NAT dla prywatnych zasobów, monitorowanie i logowanie ruchu sieciowego, zabezpieczanie usług publicznych przed atakami oraz zapewnienie bezpiecznych połączeń między zasobami lokalnymi i chmurowymi. Ważna jest także dbałość o skalowalność sieci oraz planowanie zakresów adresów IP. Segmentacja sieci, dostosowana do środowiska, typu aplikacji czy poziomu krytyczności, pozwala na lepsze zarządzanie i ochronę zasobów. A przemyślana konwencja nazewnicza wspiera efektywne zarządzanie infrastrukturą i minimalizuje problemy związane z migracją i utrzymaniem zasobów.

Stosowanie tych zasad i praktyk pozwoli na budowę stabilnej, bezpiecznej i elastycznej sieci chmurowej, gotowej na przyszłe wyzwania i rozwój.