पूरे डोमेन के लिए, सौंपे जाने की सुविधा इस्तेमाल करने के सबसे सही तरीके

एडमिन के तौर पर, डोमेन-वाइड डेलिगेशन का इस्तेमाल करके, इंटरनल और तीसरे पक्ष के ऐप्लिकेशन को अपने उपयोगकर्ताओं के Google Workspace खाते में मौजूद डेटा को ऐक्सेस करने की अनुमति दी जा सकती है. इसके लिए, असली उपयोगकर्ता की सहमति की ज़रूरत नहीं होती. इसके लिए, Google Cloud Console में एक सेवा खाता बनाया जाता है. साथ ही, Google Admin console में जाकर, पूरे डोमेन के लिए उस खाते को अनुमति दी जाती है. Admin console में, सेवा खाते को एपीआई के सीमित स्कोप भी दिए जा सकते हैं. पूरे डोमेन के डेटा का ऐक्सेस देने के बारे में ज़्यादा जानने के लिए, पूरे डोमेन के डेटा का ऐक्सेस देकर एपीआई के ऐक्सेस को कंट्रोल करना लेख पढ़ें.

सेवा खातों को मैनेज और सुरक्षित करना

पहचान और ऐक्सेस मैनेजमेंट (IAM), सेवा खातों का इस्तेमाल करने के लिए दिशा-निर्देश देता है. इससे ऐक्सेस को सीमित किया जा सकता है. साथ ही, विशेषाधिकारों के गलत इस्तेमाल और पहचान छिपाकर किए जाने वाले हमलों से बचा जा सकता है. दिशा-निर्देश देखने के लिए, सेवा खातों का इस्तेमाल करने के सबसे सही तरीके पर जाएं.

गाइड में दिए गए सभी सुझाव, डोमेन-वाइड डेलिगेशन का इस्तेमाल करने वाले सेवा खातों को सुरक्षित रखने के लिए लागू होते हैं. हालांकि, कुछ खास सुझाव यहां दिए गए हैं:

	इसके बजाय, सेवा खाते के सीधे ऐक्सेस या OAuth की सहमति का इस्तेमाल करें अगर सेवा खाते या OAuth की सहमति का इस्तेमाल करके सीधे तौर पर अपना काम पूरा किया जा सकता है, तो डोमेन-वाइड डेलिगेशन का इस्तेमाल न करें. अगर डोमेन-वाइड डेलिगेशन का इस्तेमाल करना ज़रूरी है, तो सेवा खाते के लिए OAuth स्कोप का सेट सीमित करें. OAuth के स्कोप, यह तय नहीं करते कि सेवा खाता किन उपयोगकर्ताओं के तौर पर काम कर सकता है. हालांकि, वे यह तय करते हैं कि सेवा खाता किस तरह का उपयोगकर्ता डेटा ऐक्सेस कर सकता है. पूरे डोमेन को ऐक्सेस देने की सुविधा का इस्तेमाल न करें
	सेवा खाते की कुंजी बनाने और अपलोड करने पर पाबंदी लगाना संगठन की नीतियों का इस्तेमाल करके, डोमेन-वाइड डेलिगेशन वाले सेवा खातों के लिए कुंजी बनाने और अपलोड करने पर पाबंदी लगाएं. इससे सेवा खाते की कुंजियों के ज़रिए, सेवा खाते के डुप्लीकेट बनाने की सुविधा सीमित हो जाती है. उपयोगकर्ताओं को सेवा खाते की कुंजियां बनाने या अपलोड करने की अनुमति न दें
	डिफ़ॉल्ट सेवा खातों के लिए, अपने-आप भूमिकाएं असाइन होने की सुविधा बंद करना डिफ़ॉल्ट रूप से बनाए गए सेवा खातों को Editor की भूमिका दी जाती है. इससे खाता, Google Cloud प्रोजेक्ट में मौजूद सभी संसाधनों को पढ़ और उनमें बदलाव कर सकता है. डिफ़ॉल्ट सेवा खातों के लिए, भूमिकाएं अपने-आप असाइन होने की सुविधा बंद की जा सकती है. इससे यह पक्का किया जा सकता है कि उन्हें एडिटर की भूमिका अपने-आप न मिले. साथ ही, कोई दुर्भावनापूर्ण उपयोगकर्ता उनका आसानी से गलत इस्तेमाल न कर पाए. डिफ़ॉल्ट सेवा खातों के लिए, भूमिकाएं अपने-आप असाइन होने की सुविधा का इस्तेमाल न करें
	कर्सर को कम से कम घुमाएं लैटरल मूवमेंट तब होता है, जब किसी प्रोजेक्ट में मौजूद सेवा खाते के पास, किसी दूसरे प्रोजेक्ट में मौजूद सेवा खाते के तौर पर काम करने की अनुमति होती है. इस वजह से, संसाधनों का अनचाहा ऐक्सेस मिल सकता है. किसी और के नाम पर काम करने वाले खातों की पहचान करने और उन्हें सीमित करने के लिए, "लैटरल मूवमेंट की अहम जानकारी" का इस्तेमाल करें. एक सिस्टम से दूसरे सिस्टम में हैकर के पहुंचने की जानकारी देने वाली इनसाइट का इस्तेमाल करके, हैकर के पहुंचने की संभावना को कम करना
	डोमेन-वाइड डेलिगेशन की सुविधा वाले सेवा खातों के ऐक्सेस को सीमित करना अगर सेवा खाते के पास उपयोगकर्ता से ज़्यादा सुविधाएं हैं, तो उपयोगकर्ता को सेवा खाते की अनुमति देने की नीति में बदलाव करने की अनुमति न दें. आईएएम की भूमिकाओं का इस्तेमाल करके, डोमेन-वाइड डेलिगेशन के लिए मंज़ूरी वाले सेवा खातों के ऐक्सेस को सीमित करें. उपयोगकर्ताओं को, ज़्यादा विशेषाधिकार वाले सेवा खातों की अनुमति देने से जुड़ी नीतियां बदलने की अनुमति न दें

