A felhős VPN-ed továbbra is a tárhelyszolgáltatótól függ

Telepítetted az operációs rendszert, megerősítetted a szolgáltatást és nálad vannak a kulcsok, és kezd úgy tűnni, hogy a szerver a tiéd. A tiéd úgy, ahogy egy bérelt lakás a tiéd: a zár az ellenőrzésed alatt van, az épület nem. A hipervizor, az instance előtti hálózat és a fiók, amely mindent újraépíthet, valaki másé. Ez a különbség dönti el, mit kell lefednie egy helyreállítási tervnek, és ez az a rész, amit az önhosztolás a legkevésbé változtat meg.

A fiók az igazi vezérlési sík

Egy tárhelyfiók kezeli a virtuális gépet, annak lemezeit, pillanatképeit, nyilvános címeit és hálózati szabályait. Mindegyik módosítható anélkül, hogy egyáltalán bejelentkeznél a vendégbe, ami a fiókot a legtöbb VPN-útmutató által leírt fenyegetésmodellen kívülre helyezi. Egy tökéletes tunelkonfiguráció túlél egy fiókműveletet, amely lecserél egy lemezt.

Védd ezt a fiókot külön eszközként: független hitelesítő adatok, hardverrel támogatott második tényezők és olyan auditnapló, amelyet valaki tényleg olvas. Ugyanazon jelszókezelő-bejegyzés megosztása a VPN-szolgáltatással az a hiba, amely minden más ellenőrzést értelmetlenné tesz.

A szolgáltató feladatmegosztását a konkrét termékre olvasd, ne a felhőre általában. A megosztott felelősség modellje hasznos példa arra, hogyan oszlanak meg a rétegek, és más szolgáltatók a saját határaikat írják le ahelyett, hogy azt örökölnék. Azt keresed, mely hibákat kell neked javítanod, és melyeket tudsz csak jelenteni.

Infrastruktúra-események, amelyeket nem adminisztrálhatsz

Az élő migráció, a gazdagép karbantartása, a fizikai csomópont hardverhibája és egy kapacitási esemény mind olyan dolog, amelyet a szolgáltató a saját menetrendje szerint kezel. Láthatsz újraindítást, rövid csomagvesztést vagy címváltozást, és nem fogod látni az okot. Az a terv, amely az instance-t fix pontnak tekinti, mindegyiket VPN-hibaként értelmezi. A helyes lépés az, hogy a szolgáltatás tűrje az eltűnő instance-t, ahelyett hogy olyan okot vizsgálnál, amelyet soha nem mutatnak meg.

A biztonsági mentések ehhez a réteghez tartoznak, nem a tunelhez. Tartsd a szerverkonfigurációt, az identitásokat, a címtervet és az engedélyezett útvonalakat olyan helyen, amely nem függ az instance elérhetőségétől, és igazold, hogy a másolat az eredeti lemez nélkül visszaállítható.

A cím viselkedése saját ellenőrzést érdemel. Az, hogy egy nyilvános cím túlél-e egy leállítást, cserét vagy törlést, attól függ, hogyan osztották ki, és a három művelet nem felcserélhető. Írd le, melyikre támaszkodsz, mielőtt egy incidens sürgőssé teszi a kérdést.

Ellenőrizd, mi éli túl az újraépítést

Építsd ki a helyreállítási utat, amíg minden működik. Azonosítsd a szolgáltató által kínált konzolt vagy sávon kívüli hozzáférést, igazold, hogy a tunel nélkül is eléred, és tárold a hitelesítő adatokat olyan helyen, ahonnan egy tönkrement laptop vagy egy elveszett telefon nem viszi el őket. Ha egy helyi tűzfalváltozás blokkolja a tunelt, az a konzol az egyetlen út vissza.

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

A metaadat-szolgáltatás olyan kérdésekre válaszol az instance-ról, amelyeket a vendég másképp nem lát, és pontos útvonalai szolgáltatónként és platformonként eltérnek, ezért ellenőrizd őket a futtatott termék dokumentációjában. Utána hajts végre egy ellenőrzött újraépítést egy teszt-instance-on, és mérd meg az időt. Egy helyreállítási eljárás, amelyet senki nem hajtott végre, csak hipotézis.

Figyeld meg, mit tett az újraépítés a címmel, a gazdagépkulcsokkal, a lemez identitásával és mindennel, amit az ügyfelek rögzítenek. Azok az ügyfelek, amelyek gyorsítótáraztak egy gazdagépkulcsot, panaszkodni fognak az újraépítés után, és ez a panasz helyes viselkedés, nem elfojtandó hiba.

Döntsd el, mit változtat valójában az önhosztolás

A saját VPN futtatása a bizalmat a VPN-üzemeltetőtől egy tárhelyszolgáltatóra és rád helyezi át. Ez valódi változás, és nem ugyanaz, mint egy harmadik fél eltávolítása. Ha a cél az volt, hogy egy kereskedelmi VPN ne figyelhesse a forgalmat, a szolgáltató továbbra is figyelheti az instance hálózatát, lemezét és számlázási adatait.

A saját naplóid a szoftveredet írják le, és nem írnak le minden infrastruktúra-rekordot, amelyet a szolgáltató őriz. Fordítva is igaz: az infrastruktúra láthatósága nem bizonyítja, mit tart meg egy szolgáltató. Mindkét kérdéshez a szolgáltató szabályzata és a te konfigurációd kell, és egyik sem válaszol a másikra.

Írd le a választ munkamegosztásként: melyik réteg hibázott, ki tudja megjavítani, és mennyi ideig tart a javítás. Az önhosztolás megváltoztatja, kiben bízol, és a gyakorlat hasznos része pontosan tudni, melyik rétegért bízol bennük.