Нужно ли защищать доступ к бэкенду ваших клиентских приложений? Разумеется, если вы заботитесь о рисках кибербезопасности, времени работы, соответствии стандартам SOC II и NIST или архитектурным фреймворкам AWS, Azure и GCP.
Независимо от размера и масштаба облачного приложения, закрывать вопросы соответствия требованиям безопасности идентификации необходимо для развития вашего бизнеса, особенно когда вы работаете с клиентами в строго регулируемых отраслях.
Конфиденциальные данные не просто так называются конфиденциальными. Аудиторы, оценивающие соответствие стандартам SOC II, NIST и другим, не заботятся о том, переносят ли организации программы на рабочие нагрузки виртуальных машин или создают их на основе контейнеров и безсерверных функций. Аудиторам неважно, какие облачные провайдеры использует команда разработчиков для создания своих программ. И аудиторам точно не важны крутые архитектуры микросервисов, оценки дизайна и сроки спринтов, которые приоритетны для ваших инженерных групп.
Так о чем же заботятся аудиторы? О том, чтобы компании должным образом защищали все аккаунты, которые получают доступ к конфиденциальным данным в своих приложениях.
Хорошая новость состоит в том, что несколько проверенных практик безопасности учетных записей и управления привилегированным доступом (PAM) могут помочь организациям снизить риски и создавать SaaS-приложения, отвечающие стандартам SOC II, NIST и другим.
Ниже — некоторые из этих практик. Предлагаем познакомиться с ними поближе.

Принцип наименьших привилегий

Фреймворки соответствия требуют от организаций соблюдать принцип наименьших привилегий (PoLP), фундаментального понятия кибербезопасности. Фреймворки отличаются своей терминологией – например, SOC II имеет требования по «логическому контролю доступа», в то время как NIST Cybersecurity Framework предпочитает термин «наименьшие привилегии». Здесь важно не ошибиться – для создания соответствующих SaaS-приложений организации должны позаботиться о том, чтобы все аккаунты имели необходимые права для выполнения своих обязанностей.

Организации должны, как указано в AWS Well-Architected Framework, «реализовывать принцип наименьших привилегий и обеспечивать распределение обязанностей с соответствующим разрешением для каждого взаимодействия с ресурсами AWS».

Zero Standing Privileges (ZSP) для всех операционных доступов

После внедрения принципа наименьших привилегий организации должны позаботиться о защите привилегированного доступа. Для обеспечения соответствия многие организации принимают новую философию безопасности – Zero Standing Privileges (ZSP), то есть нулевые постоянные привилегии. Методологии этого принципа безопасности строятся на основе наименьших привилегий, повышая доступ только в нужное время и минимизируя использование долгосрочных паролей и учетных данных для доступа к рабочим нагрузкам и сервисам облака.
Ведущие поставщики облачных сервисов рекомендуют использовать модели федеративного доступа (а не общие аккаунты) для доступа к рабочим нагрузкам и сервисам. Разработчики, инженеры и специалисты в области науки о данных могут выполнять роли IAM без использования постоянных учетных данных. В результате большая часть доступа разработчиков может считаться операционной: пользователям облака не требуется постоянный доступ к ресурсам, а только на время выполнения конкретных задач.
Организации могут удовлетворить требования аудита и соответствия операционному доступу с подходом ZSP. Ключевые элементы ZSP включают в себя:
● Повышение доступа к консоли и CLI к уровню облачных сервисов на принципах just-in-time, используя роли, которые имеют минимальные необходимые разрешения для выполнения поставленной задачи. Примеры включают доступ к сервисам CSP для изменения конфигураций сети, базы данных и автоматического масштабирования вычислений. ● Повышение доступа к рабочим нагрузкам, работающим на базе облака, на принципах just-in-time. Примеры включают операционный доступ к виртуальным машинам Linux и Windows для перенесенных программ или Kubernetes и другим контейнерам для программ, работающих в облачных, микросервисных архитектурах. ● Интеграцию рабочих процессов запросов на доступ с имеющимися инструментами разработки, чтобы избежать замедления скорости. Разработчикам часто необходим дополнительный доступ для решения проблем во время отключений или критических ситуаций (так называемых кризисов). Сделать этот доступ простым и полностью контролируемым важно для комплаенса.

Безопасное управление учетными данными и их ротация

