Miksi sinun ei pitäisi rakentaa omaa todennusjärjestelmää: opit kymmenistä asiakashaastatteluista

Todennus vaikuttaa sellaiselta, jonka voisi tehdä itse tuosta vain. Sähköposti, salasana, hajautus, vertaaminen kirjautuessa. Kuinka vaikeaa oman todennusjärjestelmän rakentaminen voi olla?

Voit rakentaa sen. Siinä on ansa.

Olemme keskustelleet kymmenien tiimien kanssa heidän itse rakentamastaan tunnistautumisesta. Useimmat tulivat meille saman syyn vuoksi: se hidasti liiketoimintaa.

Eri toimialat, teknologiat, ja koot, mutta sama loppu. Se todennus, jonka he olivat rakentaneet, oli muuttunut velaksi, jota tiimi kantoi.

Omituista on, että se ei koskaan näy katkoksena. Järjestelmä kirjaa käyttäjiä sisään ja toimii hyvin — kunnes liiketoiminnan muutos pysäyttää kaiken: tietoturvatarkastus, ensimmäinen yritysasiakas, yrityskauppa, ominaisuus, joka ylittää kaksi tuotetta.

Viime viikolla kaikki oli "hyvin". Sitten seuraava asia tiekartalla jumiutuu sen taakse.

Suurin virhe kotitekoisessa tunnistautumisessa on kohdella sitä ominaisuutena. Voit kirjoittaa sen ensimmäisenä päivänä. Mutta kun oikea liikenne käy järjestelmän läpi, se kietoutuu käyttäjiisi, organisaatioihisi ja oikeuksiisi.

Todennus ei ole ominaisuus. Se on identiteetti-infrastruktuuria.

Kirjautumissivun takana on kokonainen identiteettimalli#

Jokainen kotitekoinen todennusjärjestelmä alkaa samalla tavalla. Ota sähköposti ja salasana, hajauta ne, tallenna, vertaa kirjautuessa. Neljäkymmentä riviä koodia, siistiä ja valmista.

Ongelmat alkavat julkaisun jälkeen. Botit moukaroivat rekisteröitymistä, joten lisäät rajoituksia, CAPTCHA:n, laitteen sormenjäljen. SMS-koodien lähetys lakkaa eräänä aamuna, joten lisäät uusintayritykset ja päiväkohtaisen katteen. Sitten tulevat vaikeammat osat: turvallinen salasanan palautus, MFA ja sen palautusprosessi, istunnot ja päivitystunnukset, ja käyttöoikeusmalli, joka on paljon muutakin kuin pelkkä is_admin-totuusarvo.

Mikään näistä ei yksinään ole vaikea. Jokainen mahtuu sprinttiin. Mutta joka kerta kun julkaiset jonkin, vastaat isompaan kysymykseen tuotteen puolesta.

Kasaamalla nämä vastaukset saat identiteettimallin, jonka tuotteesi hiljaa olettaa olevan tosi: kuka lasketaan käyttäjäksi, voiko yksi henkilö kuulua useaan organisaatioon, miten yritysasiakkaan oma tunnistusjärjestelmä integroidaan, ja miten tunnukset poistetaan kun joku lähtee.

Jokainen myöhemmin kirjoittamasi ominaisuus olettaa nämä annetuksi, ja mitä pidemmälle aika kuluu, sitä vaikeampi niitä on muuttaa.

Näimme tämän yhdessä yrityksessä: toimialakohtainen B2B SaaS, kaksikymmentä vuotta liiketoimintaa, kivijalkatoimijoiden palveluksessa. He rakensivat oman tunnistautumisensa yli vuosikymmen sitten, erillisellä kirjautumisella joka asiakasta varten ja käyttöoikeustarkistukset suoraan liiketoimintamoduuleihin. Se oli silloin järkevä ratkaisu.

Kaksikymmentä vuotta myöhemmin, he halusivat jotain, joka kuulostaa pieneltä: yhtenäinen kirjautumissivu, jossa sähköposti on käyttäjätunnus. Kyse ei ollutkaan vain sivun muutoksesta. Oikeustarkistukset olivat levinneet satoihin moduuleihin, ja kirjautumisen yhtenäistäminen tarkoitti käyttäjämallin, organisaatiomallin, tunnistetietojen migraation ja kaikkien käyttöoikeusrajojen muuttamista. Kukaan ei halunnut ottaa vastuuta, joten muutos venyi vuosiksi.

