DE{CODE}: Dlaczego Edge nie jest przypadkiem Edge

Gdy jesteś na krawędzi, szybkość, bezpieczeństwo i stan serwera nie mogą być przedmiotem refleksji. Podczas tej sesji wiceprezes ds. produktu Cloudflare, Sergi Isasi, i menedżer produktu WP Engine, Pavan Tirupati, omawiają, dlaczego myślenie o krawędzi jest niezbędne dla sukcesu każdej tworzonej lub utrzymywanej witryny

Slajdy sesji

Transkrypcja pełnego tekstu

PAVAN TIRUPATI : Hej wszystkim. Dziękujemy za dołączenie do nas w tej sesji o tym, że wiek nie jest przypadkiem skrajnym. Nazywam się Pavan Tirupati, menedżer produktu w WP Engine z zespołem The Outreach i jestem przede wszystkim odpowiedzialny za bezpieczeństwo, wydajność i niezawodność krawędzi w celu rozwoju i wzmocnienia pozycji klientów WP Engine.

Dziś dołącza do nas z Cloudflare Sergi, wiceprezes ds. zarządzania produktami. Sergi, chciałbyś się przedstawić?

SERGI ISASI : Jasne. Dzięki za przyjęcie mnie, Pavan. I dziękuję wszystkim za udział w naszej sesji. Jak powiedział Pavan, jestem wiceprezesem ds. wydajności aplikacji w Cloudflare i skupiam się na wydajności i niezawodności naszej krawędzi. Chcemy, aby wszystko było szybkie i niezawodne dla wszystkich naszych klientów. Produkty, które omawiam, to sposób, w jaki Cloudflare odbiera i przetwarza ruch na krawędzi, a więc zarówno w warstwie 4, jak i 7. Obejmuje to naszą pamięć podręczną, nasz serwer proxy, widmo FL, podstawową technologię Cloudflare, taką jak nasze systemy DNS, nasze systemy zarządzania certyfikatami i nasze Systemy zarządzania adresami IP, a następnie nowe aplikacje brzegowe, takie jak równoważenie obciążenia, nasz nowy produkt Waiting Room i nasze nadchodzące produkty Web3.

Jestem w Cloudflare od około 4 i 1/2 roku. I znowu, cieszę się, że mogę tu dzisiaj być.

PAVAN TIRUPATI: Niesamowite. A dzisiaj mamy dla was wspaniałą sesję, podczas której zagłębimy się w to, czym dokładnie jest krawędź i jak jest użyteczna, a także, jak mówi tytuł, dlaczego krawędź nie jest już przypadkiem krawędzi. Agenda, którą mamy dla was, to zagłębienie się w to, czym jest krawędź i jakie są z niej korzyści. A biorąc pod uwagę te czasy, bardzo ważne jest, aby bardziej skupić się na bezpieczeństwie.

Porozmawiamy o kilku przykładach i o niektórych zagrożeniach dla bezpieczeństwa. Przyjrzymy się również, w jaki sposób Edge będzie korzystny dla obecnych tutaj odbiorców i wszystkich, którzy są obecni w świecie cyfrowym. Przyjrzymy się również niektórym konkretnym przykładom, które mogą być korzystne dla osób, które mogą przechodzić przez niektóre z tych zagrożeń i problemów bezpieczeństwa.

Będzie więc ekscytująco, pomysłowo i odkrywczo. Zacznijmy więc od ustalenia kontekstu. Chcę ustawić pewną linię bazową tego, co jest krawędzią. I myślę, że nikogo nie zaskoczy, gdy powiem, że firmy doświadczają zmiany w kierunku kultury konstruktorów, która opiera się na zdolności programistów do bezpośredniego tworzenia i kontrolowania cyfrowych doświadczeń.

W miarę jak witryny i aplikacje przechodzą od konstrukcji monolitycznych do architektury opartej na mikrousługach, możliwość dostarczania treści z różnych źródeł staje się coraz ważniejsza. Wiemy i rozumiemy, że krawędź jest częścią internetu, która jest najbliżej naszych użytkowników końcowych, czasami nazywana również ostatnią milą. Ale zanim przejdę do szczegółów, Sergi, chcę wyjaśnić widzom, czym jest przewaga i dlaczego jest w ogóle krytyczna.

SERGI ISASI: Jasne. Tak więc od dawna mówi się o przetwarzaniu w chmurze, które brzmi: „chmura to po prostu czyjś komputer”. Bardzo podoba mi się to powiedzenie. Oznacza to, że jest to to samo, co na komputerze stacjonarnym lub laptopie, ale zarządza nim ktoś inny. A krawędź to dokładnie to samo, tylko bliżej użytkownika.