Даже в облаке нельзя обойти определенный долговременный доступ на системном уровне. Типичными примерами являются:
● учетные записи root ● регистрации, необходимые для создания облачной среды ● секреты DevOps, используемые программами ● учетные записи служб и программ ● учетные записи администратора для перенесенных рабочих нагрузок программного обеспечения, работающих внутри виртуальных машин (например, учетные записи администратора для ERP, баз данных или систем безопасности)
Стратегии безопасности и соответствия должны учитывать повышенный риск, который являют собой эти долгосрочные учетные записи на уровне системы. В этом могут помочь установившиеся подходы к PAM и управлению секретами. К примеру:
● Открытие учетных данных, которые используются администраторами, учетными записями служб и другими идентификаторами, и их интеграция в решение PAM. Это уменьшает риск кражи учетных данных. ● Централизованное управление секретами, которое используется разработчиками, в том числе путем интеграции с родными хранилищами секретов CSP. Этот подход к управлению секретами позволяет разработчикам использовать их предпочтительные инструменты, обеспечивая при этом управление и ротацию учетных данных, что соответствует целям комплаенса. ● Автоматическую ротацию учетных данных через интервалы, согласованные с политикой организации (часто определяемые в рамках соответствия). ● Регистрация всего использования привилегированных аккаунтов для сдерживания внутренних угроз. Для повышения эффективности аудита централизованно сохраняйте аудиторские следы для обоих сеансов, используя общие привилегированные учетные записи или сеансы с федеративным доступом с нулевыми постоянными привилегиями. ● Изоляция использования этих аккаунтов для предотвращения проникновения программ-вымогателей и другого вредоносного программного обеспечения на виртуальные машины и другие рабочие нагрузки в облаке.

Расширение безопасности учетных записей на сторонних поставщиков

Внутренние сотрудники – не единственные лица, имеющие доступ к бэкенду ваших SaaS-приложений. Многие организации пользуются услугами удаленных сторонних поставщиков и подрядчиков для настройки или запуска облачных рабочих нагрузок и сервисов, которые поддерживают их приложения.
Аудиторы, оценивающие соответствие ведущим фреймворкам кибербезопасности, часто уделяют большое внимание этому доступу. В частности, соответствие SOC II основывается на конкретных требованиях управления удаленным доступом и всеми точками доступа к данным. Организации могут продемонстрировать соответствие этим требованиям посредством привычных стратегий. Примеры включают:
● Управление всеми точками удаленного доступа к данным как для внутренних, так и для внешних доступов: разработчиков-подрядчиков, IT-подрядчиков и других сторонних поставщиков. ● Отмену любого постоянного привилегированного доступа для посторонних лиц к рабочим нагрузкам и сервисам облака. Чрезмерный доступ посторонних лиц был причиной нескольких случаев утечки данных в облачных средах в последние годы. ● Применение сильной биометрической проверки подлинности для доступа посторонних лиц к бэкенду SaaS-приложений.

Усиленная аутентификация и мониторинг для более глубокой защиты

Контроль доступа – это мощный способ уменьшения риска. Но принятие парадигмы Zero Trust требует от организаций «никогда не доверять» и «всегда проверять» доступ к их облачной среде.
Та же философия Zero Trust может придать дополнительную ценность организациям, стремящимся создавать безопасные программы с соблюдением всех требований. Чтобы усилить соответствие SOC II и другим фреймворкам, организации должны рассмотреть дополнительные элементы контроля глубинной защиты, такие как:
● Применение сильной, адаптивной многофакторной аутентификации (MFA) и выявление угроз идентификации для всех попыток доступа к бэкенду SaaS-приложений. Это должно включать аутентификацию для доступа третьих лиц и применение элементов управления, таких как усиленная и непрерывная аутентификация. ● Обеспечение проверки подлинности всех соединений между машинами. ● Мониторинг всех сеансов с высоким уровнем риска для рабочих нагрузок и сервисов, включая полную информацию про аудиторские следы. Запись экрана и воспроизведение видео могут помочь аудиторам и командам по судебной экспертизе упростить свои задачи. ● Систематический просмотр и сертификация доступа, удаление прав для обеспечения того, что разрешения доступа соответствуют должностным обязанностям и уровню ответственности. ● Внедрение возможностей для быстрого реагирования на злоупотребление привилегированными учетными записями или любым доступом с высоким уровнем риска.
Перечисленные практики безопасности учетных записей могут укрепить ваши инициативы касательно комплаенса.

О CyberArk 

CyberArk (NASDAQ: CYBR) является мировым лидером в сфере защиты персональных данных. Ориентируясь на интеллектуальный контроль привилегий, CyberArk предоставляет самое полное предложение безопасности для любых учетных данных в бизнес-приложениях, распределенных рабочих группах, гибридных облачных средах и на протяжении всего жизненного цикла DevOps. Ведущие мировые организации доверяют CyberArk защиту своих наиболее важных активов.