উন্নত মোডের জন্য কনটেক্সট-অ্যাওয়ার অ্যাক্সেসের উদাহরণ

সংবেদনশীল তথ্য ধারণকারী অ্যাপ্লিকেশনগুলিতে অ্যাক্সেসের নিরাপত্তা উন্নত করতে, ব্যবহারকারী সিস্টেমে কীভাবে প্রমাণীকরণ করেছেন তা নির্ধারণ করে তিনি অ্যাপ্লিকেশনটিতে অ্যাক্সেস পাবেন কিনা তা স্থির করা যায়।

উদাহরণস্বরূপ, শুধুমাত্র পাসওয়ার্ড দিয়ে লগ ইন করা ব্যবহারকারীদের কেবল সেইসব অ্যাপ্লিকেশন অ্যাক্সেস করার অনুমতি দেওয়া যেতে পারে যেগুলিতে কোনও সংবেদনশীল তথ্য নেই, অন্যদিকে দ্বিতীয় ধাপ হিসেবে হার্ডওয়্যার সিকিউরিটি কী দিয়ে লগ ইন করা একজন ব্যবহারকারীকে সবচেয়ে সংবেদনশীল এন্টারপ্রাইজ অ্যাপ্লিকেশনগুলি অ্যাক্সেস করার অনুমতি দেওয়া যেতে পারে।

এই অ্যাক্সেস লেভেলটি request.auth অ্যাট্রিবিউট ব্যবহার করে যাচাই করে যে, ব্যবহারকারীরা টু-স্টেপ ভেরিফিকেশনের জন্য পাসওয়ার্ড ও হার্ডওয়্যার কী উভয়টি ব্যবহার করে লগ ইন করেন এবং সংবেদনশীল অ্যাপ্লিকেশনগুলো অ্যাক্সেস করতে পারেন।

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

প্রায়শই প্রশাসকরা চান যে ব্যবহারকারী শক্তিশালী ক্রেডেনশিয়াল দিয়ে প্রমাণীকরণের পরেই যেন কর্পোরেট রিসোর্সে অ্যাক্সেস নিশ্চিত করা হয়। নিম্নলিখিত উদাহরণে levels এবং request.auth অ্যাট্রিবিউটগুলো যেভাবে ব্যবহার করা হয়েছে তা হলো:

• যদি কোনো ব্যবহারকারী কর্পোরেট ডিভাইস থেকে আসেন, তাহলে এসএমএস ছাড়া যেকোনো এমএফএ পদ্ধতিই যথেষ্ট হবে (পদ্ধতিগুলো হতে পারে পুশ নোটিফিকেশন, হার্ডওয়্যার বা সফটওয়্যার সিকিউরিটি কী, অথবা ওয়ান টাইম পাসওয়ার্ড)।
• If a user is coming from a non-corporate device, then either a hardware or software security key must be used

কর্পোরেট ডিভাইসগুলিতে বেসিক এমএফএ (এসএমএস নয়) এবং অন্যথায় সিকিউরিটি কী (হার্ডওয়্যার বা সফ্টওয়্যার) প্রয়োজন।
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
)
)
)

শুধুমাত্র ডেস্কটপ ওয়েব অ্যাপের জন্য সীমাবদ্ধ এবং মোবাইল অ্যাপ বা এপিআই-এর ক্ষেত্রে প্রযোজ্য নয়।

ডিভাইস বাউন্ড সেশন ক্রেডেনশিয়ালস (DBSC) বাধ্যতামূলক করার মাধ্যমে আপনি সংবেদনশীল ডেটা ধারণকারী অ্যাপগুলিতে অ্যাক্সেসের নিরাপত্তা উন্নত করতে পারেন। যখন কোনো ব্যবহারকারী উইন্ডোজে ক্রোম ব্রাউজার ব্যবহার করেন, তখন DBSC তার সেশনকে ডিভাইসের সাথে সংযুক্ত করে, যা সেশন হাইজ্যাকিংয়ের ঝুঁকি উল্লেখযোগ্যভাবে কমাতে পারে।

This access level uses the request.auth attribute to verify that the user's sessions are bound to a specific device. If it is, access is granted to the app. If not (meaning the session isn't DBSC-bound), access is denied.

ত্রুটি এড়াতে, এই অ্যাক্সেস লেভেলের অধীনস্থ সকল ইউজার অ্যাকাউন্টের জন্য DBSC চালু করুন। বিস্তারিত জানতে, “Turn on DBSC” অংশে যান।

