Yli 9 300 julkisuuteen vuotanutta AWS-avainta oli yhä käyttökelpoisia

Julkisuuteen päätynyt AWS-tunnus ei ollut tutkimuksessa useinkaan hetkellinen vahinko. Truffle Securityn elokuun 2022 ja elokuun 2026 väliseen aineistoon perustuva selvitys osoitti, että monet avaimet säilyivät voimassa vuosia – osa niistä niin laajoilla oikeuksilla, että niiden avulla olisi ollut mahdollista ottaa yrityksen AWS-tili hallintaan.

Julkinen vuoto muuttui pitkäkestoiseksi riskiksi

Truffle Security keräsi julkisista lähteistä 431 875 AWS-salaisuuden esiintymää. Mukana oli koodirepositorioita, Git-historiaa, julkaistuja aineistoja, Docker-kuvia, konttirekistereitä ja jatkuvan integraation eli CI:n lokeja. Kaksoiskappaleiden poistamisen jälkeen aineisto sisälsi 64 024 yksilöllistä AWS-käyttöavainta, jotka liittyivät 50 654 AWS-tiliin.

Tutkijat pystyivät varmistamaan 10 616 täydellistä avainparia. Kun tunnukset testattiin uudelleen 10. elokuuta, 88 % niistä onnistui edelleen todentautumaan. Tämä tarkoittaa, että yli 9 300 julkisuuteen päätynyttä avainta oli yhä käyttökelpoinen.

Pelkkä avaimen löytyminen julkisesta repositoriosta ei vielä kerro, onko se vaarallinen. Riski muuttuu aktiiviseksi, kun avainta ei ole peruttu, se kelpaa edelleen kirjautumiseen ja sillä on merkittäviä oikeuksia. Tutkimuksessa nämä kolme ehtoa toteutuivat usein yhtä aikaa.

768 avainta tarjosi yritystilille täyden hallinnan

Yritysten tileihin liittyneistä toimivista avaimista 817 kuului yrityksille. Niihin sisältyi:

• 526 AWS root -tilin avainta
• 242 IAM-käyttäjän avainta, joihin oli liitetty AWS:n AdministratorAccess-käytäntö
• yhteensä 768 avainta, joilla oli täydet hallintaoikeudet yrityksen AWS-tiliin

AWS:n root-tunnukset ovat asiakkaan käytettävissä olevista tunnuksista korkeimman tason käyttöoikeuksia. AdministratorAccess puolestaan antaa IAM-identiteetille laajat oikeudet eri AWS-palveluihin. Voimassa oleva avain kummallakin tasolla voi avata tien tilin kaappaukseen, luvattomaan resurssien luomiseen, tietojen käyttöön tai pilvilaskun väärinkäyttöön.

Tulokset kertovat ennen kaikkea käyttöoikeuksien ja tunnusten elinkaaren hallinnan ongelmasta – eivät vain huolimattomuudesta lähdekoodissa. Avaimen poistaminen näkyvästä tiedostosta ei suojaa tiliä, jos joku on ehtinyt kopioida sen. Tunnus on peruttava tai vaihdettava.

Hugging Face oli suurin yksittäinen lähde

Hugging Facesta löytyi 8 482 AWS-tunnusten altistumista, enemmän kuin mistään muusta yksittäisestä lähteestä. Truffle Securityn mukaan 17,9 % näistä AWS-tunnuksista oli root-tunnuksia.

Löydökset liittyvät yhtiön laajempaan julkisten Hugging Face -aineistojen tarkistukseen. Truffle Security kertoi tutkineensa 7,6 petatavua dataa ja löytäneensä toimivia tunnuksia tuhansista aineistoista. Tapaus osoittaa, että salaisuudet eivät pysy vain tavanomaisissa ohjelmistorepositorioissa, vaan voivat levitä myös julkisesti jaeltaviin data-aineistoihin.

Turvatiimeille viesti on selvä: pelkkä nykyisten lähdekoodirepositorioiden tarkistaminen ei riitä. Git-historia, koontituotokset, konttikuvat, rekisterit, julkaistut aineistot ja CI:n tulosteet voivat säilyttää tunnuksia senkin jälkeen, kun kehittäjät luulevat poistaneensa ne.

Vanhimmat avaimet olivat lähes kaksi vuosikymmentä vanhoja

Raportoitu tunnusten mediaani-ikä oli noin 1 831 päivää, eli suunnilleen viisi vuotta. Vanhin avain oli 17,4 vuotta vanha. Vain 13,7 %:lla havainnoista oli samaan käyttäjään liittyvä uudempi avain, mikä viittaa siihen, ettei suurinta osaa tunnuksista ollut vaihdettu normaalin kierrätysprosessin mukaisesti.

Pitkään voimassa olevat käyttöavaimet pidentävät aikaa, jonka ajan niitä voidaan käyttää luvatta, ja vaikeuttavat omistajan selvittämistä. Ne voivat säilyä työntekijöiden vaihtumisesta, sovellussiirroista, repositorioiden siivoamisesta ja vastuualueiden muutoksista huolimatta.

Ikää onkin syytä pitää riskisignaalina. Useita vuosia vanhaa vuotanutta avainta ei pidä olettaa vanhentuneeksi, vaan sen voimassaolo on tarkistettava ja avain peruttava. Samalla on selvitettävä, onko sitä käytetty väärin.

