Jinsi ya kulinda siri dhidi ya mawakala wa AI

Maana ya kutoweka siri ndani ya mawakala wa AI

Wakala wa AI ni mchakato wa kawaida wa Linux unaoendesha amri. Kila kigezo cha mazingira ambacho mchakato huo unashikilia kinaweza kusomwa na msimbo unaouendesha. Kwa hiyo, ufunguo wa API ulio katika mazingira ya wakala unaweza kutumwa na wakala kwa seva pangishi yoyote inayoweza kufikiwa. Kutoweka siri ndani ya wakala kunamaanisha kuupa kishikio badala ya ufunguo: tokeni yenye muda mfupi wa matumizi na wigo maalumu, au kishikilia-mahali ambacho kitu kingine hubadilisha kuwa thamani halisi kwenye mpaka wa mtandao.

Hili si hadithi kuhusu modeli kuwa na uhasama. Utaratibu wake ni wa kawaida zaidi. Wakala husoma ukurasa wa wavuti, README, au maoni ya suala yenye maagizo, kisha huyafuata, kwa sababu kwa modeli ya lugha hakuna tofauti kati ya maandishi uliyoandika na maandishi iliyoyapata. Huo ni udungaji wa maagizo. Ukishatokea, uharibifu una mipaka inayowekwa na jambo moja pekee: kile ambacho mchakato unaweza kusoma. Ikiwa bado hujaweka mpaka, kuendesha wakala wa kuandika msimbo kwa usalama kwenye seva kunaeleza viwango vya utengaji ambavyo mwongozo huu unategemea.

Muundo wa tishio kwa maneno rahisi

Tekeleza hili kama mtumiaji anayeendesha wakala wako.

tr '\0' '\n' < /proc/self/environ | grep -iE 'key|token|secret|password'

Kila mstari unaochapishwa na hii ni ombi moja la HTTP kutoka kwa seva ya mtu asiyejulikana. Sasa angalia kilicho kwenye diski karibu na wakala.

grep -rIl --exclude-dir=.git -e 'API_KEY' -e 'SECRET' ~/projects
find ~ -maxdepth 3 -name '.env' -o -name 'credentials' -o -name '*.pem'

Wakala mwenye shell hahitaji kutumia udhaifu wa kiufundi ili kutoa data hiyo nje. Njia nne za kawaida zinatosha, na zote nne huonekana kama kazi ya kawaida kwenye logi:

• curl au fetch ya nje kwenda kwa host yoyote, ikiwa thamani iko kwenye mfuatano wa hoja.
• git commit na git push kwenda kwenye repository ambayo wakala anaweza kuandikia.
• Script ya usakinishaji wa package, ambayo huendesha code yoyote kama mtumiaji wa wakala.
• Utafutaji wa DNS wa jina la host lenye thamani hiyo, ambao hufanyika hata egress ya HTTP ikiwa imezuiwa.

Huwezi kutatua hili kwa ukaguzi pekee. Suluhisho ni kuhakikisha kuwa hakuna kitu cha thamani kinachoweza kufikiwa.

Siri katika mti wa kazi ni siri katika dirisha la muktadha

Wakala husoma faili. Faili ya .env iliyo katika hifadhi ambayo wakala anafanyia kazi itasomwa. Baada ya kusomwa, huwa katika dirisha la muktadha. Hii inamaanisha kuwa huwa katika nakala ya mawasiliano, katika kumbukumbu yoyote unayohifadhi, na katika chochote ambacho wakala huandika baadaye.

Hapo awali, wakati ufunguo ulikuwa katika mti ambao wakala anafanyia kazi:

cd ~/projects/billing
cat .env
# STRIPE_SECRET_KEY=sk_live_...
# DATABASE_URL=postgres://app:hunter2@db.internal:5432/billing

Baadaye, baada ya faili kuhamishwa na kutofikika:

sudo install -d -m 750 -o root -g agent-review /etc/agent-review
sudo install -m 640 -o root -g agent-review ~/projects/billing/.env /etc/agent-review/billing.env
rm ~/projects/billing/.env