অ্যাক্টিভ মোড চালু করার আগে অ্যাক্সেস লেভেলটি মনিটর মোডে সেট করুন। মনিটর মোডে, আপনি ব্যবহারকারীর অ্যাক্সেসে কোনো ব্যাঘাত না ঘটিয়ে অ্যাক্সেস-লেভেল প্রয়োগের প্রভাব পরীক্ষা করতে পারেন।

আপনার নিজস্ব অ্যাক্সেস লেভেল তৈরি করতে এই CEL এক্সপ্রেশনটি ব্যবহার করুন:

request.auth.sessionBoundToDevice(origin) == true

শুধুমাত্র ক্রোম ব্রাউজার সংস্করণ ১৩৬ বা তার পরবর্তী সংস্করণযুক্ত উইন্ডোজ ডিভাইসগুলিতে DBSC কার্যকর করতে এই CEL এক্সপ্রেশনটি ব্যবহার করুন:

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

আপনি বিয়ন্ডকর্প অ্যালায়েন্স পার্টনার কর্তৃক রিপোর্ট করা ডিভাইস সিগন্যাল ব্যবহার করতে পারেন। এই উদাহরণে, অ্যাপ্লিকেশন হিসেবে লুকআউট সফটওয়্যার ব্যবহার করা হয়েছে।

এই অ্যাক্সেস লেভেলটি ডিভাইস অ্যাট্রিবিউট ব্যবহার করে যাচাই করে যে, গুগল ওয়ার্কস্পেস অ্যাক্সেস করতে ব্যবহৃত ডিভাইসটি লুকআউটের রিপোর্ট অনুযায়ী পলিসি মেনে চলে এবং এর হেলথ স্কোর ‘ভেরি গুড’।

এই অ্যাক্সেস লেভেলটি ডিভাইস অ্যাট্রিবিউট ব্যবহার করে যাচাই করে যে ব্যবহারকারীরা একটি ম্যানেজড ক্রোম ব্রাউজারের সর্বশেষ সংস্করণ ব্যবহার করছেন কিনা, এবং শুধুমাত্র সেই ব্রাউজারের মাধ্যমেই অ্যাক্সেসের অনুমতি দেয়।

কোনো ডিভাইস কর্পোরেট-মালিকানাধীন সম্পদ কিনা তা নির্ধারণ করতে, আপনি কাস্টম অ্যাক্সেস লেভেলের ডিভাইসগুলির জন্য এন্টারপ্রাইজ সার্টিফিকেট ব্যবহার করতে পারেন। এই অ্যাক্সেস লেভেলটি সম্পদ যাচাইয়ের জন্য ডিভাইস অ্যাট্রিবিউট ব্যবহার করে। আরও তথ্য এবং উদাহরণের জন্য ‘এন্টারপ্রাইজ সার্টিফিকেট শর্তাবলী কনফিগার করা’ পড়ুন।

একটি ডিভাইসের একাধিক সার্টিফিকেট থাকতে পারে। exists() ম্যাক্রো ব্যবহার করে একটি কাস্টম অ্যাক্সেস লেভেলে এন্টারপ্রাইজ সার্টিফিকেট ব্যবহার করা হয়। উদাহরণস্বরূপ:

device.certificates.exists(cert, predicate)

In this example, cert is a simple identifier to use in the variable predicate to bind to the device enterprise certificate. The exists() macro combines per-element predicate results with the or (||) operator. Macros return true if at least one certificate satisfies the predicate expression.

নিচের টেবিলে এমন অ্যাট্রিবিউটগুলোর তালিকা দেওয়া হলো যা ব্যবহার করে কাস্টম অ্যাক্সেস লেভেলের জন্য CEL এক্সপ্রেশন তৈরি করা যায়। উল্লেখ্য যে, স্ট্রিং তুলনা কেস-সেনসিটিভ।

Examples of commonly-used policies:

যাচাই করুন যে ডিভাইসটিতে কোম্পানির রুট সার্টিফিকেট দ্বারা স্বাক্ষরিত একটি বৈধ এন্টারপ্রাইজ সার্টিফিকেট রয়েছে।

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

This example uses the device attribute to require both disk encryption and screen lock to be enabled. In addition, the device has to be approved by administrators.

