Всем добрый день, я Станислав Тибекин, CEO компании Nixys. Мы продолжаем серию переводов статей Эяля Эстрина из AWS про особенности создания cloud-native приложений. 

В первой главе мы говорили про бизнес-требования, инфраструктуру, автоматизацию, отказоустойчивость и экологичность. Во второй части обсудим вопросы безопасности. 

Прежде чем начать, хочу предложить вам подписаться на наш блог Хабр, TG‑канал DevOps FM, vc.ru и познакомиться с YouTube. Везде выходит разный, но интересный и полезный контент.

Полезного чтения!

Управляем индентификацией и контролем доступа

Настраиваем аутентификацию

Важно задать себе вопрос: кто наши клиенты? 

Если мы создаем приложение, которое будет обслуживать внутренних клиентов (т. е. сотрудников компании), нам необходимо убедиться, что наше приложение сможет синхронизировать удостоверения от нашего поставщика удостоверений (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

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.

Защищаем сеть

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

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

Все 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.

Некоторые политики защиты контента предлагают управляемые брандмауэры седьмого уровня.

В качестве примеров брандмауэров 7-го уровня можно назвать AWS Network Firewall, Azure Firewall и Google Cloud NGFW.

Защищаем приложения

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

Примеры управляемых WAF-сервисов: AWS WAF, Azure WAF и Google Cloud Armor.

Защищаемся от DoS- и DDoS-атак

Каждое веб-приложение имеет риск подвергнуться DoS- (Denial of Service, отказ в обслуживании) или DDoS-атаке (Distributed DoS, распределённый DoS).

У вас снова есть 2 варианта: это предложенная CSP защита от DDoS-атак или решения от частных поставщиков. Примеры услуг управляемой защиты от DDoS: AWS Shield, Azure DDoS Protection, Google Cloud Armor и Cloudflare DDoS protection.

Управляем патчами

Программное обеспечение, как правило, уязвимо, и поэтому его необходимо регулярно исправлять.

Для приложений, развёрнутых на виртуальных машинах:

• создайте «‎‎золотой образ» виртуалки и регулярно обновляйте его систему безопасности и ПО;

• настройте процесс регулярных релизов патчей.

Для приложений, упакованных в контейнеры, вам тоже нужно создать «‎‎золотой образ» каждого из компонентов приложения и регулярно обновлять его.

Обязательно внедрите инструменты (SCA).

В случае обнаружения уязвимых компонентов или их зависимостей вы сможете вовремя начать процесс их замены. Примеры решений для управления исправлениями: AWS Systems Manager Patch Manager, Azure Update Manager и Google VM Manager Patch.

Соблюдаем юридические и нормативные требования

Соответствие нормативным требованиям — немаловажный фактор безопасности при разработке приложения. 

Нередко приложения содержат личную (её ещё называют PII — персонально идентифицируемой) информацию о сотрудниках или клиентах. Взаимодействие с персональными данными должно соответствовать законам и нормативным актам о конфиденциальности и сохранении данных (например, GDPR в Европе, CPRA в Калифорнии, LGPD в Бразилии и т. д.).

Некоторые организации принимают решение соответствовать высоким отраслевым стандартам и следовать лучшим практикам в области безопасности, таким как набор рекомендаций по настройке широкого спектра ПО Benchmark от Center for Internet Security (CIS) для повышения надёжности компонентов инфраструктуры. Оценить уровень безопасности можно с помощью, например, решений Cloud security posture management (CSPM).

Реагируем на инциденты

При разработке приложения в облаке важно быть готовым к быстрому реагированию на потенциальные ЧП. Для этого вам нужно создать организовать SOC.

Советуем соблюдать следующие рекомендации:

• Включите логирование изменений как инфраструктуры, так и компонентов приложения и передайте все журналы в центральный агрегатор журналов. Убедитесь, что журналы хранятся в централизованном, неизменяемом хранилище с ограниченными правами доступа для команды SOC. Выберите инструмент, который позволит просматривать журналы, обнаруживать аномалии и создавать полезные аналитические материалы для SOC.

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

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

Подведём итог

Во второй статье этого цикла мы раскрыли многие аспекты безопасности, которые компании должны учитывать при разработке новых cloud-native приложений. Рекомендуем использовать этот чек-лист как базу и постоянно дополнять и совершенствовать его при документировании своих проектов.