AI agents-ல் API keys பாதுகாப்பாக பயன்படுத்துவது எப்படி?

AI agents-ல் ரகசியங்களை ஏன் வைத்திருக்கக்கூடாது என்பதன் பொருள்

AI agent என்பது கட்டளைகளை இயக்கும் ஒரு சாதாரண Linux process ஆகும். அந்த process-ல் உள்ள ஒவ்வொரு environment variable-ஐயும் அது இயக்கும் code-ஆல் வாசிக்க முடியும். எனவே, ஒரு agent-ன் environment-ல் உள்ள API key-ஐ, அந்த agent தான் தொடர்பு கொள்ளக்கூடிய எந்தவொரு host-க்கும் அனுப்பிவிட முடியும். ரகசியங்களை agent-ல் வைத்திருக்கக்கூடாது என்பதன் பொருள், அதற்கு நேரடியாக key-ஐ வழங்குவதற்குப் பதிலாக ஒரு handle-ஐ வழங்குவதாகும்: அதாவது, குறுகிய காலத்திற்கு மட்டும் செல்லுபடியாகும் scoped token அல்லது network எல்லையில் உண்மையான மதிப்பால் மாற்றப்படும் ஒரு placeholder-ஐப் பயன்படுத்த வேண்டும்.

இது ஒரு model தீயதாக மாறுவது பற்றிய கதை அல்ல. இதன் செயல்முறை மிகவும் எளிமையானது. ஒரு agent இணையப்பக்கம், README, அல்லது issue comment ஆகியவற்றில் உள்ள அறிவுறுத்தல்களை வாசித்து, அதன்படி செயல்படுகிறது. ஏனெனில், ஒரு language model-க்கு நீங்கள் எழுதிய உரைக்கும், அது இணையத்திலிருந்து பெற்ற உரைக்கும் எந்த வித்தியாசமும் தெரியாது. இதுவே prompt injection ஆகும். இது நிகழ்ந்தவுடன், ஏற்படும் பாதிப்பு ஒரே ஒரு விஷயத்தால் மட்டுமே கட்டுப்படுத்தப்படுகிறது: அந்த process எதை வாசிக்க முடியும் என்பதுதான். நீங்கள் இன்னும் ஒரு எல்லையை (boundary) உருவாக்கவில்லை என்றால், server-ல் coding agent-ஐ பாதுகாப்பாக இயக்குவது என்ற பகுதி, இந்த வழிகாட்டிக்கு அடிப்படையாக உள்ள isolation முறைகளை விளக்குகிறது.

அச்சுறுத்தல் மாதிரியின் எளிய விளக்கம்

உங்கள் agent எந்த பயனர் கணக்கில் இயங்குகிறதோ, அதே கணக்கில் இதை இயக்கவும்.

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

இது அச்சிடும் ஒவ்வொரு வரியும், அந்நியர் ஒருவரின் server-க்கு அனுப்பப்படும் ஒரு HTTP கோரிக்கைக்குச் சமம். இப்போது, agent-க்கு அருகில் வட்டில் (disk) என்னென்ன கோப்புகள் உள்ளன என்று கவனியுங்கள்.

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

Shell அணுகல் கொண்ட ஒரு agent-க்கு, தரவுகளை வெளியேற்ற எந்தவொரு சிக்கலான exploit-ம் தேவையில்லை. சாதாரணமான நான்கு வழிகள் இதற்குப் போதுமானவை; இவை அனைத்தும் log-ல் சாதாரண வேலைகளைப் போலவே தோன்றும்:

• ஏதேனும் ஒரு host-க்கு அனுப்பப்படும் curl அல்லது fetch கோரிக்கை; இதில் தரவு query string-ல் இருக்கும்.
• agent-ஆல் எழுதக்கூடிய repository-க்கு செய்யப்படும் git commit மற்றும் git push.
• ஒரு package install script; இது agent-ன் பயனர் உரிமையுடன் தன்னிச்சையான குறியீடுகளை (arbitrary code) இயக்கும்.
• தரவை உள்ளடக்கிய hostname-க்கான DNS lookup; HTTP egress தடுக்கப்பட்டிருந்தாலும் இது செயல்படும்.