Kun he kirjoittivat sen ensimmäisen kirjautumissivun, se näytti ominaisuudelta. Todellisuudessa se jätti jälkeensä kokonaisen identiteettimallin.

Kun liiketoimintasi kasvaa, kotitekoinen tunnistus ei usein enää riitä#

Rehellisyyden nimissä: kotitekoinen tunnistus toimii yleensä pitkään. Se kirjaa käyttäjät sisään, päivittää istunnot ja pyörittää arkea vuosia. Monimutkaisuus lisääntyy hitaasti, ei kerralla, ja hoidat sitä pala palalta, kunnes tunnet hallitsevasi kokonaisuutta.

Mutta kun "riittävä" tarkoittaa vain, ettei liiketoiminta ole vielä törmännyt seinään. Kun niin tapahtuu, ongelmana ei ole itse tunnistus. Naapurina oleva liiketoiminta muuttui, ja "riittävä" muuttui yhdessä yössä "esteeksi".

Seuraavat tilanteet tulevat eteen useimmille tuotteille, kun ne kasvavat. Ne näyttävät erilaisilta, mutta taustalla on sama ongelma: liiketoiminta meni eteenpäin, mutta vanha identiteettimalli ei pysynyt mukana.

Yritysasiakkaat alkavat kysyä SSO:ta#

Tilanne: asiakas haluaa kirjautua omalla IdP:llään, mutta järjestelmäsi ei tunne konseptia "joku muu identiteetin tarjoaja".

Ensimmäinen oikea yritysdiili tulee, ja hankintatiimi lähettää vaatimusdokumentin. Ensin se on SSO heidän Microsoft Entran tai Google Workspacen kautta. Sitten tarvitaan sekä SAML että OIDC, koska seuraava asiakas käyttää eri ratkaisua. Sitten SCIM, jotta työntekijöitä voidaan hallita automaattisesti.

Jokaisen asiakkaan asennus on erilainen: eri protokollat, kenttien mappingit, varmenteiden kierto, ja erilaisia tapoja, miten heidän organisaationsa rakenne liittyy sinun malliisi.

Eikä juuri mikään työ siirry seuraavaan käyttöön. Jokainen uusi asiakas tuo mukanaan eri IdP:n ja uuden konfiguraation, ja suurin osa alkaa taas alusta. SSO ei ole ominaisuus, jonka rakennat kerran. Jokaisen suuren asiakkaan kohdalla rakennat sen uudestaan, ja kustannukset kasvavat asiakasmäärän mukana.

Todennus ei ole enää "anna käyttäjien kirjautua tuotteeseesi". Se on "salli tuotteesi liittää asiakkaan identiteettijärjestelmään". Kaksi täysin eri asiaa.

Näimme yhden yrityksen, jossa koko SSO-asennus tehtiin käsin, ja vain yksi insinööri ymmärsi sen läpikotaisin. Hänen ollessaan paikalla, asiakkaat pääsivät tuotantoon. Kun hän oli poissa, myynti ja onboarding jonottivat. Kun hän lähti, tieto katosi hänen mukanaan.

Yksikään näistä ei ollut pöydällä sinä päivänä, kun he päättivät rakentaa oman tunnistautumisensa.

Tuote tarvitsee yhdenmukaistaa hajallaan olevan identiteetin#

Tilanne: identiteettidata on hajallaan, jaettuna organisaatioittain ja tuotteittain, ja kun liiketoiminta kasvaa, yhtenäinen identiteetti alkaa olla pakollinen.

Edellä mainittu kaksikymmenvuotinen yritys kohtasi tämän yhtenäistäessään kirjautumista, ja sama ilmiö toistui muuallakin. Työskentelimme alustan parissa, jossa oli yhdeksän tuotetta, kaikki yritysostojen jälkeen, jokaisella oma tunnistus ja käyttäjätietokanta.

Yritysosto ei yhdistä niitä puolestasi. Jokaisen ostetun tuotteen mukana tulee yksi todennuspino lisää, ja yhdeksän rinnakkaista vie oikeasti työvoimaa pelkkään ylläpitoon.