Dlaczego to jest ważne? Chcemy, aby rzeczy były – w Cloudflare – jak najbliżej użytkownika. I tak naprawdę sprowadza się to do tego stwierdzenia, które powiedziałeś, czyli ostatniej mili. Więc bez względu na to, jak szybko tworzysz swoje oprogramowanie, jak wydajnie możesz je zrobić, jeśli nawet na coś reagujesz – jeśli twoje oprogramowanie może działać w mniej niż milisekundę, nadal jesteś zobowiązany do prędkości światła. A jeśli twoje oprogramowanie nie znajduje się na urządzeniu użytkownika lub tak blisko użytkownika, jak to możliwe, użytkownik doświadczy tego niewielkiego opóźnienia. I czasami to opóźnienie jest OK, a czasami jest bardzo, bardzo irytujące dla użytkownika końcowego. Chodzi więc o optymalizację tego, co ma sens, aby być blisko użytkownika końcowego na krawędzi lub tego, co jest blisko rdzenia.

A to, co robi Cloudflare, to próba postawienia wszystkiego na krawędzi. Myślę, że jednym z powodów, dla których poprosiłeś mnie o przeprowadzenie tego czatu, jest to, że prowadzimy prawdopodobnie jedną z największych sieci brzegowych na świecie i oczywiście jesteśmy z tego niesamowicie dumni. Cloudflare ma nieco ponad 10 lat i przez cały ten czas budowaliśmy tę sieć. Rozrosło się do 250 miast, 100 różnych krajów, a celem – i faktycznie osiągnęliśmy ten cel – jest znalezienie się w ciągu 50 milisekund od 95% użytkowników Internetu na całym świecie. I znowu ostatnia mila – jeśli uda nam się zmieścić w ciągu 50 milisekund, możemy być znacznie szybsi dla każdego z tych użytkowników końcowych.

Drugim elementem jest łączenie się z innymi sieciami. Łączymy się więc z 10 000 innych sieci na całym świecie, na przykład z wieloma lokalnymi dostawcami usług internetowych, a także obsługujemy własną sieć szkieletową, więc wykonuj backhauling tego ruchu, gdy musimy przejść do rdzenia lub do źródła, spraw, aby nawet szybciej. Rok 2021 zakończyliśmy z nieco ponad 100 terabitami na sekundę pojemności. Jest to ważne, jeśli chodzi o skalowanie poziome zarówno wzrostu ruchu dla naszych klientów, jak i wzrostu ataków na naszych klientów, a także na naszą własną sieć.

Jedną z interesujących rzeczy w obliczeniach w ciągu ostatnich 30, 40 lat było ich przechodzenie tam iz powrotem, od brzegu do rdzenia do klienta, w zależności od tego, gdzie miało to sens i gdzie znajdowała się cała moc obliczeniowa w tym momencie. Więc jeśli cofniesz się wstecz do przedpublicznego Internetu, miałeś komputery typu mainframe. Miałeś dużo mocy obliczeniowej w rdzeniu i bardzo mało mocy obliczeniowej na krawędzi i naprawdę niewielką przepustowość, aby przenosić to tam iz powrotem. Więc wysyłałeś polecenia do komputera mainframe, a on odsyłał wyniki tych poleceń w tekście.

Stamtąd przeszliśmy na wiele ulepszeń w punkcie końcowym, więc masz wielu grubych klientów – Windows, Microsoft Word, wszystkie te rzeczy, które teraz wykonywałeś dużo obliczeń w punkcie końcowym, a następnie wysyłałeś je z powrotem do, zazwyczaj rdzeń, aby udostępniać tę zawartość.

Gdy krawędź i rdzeń stały się mocniejsze, zacząłeś widzieć aplikacje w chmurze. Więc zamiast wprowadzić tę zmianę na swoim urządzeniu, dokonałeś zmiany w przeglądarce internetowej, która została rozpropagowana przez inne urządzenia w celu udostępnienia. Stało się to naprawdę ważne, gdy mieliśmy urządzenia mobilne, zwłaszcza wczesne urządzenia mobilne, które miały mniej mocy obliczeniowej, ale dużo większą przepustowość.

Dlaczego więc jest to krytyczne? Tak naprawdę chodzi o oczekiwania użytkowników dotyczące szybkości. Dlatego użytkownik zawsze chce dobrego doświadczenia użytkownika. Szczególnie dzisiaj idea dobrego doświadczenia użytkownika polega na natychmiastowej interakcji. Klikam na link, naciskam przycisk, coś się dzieje i tak naprawdę nie obchodzi mnie, gdzie to się stało. Może nawet nie wiem, gdzie to się stało, ale chcę, żeby to było szybko.

Inną rzeczą, która się zmieniła, jest środowisko, w którym się znajdujemy. Ataków jest więc znacznie więcej, głównie dlatego, że te urządzenia stały się potężniejsze. A potem obserwujemy wiele zmieniających się przepisów, ponieważ bezpieczeństwo i prywatność stają się priorytetem nie tylko dla użytkowników, ale także dla rządów. I właśnie dlatego Cloudflare wciąż dodaje POP. Widzimy więcej użytkowników, widzimy większy ruch, widzimy więcej ataków i widzimy więcej przypadków użycia, które moglibyśmy umieścić na krawędzi i uczynić potężnymi dla tych użytkowników końcowych.