ডিফল্টরূপে, এন্ডপয়েন্ট ভেরিফিকেশন দ্বারা তৈরি সমস্ত ডিভাইস অনুমোদিত থাকে। তবে, এমন কিছু পরিস্থিতি থাকতে পারে যেখানে আপনি কোনো ডিভাইস ব্লক করতে চাইতে পারেন, যেমন ডিভাইসটি হারিয়ে গেলে। এই ধরনের ক্ষেত্রে আপনি চাইবেন না যে এই ডিভাইসগুলো কর্পোরেট রিসোর্স অ্যাক্সেস করতে পারুক।

এই নথিতে থাকা অন্যান্য অ্যাক্সেস লেভেলের উদাহরণগুলোর ক্ষেত্রে, ধরে নিন যে এই অ্যাক্সেস লেভেলটির নাম Require_Secure_Device ।

ডিস্ক এনক্রিপশন এবং স্ক্রিন লক সক্রিয় থাকা আবশ্যক।
এটি সকল প্রধান প্ল্যাটফর্মে (উইন্ডোজ, ম্যাক, লিনাক্স, ক্রোমওএস, আইওএস, অ্যান্ড্রয়েড) প্রযোজ্য।
এটি একটি ভিত্তি এবং অন্যান্য সকল প্রবেশাধিকার স্তর এর উপর নির্ভরশীল হওয়া উচিত।
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
device.is_secured_with_screenlock &&
device.is_admin_approved_device

এই উদাহরণে, অ্যাক্সেস লেভেলটি ডিভাইস অ্যাট্রিবিউট ব্যবহার করে মৌলিক নিরাপত্তা প্রয়োজনীয়তাসহ ক্রোম ব্রাউজারকে বাধ্যতামূলক করে।

