Оригинальный источник: Which Azure Cosmos DB Role Does My App Need?
Самая важная идея в этом руководстве по Cosmos DB — не команда, не идентификатор роли и не трюк с CLI. Она архитектурная: перестаньте относиться к учётным данным как к конфигурации приложения и начните относиться к identity как к состоянию времени выполнения.
Слишком много команд всё ещё поставляют код со строками подключения, потому что так кажется быстрее. Это не быстрее. Это отложенный риск. Каждый ключ в конфигурационном файле становится инцидентом, ожидающим поспешный коммит, скопированную переменную пайплайна или утечку в лог. Managed identity плюс RBAC на уровне данных почти полностью устраняет этот класс отказов.
Практическая сложность — путаница между авторизацией на уровне управления (control-plane) и на уровне данных (data-plane). Именно здесь многие в остальном сильные команды теряют дни. Роли Azure RBAC на ресурсах не предоставляют автоматически доступ к документам, а роли данных Cosmos не дают администрирования аккаунта. Если ваша команда явно не документирует это разделение в runbook-ах, вы будете продолжать получать хрупкие развёртывания и трудноотлаживаемые 403-е ошибки.
Моя оценочная рекомендация для производственных команд проста:
Начинайте с Data Reader для путей чтения и Data Contributor только там, где записи действительно необходимы.
Расширяйте область действия широко только тогда, когда у вас одна граница приложения на аккаунт.
Если вы делите аккаунт между сервисами, сужайте область действия рано, до границ базы данных или контейнера, а не ждите давления аудита.
Это одно из тех решений, которое накапливается со временем. Когда вы подключаете ваше .NET-приложение через DefaultAzureCredential и конфигурацию только с эндпоинтом, каждое окружение становится чище: локальное, CI, staging и prod. Вы также ускоряете реагирование на инциденты, потому что можете рассуждать о правах через назначения ролей, а не искать таинственные ключи.
Статья также намекает на то, что зрелым командам стоит принять: права доступа как итеративный дизайн, а не как разовую настройку. Вы можете начать достаточно широко, чтобы доставить продукт, а затем сужать через телеметрию и ревью доступа. Минимальные привилегии — это не философская конечная точка, а привычка поставки.
Если вы примете от этого поста только одну вещь, пусть это будет: сначала уберите секреты, потом оптимизируйте роли. Команды, которые меняют этот порядок местами, обычно застревают на совещаниях. Команды, которые сначала убирают секреты, обычно доставляют продукт, а затем укрепляют его.
В 2026 году доступ к данным без секретов — это не продвинутый паттерн. Это минимальный ответственный стандарт для серьёзных .NET-систем на Azure.
