Älä liitä API-avainta chattiin tai sähköpostiin. Lähetä se kertakäyttöisenä salaisena linkkinä: avain salataan selaimessasi, purkuavain pysyy linkin #-merkin jälkeisessä osassa, ja tallennettu kopio tuhotaan ensimmäisen avauksen jälkeen. Vaihda sen jälkeen jokainen avain, joka on jo liitetty johonkin selväkielisenä.
Loppuosa oppaasta käy läpi yksityiskohdat: miksi ilmeiset kanavat pettävät, miten luovutus tehdään vaihe vaiheelta, mitä tehdä, kun avain silti vuotaa, ja milloin kertakäyttölinkki on väärä työkalu.
Miksi API-avaimen lähettäminen Slackissa tai sähköpostilla ei ole turvallista?
Koska molemmat säilyttävät viestin niin kauan kuin jokin sitä säilyttää, ja kopioivat sen matkan varrella jokaiselle laitteelle ja jokaiseen vientiin.
- Molemmista voi hakea ikuisesti. Vuonna 2023 jaettu avain on
seuraavan tietoturvapoikkeamasi lähde. Hyökkääjät, jotka
pääsevät yrityksen chattiin tai postilaatikkoon, hakevat sieltä
rutiininomaisesti juuri niitä merkkijonoja, joilta API-avaimet
näyttävät:
sk_live,AKIA,ghp_,Bearer. - Molemmat synkronoituvat kaikkialle. Puhelimiin, henkilökohtaisiin kannettaviin ja tabletteihin eli laitteisiin, joita tietoturvakäytäntösi eivät kata ja joita etätyhjennyskäytäntösi ei tavoita.
- Molemmista tehdään vientejä. Vaatimustenmukaisuuden tarkastukset, oikeudenkäyntien aineistopyynnöt ja työtilan viennit tuottavat kaikki kopioita historiasta. Jokainen vienti on yksi paikka lisää, jossa avain on tallessa.
- Molemmat säilyvät, vaikka työsuhde päättyy. Alihankkijan toimeksianto loppuu, mutta yksityisviestiketju, jossa on Stripe-avaimesi, ei katoa.
Kun salaisuuden laittaa kumpaan tahansa työkaluun, hyväksyy samalla, että salaisuus on tallessa kaikkialla, minne viesti päätyy, niin kauan kuin jokin sitä säilyttää. Kumpaakaan järjestelmää ei ole suunniteltu unohtamaan.
Ennen jakamista: pienennä avaimen oikeuksia
Paras luovutus on sellainen, jossa luovutettavalla avaimella ei juuri ole merkitystä. Sovella vähimpien oikeuksien periaatetta jo lähteessä, ennen kuin luot mitään:
- Rajaa oikeudet. Stripen rajoitetut avaimet, GitHubin tarkkarajaiset henkilökohtaiset käyttötunnisteet ja tiettyihin toimintoihin ja resursseihin rajatut AWS IAM -käytännöt: useimmissa vakavasti otettavissa palveluissa voi luoda avaimen, joka pystyy tekemään vain sen yhden asian, jota vastaanottaja tarvitsee.
- Suosi vain luku -oikeutta, ellei kirjoitusoikeutta todella tarvita.
- Aseta palveluntarjoajan puolelle voimassaoloaika, jos alusta sen sallii (GitHubin tarkkarajaiset PAT-tunnisteet, AWS:n tilapäiset kirjautumistiedot STS:n kautta). Silloin vuotaneellakin avaimella on käyttöikä, joka ei riipu mistään, mitä teet myöhemmin.
- Nimeä avain vastaanottajan mukaan (
vendor-x-readonly), jotta sen mitätöinti puolen vuoden päästä on yhden vilkaisun päätös eikä arkeologinen kaivaus.
Kun avain on rajattu, vanhenee ja sallii vain lukemisen, pahinkin vuoto on harmi eikä tietoturvapoikkeama.
Luovutuksen kaava
- Luo avain lähdejärjestelmässä (AWS, Stripe, oma API) pienimmillä mahdollisilla oikeuksilla, kuten yllä.
- Liitä se kertakäyttöiseen salaiseen linkkiin, kytke päälle asetus ”Tuhoa lukemisen jälkeen” ja valitse lyhin sopiva voimassaoloaika: lyhin valmis vaihtoehto on 1 tunti, sen jälkeen tulevat 24 tuntia ja 7 päivää, ja Pro-paketissa voi valita oman päivän ja kellonajan. Juuri sen verran kuin luovutus vaatii, ei enempää.
- Lisää salalause ja toimita se eri kanavaa pitkin: linkki sähköpostilla, salalause tekstiviestillä tai Slackin yksityisviestillä. LinkPilotissa salalause, oma voimassaoloaika ja tarkastusloki kuuluvat Pro-pakettiin, joka maksaa 29 $ kuukaudessa. Jos toinen kanava vuotaa, hyökkääjällä on silti vain puolet palapelistä. (LinkPilot laskee salalauseesta SHA-256-tiivisteen selaimessa ennen lähetystä. Salalause itse ei koskaan päädy palvelimen tietokantaan tai lokeihin, ja yrityksiä sallitaan enintään 5 minuutissa yhdestä IP-osoitteesta.)
- Lähetä linkki.
- Varmista toista kanavaa pitkin, että vastaanottaja sai avaimen, ja tarkista tarkastusloki eli loki linkin tapahtumista: yksi avaus, odotettuun aikaan, odotetusta paikasta. Se on kuittisi.
Jos linkkiä ei avata ennen kuin se vanhenee, mitätöi se ja lähetä uusi. Älä pidennä voimassaoloaikaa äläkä käytä linkkiä uudelleen.
Esimerkki: Stripen rajoitetun avaimen välittäminen
# generate a restricted key with the minimum needed scopes
stripe api_keys create \
--restricted \
--display-name "vendor-x-readonly"
# pipe the resulting key into a LinkPilot secret
curl -X POST https://api.uselinkpilot.com/v1/secrets \
-H "Authorization: Bearer $LP_KEY" \
-d 'payload=sk_restricted_…' \
-d 'expires_in=3600' \
-d 'burn_after_read=true'
Mitä vastaanottaja näkee: linkki avaa sivun, jolla on Näytä-painike,
ei avainta. Linkkien esikatselutoiminnot ja sähköpostin tarkistimet,
jotka hakevat URL-osoitteen etukäteen, saavat vain metatiedot, koska
avaus kirjataan ainoastaan erillisestä näyttämistoiminnosta eikä
koskaan GET-pyynnöstä. Kun vastaanottaja napsauttaa painiketta
”Näytä” (ja kirjoittaa salalauseen, jos sellainen on asetettu), hän
näkee avaimen täsmälleen kerran. Sen jälkeen tallennettu sisältö
ylikirjoitetaan, ja linkki palauttaa HTTP-tilakoodin 410. Vaikka
sähköposti kiertäisi koko yrityksessä, vain ensimmäinen avaaja on
voinut lukea avaimen, ja tarkastuslokista näet, kuka se oli.
Mikä kanava mihinkin luovutukseen
| Tilanne | Suositeltu tapa | Huomioita |
|---|---|---|
| Työkaveri samassa huoneessa tai puhelussa | Kertakäyttölinkki, voimassaoloaika 1 tunti (lyhin valmis vaihtoehto) | Salalause on vapaaehtoinen, koska voit varmistaa vastaanoton saman tien |
| Etänä työskentelevä työkaveri | Kertakäyttölinkki + salalause toista kanavaa pitkin | Voimassaoloaika 1 tunti |
| Alihankkija tai toimisto | Rajattu avain + kertakäyttölinkki + salalause | Nimeä avain alihankkijan mukaan ja merkitse mitätöinti kalenteriin toimeksiannon päättymispäivälle |
| Asiakas, joka saa oman avaimensa | Kertakäyttölinkki sovelluksestasi tai asiakastuen kautta | Voimassaoloaika 24 tuntia; neuvo asiakasta tallentamaan avain heti |
| CI/CD-putki tai palvelu | Alustan oma salaisuuksien säilö (Actions secrets, Vault, ASM) | Ei koskaan linkkiä, koska koneet eivät tee luovutuksia |
| Koko tiimi, jatkuva käyttö | Salasanojen hallintaohjelman holvi | Tämä on säilytystä ja käyttöoikeuksien hallintaa, ei luovutus |
Mitä tehdä, jos API-avain vuotaa?
Pidä avainta vuotaneena ja vaihda se palveluntarjoajalla. Viestin poistaminen ei auta mitään. Jokainen avain, joka on ollut chattiviestissä, sähköpostin tekstissä, kuvakaappauksessa, git-commitissa tai julkisessa tekstinjakopalvelussa, lasketaan vuotaneeksi. Toimi tässä järjestyksessä:
- Luo korvaava avain ensin, jos palveluntarjoaja sallii kaksi aktiivista avainta. Näin oikeat käyttäjät eivät kärsi katkoksesta.
- Mitätöi vuotanut avain palveluntarjoajalla. Vain tämä vaihe oikeasti lopettaa altistuksen. Slack-viestin poistaminen ei sitä tee.
- Luovuta uusi avain oikein: kertakäyttölinkki, salalause ja lyhyt voimassaoloaika, kuten yllä kuvattiin.
- Tarkista palveluntarjoajan käyttölokit vuotaneen avaimen osalta vuodon ja mitätöinnin väliltä. Odottamattomat kutsut tarkoittavat, että kyse on nyt tietoturvapoikkeamasta eikä pelkästä siivouksesta.
- Korjaa se, mikä sai avaimen liitetyksi: siirrä salaisuus
ympäristömuuttujatyökaluihin, jotka on lisätty tiedostoon
.gitignore, ota käyttöön salaisuuksien skannaus koodivarastosi palvelussa tai päivitä ohje, joka käski lähettämään avaimen yksityisviestillä.
Koko kierroksen pitäisi viedä minuutteja. Jos avaimen vaihtaminen on niin pelottavaa, että sitä vältellään, todellinen haavoittuvuus on juuri tuo hauraus. Korjaa se ensin.
Mitä välttää
- Saman salaisuuden lähettäminen uudelleen. Vaihda avain sen sijaan. Uudelleenlähetyksen jälkeen tarkastusloki ei enää todista ”täsmälleen yhtä altistusta”, ja juuri sen takia kertakäyttölinkkiä kannatti käyttää.
- Pitkät voimassaoloajat. Valitse oletuksena lyhyt. Useimmat luovutukset valmistuvat minuuteissa, ja 8 tunnin aikaikkuna on vain pidempi vuoto.
- Salalauseen jättäminen pois. Se ei maksa juuri mitään ja suojaa vahingossa vuotaneilta URL-osoitteilta: edelleen lähetetyiltä sähköposteilta, näytönjaoilta ja olan yli kurkkimiselta jaetulla näytöllä.
- Kuvakaappaukset avaimista. Ne päätyvät kamerarullaan, kuvien pilvisynkronointiin ja kuvahakuun. Kuvakaappaus on yhtä pysyvä kuin chattiin liitetty teksti, mutta sinun on vaikeampi löytää se, kun taas tekstintunnistus löytää sen hyvin.
- Linkkityökalun käyttäminen säilytykseen. Linkki on kuriiri, ei holvi. Vastaanottajan pitää tallentaa avain salasanojen hallintaohjelmaan tai ympäristömuuttujatyökaluihin heti, kun hän saa sen.
Milloin kertakäyttölinkki on väärä työkalu
Rehellisesti sanottuna tälläkin kaavalla on rajansa:
- Koneiden väliset kirjautumistiedot kuuluvat salaisuuksien hallintaohjelmaan tai alustan omaan säilöön, josta ne syötetään käyttöönoton tai ajon aikana. Linkkiä napsauttava ihminen ei ole käyttöönoton vaihe.
- Pitkäikäiset jaetut kirjautumistiedot kuuluvat salasanojen hallintaohjelmaan, jossa käyttöoikeuksia hallitaan kunnolla ja ne voi mitätöidä henkilö kerrallaan.
- Tiheä kierrätys (avaimet, jotka vaihtuvat tunneittain) kannattaa automatisoida alusta loppuun. Ihmisten ja linkkien ei pitäisi olla siinä mukana lainkaan.
- Salaisuudet, joihin ei saa koskea mikään kolmas osapuoli: siirrä luovutus verkon ulkopuolelle. Päivitys 29. syyskuuta 2026: tässä kohdassa luki alun perin, ettei LinkPilot väitä tarjoavansa päästä päähän -salausta, ja kehotettiin käyttämään päästä päähän salattua työkalua. Nykyään LinkPilot salaa tekstisisällön ja liitetiedostot selaimessa, joten se tallentaa vain salatekstiä. Sivu Tietoturva-arkkitehtuuri kertoo tarkalleen, mikä on suojattu ja mikä ei.
Tavallisessa tapauksessa, kun yksi ihminen luovuttaa yhdet kirjautumistiedot toiselle ihmiselle kerran, kertakäyttölinkki salalauseella ja lyhyellä voimassaoloajalla on vahvin saatavilla oleva yksinkertainen kaava.
Lue myös
- Miksi URL-osoitteet vuotavat arkaluonteisia tietoja
- Turvallinen salasanojen jakaminen: 5 tapaa vertailussa
- LinkPilotin tietoturva-arkkitehtuuri
- Lyhytlinkkipalvelujen API-vertailu
- Ilmainen salaisen linkin generaattori
Lähteet
- Stripe Docs, API keys: limit access with restricted keys.
- GitHub Docs, Managing your personal access tokens.
- AWS IAM User Guide, Temporary security credentials in IAM.