Kysymyksiä kasautuu. Onko sama henkilö yksi käyttäjä tuotteissa A ja B, vai kaksi? Miten sama asiakasorganisaatio yhdistetään molemmissa? Miten ominaisuudet sallitaan tuotteen yli? Kun työntekijä lähtee, miten käyttöoikeudet poistetaan kaikista tuotteista yhdellä kertaa? Ja missä niitä edes auditoidaan?

Yksikään yhdeksästä ei ole rikki. Yhdessä niistä tulee muuri.

"Yhtenäistä identiteetti" kuulostaa ominaisuudelta. Koodissa se tarkoittaa perustavimman asian uudelleenmäärittelyä: mikä lasketaan yhdeksi käyttäjäksi ja yhdeksi organisaatioksi. Lähes jokainen ominaisuus rakentuu vanhan määritelmän päälle, joten kun se liikkuu, kaikki liikkuu mukana.

AI-aikakaudella agentit ja CLI:t käyttävät järjestelmää käyttäjän puolesta#

Tilanne: enää eivät vain ihmiset kirjaudu selaimella. Nyt agentit, komentorivit ja skriptit esiintyvät käyttäjän puolesta, mutta tunnistautumisesi tuntee vain yhden asian: ihminen kirjautuu sivulla.

Agentti tarvitsee pääsyn sisäisiin työkaluihisi käyttäjän puolesta. MCP-palvelin tarvitsee suojattujen resurssien turvallisen paljastamisen. CLI tarvitsee yhteyden tilitietoihin ilman selainta.

Kaikissa nämä samat kysymykset: minkä käyttäjän puolesta tämä pyyntö toimii, mihin resursseihin se pääsee, kenelle token myönnettiin, mikä on sen laajuus, miten se perutaan, kirjataanko käyttäjä vai agentti?

Vanhassa järjestelmässä nämä mekanismit puuttuvat. MCP perustuu OAuthiin valtuutuksessa. CLI kulkee joko OAuth-kirjautumisen kautta tai käyttää henkilökohtaista käyttöoikeustunnusta, joka voidaan peruuttaa koska tahansa. Mikään näistä ei ollut tehty kirjautumissivua varten.

Jos todennuksesi suunniteltiin yhdelle ihmiselle kirjautumiseksi sivulla, nyt pitääkin hallita asiakkaan puolesta toimiva asiakas.

Pitkäaikainen ylläpito on suurin kustannus oman tunnistautumisen rakentamisessa#

Yksikään yllä mainituista tilanteista ei ole "todennus hajosi". Järjestelmä toimii edelleen. Jokainen näyttää pieneltä ominaisuudelta, mutta kun aloitat, kyse on tuotteen strategiasta, datamigraatiosta ja asiakastoimituksesta.

MFA on selvin esimerkki. Päältä se on vain "osataanko tarkistaa toisen kerran kirjautumisen jälkeen".

Kaksi askelta eteenpäin on: mille organisaatioille ja käyttäjille sitä vaaditaan, voiko ylläpitäjä pakottaa sen muille, vaatiiko arkaluontoiset toimet kuten maksutietojen muutos tai datan vienti uudelleen tarkistuksen, miten palautuskoodit generoidaan ja palautetaan, voiko tuki palauttaa ne, kuuluko SSO-käyttäjän MFA sinulle vai asiakkaan IdP:lle? MFA:n lisääminen tarkoittaa kokonaisen tietoturvapolitiikkakerroksen lisäämistä.

"Synkataan vähän käyttäjiä" on sama tarina: taustalla on pitkä ketju päätöksiä onboardingista, offboardingista ja organisaatioiden välisestä jäsenyydestä, olettaen että käyttäjä- ja organisaatiomallit oli alun perin suunniteltu oikein.

Mitä enemmän ominaisuuksia lisäät, sitä enemmän ylläpidät identiteettituotetta oman tuotteesi sisällä. Ensimmäinen versio on halpa, muutama insinööri ja pari viikkoa. Mutta ruokit sitä vuosi toisensa jälkeen.

Piilokustannus: lasku muuttui vain maksutavaksi#

Yleisin syy rakentaa itse on kustannus, eikä se ole naiivi syy.

Eräs jäsenorganisaatio, jonka haastattelimme, teki laskelmat viisi vuotta sitten. Jäseniä oli noin satatuhatta, mutta vain muutama tuhat kirjautui säännöllisesti. Toimittajat hinnoittelivat kokonaisten käyttäjämäärien mukaan, tarjous ylitti budjetin, ja itse rakentaminen tuli halvemmaksi. Sille vuodelle se ei ollut väärä päätös.

