Korzystanie z grup ochrony AWS Shield Advanced w celu poprawy wykrywania i łagodzenia ataków DDoS

Klienci Amazon Web Services (AWS) mogą używać AWS Shield Advanced do wykrywania i łagodzenia ataków typu rozproszona odmowa usługi (DDoS), których celem są ich aplikacje działające w Amazon Elastic Compute Cloud (Amazon EC2), Elastic Local Balancing (ELB), Amazon CloudFront, AWS Global Accelerator i Amazon Route 53. Używając grup ochrony dla Shield Advanced, możesz logicznie pogrupować swoje kolekcje chronionych zasobów Shield Advanced. Za pomocą tego artykułu dowiesz się, jak używać grup ochrony, aby dostosować zakres wykrywania DDoS dla zdarzeń warstwy aplikacji i przyspieszyć łagodzenie zdarzeń w warstwie infrastruktury.

Czym jest grupa ochrony?

Grupa ochrony to zasób, który tworzysz, grupując chronione zasoby Shield Advanced tak, aby usługa traktowała je jako pojedynczą, chronioną jednostkę. Grupa ochrony może zawierać wiele różnych zasobów, które składają się na aplikację, a zasoby mogą być częścią wielu grup ochrony obejmujących różne regiony AWS w ramach konta AWS. Typowe wzorce, których można użyć podczas projektowania grup ochrony, obejmują wyrównywanie zasobów do aplikacji, zespołów aplikacji lub środowisk (takich jak produkcja i przemieszczanie) oraz według warstw produktów (takich jak bezpłatne lub płatne). Aby uzyskać więcej informacji na temat konfigurowania grup ochrony, zobacz Zarządzanie grupami ochrony AWS Shield Advanced.

Dlaczego powinieneś rozważyć korzystanie z grupy ochrony?

Korzyści z grup ochrony różnią się w przypadku zdarzeń warstwy infrastruktury (warstwa 3 i warstwa 4) oraz zdarzeń warstwy aplikacji (warstwa 7). W przypadku zdarzeń w warstwach 3 i 4 grupy ochrony mogą skrócić czas potrzebny na rozpoczęcie przez program Shield Advanced działań ograniczających zagrożenie. W przypadku zdarzeń warstwy 7 grupy ochrony dodają dodatkowy mechanizm raportowania. Nie ma zmian w mechanizmie, który Shield Advanced używa wewnętrznie do wykrywania zdarzenia i nie tracisz funkcjonalności poszczególnych wyszukań na poziomie zasobów. Otrzymujesz zarówno metryki Amazon CloudWatch na poziomie grupy, jak i indywidualne zasoby, które możesz przeznaczyć do użytku operacyjnego. Pora przyjrzeć się bardziej szczegółowo zaletom każdej warstwy.

Warstwy 3 i 4: Przyspiesz czas łagodzenia skutków zdarzeń DDoS

W przypadku zdarzeń w warstwie infrastruktury (warstwa 3 i warstwa 4) Shield Advanced monitoruje natężenie ruchu do chronionego zasobu. Anormalne odchylenie ruchu sygnalizuje możliwość ataku DDoS, a Shield Advanced następnie wprowadza środki zaradcze. Domyślnie Shield Advanced obserwuje wzrost ruchu do zasobu w wielu kolejnych przedziałach czasu, aby ugruntować pewność, że trwa zdarzenie warstwy 3/warstwy 4. W przypadku braku grupy ochrony, Shield Advanced postępuje zgodnie z domyślnym zachowaniem oczekiwania na ustalenie zaufania, zanim zastosuje środki zaradcze dla każdego zasobu. Jeśli jednak zasoby są częścią grupy ochrony, a usługa wykryje, że jeden zasób w grupie jest celem, Shield Advanced używa tego zaufania dla innych zasobów w grupie. Może to przyspieszyć proces wprowadzania środków łagodzących dla tych zasobów.

Rozważ przypadek, w którym posiadasz aplikację wdrożoną w różnych regionach AWS, a każdy stos jest wyposażony w moduł równoważenia obciążenia sieciowego (NLB). Po włączeniu funkcji Shield Advanced na elastycznych adresach IP skojarzonych z równoważeniem obciążenia sieciowego w każdym regionie można opcjonalnie dodać te elastyczne adresy IP do grupy ochrony. Jeśli aktor jest skierowany do jednego z bilansów równoważenia obciążenia sieciowego w grupie ochrony i zostanie wykryty atak DDoS, Shield Advanced obniży próg wdrażania środków zaradczych w innych obciążeniach równoważenia obciążenia sieciowego skojarzonych z grupą ochrony. Jeśli zakres ataku zostanie przesunięty na cel innych NLB, Shield Advanced może potencjalnie złagodzić atak szybciej niż gdyby równoważenia obciążenia sieciowego nie było w grupie ochrony.

