A staging nem produkció: adj neki saját hozzáférési határt
A staging címke nem dönti el, ki érheti el az alkalmazást, és mit érinthet. Nézd át a közönséget, az adatokat, a hitelesítő adatokat és az admin felületeket, mielőtt közzéteszed.
A staging tesztrendszernek tűnik, amíg észre nem veszed a másolt termelési adatbázist, az élő levél-hitelesítő adatot és a fizetési kulcsot a környezetében. Ezen a ponton a lapon lévő címke jelentéktelenné válik, és az igazi kérdés az, hogy ez a telepítés mit érhet el, és ki érheti el. Egy előtér-VPN nem válaszol erre a kérdésre, mert egy utat korlátoz a rendszerbe, és semmit nem mond arról, mit tehet a rendszer kifelé menet. Kezdd a közönséggel, és haladj kifelé.
A közönséggel kezdd, ne az URL-lel
Három közönség három különböző tervet ad. Egy privát mérnöki környezetnek identitásra és útvonalra van szüksége; egy ügyfél-elfogadási tesztnek az ügyfeleket képviselő fiókokra; egy nyilvános bemutatónak szándékos kitettségre, saját kontrollokkal. A közönség első leírása megakadályozza a szokásos sodródást, amikor egy előnézeti URL csendben állandóvá válik. Az átvizsgálás minden más eleme ettől a választól függ.
Ha senki nem tudja megnevezni a közönséget, kezeld ezt első megállapításként, nem dokumentációs hiányosságként.
Menj végig az előtér-ajtón és a mögötte lévő felületeken
Oldd fel a neveket, mielőtt megbízol a kapott URL-ben, majd kérdezd meg közvetlenül az adminisztratív útvonalakat.
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/adminA további rekordok gyakran felfednek egy közvetlen eredetű címet, amely megkerüli a CDN-t vagy a VPN-belépést, ami a szándékolt kontrollt választhatóvá teszi. Egy átirányítás megmondja, hol hiszi az alkalmazás, hogy él, és egy váratlan séma vagy hosztnév utánajárást érdemel. Egy valószínű admin útvonal kipróbálásának elutasítást kell eredményeznie, nem oldalt. A 200 egy hitelesítetlen adminisztratív útvonalon az a megállapítás, amelyet az egész átvizsgálás keresett.
Ellenőrizd, mit tud a környezet, ne csak azt, mit mutat
Egy bejelentkezést igénylő oldal továbbra is backend jogosultsággal érkezik. Kérdezd meg, milyen identitásként fut a terhelés, majd olvasd el a hozzá csatolt házirendeket.
aws sts get-caller-identityEz a hívás azt a fiókot és principált jelenti, amelyet a környezet valójában használ, és ez minden további engedélykérdés kiindulópontja. Innen ellenőrizd, hogy az identitás tud-e levelet küldeni, pénzt mozgatni, termelési titkokat olvasni vagy termelési adatot írni. Cseréld le a megosztott termelési hitelesítő adatokat szűk staging identitásokra, és részesítsd előnyben a szállítói homokozókat, ahol léteznek. Egy tesztfiók, amely valódi kártyát terhelhet, egy másik hosztnevű termelési rendszer.
Tartsd meg a határt az átvizsgálás után
Egy környezetet nem egyetlen audit tesz biztonságossá; az teszi azzá, hogy a tulajdonviszony túléli a személyzeti változásokat. Jelöld ki, ki vonja meg a hozzáférést, állítja vissza a tesztadatokat és vonja ki a telepítést a használatból, és adj az előnézetnek lejáratot, amelyet valakinek meg kell újítania. Az elkülönítés csak addig segít, amíg az elkülönített dolgot karbantartják. A következő kiadás után ellenőrizd újra ugyanezeket az útvonalakat, mert egy funkciózászló vagy egy új integráció pontosan így tesz egy elutasított útvonalat nyitottá.
Fogadd el a tervet egy engedélyezett és egy elutasított munkafolyamattal. Ha mindkettő a dokumentált módon viselkedik, a határ létezik; ha csak a boldog utat tesztelted, az remény.