Система кибербезопасности Национального института стандартов и технологий США (NIST) является одним из важнейших в мире руководящих принципов по обеспечению безопасности сетей. Ее можно применять к любому количеству приложений, включая SaaS.
Одна из проблем, с которой сталкиваются те, кто отвечает за безопасность приложений SaaS, заключается в различных настройках, обнаруживаемых в каждом приложении. Это затрудняет разработку политики конфигурации, которая будет применяться к приложению HR, управляющему сотрудниками, маркетинговому приложению, управляющему контентом, и приложению R & D, управляющему версиями программного обеспечения, при одновременном согласовании со стандартами соответствия NIST.
Однако существует несколько настроек, которые могут быть применены практически к каждому приложению в стеке SaaS. В этой статье мы рассмотрим некоторые универсальные конфигурации, объясним, почему они важны, и поможем вам настроить их таким образом, чтобы повысить уровень безопасности ваших SaaS-приложений.
Для субъектов угроз взлом учетной записи администратора сродни выигрышу в лотерею. У них есть доступ ко всему. Организации должны делать все, что в их силах, чтобы сохранить контроль над этими учетными записями. Управление этим контролем осуществляется с помощью конфигураций и передовых практик.
Реализовать ограниченное резервирование
Важно иметь как минимум двух администраторов для каждого приложения. Такая избыточность затрудняет администратору действовать в одиночку вопреки наилучшим интересам организации, поскольку администраторы могут отслеживать друг друга на предмет любых признаков нарушения.
Однако каждый администратор увеличивает поверхность атаки приложения. Организации должны соблюдать баланс между наличием достаточного количества администраторов для надлежащего обслуживания приложения и ограничением уязвимости. Автоматическая проверка количества администраторов должна вызывать оповещения, когда количество администраторов выходит за пределы предпочтительного диапазона.
Устраните внешних администраторов
Внешние администраторы вносят новый уровень неопределенности в безопасность SaaS. Поскольку они находятся за пределами организации, команда безопасности не может контролировать политики паролей или инструменты аутентификации, которые они используют.
Например, если субъект угрозы попытается войти в ваше приложение и нажмет "Забыли пароль", невозможно узнать, может ли субъект угрозы взломать учетную запись электронной почты внешнего администратора. Отсутствие надзора за внешними пользователями может привести к серьезному нарушению вашего приложения SaaS, именно поэтому NIST не рекомендует привлекать внешних администраторов. В зависимости от приложения либо заблокируйте получение внешними администраторами прав администратора, либо идентифицируйте внешних пользователей с правами администратора и удалите эти права.
Для компаний, которые нанимают внешнюю ИТ-компанию или передают ее на аутсорсинг MSSP, эти лица не должны считаться внешними. Однако им следует продолжать следить за тем, чтобы другим внешним пользователям предоставлялись права администратора.
Требуется администратор MFA
Для соответствия стандартам NIST все учетные записи пользователей-администраторов должны быть обязательны для доступа к приложению с использованием многофакторной аутентификации (MFA), такой как одноразовый пароль (OTP). MFA требует, чтобы пользователи предъявляли минимум две формы идентификатора, прежде чем он аутентифицирует пользователя. Субъекту угрозы потребуется скомпрометировать две системы аутентификации, что повысит уровень сложности взлома и снизит риск для учетной записи. Обязательно установите MFA для администраторов по мере необходимости (мы также рекомендуем MFA для всех пользователей, но это обязательное условие для администраторов).
Видимый календарь может подвергнуть сотрудников фишинговым атакам, организованным социальными сетями, в то время как общие репозитории могут привести к тому, что внутренний исходный код компании станет общедоступным. Электронная почта, файлы и доски объявлений содержат конфиденциальные данные, которые не должны быть доступны широкой публике. Хотя перечисленные ниже конфигурации часто называются по-разному в каждом приложении, практически любое приложение, хранящее контент, будет иметь этот тип контроля.
Прекратить публичный доступ
Разница между "Поделиться со всеми" и "Поделиться с пользователем" огромна. Когда материалы доступны всем, любой, у кого есть ссылка, может получить доступ к материалам. Поделиться с пользователем, напротив, добавляет дополнительный механизм аутентификации, поскольку пользователю необходимо войти в систему, прежде чем получить доступ к материалу.
Чтобы уменьшить количество доступного контента, администраторам приложений следует отключить общий доступ по общедоступным URL-адресам ("Всем, у кого есть ссылка"). Кроме того, некоторые приложения позволяют пользователям отзывать доступ к URL-адресам, которые уже были созданы. При наличии возможности организациям следует обязательно переключить этот параметр в положение вкл.
Срок действия приглашений истекает
Многие приложения позволяют авторизованным пользователям приглашать внешних пользователей в приложение. Однако в большинстве приложений срок действия приглашения не установлен. В таких обстоятельствах приглашения, отправленные годами ранее, могут предоставить доступ субъекту угрозы, который только что взломал учетную запись электронной почты внешнего пользователя. Включение автоматической даты истечения срока действия для приглашений устраняет этот тип риска.
Стоит отметить, что в некоторых приложениях изменения конфигурации имеют обратную силу, в то время как другие вступят в силу только в будущем.
Пароли служат фундаментальным элементом многоуровневого подхода к обеспечению безопасности, дополняя другие меры безопасности, такие как многофакторная аутентификация (MFA) и шифрование. Скомпрометированные пароли могут быть шлюзом для злоумышленников, использующих уязвимости в среде SaaS. Эффективное управление паролями повышает общую устойчивость систем SaaS, способствуя созданию более безопасной и заслуживающей доверия цифровой экосистемы как для предприятий, так и для их пользователей.
Предотвращение атак с использованием паролей
При спрей-атаке субъекты угрозы вводят имя пользователя и общий пароль, надеясь, что им повезет и они получат доступ к приложению. Рекомендуемый способ предотвращения спрей-атак с использованием пароля - требование MFA. Для тех, кто не настаивает на том, чтобы сотрудники использовали MFA как часть процесса аутентификации, многие приложения позволяют организациям запрещать использование слов в качестве паролей. Этот список слов будет включать такие термины, как password1, letmein, 12345, а также названия местных спортивных команд. Кроме того, она будет включать такие термины, как имя пользователя, продукты компании, партнеры и другие бизнес-термины.
Изучение конфигураций и добавление пользовательского списка запрещенных слов может значительно снизить риск успешной атаки с использованием пароля.
Сложность пароля
Большинство приложений SaaS позволяют организации настраивать сложность пароля. Они варьируются от разрешения использования любого пароля до требования использования буквенно-цифровых символов, заглавных и строчных букв, символов или длины пароля. Обновите требования к паролю в приложении, чтобы они соответствовали политике вашей организации.
Если в вашей организации нет политики паролей, рассмотрите возможность следования рекомендациям NIST:
Может показаться маловероятным, что субъекты угроз тратят свое время на поиск неправильной конфигурации, которую они могут использовать. Тем не менее, это именно то, что сделала российская государственная группа Midnight Blizzard, когда в этом году взломала Microsoft. Если в Microsoft возможны неправильные настройки, стоит проверить, чтобы убедиться, что все ваши приложения защищены.
Одна из проблем, с которой сталкиваются те, кто отвечает за безопасность приложений SaaS, заключается в различных настройках, обнаруживаемых в каждом приложении. Это затрудняет разработку политики конфигурации, которая будет применяться к приложению HR, управляющему сотрудниками, маркетинговому приложению, управляющему контентом, и приложению R & D, управляющему версиями программного обеспечения, при одновременном согласовании со стандартами соответствия NIST.
Однако существует несколько настроек, которые могут быть применены практически к каждому приложению в стеке SaaS. В этой статье мы рассмотрим некоторые универсальные конфигурации, объясним, почему они важны, и поможем вам настроить их таким образом, чтобы повысить уровень безопасности ваших SaaS-приложений.
Начните с администраторов
Управление доступом на основе ролей (RBAC) является ключом к соблюдению требований NIST и должно применяться к каждому приложению SaaS. В приложении SaaS существует два типа разрешений. Функциональный доступ охватывает такие вещи, как создание учетных записей и навигация по приложению. С другой стороны, разрешения на доступ к данным определяют, какие пользователи могут извлекать и изменять данные. Учетная запись администратора (или суперадминистратора в некоторых приложениях) является наиболее чувствительной в приложении, поскольку она имеет полный доступ к обоим типам разрешений.Для субъектов угроз взлом учетной записи администратора сродни выигрышу в лотерею. У них есть доступ ко всему. Организации должны делать все, что в их силах, чтобы сохранить контроль над этими учетными записями. Управление этим контролем осуществляется с помощью конфигураций и передовых практик.
Реализовать ограниченное резервирование
Важно иметь как минимум двух администраторов для каждого приложения. Такая избыточность затрудняет администратору действовать в одиночку вопреки наилучшим интересам организации, поскольку администраторы могут отслеживать друг друга на предмет любых признаков нарушения.
Однако каждый администратор увеличивает поверхность атаки приложения. Организации должны соблюдать баланс между наличием достаточного количества администраторов для надлежащего обслуживания приложения и ограничением уязвимости. Автоматическая проверка количества администраторов должна вызывать оповещения, когда количество администраторов выходит за пределы предпочтительного диапазона.
Устраните внешних администраторов
Внешние администраторы вносят новый уровень неопределенности в безопасность SaaS. Поскольку они находятся за пределами организации, команда безопасности не может контролировать политики паролей или инструменты аутентификации, которые они используют.
Например, если субъект угрозы попытается войти в ваше приложение и нажмет "Забыли пароль", невозможно узнать, может ли субъект угрозы взломать учетную запись электронной почты внешнего администратора. Отсутствие надзора за внешними пользователями может привести к серьезному нарушению вашего приложения SaaS, именно поэтому NIST не рекомендует привлекать внешних администраторов. В зависимости от приложения либо заблокируйте получение внешними администраторами прав администратора, либо идентифицируйте внешних пользователей с правами администратора и удалите эти права.
Для компаний, которые нанимают внешнюю ИТ-компанию или передают ее на аутсорсинг MSSP, эти лица не должны считаться внешними. Однако им следует продолжать следить за тем, чтобы другим внешним пользователям предоставлялись права администратора.
Требуется администратор MFA
Для соответствия стандартам NIST все учетные записи пользователей-администраторов должны быть обязательны для доступа к приложению с использованием многофакторной аутентификации (MFA), такой как одноразовый пароль (OTP). MFA требует, чтобы пользователи предъявляли минимум две формы идентификатора, прежде чем он аутентифицирует пользователя. Субъекту угрозы потребуется скомпрометировать две системы аутентификации, что повысит уровень сложности взлома и снизит риск для учетной записи. Обязательно установите MFA для администраторов по мере необходимости (мы также рекомендуем MFA для всех пользователей, но это обязательное условие для администраторов).
Предотвращение утечек данных
Утечки данных SaaS представляют значительные риски для организаций и их пользователей, потенциально ставя под угрозу конфиденциальную информацию, хранящуюся в облачных приложениях. Приложения SaaS продаются как инструменты совместной работы. Однако конфигурации, позволяющие пользователям работать вместе, также могут поставить под угрозу файлы и данные. NIST, со своей стороны, выступает за мониторинг разрешений для каждого ресурса.Видимый календарь может подвергнуть сотрудников фишинговым атакам, организованным социальными сетями, в то время как общие репозитории могут привести к тому, что внутренний исходный код компании станет общедоступным. Электронная почта, файлы и доски объявлений содержат конфиденциальные данные, которые не должны быть доступны широкой публике. Хотя перечисленные ниже конфигурации часто называются по-разному в каждом приложении, практически любое приложение, хранящее контент, будет иметь этот тип контроля.
Прекратить публичный доступ
Разница между "Поделиться со всеми" и "Поделиться с пользователем" огромна. Когда материалы доступны всем, любой, у кого есть ссылка, может получить доступ к материалам. Поделиться с пользователем, напротив, добавляет дополнительный механизм аутентификации, поскольку пользователю необходимо войти в систему, прежде чем получить доступ к материалу.
Чтобы уменьшить количество доступного контента, администраторам приложений следует отключить общий доступ по общедоступным URL-адресам ("Всем, у кого есть ссылка"). Кроме того, некоторые приложения позволяют пользователям отзывать доступ к URL-адресам, которые уже были созданы. При наличии возможности организациям следует обязательно переключить этот параметр в положение вкл.
Срок действия приглашений истекает
Многие приложения позволяют авторизованным пользователям приглашать внешних пользователей в приложение. Однако в большинстве приложений срок действия приглашения не установлен. В таких обстоятельствах приглашения, отправленные годами ранее, могут предоставить доступ субъекту угрозы, который только что взломал учетную запись электронной почты внешнего пользователя. Включение автоматической даты истечения срока действия для приглашений устраняет этот тип риска.
Стоит отметить, что в некоторых приложениях изменения конфигурации имеют обратную силу, в то время как другие вступят в силу только в будущем.
Укрепление паролей для повышения безопасности приложений
Пароли - это первая линия защиты от несанкционированного доступа. NIST выступает за надежную и хорошо управляемую политику паролей, которая необходима для защиты конфиденциальных пользовательских данных, конфиденциальной бизнес-информации и проприетарных активов, хранящихся в облачной инфраструктуре. Уникальность, сложность и регулярное обновление паролей являются критическими аспектами надежной системы безопасности.Пароли служат фундаментальным элементом многоуровневого подхода к обеспечению безопасности, дополняя другие меры безопасности, такие как многофакторная аутентификация (MFA) и шифрование. Скомпрометированные пароли могут быть шлюзом для злоумышленников, использующих уязвимости в среде SaaS. Эффективное управление паролями повышает общую устойчивость систем SaaS, способствуя созданию более безопасной и заслуживающей доверия цифровой экосистемы как для предприятий, так и для их пользователей.
Предотвращение атак с использованием паролей
При спрей-атаке субъекты угрозы вводят имя пользователя и общий пароль, надеясь, что им повезет и они получат доступ к приложению. Рекомендуемый способ предотвращения спрей-атак с использованием пароля - требование MFA. Для тех, кто не настаивает на том, чтобы сотрудники использовали MFA как часть процесса аутентификации, многие приложения позволяют организациям запрещать использование слов в качестве паролей. Этот список слов будет включать такие термины, как password1, letmein, 12345, а также названия местных спортивных команд. Кроме того, она будет включать такие термины, как имя пользователя, продукты компании, партнеры и другие бизнес-термины.
Изучение конфигураций и добавление пользовательского списка запрещенных слов может значительно снизить риск успешной атаки с использованием пароля.
Сложность пароля
Большинство приложений SaaS позволяют организации настраивать сложность пароля. Они варьируются от разрешения использования любого пароля до требования использования буквенно-цифровых символов, заглавных и строчных букв, символов или длины пароля. Обновите требования к паролю в приложении, чтобы они соответствовали политике вашей организации.
Если в вашей организации нет политики паролей, рассмотрите возможность следования рекомендациям NIST:
- Не производите обязательных изменений паролей, поскольку пользователи, как правило, выбирают легко запоминаемые пароли.
- Используйте длинные пароли вместо сложных. Комбинации цифр, специальных символов и символов нижнего / верхнего регистра обычно соответствуют формату, подобному этому: Password1!. Их легко взломать методом перебора. Длинный пароль, такой как myfavoritedessertisspecanpie, легко запомнить, но состоящий из 27 символов, его трудно взломать методом перебора.
- Ограничьте количество попыток ввода пароля не более чем 10.
- Сопоставляйте пароли с опубликованными паролями и другими легко угадываемыми словами со списком запрещенных слов.
Конфигурации действительно важны
Примерно 25% всех инцидентов безопасности, связанных с облаком, начинаются с неправильно настроенных настроек. В дополнение к упомянутым здесь настройкам, касающимся доступа, паролей и утечек данных, которые являются довольно универсальными, конфигурации используются для управления ключами, мобильной безопасности, операционной устойчивости, защиты от фишинга, спама и многого другого. Неправильные настройки в любой из этих областей могут напрямую привести к нарушениям.Может показаться маловероятным, что субъекты угроз тратят свое время на поиск неправильной конфигурации, которую они могут использовать. Тем не менее, это именно то, что сделала российская государственная группа Midnight Blizzard, когда в этом году взломала Microsoft. Если в Microsoft возможны неправильные настройки, стоит проверить, чтобы убедиться, что все ваши приложения защищены.
