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

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

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

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

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

अक्सर एडमिन, कॉर्पोरेट संसाधनों का ऐक्सेस सिर्फ़ तब लागू करना चाहते हैं, जब उपयोगकर्ता ने सुरक्षित क्रेडेंशियल से पुष्टि की हो. यहां दिए गए उदाहरण में, लेवल और 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

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

!(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 (||) ऑपरेटर के साथ जोड़ता है. अगर कम से कम एक सर्टिफ़िकेट, प्रेडिकेट एक्सप्रेशन को पूरा करता है, तो मैक्रो true दिखाता है.

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

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

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

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")

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

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

इस दस्तावेज़ में दिए गए ऐक्सेस लेवल के अन्य उदाहरणों के लिए, मान लें कि इस ऐक्सेस लेवल का नाम 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

इस उदाहरण में, ऐक्सेस लेवल, डिवाइस एट्रिब्यूट का इस्तेमाल करके, बुनियादी सुरक्षा की ज़रूरी शर्तों वाले 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")

इस उदाहरण में, डिवाइस एट्रिब्यूट का इस्तेमाल करके, यह ज़रूरी किया गया है कि उपयोगकर्ता, मैनेज किए जा रहे 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

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

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

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

// The device is a corporate if one of the following conditions is true:
// 1. If the serial number matches what the admin has uploaded
If the device has a valid enterprise-issued certificate
levels.Require_Secure_Device &&
(
device.is_corp_owned_device ||
device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "SOME_ROOT_CA_FINGERPRINT")
)

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

$ 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)

ऐक्सेस लेवल, डिवाइस एट्रिब्यूट का इस्तेमाल करके यह पक्का करता है कि 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. Device was assessed within the last day
Assessment has not expired (2 weeks since last iat)
"CrowdStrike" in device.vendors && (
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 है. यहां दिए गए उदाहरण में, डिवाइस एट्रिब्यूट का इस्तेमाल करके यह दिखाया गया है कि हम यह कैसे जांच सकते हैं कि BeyondCorp Alliance के किसी पार्टनर ने Chrome Enterprise Premium के साथ इंटिग्रेट किया है या नहीं. साथ ही, यह भी जांचा जा सकता है कि वह डिवाइस को नीतियों के मुताबिक मानता है या नहीं.

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

// 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
)

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

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

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

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

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

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

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

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

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

// 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"
// Note that the end time is exclusive, so the above potentially has 2 seconds that
// the users may not have access. Another option is to use this
// !between('00:00:01','16:00:00')

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

levels.access_level_name_1 && levels.access_level_name_2