// ক্রোমকে প্রোফাইল বা ব্রাউজার স্তরে পরিচালনা করতে হবে, অবশ্যই থাকতে হবে
নিরাপত্তা ইভেন্ট রিপোর্টিং সক্রিয় করা হয়েছে এবং এর সংস্করণ অবশ্যই ৯৭ বা তার বেশি হতে হবে।
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` অ্যাট্রিবিউট ব্যবহার করে এটি আবশ্যক করা হয়েছে যে, ব্যবহারকারীকে অবশ্যই একটি ম্যানেজড ক্রোম ব্রাউজার বা প্রোফাইল থেকে আসতে হবে এবং ক্রোমের থ্রেট ও ডেটা প্রোটেকশন কানেক্টরগুলো চালু থাকতে হবে। উদাহরণটিতে পূর্বে বর্ণিত `Require Managed Chrome` অ্যাক্সেস লেভেলটিকে নির্দেশ করার জন্য ` levels` অ্যাট্রিবিউট ব্যবহার করা হয়েছে। নিম্নলিখিত উদাহরণটি ধরে নেয় যে, নির্ভরশীল অ্যাক্সেস লেভেলটির নাম `Require_Managed_Chrome` ।

// পরিচালিত ক্রোম প্রয়োজন ("Require_Managed_Chrome" অ্যাক্সেস স্তরের উপর নির্ভরশীল)
এবং ডাউনলোডের জন্য কন্টেন্ট পরিদর্শন ও ইউআরএল চেক সক্রিয় থাকা আবশ্যক।
levels.Require_Managed_Chrome &&
device.chrome.is_file_download_analysis_enabled &&
device.chrome.is_realtime_url_check_enabled

অ্যাক্সেস নিয়ন্ত্রণের একটি শর্ত হলো, ডিভাইসটি কোম্পানির দ্বারা পরিচালিত বা মালিকানাধীন হলেই কেবল অ্যাক্সেসের অনুমতি দেওয়া। কোনো ডিভাইস কর্পোরেট মালিকানাধীন বা পরিচালিত কিনা তা নির্ধারণ করার অনেক উপায় রয়েছে, যার মধ্যে অন্তর্ভুক্ত হলো:

• যদি কোনো ডিভাইসের সিরিয়াল নম্বর কোম্পানির অ্যাসেট ম্যানেজমেন্ট সিস্টেমে থাকা কোনো সিরিয়াল নম্বরের সাথে মিলে যায়
• যদি কোনো ডিভাইসে কোম্পানি কর্তৃক ইস্যুকৃত একটি বৈধ এন্টারপ্রাইজ সার্টিফিকেট থাকে

এই দুটি পদ্ধতি নিম্নলিখিত কাস্টম অ্যাক্সেস লেভেলে ব্যবহার করা যেতে পারে, যা ডিভাইসটি কর্পোরেট-মালিকানাধীন নাকি পরিচালিত তা নির্ধারণ করতে লেভেল এবং ডিভাইস অ্যাট্রিবিউট ব্যবহার করে।

ডিভাইসটি কর্পোরেট হবে যদি নিম্নলিখিত শর্তগুলির মধ্যে একটি সত্য হয়:
// ১. যদি সিরিয়াল নম্বরটি অ্যাডমিনের আপলোড করা তথ্যের সাথে মিলে যায়
// ২. যদি ডিভাইসটিতে একটি বৈধ প্রতিষ্ঠান-প্রদত্ত সার্টিফিকেট থাকে
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-এনকোডেড সার্টিফিকেটের আনপ্যাডেড বেস৬৪-এনকোডেড 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

• Issued at timestamp (iat)
• Expiry timestamp (exp)

CrowdStrike ডেটা যাতে সতেজ থাকে, তা নিশ্চিত করতে অ্যাক্সেস লেভেলটি ডিভাইস অ্যাট্রিবিউট ব্যবহার করে। উল্লেখ্য যে, Falcon ZTA থেকে যেকোনো নতুন অ্যাসেসমেন্ট গ্রহণ করার ক্ষেত্রে Chrome Enterprise Premium-এর একটি সহজাত ৯০ মিনিটের বিলম্ব রয়েছে, তাই এক ঘণ্টার কম সময়কাল ব্যবহার করা অনুচিত।

// Crowdstrike থেকে প্রাপ্ত ডেটার জন্য এই শর্তগুলোর মধ্যে একটি সত্য হওয়া নিশ্চিত করুন:
// Must meet one of these conditions
// 1. Device was assessed within the last day
// ২. অ্যাসেসমেন্টের মেয়াদ শেষ হয়নি (শেষ আইএটি-এর পর ২ সপ্তাহ অতিবাহিত হয়েছে)
"CrowdStrike" in device.vendors && (
request.time - timestamp(device.vendors["CrowdStrike"].data["iat"]) < duration("1d") ||
timestamp(device.vendors["CrowdStrike"].data["exp"]) - request.time > duration("0m")
)

ক্রোম এন্টারপ্রাইজ প্রিমিয়াম, বিয়ন্ডকর্প অ্যালায়েন্সের অনেক ইকোসিস্টেম পার্টনারদের সাথে তাদের ডিভাইসের সিগন্যাল এবং কনটেক্সটকে ক্রোম এন্টারপ্রাইজ প্রিমিয়াম সলিউশনে একীভূত করতে কাজ করে। পার্টনাররা ক্রোম এন্টারপ্রাইজ প্রিমিয়ামের সাথে যেকোনো সংখ্যক অ্যাট্রিবিউট শেয়ার করতে পারে, এবং সেগুলোর মধ্যে একটি হলো is_compliant_device অ্যাট্রিবিউট। নিচের উদাহরণটিতে ডিভাইস অ্যাট্রিবিউট ব্যবহার করে দেখানো হয়েছে যে, কীভাবে আমরা পরীক্ষা করতে পারি বিয়ন্ডকর্প অ্যালায়েন্সের কোনো পার্টনার ক্রোম এন্টারপ্রাইজ প্রিমিয়ামের সাথে ইন্টিগ্রেট করেছে কিনা এবং ডিভাইসটিকে কমপ্লায়েন্ট হিসেবে বিবেচনা করতে পারি।

exists ম্যাক্রোটি BeyondCorp Alliance-এর প্রতিটি অংশীদারের জন্য এক্সপ্রেশনটিকে একটি || (অথবা) অপারেটরের মাধ্যমে প্রসারিত করে।

BCA অংশীদারদের মধ্যে কেউ ডিভাইসটিকে সঙ্গতিপূর্ণ বলে মনে করে কিনা তা যাচাই করুন।
["CrowdStrike", "Tanium", "PANW", "Check Point", "Lookout"].exists(
v, v in device.vendors && device.vendors[v].is_compliant_device
)

This example uses device attributes to ensure that devices are running a safe version of Android.

ভেরিফাইড বুট যাচাই করে দেখে যে, এক্সিকিউট করা কোডটি কোনো আক্রমণকারী বা ত্রুটির কারণে নয়, বরং একটি বিশ্বস্ত উৎস (সাধারণত ডিভাইস প্রস্তুতকারক) থেকে এসেছে কি না। বিস্তারিত জানতে, ভেরিফাইড বুট দেখুন।

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

এই উদাহরণে, ডিভাইসগুলোকে কম্প্যাটিবিলিটি টেস্ট স্যুট (CTS) কমপ্লায়েন্স চেক পাস করার জন্য ডিভাইস অ্যাট্রিবিউট ব্যবহার করা হয়েছে। বিস্তারিত জানতে, কম্প্যাটিবিলিটি টেস্ট স্যুট- এ যান।

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

এই উদাহরণটিতে ডিভাইস অ্যাট্রিবিউট ব্যবহার করে ডিভাইসগুলোতে Google Play Protect Verify Apps চালু থাকা বাধ্যতামূলক করা হয়েছে।

Google Play ছাড়া অন্য কোনো উৎস থেকে অ্যাপ ইনস্টল করা হলে, Verify Apps সেগুলোকে হুমকির জন্য স্ক্যান করে। এটি নির্দিষ্ট সময় অন্তর ডিভাইসগুলোকেও সম্ভাব্য ক্ষতিকর অ্যাপের জন্য স্ক্যান করে। Verify Apps ডিফল্টভাবে চালু থাকে। অ্যাডভান্সড ম্যানেজমেন্টের অধীনে থাকা ডিভাইসগুলোর জন্য, ব্যবহারকারীরা এটি বন্ধ করতে পারবে কিনা তা আপনি নির্দিষ্ট করে দিতে পারেন। আরও তথ্যের জন্য, ‘অ্যান্ড্রয়েড মোবাইল ডিভাইসের জন্য সেটিংস প্রয়োগ করুন ’ দেখুন।

ডিভাইসগুলিতে Google Play Protect Verify Apps সক্রিয় থাকা আবশ্যক।
device.android_device_security.verify_apps_enabled == true

এই উদাহরণটি ডিভাইস অ্যাট্রিবিউট ব্যবহার করে সেইসব ডিভাইসকে অ্যাক্সেস করতে বাধা দেয়, যেগুলিতে সম্ভাব্য ক্ষতিকারক অ্যাপ রয়েছে। এই অ্যাপগুলিকে প্রায়শই ম্যালওয়্যার বলা হয়। বিস্তারিত জানতে, সম্ভাব্য ক্ষতিকারক অ্যাপ্লিকেশন (PHAs) দেখুন।

// সম্ভাব্য ক্ষতিকর অ্যাপ আছে এমন ডিভাইসগুলিতে অ্যাক্সেস অস্বীকার করুন android_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')

// ৪ঠা জুলাই ব্যতীত, সোমবার থেকে শুক্রবার সকাল ৯টা থেকে বিকাল ৫টার মধ্যে শিফট কর্মীদের বিভিন্ন সুযোগ-সুবিধা ব্যবহারের অনুমতি দেওয়া হবে।
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 অ্যাট্রিবিউট ব্যবহার করে একটি সময় ও স্থান-সীমাবদ্ধ অ্যাক্সেস লেভেল তৈরি করুন এবং নির্দিষ্ট অ্যাডমিনিস্ট্রেটরকে তা বরাদ্দ করুন। যখন এই অ্যাক্সেস লেভেলটি বরাদ্দ করা হবে, তখন এটি শুধুমাত্র নির্দিষ্ট সময়কালের জন্য বৈধ থাকবে। এই সময়কাল শেষ হয়ে গেলে, অ্যাডমিনিস্ট্রেটরের অ্যাক্সেস পুনরায় বিদ্যমান প্রয়োজনীয়তা দ্বারা নিয়ন্ত্রিত হবে।

// ১ মার্চ, ২০২২ তারিখে রাত ১০টা থেকে মধ্যরাতের মধ্যে রিসোর্সসমূহে অস্থায়ী প্রবেশাধিকার দেওয়া হবে।
এবং এই অ্যাক্সেস অবশ্যই মার্কিন যুক্তরাষ্ট্র অঞ্চলের ভেতর থেকে আসতে হবে।
levels.Require_Secure_Device &&
অনুরোধের সময় '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')

এই অ্যাক্সেস লেভেলটি levels অ্যাট্রিবিউট ব্যবহার করে, এবং এর জন্য ব্যবহারকারীদের দুটি অ্যাক্সেস লেভেলের সম্মিলিত শর্ত পূরণ করতে হয়। এই উদাহরণে, access_level_name_1 এবং access_level_name_2 বলতে Internal Name- কে বোঝানো হয়েছে।

levels.access_level_name_1 && levels.access_level_name_2