Uwaga: Ta korzyść dotyczy tylko elastycznych adresów IP i typów zasobów Global Accelerator.

Warstwa 7: Ogranicz liczbę fałszywych alarmów i popraw dokładność wykrywania zdarzeń DDoS

Shield Advanced wykrywa zdarzenia warstwy aplikacji (warstwa 7) po skojarzeniu z nią listy kontroli dostępu do sieci (web ACL) w AWS WAF. Shield Advanced wykorzystuje dane żądań dla powiązanej sieci ACL, analizuje je i tworzy linię bazową ruchu dla Twojej aplikacji. Usługa następnie używa tej linii bazowej do wykrywania anomalii we wzorcach ruchu, które mogą wskazywać na atak DDoS.

Gdy grupujesz zasoby w grupie ochrony, Shield Advanced agreguje dane z poszczególnych zasobów i tworzy linię bazową dla całej grupy. Następnie wykorzystuje tę powstałą linię bazową do wykrywania zdarzeń warstwy 7 dla zasobu grupowego. Kontynuuje również monitorowanie i raportowanie poszczególnych zasobów, niezależnie od tego, czy należą one do grup ochrony, czy nie.

Shield Advanced udostępnia trzy typy agregacji do wyboru (suma, średnia i maks.) w celu agregowania danych dotyczących wolumenu poszczególnych zasobów, które będą wykorzystywane jako punkt odniesienia dla całej grupy. W następnej sekcji poznasz trzy typy agregacji wraz z przypadkami użycia dla każdego z nich.

Uwaga: agregacja ruchu ma zastosowanie tylko do wykrywania w warstwie 7.

Przypadek 1: wdrożenia blue/green

Blue/green to popularna strategia wdrażania, która zwiększa dostępność aplikacji i zmniejsza ryzyko wdrożenia podczas wprowadzania zmian. Niebieskie środowisko uruchamia bieżącą wersję aplikacji, natomiast zielone środowisko uruchamia nową wersję aplikacji. Po zakończeniu testowania ruch aplikacji na żywo jest kierowany do środowiska zielonego, a środowisko niebieskie jest demontowane.

Podczas wdrożeń niebieskich/zielonych ruch do zielonych zasobów może w krótkim czasie przejść od zerowego obciążenia do pełnego obciążenia. Wykrywanie warstwy 7 przez Shield Advanced wykorzystuje linię bazową ruchu dla poszczególnych zasobów, więc nowo utworzone zasoby, takie jak Application Load Balancer (ALB), które są częścią operacji blue/green, nie będą miały linii bazowej, a szybki wzrost ruchu może spowodować, że Shield Advanced zadeklaruje zdarzenie DDoS. W tym scenariuszu zdarzenie DDoS może okazać się fałszywym alarmem.

W przykładowej architekturze zaprezentowanej na rysunku nr 1 autorzy skonfigurowali Shield tak, aby zawierał wszystkie zasoby typu ALB w jednej grupie ochrony z sumą typu agregacji. Shield Advanced użyje sumy ruchu do wszystkich zasobów w grupie ochrony jako dodatkowej linii bazowej. Na początek posiadasz tylko jeden ALB (zwany niebieskim). Po dodaniu zielonego ALB w ramach wdrożenia można opcjonalnie dodać go do grupy ochrony. Gdy ruch zmienia się z niebieskiego na zielony, łączny ruch do grupy ochrony pozostaje taki sam, nawet jeśli zmienia się natężenie ruchu dla poszczególnych zasobów tworzących grupę. Po usunięciu niebieskiego ALB, wraz z nim zostanie usunięta linia bazowa Shield Advanced dla tego ALB. W tym momencie zielony ALB nie istnieje wystarczająco długo, aby mieć własną dokładną linię bazową, ale linia bazowa grupy ochrony utrzymuje się. Nadal możesz otrzymać metrykę DDoSDetected CloudWatch o wartości 1 dla poszczególnych zasobów, ale dzięki grupie ochrony możesz ustawić jeden lub więcej alarmów na podstawie metryki DDoSDetected na poziomie grupy. W zależności od przypadku użycia aplikacji może to zmniejszyć liczbę powiadomień o zdarzeniach niepodlegających działaniu.

Uwaga: Być może masz już ustawione alarmy dla poszczególnych zasobów, ponieważ kreator wdrażania w programie Shield Advanced zapewnia opcję tworzenia alarmów po dodaniu ochrony do zasobu. Dlatego powinieneś przejrzeć alarmy, które już skonfigurowałeś, zanim utworzysz grupę ochrony. Samo dodanie zasobu do grupy ochrony nie zmniejszy liczby fałszywych alarmów.

Przypadek 2: Zasoby o podobnych do siebie wzorcach ruchu

