Wdrożenie i obsługa Sophos Firewall w AWS

Sophos Firewall 22 działa w AWS jako wirtualna appliance EC2 inline w VPC. Najpierw trzeba określić ruch podlegający inspekcji. Firewall standalone może kontrolować ruch przychodzący i wychodzący; template Sophos Auto Scaling jest wyspecjalizowanym projektem PAYG dla przychodzącego DNAT lub WAF.

Bezpieczna ścieżka to wybór architektury i licencji, zapisanie planu IP i routingu, uruchomienie właściwego template Marketplace, ograniczenie zarządzania do stałego IP źródłowego, weryfikacja jednego przepływu end-to-end i dopiero potem publikacja kolejnych usług.

⚠️ AWS Security Groups pozostają drugą warstwą firewalla. Reguła SFOS nie pomoże, jeśli Security Group, NACL lub Route Table blokuje ścieżkę. Otwartego portu AWS nie należy też łączyć z szeroką regułą Sophos. Security Groups są stateful, a Network ACL stateless, więc własna NACL musi zezwalać na żądanie i odpowiedź.

Wybór standalone lub Auto Scaling

AWS nie obsługuje natywnego HA Sophos Firewall. Auto Scaling i Network Load Balancing to inny projekt chmurowy, a nie synchronizacja HA SFOS. Standalone wymaga więc procedury odbudowy i akceptowanego okna przerwy.

Przy wyborze instancji obowiązują trzy kontrole: typ EC2 musi być oferowany w otwartym szablonie Marketplace CloudFormation dla wybranego regionu i AMI; CPU, RAM i wydajność sieci muszą odpowiadać przepustowości i profilowi połączeń; w BYOL należy potwierdzić uprawnienia dotyczące CPU oraz warunki obowiązujące dla tej konkretnej licencji.

Zestawienie dla SFOS 22/23 wskazuje na przykład m5.large z 2 vCPU i 8 GB RAM dla SFv2C4 oraz m5.xlarge z 4 vCPU i 16 GB RAM dla SFv4C6. Są to przykłady przypisania zależne od wersji i oferty, a nie gwarancja dla każdego aktualnego szablonu. Historyczny sufiks RAM w nazwie licencji nie jest zatem wiarygodną górną granicą fizycznej pamięci RAM instancji EC2; nie wynika z tego jednak również ogólna gwarancja uprawnienia do nieograniczonej ilości RAM. Przed zakupem wyjaśnić z Sophos lub partnerem licencyjnym konkretne uprawnienia wynikające z licencji i oferty oraz je udokumentować; w razie niejasności nie wdrażać produkcyjnie.

Wybrać oferowany rozmiar z zapasem wydajności i zapisać w planie wdrożenia typ EC2, AMI/wersję SFOS oraz potwierdzone warunki licencyjne.

W PAYG rozliczanie oprogramowania kończy się dopiero po usunięciu wszystkich objętych nim instancji firewall; osobno pozostawione zasoby AWS mogą nadal generować koszty.

Jeśli planowanego typu nie ma w szablonie albo CloudFormation odrzuca kombinację regionu, AMI i rozmiaru, nie wymuszać jej ręczną zmianą szablonu. Wybrać oferowany typ spełniający wymagania obciążenia i licencji albo zatrzymać wdrożenie do czasu wyjaśnienia regionu, oferty lub licencji.

Wyjaśnić kwestie licencji i pilotażu przed zakupem

Jeżeli PAYG nie jest dostępny w danym kraju lub ofercie, można rozważyć Standalone BYOL z potwierdzoną licencją; nie oznacza to jednak, że szablon Auto Scaling przeznaczony wyłącznie dla PAYG można używać z BYOL. Za pośrednictwem Sophos lub partnera można również sprawdzić możliwość skorzystania z Private Offer z indywidualnie uzgodnionymi cenami i warunkami. BYOL eliminuje opłatę za oprogramowanie w Marketplace, ale nie koszty EC2 i infrastruktury.

