Serverless Security 101: Как думать о безопасности бессерверного облака?

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

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

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

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

Что нужно защищать при использовании serverless
Это то, что облачные провайдеры — в данном случае AWS — называют «моделью общей ответственности бессерверных приложений»:

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

Как правило, вы можете думать об этом следующим образом:

Они отвечают за безопасность инфраструктуры.
Вы отвечаете за безопасность в инфраструктуре.

В целом, четыре столпа безопасности требуют вашего внимания, когда вы разрабатываете бессерверную инфраструктуру:

Мы будем использовать эту базовую архитектуру сервиса для изучения этих тем:

В этом простом CRUD-сервисе у нас есть 2 маршрута: POST: /author для создания и обновления авторов, и GET: /booksStats для возврата информации о статистике книг авторов.

Каждый маршрут связан со своей лямбда-функцией, а каждая лямбда имеет свои источники данных: authorHandler использует DocumentDB, а booksStatistics использует как ведро S3, так и таблицу DynamoDB.

Аутентификация и авторизация

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

  • Аутентификация — это проверка того, что вы являетесь тем, за кого себя выдаете.
  • Авторизация — это проверка того, что вам разрешено делать то, что вы пытаетесь сделать.

Вы, вероятно, уже используете какой-либо вид аутентификации (OAuth, Cognito, токены JWT и т.д.), чтобы позволить вашим пользователям входить и выполнять действия в вашей системе — но когда вы используете serverless, авторизация и аутентификация не ограничивается только вашими пользователями, но и вашими ресурсами — такими как функции Lambda и управляемые сервисы.

Одним из важнейших принципов безопасности является принцип наименьших привилегий — это означает предоставление пользователю/процессу только необходимых привилегий для выполнения его роли.

В случае с serverless это означает, что каждый ресурс — будь то Lambda, ECS Task, API-шлюз или что-то еще — должен иметь доступ и вызывать только те ресурсы, которые необходимы ему для выполнения своей функции.

Например, наша лямбда authorHandler на диаграмме должна запускаться только шлюзом API и иметь разрешения на доступ только к documentDB. Лямбда booksStatistics должна иметь доступ только к нашей таблице dynamoDB и ведру S3.

Это также означает, что если authorHandler использует имя пользователя/пароль для подключения к нашему documentDB, то эти секреты не должны быть видны никому, кто имеет доступ к лямбде (через веб-консоль или CLI) — поэтому их нельзя, например, хранить в виде переменных лямбды Env Variable, а лучше использовать сервисы вроде AWS SSM.

Безопасность и целостность данных

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

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

С точки зрения безопасности данные немного странные: Они существуют в двух состояниях — In transit и At rest.

Ваши данные должны быть зашифрованы на обоих этих этапах — поэтому все ваши соединения должны быть зашифрованы (да, как https, если вы используете http), и все ваши решения для хранения данных — файлы, сетевые диски, кэш, базы данных, ведра и т.д.

В нашем примере выше вы, вероятно, захотите зашифровать ведро S3, таблицу DynamoDB (зашифрованную по умолчанию) и DocumentDB — все это правильно, но здесь скрыта еще одна уязвимость.

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

Но недостаточно защитить данные, когда они находятся в пути и в состоянии покоя’ — вам также нужно убедиться, что никто не пытается вас обмануть — поэтому, по сути, вам нужно провести некоторую санацию данных.

Например, злоумышленник может ввести John Doe; DROP TABLE users;, когда ему будет предложено ввести свое имя — и хотя строка будет зашифрована на пути к серверу и (возможно) надежно сохранена в вашей базе данных, вы все равно не захотите, чтобы эта информация обрабатывалась как есть.

Мониторинг и протоколирование

Мониторинг и протоколирование — это эквивалент облачных технологий, когда на вашем предприятии установлены камеры наблюдения.

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

Существует множество сервисов для ведения журналов (DataDog, Logz.io, AWS CloudWatch и т.д.), и, как правило, каждый поставщик облачных услуг имеет свой собственный сервис, который регистрирует все действия в системе — например, AWS CloudTrail, GCP Cloud Audit и Azure Sentinel.

Атаки грубой силы

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

Как обеспечить безопасность всего (и всех)?

Все вышеперечисленные темы одновременно и сложны для решения, и ими легко пренебречь. Хотя IaC (Infrastructure as Code) и serverless значительно упрощают многие вещи, убедиться в том, что простота разработки не наступает на просторы безопасности, очень сложно. В следующих нескольких постах этой серии мы рассмотрим, какие инструменты вы можете использовать для проверки, мониторинга и создания инфраструктуры в соответствии с подходом «безопасность по проекту».

Следующие шаги

Хотите попробовать? Мы предоставляем бесплатный вечный план для разработчиков.
Создайте свою бесплатную учетную запись сегодня на сайте https://app.altostra.com.

Хотите быть в курсе последних новостей Altostra? Присоединяйтесь к нашему сообществу на Slack.

Мы хотим услышать вас! Поделитесь с нами своим опытом работы с Altostra в Twitter @AltostraHQ
и LinkedIn, а также любыми предложениями, которые могут сделать вашу работу в Altostra еще лучше.

Счастливого кодинга!

Оцените статью
devanswers.ru
Добавить комментарий