Внедрение контроля доступа на основе ролей в приложениях без серверов

• Пользователи: Личность человека или службы, нуждающаяся в доступе.
• Роль: Названы категории (например, Админ , Вивер, Контрибьютор), которые объединяют разрешения.
• Разрешения: Возможность выполнения конкретного действия на конкретном ресурсе (например, на функции ).
• Политика: Документы, которые определяют набор разрешений и прикрепляются к ролям.
• Сессионный контекст: Информация о пользователе, его ролях и текущем запросе (например, время, IP, доступ к ресурсу).

В безсерверном режиме эти компоненты часто выражаются через облачные системы провайдера IAM (AWS IAM, Azure RBAC, GCP IAM), но также могут быть реализованы на уровне приложения с использованием службы авторизации на заказ.

Стратегии внедрения RBAC в приложения без серверов

Не существует единого подхода, подходящего для всех. Правильная стратегия зависит от вашего поставщика облачных услуг, сложности ваших разрешений и вашей терпимости к задержке. Ниже приведены проверенные методы.

1. Используйте облачные сервисы IAM в качестве основы

Большинство крупных облачных провайдеров предлагают встроенный IAM, который можно использовать для определения ролей и прикрепления политик на уровне учетной записи или ресурса. Например, AWS IAM позволяет создавать роли исполнения для функций Lambda. Если функция должна читаться из DynamoDB, вы прикрепляете политику IAM, предоставляющую на эту конкретную таблицу. Это самая простая форма RBAC: роль привязана к контексту исполнения функции, а не к конечному пользователю. Однако, поскольку все вызовы этой функции имеют одну и ту же роль исполнения, мелкозернистые разрешения на пользователя требуют дополнительной логики внутри самой функции.

Для Azure RBAC Azure интегрируется с Azure Functions и App Service. Вы можете назначать роли управляемым идентификаторам или группам Azure AD, и эти роли диктуют доступ к ресурсам Azure, таким как Blob Storage или Cosmos DB. Аналогично GCP IAM работает с облачными функциями и другими службами.

2. Внедрение контроля доступа с использованием пользовательских политик

Когда разрешения зависят от атрибутов запроса (например, идентификатор пользователя, владелец документа или выполняемое действие), одного только облачного IAM недостаточно. Именно здесь в игру вступает мелкозернистый или основанный на атрибутах контроль доступа (ABAC). Вы можете комбинировать политики IAM с ключами состояния. Например, в AWS вы можете написать политику, которая предоставляет только в том случае, если тег объекта соответствует отделу пользователя. Это снимает большую часть нагрузки с функционального кода.

Для более сложных правил вам может потребоваться принудительное авторизация на уровне приложения. После того, как функция получает событие вызова, она запрашивает хранилище ролевых разрешений (например, в DynamoDB или Redis), чтобы определить, имеет ли абонент право выполнять запрошенное действие. Это часто упоминается как политический контроль доступа (PBAC) и популярно в приложениях SaaS с несколькими арендаторами.

3. Используйте API Gateway Custom Authorizers

Для функций, открытых через HTTP (например, REST или GraphQL), API Gateway является естественной точкой правоприменения. AWS API Gateway пользовательские авторизаторы (авторизаторы Lambda) могут проверять токен на предъявителя (JWT, OAuth) и возвращать политику IAM, которая диктует, к каким конечным точкам API и методам позволен доступ. Эта политика затем кэшируется и применяется к последующим запросам, уменьшая задержку. Аналогично, Azure API Management предлагает валидацию JWT и выражения политики, в то время как Google Cloud Endpoints поддерживает аутентификацию и авторизацию через Firebase или Cloud IAM.

Пользовательские авторизаторы идеальны, потому что они централизуют логику авторизации в единую функцию, а не разбрасывают ее по каждой функции бэкэнда. Авторизатор получает токен, извлекает роли пользователей, просматривает разрешения и возвращает политику. Таким образом, ваши функции бизнес-логики остаются без состояния и сосредоточены.

4.Сохраняйте карты ролей в безопасном хранилище данных

Роли и пользовательские задания должны храниться и извлекаться во время выполнения.

• Управляемые службы каталогов: Azure AD, AWS Cognito или Auth0 могут хранить информацию о ролях в качестве пользовательских атрибутов или групп.
• Реляционные или NoSQL базы данных: Сохраните таблицу с колонкой или отдельную картографическую таблицу.
• Распределенные кэши: Amazon ElastiCache (Redis) или DAX могут служить ролевыми данными с низкой задержкой, критически важными для холодных запусков.

Убедитесь, что хранилище данных защищено строгими политиками IAM. Никогда не подвергайте данные о роли неаутентифицированным конечным точкам.

Шаги реализации: от проектирования до развертывания

Выполните следующие шаги по разработке и внедрению RBAC в безсерверное приложение:

