• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

Гостевая статья Достижение DevSecOps с помощью облачных сервисов AWS

В нашей предыдущей статье « мы исследовали, что на самом деле означает «DevSecOps», и как этого можно добиться с помощью простых инструментов с открытым исходным кодом, интегрированных в существующий конвейер DevOps, организованных с помощью Jenkins и развернутых в докере в режиме специального архитектура помещений.

В этой статье и объясняют, как можно добиться DevSecOps для среды, полностью работающей на AWS и их собственных предложениях.

Прежде чем перейти к DevSecOps, давайте перечислим все нативные среды DevOps в AWS.

Иллюстративные DevOps на AWS
image001 (1).png



Приведенная выше диаграмма иллюстрирует различные нативные сервисы AWS, которые можно использовать для автоматизации CI / CD в AWS.

Подробная информация об услугах AWS:

  • Разработчики используют AWS Cloud9 SDK для написания кода. AWS Cloud9 - это облачная интегрированная среда разработки (IDE), которая позволяет вам писать, запускать и отлаживать код с помощью всего лишь браузера. Он включает в себя редактор кода, отладчик и терминал с настраиваемыми плагинами.
  • Разработчики передают свой код в AWS CodeCommit. AWS CodeCommit - это полностью управляемая служба контроля версий, в которой размещаются безопасные репозитории на основе Git. Это облегчает группам совместную работу над кодом в безопасной и масштабируемой экосистеме.
  • AWS CodeBuild - это сервис, где разработчики могут компилировать свой исходный код, выполнять интеграцию из нескольких SCM и создавать артефакты сборки. Он конфигурируется с использованием файла «buildspec.yml», в котором объявляются все инструкции, связанные с интеграцией, компиляцией и сборкой. Он предоставляет предварительно упакованные среды сборки для популярных языков программирования и инструментов сборки, таких как Apache Maven, Gradle, а также может создавать настроенную среду сборки.
  • Контейнеры AWS S3 используются для хранения конечных артефактов / двоичных файлов сборки.
  • AWS CodeDeploy - это сервис, который извлекает двоичные артефакты из корзин S3 и развертывает их в предварительно подготовленных средах AWS, таких как EC2, ElasticBeanstalk и ECS. CodeDeploy полностью настраивается с помощью файла «appspec.yml».
  • Наконец, у нас есть AWS CodePipeline, которая координирует различные этапы сборки и развертывания, определенные в CodeBuild и CodeDeploy, предоставляя нам полностью управляемую службу непрерывной доставки.
Интеграция безопасности в AWS
AWS предоставляет множество инструментов безопасности в собственном облачном формате, однако, как правило, эти инструменты больше ориентированы на мониторинг и отчетность, что требует от нас развертывания и использования собственных инструментов для работы в других областях.

Интеграция безопасности в среде AWS требует действий, аналогичных тем, которые требуются в среде On-prem, таких как интеграция инструмента анализатора кода в SAST (статическое тестирование безопасности приложений) или проверка зависимостей в SCA (анализ состава программного обеспечения), как это было видно из .

Конфигурация различных инструментов в среде AWS для выполнения будет отличаться.

В предварительной модели инструменты могут быть загружены по желанию и выполнены в виде скрипта или контейнера докера. Однако в облаке, поскольку биллинг обычно используется, загрузка требует дополнительных затрат, и поэтому стратегия использования этих инструментов в AWS заключается в создании хранилища инструментов с использованием корзины S3 и ссылки на эту корзину S3 в каждом файле «buildspec.yml». Каждый этап будет иметь свой собственный «buildspec- <stage> .yml», в котором инструменты будут извлечены из внутреннего сегмента S3 и выполнены. Ниже приведен пример файла «buildspec-sca.yml» для этапа SCA, выполняющего проверки зависимостей.

image003 (1).png



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

Если инструмент совместим со спецификациями AWS Lambda, то преобразование инструмента в сервис Lambda будет исключительно важной задачей, и для управления уязвимостями именно это мы и сделали. Мы развернули Archery как который активируется только тогда, когда инструменту необходимо вставить в него данные об уязвимостях.

Приведенная ниже диаграмма является иллюстративным примером конвейера AWS DevSecOps.

image005 (1).png


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

image007 (1).png



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

AWS угрозы ландшафта
Ниже приведены проблемы, описывающие полный ландшафт угроз AWS.

Неправильная настройка безопасности контроля доступа
В AWS управление доступом осуществляется с помощью политик IAM. Политика - это объект в AWS, который, когда связан с удостоверением или ресурсами, определяет их разрешения. Если объекту EC2 требуется доступ к корзине S3, необходимы определенные разрешения. Наблюдение или предоставление чрезмерных привилегий может привести к различным сценариям, в которых корзины S3 имеют открытый доступ, что может привести к возможной утечке конфиденциальной информации. Список всех утечек S3 Bucket можно найти здесь https://github.com/nagwww/s3-leaks.

