Miért nem kezeskedhet egy VPN-könyvtár a mögötte álló csomópontért
Egy bejegyzés egy kapcsolatot ír le és azt a könyvtárat, amely közzétette. A gyűjtés és a megőrzés az üzemeltetőé, aki más fél is lehet.
Azok a könyvtárbejegyzések, amelyek gépnevet, országot és protokollkészletet sorolnak fel, a kapcsolhatóságról adnak bizonyítékot, nem arról, hogy mit rögzít a másik oldali gép. Az itt számító döntés nem az, hogy általában bízni kell-e a listákban. Hanem az, hogy melyik fél van abban a helyzetben, hogy megválaszolja a kérdést, amelyet valóban feltesz.
Négy fél egy bejegyzés mögött
Válassza szét a szerepeket, mielőtt bármilyen ígéretet elolvas. A könyvtár teszi közzé a bejegyzést, a szoftverprojekt szállítja a protokoll megvalósítását, a tárhelyszolgáltató szállítja a gépet és a hálózatot, a csomópont üzemeltetője pedig beállítja a szolgáltatást. A négy közül bármelyik lehet más szervezet, és mindegyik csak a saját részéért tud szólni.
Ez a felosztás magyarázza, miért lehet egy állítás igaz és mégis hasznavehetetlen. Az a fejlesztő, aki dokumentálja, hogy a protokoll nem naplózza a tartalmat, semmit nem mond arról az üzemeltetőről, aki részletes kapcsolatnaplózást kapcsolt be egy relén. Mindkét állítás megfér egymás mellett ellentmondás nélkül. Éppen ezért kell a kérdést megnevezett félhez intézni.
Egyes szolgáltatások maguk üzemeltetik a végpontjaikat, és ilyenkor a bejegyzés és a szabályzat ugyanattól a féltől származik. Ez erősebb pozíció, de még mindig bizonyítani kell, nem az oldal formátumából kikövetkeztetni. Kérje a nyilatkozatot, és ellenőrizze, hogy megnevezi-e azt a szolgáltatást, amelyre a bejegyzés mutat.
Kérje az állításhoz illő dokumentumot
A gyűjtésre vonatkozó állításhoz olyan dokumentum kell, amely megnevezi a rendszert, az adatkategóriát és az időszakot. A megőrzésre vonatkozó állításhoz szám és hatókör kell. A függetlenségre vonatkozó állításhoz annak leírása kell, ki miért felel, nem egy melléknév.
| Field in a listing | What it evidences | What it cannot evidence |
|---|---|---|
| Hostname or address | A reachable endpoint existed when the entry was published | Who runs it, or what it stores |
| Protocols offered | Which client configurations should interoperate | Whether logging was disabled on that deployment |
| Country | Where the endpoint claims to be located | Which legal process could reach the operator |
| Availability score | How often the entry answered a probe | Anything about data handling |
Az önkéntes projektek gyakran a legvilágosabb példák, mert egyesek kifejezett naplózási követelményeket tesznek közzé az általuk elfogadott csomópontokra. Az a dokumentum elsődleges bizonyíték a projekt szabályairól, és továbbra sem bizonyíték egy olyan egyedi üzemeltetőről, aki figyelmen kívül hagyta őket.
Az auditok ugyanezt a logikát követik más léptékben. Egy jelentés, amely egy adott telepítést egy adott időablakban vizsgált, azon a határon belül hasznos. Ha ugyanazon szoftver minden független példányára kiterjesztik, olyan garanciává válik, amelyet senki nem adott ki. Olvassa el a hatókörről szóló bekezdést a következtetés előtt.
Amikor egy szállító adatvédelmi nyilatkozata a saját szolgáltatását fedi, olvassa úgy, mint annak a szállítónak a nyilatkozatát a saját rendszereiről. Ha ezt egy harmadik fél reléjének leírására használja fel újra, az kategóriahiba, akkor is, ha a protokoll azonos.
Döntse el, mit vásárol az egyes lehetőségekkel
Egy nyilvános csomópont elérhetőséget és változatosságot vásárol az elszámoltathatóság árán. Egy üzemeltető, aki semmivel nem tartozik Önnek, eltűnhet, módosíthatja a beállításokat vagy értesítés nélkül megőrizheti a naplókat, és az Ön kiútja csak ennyi: végpontok váltása. Ez az alku bizonyos feladatoknál elfogadható, másoknál nem.
Egy fizetett szolgáltatás olyan ellenfelet vásárol, akinek közzétett szabályzata van, és van mit veszítenie. Nem vásárol technikai garanciát, és nem szünteti meg a szabályzat elolvasásának szükségét, de egy megnevezett szervezet megőrzési nyilatkozattal könnyebben értékelhető, mint egy névtelen relé.
Az a döntési szabály, amely mindkét esetben megállja a helyét, hogy a bizonyítékot a kockázathoz kell igazítani. Ha a feladat elvisel egy váltakozó végpontot, a könyvtár hatékony eszköz. Ha egy konkrét adatkezelési ígérettől függ, csak az a fél releváns, aki ezt az ígéretet meg tudja adni, és a könyvtár útvonalkényelem, nem biztosíték.
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'A fenti egyetlen parancsot érdemes futtatni, mert tisztán szétválaszt két kérdést. Megmutatja azt a címet, amelyet a forgalma valóban használt, ami kapcsolhatósági tény, és semmit nem mond arról, hogy annak a címnek az üzemeltetője mit tett a kapcsolat metaadataival.
Tartsa külön az ügyféloldali kérdéseket
Az üzemeltető szabályzata az egyik réteg, és az, hogy mi történik az alagúton belül, a másik. A céloldali HTTPS, a munkamenetek kezelése a böngészőben és a bejelentkezéshez használt fiók erőssége az Ön ellenőrzése marad, és egy megengedő relé nem gyengíti ezeket, ahogy egy kiváló sem erősíti.
Ez a szétválasztás két gyakori hibát előz meg. Az egyik, hogy egy szigorú üzemeltetői szabályzatot a HTTPS kihagyásának okaként tekintünk, a másik pedig, hogy egy működő HTTPS-kapcsolatot annak okaként tekintünk, hogy figyelmen kívül hagyjuk, ki üzemelteti a relét. Mindkét hiba egy rétegbe olvaszt két réteget, majd a rosszról vitatkozik.
Egy rövid írásos értékelés mindkettőt kezeli. Nevezze meg a felet, amelyik az egyes ígéreteket adja, csatolja a támogató dokumentumot, és jegyezze fel a dátumot. Ezután döntse el, hogy a feladatnak az erősebb állításra van szüksége, vagy csak egy működő útvonalra.
A bejegyzés akkor tette meg a dolgát, amikor megmondta, hová lehet csatlakozni. A kérdés többi része azt illeti, aki azt a végpontot üzemelteti, és az őszinte válasz gyakran az, hogy ezt nem tudhatja, és ennek megfelelően kell választania.