DE{CODE}: почему край не крайний случай

Когда вы находитесь на грани, скорость, безопасность и работоспособность сервера не могут быть запоздалыми. В этой сессии Серджи Исаси, вице-президент Cloudflare по продуктам, и менеджер по продуктам WP Engine Паван Тирупати обсуждают, почему для успеха каждого веб-сайта, который вы создаете или поддерживаете, необходимо иметь первоочередное мышление.

Слайды сессии

Полный текст стенограммы

ПАВАН ТИРУПАТИ : Всем привет. Спасибо, что присоединились к нам на этой сессии о том, что возраст на самом деле не является крайним случаем. Я Паван Тирупати, менеджер по продукту в WP Engine с командой The Outreach, и я в первую очередь отвечаю за безопасность, производительность и надежность периферии для роста и расширения возможностей клиентов WP Engine.

И сегодня к нам из Cloudflare присоединился Серджи, вице-президент по управлению продуктами. Сергей, не хочешь представиться?

СЕРГИЙ ИСАСИ : Конечно. Спасибо, что пригласил меня, Паван. И спасибо всем за участие в нашей сессии. Итак, как сказал Паван, я являюсь вице-президентом по продуктам для производительности приложений в Cloudflare и сосредоточен на производительности и надежности наших периферийных устройств. Мы хотим сделать все быстро и надежно для всех наших клиентов. Продукты, о которых я рассказываю, — это то, как Cloudflare получает и обрабатывает трафик на периферии, то есть как на уровне 4, так и на уровне 7. Это включает в себя наш кеш, наш прокси-сервер, спектр FL, фундаментальные технологии для Cloudflare, такие как наши системы DNS, наши системы управления сертификатами и наши Системы управления IP-адресами, а также новые периферийные приложения, такие как балансировка нагрузки, наш новый продукт «Зал ожидания» и наши будущие продукты Web3.

Я работаю в Cloudflare около 4 с половиной лет. И снова рад быть здесь сегодня.

ПАВАН ТИРУПАТИ: Потрясающе. И сегодня у нас есть замечательный сеанс для вас, ребята, когда мы углубимся в то, что именно является преимуществом и как оно полезно, и, как следует из названия, почему преимущество больше не является крайним случаем. Повестка дня, которую мы подготовили для вас, ребята, заключается в более глубоком изучении того, что такое преимущество и каковы его преимущества. И в наше время очень важно уделять больше внимания безопасности.

И мы собираемся поговорить о некоторых примерах и поговорить о некоторых угрозах безопасности. Мы также посмотрим, как Edge будет полезен для присутствующей здесь аудитории и всех, кто имеет цифровое присутствие в мире. И мы также рассмотрим некоторые конкретные примеры, которые могут быть полезны для людей, которые могут столкнуться с некоторыми из этих угроз и проблем безопасности.

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

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

СЕРДЖИ ИСАСИ: Конечно. Так что в облачных вычислениях есть давняя поговорка: «Облако — это просто чей-то компьютер». Мне очень нравится это высказывание. Это означает, что это то же самое, что и на вашем настольном компьютере или ноутбуке, но просто им управляет кто-то другой. Край — это то же самое, просто он ближе к пользователю.

Почему это важно? Мы хотим, чтобы в Cloudflare все было как можно ближе к пользователю. И это действительно сводится к тому заявлению, которое вы сказали, которое является последней милей. Таким образом, независимо от того, насколько быстро вы создаете свое программное обеспечение, насколько эффективным вы можете его сделать, даже если вы на что-то реагируете — если ваше программное обеспечение может работать за долю миллисекунды, вы все равно обязаны скорости света. И если ваше программное обеспечение не находится на устройстве пользователя или как можно ближе к пользователю, пользователь будет испытывать небольшую задержку. И иногда эта задержка в порядке, а иногда она очень и очень раздражает конечного пользователя. Таким образом, смысл в том, чтобы оптимизировать то, что имеет смысл быть ближе к конечному пользователю на периферии или ближе к ядру.

И что делает Cloudflare, так это то, что мы пытаемся сделать все на грани. Я думаю, что одна из причин, по которой вы попросили меня сделать этот чат, заключается в том, что у нас, возможно, одна из крупнейших периферийных сетей в мире, и мы, очевидно, невероятно гордимся ею. Cloudflare чуть больше 10 лет, и мы все это время строили эту сеть. Он вырос, чтобы быть в 250 городах, 100 разных странах, с целью — и на самом деле мы достигли этой цели — быть в пределах 50 миллисекунд от 95% интернет-пользователей по всему миру. И это, опять же, последняя миля — если мы сможем быть в пределах 50 миллисекунд, мы сможем быть намного быстрее для каждого из этих конечных пользователей.

