एडवांस मोड के लिए कॉन्टेक्स्ट अवेयर ऐक्सेस के उदाहरण

संवेदनशील डेटा वाले ऐप्लिकेशन को ऐक्सेस करने की सुरक्षा को बेहतर बनाने के लिए, यह तय किया जा सकता है कि सिस्टम में उपयोगकर्ता की पुष्टि कैसे की जाए. इससे यह तय किया जा सकेगा कि उपयोगकर्ता को ऐप्लिकेशन का ऐक्सेस मिलेगा या नहीं.

उदाहरण के लिए, सिर्फ़ पासवर्ड से लॉग इन करने वाले उपयोगकर्ताओं को ऐसे ऐप्लिकेशन ऐक्सेस करने की अनुमति दी जा सकती है जिनमें कोई संवेदनशील जानकारी नहीं होती. वहीं, दूसरे फ़ैक्टर के तौर पर हार्डवेयर सुरक्षा कुंजी से लॉग इन करने वाले उपयोगकर्ता को, एंटरप्राइज़ के सबसे संवेदनशील ऐप्लिकेशन ऐक्सेस करने की अनुमति दी जा सकती है.

इस ऐक्सेस लेवल में, request.auth एट्रिब्यूट का इस्तेमाल किया जाता है. इससे यह पुष्टि की जाती है कि उपयोगकर्ता, दो चरणों में पुष्टि करने के लिए पासवर्ड और हार्डवेयर कुंजी, दोनों का इस्तेमाल करके लॉग इन करते हैं. साथ ही, संवेदनशील ऐप्लिकेशन को ऐक्सेस कर सकते हैं.

request.auth.claims.crd_str.pwd == true && request.auth.claims.crd_str.hwk == true

एडमिन अक्सर यह चाहते हैं कि उपयोगकर्ता को कॉर्पोरेट संसाधनों का ऐक्सेस सिर्फ़ तब मिले, जब उसने ज़्यादा सुरक्षित क्रेडेंशियल से पुष्टि की हो. यहां दिए गए उदाहरण में, levels और request.auth एट्रिब्यूट का इस्तेमाल इस तरह किया गया है:

• अगर कोई उपयोगकर्ता कॉर्पोरेट डिवाइस से आ रहा है, तो एसएमएस के अलावा, पुष्टि करने के किसी भी तरीके का इस्तेमाल किया जा सकता है. जैसे, पुश नोटिफ़िकेशन, हार्डवेयर या सॉफ़्टवेयर सुरक्षा कुंजी या एक बार इस्तेमाल किया जाने वाला पासवर्ड
• अगर कोई उपयोगकर्ता किसी ऐसे डिवाइस से आ रहा है जो कंपनी का नहीं है, तो उसे हार्डवेयर या सॉफ़्टवेयर सुरक्षा कुंजी का इस्तेमाल करना होगा

// Require basic MFA (not SMS) on corporate devices and security key (hardware or software) if not
levels.Require_Secure_Device &&
(
(
levels.Require_Corporate_Device &&
request.auth.claims.crd_str.mfa &&
!request.auth.claims.crd_str.sms
) ||
(
!levels.Require_Corporate_Device &&
(
request.auth.claims.crd_str.hwk || request.auth.claims.crd_str.swk
)
)
)

सिर्फ़ डेस्कटॉप वेब ऐप्लिकेशन के लिए उपलब्ध है. मोबाइल ऐप्लिकेशन या एपीआई के लिए उपलब्ध नहीं है

डिवाइस बाउंड सेशन क्रेडेंशियल (डीबीएससी) की ज़रूरत होने पर, संवेदनशील डेटा वाले ऐप्लिकेशन को ऐक्सेस करने की सुरक्षा को बेहतर बनाया जा सकता है. जब कोई व्यक्ति Windows पर Chrome ब्राउज़र का इस्तेमाल करता है, तब डीबीएससी उसके सेशन को उसके डिवाइस से बाइंड कर देता है. इससे सेशन हाइजैकिंग का खतरा काफ़ी कम हो जाता है.

