Samm-sammuline tegevuskava Dockeri mitme rentnikuga isoleerimiseks

Kokkuvõte

Jagatud taristu haldamine mitme kliendikampaania või ettevõttesisese veebikeskkonna jaoks tekitab juhtkonna seas sageli vaidlusi majutuskulude ja andmeturbe üle. Dockeri konteinerid pakuvad spetsiaalsetele virtuaalmasinatele kergekaalulist alternatiivi, kuid vaikeseadistused jätavad sisse tõsised isolatsioonilüngad. Tõeline mitme rentnikuga (multi-tenant) arhitektuur nõuab teadlikke piire tuuma (kernel), protsesside, võrgu ja salvestusruumi tasemel. See juhend annab praktilise viiesammulise raamistiku mitme rentnikuga Dockeri paigalduste turvamiseks Linuxi natiivsete isolatsioonipritsiipide abil. Saate teada, kuidas jõustada ressursikvoote, piirata protsesside õigusi, segmenteerida konteinerite võrke ja valida õige isolatsioonitase. Selle tegevuskava järgimine aitab kaitsta rentnike keskkondi ja põhjendada taristueelarveid mittetehnilistele otsustajatele.

Teie mittetehniline juht astub kabinetti eelmise kuu pilvemajutuse arvega. Kulud on kasvanud, kuid samal ajal kogesid mitmed prioriteetsed maandumislehed samaaegse tooteesitluse ajal latentsuse hüppeid. Teil palutakse selgitada, miks turundusmaterjalid jagavad samu servereid, kas klientide andmed on ohus ja miks ei saa meeskond iga üksiku kampaania jaoks luua kulukat eraldiseisvat virtuaalmasinat.

Igale digitaalsele varale oma virtuaalmasina (VM) eraldamine kõrvaldab lärmakad naabrid (noisy neighbors), kuid kulutab kiiresti kogu tegevuseelarve. Tavalised Dockeri paigaldused lahendavad kuluküsimuse, käitades mitut saiti ühel operatsioonisüsteemi tuumal, kuid vaikeseadistused jätavad ohtlikud isolatsioonilüngad. Kui ühe rentniku rakendus põrkub kontrolli alt väljunud skripti või turvarikkega, satuvad ohtu kõik samas serveris majutatud rakendused.

Kasutage seda samm-sammulist tehnilist tegevuskava range mitme rentnikuga isolatsiooni seadistamiseks Dockeris. Rakendage need viis operatiivset sammu, et kaitsta süsteemi stabiilsust, isoleerida rentnike andmed ja tõlkida tehnilised taristuvalikud juhtkonnale selgeks äriväärtuseks.

---

1. Jõustage ranged ressursikvoodid kontrollgruppide (cgroups) abil

Määrake igale konteinerile koheselt selged protsessori (CPU), mälu ja ketta I/O piirangud. Kui mitu rentnikku jagavad alustaristut, konkureerivad piiranguteta konteinerid süsteemi ressursside pärast. Üks kontrolli alt väljunud andmebaasipäring või suure liiklusega kampaania võib ära kasutada kogu serveri mälumahu, käivitades Linuxi Out-Of-Memory (OOM) tapja, mis seiskab juhuslikke süsteemiprotsesse.

Linuxi kontrollgrupid (cgroups) reguleerivad, kui palju arvutusvõimsust üks konteiner võib tarbida. Määrake need piirangud otse oma paigaldusfailides:

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

• Mälupiirangud (limits.memory): seab range lae. Kui konteiner ületab 512 megabaiti, seiskab tuum protsessid selles konteineris ilma naaberrentnikke mõjutamata.
• Mälureserveeringud (reservations.memory): tagab baasmälu jaotuse, et madala liiklusega rakendused püsiksid reageerimisvõimelised.
• CPU piirangud (limits.cpus): piirab konteineri maksimaalset lubatud osa saadaolevatest CPU tuumadest, vältides olukorda, kus üks rentnik võtab endale kogu protsessoriressursi.

Kui põhjendate seda arhitektuuri mittetehnilistele juhtidele, selgitage cgroups-gruppe kui automaatseid digitaalseid alamarvesteid. Nii nagu büroohoone üürnikud maksavad oma individuaalse elektritarbimise eest, mitte ei koorma üle peakaitselülitit, tagavad cgroups-grupid, et ühe kliendi suure liiklusega maandumisleht ei lööks rivist välja teise kliendi kontaktikogumisportaali. Arhitektuursete kompromisside sügavamaks mõistmiseks lugege meie juhendit mitme rentnikuga arhitektuuri kavandamisest.

---

2. Segmenteerige rentnike protsessid nimeruumide ja mitte-juurkasutajatega

Ärge kunagi käitage konteineriprotsesse vaikimisi määratud root-kasutajana. Tavalistes Linuxi konteinerikeskkondades vastab konteineri sees olev root-õigus aluseks oleva hosti tuuma root-õigusele, kui seda pole selgesõnaliselt ümber kaardistatud. Kui ründaja murrab sisse root-kasutajana töötavasse veebirakendusse, saab ta kõrgendatud privileegid kogu jagatud serveris.

