En brannmur mellom porter er ikke en vertsgrense
To åpne porter og én brannmurregel utelater det som betyr noe: hva webarbeideren kan lese og styre. Test avvisningen, ikke bare tjenesten.
Nettstedet svarer på 443, VPN svarer på 1194, brannmuren slipper nøyaktig de to gjennom, og gjennomgangen består. Ingenting i den rekkefølgen spurte hva webarbeideren kan lese eller hvilke filer den kan skrive om. En kompromittert arbeider trenger ikke en åpen port hvis den kan nå en styresocket eller en skrivbar konfigurasjonskatalog. Grensen er myndighet, og lyttere er bare den delen som er lett å se.
Et eget tjenestenavn er en etikett; en egen identitet er en sikkerhetsegenskap.
Tell arbeiderens myndighet, ikke portene
Start med kjøretidsbrukeren, gruppene dens, egenskapene og filsystemvisningen. En tjenestekonto som tilfeldigvis er med i en VPN-gruppe, kan lese nøkkelmateriale uten at noen port er åpen. Skrivbare monteringer er den andre halvdelen: opplastinger og cacher bør ligge langt fra policyfiler og hemmeligheter, og en unødvendig delt skrivbar katalog ødelegger ryddig navngiving. Kontroller prosessen som ville utført operasjonen, fordi en privilegert forelder og uprivilegerte arbeidere ikke deler én myndighet.
At en VPN-nøkkel er lesbar under oppstarten av daemonen, betyr ikke at webarbeideren trenger den. Skill lesingen daemonen gjør, fra tilgangen applikasjonen får.
Sockets som gir mer enn de ser ut som
Noen endepunkter er administrative API-er i kostyme som en metrikkstrøm. Administrasjonsgrensesnittet til VPN-et kan endre sesjoner, koble fra klienter og lese tilstand. En runtime-socket for containere er enda bredere: tilgang til den er i praksis vertskontroll, langt utover det en webapplikasjon trenger. Ingen av dem hører til monteringssettet til en vanlig applikasjon, og ingen av dem dukker opp når du teller lyttende porter.
Å binde en administrasjonslytter til en lokal adresse er en start, ikke en fullstendig begrensning, fordi hver inngangsvei til den adressen fortsatt betyr noe. Tillat bare de tiltenkte kildene og grensesnittene.
Containere deler én kjerne
Containere legger til grenser for prosess, filsystem og nettverk, og de deler én kjerne med verten. Det gjør valg av egenskaper, vertsmonteringer og daemontilgang avgjørende: å montere vertshemmeligheter eller gi privilegert runtime-kontroll visker ut grensen containeretiketten antyder. Egne VM-er gir riktignok egne gjestekjerner, mens hypervisoren, administrative identiteter, lagring og sikkerhetskopier forblir delt. Velg grensen hvis konfigurasjon og oppdateringer har en navngitt eier.
Et mer innfløkt oppsett som ingen vedlikeholder, er dårligere enn et enkelt som faktisk blir gjennomgått.
Test avvisningen, deretter tjenesten
Bruk godkjente kontroller i arbeiderens virkelige kontekst for å bekrefte at den ikke kan endre VPN-policy, lese unødvendige hemmeligheter eller berøre administrasjonsgrensesnittet. En vellykket lesing som administrator tester ingenting om den avvisningen. Bekreft deretter nettstedet, en vanlig tillatt VPN-operasjon, og hva som skjer med hver av dem ved omstart. Behold en gjenopprettingsvei som ikke avhenger av at VPN-et blir reparert, slik at en feil forblir rettbar.
Begge rollene deler fortsatt CPU, minne, uplinkkapasitet og vedlikeholdshendelser. Disse delte ressursene hører hjemme i planen selv når myndighetsgrensen er ren.
Skriv ned hva hver prosess kan gjøre, hva som svikter hvis den stopper, og hvilken grense som forblir delt. Porttall er ikke den oversikten.