यह ऐक्सेस लेवल, request.auth एट्रिब्यूट का इस्तेमाल करके यह पुष्टि करता है कि उपयोगकर्ता के सेशन, किसी खास डिवाइस से जुड़े हैं. अगर ऐसा है, तो ऐप्लिकेशन को ऐक्सेस करने की अनुमति मिल जाती है. अगर ऐसा नहीं है (यानी कि सेशन, डीबीएससी से जुड़ा नहीं है), तो ऐक्सेस करने की अनुमति नहीं मिलती.

गड़बड़ियों से बचने के लिए, इस ऐक्सेस लेवल के तहत आने वाले सभी उपयोगकर्ता खातों के लिए, डीबीएससी की सुविधा चालू करें. ज़्यादा जानकारी के लिए, डीबीएससी चालू करना लेख पढ़ें.

ऐक्टिव मोड चालू करने से पहले, ऐक्सेस लेवल को मॉनिटर मोड पर सेट करें. मॉनिटर मोड में, ऐक्सेस लेवल लागू करने के असर को टेस्ट किया जा सकता है. इससे उपयोगकर्ता के ऐक्सेस में कोई रुकावट नहीं आती.

कस्टम ऐक्सेस लेवल बनाने के लिए, इस सीईएल एक्सप्रेशन का इस्तेमाल करें:

request.auth.sessionBoundToDevice(origin) == true

Chrome ब्राउज़र के वर्शन 136 या इसके बाद के वर्शन वाले Windows डिवाइसों पर ही डीबीएससी लागू करने के लिए, इस CEL एक्सप्रेशन का इस्तेमाल करें:

!(device.os_type == OsType.DESKTOP_WINDOWS && device.chrome.versionAtLeast("136.0.0")) || request.auth.sessionBoundToDevice(origin) == true

BeyondCorp Alliance के पार्टनर की ओर से रिपोर्ट किए गए डिवाइस सिग्नल का इस्तेमाल किया जा सकता है. इस उदाहरण में, Lookout Software को ऐप्लिकेशन के तौर पर इस्तेमाल किया गया है.

यह ऐक्सेस लेवल, डिवाइस एट्रिब्यूट का इस्तेमाल करके यह पुष्टि करता है कि Google Workspace को ऐक्सेस करने के लिए इस्तेमाल किया गया डिवाइस, Lookout की नीतियों का पालन करता है. साथ ही, डिवाइस का हेल्थ स्कोर बहुत अच्छा है.

यह ऐक्सेस लेवल, डिवाइस एट्रिब्यूट का इस्तेमाल करके यह पुष्टि करता है कि उपयोगकर्ता, मैनेज किए जा रहे Chrome ब्राउज़र के नए वर्शन का इस्तेमाल कर रहे हैं. साथ ही, यह सिर्फ़ ऐसे ब्राउज़र से ऐक्सेस करने की अनुमति देता है.

कस्टम ऐक्सेस लेवल वाले डिवाइसों के लिए, एंटरप्राइज़ सर्टिफ़िकेट का इस्तेमाल किया जा सकता है. इससे यह पता लगाया जा सकता है कि कोई डिवाइस, कंपनी के मालिकाना हक वाली ऐसेट है या नहीं. इस ऐक्सेस लेवल में, ऐसेट की पुष्टि करने के लिए डिवाइस एट्रिब्यूट का इस्तेमाल किया जाता है. ज़्यादा जानकारी और उदाहरणों के लिए, एंटरप्राइज़ सर्टिफ़िकेट की शर्तें कॉन्फ़िगर करना लेख पढ़ें.

किसी डिवाइस में एक से ज़्यादा सर्टिफ़िकेट हो सकते हैं. एंटरप्राइज़ सर्टिफ़िकेट का इस्तेमाल, कस्टम ऐक्सेस लेवल में किया जाता है. इसके लिए, exists() मैक्रो का इस्तेमाल किया जाता है. उदाहरण के लिए:

