مثال‌های دسترسی آگاه از متن برای حالت پیشرفته

برای بهبود امنیت دسترسی به برنامه‌هایی که حاوی داده‌های حساس هستند، می‌توانید نحوه احراز هویت کاربر در سیستم را تعیین کنید تا تصمیم بگیرید که آیا به برنامه دسترسی پیدا می‌کند یا خیر.

برای مثال، کاربرانی که فقط با رمز عبور وارد سیستم می‌شوند، فقط می‌توانند به برنامه‌هایی دسترسی داشته باشند که حاوی هیچ اطلاعات حساسی نیستند، در حالی که کاربری که با کلید امنیتی سخت‌افزاری به عنوان عامل دوم وارد سیستم می‌شود، می‌تواند به حساس‌ترین برنامه‌های سازمانی دسترسی داشته باشد.

این سطح دسترسی از ویژگی‌های request.auth برای تأیید ورود کاربران با استفاده از رمز عبور و کلید سخت‌افزاری برای تأیید هویت دو مرحله‌ای استفاده می‌کند و می‌تواند به برنامه‌های حساس دسترسی داشته باشد.

درخواست.auth.claims.crd_str.pwd == درست && درخواست.auth.claims.crd_str.hwk == درست

اغلب مدیران می‌خواهند دسترسی به منابع سازمانی را تنها پس از احراز هویت کاربر با اعتبارنامه‌های قوی اعمال کنند. مثال زیر از سطوح و ویژگی‌های request.auth به شرح زیر استفاده می‌کند:

• اگر کاربر از یک دستگاه شرکتی می‌آید، هر روش MFA، به جز پیامک، کافی خواهد بود (روش‌ها می‌توانند اعلان فوری، کلید امنیتی سخت‌افزاری یا نرم‌افزاری یا رمز عبور یکبار مصرف باشند)
• اگر کاربری از یک دستگاه غیرشرکتی وارد می‌شود، باید از کلید امنیتی سخت‌افزاری یا نرم‌افزاری استفاده کند.

// الزام به MFA پایه (نه پیامک) در دستگاه‌های شرکتی و در صورت عدم نیاز به کلید امنیتی (سخت‌افزار یا نرم‌افزار)
سطوح.Require_Secure_Device &&
(
(
سطوح.Require_Corporate_Device &&
درخواست.auth.claims.crd_str.mfa &&
درخواست.auth.claims.crd_str.sms !
) ||
(
!levels.Require_Corporate_Device &&
(
درخواست.auth.claims.crd_str.hwk || درخواست.auth.claims.crd_str.swk
)
)
)

محدود به برنامه‌های وب دسکتاپ است و برای برنامه‌های تلفن همراه یا APIها قابل استفاده نیست.

شما می‌توانید با الزام به اعتبارنامه‌های جلسه متصل به دستگاه (DBSC)، امنیت دسترسی به برنامه‌هایی که حاوی داده‌های حساس هستند را بهبود بخشید. DBSC جلسه کاربر را هنگام استفاده از مرورگر کروم در ویندوز به دستگاه او متصل می‌کند، که می‌تواند خطر ربودن جلسه را به میزان قابل توجهی کاهش دهد.

این سطح دسترسی از ویژگی request.auth برای تأیید اتصال جلسات کاربر به یک دستگاه خاص استفاده می‌کند. اگر چنین باشد، دسترسی به برنامه اعطا می‌شود. اگر نه (به این معنی که جلسه به DBSC متصل نیست)، دسترسی رد می‌شود.

برای جلوگیری از خطا، DBSC را برای همه حساب‌های کاربری که مشمول این سطح دسترسی هستند، فعال کنید. برای جزئیات بیشتر، به روشن کردن DBSC بروید.

قبل از فعال کردن حالت فعال، سطح دسترسی را روی حالت مانیتور تنظیم کنید. در حالت مانیتور، می‌توانید تأثیر اعمال سطح دسترسی را بدون ایجاد اختلال در دسترسی کاربر آزمایش کنید.

از این عبارت CEL برای ایجاد سطح دسترسی سفارشی خود استفاده کنید:

درخواست.auth.sessionBoundToDevice(origin) == true

از این عبارت CEL برای اعمال DBSC فقط در دستگاه‌های ویندوزی با مرورگر کروم نسخه ۱۳۶ یا بالاتر استفاده کنید:

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

شما می‌توانید از سیگنال‌های دستگاه گزارش‌شده توسط یکی از شرکای BeyondCorp Alliance استفاده کنید. در این مثال، Lookout Software به عنوان برنامه‌ی کاربردی استفاده شده است.