Na potrzeby pilotażu sprawdzić rzeczywiste uprawnienie do okresu próbnego, jego długość i warunki wybranej oferty. Historyczne FAQ AWS opisuje 30-dniowy okres próbny oprogramowania PAYG; nie jest to gwarancja dla oferty wybranej obecnie. Po zakończeniu jej okresu próbnego dalsze korzystanie z oprogramowania PAYG automatycznie staje się płatne. EC2, pamięć masowa, sieć i pozostała infrastruktura mogą być płatne już w okresie próbnym. Zapisać datę zakończenia, osobę odpowiedzialną za koszty, alarm budżetowy oraz decyzję o dalszej eksploatacji lub terminowym usunięciu wdrożenia. W BYOL użyć oferowanej aktywacji próbnej podczas pierwszej konfiguracji albo zatwierdzonej wcześniej licencji próbnej; sama rejestracja nie stanowi obietnicy przyznania licencji.

Produkcyjną licencję UTM można przenieść na Sophos Firewall wyłącznie przez przewidziany proces konwersji, zależny od posiadanych uprawnień. Przeniesienie istniejącej licencji Firewall jest również możliwe tylko w dopuszczonych scenariuszach, a nie przez dowolne ponowne użycie tego samego klucza. Obie możliwości potwierdzić z partnerem licencyjnym przed rozpoczęciem wdrożenia BYOL. Aktywacja klucza licencyjnego opisuje późniejszą aktywację.

W modelu współdzielonej odpowiedzialności aplikacje, dane, konfiguracja i utrzymanie pozostają po stronie użytkownika. IPS, filtrowanie WWW i WAF uzupełniają SG/NACL tylko na faktycznie kontrolowanej ścieżce ruchu. Synchronized Security wymaga odpowiednich licencji endpointów, rejestracji oraz konfiguracji Heartbeat i reguł firewalla; nie izoluje automatycznie każdej ścieżki ruchu między instancjami EC2, która omija te mechanizmy kontroli. Połączenie z Central wyjaśnia integrację z centralnym zarządzaniem.

Przygotowanie wdrożenia standalone

Przed startem zapisać:

• konto AWS, region, Availability Zone i ofertę BYOL lub PAYG;
• nową lub istniejącą VPC oraz nienakładające się publiczne i prywatne CIDR;
• stałe źródło zarządzania, np. 198.51.100.27/32, zamiast dostępu globalnego;
• Elastic IP, nazwy DNS i wymagane usługi inbound;
• prywatne sieci docelowe, default route i oczekiwaną drogę powrotną każdego przepływu;
• wspierany typ EC2, limit licencji, właściciela kosztów i tagi;
• procedury backupu, firmware i odbudowy.

198.51.100.27/32 to adres dokumentacyjny, który należy zastąpić prawdziwym publicznym IP administratora. Gdy często się zmienia, VPN lub kontrolowany jump host jest bezpieczniejszy niż szerokie otwarcie TCP 4444.

W istniejącej VPC nie wybiera się subnetów wyłącznie po nazwie: Route Tables muszą odpowiadać planowanemu kierunkowi. AWS opisuje włączenie appliance w przykładach middlebox routing. Source/Destination Check musi być wyłączony na przekazujących ruch ENI firewalla. CloudFormation powinien ustawić te szczegóły, a administrator je zweryfikować bez ślepych zmian.

Wdrożenie standalone przez CloudFormation