device.certificates.exists(cert, predicate)

इस उदाहरण में, cert एक सामान्य आइडेंटिफ़ायर है. इसका इस्तेमाल, डिवाइस के एंटरप्राइज़ सर्टिफ़िकेट से बाइंड करने के लिए, वैरिएबल predicate में किया जाता है. exists() मैक्रो, हर एलिमेंट के लिए तय की गई शर्त के नतीजों को or (||) ऑपरेटर के साथ जोड़ता है. अगर कम से कम एक सर्टिफ़िकेट, प्रेडिकेट एक्सप्रेशन की शर्तों को पूरा करता है, तो मैक्रो सही वैल्यू दिखाता है.

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

आम तौर पर इस्तेमाल की जाने वाली नीतियों के उदाहरण:

पुष्टि करें कि डिवाइस में कंपनी के रूट सर्टिफ़िकेट से साइन किया गया मान्य एंटरप्राइज़ सर्टिफ़िकेट मौजूद है

device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "ROOT_CA_FINGERPRINT")

डिवाइस पर एंटरप्राइज़ सर्टिफ़िकेट जारी करने वाले की पुष्टि करना

device.certificates.exists(cert, cert.is_valid && cert.issuer == "EMAILADDRESS=test_inter1@beyondcorp.in, CN=inter_1, OU=BCEDemo_1, O=BCEDemo, L=NCR, ST=UP, C=IN")

इस उदाहरण में, device एट्रिब्यूट का इस्तेमाल किया गया है. इससे यह ज़रूरी हो जाता है कि डिस्क एन्क्रिप्शन और स्क्रीन लॉक, दोनों चालू हों. इसके अलावा, डिवाइस को एडमिन की मंज़ूरी मिलनी चाहिए.

डिफ़ॉल्ट रूप से, एंडपॉइंट पुष्टि की सुविधा से बनाए गए सभी डिवाइसों को अनुमति मिल जाती है. हालांकि, कुछ मामलों में आपको किसी डिवाइस को ब्लॉक करना पड़ सकता है. जैसे, जब कोई डिवाइस खो गया हो. ऐसे मामलों में, आपको इन डिवाइसों को कॉर्पोरेट संसाधनों को ऐक्सेस करने की अनुमति नहीं देनी चाहिए.

इस दस्तावेज़ में, ऐक्सेस लेवल के अन्य उदाहरणों के लिए मान लें कि इस ऐक्सेस लेवल का नाम Require_Secure_Device है.

// Require disk encryption and screen lock enabled
// This is applicable across all major platforms (Windows, Mac, Linux, CrOS, iOS, Android)
// This foundational and should be depended upon by all other access levels
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
device.is_secured_with_screenlock &&
device.is_admin_approved_device

इस उदाहरण में, ऐक्सेस लेवल के लिए device एट्रिब्यूट का इस्तेमाल किया गया है. इससे बुनियादी सुरक्षा से जुड़ी ज़रूरी शर्तों को पूरा करने वाले Chrome ब्राउज़र का इस्तेमाल करना ज़रूरी हो जाता है.

// Require Chrome to be managed at profile or browser level, must have
// security event reporting enabled and must be version 97 or greater
levels.Require_Secure_Device &&
(
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_BROWSER_MANAGED ||
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_PROFILE_MANAGED
) &&
device.chrome.is_security_event_analysis_enabled &&
device.chrome.versionAtLeast("97")

इस उदाहरण में, device एट्रिब्यूट का इस्तेमाल किया गया है. इससे यह ज़रूरी हो जाता है कि उपयोगकर्ता, मैनेज किए जा रहे Chrome ब्राउज़र या प्रोफ़ाइल से हो. साथ ही, Chrome में खतरे और डेटा सुरक्षा से जुड़े कनेक्टर चालू हों. इस उदाहरण में, levels एट्रिब्यूट का इस्तेमाल किया गया है. इससे पहले, मैनेज किए गए Chrome के ऐक्सेस लेवल के बारे में बताया गया था. यहां दिए गए उदाहरण में, यह माना गया है कि निर्भरता वाले ऐक्सेस लेवल का नाम Require_Managed_Chrome है.