В другом случае один пользователь-администратор был настроен на доступ ко всем ресурсам AWS, что, попав в чужие руки, привело к полному .

Эти проблемы возникают из-за ошибок в политиках и разрешениях контроля доступа.

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

Инструмент PMapper , утилита, позволяющая пользователям просматривать разрешения IAM в AWS, может использоваться для графического представления всех разрешений, назначенных различным ресурсам и пользователям. Мы запустили этот инструмент в нашей лаборатории AWS DevSecOps, и графический результат показан ниже.

image009 (1).png



Кроме того, AWS S3 Inspector - это инструмент, который можно легко интегрировать в процесс DevSecOps, который будет проверять и оповещать, если какой-либо сегмент S3 в вашей учетной записи имеет открытый доступ для чтения / записи.

Ниже приведено руководство пользователя, рекомендованное AWS. Это стоит практиковать.



Неверная настройка безопасности сети
На приведенной ниже диаграмме показан типичный поток сетевого трафика и различные места, где его можно прослушивать. Группы безопасности подобны межсетевым экранам на основе хоста для отдельных экземпляров EC2. Списки контроля доступа к сети (NACL) можно настроить для группы экземпляров EC2. Таблицы маршрутов сконфигурированы для маршрутизации трафика между различными сетями, и, наконец, у нас есть VPC, которые являются окончательным универсальным модулем сегментации сети, подключенным к интернет-шлюзу.

image011 (1).png



Очень возможно иметь неправильную конфигурацию в такой сложной инфраструктуре. Например, в говорится, что из всех проанализированных компаний 73% компаний открыли порт SSH через Интернет.

Безопасное управление проблемами конфигурации, будь то сетевая конфигурация или разрешения, не может быть сделано одним нажатием кнопки. Требуется сочетание различных инструментов и выделенных ресурсов. В следующем разделе рассматриваются различные инструменты, предлагаемые AWS, а также некоторые другие инструменты с открытым исходным кодом, которые можно использовать.

Инструменты и сервисы безопасности AWS
Ниже в таблице описаны различные инструменты и их назначение.

aws_security_tools_pic_table.png


Обновленная иллюстративная диаграмма AWS DevSecOps

image013 (1).png


Утечка ключей AWS IAM
В AWS, если экземпляру EC2 требуется доступ к корзине S3, необходимо настроить надлежащие роли IAM. Роли IAM - это разрешения между службами AWS, которые отличаются от прав пользователя. Следовательно, если службе требуется программный доступ к ресурсам AWS, ему необходим набор ключей доступа AWS, которые можно получить по этому URL- метаданных

Существует два способа утечки / раскрытия этих ключей

  • Если приложение, развернутое на экземпляре EC2, имеет уязвимость RCE или SSRF, то злоумышленник может запросить URL-адрес, получить ключи доступа AWS и получить доступ ко всем доступным ресурсам AWS. Мы написали объясняющий этот вектор атаки.
  • Случайная фиксация исходного кода, содержащего ключи AWS, доступного в общедоступных папках и т. Д.
Утечка ключей AWS IAM может быть предотвращена с помощью хуков предварительной фиксации, таких как Talisman, которые обнаруживают такую информацию до того, как разработчики смогут зафиксировать изменения в репозитории.

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

Можно также использовать по защите ключей доступа AWS, такие как поворот ключей, удаление ранее использованных ключей, ограничение доступа к ресурсам и т. Д.

Использование биллинговых шапок
Если ваши ключи AWS скомпрометированы, самое первое, что могут сделать злоумышленники, это настроить экземпляры EC2 и начать майнинг биткойнов.

image015 (1).png


Не только это, но давайте рассмотрим стоимость запуска DevOps на AWS

aws_pricing_table_devops.png


Вот разбивка стоимости использования S3 Buckets.

image017 (1).png



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

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

Мы достигли точки, когда мы внедрили большинство элементов управления безопасностью в конвейере DevOps, используя большинство облачных функций, предоставляемых AWS, и дополняя их средствами с открытым исходным кодом, где это необходимо. Это может помочь облачным организациям лучше понять, как DevSecOps может воспроизводиться в их среде. Это, очевидно, не единственное решение, и различные организации могут настроить его в соответствии со своими предпочтениями. Также поставщики облачных услуг могут предлагать новые услуги в будущем, что может свести на нет потребность в решениях с открытым исходным кодом.

Ознакомьтесь с нашим видео, где вы можете увидеть моментальный снимок нашего обсуждения в блоге.


Источник:
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!