இவற்றை ஆய்வு செய்வதன் மூலம் மட்டும் நீங்கள் தப்பிக்க முடியாது. முக்கியமான தரவுகள் எதுவும் agent-ன் அணுகலுக்குள் இல்லை என்பதை உறுதிப்படுத்துவதே இதற்கான தீர்வாகும்.

Working tree-ல் உள்ள ஒரு secret, context window-விலும் ஒரு secret ஆகும்

ஒரு agent கோப்புகளை வாசிக்கும். அது பணிபுரியும் repository-ல் உள்ள ஒரு .env கோப்பு வாசிக்கப்படும். ஒருமுறை வாசிக்கப்பட்டால், அது context window-விற்குள் சென்றுவிடும். அதாவது, அது transcript-ல் இருக்கும், நீங்கள் வைத்திருக்கும் எந்த log-லும் இருக்கும், மேலும் அந்த agent அடுத்து என்ன எழுதுகிறதோ அதிலும் இருக்கும்.

முன்பு, agent பணிபுரியும் tree-லேயே key இருந்தபோது:

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

பிறகு, கோப்பு எட்டாத தூரத்திற்கு நகர்த்தப்பட்ட பிறகு:

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

Working tree-ல் அந்த கோப்பு இல்லாததால், agent-ன் பயனரால் அதைத் திறக்க முடியாது. Agent-ன் சொந்த config-ல் உள்ள deny விதிகள் இரண்டாவது அடுக்கு மட்டுமே, முதல் அடுக்கு அல்ல. Claude Code திட்டத்தில் உள்ள .claude/settings.json-லிருந்து அனுமதி விதிகளை வாசிக்கிறது:

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

இது agent கோப்புகளை ஆராயும்போது தவறுதலாகத் திறப்பதைத் தடுக்கிறது. இது file tools-ஐத் தாண்டிச் செயல்படுகிறது: Claude Code இந்த விதிகளை Bash-ல் அது அடையாளம் காணும் cat மற்றும் head போன்ற கட்டளைகளுக்கும், < .env போன்ற redirection இலக்குகளுக்கும் எதிராகச் சரிபார்க்கிறது. இது திட்டக் கோப்பகத்திற்குள் grep -r KEY .-ஐ இயக்குவதையோ அல்லது .env-ஐத் தாமாகவே திறக்கும் ஒரு சிறிய Python script-ஐயோ தடுக்காது. ஏனெனில், பெயரிடப்படாமல் கோப்புகளை வாசிக்கும் கட்டளைகளுக்கோ அல்லது தாமாகவே கோப்புகளைத் திறக்கும் subprocess-களுக்கோ deny விதிகள் பொருந்தாது என்று அனுமதிகள் குறித்த ஆவணங்கள் கூறுகின்றன. அவற்றுக்கு, ஆவணங்கள் Claude Code-ன் sandbox-ஐப் பரிந்துரைக்கின்றன, இது operating system மட்டத்தில் அந்தத் தடையை அமல்படுத்துகிறது. அத்தகைய கட்டளை இயங்குவதற்கு முன்பு உங்களிடம் அனுமதி கேட்கப்படுமா என்பது அந்த session-ன் permission mode-ஐப் பொறுத்தது. interactive Claude Code session-களுக்கு auto mode இப்போது இயல்பான தொடக்க நிலையாக உள்ளது, எனவே நீங்கள் கவனிக்காத ஒரு server-ல் இத்தகைய கட்டளைகள் பலவும் கேட்கப்படாமலேயே இயங்கும். Agent-ன் அனுமதிகளை விட அதன் பழக்கவழக்கங்களை வடிவமைக்கும் எதற்கும் இதே வரம்பு பொருந்தும்: மிகச்சிறிய மாற்றத்தையே செய்ய வேண்டும் என்று agent-ஐக் கட்டுப்படுத்தும் திறன், அது தேவையற்ற கோப்புகளைத் திறப்பதைத் தடுக்கிறது. ஆனால், இது model-ஐ வற்புறுத்தி மாற்றக்கூடிய ஒரு அறிவுரை மட்டுமே. Config-ஐ ஒரு guardrail-ஆகவும், filesystem அனுமதியை ஒரு சுவராகவும் கருதுங்கள். இதே பிரிவினை container-களுக்குள்ளும் பொருந்தும்: Docker Compose-ல் உள்ள env கோப்புகள் மற்றும் secrets இந்தச் சிக்கலின் ஒரு அடுக்கு கீழே உள்ள பதிப்பை விளக்குகிறது.