Aplikacje klienckie mogą wchodzić w interakcje z wieloma usługami w ramach pojedynczej transakcji lub przepływu pracy. Usługi te mogą znajdować się za własnymi dedykowanymi dystrybucjami ALB lub CloudFront i mogą mieć podobne do siebie wzorce ruchu. W przykładowej architekturze przedstawionej na rysunku nr 2 widzisz dwie usługi, które są zawsze wywoływane w celu zaspokojenia żądania użytkownika. Rozważ przypadek, w którym dodajesz nową usługę do miksu. Zanim istniały grupy ochrony, skonfigurowanie nowego chronionego zasobu, takiego jak ALB lub CloudFront, wymagało Shield Advanced do zbudowania zupełnie nowej linii bazowej. Trzeba było poczekać przez pewien minimalny okres, zanim Shield Advanced mógł rozpocząć monitorowanie zasobu, a usługa musiałaby monitorować ruch przez kilka dni, aby była dokładna.

W celu zwiększenia dokładności wykrywania zdarzeń poziomu 7 można spowodować, że program Shield Advanced „odziedziczy” linię bazową istniejących usług, które są częścią tej samej transakcji lub przepływu pracy. Aby to zrobić, możesz umieścić nowy zasób w grupie ochrony wraz z istniejącą usługą lub usługami i ustawić typ agregacji na oznaczający. Shield Advanced będzie potrzebował trochę czasu, aby zbudować dokładny punkt odniesienia dla nowej usługi. Jednak grupa ochrony ma ustaloną linię bazową, więc nowa usługa nie będzie podatna na zmniejszoną dokładność wykrywania w tym okresie. Zauważ, że to ustawienie nie powstrzyma Shield Advanced przed wysyłaniem powiadomień dla nowej usługi pojedynczo; jednak możesz zamiast tego podjąć działania naprawcze w oparciu o wykrycie grupy.

Przypadek 3: Zasoby dzielące ruch w sposób nierównomierny

Pora rozważyć przypadek dystrybucji CloudFront z ALB jako źródłem. Jeśli zawartość jest przechowywana w pamięci podręcznej w lokalizacjach brzegowych CloudFront, ruch docierający do aplikacji będzie mniejszy niż ten odbierany przez lokalizacje brzegowe. Podobnie, jeśli istnieje wiele źródeł dystrybucji CloudFront, wielkość ruchu poszczególnych źródeł nie będzie odzwierciedlać zgromadzonego ruchu dla aplikacji. Scenariusze, takie jak unieważnienie pamięci podręcznej lub przełączenie awaryjne, mogą spowodować zwiększony ruch w jednym z początków ALB. Może to spowodować, że Shield Advanced wyśle „1” jako wartość metryki DDoSDetected CloudWatch dla tego ALB. Jednak w takim przypadku możesz nie chcieć inicjować alarmu lub podejmować działań naprawczych.

Dystrybucję CloudFront i pochodzenie (lub źródła) można połączyć w grupie ochrony z typem agregacji ustawionym na max. Shield Advanced uwzględni wielkość ruchu w dystrybucji CloudFront jako punkt odniesienia dla całej grupy ochrony. W przykładowej architekturze na rysunku 3 dystrybucja CloudFront przoduje do dwóch ALB i równoważy obciążenie między nimi. Atorzy połączyli wszystkie trzy zasoby (CloudFront i dwa ALB) w grupę ochrony. W przypadku awarii jednego ALB, drugi ALB odbierze cały ruch. W ten sposób możesz otrzymać powiadomienie o zdarzeniu dla aktywnego ALB na poziomie pojedynczego zasobu. Jeśli jednak Shield wykryje zdarzenie wolumetryczne, możesz nie otrzymać go dla grupy ochrony, ponieważ Shield Advanced użyje ruchu CloudFront jako podstawy do określenia wzrostu. Możesz ustawić jeden lub więcej alarmów i podjąć działania naprawcze zgodnie z przypadkiem użycia aplikacji.

Wnioski

W tym artykule autorzy przedstawili, w jaki sposób AWS Shield Advanced zapewnia możliwość grupowania zasobów w celu uznania ich za pojedynczą jednostkę logiczną do wykrywania i łagodzenia ataków DDoS. Może to pomóc w zmniejszeniu liczby fałszywych alarmów i skrócić czas łagodzenia skutków dla chronionych aplikacji.

Subskrypcja Shield Advanced zapewnia dodatkowe możliwości, wykraczające poza te omówione w powyższym poście, które uzupełniają Twoją ochronę obwodową. Co więcej, zapewnia integrację z AWS WAF do wykrywania DDoS na poziomie 7, wykrywanie oparte na kondycji w celu zmniejszenia liczby fałszywych alarmów, lepszą widoczność zdarzeń DDoS, pomoc zespołu Shield Response, niestandardowe środki łagodzące i zabezpieczenia kosztów. Możesz dowiedzieć się więcej o możliwościach Shield Advanced w AWS Shield Advanced User Guide.

Źródło: AWS