Mitkä asiakkaat todella tarvitsevat oman VM:n? Porrastettu Docker-eristyssuunnitelma

Yhteenveto

Toimistot usein panikoivat, kun asiakas kysyy, kuinka todella eristettyä heidän datansa on muista asiakkaista. Dockerin nimiavaruudet (namespaces) ja cgroupit antavat todellista eristystä, mutta ne eivät vastaa laitteistorajaa. Sen sijaan, että ajaisit jokaisen asiakkaan VM:ssä—tai mikä pahempaa, kohtelisit kaikkia asiakkaita samalla tavalla—rakenna pieni joukko eristystasoja ja yhdistä kukin asiakas yhteen datan herkkyyden, luottamuksen ja vaatimustenmukaisuuden perusteella. Lukittu kontti (ei-root, pudotetut käyttöoikeudet, seccomp, read-only-juuri) kattaa useimmat sivustot; säännellyt tai vihamieliset työkuormat saavat VM:n tai kontti-VM-hybridin. Tämä kirjoitus antaa toistettavan päätösvuon, vertailutaulukon ja rehellisen katsauksen siihen, milloin lisäeristys on liioittelua.

Oletko siinä myyntipuhelun vaiheessa, jossa uusi asiakas sanoo: “olemme terveydenhuoltoalaa, näytä että datamme on eristetty muista asiakkaistasi” ja haluaisit mieluummin puhua mistä tahansa muusta?

Tämä on toimiston ongelma: ei yksi täydellinen käyttöönotto, vaan sama luotettava käyttöönotto toistettuna tusinalle asiakkaille, joilla on erilaiset budjetit, riskiprofiilit ja vaatimustenmukaisuusvaatimukset. Tässä rehellinen versio. Dockerin eristys on todellista, mutta se on erityistä. Nimiavaruudet antavat jokaiselle kontille oman näkymän prosesseihin, verkkoyhteyksiin ja tiedostojärjestelmään; cgroupit rajoittavat CPU:ta, muistia ja levyn I/O:ta, jotta asiakkaat eivät voi näännyttää toisiaan. Se, mitä se ei osta sinulle, on laitteistoseinä kontin ja isäntäytimen välillä. Jos hyökkääjä pakenee kontista, hän on ainoan ytimesi sisällä. Loput tästä artikkelista muuttaa tämän epämukavan tosiasian toistettavaksi päätökseksi: luokittele jokainen asiakas datan herkkyyden ja luottamuksen mukaan, sovella perustason kovennusprofiilia ja tartu VM:ään vain, kun tietomurron hinta on korkeampi kuin VM:n hinta.

Hetkinen, eivätkö kontit ole jo eristettyjä?

Docker toimii Linux-nimiavaruuksilla ja cgroupeilla, ja nämä sanat tekevät todellista työtä. Nimiavaruudet erottavat prosessi-ID:t, verkkopinolät, liitäntäpisteet ja käyttäjät, joten yhden kontin prosessi ei näe toisen prosessitaulua. Cgroupit asettavat rajoja: anna kontille 0,5 CPU:ta, 512 MB muistia ja kiinteä lohko-I/O-painoarvo, ja juuri sen se saa. Karkaava silmukka yhdellä asiakkaalla kuristetaan sen sijaan, että se kaataisi naapurin. Jos et ole määrittänyt rajoja, olet ohittanut perustavimman asian, johon cgroupeja käytetään.

Ota yksinkertainen PHP-sovellus kontissa A. Se näkee oman tiedostojärjestelmänsä, oman verkkoliittymänsä, oman PID 1:n. Kontissa B on sama, mutta eri näkymä. Sitä nimiavaruudet ovat. Kävele nyt pois ja jätä muistiraja asettamatta: kontti A voi täyttää isäntäkoneen RAM-muistin ja saada kontin B matelemaan. Sitä cgroupit ovat olemassa estääkseen. Mutta kaksi konttia voi olla eristetty toisistaan nimiavaruuksilla ja silti jakaa isäntäytimen, mikä on se osa, josta jokainen konttipakotarina kertoo. Hyökkäys, joka pääsee ytimeen, voi mahdollisesti tavoittaa jokaisen asiakkaan kyseisellä isännällä.

