Контроль доступа¶
Фильтрация команд¶
Фильтры команд применяются к сочетанию пользователя, актива и учетной записи. Правила проверяются по приоритету; меньшее число означает более высокий приоритет.
Откройте Консоль → Политики → Контроль доступа → Фильтрация команд и создайте фильтр.

| Поле | Описание |
|---|---|
| Пользователи | все, выбранные или совпавшие по свойствам |
| Активы | все, выбранные или совпавшие по свойствам |
| Учетные записи | все либо выбранные |
| Группы команд | наборы выражений, проверяемые фильтром |
| Действие | разрешить, запретить, запросить согласование или уведомить |
| Приоритет | от 1 до 100; меньшее значение проверяется раньше |
Группы команд¶
Группа содержит точные команды либо регулярные выражения, по одному правилу в строке.

Тестируйте регулярные выражения на безопасном активе. Слишком широкое выражение может заблокировать штатную работу, а слишком узкое — пропустить опасную команду с аргументами или иным регистром.
Правила входа пользователей¶
Правила входа ограничивают пользователей по исходному IP и времени.

Доступные действия: разрешить, запретить, уведомить или отправить запрос на согласование, если эта функция включена в выпуске и лицензии.
IP можно задавать отдельным адресом, CIDR или диапазоном; несколько значений
разделяются запятыми. * соответствует любому адресу.
Правила подключения к активам¶
Правило подключения учитывает пользователя, актив, учетную запись, исходный IP и временной интервал. Оно может разрешить или запретить подключение, отправить уведомление либо запросить согласование.

Функции согласования и автоматической смены секрета настраиваются в AFIGate. Для смены секрета после сессии требуется:
Маскирование данных¶
Правила маскирования скрывают выбранные столбцы результатов Web-запросов к
базам данных. Поддержка зависит от используемого протокола и способа
подключения; для нативных подключений через afigate_db маскирование не
гарантируется.

Ограничение способов подключения¶
Правило способа подключения может запретить Web CLI, Web SFTP, SSH, Web GUI, нативный DB-клиент или другой опубликованный способ для выбранных пользователей.

После изменения ACL проверьте положительный и отрицательный сценарии под тестовым пользователем, а затем подтвердите событие в журнале аудита.