En firewall mellem porte er ikke en værtsgrænse
To åbne porte og én firewallregel udelader det, der betyder noget: hvad webarbejderen kan læse og styre. Test afvisningen, ikke bare tjenesten.
Webstedet svarer på 443, VPN svarer på 1194, firewallen tillader præcis de to, og gennemgangen består. Intet i den rækkefølge spurgte, hvad webarbejderen kan læse, eller hvilke filer den kan genskrive. En kompromitteret arbejder har ikke brug for en åben port, hvis den kan nå en styresocket eller en skrivbar konfigurationsmappe. Grænsen er myndighed, og lyttere er kun den del, der er let at se.
Et separat tjenestenavn er en etiket; en separat identitet er en sikkerhedsegenskab.
Tæl arbejderens myndighed, ikke portene
Begynd med kørselsbrugeren, dens grupper, dens evner og dens filsystemvisning. En tjenestekonto, der tilfældigvis er med i en VPN-gruppe, kan læse nøglemateriale, uden at nogen port er åben. Skrivbare monteringer er den anden halvdel: uploads og caches skal ligge langt fra politikfiler og hemmeligheder, og en unødigt delt skrivbar mappe ødelægger pæn navngivning. Kontrollér den proces, der ville udføre handlingen, fordi en privilegeret forælder og uprivilegerede arbejdere ikke deler én myndighed.
At en VPN-nøgle kan læses under daemonens opstart betyder ikke, at webarbejderen har brug for den. Adskil den læsning, daemonen udfører, fra den adgang, applikationen får.
Sockets, der giver mere, end de ser ud til
Nogle endepunkter er administrative API'er i kostume som et metrikfeed. VPN'ens administrationsgrænseflade kan ændre sessioner, afbryde klienter og læse tilstand. En containers runtime-socket er endnu bredere: adgang til den er reelt værtskontrol, langt ud over hvad en webapplikation har brug for. Ingen af dem hører til en almindelig applikations monteringssæt, og ingen af dem dukker op, når man tæller lyttende porte.
At binde en administrationslytter til en lokal adresse er en start, ikke en fuldstændig begrænsning, fordi enhver indgangsvej til den adresse stadig betyder noget. Tillad kun de tilsigtede kilder og grænseflader.
Containere deler en kerne
Containere tilføjer grænser for proces, filsystem og netværk, og de deler én kerne med værten. Det gør valg af capabilities, værtsmonteringer og daemonadgang afgørende: at montere værtshemmeligheder eller give privilegeret runtime-kontrol sletter den grænse, containeretiketten antyder. Separate VM'er giver ganske vist separate gæstekerne, mens hypervisoren, administrative identiteter, lager og backups forbliver delt. Vælg den grænse, hvis konfiguration og opdateringer har en navngivet ejer.
En mere indviklet ordning, som ingen vedligeholder, er værre end en enkel, der faktisk bliver gennemgået.
Test afvisningen, derefter tjenesten
Brug godkendte kontroller i arbejderens virkelige kontekst til at bekræfte, at den ikke kan ændre VPN-politik, læse unødvendige hemmeligheder eller røre administrationsgrænsefladen. En vellykket læsning som administrator tester intet om den afvisning. Bekræft derefter webstedet, en almindelig tilladt VPN-handling, og hvad der sker med hver af dem ved genstart. Bevar en gendannelsesvej, der ikke afhænger af, at VPN'en bliver repareret, så en fejl forbliver mulig at rette.
Begge roller deler stadig CPU, hukommelse, uplinkkapacitet og vedligeholdelseshændelser. De delte ressourcer hører med i planen, selv når myndighedsgrænsen er ren.
Skriv ned, hvad hver proces kan gøre, hvad der svigter, hvis den stopper, og hvilken grænse der forbliver delt. Porttal er ikke den fortegnelse.