Ideiglenes IP-engedélylistás hivatkozások: mit engedélyez valójában az engedély

Egy kattintás ideiglenes tűzfalszabállyá alakítása kényelmes, és egyben olyan engedélyezési rendszert is épít, amely eldönti, ki érhet el egy szolgáltatást. Címet ad ki, nem személyt, és ez a különbség abban a pillanatban számít, amikor két ember közös NAT-on osztozik. Határolja be az engedély hatókörét, erősítse meg szándékosan, és adjon értelmet a lejáratnak, mielőtt a hivatkozás felépül. Az előtte álló döntés az, hova kerüljön a határ, nem az, hogy egyáltalán léteznie kell-e.

Döntse el, melyik kérdésre válaszol az engedély

Kezdje a követelménnyel. Ha egy megnevezett személynek el kell érnie a szolgáltatást, és az alkalmazás már hitelesíti ezt a személyt, egy hitelesített átjáró a kényszerítési ponton tartja a személyazonosságot, és egyáltalán nincs szüksége címengedélyre. Ha a cél egy build-ügynök, egy adminisztratív ugróport vagy olyan készülék, amely nem tud részt venni a felhasználói bejelentkezésben, a szűk hatókörű címengedély lehet az egyetlen gyakorlati ellenőrzés.

Ha egy felhasználók felé forduló alkalmazásnál címengedélyt választunk, az igazi engedélyezési probléma máshova kerül, és a portál örökli a felelősséget egy olyan résért, amelyet soha nem zárt be.

Határolja be a kérést a kiszolgálón

A böngésző nem választhatja ki a célt, a portot vagy az előtagot. A portál a saját nyilvántartásából oldja fel a szolgáltatást, és kiszolgálóoldali teszttel ellenőrzi a jogosultságot, ami ugyanaz az elv, amelyet az OWASP engedélyezési útmutatója minden kérésre alkalmaz. A cím származtatása szintén a védett határhoz tartozik: amikor egy fordított proxy jelenti az ügyfél címét, csak a beállított proxy-láncot és annak dokumentált fejléc-kezelését fogadja el. A látogató által biztosított továbbítási fejléc állítás a származásról, nem bizonyíték rá.

Ezután ellenőrizze, hogy a portál és a szolgáltatás ugyanazt a forrást látja-e. A megosztott alagút, egy proxyugrás és az IPv4 szemben az IPv6-tal két különböző címet adhat két célnak, ezért az egyik úton aktivált engedély nem feltétlenül fedi le a következő kérést.

Mutasd meg az engedélyt a telepítés előtt

Egy hivatkozás megnyitásának meg kell jelenítenie a javasolt szolgáltatást, a megfigyelt forrást és az időtartamot, és még nem szabad semmit megváltoztatnia. Ez az egyetlen lépés alakítja az e-mailben kapott hivatkozást műveletből javaslattá, és megakadályozza, hogy egy előnézeti bot vagy egy levélszkennelő pusztán a letöltésével hozzáférést adjon.

A megerősítésnek állapotot változtató kérésnek kell lennie a szokásos webhelyek közötti és származási védelemmel. A tokennek egyszer használatosnak kell lennie, és atomikusan el kell használódnia abban a pillanatban, amikor a szabály telepítésre kerül, a rekordnak pedig rögzítenie kell a tulajdonost, a szolgáltatást, a címet, az engedély azonosítóját és a lejáratot anélkül, hogy valaha naplózná a nyers tokent.

A token kézbesítése ugyanolyan gondosságot érdemel, mint maga a szabály. Egy lejárt vagy már elhasznált hivatkozás, amely mégis szabályt hoz létre, egy második ajtó ugyanazzal a kulccsal.

A cím megosztott, még amíg az engedély él

Az irodai NAT, a szolgáltatói NAT és a közös VPN-kimenet mind több embert tesz egy cím mögé. Ennek a címnek az engedélyezése mindenkit engedélyez mögötte — amennyiben a szolgáltatás következő határáról van szó —, miközben semmit nem bizonyít arról, ki birtokolja azt a fiókot, amelyet a szolgáltatás vár.

A szabály eltávolítása sem univerzális megszakítás. A létrejött kapcsolatok, a gyorsítótárazott alkalmazástokenek és a hosszú életű munkamenetek percekkel vagy sokkal tovább túlélhetik a szabályt, ezért a választott élettartamnak azt kell tükröznie, mit tesz a szolgáltatás az engedélyezés után, nem csak azt, meddig létezik a szabály.

Teszteljen négy esetet és mindkét címcsaládot

Egy engedély csak annyit ér, mint a négy eset, amelyet túlél: egy új engedélyezett kérés, egy nem jóváhagyott kérelmező, ugyanazon hivatkozás ismétlése és ugyanaz a kérés a lejárat után.

Ezután tesztelje mindkét családot külön, mert a szolgáltatás által megfigyelt forráscím eltérhet közöttük.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

A hasznos eredmény egy ideiglenes, auditálható engedélyezési döntés a szokásos felhasználói engedélyezés alatt, nem pedig egy állandó nyílás, amely az elsőként kattintó nevét viseli.