Lépésről lépésre: Tervrajz a több-bérlős Docker-izolációhoz

Összegzés

A több ügyfélkampányt vagy belső webes felületet kiszolgáló megosztott infrastruktúra üzemeltetése gyakran szül feszültséget a vezetőséggel a tárhelyköltségek és az adatbiztonság miatt. A Docker-konténerek pehelysúlyú alternatívát nyújtanak a dedikált virtuális gépekkel szemben, az alapértelmezett beállítások azonban komoly biztonsági réseket hagynak az izolációban. A valódi több-bérlős (multi-tenant) működéshez tudatos határokra van szükség a kernel, a folyamatok, a hálózat és a tárhely szintjén. Ez az útmutató egy gyakorlati, öt lépésből álló keretrendszert ad a több-bérlős Docker-környezetek biztonságossá tételéhez a natív Linux izolációs primitívek segítségével. Megtanulhatja, hogyan érvényesíthet erőforrás-kvótákat, korlátozhatja a folyamatjogosultságokat, szegmentálhatja a konténerhálózatokat, és hogyan választhatja ki a megfelelő izolációs szintet. Ezen tervrajz követésével megvédheti a bérlői környezeteket, és magabiztosan indokolhatja meg az infrastruktúra-költségvetést a nem technikai döntéshozók felé is.

A nem technikai beállítottságú vezetője belép az irodájába a múlt havi felhőszámla kinyomtatott példányával. A költségek megugrottak, miközben több kiemelt fontosságú landing page is késleltetési problémákkal küzdött egy egyidejű termékbevezetés során. Magyarázatot vár arra, hogy a marketingeszközök miért osztoznak a szervereken, hogy az ügyfelek adatai veszélyben vannak-e, és hogy a csapat miért nem indíthat minden egyes kampányhoz egy-egy drága, dedikált virtuális gépet.

Ha minden digitális felületnek saját virtuális gépet (VM) biztosítunk, az kiküszöböli a „zajos szomszéd” (noisy neighbor) problémát, de rendkívül gyorsan felemészti az üzemeltetési költségvetést. A hagyományos Docker-környezetek megoldják a költségproblémát azzal, hogy több webhelyet futtatnak egyetlen operációsrendszer-kernelen, ám az alapértelmezett konfigurációk veszélyes izolációs hiányosságokat hagynak maguk után. Ha az egyik bérlő alkalmazásában egy elszabadult parancsfájl fut le, vagy biztonsági incidens éri, a kiszolgálón lévő összes többi alkalmazás veszélybe kerül.

Használja ezt a lépésről lépésre követhető technikai útmutatót a szigorú több-bérlős izoláció beállításához Dockerben. Alkalmazza ezt az öt működési lépést a rendszer stabilitásának megőrzésére, a bérlői adatok elszigetelésére, valamint a technikai infrastruktúra-döntések világos üzleti értékké formálására a vezetőség számára.

---

1. Szigorú erőforrás-kvóták kikényszerítése Control Groupok (cgroups) segítségével

Azonnal állítson be explicit CPU-, memória- és lemez-I/O korlátokat minden konténerre. Amikor több bérlő osztozik egy alapul szolgáló gazdagépen, a korlátlan konténerek versengeni fognak a rendszererőforrásokért. Egyetlen elszabadult adatbázis-lekérdezés vagy nagy forgalmú kampány felemésztheti a gazdagép teljes memóriáját, ami arra készteti a Linux Out-Of-Memory (OOM) killert, hogy tetszőleges rendszerfolyamatokat állítson le.

A Linux control groupjai (cgroups) szabályozzák, hogy egy konténer mekkora számítási kapacitást használhat fel. Érvényesítse ezeket a határokat közvetlenül a telepítési leírókban:

services:
  tenant_app:
    image: nginx:alpine
    deploy:
      resources:
        limits:
          cpus: '0.75'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M

• Memóriakorlátok (limits.memory): Szigorú felső határt szab meg. Ha a konténer túllépi az 512 megabájtot, a kernel leállítja a folyamatokat az adott konténeren belül anélkül, hogy rontaná a szomszédos bérlők kiszolgálását.
• Memóriafoglalások (reservations.memory): Garantálja az alapvető memóriafoglalást, így az alacsony forgalmú alkalmazások is gyorsak maradnak.
• CPU-korlátok (limits.cpus): A konténert a rendelkezésre álló CPU-magok maximális töredékére korlátozza, megelőzve, hogy egyetlen bérlő elszívja a CPU-kapacitást.