Mtumiaji wa wakala hawezi tena kufungua faili hiyo, kwa sababu mti wa kazi hauina tena faili hiyo. Sheria za kukataa katika usanidi wa wakala ni safu ya pili, si ya kwanza. Claude Code husoma sheria za ruhusa kutoka .claude/settings.json katika mradi:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Read(./**/*.pem)"]
  }
}

Hii huzuia kosa la kawaida la wakala kufungua faili anapochunguza. Haizuii maagizo yaliyodungwa kuendesha base64 .env, kwa sababu hiyo ni amri ya shell, si usomaji wa faili. Chukulia usanidi kuwa kizuizi cha usalama, na ruhusa za mfumo wa faili kuwa ukuta. Mgawanyo huo huo hutumika ndani ya kontena: faili za mazingira na siri katika Docker Compose inaeleza toleo la tatizo hili katika tabaka moja la chini.

Mpe kila wakala akaunti yake isiyo na mapendeleo

Wakala akiendesha kama wewe, anarithi funguo zako za SSH, vitambulisho vyako vya cloud, na historia ya shell yako. Akaunti tofauti inahitaji amri moja tu na huondoa yote hayo.

sudo adduser --disabled-password --gecos "" agent-review
sudo chmod 700 /home/agent-review
sudo -u agent-review cat ~/.ssh/id_ed25519

Mstari wa mwisho lazima ushindwe kwa cat: /home/you/.ssh/id_ed25519: Permission denied. Ikiwa utachapisha funguo badala yake, saraka yako ya nyumbani inaweza kusomeka na kikundi au kila mtumiaji, na chmod 700 ~ hurekebisha hali hiyo. Usimwongeze mtumiaji wa wakala kwenye sudo, wala usimpe kanuni ya NOPASSWD iliyo pana kuliko amri moja anayohitaji kwa kweli. Watumiaji wenye mapendeleo machache kwenye VPS inaeleza kwa kina mipangilio ya vikundi na sudoers.

Kuna mpaka mwingine unaofaa kuweka kwenye VPS ya cloud. Huduma ya metadata ya instance hujibu kwenye anwani isiyobadilika ya link-local, na mara nyingi huwapa vitambulisho vya jukumu kitu chochote kinachoviomba.

sudo iptables -A OUTPUT -m owner --uid-owner agent-review -d 169.254.169.254 -j REJECT

Ihakikishe kutoka upande wa wakala. sudo -u agent-review curl -s --max-time 3 http://169.254.169.254/ inapaswa kuchapisha chochote na kutoka kwa hali isiyo ya sifuri, kwa sababu pakiti inakataliwa kabla haijaondoka kwenye mashine.

Ingiza kitambulisho cha uthibitishaji kwenye mpaka

Mfumo unaotatua tatizo hili kwa kweli ni kuingiza kitambulisho cha uthibitishaji. Agent haiwahi kushikilia key halisi. Hutuma ombi lake kupitia gateway ya ndani, na gateway hubadilisha kishikilia nafasi kuwa siri halisi inapotumwa nje. Siri huhifadhiwa katika hifadhi ya gateway, kwenye mchakato tofauti unaomilikiwa na mtumiaji tofauti.

OneCLI ni utekelezaji mmoja wa open source wa mfumo huu, wenye leseni ya Apache-2.0, na huendeshwa kama container kando ya agent. Kufikia Julai 2026, mradi unaandika usanidi huu:

git clone https://github.com/onecli/onecli.git
cd onecli
docker compose -f docker/docker-compose.yml up -d --wait

Dashboard husikiliza kwenye port 10254 na gateway husikiliza kwenye port 10255. Unahifadhi credential halisi mara moja, kisha unampa kila agent thamani ya kishikilia nafasi badala ya key pamoja na access token yake yenye upeo maalum, ambayo huituma katika header ya Proxy-Authorization. Gateway hulinganisha ombi linalotoka kwa kutumia host na path, hufichua credential inayolingana, kisha huiweka badala yake. Mazingira ya agent hayahifadhi chochote chenye thamani ya kuibiwa.