// Require managed chrome (dependent on "Require_Managed_Chrome" access level)
// and require content inspection for downloads as well as URL check enabled
levels.Require_Managed_Chrome &&
device.chrome.is_file_download_analysis_enabled &&
device.chrome.is_realtime_url_check_enabled

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

• अगर किसी डिवाइस का सीरियल नंबर, कंपनी के ऐसेट मैनेजमेंट सिस्टम में मौजूद किसी सीरियल नंबर से मेल खाता है
• अगर किसी डिवाइस में कंपनी से जारी किया गया मान्य एंटरप्राइज़ सर्टिफ़िकेट मौजूद है

इन दोनों तरीकों का इस्तेमाल, कस्टम ऐक्सेस लेवल में किया जा सकता है. कस्टम ऐक्सेस लेवल में, लेवल और डिवाइस एट्रिब्यूट का इस्तेमाल करके यह तय किया जाता है कि डिवाइस, कंपनी के मालिकाना हक वाला है या उसे मैनेज किया जा रहा है.

// The device is a corporate if one of the following conditions is true:
// 1. अगर सीरियल नंबर, एडमिन के अपलोड किए गए सीरियल नंबर से मेल खाता है
// 2. अगर डिवाइस में एंटरप्राइज़ की ओर से जारी किया गया मान्य सर्टिफ़िकेट है
levels.Require_Secure_Device &&
(
device.is_corp_owned_device ||
device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "SOME_ROOT_CA_FINGERPRINT")
)

फ़िंगरप्रिंट, DER-एन्कोड किए गए सर्टिफ़िकेट का, बिना पैडिंग वाला base64-एन्कोड किया गया SHA256 डाइजेस्ट (बाइनरी फ़ॉर्मैट में) होता है. openssl का इस्तेमाल करके, PEM फ़ॉर्मैट में मौजूद सर्टिफ़िकेट से स्ट्रिंग जनरेट की जा सकती है. इसके लिए, यह तरीका अपनाएं:

$ openssl x509 -in cert.pem -out cert.der -outform DER
$ openssl dgst -sha256 -binary cert.der > digest.sha
$ openssl base64 -in digest.sha

• जारी करने का टाइमस्टैंप (iat)
• ऐक्सेस खत्म होने का टाइमस्टैंप (exp)

ऐक्सेस लेवल, device एट्रिब्यूट का इस्तेमाल करता है, ताकि यह पक्का किया जा सके कि CrowdStrike का डेटा अप-टू-डेट है. ध्यान दें कि Chrome Enterprise Premium में, Falcon ZTA से मिले किसी भी नए आकलन को इस्तेमाल करने में 90 मिनट का समय लगता है. इसलिए, एक घंटे से कम समय का इस्तेमाल करने की सलाह नहीं दी जाती.

// Ensure one of these conditions is true for data from Crowdstrike:
// Must meet one of these conditions
// 1. डिवाइस का आकलन पिछले एक दिन में किया गया था
// 2. असेसमेंट की समयसीमा खत्म नहीं हुई है (पिछले iat के बाद दो हफ़्ते)
device.vendors में "CrowdStrike" मौजूद है && (
request.time - timestamp(device.vendors["CrowdStrike"].data["iat"]) < duration("1d") ||
timestamp(device.vendors["CrowdStrike"].data["exp"]) - request.time > duration("0m")
)

Chrome Enterprise Premium, BeyondCorp Alliance के कई पार्टनर के साथ काम करता है. इससे उनके डिवाइस सिग्नल और कॉन्टेक्स्ट को Chrome Enterprise Premium के समाधान में इंटिग्रेट किया जा सकता है. पार्टनर, Chrome Enterprise Premium के साथ कई एट्रिब्यूट शेयर कर सकते हैं. इनमें से एक एट्रिब्यूट, is_compliant_device है. यहां दिए गए उदाहरण में, device एट्रिब्यूट का इस्तेमाल किया गया है. इससे पता चलता है कि हम यह कैसे जांच सकते हैं कि BeyondCorp Alliance के किसी पार्टनर ने Chrome Enterprise Premium के साथ इंटिग्रेट किया है या नहीं. साथ ही, यह भी पता चलता है कि डिवाइस को नीति के मुताबिक माना जाता है या नहीं.

