Vaiheittainen opas monivuokralaisuuden eristämiseen Dockerissa

Tiivistelmä

Jaetun infrastruktuurin hallinta useille asiakaskampanjoille tai sisäisille verkkosivustoille aiheuttaa usein kitkaa johdon kanssa hosting-kustannuksista ja tietoturvasta. Docker-kontit tarjoavat kevyen vaihtoehdon dedikoiduille virtuaalipalvelimille, mutta oletusasetukset jättävät vakavia aukkoja eristykseen. Todellinen monivuokralaisuus (multi-tenancy) vaatii tarkkaan harkittuja rajoja ytimen, prosessien, verkon ja tallennustilan tasolla. Tämä opas tarjoaa käytännöllisen viisivaiheisen viitekehyksen monivuokralaisten Docker-ympäristöjen suojaamiseen Linuxin natiiveilla eristysmekanismeilla. Opit asettamaan resurssikiintiöitä, rajoittamaan prosessioikeuksia, segmentoimaan konttiverkkoja ja valitsemaan oikean eristystason. Tätä mallia noudattamalla voit turvata vuokralaisympäristöt ja perustella infrastruktuuribudjetit myös ei-teknisille sidosryhmille.

Ei-tekninen esihenkilösi astuu työpisteellesi mukanaan tuloste viime kuun pilvipalvelulaskusta. Kustannukset ovat nousseet, mutta silti useat tärkeät laskeutumissivut kärsivät viivepiikeistä samanaikaisen tuotelanseerauksen aikana. Sinua pyydetään selittämään, miksi markkinointisivustot jakavat samat palvelimet, ovatko asiakastiedot vaarassa ja miksi tiimi ei voi pystyttää kallista dedikoitua virtuaalipalvelinta joka ikiselle kampanjalle.

Oman virtuaalipalvelimen (VM) antaminen jokaiselle digitaaliselle kokonaisuudelle poistaa resurssisyöpöt naapurit, mutta se kuluttaa nopeasti koko käyttöbudjetin. Tavalliset Docker-asennukset ratkaisevat kustannusongelman ajamalla useita sivustoja yhdellä käyttöjärjestelmäytimellä, mutta oletuskonfiguraatiot jättävät vaarallisia eristysaukkoja. Jos yhden vuokralaisen sovelluksessa suoritetaan hallitsematon skripti tai se joutuu tietomurron kohteeksi, jokainen samalla isännällä sijaitseva sovellus on vaarassa.

Käytä tätä vaiheittaista teknistä opasta konfiguroidaksesi Dockerissa tarkan monivuokralaiseristyksen. Ota nämä viisi operatiivista vaihetta käyttöön suojataksesi järjestelmän vakauden, eristääksesi vuokralaisten datan ja kääntääksesi tekniset infrastruktuurivalinnat selkeäksi liiketoimintahyödyksi johdolle.

---

1. Määritä tiukat resurssikiintiöt cgroup-ohjausryhmien avulla

Aseta eksplisiittiset CPU-, muisti- ja levy-I/O-rajat jokaiselle kontille välittömästi. Kun useat vuokralaiset jakavat saman taustalla olevan isäntäpalvelimen, rajoittamattomat kontit kilpailevat järjestelmäresursseista. Yksi karannut tietokantakysely tai suuren liikenteen kampanja voi kuluttaa isännän koko muistivarannon, jolloin Linuxin Out-Of-Memory (OOM) -tappaja alkaa sulkea satunnaisia järjestelmäprosesseja.

Linuxin ohjausryhmät (cgroups) määräävät, kuinka paljon laskentakapasiteettia mikä tahansa kontti voi käyttää. Määritä nämä rajat suoraan käyttöönottotiedostoissasi:

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

• Muistirajat (limits.memory): Asettaa ehdottoman ylärajan. Jos kontti ylittää 512 megatavua, ydin sulkee kyseisen kontin sisällä olevat prosessit heikentämättä naapurivuokralaisten toimintaa.
• Muistivaraukset (reservations.memory): Takaa perustason muistinvarauksen, jotta vähäisen liikenteen sovellukset pysyvät toimintavalmiina.
• CPU-rajat (limits.cpus): Rajoittaa kontin käyttämään enintään tiettyä osaa käytettävissä olevista prosessoriytimistä, mikä estää yksittäistä vuokralaista viemästä kaikkia CPU-resursseja.