PAVAN TIRUPATI: Niesamowite. Czy możemy zagłębić się trochę w pop? Co to jest POP? A co się zmieniło w POP-ach na przestrzeni czasu? A konkretnie zagłębiając się w implementację POP Cloudflare, co jest wyjątkowego?

SERGI ISASI: Dzięki za przywrócenie tego. Często mówię POP i powinienem sprecyzować, co to znaczy. To Internetowy Punkt Obecności. A w przypadku Cloudflare iw większości innych przypadków, gdy słyszysz, jak ktoś mówi o POP, oznacza to stos serwerów, który siedzi gdzieś i uruchamia oprogramowanie.

Jeśli chodzi o to, co zmieniło się w czasie, w rzeczywistości łatwiej jest mówić o tym, co się zmieniło, niż o tym, co się nie zmieniło. I trochę się tym zajmiemy. Mamy więc serwery 11. generacji. O każdej z tych iteracji piszemy na naszym blogu. Tak więc coraz szybsze komputery na brzegu sieci są świetne. Oznacza to niższe koszty, oznacza więcej możliwości, oznacza po prostu lepsze rzeczy dla użytkowników końcowych.

Jedną z interesujących rzeczy, które zmieniły się na przestrzeni czasu, jest to, że faktycznie wdrożyliśmy trzy różne architektury procesorów – a właściwie dwie różne architektury procesorów, trzech producentów. Więc używamy zarówno Intela, jak i AMD, a także ARM na naszej krawędzi.

Inną rzeczą, która zmieniła się w czasie, jest to, że ciągle dodajemy lokalizacje. Nie jest dla mnie jasne, ile ich mieliśmy, kiedy wystartowaliśmy ponad 10 lat temu. To było w zakresie kilkunastu. Ale jest zabawna historia naszego CTO, który był wczesnym fanem Cloudflare, znał naszych założycieli, ale odmówił dołączenia do Cloudflare, dopóki nie zdobył POP blisko miejsca, w którym był w Europie. Powiedział, kiedy to się zbliża? A potem dołączę.

Nasze lokalizacje rozwijały się najpierw w oparciu o popyt. Widzisz więc duży ruch w regionie, ogólnie rzecz biorąc, umieszczenie sprzętu w regionie i obsługiwanie tam ruchu jest ogólnie tańsze. Więc zaczęliśmy to robić na początku.

Kiedy staliśmy się wielcy, zaczęliśmy widzieć lokalnych partnerów lub dostawców usług internetowych, którzy zaczęli prosić nas o zbudowanie sprzętu w regionie, aby zwiększyć wydajność dla nich i ich użytkowników końcowych. To była interesująca zmiana morska w świecie Cloudflare.

Naszym pierwotnym celem było znalezienie się w ciągu 100 milisekund od użytkowników końcowych. Wtedy zdaliśmy sobie sprawę, że stać nas na więcej. Więc teraz mamy cel 50 milisekund. I nie zdziwiłbym się, gdybyście zauważyli, że z biegiem lat zmniejszają się one jeszcze bardziej.

To, co się nie zmieniło, to to, że bardzo wcześnie dokonaliśmy wyjątkowego dla nas i dość brzemiennego w skutki wyboru, polegającego na uruchamianiu tego samego oprogramowania na każdym serwerze brzegowym w każdej lokalizacji. Okazało się to łatwiejszym wyborem dla większości naszych zespołów inżynierskich. Wiemy, co działa na każdym urządzeniu, i możesz rozwiązywać problemy i uruchamiać je nieco wydajniej. Z tego powodu niektóre z naszych zespołów inżynierskich mają o wiele więcej pracy.

To znacznie ułatwia skalowanie, zarówno długoterminowe, jak i krótkoterminowe. W perspektywie krótkoterminowej umożliwia nam przenoszenie zasobów do różnych usług w zależności od obciążenia i tego, co dzieje się w tej lokalizacji w danym momencie. Możemy skalować w poziomie na każdej maszynie.

W dłuższej perspektywie pozwala nam to proaktywnie decydować, gdzie mają trafić nowe maszyny, ponieważ wiemy, że musimy uruchomić cały stos. Inną dużą zaletą naszych zespołów inżynieryjnych, a zwłaszcza naszych zespołów inżynierów produktu, jest to, że mamy spójne wyniki w zakresie usług. Nie martwimy się, że jakaś lokalizacja jest bliższa określonym typom użytkowników, a zatem jest szybsza i ma inne wrażenia. Będzie spójny na wszystkich serwerach i na całym świecie.