1. Otworzyć ofertę Sophos Firewall BYOL lub PAYG w AWS Marketplace, wybrać View purchase options i zaakceptować warunki.
2. W Continue to Configuration wybrać fulfillment, aktualną wersję SFOS i region.
3. W Continue to Launch wybrać Launch CloudFormation i otworzyć template w konsoli AWS CloudFormation.
4. Podać unikatowy Stack name. Dla nowej VPC sprawdzić nakładanie zakresów z istniejącymi VPC, VPN i sieciami lokalnymi.
5. Dla istniejącej VPC przypisać VPC ID, jeden subnet publiczny, jeden prywatny i nowy lub wolny Elastic IP. Pozostawić Network Address Prefix for new VPC bez zmian.
6. Użyć wyłącznie rozmiaru EC2 oferowanego przez otwarty szablon dla regionu i AMI, a w BYOL ponownie sprawdzić go względem zapisanego limitu licencji. Nie przechowywać sekretów w ticketach, screenshotach ani publicznie czytelnych plikach parametrów.
7. Sprawdzić żądane zasoby IAM. Dopiero wtedy potwierdzić I acknowledge that AWS CloudFormation might create IAM resources i kliknąć Submit.
8. Zaczekać na CREATE_COMPLETE. Odczytać Elastic IP w Outputs, a w EC2 sprawdzić oba status checks i oczekiwane ENI.
9. Otworzyć WebAdmin z dozwolonego źródła pod https://<EIP>:4444. Ostrzeżenie początkowego lokalnego certyfikatu pominąć tylko po sprawdzeniu docelowego IP, zaakceptować warunki użytkowania i zakończyć rejestrację oraz konfigurację podstawową. Następnie w Administration > Licensing potwierdzić aktywność oczekiwanej licencji; w razie rozbieżności poprawić rozmiar instancji lub przypisanie licencji przed dopuszczeniem ruchu produkcyjnego.

Parametry Marketplace mogą się zmieniać; przed każdym wdrożeniem produkcyjnym porównaj widoczne nazwy pól z faktycznie otwartym template’em.

Wspólne otwieranie reguł AWS i SFOS

Szablon Sophos Standalone domyślnie włącza tylko dostęp administracyjny do WebAdmin i SSH. To stwierdzenie nie dotyczy ogólnie Auto Scaling: tam Public Network CIDR steruje ruchem innym niż administracyjny. IPsec, SSL VPN, RED, WAF, User Portal lub publikowane aplikacje wymagają dodatkowo odpowiednich reguł AWS Security Group. Dla SD-RED 20/60 należy uwzględnić ruch do zapory przez TCP 3400 dla kanału sterowania oraz UDP 3410 dla tunelu danych; dodatkowe wymagania dotyczące provisioningu, DNS i NTP oraz inne warianty RED należy sprawdzić osobno.

Dla każdej publikacji raz udokumentować protokół, port docelowy i źródło, ale wdrożyć je oddzielnie:

1. Security Group pozwala tylko wymaganemu źródłu na port właściwego ENI.
2. Własna NACL pozwala na żądanie i powrót. AWS wyjaśnia różnicę w Security Groups i Network ACLs.
3. Route Table prowadzi ruch przez firewall i zapewnia prawidłowy powrót.
4. Reguły firewall SFOS i w razie potrzeby NAT używają konkretnych stref, hostów i usług, logują ruch i stosują właściwe Security Profiles.

Nigdy nie otwierać SSH ani WebAdmin do 0.0.0.0/0. Wąski dostęp AWS nie zastępuje precyzyjnej reguły SFOS.

Auto Scaling dla ruchu inbound

Auto Scaling wymaga konta AWS, oferty Marketplace Sophos Cloud Firewall (PAYG) oraz konta Sophos Fusion z wymaganymi uprawnieniami do zarządzania firewallami. W Sophos Fusion (dawniej Sophos Central), w My products > General settings > API credentials management, sprawdzić warunki i utworzyć poświadczenie z nazwą, opisem oraz rolą Service principal firewall. Client ID i Client secret przechowywać w magazynie sekretów z ograniczonym dostępem, a nie w niezabezpieczonym pliku tekstowym. Hasło konta Sophos ID jest innym sekretem niż sekret klienta API.