Viisi vuotta myöhemmin matematiikka oli kääntynyt. Oman kirjautumisen ylläpito ja turvallisuuden varmistaminen olivat jo maksaneet enemmän kuin ostaminen olisi tehnyt.

Ensimmäisenä vuonna säästetty lasku on näkyvä ja insinööriaika ei. Viiden vuoden päästä säästetty lasku on sama, mutta insinööriaika on muuttunut tiekarttaviivästyksiksi, tietoturvavelaksi ja ylläpidoksi, jota kukaan ei halua ottaa.

Oman todennuksen rakentaminen ei siis ole ilmaista. Et vain koskaan saa laskua, jossa lukee "tunnistuspalvelun kuukausimaksu". Maksat sen henkilökuukausina, myöhästyneinä deadlineina, korjaustyönä, tietoturvavelkana ja insinöörien huomiona, jonka olisit voinut käyttää ydinliiketoimintaan.

Pari insinööriä omistaa siitä lopulta kaiken tiedon#

Se insinööri, joka ylläpitää SSO:ta käsin, ei ole poikkeus. Pyöritä kotitekoista todennusta tarpeeksi pitkään ja kriittinen tieto kasaantuu yhdelle tai kahdelle henkilölle: mikä asiakas on konfiguroitu miten, mitä kenttää ei saa muuttaa, miksi tietty migraatio tehtiin joskus tietyllä tavalla. Harvoin nämä päätyvät dokumentaatioon. Ne elävät jonkun päässä.

Kun hän on paikalla, toimitukset liikkuvat. Kun ei, yritysputki pysähtyy, ja huomaat että tärkeintä infrastruktuuriasi ei oikeasti omista kukaan — vain "se joka tietää".

Jotkut tiimit menevät pidemmälle ja rakentavat asiakkaille itsepalvelu-SSO-konfigurointialustan. Se kuulostaa kypsältä, kunnes kysyt montako asiakasta se palvelee. Näimme yhden 1,5 miljoonan kuukausittaisen käyttäjän järjestelmän, jossa koko ratkaisu palveli vain paria tusinaa asiakasta.

Luulit rakentavasi ominaisuutta. Todellisuudessa kehität sisäistä tuotetta, jonka hinta jakautuu kourallisen asiakkaiden kesken. Jos identiteetti on ydinliiketoimintasi, tämä voi olla järkevää. Muussa tapauksessa kyse on puhtaimmasta piilolaskusta.

Mihin haluat insinöörisi?#

Takaisin siihen kaksikymmenvuotiseen SaaS-tuotteeseen. Nämä eivät olleet heikkoja kehittäjiä. Alan tuotteen elossa pitäminen kaksikymmentä vuotta kertoo juuri siitä, että he tuntevat asiakkaansa hyvin.

Juuri siinä on koko ongelma. Suoraan sanottuna: haluatko heidän ylläpitävän käsin joka asiakkaan SSO:n ja purkavan vuosikymmenten oikeuslogiikkaa sadoista moduuleista, vai menemään syvemmälle alan ohjelmistoon itseensä?

Tämä ei ole insinööriperfektionismia. Se on resurssien kohdentamista. Jos rakennat maksuliikennettä, alan SaaS:ää, jäsenportaalia tai operatiivista ohjelmistoa, yksikään asiakas ei maksa euroakaan enemmän, koska rakensit oman OAuth-palvelimen.

Eräs maksutiimi kiteytti sen selkeästi: heidän itse tehty IdP oli ok, mutta kyse on strategisesta päätöksestä. Älä koodaa paljon todennukseen. Säästä energia parhaaseen maksujärjestelmään, ja käytä markkinoiden toimivinta todennusta muuhun.

Todennuksen pitää olla luotettava. Mutta "luotettava" ei tarkoita "itse rakennettu". Tietokantasi, sähköpostin toimitus ja pilvi-infra pitää olla luotettavia, eikä kypsä tiimi oleta, että kaiken pitää olla in-house vain siksi että se on tärkeää.

