Staging er ikke produksjon: gi det sin egen tilgangsgrense
En staging-etikett avgjør ikke hvem som når appen eller hva den kan røre ved. Gå gjennom publikum, data, påloggingsdetaljer og admin-flater før du publiserer den.
Staging ser ut som et testsystem til du legger merke til den kopierte produksjonsdatabasen, den levende e-postlegitimasjonen og betalingsnøkkelen i miljøet. På det punktet slutter etiketten på fanen å bety noe, og det egentlige spørsmålet er hva denne utrullingen kan nå og hvem som kan nå den. En VPN i fordøren svarer ikke på det spørsmålet, fordi den begrenser én vei inn i systemet og ikke sier noe om hva systemet kan gjøre på vei ut. Start med publikum og arbeid utover.
Start med publikum, ikke URL-en
Tre publikumer gir tre ulike design. Et privat ingeniørmiljø trenger identitet og en rute; en kundeaksepttest trenger kontoer som representerer kunder; en offentlig demonstrasjon trenger bevisst eksponering med egne kontroller. Å skrive ned publikummet først hindrer den vanlige driften der en forhåndsvisnings-URL stille blir permanent. Alt annet i gjennomgangen avhenger av det svaret.
Hvis ingen kan navngi publikummet, behandle det som det første funnet og ikke som et dokumentasjonshull.
Gå gjennom fordøren og flatene bak den
Løs opp navnene før du stoler på URL-en du fikk, og be deretter om de administrative stiene direkte.
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/adminEkstra poster avslører ofte en direkte opprinnelsesadresse som omgår CDN-en eller VPN-inngangen, noe som gjør den tiltenkte kontrollen valgfri. En omdirigering forteller deg hvor applikasjonen tror den bor, og et uventet skjema eller vertsnavn fortjener oppfølging. Å sondere en sannsynlig admin-rute bør gi en avvisning, ikke en side. En 200 på en uautentisert administrativ sti er funnet hele gjennomgangen lette etter.
Sjekk hva miljøet kan gjøre, ikke bare hva det viser
En side som krever innlogging leveres fortsatt med backend-autoritet. Spør hvilken identitet arbeidsbelastningen kjører som, og les deretter retningslinjene som er knyttet til den.
aws sts get-caller-identityDet kallet rapporterer kontoen og principalen som miljøet faktisk bruker, og det er utgangspunktet for hvert påfølgende tillatelsesspørsmål. Derfra kan du sjekke om identiteten kan sende e-post, flytte penger, lese produksjonshemmeligheter eller skrive produksjonsdata. Erstatt delte produksjonsopplysninger med avgrensede staging-identiteter, og foretrekk leverandørens sandkasser der de finnes. En testkonto som kan belaste et ekte kort, er et produksjonssystem med et annet vertsnavn.
Behold grensen etter at gjennomgangen er over
Et miljø sikres ikke av én revisjon; det sikres av eierskap som overlever personalendringer. Tilordne hvem som fjerner tilgang, nullstiller testdata og tar utrullingen ut av drift, og gi forhåndsvisningen en utløpsdato som noen må fornye. Isolasjon hjelper bare så lenge det isolerte vedlikeholdes. Sjekk de samme stiene igjen etter neste utgivelse, fordi et funksjonsflagg eller en ny integrasjon er nettopp hvordan en avvist rute blir en åpen.
Godta designet med én tillatt arbeidsflyt og én avvist. Hvis begge oppfører seg som dokumentert, finnes grensen; hvis bare den lykkelige veien ble testet, er den et håp.