Другая часть — это подключение к другим сетям. Таким образом, мы подключаемся к 10 000 других сетей по всему миру, например, к множеству местных интернет-провайдеров, а затем мы также управляем своей собственной магистральной сетью, поэтому делаем транзитную передачу этого трафика, когда нам нужно перейти к ядру или к источнику, сделать это даже быстрее. Мы закончили 2021 год с пропускной способностью чуть более 100 терабит в секунду. И это важно, когда речь идет о горизонтальном масштабировании как для увеличения трафика наших клиентов, так и для увеличения числа атак на наших клиентов, а также на нашу собственную сеть.

Одна из интересных особенностей вычислений за последние 30–40 лет — это их переход туда и обратно, от периферии к ядру и клиенту, в зависимости от того, где это имело смысл и где в тот момент находилась вся вычислительная мощность. Так что, если вы вернетесь к дообщественному Интернету, у вас были мэйнфреймы. У вас было много вычислительной мощности в ядре и очень мало вычислительной мощности на периферии и очень небольшая полоса пропускания для передачи туда и обратно. Итак, вы отправляли команды на мэйнфрейм, а он отправлял вам результаты этих команд в виде текста.

Оттуда мы перешли к множеству улучшений на конечной точке, так что у вас появилось много толстых клиентов — Windows, Microsoft Word, все те вещи, которые вы теперь выполняли много вычислений на конечной точке, а затем отправляли их обратно, как правило, на сервер. core, чтобы поделиться этим контентом.

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

Так почему это критично? На самом деле все дело в ожиданиях пользователей относительно скорости. Таким образом, пользователь всегда хочет хорошего пользовательского опыта. И особенно сегодня идея хорошего пользовательского опыта заключается в мгновенном взаимодействии. Я нажимаю на ссылку, нажимаю кнопку, что-то происходит, и мне все равно, где это произошло. Я могу даже не знать, где это произошло, но я хочу, чтобы это было быстро.

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

ПАВАН ТИРУПАТИ: Потрясающе. Можем ли мы немного углубиться в поп-музыку? Что такое ПОП? И что изменилось в СОЗ с течением времени? И, в частности, копаясь в реализации POP в Cloudflare, в чем уникальность?

СЕРДЖИ ИСАСИ: Спасибо, что вернули это. Я часто говорю СОЗ, и мне следует уточнить, что это значит. Это точка присутствия в Интернете. И в случае с Cloudflare, и в большинстве других случаев, когда вы слышите, как кто-то говорит о POP, это означает стек серверов, где-то стоящих, на которых работает программное обеспечение.

Что касается того, что изменилось с течением времени, то на самом деле проще говорить о том, что изменилось, чем о том, что не изменилось. И мы углубимся в это немного. Итак, у нас серверы 11-го поколения. Мы пишем о каждой из этих итераций в нашем блоге. Поэтому мы продолжаем получать более быстрые компьютеры на периферии, и это здорово. Это означает более низкие затраты, это означает больше возможностей, это означает просто лучшие вещи для конечных пользователей.

Одна из интересных вещей, которая со временем изменилась, заключается в том, что мы на самом деле реализовали на трех разных архитектурах ЦП — или на самом деле на двух разных архитектурах ЦП, трех производителей. Таким образом, мы используем как Intel, так и AMD, а также ARM.

Еще одна вещь, которая изменилась с течением времени, это то, что мы просто продолжаем добавлять местоположения. Мне не ясно, сколько у нас было, когда мы запустили 10 с лишним лет назад. Это было в пределах дюжины. Но есть забавная история нашего технического директора, который был одним из первых поклонников Cloudflare, знал наших основателей, но отказывался присоединиться к Cloudflare, пока не получил POP, близкий к тому месту, где он был в Европе. Он сказал, когда это будет? И тогда я присоединюсь.

Наши локации выросли в первую очередь за счет спроса. Итак, вы видите много трафика в регионе, на самом деле дешевле размещать оборудование в регионе и обслуживать там трафик. Так мы начали делать это в первую очередь.