Useimmilla tuotteilla todennus on ydindependenssi, ei erotustekijä. Ellei identiteetti ole liiketoimintasi ydin, identiteettituotteen pyörittäminen oman tuotteesi sisällä harvoin tuo kilpailuetua. Useimmiten se on pitkäaikainen resurssien syöppö.

Milloin oman tunnistautumisen rakentaminen on silti perusteltua?#

On helppo lipsahtaa ääripäähän: älä koskaan kirjoita tunnistautumiskoodia. Sekään ei pidä paikkaansa.

Joissain vaiheissa oman (tai puoliksi oman) rakentaminen on täysin järkevää: sisäiset demot, hyvin varhaiset prototyypit, yksittäiset validointiprojektit. Ja jos liiketoiminnallasi on erittäin erityisiä, hienojakoisia valtuutustarpeita joita valmisratkaisut eivät pysty ilmaisemaan, voit pitää sen osan omissa käsissäsi, kun taas ulkoinen järjestelmä hoitaa tunnistautumisen, istunnot, SSO:n, MFA:n ja käyttäjähakemiston.

Tarkkaile vain POC-luisua. Olemme nähneet tutun kaavan: kaksi kehittäjää käyttää kuudesta kahdeksaan kuukautta prototyypin rakentamiseen ulkoisen järjestelmän päälle. Lähestymistapa ei ole huono. Heidän itsensä mukaan ratkaisu on hyvä. Sen ei vain koskaan ollut tarkoitus skaalautua.

Ja POC:sta on helpoin kovettaa pysyvä arkkitehtuuri. Kuuden kuukauden päästä se on "nykyinen ratkaisu", kahden vuoden päästä "legacy-järjestelmä", viiden vuoden jälkeen "infrastruktuuri johon ei uskalla koskea". Paras hetki jättää kotitekoinen tunnistus ei yleensä ole vasta kun se hajoaa, vaan ennen kuin siitä tulee perusta.

Joten linja on tässä: kyse ei ole siitä oletko kirjoittanut riviäkään tunnistautumista. Kyse on siitä otatko kokonaisen geneerisen identiteetti-infrastruktuuripalan omalle tiimillesi pitkäksi aikaa.

Rakenna reunakyvykkyydet itse. Ole varovainen ydintason identiteettikerroksessa. Ja älä vahingossa rakenna täyttä CIAM-alustaa.

Jos et rakenna sitä itse, miten valitset tunnistusratkaisun?#

Jos päätät olla kirjoittamatta sitä itse, seuraava kysymys tulee: kenen ratkaisun ostat ja miten valitset?

Useimmat kypsät ratkaisut kattavat jo ominaisuudet: SSO, MFA, useat organisaatiot, yhtenäinen kirjautuminen, agenttipääsy. Todellinen ero on harvoin ominaisuustoteutuksissa.

Helpompi unohtaa – ja tärkeämpää vertailla – ovat seuraavat kohdat. Ne ovat kaikki saman asian puolia: älä vain pääse ulos muutamasta tuhannesta omasta koodirivistäsi vain lukittuaksesi itsesi toiseen järjestelmään, josta et pääse pois.

• Tartu standardiprotokolliin, älä yhden toimittajan keksimään pinon. OIDC, OAuth ja RS256-allekirjoitetut JWT:t ovat helposti ymmärrettäviä. Luet claimit suoraan tokenista, ilman vendor-kohtaista rajapintaa.
• Pidä ovi auki, josta voit oikeasti kulkea ulos. Jos ratkaisu on avoimen lähdekoodin ja itse hostattava, voit siirtyä koska vain. (Itsehostetun version pitkäaikainen ylläpito on tietenkin oma piilokustannuksensa.)
• Älä anna laskutuksen seurata käyttäjätauluasi. Käyttäjämäärän tai aktiivisten kuukausikäyttäjien perusteella laskutus seuraa taulua joka vain kasvaa, täynnä passiivisia käyttäjiä – skaalassa siitä tulee "kasvutaksi". Siksi yllä mainittu jäsenorganisaatio rakensi oman.
• Tietosi eivät lukitu. Voit viedä käyttäjädatan koska vain. Ja arkaluontoisten tietojen luovuttaminen erikoistuneelle palveluntarjoajalle säästää sinut riskiltä vartioida dataa, jota sinun ei koskaan pitänyt pitää hallussasi.

