Предыстория: я создаю веб-приложение с использованием Amazon API Gateway, Amazon S3, AWS Lambda и т. Д.
Примечание. Если вы не знаете об AWS, мы будем очень признательны за любые советы.
Ища, как защитить API Gateway от DDoS-атак, я нашел несколько ключевых слов, таких как AWS Shield, AWS WAF и так далее. В любом случае, кроме этого, я натолкнулся на идею, но, погуглил, поиск не нашел ничего, поэтому я не могу быть уверен, что идея верна.
Идея примерно такая, как показано ниже.
Прошедшие аутентификацию пользователи получают конечные точки динамически, что означает, что существует конечная точка для получения конечных точек для доступа к ресурсам. Теперь некоторая конечная точка выходит из строя из-за DDoS-атак, и пользователи получают ошибку 503, но пользователи автоматически получают конечную точку резервного копирования «конечной точкой для получения конечных точек», потому что я пишу код внешнего интерфейса таким образом и создаю несколько скопированных конечных точек резервного копирования в Amazon API Gateway.
Я хотел бы знать, будет ли это нормально работать.
Если вас беспокоит конечная точка за API GW, то экземпляр GW можно настроить так, чтобы добавить ограничение для каждого пользователя, чтобы аутентифицированный пользователь не мог выполнять больше запросов, чем вы разрешаете. Вы можете добавить проверку параметров, чтобы неверно сформированные запросы не попадали в ваш бэкэнд.
Кроме того, API GW является отказоустойчивым и высокодоступным сервисом, поэтому вы не можете его отключить (но можете выйти за рамки бюджета), поэтому конечная точка GW (как видно из мира, например, d123456.cloudfront.net) не отключится .
Похоже, вы описываете CDN (сеть доставки контента). По сути, это копия вашего статического сайта, доступная только для чтения, которая служит вашим новым интерфейсом. Важным аспектом этого является то, что интерфейс CDN больше не имеет кода на стороне сервера, поскольку этот интерфейс создается с помощью парсинга браузера, а затем повторно представляется после интерпретации, и поэтому может быть размещен в S3, где экземпляр EC2 с ранее требовался веб-сервер, что позволяло лучше масштабировать и контролировать условия DDoS-атак. Это эффективно для статических сайтов, но явно не работает для динамических приложений.
Если вы запускаете динамические приложения и вам необходимо предотвратить подобные атаки, WAF очень эффективен и имеет достаточно гибкие правила, чтобы ограничить практически любой вид трафика. Как вы видите, эти атаки происходят, WAF позволит вам адекватно адаптироваться без необходимости раскручивать дорогостоящие решения, такие как, например, F5 ASM. Хотя использование шлюза API обеспечивает серьезное отказоустойчивое решение вашей проблемы, допускающее чрезмерную пропускную способность, атака действительно может привести к потере счета. У шлюза API есть правила, которые позволят вам предотвратить это чрезмерное использование, и в сочетании с WAF позволит вам заблокировать этот би бизнес.
Наконец, вы можете рассмотреть возможность кэширования в пограничной сети. Серверы пограничного кеширования позволят вам иметь эти «конечные точки конечных точек» через глобально распределенные внешние серверы кэширования. Когда ваш исходный сервер выходит из строя, ваши кеши будут поддерживать ваши сайты и потенциально приложения в рабочем состоянии, как они были до окна простоя. Для этого есть несколько продуктов, в первую очередь CloudFront или Akamai.
Между всеми этими решениями вы должны иметь большую устойчивость к большинству видов DOS-атак с возможностью адаптации к новым видам позже.