Как только мы стали большими, мы начали видеть, как местные партнеры или интернет-провайдеры начали просить нас построить оборудование в регионе, чтобы сделать работу более эффективной для них и их конечных пользователей. Так что это было интересным кардинальным изменением в мире Cloudflare.

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

Что не изменилось, так это то, что мы очень рано сделали уникальный для нас и довольно судьбоносный выбор: мы будем запускать одно и то же программное обеспечение на каждом пограничном сервере в любом месте. Это оказалось более простым выбором для большинства наших инженерных команд. Мы знаем, что работает на каждом устройстве, и вы можете устранять неполадки и работать там немного эффективнее. Из-за этого у некоторых наших инженерных команд гораздо больше работы.

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

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

И одно из больших изменений, которые у нас произошли — этому, наверное, уже три года, — теперь мы позволяем нашим клиентам запускать свой код на нашей периферии через наш продукт Workers. И приятное преимущество заключается в том, что когда этот клиент решает развернуть свой продукт, он фактически выбирает регион мира. Мы не заставляем их говорить, я хочу баллотироваться на Западе США или что там у вас. Их программное обеспечение развернуто во всех местах и ​​работает как можно ближе к их глазам.

ПАВАН ТИРУПАТИ: Отлично. Так как же край соотносится с ядром?

СЕРДЖИ ИСАСИ: Конечно. Так что это зависит от вашей архитектуры. А для некоторых архитектур край — это ядро, а ядро ​​— это край. Если у вас есть только одно место, вы как бы делаете все сразу.

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

ПАВАН ТИРУПАТИ: А у Cloudflare есть ядро? И если да, то как это реализовано?

СЕРДЖИ ИСАСИ: Да, с первого дня. И мы не говорим об этом много. Это довольно интересно. Но если подумать, мы были основаны в 2009 году, поэтому управление всем на периферии было невероятно непрактичным в 2009 году и, в некоторых случаях, непрактичным сейчас.

Итак, что мы запускаем в ядре? Управление конфигурацией — поэтому мы должны продвигать программное обеспечение. и мы должны делать это откуда-то, поэтому мы по-прежнему продвигаем программное обеспечение Cloudflare, все наши новые версии, мы каждый день продвигаем наш код от нашего ядра до нашего края. А затем мы также запускаем конфигурацию клиента, которая по-прежнему взаимодействует с нашими основными центрами обработки данных. И идет оттуда к краю. И на самом деле это интересная история с WP Engine и нашим программным обеспечением DNS.

Итак, в первые дни Cloudflare использовала PowerDNS, программное обеспечение DNS с открытым исходным кодом. И в 2013 году мы начали создавать нечто, что мы внутри называем RR DNS, наше собственное программное обеспечение DNS. И очень эффективное программное обеспечение. У нас были некоторые зоны, которые содержали сотни тысяч записей, и все шло относительно хорошо в соответствии с этими требованиями. А потом пришли WP и сказали, что у нас, возможно, более миллиона записей в нашей зоне. А скорость обновления, то есть возможность вносить изменения и доводить их до наших пределов, была невероятно важна, потому что это означало, что клиент был подключен и ему нужно было получить этот опыт. И это был настоящий крайний случай для нас. Итак, мы посмотрели на это и сказали: «Хорошо, нам, очевидно, нужно переработать то, как мы управляем нашим ядром и направляем этот трафик на периферию, чтобы обрабатывать как размер этого контента, так и скорость и частоту, с которой вы его обновляете.

Итак, в 2016 году один из наших DNS-инженеров, Том Арнфельд, спросил, может ли он сесть за WP Engine, чтобы на самом деле понять, что вы хотите и почему вы хотите, и как это будет выглядеть в 2017 году, и как это будет выглядеть в 2022, теперь, когда нам уже пять лет. Итак, в 2017 году мы фактически переписали все структуры данных для нашего программного обеспечения DNS, чтобы по просьбе нашего генерального директора оно могло перемещать данные с периферии, как по волшебству. И на самом деле это была одна из тех вещей, когда у нас был клиент с потребностью, мы хотели удовлетворить эту потребность, но нам пришлось переосмыслить, как мы перемещаем данные из ядра на периферию.

Еще одна вещь, которую мы по-прежнему делаем в основе, — это аналитика. Таким образом, телеметрия поступает от края к ядру. Наши клиенты, когда они просматривают свою аналитику, переходят к панели управления или API, и все это обслуживается из ядра.

