Turvallinen GCP-infrastruktuuri
GCP:n tietoturvan koventamisen tarkistuslista pienille ja keskisuurille tiimeille
Käytännönläheinen perustaso tiimeille, jotka ajavat tuotantotyökuormia Google Cloudissa ilman omaa tietoturvaosastoa. Aloita sieltä, missä todennäköisimpiä reittejä vakavaan poikkeamaan on helpointa kaventaa.
Yleiset GCP:n uhkapolut
Useimmat pilven tietoturvapoikkeamat alkavat pienestä aukosta vastuissa tai konfiguraatiossa. Etsi nämä polut ennen kuin hyökkääjä löytää ne.
- Liian laajoilla oikeuksilla varustettu käyttäjä, palvelutili tai työkuorman identiteetti voi muuttaa yhden varastetun tunnistetiedon laajaksi pääsyksi useisiin projekteihin.
- Avoimesti saavutettava hallinnan päätepiste, virheenkorjausportti tai liian salliva palomuurisääntö voi ohittaa kaikki normaalille sovellusliikenteelle suunnitellut kontrollit.
- Julkinen tallennusbucket tai liian laaja allekirjoitettu URL-osoite voi paljastaa asiakastietoja ilman, että sovelluksen vaarantuminen näkyy.
- Vanhentuneet työkuormat luovat pysyvän riskin, kun vanhat konttikuvat, unohdetut nimiavaruudet, käyttämättömät palvelutilit ja resurssit, joilla ei ole omistajaa, ovat yhä otettavissa käyttöön.
- Puuttuva tai lyhytaikaisesti säilytetty tarkastusnäyttö vaikeuttaa sen selvittämistä, kuka muutti käytäntöä, milloin pääsy alkoi ja mihin tietoihin päästiin käsiksi.
- Testaamaton varmuuskopio on pelkkä toive. Epäonnistuneet palautukset, puutteellinen säilytys ja saavuttamattomat salausavaimet voivat muuttaa tietoturvatapahtuman pysyväksi menetykseksi.
Identiteetit ja käyttöoikeudet
Käsittele identiteettiä ensisijaisena ohjaustasona. Jokaisella ihmisellä, automaatioprosessilla ja työkuormalla pitää olla oma identiteettinsä, jolla on rajattu käyttötarkoitus.
Määritä resurssiraja selkeästi
Käytä organisaatiota ja kansioita suojakaiteina ja erota kehitys-, esituotanto- ja tuotantoympäristöt omiksi projekteikseen tai vahvemmin rajatuiksi luottamusalueiksi. Ota organisaatiokäytännöt käyttöön korkeimmalla käytännössä mahdollisella tasolla, rajoita palvelujen käyttöä ja vältä tuotantoprojektien jakamista toisiinsa liittymättömien tuotteiden kesken.
Myönnä pienin mahdollinen rooli suppeimmassa laajuudessa
Suosi ennalta määritettyjä tai mukautettuja rooleja laajojen perusroolien sijaan, myönnä ne ryhmille ja työkuormien identiteeteille ja käytä IAM-ehtoja, kun resurssin nimi tai tagi voi rajata pääsyä. Tarkista käyttämättömät käyttöoikeudet ja poista pysyvä pääsy tuotantoon, joka kuuluu vain break glass -hätäkäyttöprosessiin.
Poista pitkäikäiset tunnistetiedot
Käytä Workload Identity Federation for GKE -ominaisuutta, jotta podit saavat lyhytikäiset tunnistetiedot ilman vietyjä palvelutilien avaimia. Estä avainten luonti ja lataaminen organisaatiokäytännöllä aina kun mahdollista, inventoi kaikki jäljellä olevat avaimet ja määritä hälytykset suuririskisille IAM-muutoksille Cloud Audit Logsissa.
Verkko ja reuna
Oleta, että jokin sovellusvirhe on ennemmin tai myöhemmin saavutettavissa verkosta. Rajoita, mihin tuo virhe pääsee käsiksi.
Aloita estämällä kaikki ja salli nimetyt polut
Käytä vähimpien oikeuksien periaatteen mukaisia VPC-palomuurisääntöjä ja Kubernetes NetworkPolicies -käytäntöjä pod-liikenteelle. Erota ympäristöt omiin verkkoihinsa, dokumentoi jokainen saapuvan liikenteen polku ja poista laajat virheenkorjaussäännöt, jotka sallivat hallintaportit tai kaikki protokollat suurista osoitealueista.
Pidä solmut ja ohjaustasot yksityisinä
Poista ulkoiset IP-osoitteet käytöstä GKE-solmuista. Suosi ohjaustason DNS-pohjaista yksityistä päätepistettä, ja jos IP-päätepistettä ei voi välttää, rajoita sitä valtuutetuilla verkoilla. Anna työkuormille harkittu reitti lähtevälle liikenteelle laajan internetyhteyden sijaan.
Julkaise vain tarkoituksella julkisiksi valitut palvelut
Tuo sovellukset saataville tarkistetun yhdyskäytävän tai kuormantasaajan kautta, ei satunnaisesti avoimien pod- tai solmuosoitteiden kautta. Terminoi TLS hallinnoiduilla varmenteilla, rajoita saapuvan liikenteen isäntänimiä ja polkuja, ota käyttöön pyyntö- ja nopeusrajoitukset ja pidä hallintaliittymät identiteettipohjaisen pääsynhallinnan takana.
Tiedot ja salaisuudet
Suojaa tiedot levossa, siirrossa ja käytössä, ja osoita sitten, että pystyt palauttamaan ne. Tietojen löytäminen ja kartoitus on osa kontrollia.
Estä tahaton julkinen pääsy
Ota Cloud Storagessa pakolliseksi julkisen käytön esto ja yhtenäinen bucket-tason käyttöoikeus. Luokittele bucketit arkaluonteisuuden mukaan, rajoita objektien ja avainten käyttöä, ota lokitus käyttöön arvokkaille tiedoille ja käytä asiakkaan hallinnoimia salausavaimia, kun riski- tai vaatimustenmukaisuusmallisi sitä edellyttää.
Pidä salaisuudet poissa konttikuvista ja lähdekoodista
Tallenna tunnistetiedot Secret Manageriin ja myönnä tietylle työkuorman identiteetille pääsy tiettyyn salaisuuden versioon. Kierrätä salaisuuksia suunnitelmallisesti, älä kopioi niitä Gitiin tai konttikuviin äläkä pidä tavallisia Kubernetes Secrets -salaisuuksia täydellisenä suojarajana.
Testaa palautusta, ei vain varmuuskopion luomista
Määritä palautuspiste- ja palautusaikatavoitteet (RPO/RTO), säilytä kopioita tuotannon vikaantumisalueen ulkopuolella ja suojaa pääsy varmuuskopioihin ja salausavaimiin työkuorman identiteetiltä. Palauta säännöllisesti aikataulun mukaan eristettyyn ympäristöön, tarkista tiedot ja kirjaa kulunut aika sekä mahdolliset manuaaliset vaiheet.
GKE:n koventaminen
GKE suojaa hallinnoidun ohjaustason, mutta klusterin konfiguraatio, nimiavaruudet, admission-käytännöt ja työkuormat ovat edelleen sinun hallittavanasi.
Tee nimiavaruuksista sovittu eristysraja
Erota tiimit ja ympäristöt omiin nimiavaruuksiinsa tai klustereihinsa, sido niihin tarkasti rajattuja Kubernetes RBAC -rooleja ja käytä resurssikiintiöitä ja NetworkPolicies-käytäntöjä. Vältä klusterinlaajuisia kirjoitusoikeuksia sovellusten toimituksessa ja anna jokaiselle työkuormalle oma palvelutili, kun se tarvitsee erillisen identiteetin.
Päästä sisään vain konttikuvat ja konfiguraatiot, joihin luotat
Pakota käyttöön Pod Security -standardin Restricted-taso tai vastaavat Policy Controller -säännöt. Ota konttikuvat käyttöön muuttumattoman digestin perusteella, skannaa ne haavoittuvuuksien varalta, käytä Binary Authorizationia, kun alkuperällä on merkitystä, ja hylkää odottamaton pääsy isäntään, oikeuksien korotus ja cluster-admin-sidonnat.
Poista konteilta tarpeettomat oikeudet
Aja kontit muuna kuin root-käyttäjänä, poista Linuxin capabilities-oikeudet, käytä mahdollisuuksien mukaan vain luku -tilassa olevaa juuritiedostojärjestelmää ja ota käyttöön RuntimeDefault-seccomp-profiili. Älä liitä palvelutilin tokenia ilman tarvetta, vältä etuoikeutettuja kontteja ja isännän nimiavaruuksia, pidä solmujen palvelutili minimaalisena ja käytä Shielded Nodes -ominaisuutta yhdessä Container-Optimized OS:n kanssa.
Havaitseminen ja palautus
Kontrollit pettävät. Luota näyttöön ja harjoiteltuihin toimiin, älä siihen, ettei kukaan ole tehnyt virhettä.
Kerää näyttö, jota tulet tarvitsemaan
Säilytä Cloud Audit Logs sekä GKE:n järjestelmä- ja työkuormalokit keskitetyssä kohteessa niin pitkään kuin tutkintatarpeesi edellyttävät. Ota Data Access -tarkastuslokit käyttöön valikoidusti arkaluonteisille tiedoille, rajoita lokien käyttöä ja kirjaa IAM:n, palomuurin, tallennuksen ja klusterin konfiguraation hallinnolliset muutokset.
Hälytä tietoturvan kannalta merkittävistä muutoksista
Hälytä julkiseksi avautuneesta tallennustilasta, laajoista palomuuri- tai IAM-muutoksista, odottamattomista palvelutilien avaimista, admission-hylkäyksistä, ohjaustason altistumisesta, toistuvista todennusvirheistä, käytöstä poistetusta lokituksesta, epäonnistuneista varmuuskopioista ja vanhenemassa olevista varmenteista. Ohjaa jokainen hälytys omistajalle yhdessä ohjeiden kanssa, joilla hälytys vahvistetaan tai hylätään.
Harjoittele poikkeamiin reagointia
Kirjoita lyhyet runbookit vuotaneille tunnistetiedoille, julkiseksi päätyneille tiedoille, vaarantuneille työkuormille sekä menetetyille alueille tai projekteille. Kirjaa, kuka voi valtuuttaa rajaamistoimet, miten käyttöoikeudet perutaan, miten todisteet säilytetään ja miten palvelu palautetaan. Testaa runbookit niiden ihmisten kanssa, jotka niitä käyttävät.
Priorisoitu tarkistuslista 30, 60 ja 90 päivälle
Jos perustasosi on puutteellinen, järjestä työ niin, että altistumista vähennetään ensin ja myöhemmistä tarkasteluista tulee toistettavia.
Päivät 1–30: sulje ilmeiset polut
Inventoi projektit ja niiden omistajat, poista käyttämättömät ja pitkäikäiset tunnistetiedot, varmista tarkastuslokitus, estä julkiset bucketit, käy läpi laajimmat palomuurisäännöt ja IAM-oikeudet, tunnista tuotannon varmuuskopioinnin puutteet ja korjaa kaikki julkiset päätepisteet, joilla ei ole omistajaa. Määritä jokaiselle havainnolle omistaja ja määräpäivä.
Päivät 31–60: tee perustasosta toistettava
Siirrä verkon, identiteettien ja työkuormien konfiguraatio tarkastettuun infrastruktuuriin koodina ja GitOps-toimitukseen. Ota käyttöön Workload Identity, yksityiset solmut, Pod Securityn Restricted-taso, luotettujen konttikuvien tarkistukset, keskitetyt lokit ja hälytykset tärkeimmistä muutoksista.
Päivät 61–90: osoita toimivuus ja ylläpidä sitä
Tee palautustestit ja poikkeamatilanteen pöytäharjoitus, käy läpi etuoikeutetut käyttöoikeudet ja poikkeuslupien vanheneminen, skannaa konttikuvat ja riippuvuudet uudelleen, varmista, että omistajat saavat hälytykset, ja mittaa jäljelle jäävät puutteet. Ota tarkistukset osaksi toistuvaa tarkastelusykliä ennen kuin näyttö vanhenee.
Käytä tätä tarkistuslistaa lähtökohtana. Snow Tree voi toteuttaa perustason osana hallinnoidun alustan operointia tai kohdennettua konsultointiprojektia.
Viralliset lähteet
Käytä Googlen ajantasaisia ohjeita ensisijaisena teknisenä lähteenä, kun alustan oletusasetukset tai tuotteiden ominaisuudet muuttuvat.
Hallinnoitu alusta