Dynamics 365 и Azure без паролей: Managed Identity и Key Vault на практике
При разработке интеграций с Dynamics 365, Dataverse и Azure постоянно возникает вопрос аутентификации. Логины и пароли, Client Secrets, API Keys и Connection Strings приходится где-то хранить, контролировать и периодически обновлять.
Особенно актуальной эта проблема становится сегодня, когда AI-инструменты получают доступ к локальному коду и репозиториям. Чем меньше секретов хранится в коде и локальных конфигурациях, тем безопаснее процесс разработки.
В этой статье рассмотрим, как использовать Managed Identity и Azure Key Vault, чтобы минимизировать хранение паролей и секретов и при этом сохранить удобную работу как в Azure, так и локально.
А узнать больше можно в нашем видео:
Какие подключения мы используем
В повседневной разработке интеграции могут работать через разные Azure-ресурсы:
Azure Functions;
Azure WebJobs;
Web Apps и Web API;
консольные приложения и утилиты.
Они взаимодействуют с Dynamics 365/Dataverse, Azure OpenAI, Storage и другими Azure-сервисами, а также с внешними системами, например Jira или Twilio.
Практически в каждом таком сценарии необходимо решить одну задачу: как безопасно авторизовать приложение в нужном сервисе.
Почему традиционные способы создают проблемы
Самый очевидный вариант — логин и пароль. Но пароль может истечь, его необходимо обновлять во всех местах использования, а MFA дополнительно усложняет применение такого подхода в интеграциях.
Более распространенный вариант — Client ID + Client Secret. Он удобнее, но Client Secret также имеет ограниченный срок действия. Через год или два необходимо помнить, какие приложения его используют и где его нужно заменить.
Похожая ситуация возникает с:
API Keys;
Connection Strings;
секретами сторонних сервисов.
Чем больше environments и интеграций, тем сложнее контролировать все эти credentials.
Managed Identity: подключение без пароля
Для Azure-сервисов эту проблему помогает решить Managed Identity.
Упрощенно Managed Identity можно представить как специальную identity в Azure, которой предоставляется доступ к конкретным ресурсам.
Главное отличие заключается в том, что разработчику не нужно создавать и хранить для нее:
логин и пароль;
Client Secret;
другие credentials.
Azure самостоятельно получает необходимые токены для взаимодействия между ресурсами.
Например:
Azure Function → Managed Identity → Dataverse
или:
Azure Function → Managed Identity → Azure Service
При этом для каждого ресурса можно отдельно определить необходимые права.
Еще одно преимущество — сама Managed Identity не требует отдельной оплаты.
Как подключить Managed Identity к Dynamics 365
После создания Managed Identity ее необходимо предоставить Dynamics 365/Dataverse как Application User.
Процесс выглядит следующим образом:
Создаем Managed Identity в Azure.
Получаем ее Client ID.
Открываем нужный Environment в Power Platform.
Создаем Application User.
Указываем соответствующий ID.
Назначаем Business Unit и Security Role.
Важно придерживаться принципа минимально необходимых привилегий. Назначать каждому такому пользователю роль System Administrator без необходимости — не лучшая практика.
Лучше создать отдельную Security Role с теми правами, которые действительно нужны конкретной интеграции.
Как работать локально в Visual Studio
У Managed Identity есть важное ограничение: ее нельзя использовать локально так же, как внутри Azure.
При локальном debugging приложение может работать от Developer Account, настроенного в Visual Studio.
Таким образом:
в Azure: Application → Managed Identity → Resource
локально: Application → Developer Account → Resource
Это позволяет использовать практически один и тот же код и для локальной разработки, и после deployment в Azure.
При этом необходимо учитывать права. Developer Account и Managed Identity могут иметь разные Security Roles, поэтому поведение приложения локально и в Azure необходимо проверять отдельно.
Что делать с секретами внешних сервисов
Managed Identity хорошо решает проблему доступа к Azure-ресурсам, но существуют внешние системы — например Jira, Twilio и другие сервисы, которые используют собственные API Keys или Secrets.
Для таких данных можно использовать Azure Key Vault.
Вместо хранения секретов в:
коде;
Local Settings;
Environment Variables с чувствительными данными;
локальных конфигурационных файлах,
они сохраняются централизованно в Key Vault.
Managed Identity получает право читать необходимые секреты, а Developer Account может получить аналогичный доступ для локальной разработки.
В коде при этом достаточно знать URI Key Vault — сам URI секретом не является.
Что является секретом, а что нет
При внедрении такого подхода важно разделить конфигурационные данные на две категории.
Не являются секретами:
URL;
User ID;
Client ID Managed Identity;
другие публичные идентификаторы.
Являются секретами:
пароли;
API Keys;
токены;
Connection Strings с credentials;
ключи сторонних сервисов.
Нет необходимости помещать в Key Vault абсолютно всю конфигурацию. Там должны храниться именно чувствительные данные.
Преимущества подхода
Связка Managed Identity + Key Vault позволяет значительно упростить управление credentials.
Основные преимущества:
меньше паролей и секретов в локальной разработке;
отсутствие Client Secret rotation для Managed Identity;
меньше риска случайно закоммитить credentials в репозиторий;
отдельные права для каждого ресурса;
возможность использовать единый подход для Azure Functions, WebJobs, Web Apps и других приложений;
централизованное хранение секретов внешних сервисов.
При этом стоит учитывать, что изменения прав Managed Identity могут применяться не мгновенно, а доступ Developer Account для локальной разработки необходимо настраивать отдельно.
Краткий чек-лист внедрения
Перед переходом на такой подход стоит:
Определить все внешние подключения приложения.
Разделить обычные конфигурационные данные и секреты.
Использовать Managed Identity там, где сервис ее поддерживает.
Хранить необходимые внешние секреты в Azure Key Vault.
Создать Application User и необходимые Security Roles в Dataverse.
Настроить Developer Account для локальной разработки.
Проверить права и работу приложения как локально, так и после deployment в Azure.
Заключение
Отказ от хранения паролей и Client Secrets — это не только вопрос удобства. Чем больше интеграций, environments и инструментов получают доступ к исходному коду, тем важнее минимизировать количество credentials, которыми приходится управлять вручную.
Managed Identity позволяет организовать доступ между Dynamics 365/Dataverse и Azure без хранения постоянных credentials, а Azure Key Vault дополняет этот подход там, где секреты все-таки необходимы.
В результате мы получаем более управляемую архитектуру: меньше секретов в коде, меньше ручной ротации и более четкий контроль доступа к каждому ресурсу.
Comments