1. Определить ресурсы и действия: Перечислить все безсерверные функции, API, ведра для хранения, очереди и таблицы. Для каждого определите действия, которые могут быть выполнены (вызов, чтение, запись, удаление).
2. Определение ролей: Собеседование с заинтересованными сторонами для понимания функций работы (например, клиент, агент поддержки, администратор).
3. Разработка политик IAM: Для облачных ресурсов создайте политики IAM, которые предоставляют минимально необходимые действия. Используйте ресурсные ARN для ограничения объема.
4. Реализуйте аутентификацию: Убедитесь, что каждая конечная точка HTTP требует проверяемого токена (JWT, OAuth2). Используйте поставщика идентификационных данных, такого как Cognito, Auth0 или Firebase.
5. Создайте пользовательский авторизатор: Напишите функцию Lambda, которая декодирует токен, извлекает роль пользователя, запрашивает магазин разрешений и возвращает документ политики IAM.
6. Встроенное авторизация в не-HTTP триггеры: Для SQS, событий S3, или DynamoDB потоков, включать контекст роли в полезной нагрузке события или использовать поиск внутри функции.
7. Кэш агрессивно: Храните отображения ролей в разрешении в кэше Redis с TTL для снижения нагрузки на базу данных и улучшения задержки.
8. Тщательно протестируйте: Напишите интеграционные тесты, которые имитируют различные роли и проверяют, что несанкционированные действия заблокированы. Используйте такие инструменты, как AWS IAM Access Analyzer для проверки политик.
9. Монитор и аудит: Включить CloudTrail (AWS) или журналы активности (Azure) для регистрации всех попыток доступа.

Обычные подводные камни и как их избежать

• Сверхдопустимые роли исполнения: У разработчиков может возникнуть соблазн прикрепить к всем функциям одну роль IAM «пользователя мощности». Это нарушает наименьшую привилегию и увеличивает радиус взрыва. Используйте отдельные роли для одной функции или группы функций с аналогичными потребностями.
• Игнорирование холодных запусков: Данные о роли загрузки из базы данных по каждому вызову могут добавить задержку 200-500 мс. Предварительно загрузите решение о авторизации в авторизатор шлюза API и кэшируйте его.
• Разрешения на кодирование: Разрешения должны быть легко обновляться без перераспределения функций. Храните их в базе данных или файле конфигурации, а не в коде.
• Непредвзятость служебных идентичностей: RBAC должна охватывать нечеловеческих субъектов (например, запланированное событие, которое запускает функцию).
• Отсутствие тестирования на авторизацию: Легко проверить сценарии «счастливого пути». Важно провести состязательное тестирование — попытаться получить доступ к ресурсам с неаутентифицированным токеном или с поддельными претензиями.

Пример из реального мира: безопасная обработка документов несколькими участниками

Рассмотрим платформу SaaS, где арендаторы загружают документы для обработки. Каждый арендатор имеет свою собственную папку в ведре S3. Рабочий процесс использует API Gateway, функцию Lambda для загрузки документов, другую для обработки (срабатывающую через событие S3) и третью для запроса результатов хранения в DynamoDB.

Роль:

• Администратор: Может загружать документы, просматривать результаты и удалять свои собственные обработанные файлы.
• См.: Может просматривать только результаты (читай DynamoDB), но не загружать или удалять.
• Системный администратор: Полный доступ ко всем арендаторам для отладки (только для доверенной операционной команды).

Реализация:

• Идентификатор арендатора хранится в JWT, выпущенном Cognito, содержащем и претензии.
• API Gateway использует пользовательский авторизатор Lambda, который декодирует JWT, запрашивает таблицу DynamoDB, чтобы получить разрешения на роль, и возвращает политику, которая ограничивает доступ к ресурсам с префиксом ID арендатора (например, ).
• Функция загрузки получает идентификатор арендатора в контексте запроса; она использует его для обеспечения того, чтобы файл был помещен в правильную папку. Функция обработки считывает тег папки, чтобы связать результаты с арендатором.
• Все запросы DynamoDB включают идентификатор арендатора в первичном ключе, и политика IAM гарантирует, что функция может читать / писать элементы только с этим ключом раздела.

Эта архитектура гарантирует, что один арендатор не может получить доступ к данным другого арендатора, и что пользователи Viewer не могут вызвать функцию загрузки. Роли и разрешения управляются централизованно, и изменения вступают в силу немедленно, не перераспределяя какие-либо функции.

Инструменты и фреймворки для упрощения RBAC

Несколько инструментов с открытым исходным кодом и коммерческие инструменты могут ускорить внедрение RBAC:

• Агент открытой политики (OPA): Общий механизм политики, который может быть развернут в качестве коляски или микросервиса для обеспечения соблюдения сложных правил авторизации. Он хорошо интегрируется с бессерверными через HTTP-коляски или время выполнения Go/Rust.
• Касбин: Библиотека разрешений для Go, Java, Node.js и Python. Поддерживает RBAC, ABAC и пользовательские модели. Может работать внутри функции Lambda для оценки разрешений с низкой задержкой.
• Auth0 / Firebase Auth: Обе обеспечивают встроенный RBAC через пользовательские претензии и роли. Они легко интегрируются с API Gateway и облачными функциями.
• AWS Verified Permissions: Управляемая служба политики Cedar, которая может использоваться для централизации решений о разрешении за пределами Ламбды.

Аудит и соблюдение

Для соответствия требованиям соответствия (SOC 2, HIPAA, GDPR) необходимо внедрить аудит:

• Включите запись облачного следа для всех действий IAM и доступа к ресурсам.
• Зарегистрируйте каждое решение об авторизации (разрешить / отклонить) с идентификатором пользователя, ресурсом и временным меткой. Используйте структурированный подход к регистрации (JSON) и отгрузите журналы в SIEM, такой как Splunk или ELK.
• Регулярно назначайте обзоры доступа , где задания на роль подтверждаются или отменяются.
• Используйте инструменты моделирования политики (например, AWS IAM Access Analyzer) для проверки того, что политики предоставляют только предполагаемые разрешения.