Webhookin allekirjoitussalaisuuden lähettäminen asiakkaalle turvallisesti

Webhookin allekirjoitussalaisuus on kirjautumistieto eikä mikä tahansa asetus. Lähetä se samalla tavalla kuin salasana: varmista, kuka sen vastaanottaa, luovuta se kanavaa pitkin, johon ei jää kopioita, ja huolehdi, että se päätyy salaisuuksien säilöön eikä tikettiin. Lyhyesti: kertakäyttöinen salainen linkki varmistetulle yhteyshenkilölle ja asennusohjeet erikseen.

Tämä opas käy läpi kanavan valinnan, tarkistukset ennen lähettämistä, sen, mitä asiakkaan pitää tehdä arvolla, sekä salaisuuden vaihtamisen ja vianmäärityksen niin, ettei salaisuutta tarvitse liittää mihinkään uudelleen.

Mitä kanavaa pitkin salaisuus kannattaa lähettää?

Valitse kanava kahdella kysymyksellä: voitko varmistaa, kuka sen voi avata, ja kuinka monta kopiota siitä jää jälkeen? Sähköposti ja chat eivät läpäise jälkimmäistä, koska jokainen viesti säilytetään, synkronoidaan ja viedään muihin järjestelmiin vielä kauan luovutuksen jälkeen.

Asiakasportaali, jossa on henkilökohtaiset tunnukset, on hyvä ensisijainen vaihtoehto, jos sellainen on käytössä. Anna käyttöoikeus nimetylle henkilölle eikä jaettuun projektiketjuun, ja poista se, kun luovutus on tehty.

Kertakäyttölinkki pitää kirjautumistiedon poissa siitä sähköposti- tai chat-viestistä, jolla sovitte asioista. LinkPilotissa salaisuus salataan selaimessasi ennen tallentamista, tallennettu kopio tuhotaan yhden avauksen jälkeen, ja linkin voi asettaa vanhenemaan tunnin, päivän tai viikon kuluttua. Pro-paketeissa linkkiin voi lisätä salalauseen, jonka välität toista kanavaa pitkin. Nämä asetukset rajaavat luovutusta. Ne eivät korvaa sen tarkistamista, että toisessa päässä on oikea henkilö.

Salattu viestipalvelu on varavaihtoehto, kun kumpikaan edellisistä ei käy. Siirron aikainen salaus ei korjaa väärään osoitteeseen mennyttä viestiä tai liian laajaa ryhmää, joten vastaanottajan tarkistus on silloin vielä tärkeämpi.

Valitsitpa minkä tahansa, käytä selväkielistä sähköpostia ja chattia vain asioista sopimiseen. Vaikka palvelu salaisi viestit siirron aikana, säilytysajat, varmuuskopiot ja tilien käyttöoikeudet eivät ole hallinnassasi.

Varmista asiakas ja vastaanottaja

Turvallinen kanava ei auta, jos salaisuus menee väärään postilaatikkoon. Varmista ennen lähettämistä, että pyytäjä vastaa integraatiosta ja että aiottu reitti todella on hänen.

• Varmista henkilöllisyys tunnetusta lähteestä. Käytä luotettua yhteystietoa, olemassa olevaa asiakassuhdetta tai asiakkaan vakiintunutta käytäntöä. Uusi pyytäjä, äkillisesti vaihtunut yhteyshenkilö tai epätavallinen kiire on syy tarkistaa asia erikseen.
• Lue osoite merkki merkiltä, varsinkin kun kopioit sen tiketistä tai tuoreesta viestistä. Samannäköiset nimet ja jaetut postilaatikot ovat juuri niitä kohtia, joissa virheet syntyvät.
• Tarkista, kenellä muulla on pääsy. Ennen kuin jaat salaisuuden portaalin tai työtilan kautta, katso sen jäsenluettelo ja poista sieltä kaikki, jotka eivät tarvitse kirjautumistietoa.
• Varmista perillemeno toista kanavaa pitkin. Jos linkki lähti sähköpostilla, kysy tunnetusta puhelinnumerosta tai tavallisesta projektikanavasta, onnistuiko avaaminen. Älä laita salaisuutta siihen viestiin.

