Защита доступа к облачной консоли. Отдельные админ-учетные записи, строгие политики и контроль действий администраторов

Доступ к облачной консоли — точка, где расходятся зоны ответственности действующих сторон. Провайдер отвечает за защиту каналов и инфраструктуры, заказчик — за то, кто и как заходит под его учетными записями. Однако на практике все гораздо сложнее. Безопасность самой консоли зависит от того, заложены ли необходимые меры в архитектуру платформы на этапе проектирования облачного решения поставщиком услуг. И все это сводится к регуляторике со стороны государства. По крайней мере, в России. Но обо всем по порядку.

Как должно быть построено облако

Инфраструктурный слой облачного решения должен проектироваться, как целостная архитектура, где каждый элемент работает на общую задачу — обеспечение защищенности, достаточной для размещения информационных систем максимальных классов защиты. Это означает, что платформа с самого начала строится на сертифицированных средствах защиты, прошедших оценку регулятора.

Здесь важно понимать российский подход. На Западе рынок ориентируется на международные стандарты: ISO/IEC 27017, CSA CCM, NIST SP 800-53. Это мощные фреймворки, но они носят рекомендательный характер. В нашей же стране существует обязательный набор нормативных требований от ФСТЭК России и ФСБ России — это императив, который нельзя обойти.

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

На практике защищенность инфраструктурного слоя обеспечивается следующим набором средств.

• Периметр и межсегментные границы контролируются многофункциональными межсетевыми экранами.
• Системы обнаружения и предотвращения вторжений работают как на периметре, так и внутри сегментов — с анализом трафика на прикладном уровне и возможностью ретроспективного разбора.
• Каналы за пределы контролируемой зоны закрыты сертифицированными средствами криптозащиты (СКЗИ).
• Антивирусная защита включает динамический анализ в изолированной среде.
• Контроль защищенности ведется на постоянной основе: управление уязвимостями, мониторинг конфигураций, контроль состава оборудования и машинных носителей, ограничение физического доступа.

Другими словами, все проектируется таким образом, чтобы давать командам ИБ на стороне заказчика понятную точку отсчета при выстраивании защиты прикладного уровня.

Доступ к облачной консоли: где проходит граница ответственности

Административный доступ к платформе должен осуществляться через защищенные каналы с использованием сертифицированных СКЗИ. Действия администраторов фиксируются системами сбора событий и могут быть проанализированы ретроспективно благодаря им.

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

В этом контексте стоит напомнить о правилах эксплуатации любого IT-сервиса корпоративного уровня (в том числе облачной консоли), которые как будто бы все заказчики знают, но не все соблюдают.

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

Статистика инцидентов нашей сервисной команды Astra Cloud подтверждает, что взломы происходят не из-за сложных zero-day уязвимостей. Скомпрометированная учетная запись администратора с единственным фактором защиты, общая учетная запись, или пароль, сохраненный в текстовом файле, — вот наиболее частые сценарии проникновения в контур управления. Хорошая новость в том, что такое происходит редко. Но это не отменяет ответственности заказчиков в таких случаях.

Вместо заключения

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

Выбор облака начинается не с политик доступа, а с вопроса: заложена ли безопасность в архитектуру платформы на этапе проектирования? Если нет, то инцидент станет лишь вопросом времени, независимо от того, насколько сложные пароли ставят администраторы. Если да, можно выстраивать защиту прикладного уровня и контролировать все процессы, с нею связанные.

Статью подготовил Николай Есипов, архитектор информационной безопасности «Группы Астра».