1. W wybranym regionie AWS, w EC2 > Network & security > Key pairs, utworzyć odpowiednią parę kluczy lub użyć istniejącej. Bezpiecznie przechowywać klucz prywatny i zapisać nazwę do pola SSH KeyPair Name.
2. W Marketplace otworzyć View purchase options i Continue to configuration. Wybrać Sophos Auto Scaling Firewall for AWS jako Fulfillment option, zatwierdzoną Software version oraz Region. W Continue to launch wybrać akcję Launch CloudFormation, kliknąć Launch, a następnie Next w CloudFormation.
3. Nadać unikatową Stack name. Porównać AMI ID z wybraną ofertą i wersją, a w Instance size wybrać oferowany rozmiar o wystarczającej wydajności. W AvailabilityZone 1 for deployment i AvailabilityZone 2 for deployment wybrać dwie różne AZ.
4. Nowa VPC: w Network Address Prefix for new VPC wprowadzić pierwsze dwa oktety zaplanowanego zakresu bez kolizji; pola dla istniejącej VPC pozostawić puste. Istniejąca VPC: pozostawić parametr prefiksu bez zmian i wprowadzić Deploy to an existing VPC, Existing public subnet ID 1, Existing public subnet ID 2 oraz Existing private subnet ID zgodnie z planem wdrożenia. Subnety publiczne muszą należeć do wybranych AZ i mieć włączone Auto-assign public IPv4 address. Sprawdzić również trasy i NACL.
5. Ustawić nazwę firewalla, Admin Password dla WebAdmin/CLI, Secure Storage Master Key Password i SSH KeyPair Name. Oba hasła firewalla chronić oddzielnie od sekretu API.
6. Wprowadzić Sophos ID email address i Sophos ID password przewidzianego konta, Sophos Central client ID, Sophos Central client secret oraz Sophos Central AS Group name. Nazwy pól Central mogą pozostać w szablonie mimo zmiany marki na Fusion; grupa jest automatycznie tworzona na powiązanym koncie. Nie umieszczać sekretów w zgłoszeniach, zrzutach ekranu ani publicznych plikach parametrów.
7. Ustawić poniższe parametry sieci, pojemności i rejestrowania logów. Po sprawdzeniu warunków w I accept the Sophos End User License Agreement and acknowledge the Sophos Privacy Policy wpisać dokładnie yes; wielkość liter ma znaczenie. Świadomie wybrać opcję dla Opt in to the customer experience improvement program.
8. Przez Next otworzyć opcje stosu, ustawić tagi właściciela i kosztów oraz sprawdzić żądane uprawnienia IAM. Dopiero potem zaznaczyć I acknowledge that AWS CloudFormation might create IAM resources, sprawdzić pełne podsumowanie i uruchomić wdrożenie przez Submit.

Po CREATE_COMPLETE sprawdzić instancje EC2 oraz automatycznie utworzoną grupę ze wszystkimi oczekiwanymi, zatwierdzonymi workerami PAYG w My products > Firewall management > Firewalls. Potwierdzić synchronizację polityki przed udostępnieniem usługi. Jeżeli brakuje workera lub rejestracja kończy się niepowodzeniem, nie otwierać kolejnych portów; sprawdzić zdarzenia stosu, dostęp do sieci oraz powiązanie konta i API, nie zapisując sekretów w logach. Pojemność zmieniać później w EC2 > Auto scaling > Auto scaling groups > Capacity overview > Edit i zatwierdzać przez Update. Jednoznacznie udokumentować ID instancji, AZ i nazwy firewalli; po każdej zmianie pojemności ponownie sprawdzić członkostwo w grupie i Target Health.

DNAT za Network Load Balancer

Warunkiem wstępnym jest działające, sprawdzone wdrożenie Auto Scaling. Dla zatwierdzonej usługi TCP listener NLB kieruje ruch do Target Group workerów firewalla, a nie bezpośrednio do backendu. Poniższy autorski schemat przedstawia przykładową ścieżkę HTTPS, a nie połączenie zweryfikowane pomiarami:

Dozwolony klient : efemeryczny port źródłowy
                 | TCP port docelowy 443
          Listener TCP NLB :443
                 |
       Target Group workerów firewalla
         /                       \
 AZ 1: Worker PortB       AZ 2: Worker PortB
         \                       /
          DNAT do backendu :443
          SNAT = MASQ workera
                 |
          Wewnętrzny serwer aplikacji :443
                 | Odpowiedź
          Ten sam worker -> NLB -> Klient