“Docker on eristetty” on puoliksi tosi lause. Tarkka versio on “Docker eristää nimiavaruuksilla ja cgroupeilla, ja ytimen haavoittuvuus on räjähdyssäde.” Ennen kuin luotat asiakkaaseen ajamaan luottamattomia koodia, istu sen ajatuksen kanssa hetki. Vastaus ei ole “älä koskaan käytä kontteja”—se on helppo paniikki. Vastaus on tasojärjestelmä.

Joten miksi jotkut asiakkaat tarvitsevat enemmän kuin nimiavaruuksia?

Rehellinen vastaus on, että eristys ei ole kytkin, vaan spektri. Toisessa päässä on täysin jaettu kontti, jossa kaikki ovat käytännössä yhdessä sovelluksessa. Toisessa päässä on erillinen VM jokaiselle asiakkaalle omalla ytimellään. Suurin osa toimiston työstä elää epämukavassa keskellä, eikä keskikohta ole binäärinen valinta “Docker on hyvä” ja “aja VM kaikille” välillä.

Se, mikä työntää asiakkaan oikealle, ei ole heidän kokonsa. Se on neljä kysymystä:

• Tallentavatko he säänneltyä dataa? Terveystietoja, maksukorttitietoja, mitä tahansa mitä sääntelijä kutsuisi herkäksi.
• Onko heidän asiakkaansa tietomurrolla realistinen polku toiseen asiakkaaseen? Jos he voivat ajaa mielivaltaista koodia, kyllä.
• Luotatko koodiin ja sen käyttöönottajiin? Asiakas, joka palkkaa halvimman freelancerin, ei ole sama luottamustaso kuin asiakas, jonka dev-tiimin tunnet.
• Sanooko heidän sopimuksensa “dedikoitu”, “eristetty” tai “yksityinen”? Jos sanoo, olet jo luvannut tason; ainoa tehtävä nyt on valita oikea.

Jos et vielä osaa vastata näihin kysymyksiin, laita asiakas perustasolle ja kirjaa oletukset ylös. Se ei ole tietoturva-auditointi; se on järkevyystarkistus, jonka toistat jokaisen perehdytyksen yhteydessä.

Kuinka päätän asiakaskohtaisesti ilman että suoritan tietoturva-auditoinnin joka kerta?

Tee pieni taulukko ja sitoudu siihen. Et tarvitse matriisia, jossa on neljäkymmentä solua. Neljä tasoa kattaa lähes jokaisen asiakkaan, jonka toimisto näkee.

Asiakkaan asema	Mikä heidät todella erottaa	Käytä, kun
Taso 1: Jaettu sovellus/kontti	Vain sovelluslogiikka	Sisäiset työkalut, matalan riskin data, projektit, joissa kaikki ovat nimenomaisesti yhdessä kirjautumisjärjestelmässä
Taso 2: Sama isäntä, erilliset kontit	Nimiavaruudet ja cgroupit	Useimmat markkinointisivustot, yhteydenottolomakkeet, ei arkaluontoista dataa
Taso 3: Lukittu kontti	Taso 2 + ei-root, pudotetut käyttöoikeudet, seccomp, read-only-juuri, verkon segmentointi	Verkkokauppa, henkilökohtaiset tunnistetiedot (PII), mukautettu koodi, johon et täysin luota
Taso 4: Asiakaskohtainen VM	Hypervisor ja erillinen ydin	Terveydenhuolto, rahoitus, vaatimustenmukaisuuspaperit, luottamaton koodi, meluisat naapurit

Näin se toimii käytännössä. Leipomoasiakas, jolla on yhteydenottolomake ja Instagram-linkki, menee tasolle 2: yksi kontti jaetulla isännällä, oletusarvoinen Docker-verkko, resurssirajoitukset, työ valmis. Verkkokauppa, joka tallentaa asiakkaiden nimiä, osoitteita ja maksu-uudelleenohjauksia, menee tasolle 3: sama jaettu isäntä, mutta kontti toimii ei-root-käyttäjänä, sillä ei ole ylimääräisiä ytimen käyttöoikeuksia, se käyttää seccomp-profiilia ja avaa vain portin 443. Lääketieteellinen vastaanottoportaali, joka tallentaa suojattuja terveystietoja, menee tasolle 4: VM jokaista asiakasta kohden, koska tietomurron hinta ei ole “siivoamme sen” vaan “emme voi näyttää asiakkaalle, että otimme heidät vakavasti.”