सेवा खातों को इनसाइडर रिस्क से सुरक्षित रखना

डोमेन-वाइड डेलिगेशन का इस्तेमाल सिर्फ़ तब करें, जब आपके कारोबार के लिए कोई ऐसा ज़रूरी काम हो जिसके लिए किसी ऐप्लिकेशन को Google Workspace के डेटा को ऐक्सेस करने के लिए, उपयोगकर्ता की सहमति को बायपास करना ज़रूरी हो. उपयोगकर्ता की सहमति के साथ OAuth जैसे विकल्पों का इस्तेमाल करें या Marketplace ऐप्लिकेशन का इस्तेमाल करें. ज़्यादा जानकारी के लिए, Google Workspace Marketplace पर जाएं.

डोमेन-वाइड डेलिगेशन की अनुमतियों वाले सेवा खातों को अंदरूनी जोखिम से बचाने के लिए, ये सबसे सही तरीके अपनाएं:

	सिर्फ़ ज़रूरी सुविधाओं का ऐक्सेस देना पक्का करें कि डोमेन-वाइड डेलिगेशन वाले सेवा खातों के पास, सिर्फ़ वे ज़रूरी अनुमतियां हों जिनकी ज़रूरत उन्हें अपने काम करने के लिए होती है. ग़ैर-ज़रूरी OAuth स्कोप का ऐक्सेस न दें.
	सेवा खातों को अलग-अलग Google Cloud प्रोजेक्ट में होस्ट करना पक्का करें कि पूरे डोमेन पर सौंपने की सुविधा वाले सेवा खाते, Google Cloud के खास प्रोजेक्ट में होस्ट किए गए हों. उन प्रोजेक्ट का इस्तेमाल, कारोबार की अन्य ज़रूरतों के लिए न करें.
	सेवा खाते की कुंजियों का इस्तेमाल न करें पूरे डोमेन को ऐक्सेस देने की सुविधा का इस्तेमाल करने के लिए, सेवा खाते की कुंजियों का इस्तेमाल करना ज़रूरी नहीं है. इसके बजाय, signJwt API का इस्तेमाल करें. पूरे डोमेन को ऐक्सेस देने की सुविधा के लिए, सेवा खाते की कुंजियों का इस्तेमाल न करें
	उन प्रोजेक्ट का ऐक्सेस सीमित करें जिनमें पूरे डोमेन के लोगों को डेटा का ऐक्सेस दिया गया है ऐसे लोगों की संख्या कम करें जिनके पास डोमेन-वाइड डेलिगेशन की सुविधा सेट अप किए गए Google Cloud प्रोजेक्ट में बदलाव करने का ऐक्सेस है. Cloud Asset Inventory API का इस्तेमाल करके, यह पता लगाया जा सकता है कि सेवा खातों का ऐक्सेस किसके पास है. उदाहरण के लिए, Cloud Shell का इस्तेमाल करके यह कमांड चलाएं: `gcloud asset get-effective-iam-policy --scope=organizations/ORG_ID --names=//iam.googleapis.com/projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT_ID` `ORG_ID`: यह आपके Google Cloud संगठन का आईडी है. ज़्यादा जानें `PROJECT_ID`: यह उस Google Cloud प्रोजेक्ट का आईडी है जिसके तहत सेवा खाता मौजूद है. ज़्यादा जानें `SERVICE_ACCOUNT_ID`: सेवा खाते का आईडी. यह आईडी, Admin console के डोमेन-वाइड डेलिगेशन पेज पर मौजूद क्लाइंट आईडी में या सेवा खाते के ईमेल पते में दिखता है. ज़्यादा जानें यह समझने के लिए कि सेवा खाते के लिए, सीधे तौर पर या अपने-आप मिली अनुमतियां किसके पास हैं, `iam.serviceAccountTokenCreator` या `iam.serviceAccountKeyAdmin` मालिक और एडिटर जैसी अनुमतियां या भूमिकाएं देखें. जानें कि Google Cloud सेवा खातों का ऐक्सेस किसके पास है

सेवा खातों को मैनेज और सुरक्षित करना

सेवा खातों को इनसाइडर रिस्क से सुरक्षित रखना

मिलते-जुलते विषय