Jõustage protsesside isoleerimine kasutajanimeruumide ja mitte-root kasutaja määramise kaudu:

1. Määrake privileegideta käitusaegsed kasutajad: looge oma Dockerfile'ides spetsiaalsed madala õigustasemega teenusekasutajad.

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

2. Lubage kasutajanimeruumid (userns-remap): seadistage Dockeri deemon (/etc/docker/daemon.json) kaardistama konteineri kasutaja-ID-d serveri õigusteta vahemikku.

   {
     "userns-remap": "default"
   }
   

Linuxi nimeruumid jaotavad süsteemi nähtavust. Protsessi ID (PID) nimeruum tagab, et rentnik A ei näe, ei saa saata signaale ega peatada rentnikule B kuuluvaid protsesse. Haakepunktide (MNT) nimeruum annab igale rentnikule failisüsteemist isoleeritud vaate, samas kui IPC nimeruumid blokeerivad volitamata protsessidevahelise suhtluse.

Kasutajanimeruumide ümberkaardistamine neutraliseerib konteinerist väljamurdmise riskid: protsess, mis peab end konteineris root-iks (UID 0), kaardistatakse hostmasinas privileegideta ID-ks (näiteks UID 165536). Kui turvaauk võimaldab konteineri piiridest mööda pääseda, satub ründaja õigusteta kesta, millega pole võimalik muuta hosti konfiguratsioone ega pääseda ligi naaberrentnike kataloogidele.

---

3. Eemaldage tuuma privileegid ja jõustage kirjutuskaitstud failisüsteemid

Kärpige saadaolevaid Linuxi võimalusi (capabilities) ja muutke konteineri juurfailisüsteem käivitamisel muutumatuks (read-only). Vaikimisi annavad konteinerite käituskeskkonnad umbes tosin Linuxi tuuma võimekust, millest paljusid veebirakendused kunagi ei vaja. Liigsed privileegid annavad ründajatele tööriistad võrgumarsruutimise manipuleerimiseks, hosti kella muutmiseks või failijuurdepääsu kontrollidest möödahiilimiseks.

Lukustage konteinerid, eemaldades kõik vaikeprivileegid ja lisades tagasi ainult hädavajalikud töölipud:

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: eemaldab konteineri protsessilt kõik tuuma privileegid.
• cap_add: - NET_BIND_SERVICE: lubab selgesõnaliselt sidumise privilegeeritud portidega (nagu 80 ja 443), blokeerides samal ajal toorvõrgupesade (raw sockets) manipuleerimise.
• read_only: true: haagib kogu konteineri juurfailisüsteemi kirjutuskaitstuna. Ründajad ei saa pahatahtlikke faile alla laadida, PHP-skripte muuta ega veebiserveri konfiguratsioonifaile rikkuda.
• tmpfs: eraldab lenduva mälupõhise ruumi vajalike ajutiste failide jaoks (nagu /tmp), blokeerides binaarfailide käivitamise (noexec) ja õiguste laiendamise (nosuid).

Rakendage turvalise andmetöötlusrežiimi (seccomp) filtreid ja turvamooduleid nagu AppArmor või SELinux, et peatada ja piirata jagatud hosti tuumale tehtavaid süsteemikutseid. Kui teie meeskond haldab kohandatud veebirakenduste koosteid, järgige meie struktureeritud samme Dockeri konteinerite turvatugevdamiseks oma paigaldusprotsessides.

---

4. Jaotage võrgud rentnike keskkondade vahel

Keelake vaikimisi sillavõrk (default bridge network) ja looge igale rentnikule kohandatud, isoleeritud tarkvarapõhised sillavõrgud. Vaikimisi saavad tavalisse Dockeri sillavõrku paigutatud konteinerid teineteist sisemiste IP-aadresside kaudu tuvastada ja omavahel suhelda. Turvanõrkus ühe rentniku turunduse mikroteenuses võimaldab ründajal liikuda külgsuunas igasse teise samas hostis asuvasse andmebaasi ja rakendusse.

Isoleerige rentnike liiklus täielikult, deklareerides igale rentnikule sõltumatud võrgusillad:

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

• Rentnike isolatsioon: alpha_app ja alpha_db suhtlevad eranditult üle võrgu tenant_alpha_net. beta_app ei pääse ligi teenusele alpha_db, isegi kui ründaja skannib sisemist alamvõrku.
• Siselipu määrang (internal: true): takistab andmebaasivõrkudel liikluse otsest suunamist avalikku internetti, piirates sissetuleva ja väljamineva juurdepääsu ainult rakenduskonteineritele.
• Pöördproksi lüüs: ainult sissetuleva liikluse proksi ühendub võrku public_gateway_net, et suunata sissetulevad HTTP/HTTPS-päringud hostinime järgi määratud rentniku konteinerisse.

