Разрешения Azure в крупных организациях
Я знаю, что этот вопрос немного субъективен. Я хочу просто спросить, как типичные крупные организации настраивают свои облачные разрешения. Мне особенно интересны реализации Azure.
Я являюсь разработчиком в крупной медицинской компании (20 тыс. + Сотрудники 1-2 тыс. ИТ-специалистов). Мы развернули собственную реализацию Azure, но практически не предоставили разработчикам разрешения на портал Azure. Если мне нужна инфраструктура для проектов, мне нужно отправить заявку на ее запрос. Как только я получу инфраструктуру, я ничего не могу сделать с ней на портале. Если мне нужно создать несколько ролей приложений Azure Active Directory или если я хочу внести изменения в службу приложений (например, включить идентификацию управляемых служб), мне нужно отправить заявку в нашу команду Cloud Intrastructure. Это типично или другие крупные организации предоставляют разработчикам больше привилегий (особенно в непроизводственной среде)?
С точки зрения разработчика, наша установка - это безумие. Я заканчиваю тем, что пишу сценарии powershell и отправляю их в тикеты людям, работающим в инфраструктуре (или иногда администраторам Active Directory), и они в конечном итоге исполняют сценарии, не понимая, что они делают.
У меня есть ощущение, что это, вероятно, артефакт культуры наших компаний, но, возможно, нет. Предоставление разработчикам 0 прав доступа на портале Azure - это типичная вещь?
1 ответ
Хотя я не сталкивался с реализациями Azure такого размера, это звучит точно так же, как то, что произошло бы в большой специализированной / разрозненной ИТ-организации с интенсивным процессом.
- Обращайте внимание владельцев процессов на то, что это снижает вашу продуктивность в предоставлении решений.
- Изучите процессы и почему они существуют: какие риски они снижают и какой опыт необходимо задействовать.
- Предложите компромисс, такой как больший доступ в среде разработки, но держите руки подальше и тестируйте.
- Найдите и создайте инструменты для документирования и выполнения точно таких же изменений в dev, test и prod. "Инфраструктура как код", если вы хотите это так назвать.
- Создайте доверие, помогая точно выполнять изменения, поддерживая стабильную среду.
Вы называете это безумием, другие меняют контроль. Когда только администраторы каталогов могут редактировать роли, это точка контроля безопасности. Процесс одобрения для новой инфраструктуры сводит к минимуму неожиданность затрат, когда счет приходит. Документирование изменений важно ссылаться, когда неизбежно что-то ломается и причина неизвестна.
Вероятно, слишком тяжелый процесс для среды разработки, да. Хотя до тех пор, пока не узнаешь, насколько хорошо кто-то работает, я лично не хотел бы доверять им тестирование, не говоря уже о прод.