В этой статье описываются распространенные сценарии использования контекстно-зависимого доступа и приводятся примеры конфигураций, разработанных в базовом режиме.
For examples of access levels developed in Advanced mode (using the CEL editor), go to Context-Aware Access examples for Advanced mode .
Предоставлять подрядчикам доступ только через корпоративную сеть.
Многие компании хотят ограничить доступ подрядчиков к корпоративным ресурсам. Например, компании, которые используют подрядчиков для обработки общих звонков в службу поддержки или работы в центрах помощи и колл-центрах. Как и штатные сотрудники, подрядчики должны иметь поддерживаемую лицензию , чтобы на них распространялись политики контекстно-зависимого доступа.
В этом примере подрядчики получают доступ к корпоративным ресурсам только из определенного диапазона корпоративных IP-адресов.
| Название уровня доступа | contractor_access |
| A contractor gets access if they | Соответствует атрибутам |
| Атрибут условия 1 | IP-подсеть (публичная) 74.125.192.0/18 |
| назначение уровня доступа | Organizational units for contractors Все приложения, которые используют подрядчики. |
Блокировка доступа с известных IP-адресов злоумышленников.
To protect company resources from being compromised, many companies block access to known high-risk sources.
In this example, IP address 74.125.195.105 is blocked. Users get access to corporate resources if their sessions originate from any other IP address. You can specify multiple IP addresses and ranges.
| Access level name | block_highrisk |
| Пользователь получает доступ, если он | Don't meet attributes |
| Атрибут условия 1 | IP-подсеть (публичная) 74.125.195.105 |
| назначение уровня доступа | Организационное подразделение высшего уровня Все приложения |
Allow access from a specific private network in Google Cloud
Многие компании направляют пользовательский трафик в Google через виртуальную частную сеть (VPC). VPC — это защищенная, изолированная сеть в среде Google Cloud.
Учтите, что трафик, проходящий через вашу VPC, может использовать частные IP-адреса. Это может вызвать проблемы с публичными IP-адресами или региональными политиками.
В этом примере вы можете разрешить трафик из этих конкретных VPC.
| Название уровня доступа | vpc_access |
| Пользователь получает доступ, если он... | Meet attributes |
| Атрибуты условия 1 | IP-подсеть (частная) Частная IP-подсеть: //compute.googleapis.com/projects/project- name-test/global/networks/network-name VPC subnet: 74.125.192.0/18 |
| назначение уровня доступа | Организационные подразделения для всех пользователей Все приложения, которые используют подрядчики. |
Важные вещи, которые следует помнить:
- Только прямой трафик : Этот уровень доступа работает только для трафика, который напрямую поступает на серверы Google из разрешенной VPC. Если трафик сначала проходит через другую сеть или туннель, доступ не предоставляется. Google распознает только последнюю VPC, которая отправляет трафик на его серверы.
- Права администратора : Для просмотра VPC и настройки этого уровня доступа администраторы должны иметь соответствующую роль в системе управления идентификацией и доступом (IAM) (например, compute.networks.list , compute.subnetworks.list и т. д.).
- Внешние VPC : В список разрешенных VPC может входить виртуальная частная сеть (VPC) из-за пределов вашего текущего домена Google Cloud. Для добавления внешней VPC администратор должен иметь права на просмотр.
Разрешить или запретить доступ из определенных мест.
Если ваши сотрудники регулярно ездят в удаленные корпоративные офисы или офисы партнеров, вы можете указать географические местоположения, где они могут получить доступ к корпоративным ресурсам.
Например, если группа продавцов регулярно посещает клиентов в Австралии и Индии, вы можете ограничить доступ группы к их головному офису, а также к Австралии и Индии. Если же они ездят в другие страны в рамках деловой поездки, они не смогут получить доступ к корпоративным ресурсам из этих стран.
В этом примере отдел продаж может получить доступ к корпоративным ресурсам только из США (головной офис), Австралии и Индии.
| Название уровня доступа | доступ к продажам |
| Sales gets access if they | Соответствует атрибутам |
| Condition 1 attribute | Географическое происхождение США, Австралия, Индия |
| назначение уровня доступа | Группа продавцов Все приложения, которыми пользуются продавцы. |
Вы также можете создать политику, запрещающую доступ из определенных стран, указав, что пользователи получат доступ, если они не соответствуют условиям. Вам нужно будет перечислить страны, из которых вы хотите заблокировать доступ.
Вместо выбора нескольких уровней доступа при назначении используйте вложенные уровни доступа.
In some cases when you try to assign access levels to a given organizational unit or group and an application (or a set of applications), you might see an error message asking you to reduce the number of applications or access levels.
Чтобы предотвратить эту ошибку, можно уменьшить количество уровней доступа, используемых при назначении, объединив их в один уровень доступа. Вложенный уровень доступа объединяет несколько условий с помощью операции ИЛИ, при этом каждое условие содержит отдельный уровень доступа.
In this example, USWest, USEast, and USCentral are in 3 separate access levels. Let's say you want users to be able to access applications if they satisfy any of USWest OR USEast OR USCentral access levels.You can create a single nested access level (called USRegions) using the OR operator. When it comes time to assign the access levels, assign the access level USRegions to the application for the organizational unit or group.
Название уровня доступа | Регионы США |
A user gets access if they | Соответствует атрибутам |
Condition 1 attribute (only 1 access level per condition) | Уровень доступа USWest |
Объедините условие 1 и условие 2 с помощью | ИЛИ |
Пользователь получает доступ, если он | Соответствует атрибутам |
Condition 2 attribute | Уровень доступа USEast |
Join condition 2 and condition 3 with | ИЛИ |
Пользователь получает доступ, если он | Meet attributes |
Атрибут условия 3 | Уровень доступа USCentral |
Требуется наличие корпоративных приложений на настольных компьютерах, но не на мобильных устройствах.
Компании может потребоваться корпоративное настольное устройство, но не корпоративное мобильное устройство.
Сначала создайте уровень доступа для настольных устройств:
Название уровня доступа | aldesktop_access |
Пользователи получают доступ, если они | Соответствует атрибутам |
Атрибут условия 1 | Device policy
Device encryption = Not supported ОС устройства macOS = 0.0.0 Windows =0.0.0 ОС Linux = 0.0.0 Chrome OS = 0.0.0 |
Затем создайте уровень доступа для мобильных устройств:
Access level name | almobile_access |
Users get access if they | Соответствует атрибутам |
Атрибут условия 1 | ОС устройства 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 уровень доступа, включающий все требования безопасности.
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.
| Название уровня доступа | device_security |
| A user gets access if they | Meet attributes |
| Condition 1 attribute (Вы можете добавить все атрибуты к одному условию или create 3 conditions and join them with AND.) | Политика устройства ОС устройства |
3 separate 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 |
| Пользователь получает доступ, если он | Соответствует атрибутам |
| Атрибут условия 1 | Политика устройства |
| Access level name | corp_device |
| A user gets access if they | Meet attributes |
| Атрибут условия 1 | Device policy |
| Название уровня доступа | мин_ос |
| Пользователь получает доступ, если он | Meet attributes |
| Condition 1 attribute | Device policy |
1 access level with nested access levels
In this example, device encryption, minimum operating system version, and company-owned device security requirements are in 3 separate access levels. These 3 access levels are nested inside a fourth access level.
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.
Создайте 3 уровня доступа, как описано выше в разделе «3 отдельных уровня доступа»: «device_encryption», «corp_device» и «min_os». Затем создайте четвертый уровень доступа под названием «device_security», который будет иметь 3 условия. Каждое условие имеет атрибут уровня доступа. (Вы можете добавить только 1 атрибут уровня доступа к каждому условию.)
| Access level name | безопасность устройства |
| A user gets access if they | Meet attributes |
| Condition 1 attribute (только 1 уровень доступа на каждое условие) | Уровень доступа device_encryption |
| Объедините условие 1 и условие 2 с помощью | И |
| A user gets access if they | Соответствует атрибутам |
| Condition 1 attribute | Уровень доступа corp_device |
| Join condition 2 and condition 3 with | И |
| Пользователь получает доступ, если он | Meet attributes |
| Атрибут условия 1 | Уровень доступа мин_ос |