Назад | Перейти на главную страницу

Разрешения Azure в крупных организациях

Я знаю, что этот вопрос немного субъективен. Я хочу просто спросить, как типичные крупные организации настраивают свои облачные разрешения. Меня особенно интересуют реализации в Azure.

Я разработчик в крупной медицинской компании (20 тыс. Сотрудников + 1-2 тыс. ИТ-специалистов). Мы развернули нашу собственную реализацию Azure, но практически не предоставили разработчикам разрешений на лазурный портал. Если мне нужна инфраструктура для проектов, мне нужно отправить тикет, чтобы запросить ее. Как только я получу инфраструктуру, я ничего не могу с ней сделать на портале. Если мне нужно создать несколько ролей приложения Azure Active Directory или если я хочу внести изменения в свою службу приложений (например, включить Managed Service Identities), мне нужно отправить заявку в нашу команду Cloud Intrastructure. Это типично или другие крупные организации предоставляют разработчикам больше привилегий (особенно в непроизводственной среде)?

С точки зрения разработчика, наша установка - безумие. Я заканчиваю тем, что пишу сценарии PowerShell и отправляю их в билетах людям, занимающимся инфраструктурой (или иногда администраторам Active Directory), и они в конечном итоге выполняют сценарии, не понимая, что они делают.

У меня есть ощущение, что это, вероятно, артефакт культуры нашей компании, но, возможно, нет. Предоставление разработчикам 0 разрешений на лазурном портале - обычное дело?

Хотя мне не доводилось сталкиваться с реализациями Azure такого размера, это похоже на то, что произошло бы в большой специализированной / разрозненной ИТ-организации с тяжелыми процессами.

  • Докажите владельцам процессов, что это снижает вашу производительность при предоставлении решений.
  • Изучите процессы и причины их существования: какие риски они снижают и какой опыт необходимо задействовать.
  • Предложите компромисс, например, больший доступ в среде разработки, но не вмешивайтесь в продвижение и тестирование.
  • Найдите и создайте инструменты для документирования и выполнения одинаковых изменений в разработке, тестировании и продукте. «Инфраструктура как код», если хотите так назвать.
  • Укрепляйте доверие, помогая точно выполнять изменения и поддерживать стабильную среду.

Вы называете это безумием, другие меняют контроль. Когда только администраторы каталогов могут редактировать роли, это точка контроля безопасности. Процесс утверждения новой инфраструктуры сводит к минимуму непредвиденные расходы при поступлении счета. Документирование изменений важно, чтобы ссылаться на них, когда что-то неизбежно ломается, а причина неизвестна.

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