Jedną z dużych zmian, które wprowadziliśmy — w tym momencie ma to prawdopodobnie trzy lata — jest to, że teraz pozwalamy naszym klientom uruchamiać ich kod na naszej krawędzi za pośrednictwem naszego produktu Workers. A miłą zaletą jest to, że gdy klient decyduje się na wdrożenie swojego produktu, faktycznie wybiera region świata. Nie zmuszamy ich do mówienia: chcę biegać na Zachodzie Stanów Zjednoczonych czy co tam jeszcze. Ich oprogramowanie jest wdrażane we wszystkich lokalizacjach i działa jak najbliżej gałki ocznej.

PAVAN TIRUPATI: Świetnie. Jak więc krawędź wypada w porównaniu z rdzeniem?

SERGI ISASI: Jasne. Więc to zależy od twojej architektury. W przypadku niektórych architektur krawędź jest rdzeniem, a rdzeń jest krawędzią. Jeśli masz tylko jedno miejsce, robisz wszystko na raz.

Ogólnie rzecz biorąc, brzeg będzie szybszy i wydajniejszy pod względem obliczeniowym, a rdzeń to miejsce, w którym przechowujesz tajemnice i konfigurację oraz przesyłasz dane z rdzenia do brzegu.

PAVAN TIRUPATI: A czy Cloudflare ma rdzeń? A jeśli tak, to w jaki sposób jest to realizowane?

SERGI ISASI: Tak, od pierwszego dnia. I nie rozmawiamy o tym dużo. To trochę interesujące. Ale jeśli się nad tym zastanowić, zostaliśmy założeni w 2009 roku, więc uruchamianie wszystkiego na krawędzi było niewiarygodnie niepraktyczne w 2009 roku i, w niektórych przypadkach, niepraktyczne teraz.

Czym więc kierujemy się w rdzeniu? Zarządzanie konfiguracją – czyli musimy wypchnąć oprogramowanie. i musimy to zrobić skądś, więc wciąż rozwijamy oprogramowanie Cloudflare, wszystkie nasze nowe wersje, codziennie przesuwamy nasz kod, od naszego rdzenia do krawędzi. Następnie przeprowadzamy również konfigurację klienta, która nadal komunikuje się z naszymi głównymi centrami danych. I idzie stamtąd aż do krawędzi. W rzeczywistości jest to interesująca historia z WP Engine i naszego oprogramowania DNS.

Tak więc na początku Cloudflare uruchamiał PowerDNS, oprogramowanie DNS typu open source. W 2013 roku zaczęliśmy budować coś, co wewnętrznie nazywamy RR DNS, nasze własne oprogramowanie DNS. I bardzo wydajne oprogramowanie. Mieliśmy kilka stref, które zawierały setki tysięcy rekordów i wszystko szło stosunkowo dobrze zgodnie z tymi wymaganiami. A potem pojawił się WP i powiedzieli, że mamy w naszej strefie ponad milion rekordów. Szybkość aktualizacji, a więc możliwość wprowadzenia zmiany i przeforsowania jej do granic możliwości, była niezwykle krytyczna, ponieważ oznaczała, że ​​klient jest wdrażany i że musi mieć to doświadczenie. I to był dla nas prawdziwy przypadek skrajny. Więc spojrzeliśmy na to i powiedzieliśmy: OK, oczywiście musimy przerobić sposób zarządzania naszym rdzeniem i wysłać ten ruch na brzeg, aby obsłużyć zarówno rozmiar tej zawartości, jak i szybkość i częstotliwość jej aktualizacji.

Tak więc w 2016 roku jeden z naszych inżynierów DNS, Tom Arnfeld, zapytał, czy mógłby usiąść z WP Engine, aby właściwie zrozumieć, czego chcesz i dlaczego tego chcesz, oraz jak to będzie wyglądać w 2017 roku i jak będzie wyglądać w 2022, teraz, kiedy minęło już pięć lat. Tak więc to, co zrobiliśmy w 2017 r., polegało na przepisaniu całych struktur danych dla naszego oprogramowania DNS, aby na prośbę naszego dyrektora generalnego przenosiło dane z krawędzi jak za dotknięciem czarodziejskiej różdżki. I to była właściwie jedna z tych rzeczy, w których mieliśmy klienta z potrzebą, chcieliśmy zaspokoić tę potrzebę, ale musieliśmy przemyśleć, w jaki sposób przenosimy dane z rdzenia do krawędzi.

Kolejną rzeczą, którą nadal robimy u podstaw, jest analityka. Tak więc telemetria pochodzi z krawędzi do rdzenia. Nasi klienci, gdy przeglądają swoje dane analityczne, przechodzą do pulpitu nawigacyjnego lub interfejsu API, a wszystko to jest obsługiwane z rdzenia.