Koko temppu on, että et mieti arkkitehtuuria uudelleen jokaisen asiakkaan kohdalla. Valitset rivin taulukosta, josta olet jo sopinut. Näin viiden hengen toimisto voi pyörittää sataa sivustoa ilman sataa erillistä tietoturvapakkomiellettä. Se myös tarkoittaa, että seuraava asiakas ei saa vastausta, joka riippuu siitä, kuka tiimin jäsen vastasi puhelimeen. Niiden valintojen taustalla olevaa syvempää arkkitehtuurikeskustelua varten tämä opas monivuokraajien eristystasojen suunnitteluun käsittelee kompromisseja yksityiskohtaisemmin.

Miltä lukittu kontti todella näyttää?

Lopetetaan sanomasta “lukittu” ja mennään konkreettiseksi. Tämä on mitä Taso 3 tarkoittaa tyypilliselle WordPress- tai PHP-asiakkaalle.

Ensinnäkin, vaihda käyttäjä. Useimmat viralliset imagot toimivat edelleen oletuksena rootina; Dockerfilessäsi luo ei-root-käyttäjä ja aja sovellus sillä käyttäjällä. Tämä poistaa välittömästi yleisimmän tavan, jolla konttivaltaus muuttuu isäntävaltaukseksi. Toiseksi, pudota käyttöoikeudet, joita et tarvitse. Aja --cap-drop ALL ja lisää takaisin vain yksi, yleensä NET_BIND_SERVICE, jotta sovellus voi kuunnella portissa 80. Jo tämä yksinään on suurempi muutos kuin useimmat odottavat. Kolmanneksi, tee juuritiedostojärjestelmä vain luku -tilassa --read-only ja mounttaa kirjoitettavat hakemistot (uploads, tietokannan datahakemisto) volumeina tai tmpfs:nä. Neljänneksi, sovella seccomp-profiilia ja, jos isäntäsi tukee sitä, AppArmor- tai SELinux-asetuksia. Lopuksi laita kontti omaan Docker-verkkoon ja avaa vain ne portit, joiden täytyy olla tavoitettavissa.

Käydään läpi WordPress-esimerkki. Perusimago toimii todennäköisesti rootina, joten lisäät useradd-vaiheen ja USER-direktiivin. Ajat konttia muistirajalla ja CPU-rajalla, joten plugin-liikenteen piikki ei vahingoita naapuria. Mounttaat /var/www/html/wp-content/uploads kirjoitettavana volumenä. Asetat --read-only. Liität sen verkkoon, jossa ei ole --privileged-lippua missään lähellä. Tuloksena on kontti, joka ennen oli “WordPress-sivusto” ja on nyt “WordPress-sivusto, joka sattuu olemaan enemmän lukittu kuin useimmat virtuaalipalvelimet.”

Jos kaiken manuaalinen tekeminen tuntuu hauraalta, on helpompi keskitie: Dockerin Enhanced Container Isolation, joka käyttää käyttäjä-nimiavaruuseristystä ja suojattua konttiajoympäristöä. Se on laillinen oikotie, mutta se ei ole ilmainen pääsylippu ohittaa ei-root- tai käyttöoikeuksien pudottaminen. Asiakas tarvitsee silti järkevän imagon. Ero on, että ytimeen kohdistuva hyökkäyspinta pienenee ilman, että sinusta tulee seccomp-asiantuntijaa yhdessä yössä. Jos haluat tarkan järjestyksen yhdelle asiakkaalle, askel askeleelta -eristyksen kovennusopas muuttaa tämän osion kopioi-liitä-komennoiksi.

Milloin lopetan kerrostamisen ja annan heille vain VM:n?

Tässä on vastakkainen osa: lisäeristys ei ole automaattisesti parempi. VM:t antavat laitteistotason eristyksen, erillisen ytimen ja paljon pienemmän hyökkäyspinnan, jos vierasydin kaatuu. Juuri sitä terveydenhuollon ja rahoituksen asiakkaat odottavat sanoessaan “haluamme olla eristettyjä.” Mutta jokainen VM lisää päivitys-, varmuuskopiointi- ja laskentakustannuksia, ja se moninkertaistaa laivaston päivitystyön. Jos VM:itä jokaiselle asiakkaalle, koska yksi asiakas kerran sanoi Dockerin pelottavan heitä, olet ostanut turvallisuusteatteria oikealla rahalla.