Jaa salaisuus sille yhdelle henkilölle, joka määrittää päätepisteen, ja anna hänen tallentaa se asiakkaan omaan salaisuuksien säilöön. Jos usea kehittäjä tarvitsee sitä, säilön käyttöoikeuksilla hallitaan, kuka sen näkee, eikä jokaiselle lähetetä omaa kopiota.

Valmistele salaisuus ennen luovutusta

Päätä, mihin kirjautumistieto kuuluu, missä asiakkaan pitää säilyttää sitä ja kuinka kauan luovutus on auki. Valmistelu selkeyttää myöhempää salaisuuden vaihtamista ja vianmääritystä huomattavasti.

• Yksi salaisuus asiakasta tai päätepistettä kohden. Jos samaa arvoa käytetään useassa paikassa, yksi vuoto ulottuu jokaiseen integraatioon, jossa se on käytössä, ja yhden asiakkaan salaisuuden vaihtaminen katkaisee ne kaikki. Pidä sisäistä kirjaa siitä, mihin päätepisteeseen kukin salaisuus kuuluu, mutta älä kopioi arvoa projektimuistiinpanoihin.
• Säilytä oma kopiosi salaisuuksien hallintapalvelussa. Ei paikallisessa tekstitiedostossa, tiketissä tai jaetussa dokumentissa. Sama periaate pätee API-avainten jakamiseen: rajaa, kuka kirjautumistietoon pääsee käsiksi, ja pidä luovutus lyhytaikaisena.
• Määritä hakuaika. Anna asiakkaalle riittävästi aikaa hakea arvo ja tehdä asennus, mutta ei enempää. Linkki, joka tuhoutuu yhden avauksen jälkeen ja vanhenee päivässä, riittää useimpiin luovutuksiin. Jos aikaikkuna umpeutuu, luo uusi linkki äläkä avaa vanhaa uudelleen.
• Lähetä asennusohjeet erikseen. Päätepisteen URL-osoite, allekirjoitusotsake ja tarkistusvaiheet kuuluvat asiakkaan dokumentaatioon tai projektikanavalle. Kun ne pidetään erillään salaisuudesta, kopioitu ohjesivu ei ole samalla kopioitu kirjautumistieto.

Auta asiakasta säilyttämään ja käyttämään salaisuutta turvallisesti

Luovutus ei ole valmis silloin, kun asiakas pystyy lukemaan arvon. Se on valmis, kun palvelin pystyy lukemaan arvon turvallisesti ja tarkistaa sillä saapuvat allekirjoitukset.

• Tallenna se salaisuuksien hallintapalveluun tai suojattuun ympäristömuuttujaan, jonka palvelinprosessi pystyy lukemaan. Rajaa käyttöoikeus sovellukseen ja sitä ylläpitäviin ihmisiin.
• Pidä se poissa lähdekoodista, lokeista ja webhookien sisällöstä. Salaisuudella lasketaan tai tarkistetaan allekirjoitus. Se ei koskaan kulje pyynnön rungossa, eikä sen pidä näkyä virheenjäljitystulosteissa, repositorioissa tai tukipyynnöissä. Tarkista, mitä käyttöönottotyökalusi tallentavat, ennen kuin otat yksityiskohtaisen diagnostiikan käyttöön.
• Tarkista allekirjoitukset palvelimella. Vastaanottaja laskee allekirjoituksen uudelleen pyynnön muokkaamattomasta rungosta jaetulla salaisuudella ja vertaa sitä lähettäjän asettamaan otsakkeeseen. Allekirjoitus osoittaa, että pyyntö on aito ja muuttumaton, mutta se ei salaa sisältöä. HackerOnen opas webhookien allekirjoittamisesta kertoo, miksi sekä muokkaamaton runko että oikea salaisuus ovat tärkeitä.
• Lähetä testitapahtuma. Pyydä asiakasta varmistamaan, että kelvollinen allekirjoitus hyväksytään ja tahallaan rikottu hylätään. Näin löytyvät tavalliset virheet: väärän päätepisteen salaisuus tai runko, joka on jäsennetty ennen tarkistusta. Pidä testi- ja tuotantoympäristön kirjautumistiedot erillään, jos integraatio sen sallii.