Со временем размер клиентов и возросшая изощренность атак фактически заставили нас переосмыслить то, как мы занимались телеметрией. Раньше мы запускали, например, все наше программное обеспечение для обнаружения DDoS на ядре. Таким образом, телеметрия будет поступать с периферии, ядро ​​скажет, что это похоже на DDoS, и отправит данные обратно на периферию для смягчения последствий. Этого достаточно для некоторых DDoS-атак, но для других нам нужно принять это решение на периферии. Поэтому в середине прошлого года мы дополнили нашу первоначальную систему Gatebot, которая управляет ядром, парой новых систем, которые фактически работают на периферии и принимают решения независимо от ядра, а затем отчитываются, таким образом постоянно адаптируясь к атаке. поверхность.

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

ПАВАН ТИРУПАТИ: Сергей, вы упомянули DDoS и безопасность. Я хочу немного углубиться в это, особенно потому, что безопасность очень важна. Какие тенденции и вещи вы наблюдаете?

СЕРДЖИ ИСАСИ: Конечно, у нас немного заезженный рекорд, но DDoS-атаки бьют рекорды. Мы бьём этот рекорд из года в год. Причина этого в том, что ботнеты на самом деле растут в размерах и используют более мощные устройства. Поэтому, если вы думаете о том, насколько быстрее ваш мобильный телефон или ваш компьютер по сравнению с прошлым годом, имеет смысл только то, что они получают все больше и больше возможностей как для проведения крупных атак, так и для значительной пропускной способности, мы отбили Атака «2 терабайта в секунду» недавно — это вторая по величине атака, о которой мы слышали, — а также более умные атаки, которые могут делать что-то без большой пропускной способности, но, возможно, с большим количеством запросов и дорогостоящих запросов.

На самом деле то, о чем мы здесь говорим, — это более изощренные атаки. И статистика, которая мне кажется наиболее интересной, то, что мы

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

ПАВАН ТИРУПАТИ: Да, и в WP Engine мы пытаемся сделать Advanced Network, одно из наших сетевых предложений, по умолчанию для всех наших клиентов, чтобы они могли использовать этот дополнительный уровень безопасности. И мы также наблюдаем беспрецедентный рост с нашим предложением безопасности, GES, которое более ориентировано на клиентов, которые ищут дополнительные уровни и слои безопасности. Кроме того, GES поставляется с брандмауэром для веб-приложений и интеллектуальной маршрутизацией Argo.

Но одну вещь, которую я хочу здесь подчеркнуть, это то, что 65% клиентов WP Engine в настоящее время не находятся ни в одной из этих сетей. Argo Smart Routing и WAF — это то, от чего они определенно могли бы выиграть. Не могли бы вы немного рассказать о том, как интеллектуальная маршрутизация и WAF работают с точки зрения Cloudflare.

СЕРДЖИ ИСАСИ: Конечно. Так что Argo — очень интересный продукт. Это очень уникально для Cloudflare, и это немного сбивает с толку, если вы не знакомы с этим. Таким образом, Argo берет ту телеметрию, о которой я говорил, пограничную телеметрию, и на самом деле ищет лучшие маршруты в Интернете. Есть поговорка, внутренне это как Waze для Интернета, что, я думаю, работает. Это не моя любимая аналогия, но вполне разумная.

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

Важным моментом Argo является то, что он снижает эффективность «последней мили» как от пользователя до периферии, так и от периферии до источника — потому что сегодня вы, вероятно, не обслуживаете весь свой контент с периферии — на 40%. И это огромное увеличение, поскольку в основном нажимается кнопка и не требуется никаких изменений кода для приложения.

ПАВАН ТИРУПАТИ: На самом деле это очень проницательно. Спасибо, Серджи. Какие изменения вы заметили в своей клиентской базе? Каковы практические последствия увеличения количества атак и фактической поверхности атак?

СЕРДЖИ ИСАСИ: Итак, я думаю, что большой сдвиг в 2020 и 2021 годах заключается в том, что мы начали наблюдать рост атак программ-вымогателей и других видов программ-вымогателей, то есть не тех, которые захватили конечную точку и зашифровали ее, а скорее мы собираемся атаковать. вас и снять вас, если вы не заплатите нам.

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

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

ПАВАН ТИРУПАТИ: Да, предсказуемость или закономерности на самом деле хороши для понимания данных, так что я это понимаю. Но как и где разработчики этой телеконференции должны думать о защите в целом? Каков наихудший сценарий, который вы видели в прошлом, и которым вы можете поделиться здесь?