این سطح دسترسی از ویژگی دستگاه برای تأیید اینکه دستگاه مورد استفاده برای دسترسی به Google Workspace توسط Lookout مطابق با خط‌مشی‌ها گزارش شده است، استفاده می‌کند و امتیاز سلامت آن بسیار خوب است.

این سطح دسترسی از ویژگی دستگاه برای تأیید استفاده کاربران از آخرین نسخه مرورگر مدیریت‌شده کروم استفاده می‌کند و فقط از طریق چنین مرورگری امکان دسترسی را فراهم می‌کند.

شما می‌توانید از گواهی‌های سازمانی برای دستگاه‌ها در سطوح دسترسی سفارشی استفاده کنید تا مشخص شود که آیا یک دستگاه متعلق به شرکت است یا خیر. این سطح دسترسی از ویژگی دستگاه برای تأیید دارایی استفاده می‌کند. برای اطلاعات و مثال‌های بیشتر ، پیکربندی شرایط گواهی سازمانی را مطالعه کنید.

یک دستگاه می‌تواند بیش از یک گواهی داشته باشد. گواهی‌های سازمانی در سطح دسترسی سفارشی با استفاده از ماکروی exists() استفاده می‌شوند. برای مثال:

device.certificates.exists(cert, predicate)

در این مثال، cert یک شناسه ساده برای استفاده در متغیر predicate جهت اتصال به گواهی سازمانی دستگاه است. ماکرو exists() نتایج predicate هر عنصر را با عملگر or (||) ترکیب می‌کند. ماکروها در صورتی مقدار true را برمی‌گردانند که حداقل یک certificate، عبارت predicate را برآورده کند.

جدول زیر ویژگی‌هایی را که می‌توانید برای ایجاد عبارات CEL جهت استفاده با سطوح دسترسی سفارشی استفاده کنید، فهرست می‌کند. توجه داشته باشید که مقایسه رشته‌ها به حروف کوچک و بزرگ حساس است.

نمونه‌هایی از سیاست‌های رایج:

تأیید کنید که دستگاه دارای یک گواهی معتبر سازمانی است که توسط گواهی ریشه شرکت امضا شده است

device.certificates.exists(cert، cert.is_valid && cert.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 است.

// رمزگذاری دیسک و فعال بودن قفل صفحه الزامی است
// این در تمام پلتفرم‌های اصلی (ویندوز، مک، لینوکس، CrOS، iOS، اندروید) قابل اجرا است.
// این سطح دسترسی اساسی است و باید توسط تمام سطوح دسترسی دیگر مورد استفاده قرار گیرد.
device.encryption_status == وضعیت رمزگذاری دستگاه. رمزگذاری شده &&
دستگاه.با_قفل_صفحه_امن_شده_است &&
دستگاه.is_admin_approved_device

در این مثال، سطح دسترسی از ویژگی دستگاه برای الزام مرورگر کروم به رعایت الزامات امنیتی اولیه استفاده می‌کند.

// مدیریت کروم در سطح پروفایل یا مرورگر الزامی است، باید داشته باشد
// گزارش رویدادهای امنیتی فعال است و باید نسخه ۹۷ یا بالاتر باشد
سطوح.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 &&
دستگاه.کروم.نسخه حداقل("97")

این مثال از ویژگی دستگاه استفاده می‌کند تا الزام کند که کاربر از یک مرورگر یا نمایه مدیریت‌شده کروم وارد شده باشد و کروم کانکتورهای تهدید و حفاظت از داده‌ها را روشن کرده باشد. این مثال از ویژگی سطوح برای اشاره به سطح دسترسی Require Managed Chrome که قبلاً توضیح داده شد، استفاده می‌کند. مثال زیر فرض می‌کند که سطح دسترسی وابسته Require_Managed_Chrome نام دارد.

// نیاز به کروم مدیریت‌شده (وابسته به سطح دسترسی "Require_Managed_Chrome")
// و نیاز به بازرسی محتوا برای دانلودها و همچنین فعال بودن بررسی URL
levels.Require_Managed_Chrome &&
دستگاه.کروم.is_file_download_analysis_enabled &&
دستگاه.کروم.is_realtime_url_check_enabled

یکی از الزامات کنترل دسترسی، اجازه دسترسی فقط به دستگاه‌هایی است که توسط شرکت مدیریت یا متعلق به آن هستند. روش‌های زیادی برای تعیین اینکه آیا یک دستگاه متعلق به شرکت است یا توسط آن مدیریت می‌شود، وجود دارد، از جمله:

• اگر شماره سریال دستگاهی با شماره سریال موجود در سیستم مدیریت دارایی شرکت مطابقت داشته باشد
• اگر دستگاهی دارای گواهی معتبر سازمانی صادر شده توسط شرکت باشد

این دو رویکرد را می‌توان در سطح دسترسی سفارشی زیر استفاده کرد که از سطوح و ویژگی‌های دستگاه برای تعیین اینکه آیا دستگاه متعلق به شرکت است یا مدیریت می‌شود، استفاده می‌کند.

// اگر یکی از شرایط زیر برقرار باشد، دستگاه شرکتی است:
// ۱. اگر شماره سریال با آنچه مدیر آپلود کرده است مطابقت داشته باشد
// ۲. اگر دستگاه دارای گواهی معتبر صادر شده توسط سازمان باشد
سطوح.Require_Secure_Device &&
(
دستگاه.is_corp_owned_device ||
device.certificates.exists(cert، cert.is_valid && cert.root_ca_fingerprint == "SOME_ROOT_CA_FINGERPRINT")
)

اثر انگشت، خلاصه SHA256 رمزگذاری شده با base64 و بدون پد (در قالب دودویی) از گواهی رمزگذاری شده با DER است. رشته را می‌توان با استفاده از روش زیر با 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)