Kun perustelt tätä arkkitehtuuria ei-tekniselle johdolle, selitä cgroupit automatisoituina digitaalisina alamittareina. Aivan kuten toimistorakennuksen vuokralaiset maksavat omasta sähkönkäytöstään sen sijaan, että he ylikuormittaisivat pääkatkaisijan, cgroupit varmistavat, ettei yhden asiakkaan suuren liikenteen laskeutumissivu koskaan kaada toisen asiakkaan liidienkeruusivustoa. Syvempää tietoa arkkitehtuurin kompromisseista löydät oppaastamme, joka käsittelee monivuokralaisarkkitehtuurin suunnittelua.

---

2. Segmentoi vuokralaisprosessit nimiavaruuksilla ja ei-root-käyttäjillä

Älä koskaan aja konttiprosesseja oletusarvoisena root-käyttäjänä. Tavallisissa Linux-konttiympäristöissä kontin sisäinen root vastaa isäntäytimen root-käyttäjää, ellei sitä ole erikseen uudelleenkartoitettu. Jos hyökkääjä murtautuu root-oikeuksilla toimivaan verkkosovellukseen, hän saa korotetut käyttöoikeudet jaettuun isäntäkoneeseen.

Toteuta prosessieristys käyttäjänimiavaruuksien ja eksplisiittisen ei-root-suorituksen avulla:

1. Määritä etuoikeudettomat ajonaikaiset käyttäjät: Luo Dockerfile-tiedostoihisi erilliset palvelukäyttäjät, joilla on matalat oikeudet.

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

2. Ota käyttöön käyttäjänimiavaruudet (userns-remap): Määritä Docker-taustaprosessi (/etc/docker/daemon.json) kartoittamaan kontin käyttäjätunnukset (UID) isäntäkoneen etuoikeudettomalle alueelle.

   {
     "userns-remap": "default"
   }
   

Linux-nimiavaruudet jakavat järjestelmän näkyvyyden osiin. Process ID (PID) -nimiavaruus varmistaa, että Vuokralainen A ei voi tarkastella, lähettää signaaleja tai sulkea Vuokralaisen B prosesseja. Mount (MNT) -nimiavaruus tarjoaa jokaiselle vuokralaiselle eristetyn näkymän tiedostojärjestelmään, ja IPC-nimiavaruudet estävät luvattoman prosessien välisen viestinnän.

Käyttäjänimiavaruuksien uudelleenkartoitus neutraloi kontin pakenemisvektorit: prosessi, joka luulee olevansa root (UID 0) kontin sisällä, on kartoitettu etuoikeudettomaan tunnisteeseen (kuten UID 165536) isäntäkoneessa. Jos hyökkäys läpäisee kontin suojaukset, hyökkääjä päätyy etuoikeudettomaan komentotulkkiin, joka ei pysty muokkaamaan isännän asetuksia tai käyttämään naapurivuokralaisten hakemistoja.

---

3. Poista ytimen lisäoikeudet ja ota käyttöön vain luku -tiedostojärjestelmät

Karsi käytettävissä olevat Linux-oikeudet (capabilities) ja tee kontin juuritiedostojärjestelmästä muuttumaton käynnistyksen yhteydessä. Konttien oletusajoympäristöt myöntävät noin tusinan verran Linux-ytimen valtuuksia, joista useimpia verkkosovellukset eivät koskaan tarvitse. Ylimääräiset oikeudet tarjoavat hyökkääjille työkaluja verkkoreitityksen muokkaamiseen, isännän kellonajan muuttamiseen tai tiedostojen käyttöoikeuksien ohittamiseen.