СЕРДЖИ ИСАСИ: Конечно. Таким образом, наихудший сценарий — это целенаправленная атака. Поэтому, если кто-то действительно хочет вывести вас из сети, справиться с таким мотивированным злоумышленником чрезвычайно сложно. Так что это то, что следует учитывать, если вы используете приложение, которое в некотором роде вызывает споры или может иметь какого-то врага. И это много вещей в эти дни.

Атака, которую я здесь привожу, является примером того, что у Adidas было 17,2 миллиона запросов в секунду. Так что это не пропускная способность, это просто законные HTTP-запросы. Они не были усилены или подделаны. Таким образом, у этого злоумышленника был доступ к достаточному количеству устройств, которые могли установить эти соединения и сделать их законными — или на самом деле они были законными. Чрезвычайно распределенная атака. В некоторых регионах у него была некоторая концентрация, но он был замечен в подавляющем большинстве наших местоположений.

И в худшем случае смягчение последствий было дорогостоящим. Это было сделано на уровне 7. Так что нам пришлось принять соединение. Нам пришлось завершить SSL — так что это несколько рукопожатий, идущих туда и обратно — прежде чем мы смогли отразить и идентифицировать атаку по сравнению с законным трафиком. Таким образом, если вы пытаетесь запустить это на локальном WAF или чем-то подобном, это будет очень, очень дорого даже просто найти трафик, не говоря уже о его смягчении.

ПАВАН ТИРУПАТИ: Отлично. Спасибо, Серджи. Что касается безопасности, то во время войны, которую мы наблюдаем сейчас в России и Украине, ожидается всплеск кибератак. Фактически, ЦРУ и ФБР выпустили совместный бюллетень о разрушительном характере этих атак и о том, насколько уязвимыми могут быть критически важные активы и данные в это время. Они рекомендуют всем организациям, независимо от их размера, принимать повышенные меры безопасности. И в WP мы также наблюдаем тенденцию роста атак.

Как вы оцениваете готовность к подобным мероприятиям? И как мы можем подготовиться к таким ситуациям? Некоторые из других крупных событий, помимо российско-украинской войны, которые приходят на ум, — это событие Log4shell, свидетелями которого мы были в прошлом году и которое затронуло довольно много приложений по всему миру.

СЕРДЖИ ИСАСИ: Да, я имею в виду, что мы должны ответить. Это мир, в котором мы живем. Происходят вещи, и случаются очень, очень ужасные вещи, и мы должны реагировать на них. Что касается Украины, мы не можем поделиться тоннами информации, но одна из вещей, которыми мы можем поделиться, заключается в том, что, хотя трафик в Украине остается относительно стабильным с точки зрения общего пользователя, мы наблюдаем значительное усиление смягчения последствий брандмауэром.

Таким образом, он вырос с обычных 8%, ​​о которых мы говорили ранее, до 30% от общего числа запросов. Таким образом, это означает, что к обычному пользовательскому трафику примешивается больше атакующего трафика. И снова, как и в предыдущем примере, это дорогостоящие меры, которые необходимо выполнять на уровне 7, потому что их трудно отличить от обычных атак, основанных только на уровне 4.

Мы говорим о Log4shell, это было, наверное, самое большое событие, которое я могу вспомнить за долгое время. Так что это сильно ударило по индустрии. Я помню, как многие люди, как в Cloudflare, читали внутреннюю дискуссию, и я помню, что просто подумал: о, о боже, это грандиозно.

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

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

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

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

ПАВАН ТИРУПАТИ: Какие инструменты или методы доступны клиентам для масштабирования трафика в этом сценарии?

СЕРДЖИ ИСАСИ: Конечно, для любого сценария у нас есть работники Cloudflare. Это позволяет вам запускать свой код на нашем краю, и вы можете создавать все, что хотите, и не беспокоиться о горизонтальном масштабировании.

В начале 2021 года мы также представили продукт под названием «Зал ожидания». Зал ожидания — это то, с чем вы, вероятно, знакомы. Вы пошли что-то купить, и вас поставили в очередь, чтобы решить, достаточно ли этой вещи для покупки. Он также может работать для приложения. Можете ли вы подключиться к сайту и получить хороший опыт? Или стоит подождать?

