ब्राउज़र प्रोफ़ाइल ऑटोमेशन में न्यूनतम आवश्यक अधिकार

पहले अनुमति की सीमाएँ तय करें

NIST न्यूनतम आवश्यक अधिकार को उपयोगकर्ताओं और उनकी ओर से चलती प्रक्रियाओं को सौंपे काम के लिए ज़रूरी न्यूनतम पहुँच तक सीमित करना कहता है। इसलिए ब्राउज़र प्रोफ़ाइल काम में केवल automation जैसी भूमिका बहुत व्यापक है। वह कॉल करने वाले का प्रकार बताती है, लेकिन कौन-सी प्रोफ़ाइल खोल सकता है, किस वेबसाइट तक जा सकता है, क्या बदल सकता है या अनुमति कितनी देर रहेगी, नहीं बताती।

उपयोगी अनुमति सीमा के आठ आयाम हैं:

आयाम	सवाल	मज़बूत शुरुआती नियम
कर्ता	किस व्यक्ति, कार्यभार या एजेंट ने काम शुरू किया?	हर व्यक्ति या कार्यभार की पहचानी जा सकने वाली अलग पहचान
टेनेंट	किस संगठन या क्लाइंट की सीमा लागू है?	एक संगठन; दूसरे टेनेंट की पहुँच नहीं
प्रोफ़ाइल समूह	ठीक कौन-सी प्रोफ़ाइल इस्तेमाल हो सकती हैं?	स्पष्ट ID या समीक्षित फ़ोल्डर/टैग चयन
कार्रवाई	ऑटोमेशन क्या कर सकता है?	नामित कारोबारी कार्रवाइयाँ, खुली फ़ाइल या प्रक्रिया नियंत्रण नहीं
गंतव्य	किन साइट, API या वातावरण से जुड़ सकता है?	केवल स्वीकृत ओरिजिन और वातावरण
समय	अधिकार कब शुरू और समाप्त होता है?	कम अवधि के क्रेडेंशियल और सीमित कार्य अवधि
दर	कितना काम कर सकता है?	समवर्ती काम, अनुरोध और लागत की सीमाएँ
बाहरी असर	क्या बदल, प्रकाशित, मिटा या खर्च कर सकता है?	पहले केवल पढ़ना; अधिक असर के लिए स्वीकृति

हर कमांड पर नीति जाँची जानी चाहिए। सफल प्रोफ़ाइल लॉन्च से चुपचाप कुकी निर्यात, टीम प्रशासन, बिलिंग बदलाव या हर पहुँच योग्य साइट पर कार्रवाई का अधिकार नहीं मिलना चाहिए।

तीन प्रकार के अधिकार अलग रखें

ब्राउज़र ऑटोमेशन अक्सर तीन अलग क्रेडेंशियल एक वर्कफ़्लो में मिला देता है:

1. ऑटोमेशन क्रेडेंशियल प्रोफ़ाइल मैनेजर या ऑटोमेशन सेवा को कॉल अधिकृत करता है।
2. प्रोफ़ाइल की सत्र स्थिति वेबसाइट पर व्यक्ति या परीक्षण खाते को प्रमाणित कर सकती है।
3. लक्ष्य सेवा की प्रतिनिधि पहुँच तय करती है कि वह खाता वेबसाइट पर क्या कर सकता है।

ये एक-दूसरे के विकल्प नहीं हैं। ऑटोमेशन टोकन में प्रोफ़ाइल की कुकी न हो और न उससे कुकी प्रकट हो। प्रमाणित प्रोफ़ाइल यह सिद्ध नहीं करती कि कॉल करने वाला हर उपलब्ध वेबसाइट कार्रवाई के लिए अधिकृत है। वेबसाइट पासवर्ड या OAuth टोकन को प्रोफ़ाइल मैनेजर के क्रेडेंशियल की तरह दोबारा इस्तेमाल न करें।

