A portok közötti tűzfal nem gazdagép-határ
Két nyitott port és egy tűzfalszabály kihagyja a lényeget: mit olvashat és irányíthat a webes munkás. A megtagadást tesztelje, ne csak a szolgáltatást.
A weboldal a 443-on válaszol, a VPN az 1194-en válaszol, a tűzfal pontosan e kettőt engedi át, és az átvizsgálás átmegy. Ebben a sorrendben semmi sem kérdezte meg, mit olvashat a webes munkás, vagy mely fájlokat írhatja felül. Egy kompromittált munkásnak nincs szüksége nyitott portra, ha elér egy vezérlő socketet vagy egy írható konfigurációs könyvtárat. A határ a jogosultság, a hallgatók pedig csak a könnyen látható rész.
Az elkülönített szolgáltatásnév címke; az elkülönített identitás biztonsági tulajdonság.
A munkás jogosultságait számolja, ne a portokat
Kezdje a futásidejű felhasználóval, annak csoportjaival, képességeivel és fájlrendszer-nézetével. Egy szolgáltatásfiók, amely véletlenül egy VPN-csoporthoz tartozik, kulcsanyagot olvashat anélkül, hogy bármely port nyitva lenne. Az írható csatolások a másik fél: a feltöltéseknek és gyorsítótáraknak távol kell lenniük a házirendfájloktól és titkoktól, és egy szükségtelenül megosztott írható könyvtár tönkreteszi a rendezett elnevezést. Ellenőrizze azt a folyamatot, amely a műveletet végezné, mert egy kiváltságos szülő és a nem kiváltságos munkások nem osztoznak egyetlen jogosultságon.
Az, hogy a VPN-kulcs a démon indításakor olvasható, nem jelenti azt, hogy a webes munkásnak szüksége van rá. Válassza szét a démon olvasását az alkalmazásnak adott hozzáféréstől.
Socketek, amelyek többet adnak, mint amennyinek látszanak
Néhány végpont adminisztratív API metrikafolyam-jelmezben. A VPN felügyeleti felülete módosíthat munkameneteket, leválaszthat klienseket és olvashat állapotot. A konténer futásidejű socketje még szélesebb: a hozzáférés hozzá gyakorlatilag gazdagép-vezérlés, jóval túl azon, amire egy webalkalmazásnak szüksége van. Egyik sem tartozik egy közönséges alkalmazás csatolási készletébe, és egyik sem jelenik meg, amikor a hallgató portokat számolja.
Egy felügyeleti hallgató helyi címhez kötése kezdet, nem teljes korlátozás, mert az adott címhez vezető minden belépési útvonal továbbra is számít. Csak a szándékolt forrásokat és interfészeket engedje.
A konténerek egy kernelt osztanak meg
A konténerek folyamat-, fájlrendszer- és hálózati határokat adnak hozzá, és egy kernelt osztanak meg a gazdagéppel. Ez döntővé teszi a képességek megválasztását, a gazdagép csatolásait és a démon-hozzáférést: a gazdagép titkainak csatolása vagy kiváltságos futásidejű vezérlés adása kitörli a határt, amelyet a konténer címkéje sugall. A külön VM-ek valóban külön vendégkerneleket adnak, miközben a hipervizor, az adminisztratív identitások, a tárolás és a biztonsági mentések megosztottak maradnak. Válassza azt a határt, amelynek konfigurációjának és frissítéseinek van nevesített gazdája.
Egy bonyolultabb elrendezés, amelyet senki sem tart karban, rosszabb, mint egy egyszerű, amelyet tényleg átvizsgálnak.
Először a megtagadást tesztelje, aztán a szolgáltatást
Használjon jóváhagyott ellenőrzéseket a munkás valós környezetében annak megerősítésére, hogy nem módosíthatja a VPN-szabályzatot, nem olvashat szükségtelen titkokat, és nem érhet a felügyeleti felülethez. Egy sikeres olvasás rendszergazdaként semmit sem bizonyít erről a megtagadásról. Ezután ellenőrizze a weboldalt, egy szokásos engedélyezett VPN-műveletet, és hogy mi történik mindegyikkel újraindításkor. Tartson fenn egy helyreállítási útvonalat, amely nem függ a VPN javításától, hogy egy hiba helyreállítható maradjon.
Mindkét szerep továbbra is osztozik a CPU-n, a memórián, a felfelé irányuló kapacitáson és a karbantartási eseményeken. Ezek a megosztott erőforrások a tervbe tartoznak akkor is, amikor a jogosultsági határ tiszta.
Rögzítse, mit tehet az egyes folyamat, mi hibázik, ha leáll, és melyik határ marad megosztott. A portszám nem ez a feljegyzés.