Publikacja usługi nie zaczyna się od przekierowania portu. Zaczyna się od wskazania właściciela, celu biznesowego i osoby, która może zaakceptować ryzyko. Ta procedura dotyczy aplikacji WWW, paneli partnerów, API i innych usług firmowych. Nie jest instrukcją aktywnego testowania cudzych systemów.
1. Ustal właściciela i cel
Właściciel biznesowy opisuje, kto i po co korzysta z usługi, wymagane godziny dostępności oraz skutek niedostępności lub ujawnienia danych. Właściciel techniczny odpowiada za konfigurację, aktualizacje, logi i odtworzenie. Osoba zatwierdzająca podejmuje udokumentowaną decyzję o uruchomieniu. Jedna osoba może pełnić kilka ról, ale żadna rola nie może pozostać domyślna.
Wpisz domenę, publiczny adres, dostawcę, protokół i właścicieli do arkusza ekspozycji internetowej. Zapis „potrzebne zdalnie” nie wystarcza: określ użytkowników, funkcję i oczekiwany okres publikacji.
2. Potwierdź zakres i upoważnienie
Sprawdź, czy zespół ma zgodę na zmianę DNS, zapory, chmury i systemu docelowego. Zakres powinien wymieniać środowisko, nazwy, adresy, porty, dostawców oraz termin. Osobno zapisz, czego nie wolno publikować: interfejsu administracyjnego, bazy danych, udziałów plikowych, konsoli hypervisora lub środowiska testowego.
Jeżeli usługa przetwarza dane osobowe, płatności albo informacje objęte umową, uzyskaj właściwą akceptację prawną lub zgodności. Testy wykonuj tylko wobec zasobów firmy lub objętych wyraźnym upoważnieniem.
3. Wybierz architekturę
Narysuj przepływ: klient, DNS, warstwa brzegowa, usługa, zależności i ścieżka administracyjna. Umieść publiczny komponent w wydzielonej strefie. Segmentacja sieci ogranicza dozwolone połączenia między strefami, a izolacja zmniejsza liczbę elementów, które mogą zostać przejęte jednym kontem lub błędem.
Wybierz najwęższy właściwy wariant:
- Reverse proxy pasuje do publicznej aplikacji HTTP/S. Centralizuje TLS, nagłówki, limity i logi, lecz sam nie naprawia podatnej aplikacji.
- VPN jest dobry, gdy dostęp ma zamknięta grupa użytkowników i pełna publiczna dostępność nie jest potrzebna. Wymaga utrzymania klientów, tożsamości i urządzenia końcowego.
- Brama dostępu zapewnia kontrolowany punkt wejścia, polityki per aplikacja i często MFA. Zwiększa zależność od bramy lub dostawcy.
- Publikacja bezpośrednia jest wyjątkiem wymagającym uzasadnienia. Nie wystawiaj bezpośrednio RDP, SSH ani paneli administracyjnych. Dla pulpitu zdalnego zastosuj zasady z artykułu RDP wystawione do internetu to nie plan pracy zdalnej.
4. Skonfiguruj zabezpieczenia
Uwierzytelnianie oprzyj na centralnym dostawcy tożsamości, jeżeli usługa go obsługuje. Wymagaj MFA co najmniej dla administratorów i dostępu do danych wrażliwych; preferuj metody odporne na phishing. Konta serwisowe nie powinny umożliwiać logowania interaktywnego. Oddziel konta administracyjne od zwykłych i ogranicz role do niezbędnych działań.
Otwórz tylko wymagany protokół i port do konkretnego celu. Ogranicz źródła, jeżeli odbiorcy mają znane sieci. Zablokuj interfejsy zarządzania od strony publicznej. Reguły ruchu wychodzącego i połączeń do baz danych także powinny być jawne, nie „dowolne”.
Użyj TLS dla całej ścieżki zawierającej dane lub poświadczenia. Certyfikat musi odpowiadać nazwie, mieć monitorowaną datę wygaśnięcia i automatyczne odnowienie przetestowane przed startem. Wymuś aktualne protokoły i bezpieczne przekierowanie z HTTP, jeśli HTTP jest w ogóle potrzebne.
Zaktualizuj system operacyjny, aplikację, obrazy kontenerów, proxy i urządzenia brzegowe. Zapisz wersje oraz termin kolejnego okna aktualizacyjnego. Sekrety przechowuj w przeznaczonym do tego magazynie lub bezpiecznej konfiguracji, nie w repozytorium, obrazie ani skrypcie. Nadaj im minimalny zakres, rotację i właściciela.
5. Przygotuj obserwację i odtworzenie
Loguj co najmniej udane i nieudane logowania, użycie MFA, zmiany uprawnień i konfiguracji, błędy aplikacji oraz decyzje proxy lub bramy. Zsynchronizuj czas. Ogranicz dostęp do logów i ustal retencję. Alerty powinny mieć odbiorcę i reakcję: niedostępność, wzrost błędów, nietypowe odrzucenia, zmiana konta uprzywilejowanego, utrata źródła logów oraz zbliżające się wygaśnięcie certyfikatu.
Wykonaj kopię danych i konfiguracji, a następnie sprawdź możliwość odtworzenia. Plan wycofania ma wskazywać, jak przywrócić poprzednią wersję, DNS i reguły bez odcięcia administracji. Ustal kryteria przerwania uruchomienia, na przykład błędy uwierzytelniania, brak logów lub nieudany test odtworzenia.
6. Lista przed uruchomieniem
- Właściciele, cel, użytkownicy, zakres i zatwierdzający są zapisani.
- Architektura i przepływy między strefami mają akceptację.
- Publiczne są tylko wymagane nazwy, protokoły i porty.
- MFA, role minimalne i oddzielna administracja zostały sprawdzone.
- TLS, odnowienie certyfikatu, wersje i proces aktualizacji są gotowe.
- Sekrety nie znajdują się w kodzie ani obrazie.
- Logi docierają do uzgodnionego miejsca, a alerty mają odbiorcę.
- Kopia, odtworzenie i rollback zostały sprawdzone.
- Test funkcjonalny wykonano z dozwolonej sieci zewnętrznej.
- Właściciel biznesowy i osoba upoważniona zatwierdzili start.
Pomoc przy architekturze i weryfikacji zakresu opisują usługi bezpieczeństwa sieci, oceny bezpieczeństwa i administracji systemami. Przykładowe podejście techniczne pokazuje laboratorium bezpieczeństwa sieci.
7. Uruchomienie i zapis zmiany
Uruchamiaj w uzgodnionym oknie, z dostępnym właścicielem technicznym. Zapis uruchomienia powinien zawierać datę i strefę czasową, numer zmiany, wykonawcę i zatwierdzającego, wdrożoną wersję, domeny, adresy i porty, wynik testów, odnośniki do dashboardów oraz decyzję „pozostawić” albo „wycofać”. Po starcie obserwuj usługę przez ustalony okres i zamknij zmianę dopiero po potwierdzeniu logów, alertów oraz funkcji biznesowej.
8. Przegląd i wycofanie
Co najmniej kwartalnie, a także po incydencie lub istotnej zmianie, potwierdź właściciela, potrzebę biznesową, użytkowników, role, MFA, wersje, certyfikat, reguły, zależności, alerty, retencję i skuteczność odtworzenia. Każdy wyjątek musi mieć uzasadnienie, osobę akceptującą i datę wygaśnięcia.
Gdy usługa przestaje być potrzebna, ogłoś termin, zarchiwizuj wymagane dane i dowody, odbierz konta oraz tokeny, unieważnij sekrety i certyfikaty, usuń reguły, rekordy DNS i zasoby chmurowe, a monitoring pozostaw na uzgodniony okres. Na końcu zaktualizuj arkusz ekspozycji i zapisz potwierdzenie, że nazwa ani adres nie prowadzą już do porzuconej usługi.