यह अंतर ज़रूरी है क्योंकि प्रमाणित ब्राउज़र स्थिति स्वयं संवेदनशील है। Playwright चेतावनी देता है कि सेव स्थिति में परीक्षण खाते का उपयोग करने देने वाली कुकी और हेडर हो सकते हैं। इसे रहस्य वाली सामग्री मानें और स्रोत नियंत्रण, सामान्य लॉग, चैट, इश्यू ट्रैकर व सामान्य ऑटोमेशन आउटपुट से बाहर रखें।

दूर से ब्राउज़र नियंत्रण में भी वही सावधानी चाहिए। Chrome 136 से डिफ़ॉल्ट डेटा डायरेक्टरी पर रिमोट डिबगिंग स्विच लागू होना बंद हुआ और वास्तविक प्रोफ़ाइल से डिबगिंग अलग रखने के लिए कस्टम डायरेक्टरी सुझाई गई। Google की 17 मार्च 2025 की सुरक्षा सूचना ने रिमोट डिबगिंग से कुकी निकालना बदलाव का कारण बताया। आसान रास्ते के लिए किसी व्यक्ति की रोज़मर्रा की ब्राउज़र प्रोफ़ाइल से ऑटोमेशन न जोड़ें।

अनुमति देने से पहले कार्रवाइयाँ बाँटें

नियंत्रण इंटरफ़ेस कारोबारी काम और उनका जोखिम दर्शाए; एक असीमित ब्राउज़र कनेक्शन न दे।

कार्रवाई श्रेणी	उदाहरण	डिफ़ॉल्ट नियंत्रण
देखना	अनुमत प्रोफ़ाइल सूची, स्वास्थ्य, संवेदनशील जानकारी हटाई स्थिति	सीमित पढ़ने के दायरे में अनुमति
जीवनचक्र	लॉन्च, रोकना, प्रोफ़ाइल लीज़ लेना, टेस्ट स्नैपशॉट	केवल नामित प्रोफ़ाइल; हर बदलाव का लॉग
इंटरैक्शन	स्वीकृत ओरिजिन खोलना, तय परीक्षण, परीक्षण सामग्री डाउनलोड	गंतव्य, इनपुट, आउटपुट पथ और अवधि सीमित
अधिक असर	सामग्री भेजना, टेस्ट डेटा रीसेट, पहुँच बदलाव, खर्च, प्रोफ़ाइल मिटाना	पूर्वावलोकन, स्पष्ट स्वीकृति और मज़बूत नीति
रहस्य वाली	कुकी, क्रेडेंशियल, प्रॉक्सी पासवर्ड, पुनर्प्राप्ति सामग्री या कच्ची प्रोफ़ाइल स्थिति निर्यात	सामान्य ऑटोमेशन इंटरफ़ेस से अस्वीकार

जोखिम संदर्भ पर निर्भर है। अस्थायी स्टेजिंग खाते में फ़ॉर्म भेजना नियमित परीक्षण हो सकता है; वही कार्रवाई प्रोडक्शन में कानूनी, आर्थिक या प्रतिष्ठा संबंधी असर डाल सकती है। निर्णय वातावरण, खाते और सटीक प्रस्तावित बदलाव से बाँधें।

सीमित और कम अवधि के क्रेडेंशियल जारी करें

हर कार्यभार की अलग सेवा पहचान रखें। CI, स्थानीय स्क्रिप्ट या एजेंट को मानव व्यवस्थापक का सत्र न दें। उपयोगी टोकन इनसे सीमित होता है:

• संगठन और जहाँ लागू हो क्लाइंट या वर्कस्पेस;
• प्रोफ़ाइल ID, फ़ोल्डर, टैग या स्थायी संसाधन चयन;
• अनुमत कार्रवाइयाँ;
• इच्छित सेवा या ऑडियंस;
• जारी समय, समाप्ति और निरस्तीकरण स्थिति;
• जहाँ समर्थित हो डिवाइस या कार्यभार पहचान; और
• समवर्ती काम, दर तथा लागत की अधिकतम सीमा।

