<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Cloud-Security | The .NET Blog</title><link>https://thedotnetblog.com/ru/tags/cloud-security/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>ru</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Thu, 16 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/ru/tags/cloud-security/index.xml" rel="self" type="application/rss+xml"/><item><title>Доступ к Cosmos DB без секретов — новый базовый стандарт</title><link>https://thedotnetblog.com/ru/news/emiliano-montesdeoca/cosmosdb-role-assignment-without-secrets/</link><pubDate>Thu, 16 Jul 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/ru/news/emiliano-montesdeoca/cosmosdb-role-assignment-without-secrets/</guid><description>Если ваше приложение на Cosmos DB всё ещё зависит от ключей, вы уже отстаёте в операционной безопасности.</description><content:encoded>&lt;p&gt;Оригинальный источник: &lt;a href="https://devblogs.microsoft.com/cosmosdb/which-azure-cosmos-db-role-does-my-app-need/"&gt;Which Azure Cosmos DB Role Does My App Need?&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Самая важная идея в этом руководстве по Cosmos DB — не команда, не идентификатор роли и не трюк с CLI. Она архитектурная: перестаньте относиться к учётным данным как к конфигурации приложения и начните относиться к identity как к состоянию времени выполнения.&lt;/p&gt;
&lt;p&gt;Слишком много команд всё ещё поставляют код со строками подключения, потому что так кажется быстрее. Это не быстрее. Это отложенный риск. Каждый ключ в конфигурационном файле становится инцидентом, ожидающим поспешный коммит, скопированную переменную пайплайна или утечку в лог. Managed identity плюс RBAC на уровне данных почти полностью устраняет этот класс отказов.&lt;/p&gt;
&lt;p&gt;Практическая сложность — путаница между авторизацией на уровне управления (control-plane) и на уровне данных (data-plane). Именно здесь многие в остальном сильные команды теряют дни. Роли Azure RBAC на ресурсах не предоставляют автоматически доступ к документам, а роли данных Cosmos не дают администрирования аккаунта. Если ваша команда явно не документирует это разделение в runbook-ах, вы будете продолжать получать хрупкие развёртывания и трудноотлаживаемые 403-е ошибки.&lt;/p&gt;
&lt;p&gt;Моя оценочная рекомендация для производственных команд проста:&lt;/p&gt;
&lt;p&gt;Начинайте с Data Reader для путей чтения и Data Contributor только там, где записи действительно необходимы.&lt;/p&gt;
&lt;p&gt;Расширяйте область действия широко только тогда, когда у вас одна граница приложения на аккаунт.&lt;/p&gt;
&lt;p&gt;Если вы делите аккаунт между сервисами, сужайте область действия рано, до границ базы данных или контейнера, а не ждите давления аудита.&lt;/p&gt;
&lt;p&gt;Это одно из тех решений, которое накапливается со временем. Когда вы подключаете ваше .NET-приложение через &lt;code&gt;DefaultAzureCredential&lt;/code&gt; и конфигурацию только с эндпоинтом, каждое окружение становится чище: локальное, CI, staging и prod. Вы также ускоряете реагирование на инциденты, потому что можете рассуждать о правах через назначения ролей, а не искать таинственные ключи.&lt;/p&gt;
&lt;p&gt;Статья также намекает на то, что зрелым командам стоит принять: права доступа как итеративный дизайн, а не как разовую настройку. Вы можете начать достаточно широко, чтобы доставить продукт, а затем сужать через телеметрию и ревью доступа. Минимальные привилегии — это не философская конечная точка, а привычка поставки.&lt;/p&gt;
&lt;p&gt;Если вы примете от этого поста только одну вещь, пусть это будет: сначала уберите секреты, потом оптимизируйте роли. Команды, которые меняют этот порядок местами, обычно застревают на совещаниях. Команды, которые сначала убирают секреты, обычно доставляют продукт, а затем укрепляют его.&lt;/p&gt;
&lt;p&gt;В 2026 году доступ к данным без секретов — это не продвинутый паттерн. Это минимальный ответственный стандарт для серьёзных .NET-систем на Azure.&lt;/p&gt;</content:encoded></item></channel></rss>