Доступ в Azure — это система, которая отвечает на один вопрос: «кто и что может делать». Хотите прочитать файл из хранилища, запустить машину, отправить сообщение в очередь — каждый раз Azure сверяется: а разрешено ли вам это.

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

Entra ID против RBAC

В Azure доступ делится на две связанные, но разные системы, и новички их путают.

Microsoft Entra ID (бывший Azure AD) отвечает на вопрос «кто ты» — это каталог удостоверений: пользователи, группы, приложения. Через него входят люди и регистрируются программы. Он про аутентификацию — подтверждение личности.

Azure RBAC (role-based access control) отвечает на вопрос «что тебе можно делать с ресурсами». Он про авторизацию — выдачу прав. Entra ID говорит «это точно ты», а RBAC — «тебе разрешено создавать виртуальные машины в этой группе ресурсов».

Роли и назначения

В RBAC права выдаются через пару «роль + назначение».

Роль (role definition) — набор разрешений. Есть широкие встроенные роли:

  • Owner — всё, включая раздачу прав другим;
  • Contributor — создавать и менять ресурсы, но не раздавать доступ;
  • Reader — только смотреть.

И множество узких сервисных ролей вроде «Storage Blob Data Contributor» (доступ к данным в Blob Storage) или «Key Vault Secrets User» (читать секреты). Узкие роли — то, что нужно на практике.

Назначение роли (role assignment) — «кому — какую роль — на каком уровне». Роль выдают на подписку, группу ресурсов или отдельный ресурс, и права наследуются вниз: роль на группу ресурсов действует на все ресурсы внутри неё. Обычно доступ выдают на уровне группы ресурсов — удобная граница.

az role assignment create --assignee <id> \
  --role "Storage Blob Data Contributor" \
  --scope /subscriptions/<sub>/resourceGroups/my-rg

Managed identity: доступ без ключей

Главное правило: ваш код не должен носить с собой пароли и ключи. В Azure это решает управляемое удостоверение (managed identity) — учётная запись для сервиса, которой платформа сама выдаёт временные токены.

Бывает двух видов:

  • System-assigned — привязана к конкретному ресурсу (виртуальной машине, функции) и живёт вместе с ним;
  • User-assigned — отдельная сущность, которую можно навесить на несколько ресурсов.

Приложение с managed identity получает токен прямо из платформы, а библиотека Azure (SDK) находит его автоматически. В коде — ни одного секрета. Это тот же принцип, что instance profile в AWS.

Для сценариев вне Azure (например, CI, живущий не в облаке) используют service principal — учётную запись приложения с секретом или сертификатом. Такой секрет — долгоживущий, поэтому его держат в защищённом хранилище CI, а не в git, и регулярно ротируют.

Least privilege — минимум прав

Главный принцип всей безопасности: давать ровно столько прав, сколько нужно, и ни ролью больше.

Самый частый дефект новичка — выдать сервису Contributor или Owner на всю группу ресурсов «чтобы просто заработало». Так делают, чтобы не возиться, — и именно это потом превращается в инцидент: одна утёкшая учётка открывает всю группу.

На практике least privilege — итеративный процесс: начните узко (только нужные сервисные роли), запустите, посмотрите по отказам, чего не хватает, добавьте недостающую роль. Дольше, чем выдать всё сразу, но именно это отделяет нормальную работу от заголовка про утечку.

Где это применяется

Доступ — это слой «кто что может делать» поверх сетевого слоя «кто до кого вообще может достучаться». Вместе они дают полноценную защиту: минимальная сеть плюс минимальные права.

Где вы столкнётесь с этим сразу:

  • Любой ваш сервис (виртуальные машины, функции, контейнеры) получает доступ к другим сервисам через managed identity.
  • Конвейеры доставки кода работают через service principal или federated-удостоверение, а не через зашитые ключи.
  • Секреты и шифрование — соседняя тема: где хранить пароли, в безопасности и наблюдаемости.

Типичные ошибки новичков:

  • Класть ключи или секрет service principal в код или git вместо managed identity.
  • Выдавать Contributor/Owner широко «чтобы заработало», а потом забыть сузить.
  • Путать: аутентификация (Entra ID) и авторизация (RBAC) — это разные вещи; «вошёл» не значит «всё разрешено».

Что учить дальше: где хранят секреты и как шифруют данные — в безопасности и наблюдаемости; как роли описываются в инфраструктуре-как-коде — в Bicep, ARM и Terraform. Модель близка к IAM в AWS — роли и временные токены вместо вечных ключей устроены аналогично.