Jokainen tiimi päätyy lopulta tilanteeseen, jossa kirjautumistietoja on
liian monessa paikassa: .env-tiedosto jokaisella kannettavalla,
kiinnitetty viesti Slackissa, taulukko nimeltä ”tunnukset” ja
CI-muuttuja, jonka joku asetti kaksi vuotta sitten. Pilvipohjainen
salaisuuksien hallintapalvelu on olemassa, jotta kaikki tämä saadaan
yhteen paikkaan, joka on salattu, jonka käyttöoikeudet on rajattu ja
jonka jokainen käyttökerta kirjataan.
Tässä oppaassa kerrotaan, mitä pilvipohjainen salaisuuksien hallintapalvelu tekee, miten tärkeimpien vaihtoehtojen välillä valitaan, miten sen saa käyttöön ilman pitkää siirtoprojektia ja mitä yhtä tehtävää se ei hoida: salaisuuden toimittamista ihmiselle, joka ei ole pilvitilisi sisällä.
Mitä pilvipohjainen salaisuuksien hallintapalvelu tekee
Salaisuuksien hallintapalvelu tallentaa arkaluonteisia arvoja ja antaa ne pyynnöstä valtuutetuille identiteeteille. Ydinominaisuudet ovat samat kaikilla palveluntarjoajilla:
- Salattu tallennus: tallennettu tieto on salattu avaimilla, joita säilytetään palveluntarjoajan avaintenhallintapalvelussa, ja siirrossa käytetään TLS:ää.
- Identiteettiin perustuva käyttöoikeus: jokaisella salaisuudella on käytäntö, joka määrää, mitkä käyttäjät, roolit tai työkuormat saavat lukea, kirjoittaa tai kierrättää sitä. Sovellus tunnistautuu omalla identiteetillään, ei pääsalasanalla.
- Tarkastusloki jokaisesta lukemisesta, kirjoittamisesta ja kierrätyksestä: kuka, mitä ja milloin.
- Versiointi ja kierrätys: uuden arvon voi valmistella, sovellukset siirtää käyttämään sitä ja vanhan version poistaa käytöstä. Monet palvelut vaihtavat tietokantojen tunnukset automaattisesti.
- Haku ajonaikaisesti: sovellus hakee salaisuuden käynnistyessään tai tarvitessaan, joten arvoa ei koskaan kirjoiteta koodiin, levykuviin tai asetustiedostoihin.
Salaisuus on mikä tahansa, mikä antaa pääsyn johonkin. Asetukset, jotka vain kuvaavat toimintaa, kuten porttinumero tai ominaisuuslippu, kuuluvat tavallisiin asetuksiin. Jos nämä sekoitetaan, salaisuusvarastoon kertyy turhaa tavaraa ja asetuksista tulee vaarallisia.
Näin valitset palvelun
Valinta riippuu yleensä siitä, missä työkuormat ajetaan ja kuinka monta pilveä on käytössä.
| Vaihtoehto | Sopii parhaiten | Huomioitavaa |
|---|---|---|
| AWS Secrets Manager / Parameter Store | Työkuormat ovat jo AWS:ssä, IAM-identiteetit kaikkialla | Secrets Managerissa hinta salaisuutta kohden; Parameter Store on edullisempi tavallisille arvoille |
| Google Secret Manager | GCP-projektit, Cloud Run- ja GKE-työkuormat | Alueellisen replikoinnin valinnat |
| Azure Key Vault | Azure-työkuormat, varmenteiden elinkaaren hallinta | Erilliset holvit kullekin ympäristölle, jotta käytännöt pysyvät yksinkertaisina |
| HashiCorp Vault | Useampi pilvi tai oma konesali, dynaamiset lyhytikäiset tunnukset | Ylläpito jää sinulle, ellet käytä palveluna tarjottavaa versiota |
| Doppler, Infisical, 1Password Secrets Automation | Pienet tiimit, jotka haluavat kehittäjäystävällisen synkronoinnin moneen alustaan | Yksi palveluntarjoaja lisää luottamusketjussa |
Neljä kysymystä ratkaisee useimmat valinnat. Toimiiko palvelu käyttöönottotyökalujen ja ajoympäristön kanssa ilman itse tehtyä liimakoodia? Voivatko työkuormat tunnistautua siihen sillä identiteetillä, joka niillä jo on? Kierrättääkö se niitä tunnustyyppejä, joita sinulla oikeasti on? Ja päätyvätkö sen tarkastuslokit sinne, mihin tietoturvatiimi jo katsoo? Hinnat, alueet ja vaatimustenmukaisuuden sertifioinnit tulevat vasta näiden neljän jälkeen.
Käyttöönotto ilman kuuden kuukauden projektia
- Inventoi ja nimeä omistajat. Listaa jokainen salaisuus, missä se on, mikä sitä käyttää ja kuka siitä vastaa. Omistaja päättää kierrätyskäytännöstä ja käyttöoikeuksista.
- Määritä identiteetit ensin. Luo roolit tai palvelutilit jokaiselle työkuormalle ja ympäristölle ennen kuin siirrät yhtäkään arvoa. Koko idea on käyttöoikeuskäytännöissä, jotka sanovat ”tämä palvelu, tämä ympäristö, vain luku”.
- Siirrä riskijärjestyksessä. Ensin tuotannon tietokantasalasanat ja maksuavaimet, sitten kolmansien osapuolten API-avaimet ja sitten kaikki muu. Poista jokainen arvo koodista, CI-muuttujista ja asetustiedostoista sitä mukaa kuin se siirtyy, ja vaihda se siirron yhteydessä, koska vanhaa arvoa on jo kopioitu sinne tänne.
- Muuta tapa, jolla sovellukset lukevat salaisuudet. Korvaa koodiin kirjoitetut arvot ja ympäristötiedostot kutsulla palvelun SDK:hon käynnistyksen yhteydessä, tai syötä arvot alustan omalla integraatiolla.
- Ota kierrätys käyttöön kaikelle, mitä palvelu osaa kierrättää itse, ja kirjoita muille kierrätysfunktio tai toimintaohje.
- Hälytä poikkeavasta. Salaisuuden lukeminen uudella identiteetillä, lukukertojen äkillinen kasvu tai luku alueelta, jolle et tee käyttöönottoja, ansaitsee hälytyksen päivystäjälle.
Tavalliset virheet ovat ennustettavia: vanhat kopiot jätetään paikalleen siirron jälkeen, työkuormalle annetaan lukuoikeus koko varastoon eikä vain sen omiin salaisuuksiin, ja haettu arvo kirjataan sovelluksen lokeihin.
Aukko, jota salaisuuksien hallintapalvelu ei täytä
Salaisuuksien hallintapalvelu on tehty koneille ja ihmisille, jotka ovat identiteettijärjestelmäsi sisällä. Sitä ei ole tehty hetkeen, jolloin tunnukset on saatava jollekulle sen ulkopuolelle: alihankkijalle, joka tarvitsee väliaikaisen tietokantasalasanan, asiakkaalle, joka saa ensimmäiset pääkäyttäjän tunnuksensa, palveluntarjoajan insinöörille, joka tarvitsee tunnisteen iltapäiväksi, tai uudelle työntekijälle ensimmäisenä päivänä ennen kuin hänen SSO-tilinsä on olemassa.
Nämä luovutukset tapahtuvat joka tapauksessa, ja ilman hyväksyttyä reittiä ne tapahtuvat sähköpostissa ja keskusteluissa, joista salaisuuksien hallintapalvelujen piti saada tunnukset pois. Hyväksytty reitti on kertakäyttöinen salainen linkki. Arvo salataan selaimessasi ennen tallennusta, viestissä kulkee vain linkki, tallennettu kopio tuhotaan, kun linkki avataan ensimmäisen kerran, ja linkki vanhenee ajastimen mukaan, jos kukaan ei avaa sitä.
Toimiva malli: salaisuuksien hallintapalvelu on virallinen tietolähde, ja kertakäyttölinkki on toimitustapa silloin, kun järjestelmän ulkopuolinen ihminen tarvitsee arvon kerran. Luo tunnukset, tallenna ne hallintapalveluun, lähetä ne henkilölle kertakäyttölinkillä ja vaihda ne, kun hänen käyttöoikeutensa päättyy. Salaiset linkit vai salasanojen hallintaohjelmat soveltaa samaa päättelyä tiimin salasanojen hallintaohjelmaan, ja opas tunnusten luovutuksesta tiimien välillä käy läpi rutiinin.
Lyhyt tarkistuslista
- Jokaisella salaisuudella on omistaja, käyttöoikeuskäytäntö ja kierrätyssääntö.
- Työkuormat tunnistautuvat omalla identiteetillään, eivät koskaan jaetulla avaimella.
- Siirron jälkeen salaisuuksia ei ole koodissa, levykuvissa, CI-muuttujissa eikä keskusteluissa.
- Lukukerrat kirjataan paikkaan, jota joku oikeasti seuraa.
- Identiteettijärjestelmän ulkopuoliset ihmiset saavat salaisuudet kertakäyttölinkillä, eivät viestissä.
Kun nämä viisi asiaa ovat kunnossa, salaisuuksien hallintapalvelu lakkaa olemasta pelkkä ostettu tuote. Siitä tulee syy siihen, että tunnukset lakkasivat vuotamasta.