С одной стороны, перенос в облако приложений облегчил жизнь предприятиям, потому что отпала необходимость поддерживать локальную инфраструктуру. С другой, работа с софтом в мультиоблаке стала настоящим кошмаром в плане управления привилегиями. Коммерческий директор Ermetic Арик Гомановски дает на портале eWeek советы, как справиться с этой проблемой.

Предприятия хотят справиться с бесконтрольно растущим числом облачных аккаунтов, разрастанием учетных данных и избыточностью привилегий. Gartner бьет тревогу: причиной 75% проблем в обеспечении безопасности облачных сред к 2023 г.станет неправильное управление идентификационными данными, доступом и привилегиями. Пришло время справиться с этой проблемой.

Четыре столпа прав доступа

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

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

Сложность идентификаторов зависит от того, какую инфраструктуру публичного облака вы используете; каждая облачная платформа управляет идентификационными данными по-разному. Между тем многие организации также используют локальные системы идентификации, которые являются внешними по отношению к поставщику облачных услуг. В гибридных средах пользователи работают с двумя (или более) типами идентификации: идентификацией для конкретной облачной платформы и объединенной идентификацией для доступа к облачной инфраструктуре через локальные системы идентификации.

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

Разрастание прав доступа

Привилегии могут предоставляться субъектам различными способами, что еще больше усложняет управление ими.

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

Цепочки. В этом сценарии идентификатору по мере выполнения работы можно присваивать дополнительные разрешения. Предприятию следует проанализировать, как организована традиционная эскалация (повышение) привилегий в его системе. Если присвоенный пользователю идентификатор имеет больше привилегий — он мгновенно их получает. То же самое происходит в облаке, когда идентификатор, связанный с приложением, начинает работать от имени пользователя.

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

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

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

Как управлять разрешениями

Управление разрешениями начинается с обеспечения наблюдаемости. Предприятию нужно отслеживать все человеческие и машинные идентификаторы в среде. Оно должно обладать возможностью сопоставлять все структуры разрешений, идентификационные данные и ресурсы, чтобы ответить на один основной вопрос: кто может получить доступ к конфиденциальным данным в его среде? Ответ на этот вопрос требует сопоставления разрешений и анализа более широкого контекста безопасности ресурсов, включая доступ к сети и кто может обновлять ее конфигурацию. Вы должны иметь возможность удалять устаревший доступ и делать это в масштабе. В большинстве случаев количество разрешений, которые действительно требуются среде, составляет от 10 до 20% от их фактического количества.

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

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

Если вы используете несколько облачных платформ, инструменты одного облачного провайдера не смогут управлять идентификаторами и разрешениями в других облачных инфраструктурах.

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