This article describes common use cases for Context-Aware Access and includes sample configurations developed in Basic mode.
For examples of access levels developed in Advanced mode (using the CEL editor), go to Context-Aware Access examples for Advanced mode .
Allow access to contractors only through the corporate network
অনেক কোম্পানি কর্পোরেট রিসোর্সে কন্ট্রাক্টরদের অ্যাক্সেস সীমিত করতে চায়। উদাহরণস্বরূপ, যেসব কোম্পানি সাধারণ সাপোর্ট কলের উত্তর দিতে বা হেল্প সেন্টার ও কল সেন্টারে কাজ করার জন্য কন্ট্রাক্টরদের ব্যবহার করে। পূর্ণ-সময়ের কর্মীদের মতোই, কন্ট্রাক্টরদেরও কনটেক্সট-অ্যাওয়্যার অ্যাক্সেস পলিসির আওতায় থাকার জন্য একটি সমর্থিত লাইসেন্স থাকতে হবে।
In this example, contractors get access to corporate resources only from a specific corporate IP address range.
| Access level name | contractor_access |
| A contractor gets access if they | Meet attributes |
| Condition 1 attribute | IP subnet (Public) 74.125.192.0/18 |
| Access level assignment | Organizational units for contractors All apps contractors use |
Block access from known hijacker IP addresses
To protect company resources from being compromised, many companies block access to known high-risk sources.
এই উদাহরণে, 74.125.195.105 আইপি অ্যাড্রেসটি ব্লক করা হয়েছে। ব্যবহারকারীরা কর্পোরেট রিসোর্স অ্যাক্সেস করতে পারেন যদি তাদের সেশন অন্য কোনো আইপি অ্যাড্রেস থেকে শুরু হয়। আপনি একাধিক আইপি অ্যাড্রেস এবং রেঞ্জ নির্দিষ্ট করতে পারেন।
| অ্যাক্সেস স্তরের নাম | block_highrisk |
| A user gets access if they | Don't meet attributes |
| Condition 1 attribute | IP subnet (Public) 74.125.195.105 |
| Access level assignment | Top-level organizational unit সমস্ত অ্যাপ |
Allow access from a specific private network in Google Cloud
Many companies route user traffic to Google through a Virtual Private Cloud (VPC). A VPC is a secure, isolated network within the Google Cloud environment.
Be aware that traffic that's routed through your VPC might use private IP addresses. This can cause issues with public IP or region policies.
In this example, you can allow traffic from these specific VPCs.
| Access level name | vpc_access |
| A user gets access if they... | Meet attributes |
| Condition 1 attributes | IP subnet (Private) Private IP Subnetwork: //compute.googleapis.com/projects/project- name-test/global/networks/network-name VPC subnet: 74.125.192.0/18 |
| Access level assignment | Organizational units for all users All apps contractors use |
মনে রাখার মতো গুরুত্বপূর্ণ বিষয়গুলো:
- শুধুমাত্র সরাসরি ট্র্যাফিক : এই অ্যাক্সেস লেভেলটি কেবল সেইসব ট্র্যাফিকের জন্য কাজ করে যা অনুমোদিত VPC থেকে সরাসরি Google-এর সার্ভারে পৌঁছায়। যদি ট্র্যাফিক প্রথমে অন্য কোনো নেটওয়ার্ক বা টানেলের মধ্য দিয়ে যায়, তবে অ্যাক্সেস দেওয়া হয় না। Google শুধুমাত্র সেই সর্বশেষ VPC-টিকেই শনাক্ত করে যা তার সার্ভারে ট্র্যাফিক পাঠায়।
- অ্যাডমিন অনুমতি : VPC দেখতে এবং এই অ্যাক্সেস লেভেল কনফিগার করতে, অ্যাডমিনদের অবশ্যই উপযুক্ত আইডেন্টিটি অ্যান্ড অ্যাক্সেস ম্যানেজমেন্ট (IAM) রোল থাকতে হবে (উদাহরণস্বরূপ, compute.networks.list , compute.subnetworks.list , ইত্যাদি)।
- External VPCs : The VPC you allowlist can be from outside your current Google Cloud domain. An admin must have view permission to add the external VPC.
Allow or disallow access from specific locations
If you have employees who regularly travel to remote corporate or partner offices, you can specify the geographical locations where they can access corporate resources.
উদাহরণস্বরূপ, যদি একদল বিক্রয়কর্মী নিয়মিত অস্ট্রেলিয়া এবং ভারতে গ্রাহকদের সাথে দেখা করেন, তবে আপনি সেই দলের জন্য তাদের প্রধান কার্যালয় এবং অস্ট্রেলিয়া ও ভারতে প্রবেশাধিকার সীমিত করতে পারেন। যদি তারা ব্যবসায়িক সফরের অংশ হিসেবে ব্যক্তিগত ছুটিতে অন্য দেশে ভ্রমণ করেন, তবে তারা সেইসব দেশের কর্পোরেট রিসোর্স ব্যবহার করতে পারবেন না।
In this example, the sales group can access corporate resources only from the US (home office), Australia, and India.
| Access level name | sales_access |
| Sales gets access if they | Meet attributes |
| Condition 1 attribute | ভৌগোলিক উৎপত্তি US, Australia, India |
| Access level assignment | Group of salespeople All apps salespeople use |
আপনি নির্দিষ্ট কিছু দেশ থেকে প্রবেশাধিকার অস্বীকার করার জন্য একটি নীতিও তৈরি করতে পারেন, যেখানে উল্লেখ থাকবে যে ব্যবহারকারীরা শর্ত পূরণ না করলে প্রবেশাধিকার পাবে। আপনি যে দেশগুলো থেকে প্রবেশাধিকার আটকাতে চান, সেগুলোর একটি তালিকা তৈরি করবেন।
Use nested access levels instead of selecting multiple access levels during assignment
কিছু ক্ষেত্রে, যখন আপনি কোনো নির্দিষ্ট সাংগঠনিক ইউনিট বা গ্রুপ এবং একটি অ্যাপ্লিকেশন (বা একাধিক অ্যাপ্লিকেশন)-কে অ্যাক্সেস লেভেল নির্ধারণ করার চেষ্টা করেন, তখন আপনি একটি ত্রুটির বার্তা দেখতে পারেন, যেখানে অ্যাপ্লিকেশন বা অ্যাক্সেস লেভেলের সংখ্যা কমানোর জন্য বলা হয়।
এই ত্রুটি এড়াতে, আপনি অ্যাসাইনমেন্টের সময় ব্যবহৃত অ্যাক্সেস লেভেলগুলোকে একটি একক অ্যাক্সেস লেভেলে নেস্ট করে তাদের সংখ্যা কমাতে পারেন। নেস্টেড অ্যাক্সেস লেভেলটি একটি OR অপারেশনের মাধ্যমে একাধিক শর্তকে যুক্ত করে, যেখানে প্রতিটি শর্তের মধ্যে একটি স্বতন্ত্র অ্যাক্সেস লেভেল থাকে।
এই উদাহরণে, USWest, USEast, এবং USCentral তিনটি আলাদা অ্যাক্সেস লেভেলে রয়েছে। ধরা যাক, আপনি চান ব্যবহারকারীরা যেন USWest অথবা USEast অথবা USCentral-এর যেকোনো একটি অ্যাক্সেস লেভেল পূরণ করলে অ্যাপ্লিকেশনগুলো অ্যাক্সেস করতে পারে। আপনি OR অপারেটর ব্যবহার করে একটি একক নেস্টেড অ্যাক্সেস লেভেল (যার নাম USRegions) তৈরি করতে পারেন। যখন অ্যাক্সেস লেভেলগুলো অ্যাসাইন করার সময় আসবে, তখন অর্গানাইজেশনাল ইউনিট বা গ্রুপের অ্যাপ্লিকেশনটিতে USRegions অ্যাক্সেস লেভেলটি অ্যাসাইন করুন।
Access Level name | USRegions |
A user gets access if they | Meet attributes |
Condition 1 attribute (only 1 access level per condition) | Access level USWest |
Join condition 1 and condition 2 with | অথবা |
A user gets access if they | Meet attributes |
Condition 2 attribute | Access level USEast |
Join condition 2 and condition 3 with | অথবা |
A user gets access if they | Meet attributes |
Condition 3 attribute | Access level USCentral |
Require company-owned on desktop but not on mobile device
A company might require a company-owned desktop device, but not a company-owned mobile device.
First, create an access level for desktop devices:
Access level name | aldesktop_access |
ব্যবহারকারীরা অ্যাক্সেস পান যদি তারা | Meet attributes |
Condition 1 attribute | Device policy
Device encryption = Not supported Device OS ম্যাকওএস = ০.০.০ Windows =0.0.0 Linux OS = 0.0.0 Chrome OS = 0.0.0 |
এরপর, মোবাইল ডিভাইসগুলোর জন্য একটি অ্যাক্সেস লেভেল তৈরি করুন:
অ্যাক্সেস স্তরের নাম | almobile_access |
Users get access if they | Meet attributes |
শর্ত ১ বৈশিষ্ট্য | ডিভাইস ওএস iOS = 0.0.0 Android = 0.0.0 |
Require basic device security
অধিকাংশ বড় প্রতিষ্ঠান এখন কর্মীদেরকে এনক্রিপ্টেড এবং ন্যূনতম অপারেটিং সিস্টেম সংস্করণ পূরণ করে এমন ডিভাইসের মাধ্যমে কর্পোরেট রিসোর্স অ্যাক্সেস করতে বলে। কিছু প্রতিষ্ঠান আবার কর্মীদেরকে কোম্পানির মালিকানাধীন ডিভাইস ব্যবহার করতেও বলে।
You can configure these policies for all of your organizational units or only for those that work with sensitive data, such as company executives, finance, or human resources.
There are several ways you can configure a policy that includes device encryption, minimum operating system version, and company-owned devices. They each have advantages and disadvantages.
1 access level that contains all security requirements
In this example, device encryption, minimum operating system version, and company-owned device attributes are included in one access level. Users must meet all conditions to get access.
For example, if a user device is encrypted and is company-owned but doesn't run a compliant version of the operating system, they are denied access.
Advantage : Easy to set up. When you assign this access level to an app, a user has to satisfy all requirements.
Disadvantage : To separately assign the security requirements to different organizational units, you need to create a separate access level for each security requirement.
| Access level name | ডিভাইস_নিরাপত্তা |
| একজন ব্যবহারকারী অ্যাক্সেস পান যদি তারা | Meet attributes |
| Condition 1 attribute (আপনি সমস্ত বৈশিষ্ট্য একটি শর্তে যোগ করতে পারেন অথবা) তিনটি শর্ত তৈরি করুন এবং সেগুলোকে AND দিয়ে যুক্ত করুন। | Device policy Device OS |
৩টি পৃথক প্রবেশ স্তর
In this example, device encryption, minimum operating system version, and company-owned device attributes are in 3 separate access levels. Users must meet the conditions in only one access level to get access. It's a logical OR of access levels.
For example, a user who has an encrypted device and runs an older version of the operating system on a personal device gets access.
Advantage : A granular way of defining access levels. You can separately assign access levels to different organizational units.
Disadvantage : Users have to meet the conditions in only one access level.
| Access level name | device_encryption |
| A user gets access if they | Meet attributes |
| শর্ত ১ বৈশিষ্ট্য | ডিভাইস নীতি |
| অ্যাক্সেস স্তরের নাম | কর্প_ডিভাইস |
| একজন ব্যবহারকারী অ্যাক্সেস পান যদি তারা | বৈশিষ্ট্য পূরণ করুন |
| Condition 1 attribute | ডিভাইস নীতি |
| অ্যাক্সেস স্তরের নাম | min_os |
| একজন ব্যবহারকারী অ্যাক্সেস পান যদি তারা | Meet attributes |
| শর্ত ১ বৈশিষ্ট্য | ডিভাইস নীতি |
১টি অ্যাক্সেস লেভেল এবং এর মধ্যে থাকা অ্যাক্সেস লেভেলসমূহ
এই উদাহরণে, ডিভাইস এনক্রিপশন, ন্যূনতম অপারেটিং সিস্টেম সংস্করণ, এবং কোম্পানির মালিকানাধীন ডিভাইসের নিরাপত্তা সংক্রান্ত আবশ্যকতাগুলো ৩টি পৃথক অ্যাক্সেস লেভেলে রয়েছে। এই ৩টি অ্যাক্সেস লেভেল একটি চতুর্থ অ্যাক্সেস লেভেলের ভেতরে বিন্যস্ত আছে।
When you assign the fourth access level to apps, users must meet the conditions in each of the 3 nested access levels to get access. It's a logical AND of access levels.
For example, a user who has an encrypted device and runs an older version of the operating system on a personal device is denied access.
Advantage : You retain the flexibility of separating security requirements across access levels 1, 2, and 3. Using access level 4, you can also enforce a policy with all security requirements.
Disadvantage : The audit log only captures access denied to access level 4 (not to access levels 1, 2, and 3), because access levels 1, 2, and 3 aren't directly assigned to apps.
উপরে "৩টি পৃথক অ্যাক্সেস লেভেল" অংশে বর্ণিত অনুযায়ী "device_encryption," "corp_device," এবং "min_os" নামে ৩টি অ্যাক্সেস লেভেল তৈরি করুন। এরপর "device_security" নামে একটি চতুর্থ অ্যাক্সেস লেভেল তৈরি করুন, যেটিতে ৩টি কন্ডিশন থাকবে। প্রতিটি কন্ডিশনের অ্যাট্রিবিউট হিসেবে একটি অ্যাক্সেস লেভেল থাকবে। (আপনি প্রতিটি কন্ডিশনের জন্য কেবল ১টি অ্যাক্সেস লেভেল অ্যাট্রিবিউট যোগ করতে পারবেন।)
| Access level name | device_security |
| A user gets access if they | Meet attributes |
| Condition 1 attribute (প্রতিটি শর্তের জন্য শুধুমাত্র ১টি প্রবেশাধিকার স্তর) | প্রবেশাধিকার স্তর device_encryption |
| Join condition 1 and condition 2 with | এবং |
| A user gets access if they | Meet attributes |
| শর্ত ১ বৈশিষ্ট্য | Access level কর্প_ডিভাইস |
| Join condition 2 and condition 3 with | এবং |
| A user gets access if they | Meet attributes |
| Condition 1 attribute | Access level min_os |