سطح دسترسی از ویژگی دستگاه برای اطمینان از به‌روز بودن داده‌های CrowdStrike استفاده می‌کند. توجه داشته باشید که Chrome Enterprise Premium دارای تأخیر ذاتی ۹۰ دقیقه‌ای برای مصرف هرگونه ارزیابی جدید از Falcon ZTA است، بنابراین استفاده از مدت زمان کمتر از یک ساعت توصیه نمی‌شود.

// اطمینان حاصل کنید که یکی از این شرایط برای داده‌های Crowdstrike صادق است:
// باید یکی از این شرایط را داشته باشد
// ۱. دستگاه در آخرین روز ارزیابی شد
// 2. مهلت ارزیابی منقضی نشده است (2 هفته از آخرین مهلت ارزیابی گذشته است)
"CrowdStrike" در 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 ادغام شده‌اند و دستگاه را سازگار می‌دانند یا خیر.

ماکروی exist عبارت مربوط به هر یک از شرکای BeyondCorp Alliance را با یک عملگر || (یا) بسط می‌دهد.

// بررسی کنید که آیا هیچ یک از شرکای BCA دستگاه را سازگار می‌دانند یا خیر
["CrowdStrike"، "Tanium"، "PANW"، "Check Point"، "Lookout"].exists(
v، v در device.vendors && device.vendors[v].is_compliant_device
)

این مثال از ویژگی‌های دستگاه استفاده می‌کند تا اطمینان حاصل شود که دستگاه‌ها نسخه امنی از اندروید را اجرا می‌کنند.

بوت تأیید شده بررسی می‌کند که آیا کد اجرا شده از یک منبع قابل اعتماد (معمولاً تولیدکنندگان اصلی دستگاه) آمده است یا خیر، نه از یک مهاجم یا خرابی. برای جزئیات بیشتر، به بوت تأیید شده مراجعه کنید.

// وضعیت بوت تأیید شده اندروید سبز را الزامی کنید
device.android_device_security.verified_boot == درست

این مثال از ویژگی‌های دستگاه برای الزام دستگاه‌ها به گذراندن بررسی‌های انطباق مجموعه تست سازگاری (CTS) استفاده می‌کند. برای جزئیات بیشتر، به مجموعه تست سازگاری مراجعه کنید.

// الزام دستگاه‌ها به گذراندن آزمون‌های انطباق با CTS
device.android_device_security.cts_profile_match == درست

این مثال از ویژگی‌های دستگاه استفاده می‌کند تا دستگاه‌هایی را ملزم به فعال بودن Google Play Protect Verify Apps کند.

تأیید برنامه‌ها، برنامه‌ها را برای یافتن تهدیدات هنگام نصب از منابعی غیر از Google Play اسکن می‌کند. همچنین به صورت دوره‌ای دستگاه‌ها را برای یافتن برنامه‌های بالقوه مضر اسکن می‌کند. تأیید برنامه‌ها به طور پیش‌فرض فعال است. برای دستگاه‌های تحت مدیریت پیشرفته، می‌توانید مشخص کنید که آیا کاربران می‌توانند آن را خاموش کنند یا خیر. برای اطلاعات بیشتر، به اعمال تنظیمات برای دستگاه‌های تلفن همراه Android مراجعه کنید.

// فعال بودن Google Play Protect برای تأیید برنامه‌ها در دستگاه‌ها الزامی است
device.android_device_security.verify_apps_enabled == درست