RFC 9700 ऐक्सेस टोकन अधिकार न्यूनतम रखने की सलाह देता है, जिसमें इच्छित संसाधन सर्वर, संसाधन और कार्रवाइयाँ शामिल हैं। वह बताता है कि ऑडियंस सीमा टोकन लीक का असर कैसे घटाती है। वर्तमान Model Context Protocol प्राधिकरण विनिर्देश भी ऑडियंस सत्यापन माँगता है और क्लाइंट को केवल इच्छित काम के ज़रूरी दायरे माँगने को कहता है।

चरणबद्ध प्राधिकरण प्राथमिकता दें। काम को खोज और पूर्वावलोकन अधिकार से शुरू करें। बाद के कदम को अधिक अधिकार चाहिए तो उसी कदम के लिए नया कम अवधि वाला अधिकार माँगें। वर्कफ़्लो की कोई शाखा शायद कभी माँगे, इसलिए स्थायी पूर्ण पहुँच टोकन न दें।

MCP या दूसरी मध्यस्थ सेवा के लिए आगे की सेवा के क्रेडेंशियल अलग रखें। MCP प्राधिकरण सुरक्षा विचार संसाधन विशिष्ट टोकन माँगते हैं और आने वाला MCP टोकन आगे API को भेजने से रोकते हैं। यही सीख किसी ऑटोमेशन गेटवे पर लागू है: हर भरोसे की सीमा अपना क्रेडेंशियल जाँचे और स्वीकृत कार्रवाई के लिए केवल आवश्यक अगले अधिकार दे या ले।

स्वीकृति विशिष्ट और जाँच योग्य बनाएँ

स्वीकृति स्पष्ट करे, ‘किस बात को मंज़ूरी?’ ‘इस एजेंट को अनुमति दें’ जैसी सामान्य पुष्टि समीक्षक की समझ से अधिक अधिकार दे सकती है।

अधिक असर वाले कमांड के पूर्वावलोकन में दिखाएँ:

• काम शुरू करने वाला और कार्यभार;
• संगठन, प्रोफ़ाइल, लक्ष्य खाता और गंतव्य;
• प्रस्तावित बदलाव का आसानी से समझ आने वाला वर्णन;
• सटीक प्रभावित संसाधन और अधिकतम संख्या;
• अपेक्षित लागत या बाहरी असर;
• बदलने वाले मान, रहस्य छिपाकर;
• रोलबैक या पुनर्प्राप्ति विधि;
• स्वीकृति की छोटी वैधता अवधि; और
• कम अधिकार से काम क्यों नहीं हो सकता।

स्वीकृति को सामान्यीकृत अनुरोध के हैश, नीति संस्करण और प्रोफ़ाइल संस्करण से बाँधें। अपरिवर्तनीय या बाहर दिखने वाली कार्रवाई में उसे एकबारगी रखें। अनुरोध, गंतव्य, संसाधन संख्या या संबंधित स्थिति बदले तो स्वीकृति अमान्य करें और नया पूर्वावलोकन दें।

स्वीकृति प्राधिकरण का विकल्प नहीं है। समीक्षक संगठन के पास न होने वाले अधिकार नहीं दे सकता और पुष्टि संदेश निषिद्ध वर्कफ़्लो को स्वीकार्य नहीं बनाता।

विफलता में सुरक्षित निष्पादन बनाएँ

न्यूनतम अधिकार त्रुटि के बाद के परिणाम भी सीमित करता है। निष्पादन अनुबंध में प्रोफ़ाइल लीज़, पूर्वशर्तें, सीमित पुनः प्रयास, रद्द करना और पुनर्प्राप्ति व्यवहार शामिल हों।

