Всем добрый день, я Станислав Тибекин, CEO компании Nixys. Мы продолжаем серию переводов статей Эяля Эстрина из AWS про особенности создания cloud-native приложений.
В первой главе мы говорили про бизнес-требования, инфраструктуру, автоматизацию, отказоустойчивость и экологичность. Во второй части обсудим вопросы безопасности.
Прежде чем начать, хочу предложить вам подписаться на наш блог Хабр, TG‑канал DevOps FM, vc.ru и познакомиться с YouTube. Везде выходит разный, но интересный и полезный контент.
Полезного чтения!
Управляем индентификацией и контролем доступа
Что такое Identity and Access Management (IAM)? (прим. переводчика)
Разговор о безопасности стоит начать с Identity and Access Management (IAM). Фактически IAM — это пропускная система: она представляет собой набор практик, технологий и политик для централизованного управления доступом к инфраструктуре. Благодаря IAM вы будете уверены, что права доступа ваших сотрудников применяются только по мере необходимости (в зависимости от их бизнес-ролей или взаимоотношений в организации).
Настраиваем аутентификацию
Важно задать себе вопрос: кто наши клиенты?
Если мы создаем приложение, которое будет обслуживать внутренних клиентов (т. е. сотрудников компании), нам необходимо убедиться, что наше приложение сможет синхронизировать удостоверения от нашего поставщика удостоверений (IdP).
С другой стороны, если нашим приложением будут пользоваться внешние клиенты, то в большинстве случаев мы не станем управлять идентификаторами самостоятельно, а разрешим аутентификацию на основе SAML, OAuth или OpenID connect и будем управлять авторизацией в нашем приложении.
Примеры управляемых облачных сервисов идентификации: AWS IAM Identity Center, Microsoft Entra ID и Google Cloud Identity.
Настраиваем авторизацию
Content Security Policy (CSP, политика защиты контента) — это стандарт безопасности веб-приложений. Он позволяет контролировать, откуда браузер может загружать ресурсы (например, скрипты или элементы оформления). CSP помогает защититься от угроз межсайтового выполнения сценариев (XSS) или внедрения нежелательного кода (инъекций).
Когда наше приложение использует сервисы из экосистемы CSP (хранилища, базы данных и т. д.), каждый CSP имеет свои механизмы управления разрешениями на доступ к сервисам и действиям и свой способ реализации RBAC — управления доступом на основе ролей.
Важно: независимо от встроенных механизмов использования облачной инфраструктуры, мы всегда должны следовать принципу наименьших привилегий (то есть минимальных разрешений).
На уровне приложений нам необходимо разработать механизм авторизации, который будет проверять каждую личность, прошедшую аутентификацию в нашем приложении, на соответствие механизму авторизации. Здесь нам потребуется интерактивная аутентификация, неинтерактивная аутентификация или даже доступ на основе API.
Конечно, вы можете управлять авторизацией с помощью разработанного вами механизма RBAC. Однако пришло время рассмотреть те механизмы политики авторизации, что соответствуют концепции cloud native. Например, Open Policy Agent (OPA). Это open source проект, который является частью ландшафта CNCF. Основное преимущество OPA заключается в том, что его механизм не ограничивается авторизацией в приложении. Это значит, что вы сможете использовать его для авторизации в Kubernetes, для Linux (используя PAM) и многого другого.
Policy-as-Code
Что такое политика? (прим. переводчика)
Давайте разъясним термин «политика». В контексте нашей статьи (да и сферы IT в целом) «политика» — это любой тип правил, условий или инструкций, которые управляют ИТ-операциями или процессами. Политика может быть правилом, которое определяет, какие условия должны быть выполнены, например, для того, чтобы код прошел контроль безопасности и был развернут. Или это может быть набор процедур, которые выполняются автоматически в ответ на событие безопасности.
Policy-as-code (PaC, политика как код) — это подход к управлению политиками, при котором политики определяются, обновляются, делятся и применяются с помощью кода. Policy-as-Code позволяет настраивать guardrails (защитные барьеры) для различных аспектов рабочей нагрузки вашего приложения.
В каждом облачном провайдере есть своя система защиты. Она выходит за пределы облачного аккаунта и влияет на конфигурацию или максимально допустимое потребление ресурсов.
Некоторые примеры барьеров:
Ограничение допустимого региона для развертывания ресурсов (вычислительных, хранилищ, баз данных, сетей и т. д.);
Принудительное шифрование в режиме ожидания;
Запрет на создание общедоступных ресурсов (например, виртуальных машин с общедоступным IP);
Использование экземпляров виртуалок только определённого размера (т. е. ограничение количества процессоров и объёмов памяти).
В целях автоматизации защитные барьеры также могут быть применены как часть конвейера CI/CD при развертывании ресурсов с Infrastructure as Code. Код IaC проверяется перед фактическим этапом развертывания, и, если он не нарушает Policy-as-Code, то ресурсы обновляются.
В качестве примеров PaC можно вспомнить AWS Service control policies (SCPs), Azure Policy, Google Organization Policy Service, HashiCorp Sentinel и Open Policy Agent (OPA).
Защищаем данные
Практически любое приложение содержит ценные данные, — от документов до персональных данных, — поэтому мы должны защитить их от несанкционированного доступа.
Один из самых распространенных способов защиты — хранение в зашифрованном виде:
Шифрование при передаче: осуществляется с помощью таких протоколов, как TLS (последняя версия — 1.3).
Шифрование неактивных данных: выполняется на уровне тома, диска, хранилища или базы данных с использованием алгоритмов по типу AES.
Шифрование в процессе использования: выполняется с помощью аппаратного устройства, поддерживающего TEE (Trusted Execution Environment, доверенную среду исполнения), которая ещё называется конфиденциальными вычислениями.
При шифровании данных нам необходимо позаботиться о генерации ключей, защищённом хранилище для их хранения, их извлечении и уничтожении. Все крупные CSP имеют свои службы управления на всех этапах жизненного цикла ключа.
Если вы разворачиваете ваше приложение на базе инфраструктуры одной политики защиты контента, то лучше пользуйтесь теми управляемыми сервисами, которые предлагает эта политика.
Для шифрования в процессе использования выбирайте те сервисы, что поддерживают конфиденциальные вычисления, например, экземпляры виртуальных машин или рабочие узлы Kubernetes.
Управляем секретами
Секреты — это статические учётные данные, которые позволяют получить доступ к службам и ресурсам. Примерами секретов являются ключи API, пароли, учётные данные баз данных и др.
Секреты, как и ключи шифрования, являются конфиденциальными и должны быть защищены от неавторизованных лиц. Поэтому ещё на первых этапах проектирования приложения вам нужно выбрать безопасное место для хранения секретов.
Все крупные CSP имеют собственные службы управления секретами, которые контролируют весь жизненный цикл секретной информации.
В рамках конвейера CI/CD стоит внедрить автоматизированный процесс сканирования для обнаружения секретов, встроенных в код, скрипты и конфигурационные файлы, чтобы не хранить секреты вне защищенного хранилища.
Примеры сервисов управления секретами: AWS Secrets Manager, Azure Key Vault, Google Secret Manager и HashiCorp Vault.
Защищаем сеть
Приложения должны быть защищены на сетевом уровне, неважно, открываете ли вы доступ к приложению для внутренних клиентов или для клиентов через публичный интернет.
Основной способ защиты инфраструктуры на сетевом уровне — использование средств контроля доступа, которыми в нашем случае являются файерволы третьего или четвертого уровней.
Что такое файервол? (прим. переводчика)
Файервол (межсетевой экран, брандмауэр) — это своеобразный сетевой щит, программа, которая фильтрует входящий и исходящий трафик, пропуская только безопасные данные, и блокирует подозрительную информацию. Межсетевой экран третьего уровня (L3 firewall) обеспечивает фильтрацию пакетов на основе информации об IP-адресах, масках подсетей и маршрутах и предназначен для защиты сети от внешних угроз и контроля доступа к сетевым ресурсам. А брандмауэр четвёртого уровня анализирует заголовки протоколов TCP, UDP и ICMP. Он проверяет IP-адреса и порты, а также сервисы, предоставляемые на основе этих протоколов. L4 firewall использует технологию stateful inspection для запоминания и хранения состояния запросов, что позволяет разрешать необходимые ответные соединения.
Все CSP имеют механизмы контроля доступа для ограничения этого самого доступа к сервисам (виртуальным машинам, базам данных и т. д.).
Примерами управляемых сервисов L3 и L4 являются AWS Security groups, Azure Network security groups и Google VPC firewall rules.
Некоторые облачные провайдеры поддерживают частный доступ к своим сервисам, добавляя к различным сервисам сетевой балансировщик нагрузки с внутренним IP-адресом из частной подсети клиента. Таким образом весь трафик будет проходить внутри магистрали CSP, а не через публичный интернет. В качестве решений для частных подключений можно рассмотреть AWS PrivateLink, Azure Private Link и Google VPC Service Controls.
Некоторые политики защиты контента предлагают управляемые брандмауэры седьмого уровня.
Чем хорош брандмауэр седьмого уровня? (прим. переводчика)
L7 Firewall — это продвинутый тип межсетевого экрана, который работает на прикладном уровне модели OSI. Он обеспечивает более высокий уровень безопасности и контроля над сетевым трафиком, фильтруя данные на основе содержимого пакетов, включая протоколы приложений, такие как HTTP, FTP и SMTP. Этот межсетевой экран предоставляет возможности управления портами, фильтрации трафика и обеспечения безопасности с использованием протоколов SSL и TLS.
В качестве примеров брандмауэров 7-го уровня можно назвать AWS Network Firewall, Azure Firewall и Google Cloud NGFW.
Защищаем приложения
Любое приложение подвержено атакам. Существует множество разновидностей атак: внедрение вредоносного кода (инъекции), утечки данных, фальсификация данных, несанкционированный доступ и многие другие. Независимо от того, используете ли вы API, веб-приложение или мобильное приложение, важно внедрить защиту на прикладном уровне, например, файервол веб-приложений. Все крупные CSP предлагают услуги управляемых WAF. Также существует множество SaaS-решений от коммерческих поставщиков.
Что такое WAF? (прим. переводчика)
WAF (Web Application Firewall) — это совокупность мониторов и фильтров, предназначенных для обнаружения и блокирования сетевых атак на веб-приложение.
Примеры управляемых WAF-сервисов: AWS WAF, Azure WAF и Google Cloud Armor.
Защищаемся от DoS- и DDoS-атак
Каждое веб-приложение имеет риск подвергнуться DoS- (Denial of Service, отказ в обслуживании) или DDoS-атаке (Distributed DoS, распределённый DoS).
Чем опасны DDoS-атаки? (прим. переводчика)
DDos-атаки представляют большую угрозу, так как они распределены и направлены на один целевой хост. Они могут вызвать серьёзные проблемы с доступностью веб-ресурсов и привести к финансовым потерям (а иногда — и к репутационным).
У вас снова есть 2 варианта: это предложенная CSP защита от DDoS-атак или решения от частных поставщиков. Примеры услуг управляемой защиты от DDoS: AWS Shield, Azure DDoS Protection, Google Cloud Armor и Cloudflare DDoS protection.
Управляем патчами
Программное обеспечение, как правило, уязвимо, и поэтому его необходимо регулярно исправлять.
Для приложений, развёрнутых на виртуальных машинах:
создайте «золотой образ» виртуалки и регулярно обновляйте его систему безопасности и ПО;
настройте процесс регулярных релизов патчей.
Для приложений, упакованных в контейнеры, вам тоже нужно создать «золотой образ» каждого из компонентов приложения и регулярно обновлять его.
Обязательно внедрите инструменты (SCA).
Что такое SCA? (прим. переводчика)
SCA-анализ кода (Software Composition Analysis) — это автоматизированный процесс сканирования программного обеспечения с целью обнаружения фрагментов с открытым исходным кодом (OSS) и их последующей проверки на наличие уязвимостей, устаревших элементов и проблем с лицензированием. Этот анализ помогает контролировать безопасность используемых компонентов, отслеживать сторонние библиотеки и разрабатывать политики для программного обеспечения с открытым кодом
В случае обнаружения уязвимых компонентов или их зависимостей вы сможете вовремя начать процесс их замены. Примеры решений для управления исправлениями: AWS Systems Manager Patch Manager, Azure Update Manager и Google VM Manager Patch.
Соблюдаем юридические и нормативные требования
Соответствие нормативным требованиям — немаловажный фактор безопасности при разработке приложения.
Нередко приложения содержат личную (её ещё называют PII — персонально идентифицируемой) информацию о сотрудниках или клиентах. Взаимодействие с персональными данными должно соответствовать законам и нормативным актам о конфиденциальности и сохранении данных (например, GDPR в Европе, CPRA в Калифорнии, LGPD в Бразилии и т. д.).
Какие законы в России регулируют действия с персональными данными? (прим. переводчика)
В России регулирование осуществляется с применением ряда нормативно-правовых актов: № 152-ФЗ «О персональных данных»; № 149-ФЗ «Об информации, информационных технологиях и о защите информации».
Некоторые организации принимают решение соответствовать высоким отраслевым стандартам и следовать лучшим практикам в области безопасности, таким как набор рекомендаций по настройке широкого спектра ПО Benchmark от Center for Internet Security (CIS) для повышения надёжности компонентов инфраструктуры. Оценить уровень безопасности можно с помощью, например, решений Cloud security posture management (CSPM).
Что такое CSPM? (прим. переводчика)
Cloud security posture management (CSPM, управление состоянием защиты облачных сред) — это процесс управления безопасностью в облачной среде. Он помогает организациям выявлять и устранять риски безопасности, связанные с неправильно сконфигурированными публичными облачными сервисами. CSPM использует различные инструменты и методы для оценки рисков, визуализации, реагирования на инциденты, обеспечения соответствия нормативным требованиям и мониторинга безопасности в облаке.
Кстати, наша команда может помочь вам настроить CSPM.
Реагируем на инциденты
При разработке приложения в облаке важно быть готовым к быстрому реагированию на потенциальные ЧП. Для этого вам нужно создать организовать SOC.
Что такое SOC? (прим. переводчика)
SOC (Security Operations Center) — центр обеспечения безопасности. Он объединяет людей, процессы и технологии для снижения рисков и повышения киберзащиты организации. SOC состоит из команды экспертов по безопасности, которые занимаются мониторингом, анализом, предотвращением киберугроз и реагируют на подтверждённые инциденты.
Советуем соблюдать следующие рекомендации:
Включите логирование изменений как инфраструктуры, так и компонентов приложения и передайте все журналы в центральный агрегатор журналов. Убедитесь, что журналы хранятся в централизованном, неизменяемом хранилище с ограниченными правами доступа для команды SOC. Выберите инструмент, который позволит просматривать журналы, обнаруживать аномалии и создавать полезные аналитические материалы для SOC.
Если понадобится, позаботьтесь о повышении уровня компетенций для сформированной вами команды SOC. Например, вы можете разработать учебные пособия, в которых будут расписаны дальнейшие действия при после случившегося инцидента.
Создайте автоматизированные решения, которые позволят вам в случае катастрофических событий (например, при взломе сети или заражении вирусом-вымогателем) поместить затронутые сервисы в карантин и развернуть новую среду с нуля.
Подведём итог
Во второй статье этого цикла мы раскрыли многие аспекты безопасности, которые компании должны учитывать при разработке новых cloud-native приложений. Рекомендуем использовать этот чек-лист как базу и постоянно дополнять и совершенствовать его при документировании своих проектов.