Thamani ya mfumo huu si usimbaji fiche. Ni kwamba swali “agent hii ilitumia nini, na lini” linakuwa query ya log. Unasoma njia moja ya ukaguzi badala ya kukisia ni mazingira gani kati ya sita yaliyokuwa na nakala ya key.

Mkabidhi mchakato siri, si mazingira

Ukiendesha wakala chini ya systemd, huhitaji kabisa vigezo vya mazingira. LoadCredential= huweka siri katika saraka ya faragha ambayo huduma hiyo pekee inaweza kusoma, ikiwa imeonyeshwa kama %d katika faili ya unit na kama $CREDENTIALS_DIRECTORY ndani ya mchakato. Thamani hiyo haionekani kamwe katika /proc/<pid>/environ, kwa hiyo ps eww haiwezi kuionyesha, na saraka hiyo hutoweka huduma inapositishwa.

Simbisha kitambulisho kwenye mashine kwanza. Amri hizi zinatoka kwenye nyaraka za systemd na hufanya kazi kwenye systemd 250 au mpya zaidi, inayojumuisha Ubuntu 24.04 na Debian 13:

echo -n 'sk-example-value' > /tmp/plain.txt
sudo systemd-creds encrypt --name=api_key /tmp/plain.txt /etc/credstore/api_key.cred
shred -u /tmp/plain.txt
sudo systemd-run -P --wait -p LoadCredentialEncrypted=api_key:/etc/credstore/api_key.cred \
  systemd-creds cat api_key

Amri ya mwisho huchapisha sk-example-value. Hilo linathibitisha kuwa faili iliyosimbwa inaweza kusimbuliwa kwenye mwenyeji huu. Kisha irejelee kutoka kwenye unit:

[Service]
User=agent-review
LoadCredentialEncrypted=api_key:/etc/credstore/api_key.cred
Environment=AGENT_KEY_FILE=%d/api_key
ExecStart=/usr/local/bin/agent-worker

Msimbo wa wakala wako hufungua faili kwenye $AGENT_KEY_FILE unapohitaji thamani hiyo. Usomaji wa faili ni wa muda mfupi. Kigezo cha mazingira hudumu kwa maisha yote ya mchakato, katika kila mchakato tanzu unaouanzisha.

Pendelea tokeni zenye muda mfupi wa uhalali badala ya funguo zenye muda mrefu

Ufunguo ambao hauishi muda wake bado ni halali kila unapoonekana, hata miezi baadaye, kwenye logi au nakala ya mawasiliano. Huduma inapotoa tokeni ya kipindi, tumia tokeni hiyo na uweke muda mfupi zaidi unaoruhusiwa na kazi.

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/agent-readonly \
  --role-session-name agent-review \
  --duration-seconds 900

Dakika 15 ndiyo muda wa chini unaokubaliwa na AWS STS (security token service), na kwa kawaida unatosha kwa kazi moja ya wakala. Kwa GitHub, mpe mtumiaji wa wakala gh yake mwenyewe yenye tokeni yenye ruhusa zilizobainishwa kwa undani, inayolenga hazina moja tu anayofanyia kazi, ili gh auth token ndani ya kipindi hicho irudishe kitu kisichoweza kufikia kitu kingine. Weka mipaka kwa rasilimali kwanza, kisha kwa muda.

Thibitisha, kisha endelea kuthibitisha

Baada ya mabadiliko yoyote kwenye usanidi wa agent, inafaa kufanya ukaguzi tatu. Iendeshe ukiwa mtumiaji wa agent, si mtumiaji wako.

sudo -u agent-review env | grep -iE 'key|token|secret'
sudo -u agent-review ls -la /home/you/ 2>&1 | head -3
sudo -u agent-review curl -s -o /dev/null -w '%{http_code}\n' --max-time 5 https://api.github.com/user