ஒவ்வொரு agent-க்கும் தனித்தனி unprivileged user-ஐ ஒதுக்குங்கள்

Agent உங்கள் பயனர் கணக்கில் இயங்கினால், அது உங்கள் SSH keys, cloud credentials மற்றும் shell history ஆகியவற்றை அப்படியே பெற்றுக்கொள்ளும். ஒரு தனி பயனர் கணக்கை உருவாக்குவதற்கு ஒரு கட்டளை மட்டுமே தேவை, அது இந்த அபாயங்கள் அனைத்தையும் நீக்கிவிடும்.

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

கடைசி வரியானது cat: /home/you/.ssh/id_ed25519: Permission denied பிழையுடன் தோல்வியடைய வேண்டும். அது ஒரு key-ஐ வெளியிட்டால், அந்த agent பயனர் கோப்பை அணுக முடிகிறது என்று அர்த்தம். ஒரு கோப்பை அதன் பெயரைக் கொண்டு திறக்க, அந்த கோப்பிற்கு மேலே உள்ள ஒவ்வொரு directory-யிலும் search (x) அனுமதி தேவை, read அனுமதி தேவையில்லை. எனவே, 711 mode-ல் உள்ள ஒரு home directory-யை மற்றவர்கள் பட்டியலிட முடியாவிட்டாலும், கோப்பு படிக்கக்கூடியதாக இருந்தால் key கசிந்துவிடும். chmod 700 ~ அந்தப் பாதையை மூடுகிறது, chmod 600 ~/.ssh/id_ed25519 அந்த key-ஐச் சரிசெய்கிறது. Agent பயனரை sudo குழுவில் சேர்க்காதீர்கள், மேலும் அதற்குத் தேவையான ஒரு கட்டளையைத் தாண்டி அதற்கு NOPASSWD விதியை வழங்காதீர்கள். VPS-ல் குறைந்தபட்ச அதிகாரமுள்ள பயனர்கள் பகுதியில் group மற்றும் sudoers குறித்த விவரங்கள் உள்ளன. அந்தப் பிரிவினையை நினைவில் கொள்ளுங்கள், ஏனெனில் நீங்கள் ஒரே கணினியில் ஒன்றுக்கு மேற்பட்ட session-களை இயக்கும்போது, ஒரு Claude Code session மற்றொரு session-க்கு நேரடியாக உரையை அனுப்ப முடியும், மேலும் முதல் session-ல் உள்ள எதையும் ஒரே செய்தியில் அந்தப் பாதை வழியாகக் கடத்த முடியும்.