Amikor ezt az architektúrát a nem műszaki vezetőknek indokolja, mutassa be a cgroupokat automatizált digitális almérőkként. Ahogyan egy irodaház bérlői is a saját egyéni áramfogyasztásukért fizetnek ahelyett, hogy túlterhelnék a főbiztosítékot, a cgroupok biztosítják, hogy egyetlen nagy forgalmú landing page soha ne dönthesse be egy másik ügyfél leadgyűjtő portálját. Az architekturális kompromisszumok mélyebb áttekintéséhez olvassa el a több-bérlős architektúra tervezéséről szóló útmutatónkat.

---

2. Bérlői folyamatok szegmentálása névterekkel és nem root felhasználókkal

Soha ne futtasson konténerfolyamatokat az alapértelmezett root felhasználóként. Szabványos Linux-konténerkörnyezetekben a konténeren belüli root megegyezik a gazdagép kerneljén lévő roottal, hacsak nincs kifejezetten átmappelve. Ha egy támadó feltör egy rootként futó webalkalmazást, emelt szintű jogosultságokat szerez a megosztott gazdagépen.

Kényszerítse ki a folyamatok izolációját felhasználói névterek (user namespaces) és explicit, nem root futtatás révén:

1. Alacsony jogosultságú futtató felhasználók megadása: Hozzon létre dedikált, korlátozott jogosultságú szolgáltatásfelhasználókat a Dockerfile-okban.

   FROM php:8.2-fpm-alpine
   RUN addgroup -g 10001 tenantgroup && \
       adduser -u 10001 -D -G tenantgroup tenantuser
   USER tenantuser
   

2. Felhasználói névterek bekapcsolása (userns-remap): Konfigurálja a Docker démont (/etc/docker/daemon.json), hogy a konténer felhasználói azonosítóit (UID) a gazdagép egy nem kiváltságos tartományára képezze le.

   {
     "userns-remap": "default"
   }
   

A Linux-névterek particionálják a rendszerszintű láthatóságot. A folyamatazonosító (PID) névtér gondoskodik arról, hogy az „A” bérlő ne láthassa, ne küldhessen jelet és ne állíthassa le a „B” bérlőhöz tartozó folyamatokat. A csatolási (MNT) névtér minden bérlő számára izolált rálátást biztosít a fájlrendszerre, míg az IPC-névterek blokkolják a jogosulatlan folyamatközi kommunikációt.

A felhasználói névterek átképezése semlegesíti a konténerből való kitörési kísérleteket (container escape): egy olyan folyamat, amely a konténerén belül root-nak (UID 0) hiszi magát, egy nem kiváltságos azonosítóra (például UID 165536) van leképezve a gazdagépen. Ha egy exploit áttöri a konténer határait, a támadó egy jogosultságok nélküli shellben találja magát, amellyel nem tudja módosítani a gazdagép beállításait, és nem férhet hozzá a szomszédos bérlők könyvtáraihoz sem.

---

3. Kerneljogosultságok megvonása és csak olvasható fájlrendszerek érvényesítése

Vonja vissza a felesleges Linux-képességeket (capabilities), és tegye a konténer gyökérfájlrendszerét indításkor megváltoztathatatlanná (immutable). Az alapértelmezett konténer-futtatókörnyezetek körülbelül egy tucat Linux kernel-képességet biztosítanak, amelyek többségére a webalkalmazásoknak soha nincs szükségük. A felesleges képességek olyan eszközöket adnak a támadók kezébe, amelyekkel manipulálhatják a hálózati útválasztást, módosíthatják a gazdagép óráját, vagy megkerülhetik a fájlhozzáférési korlátozásokat.

Zárja le a futó konténereket az összes alapértelmezett képesség eldobásával, és csak a működéshez elengedhetetlen jelzőket adja vissza:

services:
  tenant_web:
    image: custom-nginx:latest
    read_only: true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges:true
      - seccomp=default.json
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=64m
      - /var/run:rw,noexec,nosuid,size=16m