Pienennä riskiä luovutuksen jälkeen

Luovutuksesta pitää jäädä käyttökelpoinen merkintä, ei jälki ylimääräisistä kopioista.

• Kirjaa, kenelle lupa annettiin ja milloin. Merkitse vastaanottaja, päätepiste tai asiakas ja luovutuksen ajankohta. Ei koskaan itse arvoa. Jos et pysty sanomaan, avattiinko linkki tai kuka pääsi jaettuun kansioon, kiristä käytäntöä ensi kerralla.
• Vaihda salaisuus aina, kun epäilet vuotoa. Tikettiin liitetty, väärään osoitteeseen lähetetty tai lokista löytynyt salaisuus ei ole enää yksityinen. Luo korvaava salaisuus, päivitä päätepiste ja mitätöi vanha arvo. Jakolinkin poistaminen ei peru vuotoa, vain salaisuuden vaihtaminen auttaa.
• Sopikaa vaihtamisen käytännöstä nyt. Päättäkää, kuka pyytää, luo ja asentaa korvaavan salaisuuden, tukeeko toteutus lyhyttä päällekkäisyysaikaa ja miten uusi arvo testataan ennen vanhan poistamista käytöstä. Tunnettu menettely on parempi kuin kiireinen vaihto katkoksen keskellä.
• Siivoa jäljet. Kun asiakas vahvistaa hakeneensa salaisuuden, poista väliaikaiset käyttöoikeudet ja poista ylimääräiset kopiot luonnoksista, tiketeistä ja muistiinpanoista. Tarkista jokaisen mukana olleen järjestelmän säilytyssäännöt. Viestin poistaminen yhdestä näkymästä poistaa sen harvoin varmuuskopioista.

Vianmääritys paljastamatta salaisuutta

Toimitusongelma ei ole syy lähettää kirjautumistietoa uudelleen heikompaa kanavaa pitkin. Selvitä ensin, mikä kolmesta on vialla: asiakas ei saa salaisuutta haettua, ei saa päätepistettä määritettyä tai vastaanottaa pyyntöjä mutta ei pysty tarkistamaan allekirjoituksia.

• Haku epäonnistui tai aikaikkuna umpeutui. Varmista vastaanottaja uudelleen ja tee uusi hallittu luovutus. Älä liitä arvoa tikettiin äläkä pyydä asiakasta lähettämään omaansa takaisin vertailua varten.
• Allekirjoitus ei täsmää. Lähes aina vika on tarkistuksen syötteissä: päätepisteelle väärä salaisuus, runko, jonka muotoilu muuttui ennen tiivisteen laskemista, tai väärin luettu otsake. Pyydä asiakasta testaamaan tunnetulla tapahtumalla lähettäjän testityökaluilla.
• Pyyntöjä ei tule lainkaan. Kyse on toimitus- tai reititysongelmasta eikä kirjautumistiedosta. Tarkista aikaleimat, vastauskoodit ja päätepisteen valinta, ennen kuin kukaan harkitsee salaisuuden vaihtamista. Stripen webhook-dokumentaatio on hyvä esimerkki siitä, miten päätepisteen rekisteröinti ja tapahtumien toimitus erotetaan allekirjoituksen tarkistuksesta.
• Jaa diagnostiikka sensuroituna. Tapahtuman tunniste, aikaleima, päätepiste ja virheluokka riittävät. Poista salaisuus, koko allekirjoitus silloin, kun se on arkaluonteinen, ja yksityiset sisältökentät, ja tarkista sensurointi ennen kuin lähetät esimerkkipyynnön.

Varmista vastaanottaja, luovuta salaisuus kerran kanavaa pitkin, joka ei säilytä sitä, huolehdi, että se päätyy salaisuuksien säilöön, ja vaihda se epäröimättä, jos se on voinut vuotaa. Kertakäyttölinkkien laajemmasta käytöstä kehitystyössä kerrotaan artikkelissa linkkien turvallinen jakaminen kehittäjille.