Z biegiem czasu wielkość klientów i zwiększone wyrafinowanie ataków skłoniły nas do ponownego przemyślenia sposobu wykonywania telemetrii. Wcześniej uruchamialiśmy na przykład całe nasze oprogramowanie do wykrywania DDoS. Tak więc telemetria przychodziłaby z krawędzi, rdzeń powiedziałby, że wygląda to na atak DDoS, i wysyłałaby dane z powrotem do krawędzi w celu złagodzenia. To wystarczy w przypadku niektórych ataków DDoS, ale w przypadku innych musimy podjąć taką decyzję na brzegu sieci. Dlatego w połowie ubiegłego roku rozszerzyliśmy nasz oryginalny system Gatebot, który obsługuje rdzeń, o kilka nowych systemów, które faktycznie działają na krawędzi i podejmują decyzje niezależnie od rdzenia, a następnie składają raporty, więc w pewnym sensie stale dostosowują się do ataku powierzchnia.

Ostatnią rzeczą, o której będę mówić, jest to, że większość naszego uczenia maszynowego wykonujemy dzisiaj. W szczególności w przypadku produktów zabezpieczających mocno opieramy się na uczeniu maszynowym. Ale chcemy zrobić więcej tego na brzegu, ponieważ prawdopodobnie widzimy podobny wzorzec w systemie DDoS. Dlatego nawiązaliśmy współpracę z firmą NVIDIA, aby uruchomić więcej naszych systemów uczenia maszynowego także na urządzeniach brzegowych.

PAVAN TIRUPATI: Sergi, wspomniałeś o DDoS i bezpieczeństwie. Chcę się w to trochę zagłębić, szczególnie dlatego, że bezpieczeństwo jest bardzo krytyczne. Jakie są niektóre trendy i rzeczy, które widzisz?

SERGI ISASI: Jasne, to trochę pobity rekord od nas, ale ataki DDoS są rekordowe. Z roku na rok bijemy ten rekord. Powodem tego jest to, że botnety faktycznie rosną i wykorzystują coraz potężniejsze urządzenia. Więc jeśli pomyślisz o tym, o ile szybszy jest teraz twój telefon komórkowy lub komputer w porównaniu z rokiem poprzednim, to ma sens tylko to, że mają one coraz większą pojemność do przeprowadzania dużych ataków, tak znaczną przepustowość, że odparliśmy Atak „2 terabajty na sekundę” jakiś czas temu – to drugi co do wielkości, o jakim słyszeliśmy – a także inteligentniejsze ataki, które mogą robić rzeczy bez dużej przepustowości, ale być może wielu żądań i kosztownych żądań.

Naprawdę mówimy tutaj o większym wyrafinowaniu ataków. I statystyka, która moim zdaniem jest najbardziej interesująca, coś, co my

właśnie mówiliśmy, że 8% ruchu na naszej krawędzi jest ograniczane. Więc zanim wprowadzimy jakiekolwiek zasady lub coś w tym stylu, 8% jest po prostu całkowicie odrzucane, co oznacza, że ​​dla klienta, który myśli o zabezpieczeniu na krawędzi, może szybko pozbyć się wielu transakcji i interakcji z ich aplikacją że po prostu nie chcą lub nie potrzebują, ponieważ jest to jakiś atak.

PAVAN TIRUPATI: Tak, aw WP Engine staramy się, aby Advanced Network, która jest jedną z naszych ofert sieciowych, była domyślna dla wszystkich naszych klientów, aby mogli wykorzystać tę dodatkową warstwę bezpieczeństwa. Jesteśmy również świadkami niespotykanego wcześniej wzrostu naszej oferty zabezpieczeń, GES, która jest powiązana – bardziej dostosowana do klientów, którzy szukają dodatkowych poziomów i warstw bezpieczeństwa. I jest dostarczany z – GES to coś, co jest dostarczane z zaporą sieciową aplikacji i Argo Smart Routing.

Ale jedną rzeczą, którą chcę tutaj podkreślić, jest to, że 65% klientów WP Engine nie jest obecnie w żadnej z tych sieci. Argo Smart Routing i WAF to coś, z czego z pewnością mogliby skorzystać. Czy mógłbyś więc trochę rozwinąć, jak ten inteligentny routing i WAF działają z perspektywy Cloudflare.

SERGI ISASI: Jasne. Argo jest więc bardzo ciekawym produktem. Jest to bardzo unikalne dla Cloudflare i jest to coś, co jest trochę oszałamiające, jeśli nie jesteś z tym zaznajomiony. Więc Argo bierze tę telemetrię, o której mówiłem, telemetrię brzegową, i faktycznie szuka lepszych tras w Internecie. Wewnętrznie mówi się, że to jak Waze dla internetu, co chyba trochę działa. Nie jest to moja ulubiona analogia, ale jest rozsądna.

Ponieważ czasami trasy są nieefektywne i nie są spójne. Dlatego dzisiaj przejście bezpośrednio do źródła może być szybsze, a czasem nie. Czasami bardziej sensowne jest dla nas przejście z jednej krawędzi Cloudflare do drugiej, aby w pewnym sensie ominąć niektóre przeciążenia Internetu.

Dużą zaletą Argo jest to, że zmniejsza wydajność ostatniej mili zarówno od użytkownika do krawędzi, jak i od krawędzi do źródła – ponieważ prawdopodobnie nie obsługujesz dziś wszystkich swoich treści z krawędzi – o 40%. A to ogromny wzrost, w zasadzie naciskając przycisk i nie wymagając żadnej zmiany kodu aplikacji.