این مثال از ویژگی‌های دستگاه برای جلوگیری از دسترسی به دستگاه‌هایی که برنامه‌های بالقوه مضر دارند استفاده می‌کند. این برنامه‌ها اغلب بدافزار نامیده می‌شوند. برای جزئیات بیشتر، به برنامه‌های بالقوه مضر (PHA) مراجعه کنید.

// دسترسی به دستگاه‌هایی که برنامه‌های مضر دارند را مسدود کنandroid_device_security.has_potentially_harmful_apps != true

شرکت‌ها می‌خواهند مطمئن شوند که کارکنان شیفتی‌شان فقط می‌توانند در ساعات شیفت خود به منابع سازمانی دسترسی داشته باشند. سطوح دسترسی زیر از ویژگی levels برای تعریف ۳ شیفت در طول دوشنبه تا جمعه استفاده می‌کنند.

// شیفت ۱ - دوشنبه تا جمعه، نیمه شب تا ۸ صبح
سطوح.Require_Secure_Device &&
request.time.getDayOfWeek("آمریکا/لس‌آنجلس") >= 1 &&
request.time.getDayOfWeek("آمریکا/لس‌آنجلس") <= 5 &&
request.time.timeOfDay("آمریکا/لس‌آنجلس").between('۰۰:۰۰:۰۰', '۰۸:۰۰:۰۰')

// شیفت ۲ - دوشنبه تا جمعه، ۸ صبح تا ۴ بعد از ظهر
سطوح.Require_Secure_Device &&
request.time.getDayOfWeek("آمریکا/لس‌آنجلس") >= 1 &&
request.time.getDayOfWeek("آمریکا/لس‌آنجلس") <= 5 &&
request.time.timeOfDay("آمریکا/لس‌آنجلس").between('08:00:00', '16:00:00')

// شیفت ۳ - دوشنبه تا جمعه، ۴ بعد از ظهر تا نیمه شب
سطوح.Require_Secure_Device &&
request.time.getDayOfWeek("آمریکا/لس‌آنجلس") >= 1 &&
request.time.getDayOfWeek("آمریکا/لس‌آنجلس") <= 5 &&
request.time.timeOfDay("آمریکا/لس‌آنجلس").between('16:00:00', '00:00:00')

// به کارگران شیفتی اجازه دهید از دوشنبه تا جمعه، بین ساعت ۹ صبح تا ۵ بعد از ظهر، به جز چهارم جولای، به منابع دسترسی داشته باشند.
سطوح.Require_Secure_Device &&
request.time.getDayOfWeek("آمریکا/لس‌آنجلس") >= 1 &&
request.time.getDayOfWeek("آمریکا/لس‌آنجلس") <= 5 &&
!(
request.time.getMonth("آمریکا/لس‌آنجلس") == 6 &&
request.time.getDayOfMonth("آمریکا/لس‌آنجلس") == 3
) &&
request.time.timeOfDay("آمریکا/لس‌آنجلس").between('09:30:00', '17:00:00')

شرکت‌ها گاهی اوقات می‌خواهند در مواقع اضطراری، زمانی که مدیر به دستگاه امن دسترسی ندارد اما برای مدت کوتاهی به دسترسی اضطراری نیاز دارد، اجازه دسترسی با شکستن شیشه را بدهند.

در این حالت، با استفاده از ویژگی levels ، یک سطح دسترسی با محدودیت زمانی و مکانی ایجاد کنید و آن را به مدیر مربوطه اختصاص دهید. وقتی این سطح دسترسی اختصاص داده می‌شود، فقط در مدت زمان مشخص شده معتبر خواهد بود. پس از انقضای این دوره زمانی، دسترسی مدیر دوباره با الزامات موجود کنترل می‌شود.

// اجازه دسترسی موقت به منابع در ۱ مارس ۲۰۲۲، بین ساعت ۱۰ شب تا نیمه‌شب،
// و این دسترسی باید از داخل منطقه ایالات متحده باشد.
سطوح.Require_Secure_Device &&
درخواست.زمان.بین('2022-03-01T23:00:00+08:00', '2022-03-02T23:59:59+08:00') &&
origin.region_code == "ایالات متحده"
// توجه داشته باشید که زمان پایان انحصاری است، بنابراین عبارت بالا به طور بالقوه ۲ ثانیه دارد
// ممکن است کاربران دسترسی نداشته باشند. گزینه دیگر استفاده از این است
// !between('۰۰:۰۰:۰۱','۱۶:۰۰:۰۰')

این سطح دسترسی از ویژگی‌های levels استفاده می‌کند و مستلزم آن است که کاربران شرایط ترکیبی دو سطح دسترسی را داشته باشند. در این مثال، access_level_name_1 و access_level_name_2 به Internal Name اشاره دارند.

نام_سطح_دسترسی_۱ و نام_سطح_دسترسی_۲