विफलता	सुरक्षित प्रतिक्रिया
अनुमति अस्वीकृत	रुकें। गायब अनुमति बताएँ; अपने आप अधिकार न बढ़ाएँ।
प्रोफ़ाइल उपयोग में	दूसरा लेखक शुरू न करें। सीमित प्रतीक्षा या स्पष्ट टकराव लौटाएँ।
रन में लीज़ खोना	नई कार्रवाइयाँ रोकें, संवेदनशील जानकारी रहित प्रमाण रखें और पुनर्प्राप्ति प्रक्रिया अपनाएँ।
पढ़ने से पहले नेटवर्क टाइमआउट	केवल घोषित सीमा और समय के भीतर फिर कोशिश करें।
भेजने के बाद कनेक्शन टूटना	परिणाम अज्ञात चिह्नित करें। लक्ष्य सुरक्षित एक ही असर वाला दोहराव न दे तो कार्रवाई न दोहराएँ।
स्वीकृति समाप्त या अनुरोध बदला	कार्रवाई रद्द करें और नया पूर्वावलोकन व स्वीकृति माँगें।
ऑडिट गंतव्य अनुपलब्ध	घोषित नीति अपनाएँ। अधिक असर का काम सामान्यतः रोकें; कम जोखिम के रिकॉर्ड सुरक्षित सीमित स्थानीय बफ़र में जा सकते हैं।
स्नैपशॉट या बहाली सत्यापन विफल	प्रभावित स्थिति अलग करें; पिछला ज्ञात सही संस्करण न बदलें।

हर बदलाव करने वाला कमांड बताए कि दोहराने पर उसका असर एक ही रहता है या नहीं, कौन-सी पूर्वशर्त जाँचता है और रुकावट के बाद अंतिम परिणाम कैसे मिलता है। भेजना, खरीदना, मिटाना, आमंत्रित करना और अनुमति बदलना जैसी कार्रवाइयों में ‘हर त्रुटि पर फिर कोशिश’ असुरक्षित है।

रहस्य दर्ज किए बिना निर्णय दर्ज करें

ऑडिट घटना कार्रवाई फिर समझने योग्य बनाए, दूसरा क्रेडेंशियल भंडार नहीं। OWASP लॉगिंग गाइड प्राधिकरण विफलता और अधिक जोखिम का काम दर्ज करने, कब-कहाँ-कौन-क्या बताने तथा लॉग की पहुँच सुरक्षित रखने को कहती है। वह पासवर्ड और तकनीकी रहस्य लॉग में खुलने की चेतावनी भी देती है।

हर ऑटोमेशन निर्णय में दर्ज करें:

• मानव, सेवा और प्रतिनिधि कर्ता की पहचान;
• संगठन और संवेदनशील जानकारी हटाया प्रोफ़ाइल संदर्भ;
• कमांड नाम, अनुरोध ID और जहाँ लागू हो एकबारगी असर की कुंजी;
• नीति संस्करण, निर्णय और कारण कोड;
• स्वीकृत काम की स्वीकृति संदर्भ और अनुमोदक;
• संवेदनशील जानकारी हटाया गंतव्य और संसाधन संख्या;
• शुरुआत, पूर्णता समय और परिणाम;
• ब्राउज़र, क्लाइंट और ऑटोमेशन अडैप्टर संस्करण; और
• पुनर्प्राप्ति, रद्द या मैनुअल समीक्षा स्थिति।

कुकी मान, पासवर्ड, ऐक्सेस या रीफ़्रेश टोकन, प्राधिकरण हेडर, प्रॉक्सी क्रेडेंशियल, एन्क्रिप्शन कुंजी, पूरा पेज, फ़ॉर्म मान या कच्चे प्रोफ़ाइल आर्काइव दर्ज न करें। URL न्यूनतम रखें क्योंकि पथ और क्वेरी में निजी डेटा या रहस्य हो सकते हैं। ऑडिट पहुँच बचाएँ, प्रतिधारण तय करें और लॉगिंग धीमी, भरी या बंद होने का व्यवहार जाँचें।

नीति का ठोस उदाहरण