Budjettihälytykset olivat harvinaisia

Truffle Security pystyi lukemaan tilitietoja 2 754 AWS-tililtä, mutta vain 262:ssa oli AWS:n budjettihälytykset käytössä.

Budjettihälytys ei korvaa tunnuksen perumista tai uhkien havaitsemista. Se voi kuitenkin varoittaa nopeasti, jos vuotanutta avainta käytetään kalliiden resurssien luomiseen esimerkiksi kryptolouhintaa varten. Ilman toimivaa ilmoitusketjua poikkeava kulutus voi jatkua senkin jälkeen, kun tili on vaarantunut.

Mitä AWS:n ilmoitukset ratkaisevat – ja mitä eivät

Raportoinnin mukaan AWS:n vuotaneita käyttöavaimia koskevat suojaukset voivat havaita paljastuneen avaimen, ilmoittaa asiasta asiakkaalle ja asettaa rajoituksia tai eristystoimia. Se, että niin monet testatuista avaimista olivat edelleen voimassa, viittaa kuitenkin siihen, ettei havainto johtanut johdonmukaisesti nopeaan asiakkaan tekemään perumiseen tai vaihtamiseen.

Havaitseminen on vasta tunnereaktion ensimmäinen vaihe. Perusteellinen toimintamalli edellyttää omistajan tunnistamista, avaimen käyttöoikeuksien selvittämistä, mahdollisen väärinkäytön tarkistamista ja tunnuksen mitätöintiä.

Truffle Security luonnehtii omaa validointiaan vain luku -testaukseksi: tutkijat tarkistivat tunnusten toimivuuden sekä tili- ja käyttöoikeusmetatietoja, mutta eivät muokanneet asiakkaiden resursseja. Tämä on Truffle Securityn kuvaus menetelmästä, eikä kaikkiin sen operatiivisiin yksityiskohtiin ole tässä aineistossa riippumatonta vahvistusta.

Mitä organisaation kannattaa tehdä AWS-avaimen vuotaessa?

1. Peru tai vaihda avain heti

Poista käytöstä tai poista kaikki julkisuuteen päätyneet tunnukset. Luo korvaava tunnus vain, jos käyttöä todella tarvitaan. Salaisuuden poistaminen repositoriosta, tiedoston deletointi tai Git-historian uudelleenkirjoittaminen ei mitätöi jo kopioitua avainta.

2. Poista root-käyttöavaimet

AWS:n root-käyttäjän käyttöavaimia ei pidä käyttää tavalliseen ohjelmalliseen käyttöön. Poista root-avaimet ja siirrä työkuormat hallittuihin identiteetteihin, joille annetaan vain tarvittavat oikeudet.

3. Selvitä oikeudet ja omistaja

Tarkista, mihin tiliin, käyttäjään, palveluun ja resursseihin avain liittyi. Aseta etusijalle root-oikeudet, AdministratorAccess-käytäntö, laaja pääsy dataan tai oikeus luoda infrastruktuuria sisältävät tunnukset.

4. Tutki tapahtumat ennen ja jälkeen perumisen

Käy läpi todennustapahtumat, CloudTrail-lokit, IAM-muutokset, uudet resurssit ja laskutus. Avaimen peruminen estää sen tulevan käytön, mutta ei kerro, ehdittiinkö sitä käyttää ennen perumista.

5. Siirry pitkäikäisistä avaimista lyhytkestoisiin identiteetteihin

Käytä pysyvien käyttöavainten sijaan mahdollisuuksien mukaan lyhytkestoisia IAM-rooleja ja työkuormien identiteettejä. Pienimmän oikeuden periaate rajoittaa vahinkoa, jonka vuotanut tunnus voi aiheuttaa.

6. Ota käyttöön budjetti- ja kustannushälytykset

Määritä AWS Budgets -hälytykset ja kustannuspoikkeamien seuranta. Ohjaa ilmoitukset henkilöille, jotka pystyvät reagoimaan nopeasti. Talouden seuranta on viimeinen turvaverkko – ei korvaaja salaisuuksien skannaukselle, avainten vaihdolle tai käyttöoikeuksien tarkistukselle.

Suurempi tietoturvaopetus

Tutkimuksen tärkein havainto ei ollut pelkkä salaisuuksien määrä. Huolestuttava yhdistelmä oli julkinen altistuminen, tunnusten jatkuva voimassaolo, korkeat oikeudet, poikkeuksellinen ikä ja heikko seuranta. Julkiset datavarastot voivat säilyttää tunnuksia kauan sen jälkeen, kun organisaatio on unohtanut, missä niitä käytettiin. Kopioitu avain voi puolestaan pysyä käyttökelpoisena, kunnes se nimenomaisesti perutaan.

Pilvipalveluita käyttävien organisaatioiden turvallisin oletus on yksinkertainen: käsittele jokaista julkisuuteen vuotanutta AWS-tunnusta vaarantuneena, selvitä sen ulottuvuus, peru tai vaihda se välittömästi ja korvaa pitkäikäiset avaimet lyhytkestoisilla, mahdollisimman vähäoikeuksisilla identiteeteillä.