Бессерверно и безопасно: как защитить слабые места облачных приложений

Михаил Кондрашин, технический директор Trend Micro в РФ и СНГ

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

Бессерверные вычисления

Подход, при котором предприятия используют вычислительные мощности поставщика облачных услуг (CSP), например, Amazon Web Services (AWS), не заботясь о вопросах, связанных с эксплуатацией и обслуживанием серверов и сопутствующих процессов, таких как управление исправлениями, масштабирование и доступность, называется бессерверными вычислениями. Такая модель позволяет предприятиям снизить накладные расходы на сопровождение аппаратной и программной инфраструктуры, сосредоточившись на создании приложений и основных продуктов. Это означает, что предприятия, решившие перейти на бессерверную обработку данных, выигрывают от повышения гибкости, автоматизации и рентабельности.

Бессерверная модель считается более безопасной, чем другие «облачные» модели, поскольку за безопасность базовой инфраструктуры отвечает провайдер. Например, в случае с AWS Lambda, эти вопросы решает AWS.

Однако следует разделять безопасность базовой инфраструктуры и безопасность собственно приложения, которой должны управлять сами пользователи AWS Lambda: безопасность кода, хранение и доступность конфиденциальных данных, управление идентификацией и доступом (IAM) в отношении сервиса AWS Lambda.

Сравнение моделей распределения ответственности при классической облачной инфраструктуре (сверху) и при бессерверной модели для AWS Lambda (снизу). Источник: AWS

Система назначение прав для бессерверной архитектуры базируется на двух принципах:

• «Наименьшие необходимые привилегии»,

• «Доступ по умолчанию запрещён».

Компоненты бессерверной архитектуры

Бессерверная архитектура включает в себя различные компоненты, обеспечивающие её работу:

— Amazon S3 — масштабируемая служба хранения объектов, поддерживающая различные варианты использования —мобильные приложения, средства анализа больших объёмов данных и устройства Internet-of Things (IoT).

— AWS Lambda — сервис аренды вычислительных ресурсов, который позволяет предприятиям выполнять код без хлопот, связанных с обслуживанием серверов. С его помощью разработчики могут запускать код и платить только за количество запущенных экземпляров кода. Если предприятие использует только AWS Lambda, оно может просто сосредоточиться на написании безопасного кода. Если AWS Lambda используется вместе с другими службами, следует помнить о предоставленных разрешениях, причём выдавать их придётся уже вручную.

Пример использования AWS Lambda с другими сервисами. Источник: AWS

— Amazon API Gateway — сервис, который позволяет создавать, публиковать, обслуживать, отслеживать и обеспечивать безопасность API-интерфейсов. Он действует как портал для приложений, позволяя им получать доступ к функциям внутренних сервисов или данным, используя API-интерфейсы RESTful и WebSocket. Как и AWS Lambda, Amazon API Gateway позволяет клиентам оплачивать только полученные вызовы API и объём переданных данных. Он также может действовать как мост, соединяющий развёрнутые функции с другими сервисами Amazon.

Пример использования Amazon API Gateway. Источник: AWS

— AWS Identity and Access Management (AWS IAM) — сервис, который позволяет разработчикам создавать учетные данные и разрешения безопасности и назначать их пользователям. Используя AWS IAM, предприятие может создать федерацию идентификационных данных, которая позволит существующим на предприятии идентификаторам получать доступ к консоли управления AWS Management Console, API-интерфейсам и ресурсам даже без создания уникальных пользователей AWS IAM.

При создании политики AWS IAM необходимо использовать подход с наименьшими привилегиями, чтобы гарантировать, что сервисы не будут доступны, если доступ не будет явно разрешен. Лучший способ сделать всё правильно — использовать роли IAM.

Ошибки конфигурации

Amazon S3

Amazon предлагает комплексное руководство по обеспечению безопасности хранилищ S3. Однако даже при наличии такого руководства пользователи могут столкнуться с проблемами безопасности, если допустят ошибки.