• cap_drop: - ALL: Minden kernel-képességet megvon a konténerfolyamattól.
• cap_add: - NET_BIND_SERVICE: Kifejezetten engedélyezi a kiváltságos portokhoz (mint a 80 és a 443) való kötést, miközben blokkolja a nyers hálózati socketek manipulálását.
• read_only: true: A teljes konténer gyökérfájlrendszerét csak olvashatóként csatolja fel. A támadók így nem tölthetnek le kártékony binárisokat, nem módosíthatnak PHP-szkripteket, és nem írhatják át a webszerver konfigurációs fájljait.
• tmpfs: Ideiglenes, memóriában lévő könyvtárakat biztosít a szükséges munkaterületekhez (mint a /tmp), miközben blokkolja a binárisok futtatását (noexec) és a jogosultságkiterjesztést (nosuid).

Alkalmazzon biztonságos számítási mód (seccomp) szűrőket és biztonsági modulokat, például AppArmort vagy SELinuxot a megosztott gazdagép kerneléhez intézett rendszerhívások elfogására és korlátozására. Ha csapata egyedi webalkalmazás-buildeket kezel, kövesse a Docker-konténerek megerősítéséről szóló strukturált lépéseinket az üzembe helyezési folyamatokban.

---

4. Hálózatok particionálása a bérlői környezetek között

Tiltsa le az alapértelmezett bridge hálózatot, és hozzon létre egyedi, izolált, szoftveresen definiált bridge hálózatokat minden bérlői stackhez. Alapértelmezés szerint a szabványos Docker bridge hálózatra helyezett konténerek belső IP-címeken keresztül felfedezhetik egymást és kommunikálhatnak egymással. Egy bérlő marketing-mikroszolgáltatásában lévő sebezhetőség így horizontális mozgást (lateral movement) tesz lehetővé a gazdagépen található összes többi belső adatbázis és alkalmazás felé.

Izolálja teljesen a bérlői forgalmat bérlőnként különálló hálózati hidak deklarálásával:

networks:
  tenant_alpha_net:
    driver: bridge
    internal: true
  tenant_beta_net:
    driver: bridge
    internal: true
  public_gateway_net:
    driver: bridge

services:
  alpha_app:
    image: tenant_a_app:latest
    networks:
      - tenant_alpha_net
      - public_gateway_net

  alpha_db:
    image: mariadb:10.11
    networks:
      - tenant_alpha_net

  beta_app:
    image: tenant_b_app:latest
    networks:
      - tenant_beta_net
      - public_gateway_net

  beta_db:
    image: mariadb:10.11
    networks:
      - tenant_beta_net

• Bérlői izoláció: Az alpha_app és az alpha_db kizárólag a tenant_alpha_net hálózaton keresztül kommunikál. A beta_app nem érheti el az alpha_db-t, még akkor sem, ha egy támadó feltérképezi a belső alhálózatot.
• Internal jelző (internal: true): Megakadályozza, hogy az adatbázis-hálózatok közvetlenül a külső internetre irányítsák a forgalmat, a bejövő és kimenő hozzáférést kizárólag az alkalmazáskonténerekre korlátozva.
• Reverse proxy átjáró: Csak az ingress proxy kapcsolódik a public_gateway_net hálózathoz, hogy a bejövő HTTP/HTTPS kéréseket hosztnév alapján a kijelölt bérlői konténerhez irányítsa.

Még magasabb szintű környezetekhez érdemes megfontolni a Docker Enhanced Container Isolation (ECI) módjait vagy olyan futtatókörnyezeteket, mint a Sysbox, amelyek automatikusan szigorúbb felhasználói névtér-határokat, valamint virtualizált /proc és /sys fájlrendszereket kényszerítenek ki összetett manuális hálózati szkriptek nélkül.

---

5. Objektív több-bérlős döntési mátrix felállítása

Lépjen fel azzal a feltételezéssel szemben, hogy minden digitális eszközhöz dedikált virtuális gépre van szükség. A marketingvezetők gyakran azt gondolják, hogy a hardverszintű VM-izoláció az egyetlen védhető biztonsági modell. A gyakorlatban a dedikált virtuális gépek kiosztása egyszerű landing page-ekhez vagy rövid életű kampányoldalakhoz hatalmas költségnövekedést és üzemeltetési terhet eredményez anélkül, hogy érdemben javítaná a webalkalmazások biztonságát.

