En brandvägg mellan portar är inte en värdgräns

Webbplatsen svarar på 443, VPN svarar på 1194, brandväggen släpper igenom exakt de två, och granskningen går igenom. Ingenting i den sekvensen frågade vad webbarbetaren kan läsa eller vilka filer den kan skriva över. En komprometterad arbetare behöver ingen öppen port om den kan nå en styr-socket eller en skrivbar konfigurationskatalog. Gränsen är befogenhet, och lyssnare är bara den del som är lätt att se.

Ett separat tjänstenamn är en etikett; en separat identitet är en säkerhetsegenskap.

Räkna arbetarens befogenhet, inte portarna

Börja med körtidsanvändaren, dess grupper, dess förmågor och dess filsystemsvy. Ett tjänstekonto som råkar tillhöra en VPN-grupp kan läsa nyckelmaterial utan att någon port är öppen. Skrivbara monteringar är den andra halvan: uppladdningar och cachar bör ligga långt från policyfiler och hemligheter, och en onödigt delad skrivbar katalog förstör snygg namngivning. Kontrollera processen som skulle utföra operationen, eftersom en privilegierad förälder och oprivilegierade arbetare inte delar en enda befogenhet.

Att en VPN-nyckel är läsbar vid daemonens start betyder inte att webbarbetaren behöver den. Separera läsningen som daemonen gör från åtkomsten som applikationen får.

Sockets som ger mer än de verkar

Vissa slutpunkter är administrativa API:er i kostym av ett metrikflöde. VPN:ets administrationsgränssnitt kan ändra sessioner, koppla från klienter och läsa tillstånd. En runtime-socket för containrar är ännu bredare: åtkomst till den är i praktiken värdkontroll, långt bortom vad en webbapplikation behöver. Ingen av dem hör till monteringsuppsättningen för en vanlig applikation, och ingen av dem dyker upp när du räknar lyssnande portar.

Att binda en administrationslyssnare till en lokal adress är en början, inte en fullständig begränsning, eftersom varje ingångsväg till den adressen fortfarande spelar roll. Tillåt bara de avsedda källorna och gränssnitten.

Containrar delar en kärna

Containrar lägger till gränser för process, filsystem och nätverk, och de delar en kärna med värden. Det gör val av förmågor, värdmonteringar och daemonåtkomst avgörande: att montera värdhemligheter eller ge privilegierad runtime-kontroll suddar ut gränsen som containeretiketten antyder. Separata VM:er ger visserligen separata gästkärnor, medan hypervisorn, administrativa identiteter, lagring och säkerhetskopior förblir delade. Välj den gräns vars konfiguration och uppdateringar har en namngiven ägare.

En mer invecklad ordning som ingen underhåller är sämre än en enkel som faktiskt granskas.

Testa avvisningen, sedan tjänsten

Använd godkända kontroller i arbetarens verkliga sammanhang för att bekräfta att den inte kan ändra VPN-policy, läsa onödiga hemligheter eller röra administrationsgränssnittet. En lyckad läsning som administratör testar ingenting om den avvisningen. Bekräfta sedan webbplatsen, en vanlig tillåten VPN-operation och vad som händer med var och en vid omstart. Behåll en återställningsväg som inte beror på att VPN:et repareras, så att ett misstag förblir åtgärdbart.

Båda rollerna delar fortfarande CPU, minne, upplänkskapacitet och underhållshändelser. Dessa delade resurser hör hemma i planen även när befogenhetsgränsen är ren.

Skriv ned vad varje process kan göra, vad som fallerar om den stannar, och vilken gräns som förblir delad. Portantal är inte den redogörelsen.