Täysi avoimuus: Logto on tunnistustuotteemme, joka rakennettiin juuri näiden neljän kohdan perusteella. Se on avoimen lähdekoodin, itsehostettava ja myös saatavilla hallinnoituna pilvipalveluna: käytä Cloudia ilman ylläpitoa tai hostaa open-source-versio itse – ja hetkellä, jolloin haluat siirtyä pois, ovi pysyy auki.

Kirjautuminen, MFA, SSO ja RBAC toimivat suoraan vakiostandardeilla (OIDC), ja laskutus seuraa tunnuksia – maksat käytön mukaan.

Muitakin kypsiä vaihtoehtoja on, ja todennus ei koskaan ollut kysymys, johon olisi vain yksi oikea vastaus. Jos vertailet, kirjoitin kokonaisen artikkelin aiheesta kuinka valita tunnistusratkaisu, jota voit hyödyntää.

Yhteenveto: älä erehdy pitämään pitkäaikaista identiteettialustaa tavallisena ominaisuutena#

Oman todennuksen rakentaminen on yleensä järkevää ensimmäisenä päivänä. Koukku piilee siinä, että se kasvaa myöhemmin infrastruktuuriksi.

Jokainen liiketoiminnan askel paljastaa sen uudelleen: yritysasiakkaat haluavat SSO:n, tietoturva MFA:n, tuotetiimi yhtenäisen kirjautumisen, tuotteet kytkentää toisiinsa, tekoälyagentit pääsyn käyttäjien resursseihin. Jokaisen pieneltä näyttävän ominaisuuden takana on joukoittain politiikkakysymyksiä, ja vuosien kuluessa niiden ruokkiminen syö insinöörien ajan, joka kuuluisi ydinliiketoimintaasi.

Tätä laskua ei tule vastaan ensimmäisenä päivänä. Yleensä se saapuu vuosien päästä. Silloin sen vihdoin huomaat: se kirjautumissivu, jonka kirjoitit silloin, oli jo identiteetti-infrastruktuuria, joka jättäisi jälkensä koko tuotteen elinkaareen.

Todennus tuskin on ydintuotteesi. Mitä aiemmin sen näet, sitä aikaisemmin voit käyttää aikasi, energiasi ja resurssisi taas oikean tuotteesi rakentamiseen.

FAQ#

Pitäisikö sinun koskaan rakentaa omaa todennusjärjestelmää?#

Ei. Aikaiset demot, sisäiset työkalut, yksittäiset validointiprojektit tai erittäin erityinen, hienojakoinen valtuutus, jota valmisratkaisut eivät pysty ilmaisemaan, voivat kaikki olla perusteltuja. Vältä kuitenkin ottamasta pitkäaikaisen geneerisen identiteetti-infrastruktuurin ylläpito-osuutta yritystiimin kontolle huomaamatta.

Mikä ero on todennuksella ja valtuutuksella?#

Todennus vastaa "kuka olet". Valtuutus vastaa "mitä voit tehdä". Todellisessa SaaS:ssa näitä kahta on vaikea erottaa: käyttäjät, organisaatiot, roolit, oikeudet, istunnot, token claimit ja audit-lokit kietoutuvat toisiinsa. Kun vaihdat tunnistautumisjärjestelmää, et voi katsoa vain kirjautumissivua.

Miksi yritys-SSO monimutkaistaa kotitekoisen tunnistautumisen?#

Koska se tarkoittaa, että tuotteesi täytyy kytkeytyä asiakkaan omaan identiteettijärjestelmään. Eri asiakkailla on eri IdP:t, protokollat, claim-kentät, varmenteet ja organisaatiorakenteet. Yhden yhdistäminen ei tarkoita, että muut ovat copy-paste. Usein työstä tulee käsityötä, jonka vain yksi insinööri ymmärtää.

Olemme pyörittäneet omaamme vuosia. Voimmeko silti migroida?#

Kyllä, tosin kerralla tehtävä "big bang" -siirto ei useimmiten ole oikea tapa. Migroi kerroksittain: laita uudet rekisteröitymiset, kirjautumiset ja yritys-SSO ensin identiteettialustalle, ja siirrä olemassa olevat käyttäjät heidän seuraavalla kirjautumisellaan. Pidä aina rollback-mahdollisuus ja audit-lokit mukana, jotta migraatio ei koskaan ole peruuttamaton.