Безопасность Azure: Managed Identity и Key Vault

Безопасность Azure: как защитить ваши сервисы

В предыдущих частях мы разобрали, как перемещать данные и оркестрировать процессы. Но на собеседовании вас обязательно спросят: как это всё защитить? Эта статья закрывает пробел, связывая безопасность с уже знакомыми сервисами: Service Bus, Function Apps и Logic Apps. Вы узнаете, как Managed Identity и Key Vault радикально упрощают управление секретами и делают вашу архитектуру по-настоящему безопасной.

Managed Identity: ваш пропуск в мир Azure

Managed Identity — это функция Azure, которая даёт ресурсу (Function App, Logic App, VM) автоматически управляемую учётную запись в Azure AD. Это позволяет ресурсу аутентифицироваться в других сервисах Azure без хранения паролей, строк подключения или сертификатов в коде.

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

Два типа Managed Identity

• System-assigned — привязан к жизненному циклу конкретного ресурса: создаётся вместе с ресурсом, удаляется вместе с ним, не может использоваться другими ресурсами.
• User-assigned — создаётся как отдельный ресурс Azure, а затем назначается одному или нескольким ресурсам. Он живёт независимо от жизненного цикла конкретного ресурса — удобно, когда несколько Function Apps должны использовать одну и ту же учётную запись и права доступа.

// Включение system-assigned identity в портале Azure:
// Function App -> Identity -> System assigned -> Вкл -> Сохранить
// Использование в C#: DefaultAzureCredential автоматически
// обнаруживает и использует Managed Identity при работе в Azure.
using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

var client = new SecretClient(
    new Uri("https://your-vault.vault.azure.net/"),
    new DefaultAzureCredential()
);

KeyVaultSecret secret = await client.GetSecretAsync("SqlConnectionString");
// В этом коде нет ни пароля, ни строки подключения.
// Managed Identity Function App и есть учётные данные.
// Назначение прав: Azure RBAC, а не хранимый ключ.
// Key Vault -> Управление доступом (IAM) -> Добавить назначение ролей.
// Роль: Key Vault Secrets User
// Назначить: Managed Identity вашей Function App

Компромисс: Managed Identity действительно почти всегда лучше, чем хранимый секрет для аутентификации Azure-сервисов. Ограничение — он работает только для аутентификации в Azure или сервисах, поддерживающих Azure AD. Если сторонний API принимает только API-ключ, его всё равно придётся где-то хранить — и тут на помощь приходит Key Vault.

Связь с предыдущими частями: Function App с триггером Service Bus может аутентифицироваться в Service Bus через Managed Identity, а не через строку подключения Shared Access Signature. Тот же паттерн применяется при записи в Azure SQL или вызове другой Function App из Logic Apps. Каждый переход между сервисами в ваших конвейерах — кандидат на использование Managed Identity.

Azure Key Vault: банковская ячейка для секретов

Azure Key Vault — это управляемый сервис для безопасного хранения секретов, ключей шифрования и сертификатов. В связке с Managed Identity он закрывает те случаи, когда секрет нельзя устранить полностью.

Представьте банковское хранилище: ваше приложение имеет ключ-карту (Managed Identity), которая позволяет войти и запросить конкретный секрет, но само приложение не хранит секрет.

Managed Identity устраняет необходимость хранить строки подключения Azure SQL (при использовании Azure AD auth), строки подключения Service Bus (при RBAC) и ключи доступа к Storage (при RBAC). Но в Key Vault всё ещё должны жить: API-ключ партнёра (Salesforce или ServiceNow не знают, что такое Managed Identity), секрет подписи вебхука стороннего сервиса и любые учётные данные для систем вне Azure.

// Ссылка на Key Vault в конфигурации App Service —
// для этого паттерна не нужен SDK.
// App Service -> Конфигурация -> Параметры приложения
// Имя: SalesforceApiKey
// Значение: @Microsoft.KeyVault(SecretUri=https://your-vault.vault.azure.net/secrets/SalesforceApiKey/)
// Читается как обычная настройка:
var apiKey = builder.Configuration["SalesforceApiKey"];
// App Service автоматически разрешает ссылку на Key Vault
// при запуске, используя СВОЮ СОБСТВЕННУЮ Managed Identity
// для аутентификации в Key Vault — два понятия работают вместе.

Компромисс: Key Vault имеет реальные затраты за операцию и ограничения по скорости. Он для настоящих секретов, а не для общих настроек вроде размера страницы или флагов функций — те должны жить в обычной конфигурации App Service.

Связь с предыдущими частями: В сценарии из части 2, где Logic App опрашивает REST API партнёра, API-ключ партнёра — именно тот секрет, который должен храниться в Key Vault. Managed Identity не может его устранить, так как партнёрская система не имеет понятия об Azure AD.

VNet Integration: приватный маршрут для трафика

VNet Integration позволяет PaaS-сервисам Azure (Function Apps, Logic Apps Standard, App Service) отправлять исходящий трафик через виртуальную сеть, а не через публичный интернет. Это значит, что они могут достигать ресурсов, которые принимают трафик только из частной сети.

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

Без VNet Integration Function App достигает Azure SQL через публичный интернет, и брандмауэр Azure SQL должен разрешать доступ с какого-то публичного IP-диапазона. С VNet Integration Function App идёт к Azure SQL через приватный маршрут VNet, а Azure SQL можно настроить на отклонение всего публичного трафика.

