Настройка управления доступом на основе ролей с помощью политики доступа к данным
Управление доступом к Кэш Azure для Redis экземпляру крайне важно, чтобы правильные пользователи имели доступ к правильному набору данных и команд. В Redis версии 6 появился список контроль доступа (ACL). ACL ограничивает, какие пользователи могут выполнять определенные команды, и ключи, к которым может получить доступ пользователь. Например, можно запретить определенным пользователям удалять ключи в кэше с помощью команды DEL .
Кэш Azure для Redis теперь интегрирует эту функцию ACL с идентификатором Microsoft Entra, чтобы настроить политики доступа к данным для субъекта-службы приложения и управляемого удостоверения.
Кэш Azure для Redis предлагает три встроенные политики доступа: Владелец данных, участник данных и средство чтения данных. Если встроенные политики доступа не соответствуют требованиям к защите данных и изоляции, можно создать и использовать собственную политику доступа к данным, как описано в разделе "Настройка политики пользовательского доступа к данным".
Область доступности
Уровень | "Базовый", "Стандартный" и "Премиум" | Enterprise, Enterprise Flash |
---|---|---|
Доступность | Да | Нет |
Предварительные требования и ограничения
- Политики ACL и доступа к данным Redis не поддерживаются в Кэш Azure для Redis экземплярах, работающих под управлением Redis версии 4.
- Проверка подлинности и авторизация Microsoft Entra поддерживаются только для SSL-подключений.
- Некоторые команды Redis блокируются.
Разрешения для политики доступа к данным
Как описано в списке redis контроль доступа, ACL в Redis версии 6.0 позволяет настраивать разрешения доступа для трех областей:
Категории команд
Redis создал группировки таких команд, как административные команды, опасные команды и т. д., чтобы упростить настройку разрешений для группы команд.
- Использование
+@commandcategory
для разрешения категории команд - Использование
-@commandcategory
для запрета категории команд
Эти команды по-прежнему блокируются. Следующие группы являются полезными категориями команд, поддерживаемыми Redis. Дополнительные сведения о категориях команд см. в полном списке в разделе " Категории команд".
admin
- Административные команды. Обычные приложения никогда не должны использовать их, включая
MONITOR
SHUTDOWN
и другие.
- Административные команды. Обычные приложения никогда не должны использовать их, включая
dangerous
- Потенциально опасные команды. Каждый из них должен рассматриваться с осторожностью по различным причинам, включая
FLUSHALL
, ,CLIENT
SORT
KEYS
RESTORE
,DEBUG
INFO
CONFIG
и другие.
- Потенциально опасные команды. Каждый из них должен рассматриваться с осторожностью по различным причинам, включая
keyspace
- Запись или чтение из ключей, баз данных или их метаданных в не зависящих от типах, включая
DEL
, ,RESTORE
,EXISTS
KEYS
DUMP
DBSIZE
EXPIRE
RENAME
TTL
иFLUSHALL
многое другое. Команды, которые могут изменять пространство ключей, ключ или метаданные, также имеют категорию записи. Команды, которые считывают только пространство ключей, ключ или метаданные, имеют категорию чтения.
- Запись или чтение из ключей, баз данных или их метаданных в не зависящих от типах, включая
pubsub
- Команды, связанные с PubSub.
read
- Чтение из ключей, значений или метаданных. Команды, которые не взаимодействуют с ключами, не имеют ни чтения, ни записи.
set
- Тип данных: наборы, связанные.
sortedset
- Тип данных: отсортированные наборы, связанные.
stream
- Тип данных: связанные потоки.
string
- Тип данных: строки, связанные.
write
- Запись в ключи (значения или метаданные).
Команды
Команды позволяют контролировать, какие определенные команды могут выполняться определенным пользователем Redis.
- Используйте
+command
для разрешения команды. - Используется
-command
для запрета команды.
Ключи
Ключи позволяют управлять доступом к определенным ключам или группам ключей, хранящихся в кэше.
Используется
~<pattern>
для предоставления шаблона ключей.~*
Используйте илиallkeys
укажите, что разрешения категории команд применяются ко всем ключам в экземпляре кэша.
Указание разрешений
Чтобы указать разрешения, необходимо создать строку для сохранения в качестве настраиваемой политики доступа, а затем назначить строку пользователю Кэш Azure для Redis.
В следующем списке содержатся некоторые примеры строк разрешений для различных сценариев.
Разрешить приложению выполнять все команды во всех ключах
Строка разрешений:
+@all allkeys
Разрешить приложению выполнять только команды чтения
Строка разрешений:
+@read ~*
Разрешить приложению выполнять категорию команд чтения и задавать команду для ключей с префиксом
Az
.Строка разрешений:
+@read +set ~Az*
Настройка настраиваемой политики доступа к данным для приложения
В портал Azure выберите экземпляр Кэш Azure для Redis, в котором требуется настроить проверку подлинности на основе маркера Microsoft Entra.
В меню "Ресурс" выберите конфигурацию доступа к данным.
Выберите "Добавить" и выберите "Новая политика доступа".
Укажите имя политики доступа.
Настройте разрешения в соответствии с вашими требованиями.
Чтобы добавить пользователя в политику доступа с помощью идентификатора Microsoft Entra ID, необходимо сначала включить идентификатор Microsoft Entra, выбрав проверку подлинности в меню "Ресурс".
Выберите "Включить проверку подлинности Microsoft Entra" в качестве вкладки в рабочей области.
Если флажок еще не установлен, установите флажок "Включить проверку подлинности Microsoft Entra" и нажмите кнопку "ОК". Затем нажмите кнопку Сохранить.
Всплывающее диалоговое окно отображает запрос на обновление конфигурации и информирование о том, что требуется несколько минут. Выберите Да.
Внимание
После завершения операции включения узлы в экземпляре кэша перезагружается для загрузки новой конфигурации. Мы рекомендуем выполнить эту операцию во время периода обслуживания или за пределами пиковых рабочих часов. Операция может занять до 30 минут.
Настройка клиента Redis для использования идентификатора Microsoft Entra
Теперь, когда вы настроили политику доступа пользователей и данных Redis для настройки управления доступом на основе ролей, необходимо обновить рабочий процесс клиента, чтобы обеспечить проверку подлинности с помощью определенного пользователя или пароля. Сведения о настройке клиентского приложения для подключения к экземпляру кэша в качестве конкретного пользователя Redis см. в статье Настройка клиента Redis для использования Microsoft Entra.