Kaip Agdir naudoja SecretDrop · Dalis 3
Kaip integracijos partneris mums saugiai išsiuntė privatų raktą
Kartais partneris turi jums išsiųsti tikrą privatų raktą, kad nustatytų saugią integraciją. Štai saugus būdas jį perkelti tarp dviejų įmonių.
„Kaip Agdir naudoja SecretDrop" 3 dalis — serija apie tai, kur agrotechnologijų įmonė ir jos klientai iš tikrųjų dalijasi paslaptimis.
Dažniausiai niekada nesiųsite privataus rakto. Visas raktų poros tikslas — kad privačioji pusė liktų vietoje: jūs ją sugeneruojate, užregistruojate viešąją pusę pas tą, kuris turi jus patikrinti, o privatusis raktas niekada nepalieka jūsų kompiuterio.
Tačiau kartais privatus raktas iš tikrųjų turi keliauti tarp dviejų įmonių. Tai vienos tokios situacijos istorija.
Situacija
Integracijos partneris — tiksliosios žemdirbystės įmonė, kurianti dvikryptį duomenų srautą su Agdir — paleido savo API su abipusiu TLS. Paprastų API raktų jiems nepakako: norint atidaryti ryšį, skambinantysis turi pateikti kliento sertifikatą, kurį partneris išdavė ir pasitiki. Tai tvirtas sprendimas, dažnas tarp dviejų verslo subjektų, keičiančių jautrius duomenis mašina-mašinai.
Kad Agdir jungtis galėtų autentifikuotis, partnerio operacijų komanda sugeneravo kliento sertifikatą ir jo privatų raktą — specialiai mums. Tas privatus raktas ir yra kredencialas. Be jo integracija negali prisijungti; su juo bet kas gali apsimesti mūsų jungtimi jų API atžvilgiu.
Taigi dvi įmonės susidūrė su problema, su kuria kasdien susiduria asmenys, tik su didesniais statais: kaip perduoti gyvą privatų raktą iš jų pusės mums, kad jis neprasimuštų pakelyje?
Kaip paprastai viskas eina negerai
Numatytasis B2B integracijų būdas yra nusivylimą keliantis lengvabūdiškumas:
- Supakuokite sertifikatą ir raktą, išsiųskite el. paštu kaip priedą.
- Slaptafrazę pateikite antrame el. laiške („saugumo sumetimais").
- Arba abu įdėkite į bendrą bilietą bet kuriame palaikymo įrankyje, jungiančiame dvi komandas.
Kiekvienas iš jų palieka nuolatinę privataus rakto kopiją sistemoje, kurios nei viena įmonė visiškai nekontroliuoja — pašto serveriuose, atsarginėse kopijose, bilietų įrankio duomenų bazėje, laiškų dėžutėse visų, kurie bus prisidėti vėliau. Privatus raktas, atsidūręs el. laiško siūle, yra raktas, kurio niekada iš tikrųjų nebesugrąžinsite.
Ir skirtingai nei slaptažodis, jo negalima tyliai „pakeisti" — kliento sertifikato atšaukimas ir perišdavimas reiškia rotacijos koordinavimą abiejose įmonėse. Daug geriau jo iš pradžių neleisti nutekėti.
Ką mes padarėme vietoj to
Partneris išsiuntė raktą per SecretDrop:
- Jie įklijavo privatų raktą (PEM) į vienkartinę nuorodą, o slaptafrazę išsiuntė kaip atskirą nuorodą, sunaikinimą po perskaitymo.
- Abi nuorodas jie pasidalino su mūsų integracijos inžinieriumi įprastiniu kanalu — el. paštas tiko, nes nuoroda nėra raktas.
- Mūsų inžinierius atidarė kiekvieną nuorodą vieną kartą, įkėlė sertifikatą ir raktą tiesiai į mūsų paslapčių tvarkytuvę, ir abi nuorodos sunaikino save.
Privatus raktas atliko vieną kelionę — iš jų saugyklos į mūsų — ir nepaliko jokios kopijos jokiame el. pašto dėžutėje, biliete ar pokalbyje iš abiejų pusių. Jei kas nors vėliau ieškos el. pašto siūlo, kuriame buvo nustatyta integracija, jame nebus nieko jautraus.
Išvada
Jei esate partneris, turintis perduoti kitai įmonei privatų raktą, sertifikatą ar bet kokį gyvą kredencialą:
- Niekada nesiųskite el. paštu ir nepridėkite kaip priedo. Priedai yra nuolatiniausia ir labiausiai persiunčiama kopija iš visų.
- Siųskite kaip nuorodą, sunaikinimą po perskaitymo, o slaptafrazę — kaip atskirą nuorodą.
- Patvirtinkite, kad gavėjas ją atidarė, tada laikykite perkėlimą baigtu — paslaptis daugiau nebeegzistuoja tranzite.
Saugios integracijos yra tiek saugios, kiek jų nustatymo momentas. Privatus raktas, egzistavęs tik tas kelias sekundes, kiek prireikė jį įkelti į saugyklą, yra toks, kurio joks būsimas pažeidimas — nei iš vienos pusės — negalės atskleisti.