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