Ukaguzi wa kwanza haupaswi kuchapisha chochote. Wa pili unapaswa kuchapisha ls: cannot open directory '/home/you/': Permission denied. Wa tatu unaonyesha utambulisho unaowasilishwa na njia ya mtandao ya agent. Hilo ndilo swali ambalo muundo wa gateway unalenga kujibu: 401 inamaanisha agent haina credential yake ya GitHub, na 200 inamaanisha ina credential moja. Kwa hiyo, unapaswa kujua tokeni hiyo ni ipi. Ukiendesha agents bila uangalizi, kudhibiti gharama za AI agent kwenye VPS inaeleza vikomo vya bajeti vinavyolingana na vikomo hivi vya ufikiaji.

FAQ

Je, ninaweza kuamini tu modeli isivujishe funguo zangu?

Hapana, kwa sababu katika modeli hii ya tishio, modeli si mshambulizi. Wakala husoma maandishi kutoka kwenye kurasa za wavuti, hazina za msimbo, na vifuatiliaji vya masuala. Maandishi hayo yanaweza kuwa na maagizo. Modeli haina njia ya kuaminika ya kutofautisha maagizo yako na maandishi iliyoyapata. Udhibiti wowote unaotegemea modeli kufanya uchaguzi sahihi hushindwa mara ya kwanza maagizo yaliyodungwa yanapokuwa yenye kushawishi. Kwa hiyo, udhibiti lazima uwe katika mfumo wa uendeshaji au mtandao.

Je, vigeu vya mazingira ni hatari sana kwa siri za mawakala?

Ni hatari kwa njia moja mahususi: vinarithiwa. Kila mchakato mtoto ambao wakala huanzisha hupata nakala yake, ikiwemo script ya ujenzi, kiendeshaji cha majaribio, na hook yoyote ya usakinishaji wa kifurushi. Vigeu hivyo pia vinaweza kusomwa kupitia /proc/<pid>/environ na mtumiaji huyo huyo. Kwa hiyo, chochote ambacho wakala huendesha vinaweza kuvisoma bila wakala kuviwasilisha. Faili inayosomwa wakati wa matumizi, kupitia LoadCredential= au gateway, hupunguza mfichuo hadi wakati huo pekee.

Je, kuweka siri kwenye vault hutatua tatizo hili pekee yake?

Kwa kiasi fulani tu. Vault hutatua uhifadhi. Haitatui hatua ya mwisho, ambapo kitu fulani huchota siri kutoka kwenye vault na kumpa wakala kama kigeu cha mazingira. Hilo hukurudisha kwenye hali ya awali. Kinachojalisha ni nani anayefanya uingizwaji. Wakala akichukua siri, basi wakala anakuwa na siri hiyo. Gateway au mfumo wa init ukifanya uingizwaji nje ya mchakato wa wakala, wakala haishikilii siri hiyo kamwe.

Nitajuaje ikiwa wakala tayari amevujisha kitu?

Kwa kawaida huwezi kujua baada ya tukio. Hilo ndilo jambo linalounga mkono matumizi ya gateway. Bila gateway, ushahidi wako hutawanyika katika historia ya shell, rekodi ya mazungumzo ya wakala, na kumbukumbu za miunganisho ya kutoka ambazo huenda huzihifadhi. Ukiwa na gateway ya vitambulisho, kila matumizi ya kitambulisho huwa mstari mmoja wenye utambulisho wa wakala na muhuri wa muda. Ukishuku kuvuja, badilisha key kwanza kisha uchunguze. Kubadilisha key ni nafuu, lakini kupata uhakika si rahisi.

Ni jambo gani la chini kabisa ninalopaswa kufanya leo?

Hamisha kila faili ya .env kutoka kwenye saraka ambazo mawakala wako hutumia, kisha unda mtumiaji mmoja asiye na mapendeleo kwa kila wakala. Mabadiliko hayo mawili huchukua takribani dakika 10 na hufunga njia inayotumika mara nyingi zaidi: wakala kusoma faili ya kitambulisho ambayo haikuwa na sababu ya kuwekwa karibu na msimbo. Gateway na tokeni za muda mfupi ni hatua inayofuata, si hatua ya kwanza. Mwanzo huo huo unatumika kwa runtime yoyote ya wakala, ikiwemo kuendesha wakala wa kujitegemea kwa usalama kwenye VPS.