Schemat: dwie AZ, jeden aktywny PortB na worker i ścieżka powrotna przez MASQ. Strzałki opisują logiczną ścieżkę danych; równoważenie obciążenia nie gwarantuje równomiernego wykorzystania. Wszystkie przykładowe wartości dostosować do zatwierdzonej usługi.

1. W Fusion, w My products > Firewall management > Firewalls, otworzyć Manage policy dla właściwej grupy firewalli Auto Scaling. W Hosts and services > IP host utworzyć dwa zakresy adresów IPv4 dla rzeczywistych subnetów WAN obu AZ oraz host IPv4 dla serwera wewnętrznego. Nie uwzględniać pierwszego adresu każdego subnetu; objąć tylko faktycznie użyteczne adresy workerów, bez adresów zarezerwowanych przez AWS.
2. W Hosts and services > Services utworzyć usługę TCP/UDP z Protocol TCP. Przy zestawianiu tego połączenia przychodzącego efemeryczny port klienta jest źródłem, a port publikowanej usługi — celem. Poniższy kierunek dotyczy żądania, a nie odpowiedzi; 3389 ani 8080 nie są dodatkowo otwierane.

3. Zapisać regułę firewall w Rules and policies > Firewall rules oraz regułę NAT w Rules and policies > NAT rules w polityce grupy. Sprawdzić synchronizację na każdym uruchomionym workerze.
4. W EC2 > Load balancing > Target groups > Create target group wybrać Instances, unikatową nazwę, Protocol TCP, Port 443 oraz VPC wdrożenia. Świadomie dostosować protokół, port i ewentualną ścieżkę kontroli stanu do sprawdzonej usługi. Podczas tworzenia w Available instances nie wybierać ręcznie żadnej instancji, w szczególności serwera backendu.
5. W EC2 > Auto scaling > Auto scaling groups wybrać ASG firewalla i dołączyć Target Group w Integrations > Load balancing > Edit; zatwierdzić przez Update. Dzięki temu ASG automatycznie rejestruje swoje workery, również te uruchamiane później.
6. Przed uruchomieniem listenera w Load balancers sprawdzić przypisanie Security Group do rzeczywistego NLB utworzonego przez szablon. Jeżeli NLB został utworzony bez Security Group, nie można jej dodać później. W takim przypadku nie udostępniać publicznego listenera, dopóki nie zostanie zatwierdzona wspierana ścieżka z ograniczeniem źródeł; alternatywnie użyć VPN/ZTNA. Nie przebudowywać bez sprawdzenia zarządzanego szablonu ani nie obiecywać późniejszego dołączenia SG.
7. Jeżeli restrykcyjna ścieżka istnieje, w NLB, w Listeners > Add listener, skonfigurować TCP i port 443 z Target Group workerów jako Default action. Ograniczyć SG NLB do dozwolonych CIDR klientów i portu listenera; na workerze oddzielnie zezwolić na porty docelowe i porty kontroli stanu wymagane przez NLB. Ruch wychodzący z NLB musi mieć dostęp do kontroli stanu. Dostęp na potrzeby kontroli stanu nie jest publicznym udostępnieniem aplikacji. Ograniczyć również bezpośredni dostęp do workerów i backendu.
8. Przed użyciem produkcyjnym sprawdzić, czy oczekiwane workery obu AZ oraz worker uruchomiony od nowa w zatwierdzonym oknie zmian automatycznie pojawiają się w Target Group i przechodzą przewidziane kontrole stanu. Przez nazwę DNS NLB sprawdzić prawidłowy przepływ aplikacyjny oraz negatywną próbę z niedozwolonego źródła; Log Viewer musi pokazywać oczekiwaną regułę i DNAT/MASQ. Nie polegać wyłącznie na healthy.

Bezpośrednie publiczne udostępnienie RDP nadal nie jest zalecane; preferować VPN lub ZTNA. Jeżeli target pozostaje unhealthy, najpierw sprawdzić przypisanie ASG, zsynchronizowaną politykę, port/ścieżkę kontroli stanu, ruch wychodzący z NLB, SG workera i NACL. Przy nieprawidłowym backendzie lub ścieżce powrotnej pozostawić listener zamknięty i poprawić NAT/usługę/trasę.

