System billingowy, portal klienta lub aplikacja branżowa często powstaje na bazie produktu zewnętrznego dostawcy, a następnie przez lata jest dostosowywany do procesów organizacji. Takiego rozwiązania nie da się po prostu wymienić po wykryciu podatności. Poprawki wymagają czasu, testów i uzgodnień, a system musi nadal obsługiwać klientów.

Poniższe pytania pomagają zaplanować dodatkową ochronę aplikacji internetowej i jej API za pomocą FortiWeb. Punktem wyjścia jest ciągłość procesów biznesowych: rozliczeń, wymiany danych i obsługi użytkowników.

1. Mamy system billingowy od zewnętrznego dostawcy. Po co nam dodatkowa ochrona?

Dostawca rozwija aplikację, ale organizacja nadal musi ustalić, kto odpowiada za jej udostępnienie, konfigurację infrastruktury, monitorowanie i obsługę incydentów. Dostosowania oraz integracje mogą dodatkowo komplikować aktualizacje.

WAF stanowi warstwę kontroli ruchu kierowanego do aplikacji. W projekcie warto uzgodnić z dostawcą jej zakres, sposób zgłaszania podatności i procedurę reagowania. Nie zakładamy, że sama obecność WAF rozwiązuje błędy logiki biznesowej czy uprawnień użytkowników.

2. Czy możemy wdrożyć FortiWeb, jeśli nie mamy dostępu do kodu źródłowego?

W typowym wdrożeniu reverse proxy FortiWeb znajduje się pomiędzy użytkownikami a serwerami aplikacji i analizuje ruch HTTP/HTTPS. Taka architektura pozwala włączyć ochronę na poziomie infrastruktury, bez konieczności samodzielnego rozwijania kodu aplikacji.

Potrzebna jest jednak kontrola nad odpowiednimi elementami środowiska oraz współpraca z dostawcą. Należy sprawdzić DNS, certyfikaty, adresy klientów, przekierowania, sesje i mechanizmy uwierzytelniania. W przypadku usługi SaaS zarządzanej w całości przez producenta możliwość takiego wdrożenia wymaga osobnego potwierdzenia.

Dokumentacja: tryb reverse proxy

3. Co zrobić, gdy wykryto podatność, a dostawca potrzebuje czasu na poprawkę?

Można rozważyć virtual patching: reguły WAF ograniczające możliwość wykorzystania konkretnej podatności przez ruch przechodzący przez urządzenie. FortiWeb oferuje taką funkcjonalność, ale jej zastosowanie zależy od charakteru podatności i dostępnych reguł.

To dodatkowe zabezpieczenie na czas przygotowania poprawki. Trzeba przetestować regułę, monitorować jej działanie i nadal wdrożyć aktualizację aplikacji. Ruch omijający WAF lub podatność poza jego zakresem inspekcji wymaga innych działań.

Karta produktu: FortiWeb i virtual patching

4. Nasza aplikacja jest mocno zmodyfikowana. Jak dopasować ochronę?

Przygotujmy listę najważniejszych operacji: logowania, naliczania opłat, generowania faktur, eksportów i komunikacji z partnerami. Dla każdej ustalmy poprawny przebieg oraz dane, które mogą pojawiać się w żądaniach.

Na tej podstawie planujemy obserwację ruchu, dostrojenie polityk i testy. Nietypowy format danych nie powinien automatycznie prowadzić do szerokiego wyłączenia ochrony. Wyjątki warto ograniczać do konkretnych ścieżek i parametrów, a po zmianach aplikacji ponownie je weryfikować.

5. Jak uruchomić ochronę bez zakłócania rozliczeń i obsługi klientów?

Wdrożenie powinno mieć etapy oraz uzgodniony plan wycofania zmiany. Proponujemy zacząć od testów i obserwacji, przeanalizować alerty, a dopiero później uruchamiać blokowanie dla zweryfikowanych zasad.

Testy muszą uwzględniać cały cykl biznesowy, w tym zamknięcie miesiąca, operacje masowe i szczyty ruchu. Tryb pasywnej obserwacji nie zapewnia takiej samej ochrony jak blokowanie ruchu w jego ścieżce. Dokumentacja FortiWeb wskazuje, że Offline Protection może wykrywać ataki, lecz nie gwarantuje ich zatrzymania przed dotarciem do serwera.

