Turvallinen linkkien jakaminen kehittäjille

Kehittäjän työssä salaisuuksien jakaminen tulee yleensä vastaan kolmessa paikassa: perehdytyksessä, luovutuksessa toimittajalle ja häiriötilanteissa. Tässä on kehittäjän näkökulma siihen, milloin kertakäyttölinkki kannattaa ottaa käyttöön, milloin sen voi jättää väliin ja miten sen luonti skriptataan niin, ettei salaisuus vuoda matkalla komentohistoriaan. Jos haluat ensin kokeilla mekanismia, ilmainen kertakäyttöisten salaisten linkkien luontityökalu toimii ilman tiliä.

Milloin kehittäjän kannattaa käyttää kertakäyttölinkkiä?

Kun luovutuksen ainakin toisessa päässä on ihminen eikä arvon pidä säilyä missään luovutuksen jälkeen. Tavallisimmat tapaukset:

• Uuden kehittäjän perehdytys ja hänen ensimmäiset tunnuksensa.
• Väliaikaisen pääkäyttäjän salasanan jakaminen häiriötilanteessa.
• Toimittajan tai alihankkijan tunnisteen luovuttaminen, kun sen ei pidä jäädä holviisi.
• Tunnuksen vaihto, kun vanhan arvon pitää lakata toimimasta pian.
• API-avaimen lähettäminen asiakkaalle, jolle loit sen.

Milloin kertakäyttölinkkiä ei kannata käyttää

• Koneelta koneelle kulkevat salaisuudet. Niihin oikea perusratkaisu on CI:n ympäristömuuttujat (esimerkiksi GitHub Actions -salaisuudet), Kubernetes Secrets ja Vaultin dynaamiset tunnukset. Linkki on tarkoitettu siihen, kun ihminen vie tiedon näihin järjestelmiin.
• Tiimin pitkäikäiset tunnukset. Ne kuuluvat salasanojen hallintaohjelmaan.
• Julkiset asetukset. Älä naamioi asetuksia salaisuudeksi, jos ne eivät ole salaisia. Käytä tavallista linkkiä.

Raja kulkee näin: jos siirron molemmissa päissä on kone, käytä alustasi salaisuusvarastoa. Jos ainakin toisessa päässä on ihminen, kertakäyttölinkki on yleensä siistein ratkaisu.

Skriptaus

LinkPilotissa on REST API (kaikissa paketeissa, myös Free-paketissa). Salaisuuden luonti skriptistä näyttää tältä:

LP_KEY=lp_live_...

URL=$(curl -sS https://api.uselinkpilot.com/v1/secrets \
  -H "Authorization: Bearer $LP_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "payload": "'"$NEW_DB_PASSWORD"'",
    "expires_in": 3600,
    "burn_after_read": true,
    "passphrase": "'"$ONBOARDING_PASSPHRASE"'"
  }' | jq -r '.url')

echo "Secret link: $URL"

Ohjaa URL-osoite siihen toimituskanavaan, jota jo käytät: Slackin yksityisviestiin, sähköpostiin tai perehdytystyökalusi webhookiin.

Sisältö pois prosessilistasta

Yllä olevassa koodissa on klassinen virhe: kun sisältö upotetaan valitsimeen -d, se päätyy curlin komentoriville, jolta kuka tahansa paikallinen käyttäjä voi lukea sen komennolla ps pyynnön ollessa käynnissä. Rakenna JSON sen sijaan jq-työkalulla ja syötä se vakiosyötteestä curlin valitsimella -d @-:

set -euo pipefail

jq -n --arg payload "$NEW_DB_PASSWORD" \
      --arg pass "$ONBOARDING_PASSPHRASE" \
      '{payload: $payload, expires_in: 3600,
        burn_after_read: true, passphrase: $pass}' |
curl -sS https://api.uselinkpilot.com/v1/secrets \
  -H "Authorization: Bearer $LP_KEY" \
  -H "Content-Type: application/json" \
  -d @- | jq -r '.url'

Kolme tapaa, joiden pitäisi olla selkäytimessä:

