Staging är inte produktion: ge det sin egen åtkomstgräns

Staging ser ut som ett testsystem tills du lägger märke till den kopierade produktionsdatabasen, den levande e-postuppgiften och betalningsnyckeln i dess miljö. Vid den punkten slutar etiketten på fliken att spela roll och den verkliga frågan är vad denna driftsättning kan nå och vem som kan nå den. En VPN vid ytterdörren svarar inte på den frågan, eftersom den begränsar en väg in i systemet och inte säger något om vad systemet kan göra på vägen ut. Börja med publiken och arbeta utåt.

Börja med publiken, inte med URL:en

Tre publiker ger tre olika designer. En privat ingenjörsmiljö behöver identitet och en rutt; ett kundacceptanstest behöver konton som representerar kunder; en offentlig demonstration behöver avsiktlig exponering med egna kontroller. Att skriva ned publiken först förhindrar den vanliga driften där en förhandsgransknings-URL tyst blir permanent. Allt annat i granskningen beror på det svaret.

Om ingen kan namnge publiken, behandla det som det första fyndet och inte som en dokumentationslucka.

Gå igenom ytterdörren och ytorna bakom den

Lös upp namnen innan du litar på URL:en du fick, och be sedan direkt om de administrativa vägarna.

dig +short staging.example.com
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/admin

Extra poster avslöjar ofta en direkt ursprungsadress som kringgår CDN:en eller VPN-ingången, vilket gör den avsedda kontrollen valfri. En omdirigering berättar var applikationen tror att den bor, och ett oväntat schema eller värdnamn förtjänar en uppföljning. Att sondera en sannolik adminväg borde ge en avvisning, inte en sida. En 200 på en oautentiserad administrativ väg är fyndet som hela granskningen letade efter.

Kontrollera vad miljön kan göra, inte bara vad den visar

En sida som kräver inloggning levereras ändå med backend-behörighet. Fråga vilken identitet arbetsbelastningen körs som och läs sedan policyerna som är kopplade till den.

aws sts get-caller-identity

Det anropet rapporterar det konto och den principal som miljön faktiskt använder, och det är utgångspunkten för varje följande behörighetsfråga. Därifrån kontrollerar du om identiteten kan skicka e-post, flytta pengar, läsa produktionshemligheter eller skriva produktionsdata. Ersätt delade produktionsuppgifter med avgränsade stagingidentiteter och föredra leverantörens sandlådor där de finns. Ett testkonto som kan debitera ett riktigt kort är ett produktionssystem med ett annat värdnamn.

Behåll gränsen efter att granskningen är slut

En miljö säkras inte av en enda revision; den säkras av ägarskap som överlever personalbyten. Tilldela vem som tar bort åtkomst, återställer testdata och avvecklar driftsättningen, och ge förhandsgranskningen ett utgångsdatum som någon måste förnya. Isolering hjälper bara så länge det isolerade underhålls. Kontrollera samma vägar igen efter nästa release, eftersom en funktionsflagga eller en ny integration är precis hur en nekad rutt blir en öppen.

Acceptera designen med ett tillåtet arbetsflöde och ett nekat. Om båda beter sig som dokumenterat finns gränsen; om bara den lyckliga vägen testades är det ett hopp.