Lukitse ajonaikaiset kontit poistamalla kaikki oletusoikeudet ja lisäämällä takaisin vain välttämättömät toimintaliput:

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: Poistaa kaikki ytimen lisäoikeudet konttiprosessilta.
• cap_add: - NET_BIND_SERVICE: Sallii nimenomaisesti sitomisen etuoikeutettuihin portteihin (kuten 80 ja 443), mutta estää raakojen verkkosockettien manipuloinnin.
• read_only: true: Liittää koko kontin juuritiedostojärjestelmän vain luku -tilassa. Hyökkääjät eivät voi ladata haitallisia binäärejä, muokata PHP-skriptejä tai muuttaa verkkopalvelimen konfiguraatiotiedostoja.
• tmpfs: Varaa haihtuvia muistipohjaisia hakemistoja välttämättömille väliaikaistiedostoille (kuten /tmp) estäen samalla binäärien suorittamisen (noexec) ja oikeuksien korottamisen (nosuid).

Käytä seccomp-suodattimia (secure computing mode) ja tietoturvamoduuleja, kuten AppArmoria tai SELinuxia, katkaisemaan ja rajoittamaan jaettuun isäntäytimeen tehtyjä järjestelmäkutsuja. Jos tiimisi hallinnoi räätälöityjä verkkosovelluksia, tutustu ohjeisiimme Docker-konttien koventamisesta julkaisuputkissa.

---

4. Osioi verkot eri vuokralaisympäristöjen välillä

Poista oletussiltakuuntelu (bridge networking) käytöstä ja luo kullekin vuokralaiselle omat, eristetyt ohjelmistopohjaiset siltakytkimet. Oletusarvoisesti Dockerin tavalliseen siltaverkkoon sijoitetut kontit voivat löytää toisensa ja viestiä keskenään sisäisten IP-osoitteiden kautta. Yhden vuokralaisen markkinointimikropalvelun haavoittuvuus mahdollistaa sivuttaisen liikkumisen kaikkiin muihin isännän sisäisiin tietokantoihin ja sovelluksiin.

Eristä vuokralaisten liikenne täysin määrittämällä erilliset verkkosillat kullekin vuokralaiselle:

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

• Vuokralaisten eristys: alpha_app ja alpha_db viestivät yksinomaan tenant_alpha_net-verkon kautta. beta_app ei voi tavoittaa alpha_db-tietokantaa, vaikka hyökkääjä skannaisi sisäistä aliverkkoa.
• Internal-lippu (internal: true): Estää tietokantaverkkoja reitittämästä liikennettä suoraan ulkoiseen internetiin rajoittaen saapuvan ja lähtevän liikenteen vain sovelluskontteihin.
• Käänteisen välityspalvelimen yhdyskäytävä (Reverse Proxy): Vain saapuvan liikenteen välityspalvelin muodostaa yhteyden public_gateway_net-verkkoon ja reitittää saapuvat HTTP/HTTPS-pyynnöt oikeaan vuokralaiskonttiin isäntänimen perusteella.

Kehittyneemmissä ympäristöissä kannattaa harkita Dockerin ECI-tiloja (Enhanced Container Isolation) tai Sysboxin kaltaisia ajoympäristöjä, jotka ottavat automaattisesti käyttöön tiukemmat käyttäjänimiavaruuksien rajat sekä virtualisoidut /proc- ja /sys-tiedostojärjestelmät ilman monimutkaista manuaalista verkkoskriptausta.

---

5. Luo objektiivinen monivuokralaisuuden päätösmatriisi

Kyseenalaista oletus, että kaikki digitaaliset palvelut vaativat dedikoituja virtuaalipalvelimia. Markkinointijohto usein olettaa, että laitteistotason VM-eristys on ainoa hyväksyttävä tietoturvamalli. Käytännössä dedikoitujen virtuaalipalvelimien varaaminen kevyille laskeutumissivuille tai lyhytaikaisille kampanjasivustoille aiheuttaa valtavaa kustannusten ja ylläpidon turvotusta parantamatta verkkosovellusten tietoturvaa.

Käytä seuraavaa vertailumatriisia työkuormien vaatimusten arviointiin ja järkevän käyttöönottostrategian esittämiseen päättäjille:

