Akceptacja zdalnego dostępu do VPC wymaga testów odmowy

Akceptacja zdalnego dostępu to tabela oczekiwanych wyników, a nie zrzut ekranu działającej strony. Dla każdej grupy zapisz, co powinno się udać, a co powinno się nie udać, a następnie wykonaj oba scenariusze na dedykowanych tożsamościach testowych w kontrolowanym oknie czasowym. Odmowy to ta część, która dowodzi granicy; udane logowanie dowodzi jedynie, że tunel istnieje. Wszystko to działa z już wybranym produktem VPN.

Do testów używaj osobnych kont i oznacz je tak, aby nikt nie pomylił tożsamości testowej z prawdziwym wyjątkiem.

Zapisz granicę jako oczekiwane wyniki

Zacznij od ról, a nie od komponentów: kto potrzebuje której usługi, skąd i z jaką tożsamością. Weź przykładową VPC: jedna grupa potrzebuje środowiska testowego przez HTTPS, inna potrzebuje bazy produkcyjnej, a trzecia, mniejsza grupa administruje samą bramą. Każdy wiersz otrzymuje oczekiwane zezwolenie i oczekiwaną odmowę, w tym sąsiednią usługę i sąsiednie konto, które nie powinny działać. Ta tabela jest kryterium akceptacji i mogą ją przejrzeć osoby, które nie wykonują testów.

Testuj logowanie do bazy danych osobno od ścieżki sieciowej. Osiągalny port TCP nie powinien powodować powodzenia niezatwierdzonego konta bazy danych, a członkostwo w VPN nie powinno tworzyć roli IAM w chmurze ani przyznawać dostępu administracyjnego do API. To trzy niezależne mechanizmy kontroli i zawodzą niezależnie.

Trasa nie jest autoryzacją

Trasa umożliwia ścieżkę; nie przyznaje uprawnienia. Wstrzymywanie trasy to słaby substytut ograniczenia egzekwowanego w miejscu docelowym, ponieważ klient zawsze może dodać własną trasę. Grupa zabezpieczeń, uprawnienie do bazy danych i własna autoryzacja aplikacji pozostają mechanizmami, które decydują. Gdy test nieoczekiwanie się udaje, spójrz najpierw na politykę miejsca docelowego, a nie na tablicę routingu, którą zamierzałeś dać klientowi.

Dlatego testy odmowy celują w stronę serwera: tych wyników nie można zmienić, edytując klienta.

Które źródło kontrola faktycznie widzi?

Adres źródłowy oceniany przez kontrolę zależy od architektury bramy. Brama hostowana na EC2 może przekazywać trasowaną pulę, tłumaczyć ją na własny adres lub po NAT przedstawiać inny adres; zarządzany Client VPN łączy się z podsiecią i działa według własnego modelu. Grupy zabezpieczeń i listy ACL sieci widzą to, co przychodzi po tym przetwarzaniu. Sprawdzanie reguły przy błędnym założeniu o źródle to częsty sposób zbudowania granicy, która wygląda poprawnie i przepuszcza niewłaściwy ruch.

Powiąż każdy wynik z najmniejszym użytecznym zdarzeniem: tożsamość i sesja, zasób, operacja, czas i decyzja. Wywołanie API w CloudTrail, rekord przepływu VPC i dziennik sesji VPN odpowiadają na różne pytania i żaden z nich sam nie jest audytem aplikacji.

Wycofaj tożsamość i przetestuj ją ponownie

Uwzględnij wycofanie w tej samej tabeli. Usuń tożsamość testową, potwierdź, że nowa sesja jest odrzucana, a następnie osobno potwierdź, jak traktowane są istniejące sesje, ponieważ to różne zachowania z różnymi właścicielami. Sprawdź, co się dzieje po restarcie lub wymianie bramy, aby ręcznie dodany wyjątek nie zniknął po cichu ani nie wrócił szerszy. Granica, która trwa tylko do następnego wdrożenia, nie jest granicą.

Nic z tego nie zastępuje pracy nad łatkami, odtwarzaniem lub cyklem życia poświadczeń. Czyni to węższą obietnicę mierzalną: właściwi ludzie docierają do właściwych usług, podczas gdy pobliskie trasy, konta i powierzchnie zarządzania pozostają poza uprawnieniem.

Przechowuj tabelę razem z wdrożeniem i uruchamiaj ją ponownie, gdy brama się zmieni. Testy są tanie; założenia za nimi nie.