Odbiór jednego przepływu warstwa po warstwie

Zapisać jeden przepływ, np. 198.51.100.27:55000 -> NLB-DNS:443 -> App-Server:443. Port źródłowy jest tylko przykładem efemerycznego portu klienta. Sprawdzić kolejno:

1. DNS i listener NLB wskazują oczekiwany cel, a Target Group pokazuje workery jako healthy.
2. Security Groups i NACL pozwalają dokładnie na żądanie i powrót.
3. Route Tables i ENI prowadzą ruch przez appliance; Source/Destination Check jest wyłączony na interfejsach tranzytowych.
4. SFOS Log Viewer pokazuje oczekiwaną Rule ID. Dla DNAT zgadzają się cel pierwotny, tłumaczony i powrót.
5. Test dozwolony dociera do aplikacji, a test z niedozwolonego źródła jest blokowany.

Jeśli brak logu SFOS, sprawdzić DNS, listener, Target Health, Security Group, NACL i route. Przy dropie z inną Rule ID poprawić strefy, obiekty sieciowe, usługę i kolejność. Gdy żądanie dociera bez odpowiedzi, sprawdzić Route Table, NACL, default gateway serwera i w Auto Scaling ustawienie MASQ.

Eksploatacja i odtwarzanie

Standalone i Auto Scaling wymagają różnych runbooków. Dla standalone udokumentować backup SFOS i przetestowane odtworzenie, proces firmware, parametry CloudFormation i próbę odbudowy. Snapshot EC2 nie zastępuje eksportowanego backupu SFOS.

Workery Auto Scaling są efemeryczne. Z CloudWatch logi trafiają pod /sophos/xg/; jawnie ustawić retencję, szyfrowanie, dostęp i koszty. Zakończone instancje EC2 pozostają w grupie Fusion i trzeba je usunąć ręcznie. Warm Pool nie zastępuje kontroli aktualnej policy na każdym workerze.

Rejestr eksploatacyjny obejmuje tagi właściciela i kosztów, alerty budżetowe, licencję, rotację sekretów, retencję CloudWatch, czyszczenie Fusion, zatwierdzanie firmware, testy zmian i recovery. Po każdej zmianie template, routingu lub policy powtórzyć test pozytywny i negatywny.

Zatrzymać zmianę i wycofać ją w sposób ukierunkowany

Przed zmianą zabezpieczyć parametry stosu i ID zasobów, przypisanie listenera do Target Group, SG/NACL/Route Tables oraz politykę grupy SFOS i backup. Przy nieprawidłowym celu, nieoczekiwanym źródle, braku synchronizacji polityki lub zakłóceniu istniejącego połączenia najpierw zamknąć nowo dodany listener albo nowy dostęp zewnętrzny; następnie przywrócić do udokumentowanego bezpiecznego stanu tylko nowo wprowadzone reguły i trasy. Ponownie sprawdzić istniejący ruch oraz blokowanie niedozwolonych źródeł. Nie usuwać współdzielonej VPC, subnetów, bramy ani istniejących listenerów w celu usunięcia błędu.

Przy planowanym usunięciu wdrożenia PAYG nie wystarczy zakończyć pojedynczych workerów: ASG może utworzyć je ponownie. Najpierw usunąć nowy dostęp zewnętrzny, przeprowadzić zatwierdzone wycofanie z eksploatacji zgodnie z cyklem życia stosu/ASG i sprawdzić, czy ani akcje skalowania, ani instancje Warm Pool nie uruchamiają ponownie workerów. Usunąć wszystkie powiązane instancje firewall PAYG i sprawdzić rzeczywisty stan zasobów. Zachowane wolumeny, EIP, NLB, Log Groups i inne płatne zasoby ocenić indywidualnie na podstawie listy zasobów, zamiast usuwać je zbiorczo; zakończone workery usunąć z grupy Fusion. Następnie sprawdzić rozliczenia i kontrolę kosztów.