Eristystaso	Taustateknologia	Tietoturvaraja	Resurssiylimäärä	Paras käyttökohde
Jaetun pinon kontit	Nimiavaruudet ja cgroupit yhdellä käyttöjärjestelmällä	Looginen käyttöjärjestelmätason eristys	Erittäin matala	Suuren liikenteen laskeutumissivut, sisäiset testiympäristöt, tilapäiset kampanjasivustot
Kovennetut kontit (ECI / Sysbox)	Käyttäjänimiavaruudet, AppArmor, vain luku -juuri	Kehittynyt käyttöjärjestelmätaso & virtualisointi	Matala	Usean asiakkaan toimistohostaus, todennetut portaalit, arkaluonteiset markkinointilomakkeet
Dedikoidut virtuaalipalvelimet (VM:t)	Hypervisor-laitteistovirtualisointi	Tiukka laitteisto-/ydinerottelu	Korkea	Maksujen käsittely, säännelty HIPAA/PCI-data, luotettavuudeltaan tuntemattoman koodin suoritus
Hybridi (kontit dedikoiduissa VM:issä)	Kovennetut kontit vuokralaiskohtaisissa VM:issä	Monikerroksiset laitteisto- ja käyttöjärjestelmärajat	Kohtalaisesta korkeaan	Vaativat yritysasiakkaat, joilla on tiukat sopimusvelvoitteet

Arvioi jokainen projekti tiukkojen kriteerien mukaan ennen infrastruktuuribudjetin myöntämistä:

1. Datan arkaluonteisuus: Tallentaako projekti sääntelyn alaista tietoa (esim. luottokorttitietoja tai terveystietoja)? Jos kyllä, ota käyttöön dedikoitu virtuaalipalvelin.
2. Koodin alkuperä: Otatko käyttöön standardoitua, tiimin tarkastamaa koodia vai sallitaanko tarkastamattomat kolmannen osapuolen lisäosat? Vakiokoodi kuuluu kovennettuihin kontteihin; testaamaton ulkopuolinen koodi vaatii hypervisor-eristyksen.
3. Budjetti ja elinkaari: Kausiluontoisille laskeutumissivuille ja yrityksen perussivustoille kovennettu konttipohjainen monivuokralaisuus tarjoaa parhaan suorituskyvyn suhteessa hintaan.

Kun esittelet infrastruktuurisuunnitelmia johdolle, tutustu oppaaseemme asiakkaiden dedikoitujen virtuaalipalvelimien tarpeen arvioinnista tukeaksesi suosituksiasi selkeillä tasopohjaisilla argumenteilla.

---

Johtopäätös: Tietoturvakontrollien kääntäminen liiketoiminnan tuotoiksi

Monivuokralaisen Docker-ympäristön suojaaminen ei vaadi suuryritystason pilviarkkitehtuuribudjettia. Se vaatii käyttöjärjestelmän hallintamekanismien johdonmukaista ja kurinalaista soveltamista.

Kun käyt infrastruktuuria läpi ei-teknisen johdon kanssa, sido nämä tekniset ratkaisut kolmeen liiketoimintamittariin:

• Kustannustehokkuus: Monivuokralaiset kontit mahdollistavat kymmenien markkinointisivustojen ylläpidon murto-osalla siitä laskentakapasiteetista, jota erilliset virtuaalipalvelimet vaatisivat.
• Käytettävyyden turvaaminen: Ohjausryhmät (cgroups) takaavat, etteivät kausikampanjan liikennepiikit heikennä brändin pääsivustojen suorituskykyä.
• Vaikutusalueen rajaus (Blast Radius): Vain luku -tiedostojärjestelmät, karsitut käyttöoikeudet ja eristetyt verkkosillat varmistavat, ettei yksittäisen sivuston tietomurto vaaranna viereisiä asiakastietokantoja tai isännän hallintaa.

Toteuta nämä suojaukset järjestelmällisesti konttipohjissasi. Näin luot korkean suorituskyvyn ja kustannustehokkaan infrastruktuurin, joka täyttää sekä ohjelmistokehityksen tietoturvavaatimukset että johdon budjettiraamit.