• Arvot tulevat ympäristömuuttujista tai salaisuuksien hallinnan CLI-työkalusta, eikä niitä koskaan kirjoiteta interaktiiviseen komentotulkkiin, josta ne jäävät historiaan.
• Skripti tulostaa linkin, ei koskaan sisältöä.
• Rivi set -euo pipefail estää epäonnistunutta API-kutsua välittämästä tyhjää URL-osoitetta huomaamatta seuraavaan vaiheeseen.

Perehdytyksen malli

Toimintatapa, joka toimii hyvin uusille kehittäjille ensimmäisenä päivänä:

1. Perehdytysskripti luo käyttäjätilit ja hakee kertakäyttöiset tunnukset.
2. Skripti luo jokaiselle tunnukselle oman salaisen linkin, jonka voimassaoloaika on 4 tuntia ja jolla on yhteinen salalause.
3. Skripti lähettää sähköpostin, jossa ovat kaikki linkit, ja salalauseen Slackin yksityisviestillä.
4. Kehittäjä avaa jokaisen linkin ja kopioi tunnuksen salasanojen hallintaohjelmaansa.
5. Kaikki, mitä ei ole avattu työpäivän loppuun mennessä, mitätöidään ja lähetetään uudelleen hänen tahtiinsa.

Miksi juuri nämä asetukset: 4 tunnin voimassaoloaika riittää tavalliseen ensimmäiseen aamupäivään, eivätkä tunnukset jää yöksi voimaan. Salalause kulkee toista kanavaa pitkin, joten edelleen lähetetystä tai väärään osoitteeseen menneestä sähköpostista ei ole haittaa. Koska linkit tuhoutuvat lukemisen jälkeen, kehittäjän postilaatikossa on päivän päätteeksi vain toimimattomia URL-osoitteita.

Kerro uudelle työntekijälle suoraan: ”jokainen linkki toimii kerran, tallenna arvo salasanojen hallintaohjelmaan ennen kuin suljet välilehden.” Yleisin perehdytyksen virhe on vastaanottaja, joka lukee salaisuuden, sulkee välilehden ja olettaa voivansa palata siihen myöhemmin.

Vaihdon toimintaohje

Jaetun tietokantasalasanan vaihto, kun vastaanottajana on alihankkija tai työkaveri:

1. Luo uusi salasana ja ota se käyttöön lähdejärjestelmässä (tietokanta, pilvikonsoli tai mikä tahansa virallinen lähde).
2. Päivitä ensin omat käyttökohteesi, kuten CI:n holvi, K8s-secret ja sovelluksen asetukset, jotta mikään ei hajoa ihmisten välisen luovutuksen aikana.
3. Luo uudelle arvolle kertakäyttölinkki: tuhoutuu lukemisen jälkeen, voimassaoloaika 1 tunti, salalause.
4. Toimita linkki ja salalause eri kanavia pitkin.
5. Tarkista avaustapahtuma tarkastuslokista. Eikö linkkiä avattu ennen vanhenemista? Mitätöi se ja lähetä uusi. Älä koskaan lähetä samaa linkkiä uudelleen.
6. Varmista, että vanha tunnus on poistettu käytöstä lähteessä.

Jokainen vaihto saa oman linkkinsä. Linkit ovat tarkoituksella toisistaan riippumattomia. Toimituksessa se on etu, hallinnassa puute, joten vaihtojen aikataulu kuuluu hallintaohjelmaan tai toimintaohjeeseen eikä linkkityökaluun.

Häiriötilanteet

Häiriötilanteessa tunnus pitää usein vaihtaa ja uusi arvo jakaa nopeasti muutamalle selvittäjälle. Älä liitä sitä häiriökanavaan. Kanavan keskustelu tallennetaan jälkikäteistä analyysia varten, ja salaisuus päätyy vientitiedostoon, retrospektiivin muistioon ja jokaiseen niistä eteenpäin kulkevaan säilytysjärjestelmään.

