Salaisuuksien hallinta puolustuksen CI/CD-putkilinjoissa: Vault, HSM ja avainten kierrätys

Jokainen puolustusohjelmistojärjestelmä riippuu salaisuuksista: TLS-varmenteista, jotka autentikoivat palveluidentiteettejä, API-avaimista, jotka valtuuttavat pääsyn ulkoisiin palveluihin, tietokantasalasanoista, jotka suojaavat operatiivista dataa, salausavaimista, jotka suojaavat luokiteltua tietoa ja koodin allekirjoitusavaimista, jotka varmentavat laiteohjelmiston ja ohjelmiston eheyden. Jos nämä salaisuudet käsitellään huolimattomasti — tallennetaan konfiguraatiotiedostoihin, viedään lähdekoodiarkistoihin, välitetään ympäristömuuttujina selkotekstinä tai jätetään muuttumattomiksi määräämättömäksi ajaksi — niistä tulee hyökkäysvektoreita, jotka ohittavat kaikki muut turvallisuusvalvontatoimet.

Salaisuuksien hallinta puolustuksen CI/CD-putkilinjoissa ei ensisijaisesti koske kehittäjävirheiden ehkäisemistä (vaikka se tekeekin senkin). Kyse on turvallisuusarkkitehtuurin toteuttamisesta, jossa salaisuudet eivät koskaan ole selkotekstinä valtuutetun käyttökontekstinsa ulkopuolella, jossa jokainen salaisuuden käyttö auditoidaan, jossa salaisuuksilla on määritellyt elinajat ja ne kierrätetään automaattisesti, ja jossa minkä tahansa yksittäisen salaisuuden vaarantumisella on rajallinen räjähdyssäde lyhyen vanhentumisen ja rajatun pääsyn ansiosta.

Salaisuustyypit puolustuksen putkilinjoissa

Puolustuksen CI/CD-putkilinjat kohtaavat laajemman valikoiman salaisuustyyppejä kuin kaupalliset vastineet, koska niiden käyttöönottamilla järjestelmillä on tiukemmat pääsynhallinta- ja autentikointivaatimukset:

TLS-varmenteet autentikoivat palveluidentiteettejä mTLS-käyttöönotoissa ja suojaavat verkkoviestintää. Puolustuksen Kubernetes-klusterissa palveluverkolla jokaisella mikropalvelulla on oma varmenne, mahdollisesti tuhansia varmenteita yhteensä, kaikki vaativat kierrätystä ennen vanhentumista. Ulkoisia palveluita varten olevien varmenteiden on ketjuttava valtuutettuun CA:han; sisäiset palvelun varmenteet voivat ketjuttua Vaultin tai palveluverkon ohjaustason hallinnoimaan sisäiseen CA:han.

API-avaimet ja käyttötunnukset valtuuttavat palvelu-palvelu-kutsut, pääsyn ulkoisiin uhkatietoyhteisöihin, SIEM API -pääsyn ja integraation luokiteltujen järjestelmien taustajärjestelmien kanssa. Nämä ovat tyypillisesti staattisia salaisuuksia (ei dynaamisesti generoituja) ja todennäköisimmin ilmestyvät lähdekoodiarkistoihin kehittäjävirheen kautta.

Tietokantatunnistetiedot suojaavat pääsyn operatiivisiin ja luokiteltuihin tietokantoihin. Staattiset tietokantatunnistetiedot — käyttäjätunnus ja salasana, joka ei koskaan muutu — ovat merkittävä turvallisuusriski: jos tunnistetiedot vaarantuvat, pääsy jatkuu kunnes tunnistetiedot kierrätetään manuaalisesti, mikä voi tapahtua kuukausien tai vuosien päästä. Dynaamiset tunnistetiedot lyhyillä eliniällä ovat huomattavasti turvallisempia.

Koodin allekirjoitusavaimia käytetään ohjelmistojulkaisujen, konttikuvien, laiteohjelmistopakettien ja konfiguraatioajokorttien allekirjoittamiseen. Nämä avaimet ovat erittäin herkkiä — vaarantunut koodin allekirjoitusavain antaa hyökkääjälle mahdollisuuden allekirjoittaa haitallinen koodi, johon kaikki kyseiseen avaimeen luottavat järjestelmät luottavat. Koodin allekirjoitusavaimet tulisi suojata HSM-laitteistolla ja niiden käyttöön tulisi vaatia useamman osapuolen valtuutus.

HashiCorp Vault: Dynaamiset salaisuudet ja auditointiloki