На самом деле это действительно интересный продукт, который мы создали. Мы построили его на периферии и с использованием рабочих Cloudflare. И это было трудно. Это, вероятно, более простой продукт для создания ядра. Это не ДНК Cloudflare. Мы можем создавать вещи на грани, и на самом деле мы хотели масштабироваться. Если вы пытаетесь масштабировать что-то на уровне ядра, это становится намного сложнее.

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

Итак, я приведу вам пример. Скажем, здесь, в районе залива, идет концерт. Большинство покупателей на этот концерт будут в районе залива, и они, скорее всего, подключатся к нашему дата-центру в Сан-Хосе. Однако некоторые нет. У вас будет горстка или какой-то процент покупателей со всего мира, которые прилетят на концерт или, возможно, будут путешествовать в это время.

Так как же сделать это справедливым? У вас не может быть очереди для пользователей в районе залива, а очередь для пользователей есть в любом другом месте. Это потребовало от нас подумать, как мы можем делиться состоянием через границу. И я думаю, что именно здесь будущее как бы идет на край.

И мы используем наш собственный продукт Durable Objects — вы можете увидеть его здесь на слайде — для синхронизации и обмена состоянием во всех местах. Но по мере того, как мы, как отрасль, стремимся решать больше этих проблем на периферии, я думаю, вы начнете видеть гораздо больше вариантов использования программного обеспечения на периферии, где совместное использование состояния все еще затруднено, и что вы делаете? о последовательности, будь то возможная или немедленная? И я думаю, что это будущее нашего программного обеспечения.

ПАВАН ТИРУПАТИ: Отлично. Спасибо, Серджи. Я знаю, что в WP Engine у ​​нас есть этот менталитет, чтобы гарантировать, что мы обеспечиваем производительность и безопасность для наших клиентов. Сергей, каковы ваши последние мысли, или слова совета, или главные соображения, или предложения для разработчиков, которые строят на периферии?

СЕРДЖИ ИСАСИ: Итак, я думаю, прежде всего, вы строите в правильном месте. А во-вторых, я думаю, что это должно быть творческим. Есть много вещей, которые, если бы вы спросили меня год назад, можем ли мы сделать это на краю, я бы сказал, а, я не знаю. Я так не думаю. И здесь вы найдете более быстрый темп инноваций и множество творческих разработчиков, которые думают о проблемах, о которых вы думаете, и предлагают решения как для клиента, так и для продукта.

Еще одна интересная вещь - это своего рода общение и обмен. Мы видели много движений, особенно в Discords для разработчиков, в поиске новых, творческих способов решения проблем и создании большего количества вещей на периферии. Я думаю, наконец, в качестве плагина для Cloudflare, если есть что-то, что вы не можете сделать, найдите менеджера по продукту Cloudflare. Отправьте нам электронное письмо, найдите нас в Твиттере или где-то еще и сообщите нам, что вы хотите построить, и мы посмотрим, сможем ли мы помочь вам это сделать.

ПАВАН ТИРУПАТИ: Это потрясающе. И я думаю, будет справедливо сказать, что периферия больше не является граничным случаем, потому что если вы сосредоточены на безопасности и производительности, то периферия — это то, что вам нужно.

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

ВЕДУЩИЙ: И это подведение итогов DE{CODE} 2022. Надеюсь, вы нашли его вдохновляющим и уезжаете с большим опытом работы с WordPress и новыми связями в сообществе. Ищите записанный контент на сайте с пятницы, чтобы наверстать упущенное или посмотреть видео еще раз.

Я хочу в заключение поблагодарить наших партнеров-спонсоров — Amsive Digital, Box UK, Candyspace, Draw, Elementary Digital, Illustrate Digital, Kanopi Studios, Springbox, Studio Malt, StrategiQ, WebDev Studios и 10Up. Огромное спасибо за пожертвование на наш сбор средств DECODE. Мы очень ценим вашу щедрость.

Теперь для всех, кто взаимодействовал с нами в нашем Attendee Hub и на наших сессиях, мы выберем трех лучших победителей и сообщим вам, как вы можете получить свой приз в конце DE{COD}E. Мы с нетерпением ждем встречи с вами снова на наших будущих мероприятиях, лично или виртуально. Мы не можем дождаться, чтобы рассказать вам о последних тенденциях разработки WordPress и о том, как вы можете реализовать их для ускорения создания сайтов WordPress. Это все от меня. Большое спасибо, что присоединились к нам и берегите себя.