Voitot:
- Kyky erottaa todennus ja valtuutus ja käyttää vähimmäisvaltuutusta RBAC/ABAC:n kanssa
- Kyky välttää sekavälityspalvelinriskiä suorittamalla malli käyttäjän kontekstissa
- Kyky tallentaa ja kiertää API-avaimia salaisen hallintajärjestelmän avulla
Merkittävä osa tekoälyjärjestelmää vastaan tehdyistä hyökkäyksistä ei aloita mallin "huijaamisesta", vaan varastetusta API-avaimesta tai ylivaltuutetusta tilistä. Tämä suojakerros tulee klassisesta tietoturvasta, mutta lisää uusia riskejä tekoälyn yhteydessä: malli soittaa kyydin jonkun toisen puolesta, palvelutili pääsee kaikkeen dataan, avain vuotaa GitHubille. Tässä osiossa opimme rajaamaan pääsyä tekoälyjärjestelmään autentikoinnin, valtuutuksen (RBAC/ABAC), vähimmäisvaltuutuksen ja salaisen hallinnan avulla.
Ero todennuksen ja valtuutuksen välillä
Nämä kaksi termiä sekoitetaan usein:
- Todennus: "Kuka sinä olet?" — sen todistaminen, että käyttäjä/palvelu on todella se, jonka he väittävät olevansa (salasana, tunnus, varmenne, MFA).
- Valtuutus: "Mitä voit tehdä?" — määrittää, mitä resurssia/toimintoa todennettu osapuoli voi käyttää.
Tekoälyjärjestelmien kriittinen hienovaraisuus on tämä: kun malli tekee työtä käyttäjän puolesta, toimiiko se kyseisen käyttäjän valtuuksilla vai laajalla palvelutilillä? Jälkimmäinen on vaarallista – koska ruiskeen huijattu malli saa täyden pääsyn palvelutilille.
Varoitus: "Sekava sijainen" -ongelma: vähäpätöinen käyttäjä käyttää epäsuorasti tietoja, joita hän ei voi käyttää ulkoistamalla korkean auktoriteetin mallin. Mallin tulee aina toimia käyttäjän auktoriteetin puitteissa, ei hänen oman laajan auktoriteettinsa puitteissa.
RBAC ja ABAC
- RBAC (Role-Based Access Control): Pääsy riippuu käyttäjän roolista. "Tukiasiantuntija" -rooli voi lukea asiakkaiden huomautuksia, mutta ei voi poistaa niitä. Yksinkertaista ja yleistä.
- ABAC (Attribute-Based Access Control): Pääsy riippuu attribuuteista: käyttäjän osastosta, tietojen tietosuojatunnisteesta, kellonajasta, verkosta, josta pyyntö tulee. Hienosäädetympi mutta monimutkaisempi.
Useimmat organisaatiot aloittavat RBAC:sta ja syvenevät ABACiin arkaluontoisten tietojen osalta. Tekoälyn peukalosääntö: mallin tulee suodattaa jokainen kutsumansa agentti ja kaikki käyttämänsä tiedot pyynnön tekevän käyttäjän roolin/määritteiden perusteella.
Askel askeleelta: Vähimmäisvallan käyttäminen
- Tee inventaario. Mitä työkaluja malli kutsuu, mitä tietoja se käyttää? Listaa ne kaikki.
- Perustele jokainen käyttöoikeus. "Tarvitseeko tämä avustaja todella poistovaltuuksia?" Muussa tapauksessa poista se.
- Vain luku -oletus. Mallin pitäisi pystyä lukemaan oletusarvoisesti; Edellytä erillistä, kapea-alaista merkintää/poistamista.
- Siirrä käyttäjän kontekstia. Soita ajoneuvoon käyttäjän valtuutuksella, ei palvelutilillä.
- Lyhytaikainen valtakirja. Käytä lyhytikäisiä, automaattisesti uusiutuvia tunnuksia pitkäikäisten avainten sijasta.
Salainen hallinta
Salaisuus ovat valtuustietoja, joiden on pysyttävä salassa, kuten API-avain, salasana, tunnus tai varmenne. Tekoälyprojekteissa yleisin tapaturma on, kun mallintoimittajan API-avain upotetaan koodiin ja vuotaa versionhallintaan (Git).
Oikea sovellus:
- Älä koskaan upota avaimia koodiin; Käytä ympäristömuuttujaa tai salaista hallintajärjestelmää (palvelu, joka tallentaa avaimet salattuna ja hallitsee pääsyä).
- Kierto: uusi avaimet säännöllisin väliajoin (esim. 90 päivän välein); Jos epäilet vuotoa, peruuta välittömästi.
- Soveltamisalan vähentäminen: Jokaisella kytkimellä on vain vaadittu palvelu ja vaadittu lupa.
- Tarkastus: kirjaa kuka käytti avainta, milloin ja missä.
Neljä kopioitavaa mallia
Pääsytarkistuksen hallintakehote:
Arvioi jokaiselle alla olevan työkaluluettelon työkalulle:- Vaaditaanko tämä työkalu tämän avustajan työn suorittamiseen? (kyllä/ei) - Onko se vain luku - vai kirjoitus/pyyhitys? - Kutsutaanko tätä työkalua käyttäjän valtuutus- tai palvelutilillä? Merkitse tarpeettomat tai liian valtuutetut kohteeksi "POISTA/MUOKKAA".<tools>{{ tool_list }}</tools>
Salainen vuodon skannauskehote:
Etsi seuraavasta koodinpätkästä kaikki, mikä voi olla kovakoodattu salaisuus: API-avain, salasana, tunnus, yhteysmerkkijono, yksityinen avain. Anna kullekin rivi ja tyyppi. COPY arvo vastaukseen;mask (ensimmäiset 4 merkkiä + ***).<code>{{ lähde }}</code>
Pienimmän viranomaisen päätöksen sääntö:
Kun uusi työkalu/käyttöpyyntö saapuu, kysy:1. Voidaanko tehtävä suorittaa ilman tätä käyttöoikeutta? -> Jos kyllä: hylkää2. Riittääkö pelkkä luku? -> Jos kyllä: MYÖNTÄ kirjoitusoikeus3. Voidaanko soveltamisalaa rajata yhteen lähteeseen? -> Jos kyllä: daratOletusvastaus on "ei"; Pääsy saavutetaan syystä.
Kiertokalenterin muistutus:
Jokaisen salaisuuden kohdalla tietue: omistaja, luontipäivämäärä, voimassaoloaika, laajuus. Ilmoita kaikki avaimet, jotka ovat ylittäneet 90 päivää tai joita ei ole käytetty 30 päivään "KIERTO-/PERUUTUSAHDOTUKSI".
Heikko kehote / Vahva kehote
huono lähestymistapa
Vahva lähestymistapa
Malli käyttää kaikkia tietoja yhdellä palvelutilillä
Malli käyttää pyynnön tekevän käyttäjän valtuuksia
API-avain on upotettu koodiin, se ei koskaan muutu
Kierto avaimen salaisuuden hallinnassa, 90 päivää
Laaja "tee mitä tahansa" -valtuudet avustajalle
Vain luku -oletus, kirjoita suppeasti
Pääsyjä ei koskaan tarkisteta
Säännöllinen käyttöoikeuksien tarkistus ja peruuttaminen
Kolme minikoteloa
Tapaus 1 – Vuotanut sekavälityspalvelintiedot. Talon sisäinen avustaja työskenteli palvelutilin kanssa, jolla oli pääsy kaikkiin työntekijätietoihin. Harjoittelukäyttäjä pääsi tietoihin, joita hän ei normaalisti näkisi sanomalla "yhteenveto johdon palkkataulukosta"; koska malli kyseenalaisti sen oman laajan auktoriteettinsa puitteissa, ei käyttäjän. Kun käyttäjäkonteksti oli säädetty siirrettäväksi, harjoittelija pystyi vetämään tallenteita, jotka vain hän näki.
Tapaus 2 — Vuotanut avain, 190 000 TL:n lasku kahdessa viikossa. Kehittäjä upotti mallin API-avaimen apuohjelmaan ja työnsi sen julkiseen arkistoon. Botti löysi avaimen 40 minuutissa ja käytti sitä kaksi viikkoa; Lasku oli 190 000 TL. Kun avain siirrettiin salaiseen hallintaan, yhdistettiin kiertoon ja arkiston tarkistus lisättiin, tapaus ei toistunut.
Tapaus 3 — Vain luku -oletuksena estetty keskeytys. DevOps-avustaja sai "nollaa tuotantotietokanta" -komennon kehotteen avulla. Assistentille annettiin kuitenkin vain luku -tunnus; kirjoitus/poistaminen oli erillisessä hyväksytyssä prosessissa. Komento hylättiin valtuutusvirheen vuoksi ja tapahtuma kirjattiin hälytyksenä; Tietojen menetystä ei tapahtunut.
Vinkki: Aseta "ei" oletusvastaukseksi uuteen käyttöoikeuspyyntöön. Pääsy on jotain, joka saavutetaan perustelun kautta; Kaikille antaminen ja sitten leikkaaminen on lähes koskaan tehty ja riskit kasaantuvat.
Yleisiä virheitä
- Mallin suorittaminen suurella palvelutilillä ja käyttäjäkontekstin menettäminen (sekavälityspalvelin).
- API-avaimen upottaminen koodiin ja sen vuotaminen versionhallintaan.
- Ei pyöritä näppäimiä ollenkaan ("toimii, älä koske").
- Oletuksena avustajan kirjoitus-/poistooikeudet.
- Käyttöoikeuden myöntäminen kerran, eikä sitä koskaan harkita uudelleen.
- Todennuksen sekoittaminen valtuutukseen ja oletus "hän on kirjautunut sisään, hän pääsee kaikkeen".
Yhteenvetona
- Todennus on kysymys "kuka olet", valtuutus on kysymys "mitä voit tehdä"; Tekoälyssä molempien on toimittava käyttäjän kontekstissa.
- Mallin tulee toimia pyynnön tekevän käyttäjän valtuudella, ei omalla laajalla valtuudellaan (välttäen sekaisin toimijan riskin).
- Aloita RBAC:lla, syvennä arkaluontoisten tietojen ABAC:lla; Tee oletusarvoksi minimaalinen auktoriteetti.
- Älä hauta salaisuuksia koodiin; tallenna se salaiseen hallintaan, rajaa sitä ja laita se säännölliseen kiertoon.
- Vain luku -oletus ja kapea kirjoitus rajoittavat suuresti injektion vaikutusta.
Sovellustehtävä
Luettele kaikki työkalut ja tiedot, joita AI-avustajasi käyttää. Vastaa kolmeen kysymykseen jokaisesta: (1) Onko se todella tarpeen? (2) Riittääkö vain luku? (3) Toimiiko se käyttäjän kontekstissa? Etsi sitten kaikki kovakoodatut salaisuudet (yllä olevan skannauskehotteen kautta) ja kirjoita kiertosuunnitelma jokaiselle löytämällesi avaimelle. Poista vähintään yksi tarpeeton valtuutus.
tarkistuslista
- [ ] Malli toimii pyynnön tekevän käyttäjän auktoriteetin kontekstissa.
- [ ] Työkalujen ja tietojen käyttöoikeus on rajoitettu vähiten etuoikeuksien periaatteeseen.
- [ ] Kirjoitus/tyhjennys on erillinen vain luku -käytöstä, todennettu ja kapea.
- [ ] Koodiin ei ole haudattu salaisuuksia; Sitä säilytetään salaisessa hallinnassa.
- [ ] Avaimille on kiertoaikataulu ja peruutusmenettely.
- [ ] Käyttöoikeudet tarkistetaan säännöllisesti.