Cloud VPS-ல் கூடுதலாக ஒரு பாதுகாப்பு எல்லையைச் சேர்ப்பது அவசியம். Instance metadata service ஒரு நிலையான link local முகவரியில் பதிலளிக்கிறது, மேலும் அது கேட்கும் எதற்கும் பெரும்பாலும் role credentials-ஐ வழங்குகிறது. எந்த உள்ளூர் பயனர் அழைக்கிறார் என்பதை அந்த endpoint சரிபார்ப்பதில்லை: EC2-ல், IMDSv1 அழைப்புகளுக்கு token தேவையில்லை என்று AWS ஆவணப்படுத்துகிறது. ஒரு பயனர் இந்தச் சேவையை அணுகுவதைத் தடுப்பதற்கான அதன் சொந்த ஆலோசனை, அந்தப் பயனரின் ID-ஐ அடிப்படையாகக் கொண்ட உள்ளூர் firewall விதியாகும்.

sudo iptables -I OUTPUT 1 -p tcp -m owner --uid-owner agent-review -d 169.254.169.254 -j REJECT

-A மூலம் விதியைச் சேர்ப்பதற்குப் பதிலாக, -I மூலம் அதை முதலிடத்தில் செருகவும். இயல்பாக outgoing இணைப்புகளை அனுமதிக்கும் ufw கொள்கையைக் கொண்ட host-ல், ufw-ன் கடைசி OUTPUT chain ஒவ்வொரு புதிய TCP இணைப்பையும் ஏற்றுக்கொள்கிறது, எனவே இறுதியில் சேர்க்கப்படும் விதி ஒருபோதும் செயல்படாது. நீங்கள் iptables விதிகளைச் சேமிக்காவிட்டால், reboot செய்யும்போது அவை மறைந்துவிடும். நீங்கள் metadata service-ன் IPv6 endpoint-ஐ, [fd00:ec2::254], இயக்கியிருந்தால், ip6tables மூலம் அதே விதியைச் சேர்க்கவும்.

Agent-ன் பக்கத்திலிருந்து இதைச் சரிபார்க்கவும். sudo -u agent-review curl -s --max-time 3 http://169.254.169.254/ எதையும் காட்டாமல் non-zero நிலையில் வெளியேற வேண்டும், ஏனெனில் அந்த packet கணினியை விட்டு வெளியேறும் முன்பே நிராகரிக்கப்படுகிறது. அது ஒரு பட்டியலைக் காட்டினால், அந்த விதி செயல்படவில்லை என்று அர்த்தம்.

எல்லையில் நற்சான்றிதழை (credential) செலுத்துதல்

இதற்கான உண்மையான தீர்வு நற்சான்றிதழ் செலுத்துதல் (credential injection) ஆகும். முகவர் (agent) ஒருபோதும் உண்மையான சாவியை (key) வைத்திருக்காது. அது தனது கோரிக்கையை ஒரு உள்ளூர் நுழைவாயில் (local gateway) வழியாக அனுப்புகிறது; அந்த நுழைவாயில் வெளியே செல்லும் வழியில் ஒரு தற்காலிக அடையாளத்திற்கு (placeholder) பதிலாக உண்மையான ரகசியத்தை (secret) மாற்றுகிறது. இந்த ரகசியம் நுழைவாயிலின் சேமிப்பகத்தில், வேறொரு பயனர் உரிமையுள்ள வேறொரு செயல்முறையில் (process) இருக்கும்.

OneCLI என்பது இதன் ஒரு திறந்த மூல (open source) செயலாக்கம் ஆகும். இது அதன் ee/ கோப்பகங்களைத் தவிர்த்து Apache-2.0 உரிமம் பெற்றது; அந்த கோப்பகங்கள் தனி நிறுவன உரிமத்தைக் கொண்டுள்ளன, இதற்கு உற்பத்தி பயன்பாட்டிற்கு சந்தா தேவைப்படுகிறது. இது முகவருக்கு அருகிலுள்ள கொள்கலன்களில் (containers) இயங்குகிறது. அக்டோபர் 2026 நிலவரப்படி, இந்தத் திட்டம் Docker Compose அமைப்பை ஆவணப்படுத்துகிறது, இது compose கோப்பிற்கு அருகிலுள்ள .env கோப்பிலிருந்து உருவாக்கப்பட்ட மூன்று ரகசியங்களைப் படிக்கிறது:

