Engedélyezhet-e egy fizetős VPN munkameneteket a fiókod nélkül?
Nem összekapcsolható tokenek szétválaszthatják a jogosultság ellenőrzését magától a munkamenettől. A kibocsátás és a beváltás kialakítása számít, nem a bejelentkező képernyő felirata.
Egy alagútért fizetni nem kell azt jelentse, hogy minden kapcsolatnál felmutatod a számlázási személyazonosságot. Egy terv egyszer ellenőrizheti a jogosultságot, kriptográfiai tokeneket adhat az ügyfélnek, és később hagyhatja, hogy az átjáró elfogadjon egy tokent anélkül, hogy látná a mögötte lévő fiókot. Hogy ez valóban elrejt-e valamit, a kibocsátási és beváltási döntésektől függ, ezért négyszakaszos specifikációs gyakorlatként kezeld, ne kapcsolóként, amit bekapcsolsz.
Válaszd szét a vásárlás lépését a munkamenet lépésétől
Az RFC 9576 Privacy Pass architektúrája adja a szókincset: ügyfél, igazoló, kibocsátó és eredet. Az ügyfél igazol valamilyen tulajdonságot a kibocsátónak, és tokeneket kap; később bemutat egyet az eredetnek, amely eldönti, kiszolgálja-e. VPN-re alkalmazva az igazolt tulajdonság lehet egyetlen hozzáférési egység.
A számlázás továbbra is látja, amire a saját folyamatának szüksége van, és ezt senki nem állítja másként. A szűkebb cél az, hogy a későbbi beváltás ne legyen összekapcsolható azzal a vásárlással, amely a tokent létrehozta. Ez konkrét, tesztelhető tulajdonság, és éppen ezt érdemes leírni.
Egy véletlenszerűnek tűnő hordozókarakterlánc ezt nem nyújtja. Ha a kibocsátó az értéket egy ügyfélrekord mellett tárolja, és az átjáró kérheti ezt a hozzárendelést, a két interakciót adatbázis köti össze, nem kriptográfia. A konstrukciónak alkalmatlanná kell tennie a kibocsátót a kérdés megválaszolására, a telepítésnek pedig meg kell akadályoznia, hogy a kibocsátó és az átjáró egyesítse a nézeteit.
Határozd meg, mit engedélyez egy token
Az «egy token hozzáférést vásárol» üzemeltetési szempontból szinte semmire nem válaszol. Az egység egyetlen kapcsolat, időkeret vagy adatmennyiség? Folytathatja-e ugyanazt az engedélyt az az ügyfél, amely elvesztette a válaszát? Mi történik, ha egy eszköz hálózatváltás közben újra csatlakozik? Ezek a válaszok döntik el, használható-e a terv, és mindegyiknek van adatvédelmi következménye.
| Reuse rule | What it buys | What it leaks |
|---|---|---|
| Single use per connection | Strongest unlinkability between sessions | Frequent reissuance, more purchase-to-use timing pairs |
| Bounded time window | Fewer tokens, reconnects work | Activity inside the window is linkable |
| Long-lived grant | Operationally simple | Behaves like an account reference with extra steps |
Válassz egyet szándékosan, és írd mellé a hiba esetén tanúsított viselkedést. Az az ügyfél, amely időtúllépés után új jogosultsággal próbálkozik, még egy egységet fogyaszt, ami egyszerre számlázási meglepetés és adatvédelmi jelzés.
Írd le az újrafelhasználás és a visszavonás szabályát
A visszavonás az a pont, ahol az anonim tervek általában megszegik a saját ígéretüket. Az előfizetés lemondása és a már kiadott tokenek érvénytelenítése külön művelet, és az az átjáró, amely csendben fiókkeresést végez a döntéshez, ezen a ponton már nem anonim.
Válassz egymáshoz illő lejáratot, kibocsátási korlátot és visszavonási történetet. Ezután vizsgáld át az átjáró saját nyilvántartásait olyan mezők után, amelyek visszahozzák az eltávolított kapcsolatot.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
Ez a keresés token- vagy fiókmezőket tartalmazó naplófájlokat listáz, és ez az első hely, ahol egy gondos terv a gyakorlatban kiszivárog. Az a munkamenet-rekord, amely a token értékét egy fiókazonosító mellett tárolja, tönkreteszi az egész konstrukciót, és általában egy olyan hibakeresési változtatáson keresztül érkezik, amelyet senki nem nézett át újra.
Azt is határozd meg, mit tart meg az átjáró a munkamenet vége után. Az időtartam, a bájtok és a végpont hasznos az üzemeltetésnek, és mindegyik egy darab abból a kirakósból, amelyet egy megfigyelő szeretne. Tartsd rövidnek a megőrzési időt és rövidnek a mezőlistát, majd vizsgáld át mindkettőt, amikor egy hibakeresési változtatás oszlopot ad hozzá. Senki nem vesz észre egy új naplómezőt, amíg egy évig ott nem volt.
Fogalmazd meg az állítást, majd a megmaradó megfigyeléseket
Írd le az adatvédelmi állítást egy mondatban, a feltevéseivel együtt: melyik félnek kell képtelennek lennie mely kontextusok összekapcsolására, és mi történik, ha a kibocsátó és az átjáró összeveti a feljegyzéseit. Az a terv, amely túléli ezt a mondatot, áttekinthető; az, amelyet csak «nulla tudásként» írnak le, nem.
Ezután sorold fel, mi marad látható minden körülmények között. A forráscímek, a kapcsolódási idők, a csomagméretek és az az egyszerű tény, hogy a vásárlás nem sokkal az egyetlen új kapcsolat megjelenése előtt történt, mind a kriptográfián kívül esnek. Egyetlen ügyfél, aki egy egységet vásárol és egyszer csatlakozik, pusztán az időzítés alapján összekapcsolható, és ezen semmilyen tokenterv nem változtat.
Az őszinte eredmény szűkebb kapcsolat a fiók és a használat között, nem láthatatlan munkamenet. Még mindig érdemes megépíteni, feltéve, hogy a dokumentáció ezt mondja, és az üzemeltetési nyilvántartások megfelelnek az állításnak.