В сегодняшней быстро развивающейся среде SaaS основное внимание уделяется пользователям-людям. Это одна из наиболее уязвимых областей в управлении безопасностью SaaS и требует строгого управления ролями пользователей и разрешениями, мониторинга привилегированных пользователей, их уровня активности (бездействующий, активный, гиперактивный), их типа (внутренний / внешний), являются ли они новичками, перемещающимися или увольняющимися, и многого другого.
Неудивительно, что усилия по обеспечению безопасности в основном были ориентированы на человека. Варианты конфигурации включают такие инструменты, как MFA и SSO для аутентификации человека. Управление доступом на основе ролей (RBAC) ограничивает уровень доступа; рекомендации по сложности пароля блокируют доступ неавторизованных пользователей к приложению.
Тем не менее, в мире SaaS нет недостатка в доступе, предоставляемом нечеловеческим субъектам, или, другими словами, сторонним приложениям, подключенным к интернету.
Учетные записи служб, авторизации OAuth и ключи API - это лишь некоторые из идентификаций нечеловеческих объектов, для которых требуется доступ SaaS. Если смотреть через призму приложения, учетные записи нечеловеческих объектов похожи на учетные записи людей. Они должны проходить аутентификацию, получать набор разрешений и отслеживаться. Однако, поскольку они нечеловеческие, обеспечению безопасности уделяется значительно меньше внимания.
Рисунок 1: Области требуемых разрешений Calendly
Другие нечеловеческие учетные записи предполагают обмен данными между двумя или более приложениями. SwiftPOS - это приложение и устройство для торговых точек (POS) для баров, ресторанов и торговых точек. Данные, собираемые POS, передаются на платформу бизнес-аналитики, такую как Microsoft Power BI, где они обрабатываются и анализируются. Данные передаются из SwiftPOS в Power BI через учетную запись, не являющуюся человеком.
Приложения SaaS также используют разные подходы к управлению этими учетными записями. Некоторые включают нечеловеческие учетные записи в свой реестр пользователей, в то время как другие хранят и отображают данные в другом разделе приложения, что упрощает их просмотр.
Учетные записи людей могут быть аутентифицированы через MFA или единый вход. Учетные записи, не являющиеся людьми, напротив, аутентифицируются один раз и о них забывают, если не возникает проблем с интеграцией. У людей также есть типичные модели поведения, такие как вход в приложения в рабочее время. Учетные записи, не являющиеся людьми, часто получают доступ к приложениям в непиковое время, чтобы снизить сетевой трафик и нагрузку. Когда человек входит в свой SaaS в 3 часа ночи, это может вызвать расследование; когда нечеловек выходит в сеть в 3 часа ночи, это просто обычный бизнес.
Стремясь упростить управление учетными записями нечеловеческими лицами, многие организации используют один и тот же ключ API для всех интеграций. Чтобы облегчить это, они предоставляют ключу API широкие наборы разрешений для покрытия всех потенциальных потребностей организации. В других случаях разработчик использует свой собственный ключ API с высоким разрешением для предоставления доступа к нечеловеческой учетной записи, позволяя ей получать доступ ко всему в приложении. Эти ключи API функционируют как проходы общего доступа, используемые несколькими интеграциями, что делает их невероятно сложными для контроля.
Рисунок 2: Вредоносное приложение OAuth, обнаруженное с помощью SSPM Adaptive Shield
Учетные записи, не являющиеся людьми, требуют такой же видимости для служб безопасности, что и учетные записи людей, и должны управляться в том же реестре пользователей, что и их аналоги-люди. Благодаря унификации управления идентификацией намного проще просматривать доступ и разрешения и обновлять учетные записи независимо от того, кто является владельцем. Это также обеспечивает единый подход к управлению учетными записями. Организационные политики, такие как запрет на совместное использование учетных записей, должны применяться повсеместно. Учетные записи нечеловеческих пользователей должны быть ограничены определенными IP-адресами, которые предварительно утверждены в списке разрешенных, и им не следует предоставлять доступ через стандартные экраны входа в систему (UI login). Кроме того, разрешения должны быть адаптированы к конкретным потребностям приложений, а не быть широкими или соответствовать их человеческим аналогам.
ITDR также играет важную роль. Учетные записи, не являющиеся людьми, могут получать доступ к приложениям SaaS в любое время суток, но обычно они довольно последовательны в своих взаимодействиях. ITDR может обнаруживать аномалии в поведении, будь то изменения в расписании, тип данных, добавляемых в приложение, или действия, выполняемые нечеловеческой учетной записью.
Наглядность, предоставляемая SSPM учетным записям и ITDR поведению нечеловеческих личностей, важна для управления рисками и выявления угроз. Это важное действие для обеспечения безопасности приложений SaaS.
Неудивительно, что усилия по обеспечению безопасности в основном были ориентированы на человека. Варианты конфигурации включают такие инструменты, как MFA и SSO для аутентификации человека. Управление доступом на основе ролей (RBAC) ограничивает уровень доступа; рекомендации по сложности пароля блокируют доступ неавторизованных пользователей к приложению.
Тем не менее, в мире SaaS нет недостатка в доступе, предоставляемом нечеловеческим субъектам, или, другими словами, сторонним приложениям, подключенным к интернету.
Учетные записи служб, авторизации OAuth и ключи API - это лишь некоторые из идентификаций нечеловеческих объектов, для которых требуется доступ SaaS. Если смотреть через призму приложения, учетные записи нечеловеческих объектов похожи на учетные записи людей. Они должны проходить аутентификацию, получать набор разрешений и отслеживаться. Однако, поскольку они нечеловеческие, обеспечению безопасности уделяется значительно меньше внимания.
Примеры доступа нечеловеческих пользователей
Интеграция, вероятно, является самым простым способом понять, что такое нечеловеческий доступ к приложению SaaS. Calendly - это приложение, которое устраняет переадресацию электронных писем о назначении встреч, отображая доступность пользователя. Он интегрируется с календарем пользователя, считывает календарь для определения доступности и автоматически добавляет встречи. При интеграции с Google Workspace через авторизацию OAuth он запрашивает области, которые, среди прочего, позволяют ему просматривать, редактировать, делиться и удалять календари Google. Интеграция инициируется человеком, но Calendly не является человеком.
Рисунок 1: Области требуемых разрешений Calendly
Другие нечеловеческие учетные записи предполагают обмен данными между двумя или более приложениями. SwiftPOS - это приложение и устройство для торговых точек (POS) для баров, ресторанов и торговых точек. Данные, собираемые POS, передаются на платформу бизнес-аналитики, такую как Microsoft Power BI, где они обрабатываются и анализируются. Данные передаются из SwiftPOS в Power BI через учетную запись, не являющуюся человеком.
Проблема защиты нечеловеческих учетных записей
Управлять учетными записями нечеловеческих лиц и обеспечивать их безопасность не так просто, как кажется. Начнем с того, что у каждого приложения свой подход к управлению этими типами учетных записей пользователей. Некоторые приложения, например, отключают интеграцию OAuth, когда авторизовавший ее пользователь отключается от приложения, в то время как другие поддерживают соединение.Приложения SaaS также используют разные подходы к управлению этими учетными записями. Некоторые включают нечеловеческие учетные записи в свой реестр пользователей, в то время как другие хранят и отображают данные в другом разделе приложения, что упрощает их просмотр.
Учетные записи людей могут быть аутентифицированы через MFA или единый вход. Учетные записи, не являющиеся людьми, напротив, аутентифицируются один раз и о них забывают, если не возникает проблем с интеграцией. У людей также есть типичные модели поведения, такие как вход в приложения в рабочее время. Учетные записи, не являющиеся людьми, часто получают доступ к приложениям в непиковое время, чтобы снизить сетевой трафик и нагрузку. Когда человек входит в свой SaaS в 3 часа ночи, это может вызвать расследование; когда нечеловек выходит в сеть в 3 часа ночи, это просто обычный бизнес.
Стремясь упростить управление учетными записями нечеловеческими лицами, многие организации используют один и тот же ключ API для всех интеграций. Чтобы облегчить это, они предоставляют ключу API широкие наборы разрешений для покрытия всех потенциальных потребностей организации. В других случаях разработчик использует свой собственный ключ API с высоким разрешением для предоставления доступа к нечеловеческой учетной записи, позволяя ей получать доступ ко всему в приложении. Эти ключи API функционируют как проходы общего доступа, используемые несколькими интеграциями, что делает их невероятно сложными для контроля.
Рисунок 2: Вредоносное приложение OAuth, обнаруженное с помощью SSPM Adaptive Shield
Риски, которые добавляют нечеловеческие аккаунты в стек SaaS
Учетные записи нечеловеческих пользователей в основном не контролируются и имеют широкий диапазон разрешений. Это делает их привлекательной мишенью для субъектов угроз. Компрометируя любую из этих учетных записей, субъекты угрозы могут проникнуть в приложение незамеченными, что приведет к нарушениям, несанкционированным модификациям или сбоям в обслуживании.Принятие мер по защите учетных записей, не являющихся людьми
Используя платформу управления состоянием безопасности SaaS (SSPM) совместно с решениями для обнаружения угроз идентификации и реагирования на них (ITDR), организации могут эффективно управлять своими учетными записями нечеловеческих лиц и обнаруживать, когда они ведут себя аномально.Учетные записи, не являющиеся людьми, требуют такой же видимости для служб безопасности, что и учетные записи людей, и должны управляться в том же реестре пользователей, что и их аналоги-люди. Благодаря унификации управления идентификацией намного проще просматривать доступ и разрешения и обновлять учетные записи независимо от того, кто является владельцем. Это также обеспечивает единый подход к управлению учетными записями. Организационные политики, такие как запрет на совместное использование учетных записей, должны применяться повсеместно. Учетные записи нечеловеческих пользователей должны быть ограничены определенными IP-адресами, которые предварительно утверждены в списке разрешенных, и им не следует предоставлять доступ через стандартные экраны входа в систему (UI login). Кроме того, разрешения должны быть адаптированы к конкретным потребностям приложений, а не быть широкими или соответствовать их человеческим аналогам.
ITDR также играет важную роль. Учетные записи, не являющиеся людьми, могут получать доступ к приложениям SaaS в любое время суток, но обычно они довольно последовательны в своих взаимодействиях. ITDR может обнаруживать аномалии в поведении, будь то изменения в расписании, тип данных, добавляемых в приложение, или действия, выполняемые нечеловеческой учетной записью.
Наглядность, предоставляемая SSPM учетным записям и ITDR поведению нечеловеческих личностей, важна для управления рисками и выявления угроз. Это важное действие для обеспечения безопасности приложений SaaS.