git clone https://github.com/onecli/onecli.git && cd onecli/docker
cat > .env <<EOF
SECRET_ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)
GATEWAY_INTERNAL_SECRET=$(head -c 32 /dev/urandom | base64)
BETTER_AUTH_SECRET=$(head -c 32 /dev/urandom | base64)
COMPOSE_PROFILES=runner
EOF
chmod 600 .env
docker compose up -d --wait

அந்த .env கோப்பை காப்புப்பிரதி (backup) எடுக்கவும், ஏனெனில் SECRET_ENCRYPTION_KEY-ஐ இழந்தால் அதனுடன் சேமிக்கப்பட்ட அனைத்து ரகசியங்களும் பயனற்றதாகிவிடும். டாஷ்போர்டு 10254 போர்ட்டிலும், நுழைவாயில் 10255 போர்ட்டிலும் கேட்கிறது (listen), இவை முன்னிருப்பாக 127.0.0.1-உடன் பிணைக்கப்பட்டுள்ளன. நீங்கள் உண்மையான நற்சான்றிதழை ஒருமுறை சேமித்துவிட்டு, ஒவ்வொரு முகவருக்கும் சாவிக்கு பதிலாக ஒரு தற்காலிக அடையாள மதிப்பையும், அதன் சொந்த அணுகல் டோக்கனையும் (access token) வழங்குகிறீர்கள்; அதை அது Proxy-Authorization தலைப்பில் (header) அனுப்புகிறது. நுழைவாயில் வெளியே செல்லும் கோரிக்கையை host மற்றும் path மூலம் பொருத்தி, தொடர்புடைய ரகசியத்தை மறைகுறியாக்கம் (decrypt) செய்து, அதை மாற்றுகிறது. முகவரின் சூழலில் திருடுவதற்கு மதிப்புள்ள எதுவும் இருக்காது.

இங்குள்ள மதிப்பு மறைகுறியாக்கத்தில் இல்லை. "இந்த முகவர் எதைப் பயன்படுத்தியது, எப்போது பயன்படுத்தியது" என்ற கேள்வி ஒரு பதிவு வினவலாக (log query) மாறுவதில்தான் உள்ளது. ஆறு சூழல்களில் எதில் சாவியின் நகல் இருந்தது என்று யூகிப்பதற்குப் பதிலாக, நீங்கள் ஒரே ஒரு தணிக்கை தடத்தை (audit trail) படிக்கிறீர்கள்.

ரகசியத்தை environment-க்கு வழங்காமல், process-க்கு நேரடியாக வழங்கவும்

நீங்கள் systemd-ன் கீழ் agent-ஐ இயக்கினால், environment variables எவையும் உங்களுக்குத் தேவையில்லை. LoadCredential= ரகசியத்தை ஒரு தனிப்பட்ட கோப்பகத்தில் (private directory) வைக்கிறது; இதை அந்த service-ன் user மட்டுமே படிக்க முடியும். இது unit file-ல் %d ஆகவும், process-க்குள் $CREDENTIALS_DIRECTORY ஆகவும் வெளிப்படுத்தப்படுகிறது. இந்த கட்டுப்பாடு service-ஐ அடிப்படையாகக் கொண்டதல்ல, user-ஐ அடிப்படையாகக் கொண்டது. எனவே, ஒவ்வொரு agent service-க்கும் தனித்தனி user-ஐ உருவாக்கவும். ஒரே user-ன் கீழ் இயங்கும் பிற process-கள் அந்தக் கோப்பகத்தைத் திறக்க முடியும்; unit file-ல் PrivateMounts=yes போன்ற filesystem namespacing பயன்படுத்தினால் மட்டுமே மற்ற service-களிடமிருந்து இதை மறைக்க முடியும். இதன் மதிப்பு ஒருபோதும் /proc/<pid>/environ-ல் தோன்றாது, எனவே ps eww-ஆல் இதைக் காட்ட முடியாது. service நிறுத்தப்படும்போது அந்தக் கோப்பகம் மறைந்துவிடும்.