exists मैक्रो, BeyondCorp Alliance के हर पार्टनर के लिए एक्सप्रेशन को || (या) ऑपरेटर के साथ बढ़ाता है.

// Check to see if any of the BCA partners consider the device to be compliant
["CrowdStrike", "Tanium", "PANW", "Check Point", "Lookout"].exists(
v, v in device.vendors && device.vendors[v].is_compliant_device
)

इस उदाहरण में, device एट्रिब्यूट का इस्तेमाल किया गया है. इससे यह पक्का किया जा सकता है कि डिवाइसों पर Android का सुरक्षित वर्शन चल रहा हो.

वेरिफ़ाइड बूट यह जांच करता है कि एक्ज़ीक्यूट किया गया कोड, भरोसेमंद सोर्स (आम तौर पर डिवाइस के ओईएम) से आया है या नहीं. यह भी जांच की जाती है कि कोड किसी हमलावर या गड़बड़ी से तो नहीं आया है. ज़्यादा जानकारी के लिए, पुष्टि किया गया बूट पर जाएं.

// Require green Android verified boot status
device.android_device_security.verified_boot == true

इस उदाहरण में, device एट्रिब्यूट का इस्तेमाल किया गया है. इससे यह पता चलता है कि डिवाइसों को Compatibility Test Suite (CTS) की ज़रूरी शर्तों को पूरा करना होगा. ज़्यादा जानकारी के लिए, Compatibility Test Suite पर जाएं.

// Require devices to pass CTS compliance checks
device.android_device_security.cts_profile_match == true

इस उदाहरण में, device एट्रिब्यूट का इस्तेमाल किया गया है. इससे यह ज़रूरी हो जाता है कि डिवाइसों में Google Play Protect की 'ऐप्लिकेशन की पुष्टि करें' सेटिंग चालू हो.

ऐप्लिकेशन की पुष्टि करने की सुविधा, Google Play के अलावा अन्य सोर्स से इंस्टॉल किए गए ऐप्लिकेशन को खतरों के लिए स्कैन करती है. यह समय-समय पर डिवाइसों को भी स्कैन करता है, ताकि नुकसान पहुंचाने वाले ऐप्लिकेशन का पता लगाया जा सके. 'ऐप्लिकेशन की पुष्टि करें' सुविधा डिफ़ॉल्ट रूप से चालू होती है. बेहतर मैनेजमेंट की सुविधा के तहत आने वाले डिवाइसों के लिए, यह तय किया जा सकता है कि उपयोगकर्ता इस सुविधा को बंद कर सकते हैं या नहीं. ज़्यादा जानकारी के लिए, Android फ़ोन या टैबलेट के लिए सेटिंग लागू करना लेख पढ़ें.

// Require devices to have Google Play Protect Verify Apps enabled
device.android_device_security.verify_apps_enabled == true

इस उदाहरण में, device एट्रिब्यूट का इस्तेमाल किया गया है. इससे उन डिवाइसों को ऐक्सेस करने से रोका जा सकता है जिनमें नुकसान पहुंचा सकने वाले ऐप्लिकेशन मौजूद हैं. इन ऐप्लिकेशन को अक्सर मैलवेयर कहा जाता है. ज़्यादा जानकारी के लिए, नुकसान पहुंचा सकने वाले ऐप्लिकेशन (पीएचए) पर जाएं.

// Deny access to devices that have potentially harmful appsandroid_device_security.has_potentially_harmful_apps != true