PAVAN TIRUPATI: To całkiem odkrywcze. Dzięki, Sergi. Jakie zmiany zaobserwowałeś w swojej bazie klientów? Jaki jest praktyczny wpływ wzrostu ataków i rzeczywistej powierzchni ataków?

SERGI ISASI: Myślę więc, że dużą zmianą w 2020 i 2021 roku jest to, że zaczęliśmy obserwować wzrost liczby ataków ransomware i innego rodzaju oprogramowania ransomware, więc nie takiego, które przejęło punkt końcowy i zaszyfrowało go, ale raczej zaatakuje cię i ściągniemy, jeśli nam nie zapłacisz.

W 2020 roku widzieliśmy ich całkiem sporo. W 2021 roku zaobserwowaliśmy wzrost, ale zmianę wzorca. A zmiana wzorca polegała na znalezieniu celu, a nie na znalezieniu celu w tej samej branży. Interesujące jest to, że widzieliśmy, jak wiele firm zajmujących się transmisją głosową IP i telekonferencjami stało się celem ataków. To ma sens, prawda? Ponieważ wszyscy więcej pracowali zdalnie, te usługi były krytyczne. Ważne było, aby zarówno użytkownicy, jak i dostawcy pozostali online, aby atakujący miał tam bardzo oczywisty cel.

Jedna rzecz, która wciąż pozostaje aktualna, to wspólna inteligencja, która jest ważna. Podczas gdy widzieliśmy, jak każdy klient jest atakowany, widzieliśmy te same wzorce i ten sam wzorzec ataku skierowany do tych aplikacji, co ułatwia komuś takiemu jak my, kto widzi ten ruch – ułatwia nam blokowanie.

PAVAN TIRUPATI: Tak, przewidywalność lub wzorce są właściwie dobre w zrozumieniu danych, więc rozumiem. Ale jak i gdzie twórcy tej rozmowy powinni myśleć ogólnie o ochronie? Jaki najgorszy scenariusz widziałeś w przeszłości, którym możesz się tutaj podzielić?

SERGI ISASI: Jasne. Tak więc najgorszym scenariuszem jest skoncentrowany atak. Więc jeśli ktoś naprawdę chce zabrać cię w tryb offline, niezwykle trudno jest poradzić sobie z tego rodzaju zmotywowanym napastnikiem. Jest to więc coś do rozważenia, jeśli używasz aplikacji, która jest w jakiś sposób kontrowersyjna lub może mieć jakiegoś wroga. A to wiele rzeczy w dzisiejszych czasach.

Atak, który mam tutaj, jest przykładem Adidasa, który miał 17,2 miliona żądań na sekundę. Więc to nie jest przepustowość, to tylko rzeczywiste uzasadnione żądania HTTP. Nie zostały one wzmocnione ani sfałszowane. Tak więc ten atakujący miał dostęp do wystarczającej liczby urządzeń, które mogły nawiązywać te połączenia i sprawiać, że wyglądały na legalne – a właściwie były legalne. Ekstremalnie rozproszony atak. Wystąpiła pewna koncentracja w niektórych regionach, ale była widoczna w zdecydowanej większości naszych lokalizacji.

A najgorszym scenariuszem jest to, że łagodzenie było kosztowne. Dokonano tego w warstwie 7. Musieliśmy więc zaakceptować połączenie. Musieliśmy zakończyć SSL – więc to jest wiele uścisków dłoni w tę iz powrotem – zanim mogliśmy odeprzeć i zidentyfikować atak w porównaniu z legalnym ruchem. Więc to jest coś takiego, że jeśli próbujesz uruchomić to na lokalnym WAF lub coś w tym stylu, znalezienie ruchu będzie bardzo, bardzo drogie, a tym bardziej złagodzenie go.

PAVAN TIRUPATI: Świetnie. Dziękuję, Sergi. Pozostając przy kwestiach bezpieczeństwa, w czasie wojny, której jesteśmy obecnie świadkami w przypadku Rosji i Ukrainy, spodziewany jest wzrost cyberataków. W rzeczywistości CIA i FBI wydały wspólne zalecenie dotyczące destrukcyjnego charakteru tych ataków oraz tego, jak wrażliwe mogą być krytyczne zasoby i dane w tych czasach. Zalecają, aby wszystkie organizacje, niezależnie od wielkości, przyjęły podwyższoną postawę bezpieczeństwa. W WP obserwujemy również ten trend wzrostowy w atakach.

Jak oceniasz gotowość do takich wydarzeń? A jak możemy się przygotować na takie sytuacje? Niektóre inne duże wydarzenia, inne niż wojna rosyjsko-ukraińska, które przychodzą na myśl, to zdarzenie Log4shell, którego byliśmy świadkami w zeszłym roku, które miało wpływ na wiele aplikacji na całym świecie.