HashiCorp Vault on standardin mukainen salaisuuksien hallintaalusta puolustuksen DevSecOps-ympäristöille. Vault tarjoaa keskitetyn, auditoidun varaston salaisuuksille, yhtenäisen API:n salaisuuksien hakuun ja dynaamisen salaisuusmoottorin, joka generoi aikarajoitettuja, tarkoituskohtaisia tunnistetietoja sen sijaan, että sovellukset tallentaisivat pitkäikäisiä staattisia salaisuuksia.

Dynaamiset salaisuudet ovat Vaultin tehokkain turvallisuusominaisuus. Sen sijaan, että tallennetaan staattinen tietokantasalasana, jonka sovellukset hakevat, Vault generoi dynaamisesti uuden tietokantakäyttäjän aikarajoitetulla tunnistetiedolla joka kerta, kun sovellus pyytää pääsyä. Tunnistetiedot vanhenevat automaattisesti ja tietokantakäyttäjä peruutetaan vuokra-ajan jälkeen (tyypillisesti 1–24 tuntia). Hyökkääjällä, joka kaappaa dynaamisen tietokantatunnistetiedon, on kapea ikkuna sen hyödyntämiseen ennen vanhentumista; hyökkääjällä, joka kaappaa staattisen tunnistetiedon, on rajoittamaton pääsy kunnes tunnistetiedot kierrätetään manuaalisesti.

Vaultin dynaamiset salaisuusmoottorit kattavat PostgreSQL:n, MySQL:n, MSSQL:n, MongoDB:n, Cassandran, Elasticsearchin (lokinhallinnalle), PKI:n (varmenteen myöntäminen), AWS IAM:in (pilvi-tunnistetiedot) ja muuta. Puolustusympäristöille PKI-salaisuusmoottori — joka mahdollistaa Vaultin toimia väli-CA:na, joka myöntää pyydettäessä lyhytikäisiä TLS-varmenteita — on erityisen arvokas: 24 tunnin TTL:illä myönnetyt varmenteet eliminoivat varmenteen väärinkäytön ikkunan, jos varmenne vaarantuu.

Vaultin auditointiloki tallentaa jokaisen API-kutsun Vault:iin: jokaisen salaisuuspyynnön, jokaisen autentikointiyrityksen, jokaisen politiikkahaun. Auditointiloki on vain lisättävissä eikä Vault-ylläpitäjät voi muokata sitä. Puolustusympäristöille auditointiloki tarjoaa akkreditoinnin edellyttämän todistusketjun: kuka käytti mitä salaisuutta, milloin ja mistä järjestelmästä. Vault-auditointilokeja tulisi välittää SIEM:iin korrelaatiota varten sovellus- ja verkkotapahtumien kanssa.

Laitteiston turvamodulit: Milloin ohjelmistopohjainen Vault on riittämätön

HashiCorp Vault suojaa omat salausavaimensa (pääavain, jota käytetään Vault:in avaamiseen ja salaisuusvaraston salaamiseen) ohjelmistopohjaisella avaimen salausmenetelmällä. Useimmille ympäristöille tämä on riittävä turvallisuus. Puolustusympäristöille, joilla on FIPS 140-2 taso 3 -vaatimukset — joita sovelletaan kansallisiin turvallisuusjärjestelmiin ja järjestelmiin, jotka käsittelevät luokiteltua salausavainmateriaalia — juuriavaimet on suojattava laitteistolla, ei ohjelmistolla.

FIPS 140-2 taso 3 vaatii muokkaussuojatun fyysisen turvallisuuden, identiteettipohjaisen autentikoinnin operaattoreille ja kriittiset turvallisuusparametrit (yksityiset avaimet), joita ei viedä selkotekstinä millään hetkellä. Ohjelmistopohjaiset avainvarastot, vaikka ne olisivatkin hyvin salattuja, eivät täytä tätä vaatimusta, koska salausavain itsessään on ohjelmistomuistissa, jossa etuoikeutettu ohjelmistohyökkääjä voi mahdollisesti päästä siihen käsiksi.

HSM:n auto-avaus Vault:ille on standardiarkkitehtuuri: Vaultin pääavain kääritään HSM-avaimella, ja Vault avautuu automaattisesti lähettämällä käärityn pääavaimensa HSM:lle avaamista varten käynnistyksen yhteydessä. HSM suorittaa salauksen purkamisen muokkaussuojatussa rajassaan — pääavain ei koskaan ole selkotekstinä HSM:n ulkopuolella. Tämä arkkitehtuuri täyttää FIPS 140-2 taso 3 -vaatimukset juuriavaimen suojaustasolla.

