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

Когда дело доходит до защиты инженерного доступа к облачным средам, таким как AWS, GCP и Azure, большинство предприятий снижают риски доступа, используя комбинацию решений, каждое из которых имеет как преимущества, так и ограничения.

Виртуальные частные сети. Хотя виртуальные частные сети удаленного доступа устраняют риск атак MITM, они не могут гарантировать безопасный доступ к уязвимым средам, включающим сотни серверов. VPN-шлюзы очень небезопасны, потому что они обеспечивают полный доступ ко всем ресурсам в сети с подключением уровня 3.
Статическая сегментация: разделение сети может быть реализовано через VLAN или внутренние группы безопасности. Но шаблоны классификации для сегментации чрезвычайно сложны и требуют большой настройки, а статическая сегментация также не позволяет использовать реальные, детализированные элементы управления и обычно дает пользователям доступ к более широким сегментам, чем им на самом деле нужно.
Белый список IP-адресов: при правильной реализации белый список IP-адресов в группе безопасности или брандмауэре может быть эффективной стратегией в облачных средах. Но управление белым списком создает огромные накладные расходы. Динамические IP-адреса и изменения местоположения требуют постоянного обновления. Если белый список не будет строго соблюдаться, наиболее конфиденциальные ресурсы компании скоро будут перегружены.
Ключевой менеджмент. Ключи шифрования - это эффективный метод мониторинга активности пользователей на сервере. Но для управления ключами требуются специальные инструменты для создания, управления и контроля учетных записей пользователей. Несмотря на все наши усилия, ключи и пароли все же могут быть случайными.
На эти устоявшиеся решения больше нельзя полагаться для безопасного доступа к DevOps. По мере того, как компании переходят на новую инфраструктуру, методологии и инструменты, меры безопасности и стандарты доступа должны измениться соответствующим образом.

Появился новый подход к безопасности, Zero-Trust Network Access (ZTNA), который сосредоточен на предотвращении утечек данных за счет недоверия никому внутри или за пределами сетевой архитектуры организации. ZTNA запрещает сетевое подключение всем пользователям, машинам и приложениям до тех пор, пока они не будут явно проверены.

Этого можно добиться за счет: Обеспечение доступа с минимальными привилегиями, ограничивающего доступ только к прикладному уровню (уровень 7 OSI), и предоставление доступа только после выполнения строгой контекстной аутентификации пользователя.
Предотвращение видимости внутренних ресурсов посредством «очернения центра обработки данных»
Использование сквозного зашифрованного туннеля с взаимным TLS
Мониторинг каждого сеанса пользователя от попытки доступа до активности в сеансе
Подход ZTNA решает многие проблемы удаленного доступа, обеспечивая безопасное, гибкое и бесперебойное подключение. Однако технологически ориентированные компании с большими группами инженеров, техподдержки и ИТ могут по-прежнему испытывать трудности с поддержкой масштабной работы с динамическими серверами, сохраняя при этом разумный уровень административных накладных расходов и беспроблемное взаимодействие с пользователем.