Ошибка № 1: открытый публичный доступ для приватного хранилища

Хакеры могут похищать конфиденциальные данные из неправильно сконфигурированных хранилищ. Например, по этой причине в марте 2020 года была похищена база данных , содержащая более 500 тыс. конфиденциальных и частных юридических и финансовых документов. А в феврале 2020 года было обнаружено открытое хранилище, связанное с облачным приложением JailCore , содержащее более 36 тыс. записей со сведениями о заключённых из исправительных заведений США.

Ошибка № 2: уязвимый код в хранилище

Amazon не рекомендует использовать хранилища S3 для размещения динамического контента, например, серверных скриптов. Однако многие пользователи не следуют этим правилам и готовы идти на риск.

Размещённая в S3 страница, содержащая уязвимый PHP-код. Источник: Trend Micro

Нам удалось найти написанный на PHP сайт, размещённый в Amazon S3. Когда браузер посетителя запрашивает страницы этого сайта, любой может увидеть, что на них используются инструменты командной строки curl и wget. Более пристальное изучение сайта может привести к раскрытию конфиденциальных сведений, например, учетных данных или частей кода, не предназначенных для публичного просмотра — путей к ресурсам и логики программирования. Это позволит злоумышленникам найти уязвимости в коде и проэксплуатировать их с помощью межсайтового скриптинга (XSS) или SQL-инъекции.

AWS Lambda

Пользователи этого сервиса не менее беспечны и точно так же, как и пользователи S3, игнорируют рекомендации по безопасному использованию, что в итоге приводит к инцидентам безопасности.

Ошибка № 1: уязвимый код

Функции AWS Lambda предназначены для запуска кода и выдачи результатов, поэтому некачественный код AWS Lambda может позволить злоумышленнику внедрить вредоносный код в данные, которые вводит пользователь. Входные данные могут поступать не только от обычного просмотра или вызова HTTP API. Функции AWS Lambda могут быть развёрнуты в различных вариантах, а вредоносные инъекции могут отправляться с различных триггеров, например, от Amazon Simple Notification Service (SNS), от электронной почты и даже от устройств IoT. В таких случаях обычный брандмауэр веб-приложений (WAF) на уровне API не способен защитить функции AWS Lambda от вредоносных инъекций, если функция не обрабатывает входные данные безопасным образом.

Ошибка № 2: раскрытие конфиденциальных данных

При запуске функций AWS Lambda специфические для среды настройки — авторизация, размер ресурсов и хост-контейнер, на котором запущен код, передаются в виде переменных окружения. Для авторизации или управления другими службами пользователи могут создавать собственные переменные с учётными данными, паролями, токенами авторизации и параметрами приложения. Срок жизни этих переменных заканчивается после окончания работы контейнера.

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

Ошибка № 3: уязвимые библиотеки и примеры кода из онлайн-репозиториев

При разработке функции пользователь должен помнить, что импортируемые библиотеки, как и сам код, должны быть защищены. Использование компонентов с известными уязвимостями — один из десяти основных рисков веб-приложений, согласно проекту Open Web Application Security Project (OWASP).

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

Рекомендации по созданию безопасных бессерверных приложений

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

Ниже приведены несколько рекомендаций по безопасности, которые помогут создавать более защищённые бессерверные приложения:

• Проводите качественный аудит кода. За создание безопасного кода отвечают пользователи, а не CSP. Надежный процесс аудита кода имеет решающее значение для обеспечения безопасности приложений, начиная со стадии проектирования и заканчивая развертыванием.

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

• Не оставляйте следов. Большинство целевых атак начинаются с разведки, поэтому постарайтесь свести к минимуму количество «отпечатков», оставленных используемыми службами. Например, вместо развертывания приложений, которые непосредственно подключаются к шлюзу Amazon API, можно выбрать собственный или сторонний компенсатор нагрузки, сеть доставки контента (CDN) или прокси-сервер.

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