--- title: "GCP:n tietoturvan koventamisen tarkistuslista | Snow Tree" url: "https://www.snow-tree.com/fi/gcp-security-hardening/" --- 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. ## Tällä sivulla 1. [Yleiset GCP:n uhkapolut](https://www.snow-tree.com/fi/#threat-paths) 2. [Identiteetit ja käyttöoikeudet](https://www.snow-tree.com/fi/#identity) 3. [Verkko ja reuna](https://www.snow-tree.com/fi/#network) 4. [Tiedot ja salaisuudet](https://www.snow-tree.com/fi/#data) 5. [GKE:n koventaminen](https://www.snow-tree.com/fi/#gke) 6. [Havaitseminen ja palautus](https://www.snow-tree.com/fi/#detection) 7. [Priorisoitu tarkistuslista 30, 60 ja 90 päivälle](https://www.snow-tree.com/fi/#checklist) 8. [Viralliset lähteet](https://www.snow-tree.com/fi/#references) ## 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. [Hallinnoitu alusta](https://www.snow-tree.com/fi/managed-platform/) [Konsultointi](https://www.snow-tree.com/fi/consulting/) ## Viralliset lähteet Käytä Googlen ajantasaisia ohjeita ensisijaisena teknisenä lähteenä, kun alustan oletusasetukset tai tuotteiden ominaisuudet muuttuvat. - [Google Cloud: Parhaat käytännöt GKE-klusterin koventamiseen](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster) - [Google Cloud: GKE:n tietoturvan parhaat käytännöt](https://docs.cloud.google.com/docs/security/gke-security-bps) Hallinnoitu alusta ## Anna Snow Treen rakentaa, hostata ja operoida ohjelmistoa. [Aloita projekti](mailto:support+snow-tree-platform-1-issue-@gitlab.snow-tree.com?subject=Snow%20Tree%20project)