यह छद्मकोड डिज़ाइन उदाहरण है, Isoline कॉन्फ़िगरेशन नहीं। यह CI कार्यभार को केवल स्टेजिंग प्रोफ़ाइल पर क्षेत्रीय स्मोक परीक्षण की अनुमति देता है:

principal: "workload:regional-smoke-tests"
tenant: "org:example-studio"
profiles:
  selector: "tag == qa-staging"
operations:
  allow:
    - "profile.read"
    - "profile.launch"
    - "test.run-approved-suite"
    - "profile.stop"
  deny:
    - "profile.export-session-state"
    - "profile.delete"
    - "team.manage"
destinations:
  allow:
    - "https://staging.example.test"
conditions:
  expiresAt: "2026-08-26T18:00:00Z"
  maxConcurrentProfiles: 2
  maxRuns: 20
  requireCleanStop: true
approvals:
  "staging-data.reset": "single-use-human-approval"
onUnknownSideEffect: "stop-and-review"

यह सामान्य ब्राउज़िंग, प्रोडक्शन पहुँच, रहस्य निर्यात, टीम प्रशासन या मनमाने दायरे जोड़ने का अधिकार नहीं देती। परीक्षण को नया ओरिजिन या कार्रवाई चाहिए तो वह नीति समीक्षा से गुज़रे, रनटाइम पर अनुमान से न जुड़े।

समीक्षा चेकलिस्ट

ऑटोमेशन चालू करने से पहले पुष्टि करें कि:

• सिस्टम स्वामी और जहाँ लागू हो क्लाइंट ने उद्देश्य दर्ज किया है;
• हर मानव और कार्यभार की जवाबदेह पहचान है;
• टोकन टेनेंट, प्रोफ़ाइल, कार्रवाई, ऑडियंस, समय और दर से सीमित है;
• लक्ष्य खातों में केवल काम की आवश्यक भूमिकाएँ हैं;
• रोज़मर्रा की निजी प्रोफ़ाइल बाहर हैं;
• सामान्य पढ़ने या लॉग से सत्र स्थिति और रहस्य नहीं निकलते;
• अधिक असर के काम का विशिष्ट पूर्वावलोकन और समाप्त होने वाली स्वीकृति है;
• प्रोफ़ाइल लॉक समवर्ती लेखक रोकता है;
• बदलाव कमांड में पूर्वशर्त, दोहराव का असर और अज्ञात परिणाम का प्रबंधन तय है;
• रद्द करना, निरस्तीकरण, रुकावट और बहाली जाँची गई हैं;
• ऑडिट संवेदनशील सामग्री दिखाए बिना निर्णय फिर समझा सकता है; और
• अनुमति हटने या लक्ष्य सेवा द्वारा कार्रवाई अस्वीकार होने पर वर्कफ़्लो रुकता है।

सीमाएँ

न्यूनतम अधिकार गलती और क्रेडेंशियल लीक का असर घटाता है; अनधिकृत काम स्वीकार्य नहीं बनाता और तीसरी सेवा की अनुमति सुनिश्चित नहीं करता। Playwright ब्राउज़र संदर्भ दस्तावेज़ के अनुसार संदर्भ अलगाव परीक्षण अलग रख सकता है, लेकिन एक मशीन को कई स्वतंत्र भरोसेमंद डिवाइस नहीं बनाता। प्रभावित डिवाइस, दुर्भावनापूर्ण एक्सटेंशन, अधिक अधिकार वाला लक्ष्य खाता या असुरक्षित अगली सेवा इच्छित सीमा तोड़ सकती है।

वर्कफ़्लो बदलने पर अनुमतियाँ जाँचें। अप्रयुक्त दायरे हटाएँ, निष्क्रिय क्रेडेंशियल समाप्त करें, अस्वीकृति प्रक्रियाएँ फिर जाँचें और कच्ची सत्र सामग्री की माँग को सामान्य ऑटोमेशन सुविधा के बजाय अलग अधिक जोखिम की सुरक्षा समीक्षा मानें।