// Включение VNet Integration в портале Azure:
// Function App -> Сеть -> VNet Integration -> Добавить VNet
// Выберите существующую VNet и делегированную подсеть.
// Это влияет на ИСХОДЯЩИЕ вызовы из Function App —
// вызовы к Azure SQL, Service Bus, Key Vault и другим сервисам
// теперь могут идти через VNet, если те также настроены
// на приём приватного трафика (через Private Endpoints).

Компромисс: VNet Integration требует тарифного плана Premium или выше для App Service / Function App. Он недоступен на уровне Consumption, так что это реальное решение по стоимости и архитектуре, а не просто галочка.

Связь с предыдущими частями: Function App, обрабатывающая чувствительные данные заказов из сценариев части 2, может использовать VNet Integration для доступа к Azure SQL полностью приватно. Даже если HTTP-эндпоинт Function App будет скомпрометирован, злоумышленник не сможет достучаться до базы данных через публичный интернет — такого пути просто не существует.

Private Endpoints vs Service Endpoints: ловушка на собеседовании

Обе функции позволяют трафику из VNet достигать PaaS-сервисов Azure более прямым путём, чем через публичный интернет, но работают они принципиально по-разному. Их путают на собеседованиях чаще всего.

Service Endpoint — трафик идёт на публичный IP-адрес сервиса, но по оптимизированному маршруту. Сервис можно настроить на приём трафика только из определённых подсетей VNet. У сервиса остаются публичный IP и публичное DNS-имя, а брандмауэр (например, Azure SQL) ограничивает доступ.

Private Endpoint — сервис Azure получает настоящий приватный IP-адрес внутри вашей VNet. DNS-резолвинг сервиса из VNet теперь даёт приватный IP, а не публичный. Сервис можно настроить на полный отказ от публичного трафика — не просто ограничение по источнику, а отсутствие публичного пути в принципе.

Представьте Service Endpoint как VIP-полосу на входе в публичное здание: вы приходите к тому же зданию, но через отдельную дверь. Private Endpoint — это когда здание целиком перенесли на охраняемую территорию, и публичного входа больше не существует.

// Настройка Private Endpoint в портале Azure:
// Azure SQL Server -> Сеть -> Приватный доступ
// -> Создать Private Endpoint -> выбрать VNet + подсеть
// После этого DNS-имя SQL-сервера резолвится в ПРИВАТНЫЙ IP
// (например, 10.0.1.5) при запросе из VNet, а не в публичный.
// Затем можно включить "Запретить публичный сетевой доступ" —
// сервер становится недоступен из интернета полностью,
// независимо от правил брандмауэра, так как публичного пути нет.

Компромисс: Private Endpoints стоят дороже (почасовая оплата за каждый эндпоинт) и добавляют сложности с DNS — часто требуется Private DNS Zone. Service Endpoints проще и бесплатны, но дают более слабую границу безопасности, так как сервис технически остаётся публично достижимым.

Связь с предыдущими частями: Service Bus, Azure SQL и Key Vault — каждая точка выхода и зависимости в конвейерах из частей 1 и 2 — могут быть настроены с Private Endpoint. Это значит, что весь конвейер можно перестроить так, чтобы он не касался публичного интернета ни на одном внутреннем шаге, а публично доступной оставалась только точка входа (например, APIM).

Сетевые группы безопасности (NSG)

Сетевая группа безопасности (NSG) — это набор правил брандмауэра, применяемых на уровне подсети или отдельного сетевого интерфейса. Они контролируют входящий и исходящий трафик по IP-адресу источника и назначения, порту и протоколу.

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

Ключевые концепции NSG, которые нужно знать точно:

• Правила имеют приоритет от 100 до 4096. Меньшее число проверяется первым, и первое совпавшее правило побеждает.
• Правила задают направление (входящий/исходящий), источник, назначение, порт, протокол и действие (разрешить/запретить).
• Существуют правила по умолчанию, которые нельзя удалить, но можно переопределить правилом с более высоким приоритетом. Они разрешают трафик внутри VNet, трафик от Azure Load Balancer и запрещают весь остальной входящий трафик.
• NSG можно применять на двух уровнях одновременно: на уровне подсети (влияет на всё в ней) и на уровне сетевого интерфейса (влияет на конкретный ресурс). Если заданы оба, трафик должен пройти через оба.

// Пример правила NSG (концептуально, через портал или CLI)
Priority: 100
Name: Allow-HTTPS-Inbound
Direction: Inbound
Source: Internet
Destination: 10.0.1.0/24 (конкретная подсеть)
Port: 443
Protocol: TCP
Action: Allow

Priority: 200
Name: Deny-All-Other-Inbound
Direction: Inbound
Source: *
Destination: *
Port: *
Protocol: *
Action: Deny

Компромисс: NSG — это базовый уровень безопасности, но они не заменяют Private Endpoints. Они работают на уровне сети, а не приложения, и их легко misconfigure. Однако это обязательный элемент защиты периметра.

Практический вывод: что делать прямо сейчас

Начните с аудита ваших существующих Azure-ресурсов. Найдите все места, где в коде или конфигурации хранятся строки подключения или ключи. Замените их на Managed Identity, где это возможно. Для секретов, которые нельзя устранить, создайте Key Vault и перенесите их туда. Затем настройте VNet Integration для критичных Function Apps и добавьте Private Endpoints для Azure SQL и Service Bus. Наконец, убедитесь, что NSG настроены на принцип «запрещено всё, что не разрешено явно». Эти шаги кардинально повысят безопасность вашей архитектуры.