Tuettu HSM-integrointi HashiCorp Vault Enterpriselle sisältää Thales (entinen SafeNet) Lunan, nCipher nShieldin, AWS CloudHSM:n ja Azure Dedicated HSM:n. Ilmirakostetuille puolustusympäristöille tarvitaan on-premises HSM -vaihtoehtoja (Thales Luna, nCipher nShield) — pilvipohjaiset HSM-palvelut eivät ole käytettävissä ilmirakostetuista verkoista.

Avainten kierrätys ilman käyttökatkosia

Avainten kierrätys — olemassa olevan salausavaimen korvaaminen uudella — on välttämätöntä turvallisuushygienialle: se rajoittaa altistumisikkunaa, jos avain vaarantuu ja täyttää sääntelyvaatimukset avainten elinikärajoituksille. Mutta avainten kierrätys, joka vaatii sovelluksen käyttökatkoja tai monimutkaista manuaalista koordinointia, lykätään usein toistaiseksi, mikä kumoaa sen turvallisuusarvon.

Vaultin avaimen versiointi mahdollistaa kierrätyksen ilman käyttökatkosia salaisuuksille ja salausavaimille. Kun Vaultin kauttakulkusalauksen moottori (joka tarjoaa sovelluksille salauksen palveluna) kierrättää avaimen, se luo uuden avainversion säilyttäen samalla vanhat versiot aiemmilla versioilla salatun datan purkamiseen. Uutta dataa salaavat sovellukset käyttävät nykyistä avainversiota; olemassa oleva salakirjoitus voidaan edelleen purkaa vanhalla versiolla, kunnes sovellus päivitetään salaamaan se uudelleen. Kierrätys on läpinäkyvä sovellukselle — sen ei tarvitse mennä offline-tilaan.

Siirtymäajat varmenteen kierrätykselle mahdollistavat uusien varmenteiden asteittaisen käyttöönoton: uusi varmenne jaetaan ja siihen luotetaan ennen vanhan varmenteen peruuttamista, joten ei ole ikkunaa, jossa joillakin palveluilla on uusi varmenne ja toiset eivät ole vielä vastaanottaneet sitä. Vaultin PKI-salaisuusmoottori tukee varmenteen TTL:ien ja uusimisjaksojen konfigurointia tämän siirtymäajan hallinnan automatisoimiseksi.

CI/CD-integrointi: Salaisuuksien injektointimallit

Salaisuudet on toimitettava sovelluksille ja infrastruktuurikomponenteille, jotka tarvitsevat niitä, ilman paljastumista CI/CD-putkilinjan lokeissa, ympäristömuuttujien dumppauksissa tai konttikuvakerroksisssa. Kolme integrointimallia hallitsee puolustuksen CI/CD-ympäristöjä:

Vault Agent -sivuvaunu (Kubernetesissa) ottaa käyttöön Vault Agent -kontin sovelluskonttierin rinnalle. Vault Agent autentikoituu Vault:iin podin Kubernetes-palvelutilin identiteetillä, hakee konfiguroitu salaisuudet ja kirjoittaa ne jaettuun muistissa olevaan volyymiin tai injektoi ne sovelluskonttierin ympäristöön. Salaisuudet eivät koskaan näy pod-spesifikaatiossa tai konttikuvassa — ne injektoidaan ajon aikana Vault:ista.

External Secrets Operator on Kubernetes-operaattori, joka synkronoi salaisuudet ulkoisista salaisuusvarastoista (Vault, AWS Secrets Manager, Azure Key Vault) Kubernetes Secretsiin. Se tarjoaa deklaratiivisen, GitOps-yhteensopivan lähestymistavan: ExternalSecret-mukautettu resurssi GitLab/Kubernetes-konfiguraatiossa ilmoittaa mitä salaisuuksia tarvitaan ja mistä ne tulevat; operaattori käsittelee haun ja synkronoinnin. Operaattorin luomat Kubernetes Secrets voidaan liittää podeihin normaalisti.

GitLab CI -putkilinjoille GitLab-Vault-integrointi (GitLab CI/CD Vault -integrointi, käyttäen JWT-autentikointia) mahdollistaa putkilinjatyöt autentikoitua Vault:iin GitLab JWT -identiteetillään ja hakea salaisuudet putkilinjatyön keston ajaksi. Salaisuudet ovat saatavilla ympäristömuuttujina työn sisällä eikä niitä koskaan tallenneta GitLab CI -konfiguraatioon tai arkistoon.