कंपनियां यह पक्का करना चाहती हैं कि उनके यहां अलग-अलग शिफ्ट में काम करने वाले कर्मचारी, सिर्फ़ अपनी शिफ्ट के दौरान कॉर्पोरेट संसाधनों को ऐक्सेस कर पाएं. यहां दिए गए ऐक्सेस लेवल में, सोमवार से शुक्रवार तक तीन शिफ़्ट तय करने के लिए levels एट्रिब्यूट का इस्तेमाल किया गया है.

// Shift 1 - Monday to Friday, midnight to 8am
levels.Require_Secure_Device &&
request.time.getDayOfWeek("America/Los_Angeles") >= 1 &&
request.time.getDayOfWeek("America/Los_Angeles") <= 5 &&
request.time.timeOfDay("America/Los_Angeles").between('00:00:00', '08:00:00')

// Shift 2 - Monday to Friday, 8am to 4pm
levels.Require_Secure_Device &&
request.time.getDayOfWeek("America/Los_Angeles") >= 1 &&
request.time.getDayOfWeek("America/Los_Angeles") <= 5 &&
request.time.timeOfDay("America/Los_Angeles").between('08:00:00', '16:00:00')

// Shift 3 - Monday to Friday, 4pm to midnight
levels.Require_Secure_Device &&
request.time.getDayOfWeek("America/Los_Angeles") >= 1 &&
request.time.getDayOfWeek("America/Los_Angeles") <= 5 &&
request.time.timeOfDay("America/Los_Angeles").between('16:00:00', '00:00:00')

// Allow shift workers to access resources from Monday to Friday between 9 AM to 5 PM, except for July fourth.
levels.Require_Secure_Device &&
request.time.getDayOfWeek("America/Los_Angeles") >= 1 &&
request.time.getDayOfWeek("America/Los_Angeles") <= 5 &&
!(
request.time.getMonth("America/Los_Angeles") == 6 &&
request.time.getDayOfMonth("America/Los_Angeles") == 3
) &&
request.time.timeOfDay("America/Los_Angeles").between('09:30:00', '17:00:00')

कभी-कभी कंपनियां, आपातकालीन स्थितियों में ब्रेक ग्लास ऐक्सेस की अनुमति देना चाहती हैं. ऐसा तब होता है, जब एडमिन के पास सुरक्षित डिवाइस का ऐक्सेस नहीं होता है, लेकिन उसे कुछ समय के लिए आपातकालीन ऐक्सेस की ज़रूरत होती है.

ऐसे में, levels एट्रिब्यूट का इस्तेमाल करके, समय और जगह के हिसाब से ऐक्सेस लेवल बनाएं. इसके बाद, इसे किसी खास एडमिन को असाइन करें. यह ऐक्सेस लेवल असाइन किए जाने पर, सिर्फ़ तय की गई अवधि के लिए मान्य होगा. यह समयसीमा खत्म होने के बाद, एडमिन के ऐक्सेस को मौजूदा ज़रूरी शर्तों के हिसाब से कंट्रोल किया जाएगा.

// Allow temporary access to resources on March 1, 2022, between 10 PM to midnight,
// and this access must come from within the US region.
levels.Require_Secure_Device &&
request.time.between('2022-03-01T23:00:00+08:00', '2022-03-02T23:59:59+08:00') &&
origin.region_code == "US"
// ध्यान दें कि खत्म होने का समय शामिल नहीं है. इसलिए, ऊपर दिए गए समय में दो सेकंड ऐसे हो सकते हैं
// जिन्हें उपयोगकर्ता ऐक्सेस नहीं कर सकते. इसके अलावा, इस
// !between('00:00:01','16:00:00') का इस्तेमाल किया जा सकता है

इस ऐक्सेस लेवल में लेवल एट्रिब्यूट का इस्तेमाल किया जाता है. साथ ही, इसके लिए ज़रूरी है कि उपयोगकर्ता, दो ऐक्सेस लेवल की शर्तों को पूरा करें. इस उदाहरण में, access_level_name_1 और access_level_name_2, Internal Name को रेफ़र करते हैं.

levels.access_level_name_1 && levels.access_level_name_2