Dokumentacja: ograniczenia Offline Protection

6. Co z integracjami API, ERP, płatnościami i systemami partnerów?

Ruch pomiędzy systemami jest równie ważny jak ruch użytkowników. Warto zinwentaryzować interfejsy, metody uwierzytelniania, formaty danych, limity wielkości komunikatów oraz operacje wykonywane okresowo.

FortiWeb udostępnia ochronę interfejsów XML, JSON i REST. Konkretne mechanizmy dobieramy do aplikacji i pakietu. W testach uwzględniamy również callbacki płatnicze, ponawianie żądań i komunikację z adresów partnerów. Integracje, które nie przechodzą przez WAF, wymagają odrębnej analizy zabezpieczeń.

Dokumentacja: ochrona API

7. Czy FortiWeb stanie się pojedynczym punktem awarii?

To zależy od architektury wdrożenia. FortiWeb obsługuje konfiguracje wysokiej dostępności, w tym active-passive i wybrane warianty active-active. Dostępność danego wariantu zależy od trybu pracy.

Projekt powinien obejmować również łącza, przełączniki, zasilanie i serwery aplikacji. Przed odbiorem należy sprawdzić przełączenie awaryjne oraz wpływ na sesje i trwające operacje. Sam zakup dwóch urządzeń nie potwierdza odporności całej usługi na awarie.

Dokumentacja: wysoka dostępność FortiWeb

8. Mamy już FortiGate. Jaką dodatkową rolę pełni FortiWeb?

FortiWeb pozwala osobno zaprojektować ochronę aplikacji i API: uwzględnić ich strukturę, oczekiwane żądania i specyficzne zagrożenia. Dobór zaczynamy od sprawdzenia istniejących zabezpieczeń i ustalenia, gdzie potrzebna jest dodatkowa kontrola.

FortiGate i FortiWeb mogą być elementami wspólnej architektury Fortinet Security Fabric. Zakres integracji, logowania i reakcji ustalamy podczas wdrożenia. Nie należy zakładać, że posiadanie FortiGate automatycznie zapewnia licencję lub konfigurację FortiWeb.

9. Gdzie będą przetwarzane dane i co trafi do logów?

Odpowiedź musi wynikać z wybranego modelu wdrożenia i konfiguracji usług. Przed uruchomieniem trzeba ustalić miejsce inspekcji HTTPS, obsługę certyfikatów, zakres rejestrowanych informacji, czas przechowywania oraz uprawnienia administratorów.

W systemie billingowym szczególnej uwagi wymagają dane klientów, identyfikatory i informacje uwierzytelniające. W projekcie określamy, które informacje mogą trafiać do logów i usług analitycznych. Samo wdrożenie urządzenia lokalnie nie przesądza o przepływie danych do wszystkich usług dodatkowych.

10. Jak dobrać licencje dla kilku aplikacji i środowisk?

Najpierw rozdzielamy produkcję, testy, aplikacje i API oraz określamy ruch i wymagania dostępności. FortiWeb występuje jako urządzenie fizyczne i maszyna wirtualna; FortiAppSec Cloud WAF jest usługą SaaS.

W usłudze chmurowej dobór obejmuje plan, liczbę aplikacji i przepustowość. Dla wdrożeń własnych uwzględniamy model lub rozmiar VM, usługi ochronne i elementy HA. Nie należy utożsamiać liczby domen z liczbą jednostek licencyjnych bez sprawdzenia zasad danego wariantu.

Przewodnik zakupu i licencjonowania FortiWeb

Jak rozpocząć projekt ochrony aplikacji?

Przygotuj listę aplikacji i integracji, opis hostowania, dane o ruchu oraz wymagania dostępności. Warto zaprosić do rozmowy osoby odpowiedzialne za infrastrukturę, bezpieczeństwo i rozwój aplikacji po stronie dostawcy.

Te same pytania są przydatne dla e-commerce: sklepu połączonego z ERP, płatnościami i logistyką. Zakres testów powinien wówczas obejmować zakupy, aktualizacje stanów i potwierdzanie transakcji.

Poznaj FortiWeb i warianty ochrony aplikacji lub porozmawiaj z IT Serwis o swoim środowisku.