VM on oikea vastaus, kun riski asiakasta kohti on korkeampi kuin VM:n käyttökustannus asiakasta kohti. Se tarkoittaa säänneltyä dataa, kirjallisia vaatimustenmukaisuusvaatimuksia, luottamatonta kolmannen osapuolen koodia tai asiakasta, joka tarvitsee meluisan naapurin poistettua. Se on myös oikea vastaus, kun asiakkaan sopimus kirjaimellisesti lupaa dedikoidun ympäristön, koska “kontti” ei ole se, mitä he kuvittelevat allekirjoittaessaan “dedikoitu.”

Mutta VM ei vapauta huolimattomasta kontista. Yleinen ansa on laittaa asiakas VM:ään ja sitten jättää kovennukset väliin, koska “VM suojaa heitä.” VM suojaa isäntää asiakkaalta, ei asiakasta omalta huonolta imagoltaan. Haluat silti ei-rootin, pudotetut käyttöoikeudet ja seccomp:in tuon VM:n sisällä. Hybridilähestymistapa—kontit VM:n sisällä—on usein makea piste: VM tarjoaa rajan vaatimustenmukaisuuskeskusteluille, ja kontti antaa sinulle käyttöönottotyönkulun, jonka jo tunnet. Siitä keskustelusta on pidempi versio artikkelissa Pitäisikö jokaisen asiakkaan saada oma VM?, mutta lyhyt vastaus on, että VM on sopimusta varten, ei pelkoa varten.

Kuinka teen tästä toistettavaa jokaisen asiakkaan kohdalla?

Teet siitä toistettavan tekemällä tasojärjestelmästä mallipohjan, ei muistin varassa olevan. Pidä hakemisto Compose-tiedostoja, yksi kutakin tasoa kohden: tier2-baseline, tier3-locked, tier4-vm-hybrid. Kun uusi asiakas ilmestyy, kopioi mallipohja, muuta ympäristömuuttujat, ja tiedät jo eristyksen muodon ennen kuin olet kirjoittanut riviäkään uutta infrastruktuuria.

Kirjaa sitten päätös ylös. Ei 400-sivuista tietoturvaraporttia, vaan lyhyt kappale asiakkaan repositorioon: mitä dataa he tallentavat, millä tasolla he ovat, miksi ja mikä nostaisi heidät tasoa ylemmäksi. Se kappale on arvokkaampi kuin sata palomuurisääntöä, koska se on asia, jonka voit näyttää seuraavalle auditoijalle tai seuraavalle huolestuneelle asiakkaalle. Se myös estää sinua joutumasta muistamaan, miksi leipomo sai Tason 2 ja verkkokauppa Tason 3 alkuperäisen myyntipuhelun haihduttua.

Automatisoi tylsät tarkistukset. Anna CI:n skannata jokainen asiakaskuva ja epäonnistua rakennus, jos se toimii rootina, jos sillä on kaikki käyttöoikeudet, tai jos se yrittää julkaista muun portin kuin ne, jotka taso sallii. Mikään tästä ei ole eksoottista; se on vain varmistamista, että mallipohjaa ei vahingossa rikota hyvää tarkoittava kehittäjä. Jos rakennat ympäröivää hosting-työnkulkua muutenkin, tuotantovalmiin Docker-hosting-strategioiden artikkeli kattaa osan, joka tulee konttien määrittelyn jälkeen.

Mikään tästä ei ole glamouria. Yksikään blogikirjoitus ei saa “asiakaseristystä” kuulostamaan yhtä jännittävältä kuin greenfield-arkkitehtuurikaavio. Mutta tämä on ero toimiston välillä, joka vastaa “kuinka eristettyjä olemme?” sormet ristissä “täysin” ja sellaisen välillä, joka voi näyttää tason, konfiguraation ja syyn. Kontit eivät ole taikaseinä. VM:t eivät ole taikaluoti. Tasojärjestelmä on vain päätös, jonka kirjoitat ylös ja käytät uudelleen—ja toimistolle toistettavuus on koko peli.