Lokit eivät ole todisteita
Epämukava vaihe hallintapaneelin jälkeen
Ensimmäinen auditointikokous alkaa yleensä luottavaisesti. Tiimillä on hallintapaneelit. Tiimillä on lokitus. Tiimillä on säilytyskäytäntö, SIEM-integraatio, muutama kuvakaappaus ja joku, joka tietää, mistä pilvikonsolista vientipainike löytyy. Kaikki ovat tehneet tavalliset asiat. Juuri siksi kokouksesta tulee epämukava.
Auditoija ei kysy, onko lokitiedostoja olemassa. Tietenkin niitä on. Jokainen moderni järjestelmä tuottaa niitä kiloittain. Kysymys on siitä, pystyykö tallenne vastaamaan tiettyyn tarkastuskysymykseen ilman, että tiimi rakentaa tarinaa uudelleen käsin. Kuka hyväksyi työkalukutsun? Mikä työnkulun versio suoritettiin? Mitä tietojen käyttöoikeutta hyödynnettiin? Milloin tekoälyyn liittyvä poikkeama tuli tietoon? Mitä tarkalleen ottaen julkaistiin? Voiko ketjun tarkistaa sen jälkeen, kun järjestelmä on siirretty, kun tiedosto on kierrätetty, kun alkuperäinen palvelu on korvattu?
Tässä kohtaa tavallinen lokitus alkaa horjua. Lokirivi on hyödyllinen operatiivinen vihje. Se kertoo kehittäjälle, mistä savu tulee. Se ei ole automaattisesti todiste. Se voi olla vapaamuotoista tekstiä. Sitä voivat sekoittaa kellot, puskurointi, työntekijät, uudelleenyritykset ja tiedostojen kierrätys. Kentät voivat olla epäjohdonmukaisia, koska yksi tiimi kirjoitti rakenteista JSONia ja toinen tiimi kirjoitti mitä tahansa, mikä tuntui hyödylliseltä kello 23.41. Hollantilainen erikoisuus, muuten: kirjoita kaunis prosessidokumentti ja tallenna sitten ainoa hyödyllinen tosiasia lokiviestiin nimeltä misc. Hyvin tehokasta, jos tavoitteena on myöhempi katumus.
Ledger on olemassa kohtaa varten, jossa katumuksesta tulee kallista. Se on append-only-virta tyypitetyistä tapahtumista, ryhmiteltynä istuntoihin, linkitettynä hajautusarvoilla, tallennettuna tallennuspalveluihin ja toistettavissa järjestelmän historiana. Se ei yritä korvata jokaista tietokantaa. Se ei yritä olla AION. Se ei ole todiste johtopäätöksestä yksittäisen päätöksen sisällä. Se on sinetöity operatiivinen tallenne siitä, mitä järjestelmän ympärillä tapahtui.
Ero kuulostaa pieneltä, kunnes ensimmäinen vakava tarkastus tulee. Lokit edellyttävät, että tarkastaja uskoo rivijoukon olevan riittävän täydellinen, riittävän järjestyksessä ja riittävän muuttumaton. Ledger muuttaa vastauksen muodon. Se sanoo: tässä on tapahtuma, tässä on edellinen hajautusarvo, tässä on istunto, tässä on tyypitetty sisältö, tässä on miten ketjua kävellään. Vähemmän teatteria. Enemmän objektia.
Auditointikysymyksellä on muoto
Hyvät auditointikysymykset ovat ärsyttävän konkreettisia. Niihin ei tee vaikutusta se, että järjestelmä oli monimutkainen. Ne eivät välitä siitä, että käyttöönotossa oli kymmenen palvelua ja viestiväylä mielipiteineen. Ne kysyvät ajankohtaa, vastuullista toimintaa, tallennetta ja tapaa varmistaa, että tallenne tarkoittaa edelleen samaa kuin silloin, kun se kirjoitettiin.
Siksi Ledger alkaa tyypitetyistä tapahtumista. Työkalukutsu ei ole vain merkkijono, joka sisältää tekstin tool called. Työkalun tulos ei ole vain lause. Hyväksyntä ei ole olankohautus tikettijärjestelmässä. Suostumus, DPIA-toiminta, rekisteröidyn oikeudet, poistopyynnöt, tekoälypoikkeamat, SBOM-luonti, vakuutukset, artefaktit, istunnot, tarkistuspisteet, toistotulokset: nämä kuuluvat tapahtumamuotoihin. Sivusto kuvaa yhdeksän kategoriaa ja kaksikymmentäkolme muunnelmaa; paikallinen tapahtumaskaema tukee tätä rakennetta. Tarkka lukumäärä on vähemmän tärkeä kuin sen takana oleva suunnittelutapa. Tarkastuskysymyksen pitäisi osua tyyppiin, ei kappaleeseen.
Kirjoittaminen ei ole byrokratiaa byrokratian vuoksi. Se estää jokaista tutkimusta muuttumasta pienimuotoiseksi arkeologiahankkeeksi. Jos tapahtumalla on luokka, hyötykuorma, aikaleima, istunto, vanhempisuus viittaus tarvittaessa, metatiedot, sisältötiiviste, edellinen tiiviste, valinnainen allekirjoitus ja vaatimustenmukaisuusmetatiedot, tarkastajalla on tietue, jota tutkia. Jos tapahtuma on muotoiltu merkkijono, tarkastajalla on tunnelma.
Tämä ei ole sota lokeja vastaan. Lokit ovat edelleen hyödyllisiä käynnissä oleville järjestelmille. Ne ovat insinöörin reunahavainto. Ledger on niitä hetkiä varten, jolloin reunahavainto ei riitä. Tarkastus kysyy, säilytettiinkö historia, voidaanko tietue toistaa, voidaanko tila rakentaa uudelleen ja näkyvätkö hiljaiset muokkaukset. Nämä kysymykset vaativat rakenteen, joka on suunniteltu ennen tapausta, ei koottu sen jälkeen.
Vain lisäys on lupaus, jonka voit testata
Vain lisäys kuulostaa yksinkertaiselta lupaukselta. Kirjoita kerran. Lisää loppuun. Älä kirjoita historiaa uusiksi. Käytännössä tämä lupaus merkitsee vain, jos tietue voi paljastaa peukaloinnin, katkaisun, puuttuvat linkit ja katkenneen jatkuvuuden. Tekstitiedostoa voidaan kutsua vain lisäys -periaatteella toimivaksi politiikkadokumentissa, mutta jos rivi katoaa eikä mikään valita, politiikka oli lähinnä sisustusta.
Ledger mallintaa eheyden tapahtumatasolla. Jokaisella tapahtumalla on sisältö, joka vaikuttaa sisältötiivisteeseen. Tapahtuma osoittaa myös edelliseen ketjutiivisteeseen. Tallennuksen ylläpito voi varmistaa jatkuvuuden. Toisto voi käydä tapahtumat läpi järjestyksessä. Luottamusankkurit voivat sinetöidä segmenttejä. Tärkeä ajatus on, että eheyttä ei ole ulkoistettu tallennuspalvelulle, joka sanoo kirjoituksen onnistuneen. Tapahtuma itse kantaa linkin, jonka avulla ketju voidaan tarkistaa.
Putki on tarkoituksella tavallinen: lisää, tiivistä, ankkuroi, säilytä, toista. Tavallinen on hyvä asia tässä. Auditointi-infrastruktuuri ei saisi riippua sankariteoista. Jos järjestelmä tarvitsee rohkean insinöörin taulukkolaskentaohjelman kanssa aina, kun tarkastaja kysyy peruskysymyksen, järjestelmää ei ole tehty vastuulliseksi. Sille on vain palkattu kärsivällinen henkilö.
Lähdemateriaali tarjoaa myös hyödyllisen käyttöönottokohdan. Ledger voi sijaita lähellä järjestelmää: upotettuna Rust-rajapintana, C-ABI:na, sivupalvelimena tai palvelupintana. Tämä on merkityksellistä, koska kaukaa kirjattu alkuperä saapuu usein myöhään, menettää kontekstin tai suodattuu kuljetuksesta vastaavan tahon mukavuuden kautta. Mitä lähempänä tapahtuma on itse tapahtunutta asiaa, sitä vähemmän tulkinnallisia kikkoja tarvitaan myöhemmin.
Ledger ei ole AION, ja se on hyvä asia
Yleinen vika tekoälyn hallinnassa on käyttää yhtä sanaa viidestä erilaisesta todisteesta. Kaikesta tulee jäljitettävyyttä, alkuperää, selitettävyyttä tai läpinäkyvyyttä. Sanoista tulee lämmintä keittoa. Kaikki nyökkäävät, kukaan ei voi toistaa mitään, ja sitten sääntelijä kysyy tarkentavan kysymyksen. Tämä ei ole strategia. Se on sumua laskujen kanssa.
Ledger ja AION vastaavat eri kysymyksiin. Ledger tallentaa, mitä järjestelmässä tapahtui: työkalujen kutsut, tulokset, hyväksynnät, artefaktit, istunnot, vaatimustenmukaisuustapahtumat, poikkeamat, vakuutukset. AION varmentaa päättelyvaiheet päätöksen sisällä: annetuista lähtökohdista ja säännöistä, seurasiko tämä johtopäätös tallennetun todistuksen kautta? Trace puolestaan kuljettaa operaatioiden graafit, politiikkaportit, tiivisteet, juuret ja toistopolut laskentaa varten. Selvedge tallentaa suorituspöytäkirjat hiekkalaatikossa. Lattice arvioi politiikkaportteja. Nämä ovat naapureita, eivät synonyymejä.
Erottelu ei ole pilkunviilausta. Se estää tiimejä liioittelemasta. Erittäin hyvä Ledger-tietue voi osoittaa, että malli kutsuttiin, että hyväksyntä myönnettiin, että artefakti tuotettiin ja että poikkeama kirjattiin. Se ei yksinään todista, että looginen johtopäätös seurasi. Se on AIONin aluetta. Hyvä AION-sertifikaatti voi todistaa päättelypolun, mutta se ei yksinään kirjaa jokaista työnkulun ympäröivää operatiivista tapahtumaa. Se on Ledgerin aluetta.
Kun rajat ovat selkeät, pinosta tulee helpommin puolustettava. Operatiivinen aikajana elää Ledgerissä. Päätöksen todiste elää AIONissa. Laskennan jälki elää Tracessa. Käytäntöpäätös voidaan arvioida uudelleen Laticen kautta. Hiekkalaatikon suoritus voidaan toistaa Selvedgen kautta. Arvioija voi esittää täsmällisen kysymyksen ja saada oikeanlaisen objektin, ei esitettä läpinäkyvyydestä.
Tallennus ei saa muuttaa merkitystä
Yksi helpoimmista tavoista pilata auditointijälki on antaa tallennusvalinnan muuttaa tietueen merkitystä. Muistipohjainen taustajärjestelmä testejä varten, JSONL-tiedosto siirrettävyyttä varten, paikallinen tietokanta sulautettua käyttöä varten, palvelintietokanta indeksoitua tuotantokäyttöä varten, arkistointisäiliö pitkäaikaissäilytystä varten: nämä ovat käyttöasentopäätöksiä. Niiden ei pitäisi luoda viittä erilaista totuutta.
Sekä Ledgerin lähde että sivusto korostavat vaihdettavaa tallennusta ja vakaata tapahtumamallia. Tarkka taustajärjestelmäluettelo on hieman eriytynyt lähteiden välillä, joten julkinen opetus on yksinkertaisempi ja vahvempi: tallennus on kerros, ei skeema. Tietueen muodon tulisi säilyä siirroissa. Migraation ei pitäisi muuttaa tapahtumaa uudeksi tulkinnaksi itsestään. Jos organisaatio muuttaa käyttöasentoaan, ketjun tulisi pysyä ketjuna.
Tämä kuulostaa itsestäänselvyydeltä, kunnes katsoo oikeiden järjestelmien epäonnistuvan siinä. Tiimi kirjaa täydet kentät kehityksessä, karsii kenttiä tuotannossa kustannusten vuoksi, vie eri muodon analytiikkaan, tallentaa osajoukon datajärveen ja toivoo sitten, että myöhempi tarkastelu hyväksyy yhdistelmän. Se ei ole ketju. Se on leikekirja. Silloin tällöin hyödyllinen leikekirja, mutta silti leikekirja.
Ledgerin käytännön arvo on siinä, että se antaa tiimeille yhden tapahtumamuodon, jonka ympärille suunnitella. Tallennuskerros voidaan valita skaalan, kustannusten, säilytyksen, kyselytehon tai eristyksen mukaan. Tarkastelun kohteena pysyy tapahtumavirta. Auditoijan ei tarvitse oppia jokaisen taustajärjestelmän luonnetta ennen kuin kysyy, säilyikö historia.
Mitä tarkastelu kysyy
Tarkasteluhetki on aina vähemmän abstrakti kuin arkkitehtuurikaaviot antavat ymmärtää. Joku kysyy, kuka hyväksyi toimenpiteen. Joku kysyy, oliko suostumus olemassa. Joku kysyy, milloin organisaatio tiesi tekoälypoikkeamasta. Joku kysyy, mikä ohjelmistosisältöluettelo tai attestaatio oli olemassa, kun asia julkaistiin. Jos nämä tosiasiat eivät ole jo tietueita, tiimi alkaa rekonstruoida niitä tiketeistä, keskusteluista, käyttöönotolokeista, sähköposteista ja toivosta. Toivo ei ole tietomalli. Harmi, sillä sen käyttöönottoaste on erinomainen.
Tässä Ledgerin tapahtumataksonomia osoittaa arvonsa. ApprovalRequested, ApprovalGranted, ApprovalDenied. ConsentRecorded. DataSubjectRightExercised. DpiaCompleted. RightToErasureRequested. AiIncidentDetected. SbomGenerated. AttestationCompleted. Nämä nimet eivät ole hohdokkaita. Hyvä. Complianceen liittyvä hohdokas osa on yleensä siellä, missä ongelmat alkavat. Hyödyllinen osa on tylsä tietue, joka on olemassa ennen kuin kukaan on hermostunut.
AI-järjestelmien kannalta tämä on tärkeää, koska toimintaa ympäröivät tosiasiat ovat usein yhtä tärkeitä kuin mallin tuottama tulos. Päätös voi olla teknisesti oikea mutta toiminnallisesti puolustuskyvytön, jos suoritettiin väärä versio, käytettiin väärää datan laajuutta, ohitettiin väärä hyväksyntäpolku tai tapahtumatieto luotiin kolme päivää sen jälkeen, kun kaikki jo tiesivät asiasta. Malli ei ole koko järjestelmä. Hyvin ärsyttävää mallipalvojille, hyvin hyödyllistä aikuisille.
Tyypitetyt tapahtumat tekevät myös vastuusta vähemmän liukasta. Katselmuskysymys voi osoittaa tapahtumaan, jonka pitäisi olla olemassa. Jos se on olemassa, tarkasta se. Jos sitä ei ole, tämä puuttuminen on itsessään tosiasia. Se on parempi kuin teeskennellä, että vastaus on jossain lokeissa, jos vain jollakulla on tarpeeksi regex-kestävyyttä.
Toisto tekee tallenteesta hyödyllisen
Tallenne, jota ei voi toistaa, on usein vain muistin tuki. Se voi auttaa ihmisiä selittämään, mitä todennäköisesti tapahtui. Toisto muuttaa tämän. Se antaa tiimin kävellä järjestettyjen tapahtumien läpi ja rakentaa tilan uudelleen tietyssä ajankohdassa. Tämä eroaa aikajanan lukemisesta. Se on lähempänä sitä, että järjestelmän historiaa pyydetään laskemaan oma menneisyytensä.
Ledger ryhmittelee tapahtumat istunnoiksi. Istunto voi edustaa keskustelua, työnkulkua, suoritusta tai suorituksen ajanjaksoa. Tapahtumia voidaan kysellä yhdessä ja toistaa yhdessä. Tarkistuspisteet tekevät pitkistä historiosta vähemmän kivuliaita. Eheystarkistukset tekevät katkenneista ketjuista näkyviä. Tämä on tärkeää, koska todelliset poikkeamat ovat harvoin yksittäisiä tapahtumia. Ne ovat sarjoja. Järjestys, konteksti ja vanhempisuhteet tulevat osaksi vastausta.
Toisto muuttaa myös todisteiden taloutta. Ilman toistoa jokaisesta vakavasta kysymyksestä tulee käsityötä. Toiston avulla organisaatio voi ottaa otoksia tallenteista, testata jatkuvuutta, tarkastaa istuntoja ja rakentaa tilan uudelleen osana normaalia toimintaa. Tämä ei poista harkintaa. Se poistaa luokan vältettävissä olevaa kaaosta.
Paras versio tästä on hiljainen. Kukaan ei juhli sitä, että katselmuskysymykseen saatiin vastaus tallenteesta. Sen pitäisi tuntua normaalilta. Tapahtuma kirjoitettiin, kun toiminta tapahtui. Ketju varmistuu edelleen. Istunto rakentuu uudelleen. Tila valitussa kohdassa on näkyvissä. Se on ohjelmiston vastine kuittien säilyttämiselle, paitsi että kuitti voi valittaa, jos joku leikkaa siitä palan pois.
Miksi tämä kuuluu lähelle AI-työtä
AI-työllä on tapana tuottaa vaikuttavia vastauksia ja heikkoa toiminnallista muistia. Tiimit muistavat demon, kehotteen, mallin nimen, ehkä kuvakaappauksen, mahdollisesti Slack-ketjun, jossa joku sanoi julkaistaan. Sitten järjestelmä siirtyy tuotantoon ja alkaa tehdä päätöksiä, kutsua työkaluja, käyttää dataa, siirtää artefakteja, pyytää hyväksyntöjä ja luoda poikkeuksia. Siinä vaiheessa tulos ei ole enää ainoa tarina.
Agenttijärjestelmät tekevät tästä terävämpää. Agentti ei pelkästään vastaa. Se havainnoi, hakee, päättelee, toimii ja siirtää työtä muille järjestelmille. Jokainen työkalukutsu ja tulos voi olla merkityksellinen. Jokainen hyväksyntä voi olla merkityksellinen. Jokainen artefakti voi olla merkityksellinen. Jokainen käytäntöportti voi olla merkityksellinen. Jos ainoa kestävä tallenne on sekalainen kasa lokeja, organisaatio on rakentanut kiireisen järjestelmän, jolla on huono muisti.
Ledger antaa tälle muistille muodon. Se ei tee agentista turvallista yksinään. Se ei siunaa huonoa työnkulkua. Se ei todista matemaattista johtopäätöstä. Se tallentaa toiminnallisen jäljen tavalla, joka voidaan varmistaa ja toistaa. Se on jo vakava askel eteenpäin kuvakaappauksista, konsolivienneistä ja retrospektiivisen totuuden pyhästä laskentataulukosta.
Tämä parantaa myös insinöörityön laatua. Kun tapahtumat ovat tyypitettyjä, tiimien on päätettävä, mikä on olennaista. Kun tapahtumat ovat hajautusketjutettuja, tiimien on kohdeltava historiaa ketjuna. Kun tapahtumat ovat toistettavissa, tiimit voivat testata, rakentuuko heidän operatiivinen kertomuksensa todella uudelleen. Vastuullisuus lakkaa olemasta riskiosion kappale ja siitä tulee osa ajonaikaista sopimusta.
Opetus
Opetus ei ole se, että lokit ovat huonoja. Lokit ovat hyödyllisiä. Ne auttavat ihmisiä ylläpitämään järjestelmiä, selvittämään vikoja, ymmärtämään suorituskykyä ja säästävät kehittäjät siltä, että heidän pitäisi päätellä tuotantokäyttäytyminen mututuntumalla. Mutta lokit eivät ole automaattisesti todisteita. Tekstirivistä ei tule luotettavaa vain siksi, että sen on kirjoittanut vakavanniminen palvelin.
Todisteet tarvitsevat rakenteen. Ne tarvitsevat jatkuvuuden. Ne tarvitsevat omistajuuden. Ne tarvitsevat tavan havaita muokkaukset ja aukot. Niiden on kestettävä tallennussiirrot, käyttöönottomuutokset, toimittajavaihdokset ja hyvin inhimillisen halun siistiä historiaa ennen arviointia. Ledger on avoin operatiivinen rekisteri tähän tehtävään: tyypitetyt tapahtumat, hajautusketjutus, istunnot, toisto, eheystarkistukset ja käyttöönottopinnat riittävän lähellä järjestelmää ollakseen hyödyllisiä.
On kuivaa komiikkaa siinä, että vastuullisen tekoälyn tulevaisuus riippuu parempien merkintöjen tekemisestä tylsistä tapahtumista. Mutta niin vakavat järjestelmät toimivat. Vaikuttava vastaus saa huomiota. Rekisteri ratkaisee, pitäisikö kenenkään vielä uskoa järjestelmään kuuden kuukauden kuluttua.
Joten pitäkää lokit. Lukekaa niitä, hakekaa niistä, piirtäkää niistä kaavioita, kirotkaa niille, kun aikaleiman muoto muuttuu. Älkää vain sekoittako niitä todisteisiin. Todisteet ovat rekisteri, jonka läpi voitte kulkea taaksepäin, ketju, joka valittaa, kun se on rikki, ja tila, jonka voitte rakentaa uudelleen, kun huone hiljenee ja joku kysyy, mitä oikeasti tapahtui.