Egen drift ger dig operatörsrollen: du väljer programvaran, konfigurationen, uppdateringsschemat och vad din egen tjänst registrerar. Det den inte gör är att ta bort de andra parterna från anslutningen. Ditt åtkomstnät bär fortfarande paketen, din webbhotelleverantör driver fortfarande maskinen, en resolver svarar fortfarande på frågor och ett mål ser fortfarande en förfrågan. Att veta vilka av dem du faktiskt har ändrat är hela övningen.

Steg 1: inventera parterna

Lista varje part i den verkliga driften: din enhet, nätet du ansluter till, VPN-värden, DNS-resolvern och måltjänsten. Notera för var och en vad den kan observera och vilka inställningar du styr.

Den tabellen är mer användbar än något påstående om anonymitet, eftersom den visar var kontrollen faktiskt ändrades. Du styr värdens konfiguration och loggar. Du styr inte åtkomstnätets bild av din anslutning, och du styr inte vad målet registrerar om ditt konto.

För en ändpunkt hemma lämnar täckt trafik normalt hemmets åtkomstanslutning. Den utgångsadress som målet ser är hushållets adress, vilket är ett faktum om topologin och inte ett fel i programvaran. Om det är den adressen du ville ändra kan en hemserver inte göra det. Du behöver en utgång någon annanstans.

Steg 2: skriv ner vad du har vunnit

Du kan granska den driftsatta konfigurationen, bestämma vilka enheter som får ansluta, sätta en diagnostikpolicy och föra de register du väljer. Det är verkliga kontroller när du underhåller dem, och de är det ärliga skälet att driva själv.

De är också villkorliga. En oanvänd standardinställning och en otestad säkerhetskopiering är inte egenskaper som protokollet levererar; de är avsikter. Skriv ner kontrollen tillsammans med det prov som bevisar den, annars räknas den inte.

Steg 3: acceptera underhållslistan

Listan är kort och obeveklig: skydda administratörskontot, skydda serverns nycklar, tilldela och återkalla klienters identiteter, håll säkerhetskopior, ta bort förlorade enheter och behåll en återställningsväg som inte beror på den trasiga tunneln.

Återkallelse förtjänar en egen rad. En enhet som du har tagit bort från konfigurationen men aldrig återkallat har fortfarande giltiga inloggningsuppgifter, och skillnaden syns först när någon använder dem. Testa borttagningen genom att försöka ansluta med det gamla materialet.

Säkerhetskopior behöver samma behandling. Återställ en på en reservvärd och bekräfta att tunneln kommer upp med samma identiteter. En säkerhetskopia du aldrig har återställt är en fil, inte en återställningsplan.

Steg 4: släpp antagandet om anonymitet

Att köra servern gör inte din webbläsare anonym. Webbplatser tar fortfarande emot kontoinformation och kakor, och HTTPS skyddar programdata på sin egen väg oavsett tunneln.

Det finns också en subtilare effekt: en adress som bara du använder kan bli en stabil signal kopplad till din användning. En kommersiell utgång delas med främlingar, vilket är dåligt för integriteten på ett sätt och bra på ett annat. Din egen adress är unik, vilket vänder den avvägningen.

Om målet är att vara svår att korrelera kan egen drift göra det lättare i stället för svårare. Bestäm vilken egenskap du egentligen vill ha innan du lägger en kväll på det. Unikhet är en kostnad, inte en funktion, och den dyker inte upp i de flesta texter om egen drift. Skriv in den i partstabellen från steg 1, och avvägningen blir synlig.

Steg 5: välj det av en angiven anledning

Privat åtkomst till ditt eget nät, kontroll över konfigurationen, ett särskilt routingkrav eller oberoende av en leverantörs policy är alla goda skäl. Skriv ner det som gäller och utforma det prov som skulle visa att det fungerar.

Kontrollera sedan de tråkiga delarna: är värden patchad, är gamla nycklar borta, stämmer lagringen med det du dokumenterade, och kan du återställa tjänsten efter ett fel? De fyra svaren beskriver förtroendemodellen mycket bättre än protokollets namn.

Steg 6: planera utgången

Bestäm i förväg hur du skulle flytta bort från värden: var konfigurationen bor, hur klientprofiler utfärdas på nytt och vad som händer med de register du har sparat. En självdriven tjänst utan utträdesplan blir ett beroende du inte kan ta bort.

Den AWS delade ansvarsmodell är en användbar mall även utanför AWS, eftersom den tvingar fram samma fråga: vilket lager är ditt och vilket tillhör någon annan. Besvara den för varje part i steg 1, och förtroendemodellen slutar vara en slogan.

Relaterade artiklar