முதலில் credential-ஐ அந்த machine-க்கு ஏற்றவாறு encrypt செய்யவும். இந்தக் கட்டளைகள் systemd ஆவணங்களிலிருந்து பெறப்பட்டவை. இவை systemd 250 அல்லது அதற்குப் பிந்தைய பதிப்புகளில் (Ubuntu 24.04 மற்றும் 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

கடைசி கட்டளை sk-example-value-ஐ அச்சிடும். இந்த host-ல் encrypted கோப்பு சரியாக decrypt ஆகிறது என்பதை இது உறுதிப்படுத்துகிறது. பின்னர், unit file-ல் இதைக் குறிப்பிடவும்:

[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

உங்கள் agent code-க்கு மதிப்பு தேவைப்படும்போது, அது $AGENT_KEY_FILE-ல் உள்ள கோப்பைத் திறக்கும். கோப்பை வாசிப்பது என்பது ஒரு கணநேரச் செயல். ஆனால், environment variable என்பது process இயங்கும் காலம் முழுவதும் நீடிக்கும், அது உருவாக்கும் ஒவ்வொரு child process-க்கும் அது பரவும்.

நீண்ட கால பயன்பாட்டு விசைகளை விட குறுகிய கால டோக்கன்களை முன்னுரிமைப்படுத்துங்கள்

காலாவதி தேதி இல்லாத ஒரு விசை, பல மாதங்களுக்குப் பிறகு log அல்லது transcript-ல் வெளிப்பட்டாலும், அது இன்னும் செல்லுபடியாகும். ஒரு சேவை session token-ஐ வழங்கினால், அதைப் பயன்படுத்தி, உங்கள் பணிக்குத் தேவையான மிகக் குறைந்த கால அளவை (lifetime) அமைக்கவும்.

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

AWS STS (security token service) ஏற்கும் குறைந்தபட்ச கால அளவு 15 நிமிடங்கள் ஆகும்; இது ஒரு agent பணிக்கு பொதுவாக போதுமானது. GitHub-ஐப் பொறுத்தவரை, அந்த agent பயனருக்குத் தனிப்பட்ட gh login-ஐ வழங்கவும். அது பணிபுரியும் ஒரு குறிப்பிட்ட repository-க்கு மட்டும் கட்டுப்படுத்தப்பட்ட fine grained token-ஐப் பயன்படுத்தவும். இதன் மூலம், அந்த session-க்குள் இருக்கும் gh auth token, மற்ற எதையும் அணுக முடியாதவாறு இருக்கும். முதலில் resource அடிப்படையிலும், பிறகு கால அடிப்படையிலும் கட்டுப்பாடுகளை (scope) விதிக்கவும்.

சரிபார்த்தல், மீண்டும் சரிபார்த்தல்

ஏஜென்ட் அமைப்பில் ஏதேனும் மாற்றம் செய்த பிறகு, மூன்று சோதனைகளைச் செய்வது அவசியம். இவற்றை நீங்களாகச் செய்யாமல், ஏஜென்ட்டின் பயனர் கணக்கின் (agent's user) மூலம் இயக்கவும்.

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

முதல் சோதனை எதையும் அச்சிடக்கூடாது. இரண்டாவது சோதனை ls: cannot open directory '/home/you/': Permission denied என்று அச்சிட வேண்டும்; இது அந்த கோப்பகத்தை (directory) பட்டியலிட முடியாது என்பதை மட்டுமே காட்டுகிறது. முன்னதாகச் செய்த cat சோதனைதான், அதற்குள் இருக்கும் கோப்பை வாசிக்க முடியாது என்பதை உறுதிப்படுத்துகிறது. மூன்றாவது சோதனை, ஏஜென்ட்டின் நெட்வொர்க் பாதை எந்த அடையாளத்தை வழங்குகிறது என்பதைத் தெரிவிக்கும்; கேட்வே பேட்டர்ன் (gateway pattern) எதற்காக உருவாக்கப்பட்டது என்பதற்கான விடை இதுவே. 401 என்பது, GitHub ஏற்கும் அங்கீகாரம் (credential) எதுவுமின்றி கோரிக்கை சென்றடைந்ததைக் குறிக்கிறது; அதாவது, அங்கீகாரம் இல்லை அல்லது அது காலாவதியாகிவிட்டது. 200 என்பது, செல்லுபடியாகும் அங்கீகாரம் பயன்படுத்தப்படுவதைக் குறிக்கிறது; எனவே, எந்த டோக்கன் (token) பயன்படுத்தப்படுகிறது என்பதை நீங்கள் அறிந்திருக்க வேண்டும். நீங்கள் ஏஜென்ட்டுகளைத் தானியங்கி முறையில் (unattended) இயக்கினால், VPS-ல் AI ஏஜென்ட் செலவுகளைக் கட்டுப்படுத்துதல் என்ற பகுதியில், இந்த அணுகல் கட்டுப்பாடுகளுடன் இணைந்த பட்ஜெட் வரம்புகள் குறித்து விளக்கப்பட்டுள்ளது.

FAQ

எனது ரகசியக் குறியீடுகளை (keys) கசியவிடாது என்று இந்த மாடலை நான் நம்பலாமா?

முடியாது. ஏனெனில், இந்த அச்சுறுத்தல் மாதிரியில் (threat model) மாடல் ஒரு தாக்குதல் நடத்துபவர் அல்ல. இந்த ஏஜென்ட் இணையப் பக்கங்கள், repositories மற்றும் issue trackers ஆகியவற்றிலிருந்து உரையை வாசிக்கும்; அந்த உரையில் கட்டளைகள் இருக்கலாம். தான் பெற்றுக்கொண்ட உரையில் எது உங்கள் கட்டளை, எது மற்றவை என்பதைப் பிரித்தறியும் நம்பகமான வழி மாடலுக்கு இல்லை. ஊடுருவப்பட்ட கட்டளை (injected instruction) நம்பும்படியாக இருக்கும்போது, மாடலின் முடிவைச் சார்ந்திருக்கும் எந்தவொரு கட்டுப்பாடும் தோல்வியடையும். எனவே, அத்தகைய கட்டுப்பாடுகள் operating system அல்லது network மட்டத்திலேயே இருக்க வேண்டும்.

ஏஜென்ட் ரகசியங்களுக்கு environment variables பயன்படுத்துவது உண்மையிலேயே மோசமானதா?

அவை ஒரு குறிப்பிட்ட வகையில் மோசமானவை: அவை மரபுரிமையாக (inherited) கிடைக்கின்றன. ஏஜென்ட் உருவாக்கும் ஒவ்வொரு child process-க்கும், build script, test runner மற்றும் package install hook உட்பட, அந்த variables-ன் நகல் கிடைத்துவிடும். அதே பயனரால் /proc/<pid>/environ மூலமாகவும் அந்த variables-ஐ வாசிக்க முடியும். எனவே, ஏஜென்ட் எதையும் பகிராமலேயே, அது இயக்கும் எந்தவொரு நிரலும் அவற்றை வாசிக்க முடியும். பயன்படும் தருணத்தில் மட்டும் LoadCredential= அல்லது ஒரு gateway மூலம் வாசிக்கப்படும் கோப்பு, அந்தத் தருணத்தில் மட்டுமே வெளிப்பாட்டை (exposure) கட்டுப்படுத்துகிறது.

ரகசியங்களை ஒரு vault-ல் வைப்பது மட்டும் இதற்குத் தீர்வாகுமா?

பகுதியளவு மட்டுமே. ஒரு vault சேமிப்பகத்தைச் சரிசெய்கிறது. நீங்கள் அந்த vault-ஐ நீங்களே host செய்தால், அதற்குத் தனிப்பட்ட பாதுகாப்பு நடவடிக்கைகள் தேவை. ஏனெனில், ஒரு Vaultwarden server பொதுவாக அதன் admin token அல்லது backup file மூலமே உடைக்கப்படுகிறது, அதில் உள்ள encrypted பொருட்கள் மூலம் அல்ல. இது இறுதிப் படியைச் சரிசெய்யாது; அதாவது, vault-லிருந்து ரகசியத்தை எடுத்து ஏஜென்டிடம் environment variable-ஆகக் கொடுக்கும்போது, நீங்கள் மீண்டும் பழைய நிலைக்கு வந்துவிடுவீர்கள். ரகசியத்தை யார் மாற்றீடு (substitution) செய்கிறார்கள் என்பதே முக்கியம். ஏஜென்ட் ரகசியத்தைப் பெற்றால், ஏஜென்டிடம் ரகசியம் இருக்கும். ஒரு gateway அல்லது init system ஏஜென்ட்டின் process-க்கு வெளியே மாற்றீடு செய்தால், ஏஜென்ட் ஒருபோதும் ரகசியத்தைக் கொண்டிருக்காது.

ஒரு ஏஜென்ட் ஏற்கனவே எதையாவது கசியவிட்டுவிட்டதா என்பதை நான் எப்படி அறிவது?

பொதுவாக, நடந்த பிறகு இதைக் கண்டறிய முடியாது; இதனால்தான் gateway பயன்படுத்தப் பரிந்துரைக்கப்படுகிறது. அது இல்லையென்றால், உங்கள் ஆதாரங்கள் shell history, ஏஜென்ட்டின் transcript மற்றும் நீங்கள் பெரும்பாலும் பராமரிக்காத outbound connection logs ஆகியவற்றில் சிதறிக்கிடக்கும். ஒரு credential gateway இருந்தால், ஒவ்வொரு முறை credential பயன்படுத்தப்படும்போதும், ஏஜென்ட்டின் அடையாளம் மற்றும் நேர முத்திரையுடன் (timestamp) ஒரு வரி பதிவாகும். கசிவு இருப்பதாகச் சந்தேகித்தால், முதலில் key-ஐ மாற்றிவிட்டு (rotate), பிறகு விசாரணையைத் தொடங்குங்கள். key-ஐ மாற்றுவது எளிது, ஆனால் உறுதித்தன்மை கிடைப்பது கடினம்.

இன்று நான் செய்ய வேண்டிய குறைந்தபட்ச நடவடிக்கை என்ன?

ஒவ்வொரு .env கோப்பையும் உங்கள் ஏஜென்ட்கள் வேலை செய்யும் directories-லிருந்து வெளியேற்றுங்கள். ஒவ்வொரு ஏஜென்ட்டுக்கும் ஒரு unprivileged user-ஐ உருவாக்குங்கள். இந்த இரண்டு மாற்றங்களும் சுமார் பத்து நிமிடங்களில் முடிந்துவிடும். இவை மிகவும் பொதுவான பாதையை அடைத்துவிடும்; அதாவது, குறியீட்டிற்கு (code) அருகில் இருக்க வேண்டிய அவசியமே இல்லாத ஒரு credential கோப்பை ஏஜென்ட் வாசிப்பதைத் தடுக்கும். Gateway மற்றும் குறுகிய கால tokens (short lived tokens) அடுத்தகட்ட நடவடிக்கைகள், முதல் கட்டம் அல்ல. இதே தொடக்கப் புள்ளி எந்தவொரு ஏஜென்ட் runtime-க்கும் பொருந்தும், ஒரு VPS-ல் தன்னாட்சி ஏஜென்ட்டைப் பாதுகாப்பாக இயக்குவது உட்பட.