SERGI ISASI: Tak, to znaczy, musimy zareagować. To jest świat, w którym żyjemy. Rzeczy się zdarzają i naprawdę, naprawdę straszne rzeczy się zdarzają i musimy na nie reagować. Jeśli chodzi o Ukrainę, nie możemy dzielić się mnóstwem informacji, ale jedną z rzeczy, którymi możemy się podzielić, jest to, że chociaż ruch na Ukrainie pozostaje względnie stały z ogólnej perspektywy użytkownika, zaobserwowaliśmy znaczny wzrost zabezpieczeń zapór ogniowych.

Od typowych 8%, o których mówiliśmy wcześniej, do 30% wszystkich żądań. Oznacza to, że jest po prostu więcej ruchu związanego z atakami zmieszanego ze zwykłym ruchem użytkowników. I znowu, podobnie jak w poprzednim przykładzie, są to kosztowne środki zaradcze, które należy wykonać w warstwie 7, ponieważ trudno jest je zidentyfikować na podstawie zwykłych ataków opartych tylko na warstwie 4.

Rozmawiamy o Log4shell, to było chyba największe wydarzenie, jakie pamiętam od dłuższego czasu. To mocno uderzyło w branżę. Pamiętam, jak wiele osób, zarówno w Cloudflare, czytało wewnętrzną dyskusję, jak i po prostu pomyślałem, och, o Boże, to jest ogromne.

I to była luka w zabezpieczeniach i bardzo powszechny fragment oprogramowania, który pozwolił atakującemu wstawić dowolne znaki, a następnie obecność tych znaków spowodowała, że ​​oprogramowanie wysłało żądanie git dla adresu URL, który wstawił atakujący. Więc wszyscy się ścigali. Możesz nie znać swoich zależności. To rodzaj lekcji pierwszej, to znać swoje zależności, wiedzieć, jakie oprogramowanie używasz i jakie oprogramowanie działa.

Ale najważniejsze było to, że było tu wiele naprawdę sprytnych exploitów. Kiedy więc ograniczaliśmy to dla naszych klientów — i dla waszych klientów — mieliśmy wiele różnych odmian naszych reguł zapory ogniowej, które wciąż trzeba było wdrażać, ponieważ istniała zawartość i różne sposoby jej kodowania.

Jedną z rzeczy, które uważałem za najbardziej interesującą rzecz w Log4j, było to, że widzieliśmy to w potoku rejestrowania. Więc nawet jeśli myślałeś, że twoja aplikacja jest wystarczająco zabezpieczona zaporą ogniową, że nie otrzyma połączenia ze świata zewnętrznego, jeśli wyciągniesz zdarzenie dziennika, które zawiera te znaki, nadal pójdzie i wykona to żądanie. Tak więc prosty firewall nie wystarczył.

Edge jest tutaj ważny i bardzo pomocny, ponieważ umożliwia szybki i łatwy sposób inicjowania kontroli, niezależnie od tego, czy jesteś pewien, czy jesteś podatny na ataki, czy nie. Wdrożenie kontroli nie ma żadnych wad, co jest kolejnym powodem, dla którego udostępniliśmy ją nawet naszym darmowym klientom. Tak więc pojedynczy punkt kontrolny jest w rzeczywistości bardzo pomocny w tym scenariuszu.

PAVAN TIRUPATI: Jakie narzędzia lub techniki są dostępne dla klientów w celu skalowania ruchu w tym scenariuszu?

SERGI ISASI: Jasne, więc dla każdego scenariusza mamy pracowników na Cloudflare. Dzięki temu możesz uruchamiać swój kod na naszej krawędzi i możesz budować, co chcesz, bez martwienia się o skalowanie w poziomie.

Na początku 2021 roku wprowadziliśmy również produkt o nazwie Poczekalnia. Poczekalnia to coś, co prawdopodobnie znasz. Poszedłeś coś kupić i zostałeś ustawiony w kolejce, aby zdecydować, czy jest wystarczająco dużo tej rzeczy do kupienia. Może również działać dla aplikacji. Czy możesz połączyć się z witryną i mieć dobre wrażenia? A może powinieneś poczekać?

To naprawdę interesujący produkt, który zbudowaliśmy. Zbudowaliśmy go na krawędzi i przy użyciu pracowników Cloudflare. A to było trudne. Jest to prawdopodobnie prostszy produkt do zbudowania u podstaw. To nie jest DNA Cloudflare. Możemy budować rzeczy na krawędzi i tak naprawdę szukaliśmy możliwości skalowania. Jeśli spróbujesz skalować coś u podstaw, staje się to o wiele trudniejsze.

Dużym problemem, jaki mieliśmy podczas budowania poczekalni, było udostępnianie stanu. Chciałeś więc, aby użytkownicy mieli jedno doświadczenie w poczekalni na całym świecie. A mówiliśmy o ponad 200 lokalizacjach. To nie jest łatwe.

