Agent के अधिकार सीमित करें
पूरा हुआस्वीकार्य कार्रवाइयाँ, resources और शर्तें तय करें। मॉडल के बाहर permissions जाँचें और implementation को release से अलग रखें।
प्रकाशक Taigaहम कैसे लिखते हैं
अपनी समझ जाँचेंआप agent को एक branch edit करने को कहते हैं, लेकिन उसका token default branch पर push कर सकता है। वास्तविक सीमा क्या है?अभ्यास करें
आप क्या सीखेंगे
- Permission को कार्रवाई, resource और शर्त के रूप में लिखें।
- काम की स्वीकृति और उसे execute करने के अधिकार को अलग करें।
- जाँचें कि प्रतिबंधित कार्रवाई अस्वीकार होती है।
Access देने से पहले काम बताएँ
Code पढ़ने वाले agent और service deploy करने वाले agent को अलग अधिकार चाहिए। केवल इसलिए दोनों तरह की permissions न दें कि वही product दोनों काम कर सकता है।
अधिकार तीन हिस्सों में तय करें: कार्रवाई, resource और शर्त। काल्पनिक report fix में agent काम जारी रहने तक एक feature branch में लिख सकता है। वह repository की स्वीकृत files पढ़ सकता है। वह production data या repository protection rules नहीं बदल सकता।
| जरूरी operation | सीमा का उदाहरण |
|---|---|
| Code का निरीक्षण | चुनी हुई repository पढ़ना |
| Checks चलाना | काल्पनिक fixtures वाला अलग environment इस्तेमाल करना |
| बदलाव तैयार करना | काम की branch में लिखना |
| Review माँगना | PR खोलना, उसे merge नहीं करना |
| Software release करना | अलग, सुरक्षित deployment प्रक्रिया इस्तेमाल करना |
सीमा लागू करने का सटीक तरीका tool पर निर्भर है। Token में branch restriction व्यक्त न कर सकें, तो अतिरिक्त repository controls या execution service इस्तेमाल करें। बाकी उपलब्ध अधिकार ईमानदारी से दर्ज करें।
मॉडल के बाहर सीमा लागू करें
Prompt access-control system नहीं है। Execution component को माँगी गई कार्रवाई और target की वर्तमान permissions से जाँच करनी चाहिए। मॉडल का यह कथन स्वीकार नहीं करना चाहिए कि approval पहले से है।
AWS उपयुक्त workloads के लिए सीमित permissions और temporary credentials सुझाता है। OWASP agents और उनके tools पर इसी तरह least privilege का तर्क लागू करता है। इन सिद्धांतों को वास्तविक identity और execution systems में लागू करना जरूरी है। AWS IAM guidance, OWASP agent guidance।
जहाँ support हो, कम अवधि वाले credentials इस्तेमाल करें। असंबंधित secrets environment से बाहर रखें। Read-only repository task को developer के shell से production database password नहीं मिलना चाहिए।
Approval को वास्तविक कार्रवाई से जोड़ें
बदलाव तैयार करने का approval उसे deploy करने का approval नहीं है। Deployment निर्णय में artifact, target environment और संबंधित शर्तें स्पष्ट हों। ये बदलें, तो पिछला निर्णय लागू न भी रहे।
ऐसा agent लें जो सुरक्षित database read सुझाता है, फिर approval मिलने पर अलग query चलाता है। उपयोगी approval mechanism उस operation को जाँचता है जो वास्तव में चलता है। तय target के बिना सामान्य “जारी रखें” संदेश यह अंतर छिपा सकता है।
Identity और capability भी अलग रखें। दर्ज करें कि run किस व्यक्ति या workload ने शुरू किया। कार्रवाई के समय जाँचें कि शुरू करने वाली identity को अब भी अनुमति है। किसी व्यक्ति का access हटाने का queued work पर स्पष्ट असर होना चाहिए।
Denial और interruption जाँचें
केवल सफल path से अधिक जाँचें। अलग test environment में स्वीकार्य resource के बाहर कार्रवाई का प्रयास करें। पुष्टि करें कि execution system उसे अस्वीकार करता है। Credentials दर्ज किए बिना audit event का निरीक्षण करें।
फिर cancellation या credential expiry जाँचें। तय करें कि कौन-सा काम तुरंत रुकता है और कौन-सा operation पूरा हो सकता है। Stop button उस कार्रवाई को जरूरी नहीं पलटता जो दूसरे system तक पहुँच चुकी है।
काम के साथ permissions का छोटा record रखें। जिम्मेदार व्यक्ति, स्वीकृत दायरा, वास्तविक controls, denial test और समाप्ति शामिल करें। इससे बाद का review workflow सुधारने जितना स्पष्ट रहता है।
अभ्यास करें
Report filter ठीक करने वाले agent की permissions तय करें। तीन स्वीकार्य और तीन अस्वीकार्य कार्रवाइयाँ लिखें। Repository, branch, environment और समाप्ति की शर्त शामिल करें। Production बदले बिना हर denial जाँचने का तरीका बताएँ।
Worksheet डाउनलोड करें (Markdown)यह चयन हटाने से इस browser में सहेजी गई पूरी प्रगति मिट जाती है।
प्रगति इसी browser में रहती है। कोई account या tracking नहीं।