Használja az alábbi összehasonlító mátrixot a munkaterhelési követelmények felméréséhez és a racionális üzembe helyezési stratégia döntéshozók elé terjesztéséhez:

Izolációs szint	Alapul szolgáló technológia	Biztonsági határ	Erőforrás-többletterhelés	Legjobb felhasználási eset
Megosztott stack konténerek	Névterek és cgroupok egyetlen OS-en	Logikai, OS-szintű izoláció	Nagyon alacsony	Nagy forgalmú landing page-ek, belső staging, átmeneti kampányoldalak
Megerősített konténerek (ECI / Sysbox)	Felhasználói névterek, AppArmor, csak olvasható root	Haladó OS-szintű és virtualizáció	Alacsony	Ügynökségi többügyféles hoszting, hitelesített portálok, érzékeny marketingűrlapok
Dedikált virtuális gépek (VM-ek)	Hypervisor hardveres virtualizáció	Szigorú hardver-/kernel-elkülönítés	Magas	Fizetésfeldolgozás, szabályozott HIPAA/PCI adatok, nem megbízható egyedi kód futtatása
Hibrid (Konténerek dedikált VM-ekben)	Megerősített konténerek bérlőspecifikus VM-ekben	Többrétegű hardveres és OS-határok	Közepestől a magasig	Prémium vállalati ügyfelek dedikált szerződéses megfelelőségi követelményekkel

Mielőtt infrastruktúra-költségvetést rendelne egy projekthez, értékelje azt szigorú szempontok szerint:

1. Adatérzékenység: Tárol-e a projekt szabályozás alá eső adatokat (pl. bankkártyaadatokat vagy egészségügyi információkat)? Ha igen, helyezze dedikált virtuális gépre.
2. Kód eredete: Szabványosított, a csapat által auditált kódot telepít, vagy nem ellenőrzött külső bővítményeket engedélyez? A szabványos kódnak a megerősített konténerekben a helye; a teszteletlen harmadik féltől származó kód hypervisor-izolációt igényel.
3. Költségvetés és élettartam: Szezonális landing page-ek és alapvető vállalati webhelyek esetén a megerősített konténeres multi-tenancy biztosítja a maximális ár-érték arányt.

Amikor infrastruktúra-terveket mutat be a vezetőségnek, tekintse meg annak felméréséről szóló útmutatónkat, hogy mikor van szükségük az ügyfeleknek dedikált virtuális gépekre, hogy javaslatait világos, szinteken alapuló érvekkel támassza alá.

---

Összegzés: A biztonsági kontrollok üzleti megtérülésre (ROI) fordítása

A több-bérlős Docker-környezet biztonságossá tételéhez nincs szükség vállalati felhőarchitektúra-költségvetésre. Csupán az operációs rendszer kontrolljainak szigorú, fegyelmezett alkalmazását igényli.

Amikor áttekinti az infrastruktúrát a nem technikai vezetéssel, fogalmazza meg ezeket a technikai konfigurációkat három vezetői metrika köré:

• Költséghatékonyság: A több-bérlős konténerek lehetővé teszik a csapat számára, hogy több tucat marketingszájtot hosztoljon az egyedi virtuális gépekhez szükséges számítási kapacitás töredékén.
• Rendelkezésre állás védelme: A control groupok garantálják, hogy a szezonális kampányok forgalmi csúcsai nem rontják az alapvető márkaoldalak teljesítményét.
• Károsodási zóna (Blast Radius) minimalizálása: A csak olvasható fájlrendszerek, a megvont képességek és az izolált hálózati hidak biztosítják, hogy egyetlen webhely sebezhetősége ne engedjen hozzáférést a szomszédos ügyfelek adatbázisaihoz vagy a gazdagép vezérléséhez.

Építse be ezeket a védelmi vonalakat szisztematikusan a konténersablonjaiba. Így olyan nagy teljesítményű, költséghatékony infrastruktúrát hozhat létre, amely a mérnöki biztonsági előírásoknak és a vezetőség költségvetési elvárásainak egyaránt megfelel.