Więc dam ci przykład. Powiedzmy, że jest koncert w Bay Area. Większość kupujących ten koncert będzie w Bay Area i prawdopodobnie połączą się z naszym centrum danych w San Jose. Jednak niektóre nie. Będziesz mieć garstkę lub jakiś procent kupujących z całego świata, którzy przylecą na koncert lub być może podróżują w tym czasie.

Jak więc sprawić, by było sprawiedliwie? Nie możesz mieć kolejki dla użytkowników w Bay Area, a kolejka dla użytkownika jest w każdej innej lokalizacji. To wymagało od nas zastanowienia się, w jaki sposób możemy udostępniać stan na krawędzi. I myślę, że to jest miejsce, w którym przyszłość zmierza ku krawędzi.

Korzystamy z naszego własnego produktu Durable Objects — możesz to zobaczyć na slajdzie — do synchronizacji i udostępniania stanu we wszystkich lokalizacjach. Ale ponieważ my, jako branża, staramy się rozwiązać więcej tych problemów na brzegu sieci, myślę, że zaczniesz widzieć o wiele więcej przypadków użycia oprogramowania na brzegu sieci, gdzie udostępnianie stanu jest nadal trudne i co robisz o spójność, czy to ostateczną, czy natychmiastową? I myślę, że to jest przyszłość naszego oprogramowania.

PAVAN TIRUPATI: Świetnie. Dziękuję, Sergi. Wiem, że w WP Engine mamy tę mentalność na pierwszym miejscu, aby zapewnić naszym klientom wydajność i bezpieczeństwo. Sergi, jakie są Twoje ostatnie przemyślenia lub słowa rady, najważniejsze uwagi lub sugestie dla programistów, którzy budują na krawędzi?

SERGI ISASI: Myślę więc, że przede wszystkim budujesz we właściwym miejscu. A po drugie, myślę, że to ma być kreatywne. Jest wiele rzeczy, o których gdybyś rok temu zapytał mnie, czy moglibyśmy to zrobić na krawędzi, powiedziałbym, ech, nie wiem. nie sądzę. Znajdziesz tutaj szybsze tempo innowacji i wielu kreatywnych programistów, którzy myślą o problemach, o których myślisz, i wymyślają rozwiązania zarówno po stronie klienta, jak i produktu.

Kolejną interesującą rzeczą jest sposób komunikowania się i udostępniania. Widzieliśmy wiele ruchów, szczególnie w deweloperskich Discordach, dotyczących znajdowania nowych, kreatywnych sposobów rozwiązywania problemów i budowania większej ilości rzeczy na krawędzi. Myślę, że na koniec jako wtyczka do Cloudflare, jeśli jest coś, czego nie możesz zrobić, znajdź menedżera produktu Cloudflare. Wyślij nam e-mail, znajdź nas na Twitterze lub gdziekolwiek indziej i daj nam znać, co chcesz zbudować, a my zobaczymy, czy nie będziemy w stanie Ci pomóc.

PAVAN TIRUPATI: To niesamowite. I myślę, że można śmiało powiedzieć, że Edge nie jest już przypadkiem Edge, ponieważ jeśli skupiasz się na bezpieczeństwie i wydajności, to Edge jest miejscem, w którym warto być.

Więc dziękuję, Sergi, za te wspaniałe słowa o krawędzi. Mam nadzieję, że uznaliście tę sesję za przydatną. Dziękujemy za poświęcenie czasu i dołączenie do nas. Mam nadzieję, że masz dobrą resztę dnia.

PREZENTUJĄCY: I to jest podsumowanie DE{CODE} 2022. Mam nadzieję, że uznałeś to za inspirujące i odchodzisz z większą wiedzą na temat WordPressa i nowymi kontaktami ze społecznością. Wypatruj nagranych treści w witrynie od piątku, aby nadrobić zaległości lub ponownie obejrzeć film.

Na koniec chciałbym podziękować naszym sponsorom – Amsive Digital, Box UK, Candyspace, Draw, Elementary Digital, Illustrate Digital, Kanopi Studios, Springbox, Studio Malt, StrategiQ, WebDev Studios i 10Up. Ogromne podziękowania za wpłaty na naszą zbiórkę DECODE. Naprawdę doceniamy twoją hojność.

Teraz dla wszystkich, którzy wchodzili z nami w interakcje w naszym Centrum uczestników i podczas naszych sesji, wybierzemy trzech najlepszych zwycięzców i poinformujemy Cię, jak możesz odebrać nagrodę pod koniec DE{COD}E. Z niecierpliwością czekamy na ponowne spotkanie z Państwem w naszych przyszłych wydarzeniach, osobiście lub wirtualnie. Nie możemy się doczekać, aby przekazać Ci więcej informacji na temat najnowszych trendów rozwoju WordPress i sposobów ich wdrażania w celu szybszego tworzenia witryn WordPress. To wszystko ode mnie. Bardzo dziękujemy za dołączenie do nas i dbanie o siebie.