По мере роста сред Amazon Quick и расширения возможностей, предоставляемых функциями на базе ИИ, автоматизация пользовательских разрешений становится критически важной для поддержания принципа наименьших привилегий. Пользовательские разрешения в Quick позволяют применять детальный контроль доступа, включая или отключая определенные функции для отдельных пользователей. Например, финансовые аналитики могут создавать отчеты без возможности экспорта необработанных данных, а внешние партнеры могут просматривать дашборды без доступа к элементам управления общим доступом. Хотя Quick предлагает различные варианты применения пользовательских разрешений на уровне учетной записи, роли и пользователя, существуют сценарии, когда специфические разрешения организации должны применяться динамически. В этой статье рассматриваются четыре архитектурных шаблона для автоматизации назначения пользовательских разрешений на ключевых этапах жизненного цикла пользователя. Подходы варьируются от использования одного параметра API до автоматизации, управляемой событиями, охватывая новых пользователей, будущих пользователей, логику на основе групп и ретроактивные массовые обновления.
Предварительно зарегистрированные пользователи: API и CLI
Если вы используете пользовательский портал или скрипты для регистрации пользователей через API RegisterUser, сложная автоматизация не требуется. Пользовательские разрешения можно применить во время создания пользователя Quick, включив параметр —custom-permissions-name в вызов API. Этот подход применим, когда организация полностью контролирует процесс создания пользователей через собственный портал или скрипт. Это наиболее прямой путь, не требующий инфраструктуры, управляемой событиями. Такой метод часто используется SaaS-компаниями, встраивающими Quick в учетные записи клиентов, например, для автоматического ограничения премиум-функций, таких как постраничные отчеты и GenBI, в зависимости от тарифного плана клиента в момент предоставления доступа каждому пользователю. Приведенный пример применяет профиль пользовательских разрешений с именем "Restricted-Author-Profile" к авторам в учетной записи, но тот же API может быть использован для применения профилей разрешений к любой роли (включая Author Pros, Admins, Admin Pros, Readers и Reader Pros).
Пример команды CLI: aws quicksight register-user —aws-account-id 123456789012 —namespace default —identity-type QUICKSIGHT —user-role AUTHOR —email user@example.com —user-name user_name —custom-permissions-name "Restricted-Author-Profile".
Разрешения по умолчанию для учетной записи или роли: API и CLI
С помощью двух нативных API можно установить профили пользовательских разрешений по умолчанию без автоматизации для каждого пользователя. Пользовательские разрешения Quick следуют трехуровневой иерархии (учетная запись, роль и пользователь), где настройки на уровне пользователя переопределяют настройки на уровне роли, которые, в свою очередь, переопределяют настройки на уровне учетной записи, что позволяет администраторам реализовывать гибкие, многоуровневые политики безопасности. Этот подход охватывает как текущие, так и будущие сценарии использования с минимальными операционными издержками. Рекомендуется начинать с него, прежде чем создавать пользовательскую автоматизацию. Переходить к Сценарию 3 следует только в том случае, если требуется условная логика, выходящая за рамки поддерживаемых по умолчанию настроек на уровне учетной записи или роли. Например, предприятию с 50 000 пользователей может потребоваться блокировка всех недавно запущенных функций GenBI и коннекторов по умолчанию до завершения 60-90-дневного обзора их командой безопасности. Уровень учетной записи по умолчанию обеспечивает это ограничение мгновенно, не требуя автоматизации для каждого пользователя и без пробелов в предоставлении доступа.
Опция A: Уровень учетной записи по умолчанию. API UpdateAccountCustomPermission устанавливает резервный профиль пользовательских разрешений, который Quick применяет к любому пользователю, не имеющему явно назначенного профиля, включая новых пользователей, созданных с помощью Just-In-Time provisioning. Пример команды CLI: aws quicksight update-account-custom-permission —aws-account-id 123456789012 —custom-permissions-name "Restricted-User-Profile".
Опция B: Уровень роли по умолчанию. С помощью API UpdateRoleCustomPermission можно установить профиль пользовательских разрешений по умолчанию для каждой роли Quick (READER, AUTHOR, ADMIN и PRO роли). Пример команды CLI: aws quicksight update-role-custom-permission —aws-account-id 123456789012 —role AUTHOR —namespace default —custom-permissions-name "Restricted-Author-Profile".
Управляемая событиями пользовательская логика: Amazon EventBridge и Lambda
Этот сценарий решает более детальные требования: применение различных профилей пользовательских разрешений к пользователям в зависимости от того, к какой группе Quick или IAM Identity Center они принадлежат. Например, технологической сервисной компании с 125 000 сотрудников требуется, чтобы авторы в каждом бизнес-подразделении получали отдельные профили разрешений в момент назначения группы. Это предотвращает совместное использование активов между подразделениями, предоставляя доступ опытным пользователям только утвержденным лицам, даже если все авторы имеют одну и ту же роль Quick. Поскольку нет нативного API для назначения пользовательских разрешений группе, потребуется архитектура, которая обнаруживает, когда пользователь добавляется в группу, которая должна иметь определенные разрешения.
Рекомендуется комбинировать этот подход со Сценарием 2 для полностью многоуровневой стратегии разрешений. Сценарии 2 и 3 дополняют друг друга, а не являются альтернативами. При предоставлении доступа пользователю через федерацию Just-In-Time существует неизбежное окно между созданием учетной записи и моментом, когда администратор добавляет его в соответствующую группу. Сценарий 3 срабатывает только при событии членства в группе. Чтобы пользователи никогда не находились в неограниченном состоянии, сначала примените Сценарий 2 в качестве базового: установите уровень учетной записи или роли по умолчанию, который обеспечивает наиболее ограничительный приемлемый профиль. Затем используйте Сценарий 3 для уточнения разрешений после назначения пользователя в группу. Переопределение на уровне пользователя из Сценария 3 будет иметь приоритет над настройками по умолчанию из Сценария 2, поэтому конфликта нет, только дополнительные уровни контроля.
Рассмотрим глобальный банк с более чем 200 000 пользователей, предоставляемых через единый вход (SSO), который должен блокировать экспорт данных в момент присоединения сотрудника. Сценарий 2 немедленно устраняет этот пробел с помощью ограничительного уровня учетной записи по умолчанию, а Сценарий 3 уточняет разрешения после назначения пользователя в его группу соответствия. Это предотвращает загрузку сотрудниками конфиденциальных клиентских данных в период между предоставлением доступа и назначением группы. Quick и IAM Identity Center генерируют отдельные события AWS CloudTrail для изменений членства в группах. Quick генерирует CreateGroupMembership при добавлении пользователя и DeleteGroupMembership при удалении. IAM Identity Center генерирует AddMemberToGroup при добавлении пользователя и RemoveMemberFromGroup при удалении. Следующая архитектура обнаруживает эти события для автоматического запуска обновлений разрешений. Это будет реализовано с использованием Amazon EventBridge (для обнаружения события) и AWS Lambda (для применения исправления).
Архитектура, управляемая событиями, которая применяет профиль пользовательских разрешений при добавлении пользователя в группу Quick или IAM Identity Center, работает следующим образом: пользователь добавляется в группу Quick или Identity Center. Amazon CloudTrail фиксирует события CreateGroupMembership или AddMemberToGroup. Amazon EventBridge фильтрует эти события.
Источник: Artificial Intelligence