• Vaihda tunnus lähdejärjestelmässä.
• Luo salainen linkki, jonka voimassaoloaika on 30 minuuttia.
• Lähetä linkki kanavaan ja lähetä salalause yksityisviestillä.
• Varmista häiriön jälkeen, että linkki on tuhoutunut tai mitätöity.

Jälkianalyysissa on silloin toimimaton URL-osoite eikä voimassa olevaa pääkäyttäjän salasanaa. Lisäksi tarkastuslokista saa ilmaiseksi tarkan merkinnän aikajanan läpikäyntiin: ”tunnus annettu uudelleen klo 14:32, avattu klo 14:33”.

Yksi huomio linkkien esikatselusta: chat-sovellukset hakevat liitetyt URL-osoitteet esikatselun luomiseksi. Hyvin suunniteltu salainen linkki kestää tämän, koska esikatselu tekee GET-pyynnön ja näyttäminen vaatii erillisen POST-pyynnön. Koko mekanismi on kuvattu artikkelissa linkkiskannerit ja kertakäyttöiset salaisuudet. Jos arvioit työkalua, testaa tämä ennen häiriötilannetta, älä sen aikana.

Mitä tarkastusloki kertoo?

Sen, avattiinko salaisuus, milloin ja suunnilleen mistä, ja yrittikö joku väärää salalausetta. Jokaisella LinkPilot-salaisuudella on tapahtumien aikajana: created, viewed, failed_passphrase, burned, expired, revoked. Avauksista tallennetaan aikaleima, karkea sijainti, kun se on saatavilla, selaimen käyttäjäagentti ja IP-osoitteen tiiviste (SHA-256 päivittäin vaihtuvalla suolalla; alkuperäistä IP-osoitetta ei tallenneta koskaan). Käytännössä tästä saa kolme vastausta, joihin skriptit ja toimintaohjeet voivat luottaa:

• Toimitusvahvistus: viewed-tapahtuma tarkoittaa, että luovutus tapahtui.
• Poikkeamien havaitseminen: failed_passphrase-tapahtumien sarja tai avaus, jota et tunnista, on merkki siitä, että tunnus pitää vaihtaa heti.
• Selkeä merkintä tarkastuksia varten: ”toimitettu kerran, avattu kerran, tuhoutunut” on lause, josta tarkastajat pitävät.

Rajoitukset: mitä linkit eivät ratkaise

• Ne eivät ole holvi. Kertakäyttölinkki ei hallitse jatkuvaa pääsyä, vaihtojen aikatauluja eikä luetteloa siitä, kenellä on mitäkin.
• Linkki on avain. LinkPilot salaa tekstisisällön selaimessasi eikä koskaan saa avainta, mutta avain kulkee linkin #-merkin jälkeisessä osassa. Kuka tahansa, joka saa koko linkin, voi siis lukea salaisuuden, ja jos linkki katoaa, salaisuutta ei voi palauttaa. Liitetiedostot salataan samalla tavalla, mutta niiden nimiä ja kokoja ei salata. Lyhyellä voimassaoloajalla ja lukemisen jälkeisellä tuhoutumisella on silti merkitystä. Päivitys 29. syyskuuta 2026: tässä kohdassa luki aiemmin ”niitä ei salata päästä päähän”, mikä piti paikkansa siihen päivään asti. Yksityiskohdat ovat sivulla tietoturva-arkkitehtuuri.
• Ne eivät korjaa koodiin levinneitä salaisuuksia. Repoihin kovakoodatut avaimet vaativat skannausta ja vaihtamista, eivät parempaa toimitustapaa.
• Ne eivät suojaa sitä, mitä vastaanottajan päässä tapahtuu. Kun ihminen on lukenut arvon, oleta sen olevan kaikkialla, minne hän sen laittoi.

Lue myös

• Näin jaat API-avaimet turvallisesti
• Vanhenevat linkit: miksi lyhyt voimassaoloaika on tärkeä
• LinkPilotin tietoturva-arkkitehtuuri

Lähteet

• GitHub Docs, Using secrets in GitHub Actions.
• Kubernetes, Secrets.
• jq, Manual.
• curl, Manual page, -d, --data.