Täiustatud keskkondade puhul kaaluge Dockeri laiendatud konteinerisolatsiooni (ECI) režiime või selliseid käitusaegu nagu Sysbox, mis jõustavad automaatselt rangemaid kasutajanimeruumide piire ja virtualiseeritud /proc ning /sys failisüsteeme ilma keerulise käsitsi võrguskriptimiseta.

---

5. Koostage objektiivne otsustusmaatriks mitme rentnikuga lahendustele

Lükake ümber eeldus, et kõik digitaalsed varad vajavad eraldiseisvaid virtuaalmasinaid. Turundusjuhid eeldavad sageli, et riistvaratasemel virtuaalmasinate isolatsioon on ainus aktsepteeritav turvamudel. Praktikas tekitab spetsiaalsete virtuaalmasinate loomine kergetele maandumislehtedele või lühiajalistele kampaaniasaitidele tohutu kulude kasvu ja operatiivse hoolduskoormuse, parandamata tegelikult veebirakenduste turvalisust.

Kasutage järgmist võrdlusmaatriksit töökoormuse nõuete hindamiseks ja ratsionaalse paigaldusstrateegia esitlemiseks otsustajatele:

Isolatsioonitase	Alustehnoloogia	Turvapiir	Ressursikulu	Parim kasutusjuht
Jagatud pinu konteinerid	Nimeruumid ja Cgroups ühel OS-il	Loogiline OS-taseme isolatsioon	Väga madal	Suure liiklusega maandumislehed, sisekasutuse testkeskkonnad, ajutised kampaaniasaidid
Tugevdatud konteinerid (ECI / Sysbox)	Kasutajanimeruumid, AppArmor, kirjutuskaitstud juur	Täiustatud OS-tase ja virtualiseerimine	Madal	Agentuuride majutus mitmele kliendile, autentimisega portaalid, tundlikud turundusvormid
Spetsiaalsed virtuaalmasinad (VM-id)	Hüperviisori riistvaraline virtualiseerimine	Range riistvara/tuuma eraldatus	Kõrge	Maksete töötlemine, reguleeritud HIPAA/PCI andmed, kontrollimata kohandatud koodi käitamine
Hübriid (konteinerid eraldi virtuaalmasinates)	Tugevdatud konteinerid kliendipõhistes virtuaalmasinates	Mitmekihilised riistvara ja OS-i piirid	Mõõdukas kuni kõrge	Tipptaseme suurettevõtetest kliendid, kes nõuavad lepingulist rangeimat vastavust

Hinnake iga projekti enne taristueelarve eraldamist rangete kriteeriumide alusel:

1. Andmete tundlikkus: kas projekt salvestab rangelt reguleeritud andmeid (nt krediitkaardiandmed või terviseandmed)? Kui jah, paigaldage see eraldi virtuaalmasinasse.
2. Koodi päritolu: kas paigaldate standardiseeritud, meeskonna poolt auditeeritud koodi või lubate kontrollimata kolmandate osapoolte pistikprogramme? Standardkood sobib tugevdatud konteineritesse; testimata kolmanda osapoole kood nõuab hüperviisori isolatsiooni.
3. Eelarve ja eluiga: hooajaliste maandumislehtede ja ettevõtte põhiliste veebisaitide puhul tagab tugevdatud konteinerite mitme rentnikuga mudel maksimaalse jõudluse iga investeeritud euro kohta.

Taristuplaane juhtkonnale tutvustades tutvuge meie juhendiga kliendi vajaduse hindamisest spetsiaalsete virtuaalmasinate järele, et toetada oma soovitusi selgete tasemepõhiste argumentidega.

---

Kokkuvõte: turvakontrollide muutmine ettevõtte tasuvuseks (ROI)

Mitme rentnikuga Dockeri keskkonna turvamine ei nõua suurettevõtte pilvetaristu eelarvet. See nõuab operatsioonisüsteemi tasemel kontrollide ranget ja distsiplineeritud rakendamist.

Kui arutate taristut mittetehnilise juhtkonnaga, raamige need tehnilised seadistused kolme juhtimismõõdiku ümber:

• Kuluefektiivsus: mitme rentnikuga konteinerid võimaldavad meeskonnal majutada kümneid turundussaite murdosaga sellest arvutusvõimsusest, mida nõuaksid eraldiseisvad virtuaalmasinad.
• Töökindluse kaitse: kontrollgrupid (cgroups) tagavad, et hooajalise kampaania liiklusmahud ei halvenda peamiste brändisaitide jõudlust.
• Kahjuraadiuse piiramine: kirjutuskaitstud failisüsteemid, eemaldatud privileegid ja isoleeritud võrgusillad tagavad, et ühe saidi turvaintsident ei võimalda ligipääsu naaberkliendi andmebaasidele ega hosti juhtelementidele.

Rakendage neid kaitsemeetmeid süsteemselt oma konteinerite mallides. Nii tagate suure jõudlusega ja kulutõhusa taristu, mis vastab nii insenertehnilistele turvastandarditele kui ka juhtkonna eelarvepiirangutele.