NIST vill varanlegt auðkenni en skammlífa lykla fyrir gervigreindarfulltrúa

Bandaríska staðlastofnunin NIST birti 29. september 2026 samantekt umsagna frá meira en 600 aðilum um auðkenni og heimildagjöf hugbúnaðar og gervigreindarfulltrúa. National Cybersecurity Center of Excellence (NCCoE), sem starfar innan NIST, ætlar að nota örugga hugbúnaðarþróun, DevSecOps, sem fyrsta innleiðingardæmi: þar verður sýnt hvernig fulltrúar geta auðkennt sig og fengið afmarkaðar heimildir í hugbúnaðarferli.

Meginlínan í umsögnunum er að tengja fulltrúa við varanlegan traustgrunn en láta skilríki og aðgang fyrir einstök verkefni endast stutt og vera afturkallanleg. Einn umsagnaraðili orðaði kjarnann svo í samantekt NCCoE: „The identity anchor should be stable.“ Þessi aðgreining verður viðfangsefni áframhaldandi vinnu, en val á nákvæmri tækni og stöðlum bíður útfærslu í sýnidæminu.

Traustgrunnurinn helst þótt skilríkin renni út

Varanlegur traustgrunnur á að tengja fulltrúa við hugbúnaðarafurðina, stofnunina sem ber ábyrgð á honum og umhverfið þar sem hann er keyrður. Þannig verður hægt að rekja uppruna hans þótt einstök keyrsla ljúki og tímabundið aðgangsskilríki falli úr gildi. Traustgrunnurinn er ekki sjálfur leyfi til að lesa gögn eða breyta kóða; slík heimild ræðst af verkefni og aðstæðum hverju sinni.

Umsagnaraðilar lögðu til að skilríki væru tengd þessum grunni með sannreynanlegum hætti. Þau ættu að renna út þegar tilteknu undirverki lýkur eða tími þess er liðinn. Ef skilríki verður óöruggt þarf að vera hægt að afturkalla það sérstaklega, án þess að eyða varanlega auðkenninu eða stöðva aðrar samtímis keyrslur sama kerfis.

Þessi skipting svarar vandamáli sem verður skýrara þegar hugbúnaður stofnar marga skammlífa fulltrúa. Aðgangslykill sem lifir lengur en verkefnið getur nýst áfram eftir að tilgangur aðgangsins er horfinn; einn sameiginlegur lykill fyrir alla fulltrúa gerir jafnframt erfiðara að afmarka áhrif leka. Í tillögunum er því gert ráð fyrir að hver keyrsla fái aðeins þá heimild sem hún þarf og geti misst hana án þess að rekjanlegur uppruni hennar glatist.

Framsal heimilda þarf að þrengjast

Auðkenni fulltrúa svarar því hver eða hvað sendir beiðni; heimildagjöf svarar hvort þessi beiðni megi fara fram. Umsagnirnar greina líka á milli þjónustuauðkennis, keyrslunnar sjálfrar, þess manns eða þeirrar stofnunar sem heimilaði verkefnið og heimildarinnar sem gildir á þessu augnabliki. Fastur auðkennisstrengur einn og sér getur því ekki skýrt hvers vegna tiltekin aðgerð var leyfð.

Þegar fulltrúi felur undirfulltrúa hluta verksins á að heimildin þrengjast með framsalinu. Sá sem tekur við má ekki sjálfkrafa erfa öll réttindi notandans eða yfirfulltrúans, heldur þarf aðgangur hans að ná til skilgreinds gagns, verkfæris og aðgerðar. Þetta á einnig við þegar verkefni fer milli þjónusta eða yfir mörk stofnana: móttakandi þarf að geta sannreynt bæði hver sendir beiðnina og hvaðan heimildin kom.

Ákvörðun um aðgang þarf einnig að taka mið af því sem fulltrúinn er að gera á þeirri stundu, fremur en aðeins innskráningu við upphaf verkefnis. Ný fyrirmæli, breytt verkefni eða ótraust gögn geta breytt forsendum aðgangs. Í umsögnunum er því lögð áhersla á samfellda, aðstæðubundna heimildagjöf og skýra aðgreiningu hennar frá fyrirmælum sem fulltrúi túlkar sjálfur.

Rekjanleiki án óþarfa persónugagna

Framsal nýtist lítið til ábyrgðar ef ekki er hægt að rekja aðgerð aftur að upphaflegri beiðni. Í umsögnunum er lýst þörf fyrir skráningu sem sýnir hvaða beiðni var metin, hvaða auðkenni og framseldar heimildir áttu við, hvaða ákvörðun var tekin og hvaða verkfæri var síðan kallað. Skrá yfir API-köll ein og sér gefur ekki þessa heildarmynd, sérstaklega þegar nokkrir fulltrúar vinna í sömu keðju.

Varanleg auðkenning hugbúnaðar kallar þó ekki á að fast persónuauðkenni notanda fylgi öllum beiðnum hans milli þjónusta. Umsagnaraðilar bentu á að samtenging slíkra auðkenna gæti gert kleift að rekja ferðir einstaklings og draga ályktanir um hegðun hans. Fyrirmæli, verkefnissamhengi og aðgerðaskrár geta líka geymt viðkvæm gögn, jafnvel þótt þau séu skráð vegna öryggis.

Af þessu leiðir tvíþætt hönnunarverkefni: varðveita nægar sannanir til að rekja hver heimilaði aðgerð og hvers vegna hún fór fram, en senda og geyma aðeins þær persónuupplýsingar sem þarf fyrir þá ákvörðun. Í samantektinni eru nefndar afmarkaðar framsalsheimildir, sýnilegt samþykki og stýring á gögnum þegar fulltrúi sendir samhengi áfram til annars fulltrúa, ytri þjónustu eða verkfæris. Nákvæm mörk þessara upplýsinga ráðast af notkunardæminu.

DevSecOps verður fyrsti prófsteinninn

Fyrsta fyrirhugaða sýnidæmið snýr að fulltrúum í hugbúnaðarþróun, þar sem sama ferli getur falið í sér lestur kóða, breytingar, prófanir og dreifingu. Slíkar aðgerðir þurfa ólíkar heimildir og geta farið í gegnum fleiri en eina þjónustu. Fyrir lítið hugbúnaðarteymi er meginspurningin hvort auðkenni fulltrúa, tímamörk skilríkja, framsalskeðja og aðgangsákvarðanir séu nægilega aðgreind til að hægt sé að stjórna þeim hverju fyrir sig.

Samantektin er enn samráðsyfirlit, ekki bindandi tækniforskrift; óháð stöðuskrá um auðkenni fulltrúa flokkar hana einnig sem verkefnisgagn fremur en staðal eða staðfestingu á virkri útfærslu. Næsta fyrirhugaða skref verkefnisins er birting draga að verkefnislýsingu þar sem óskað verður umsagna um umfang, notkunardæmi, kerfishögun og staðla. Sú lýsing mun afmarka hvaða hugmyndir úr umsögnunum verða reyndar saman í fyrsta DevSecOps-dæminu.

Lestu einnig:

• Slack eða Teams: ódýrara valið ræðst af hugbúnaðinum sem er fyrir
• GitHub krefst nýrrar auðkenningar — stolinn vefkökuaðgangur dugar ekki
• 48% starfsmanna ýkja gervigreindarkunnáttu sína undir þrýstingi