DE{CODE}: Mengapa Edge Bukan Kasus Edge

Saat Anda berada di tepi, kecepatan, keamanan, dan kesehatan server tidak bisa menjadi renungan. Dalam sesi ini, Cloudflare VP of Product Sergi Isasi dan WP Engine Product Manager Pavan Tirupati membahas mengapa memiliki mentalitas terdepan sangat penting untuk kesuksesan setiap situs web yang Anda buat atau pelihara

Slide Sesi

Transkrip Teks Lengkap

PAVAN TIRUPATI : Hai semuanya. Terima kasih telah bergabung dengan kami dalam sesi ini tentang bagaimana usia bukanlah masalah yang serius. Saya Pavan Tirupati, Manajer Produk di WP Engine dengan tim The Outreach, dan saya terutama bertanggung jawab atas keamanan, kinerja, dan keandalan edge untuk mengembangkan dan memberdayakan pelanggan WP Engine.

Dan bergabung dengan kami hari ini dari Cloudflare adalah Sergi, VP Manajemen Produk. Sergi, apakah Anda ingin memperkenalkan diri?

SERGI ISASI : Tentu. Terima kasih telah menerima saya, Pavan. Dan terima kasih, semuanya, telah bergabung dengan sesi kami. Seperti yang dikatakan Pavan, saya adalah Wakil Presiden Produk untuk Performa Aplikasi di Cloudflare, berfokus pada performa dan keandalan edge kami. Kami ingin membuat segalanya cepat dan dapat diandalkan untuk semua pelanggan kami. Produk yang saya bahas adalah bagaimana Cloudflare menerima dan memproses lalu lintas di edge, baik di layer 4 dan 7. Jadi itu termasuk cache kami, proksi kami, spektrum FL, teknologi fundamental untuk Cloudflare seperti sistem DNS kami, sistem manajemen sertifikat kami, dan kami Sistem manajemen alamat IP, dan kemudian juga aplikasi tepi baru, jadi penyeimbangan muatan, produk Ruang Tunggu baru kami, dan produk Web3 kami yang akan datang.

Saya sudah berada di Cloudflare selama sekitar 4 dan 1/2 tahun. Dan sekali lagi, senang berada di sini hari ini.

PAVAN TIRUPATI: Luar biasa. Dan hari ini, kami memiliki sesi yang luar biasa untuk kalian saat kami menggali lebih dalam tentang apa sebenarnya edge itu dan apa kegunaannya, dan seperti judulnya, mengapa edge bukan lagi casing edge. Agenda yang kami miliki untuk kalian adalah menggali lebih dalam tentang apa itu edge dan apa manfaatnya. Dan mengingat saat-saat ini, sangat penting untuk lebih fokus pada keamanan.

Dan kita akan berbicara tentang beberapa contoh dan berbicara tentang beberapa ancaman keamanan. Kami juga akan melihat bagaimana edge akan bermanfaat bagi audiens yang ada di sini dan semua orang yang memiliki kehadiran digital di dunia. Dan kita juga akan melihat beberapa contoh spesifik yang mungkin bermanfaat bagi orang-orang yang mungkin mengalami beberapa ancaman dan masalah keamanan ini.

Jadi itu akan menjadi menarik, banyak akal, dan berwawasan luas. Jadi mari kita mulai dengan menetapkan beberapa konteks di sini. Saya ingin menetapkan beberapa garis dasar tentang apa itu edge. Dan menurut saya tidak mengherankan bagi siapa pun ketika saya mengatakan bahwa perusahaan sedang mengalami pergeseran ke budaya pembangun, budaya yang dibangun di atas kemampuan pengembang untuk secara langsung menciptakan dan mengontrol pengalaman digital.

Saat situs dan aplikasi beralih dari build monolitik ke lebih banyak arsitektur layanan mikro, kemampuan untuk mengirimkan konten dari berbagai sumber menjadi semakin penting. Dan kami mengetahui dan memahami edge untuk menjadi bagian dari internet yang sebenarnya paling dekat dengan pengguna akhir kami, terkadang juga disebut sebagai mil terakhir. Tetapi sebelum saya membahas secara spesifik, Sergi, saya ingin mengatur level kepada audiens tentang apa kelebihannya dan mengapa itu bahkan kritis.

SERGI ISASI: Tentu. Jadi ada pepatah lama dalam komputasi awan, yaitu "awan hanyalah komputer orang lain". Saya sangat suka pepatah ini. Ini berarti bahwa itu adalah hal yang sama yang Anda miliki di desktop atau laptop Anda, tetapi hanya orang lain yang mengelolanya. Dan keunggulannya adalah hal yang persis sama, hanya saja lebih dekat dengan pengguna.

Mengapa itu penting? Kami ingin segalanya menjadi– di Cloudflare — sedekat mungkin dengan pengguna. Dan itu benar-benar sampai pada pernyataan yang Anda katakan, yang merupakan mil terakhir. Jadi, tidak peduli seberapa cepat Anda membuat perangkat lunak, seberapa efisien Anda membuatnya, bahkan jika Anda merespons sesuatu– jika perangkat lunak Anda dapat berjalan dalam submilidetik, Anda masih terikat pada kecepatan cahaya. Dan jika perangkat lunak Anda tidak ada di perangkat pengguna atau sedekat mungkin dengan pengguna, pengguna akan mengalami sedikit latensi itu. Dan terkadang latensi itu baik-baik saja dan terkadang sangat, sangat menggelegar bagi pengguna akhir. Jadi intinya adalah mengoptimalkan apa yang masuk akal untuk menjadi dekat dengan pengguna akhir di tepi atau apa yang dekat dengan inti.

Dan apa yang Cloudflare lakukan adalah kami mencoba menempatkan segalanya di ujung tanduk. Saya pikir salah satu alasan Anda meminta saya untuk melakukan obrolan ini adalah karena kami menjalankan salah satu jaringan tepi terbesar di dunia dan kami jelas sangat bangga akan hal itu. Cloudflare berusia lebih dari 10 tahun dan kami telah membangun jaringan ini selama ini. Ini berkembang menjadi 250 kota, 100 negara berbeda, dengan tujuan– dan sebenarnya kami telah mencapai tujuan ini– berada dalam 50 milidetik dari 95% pengguna internet di seluruh dunia. Dan itu, sekali lagi, mil terakhir– jika kita bisa berada dalam 50 milidetik, kita bisa jauh lebih cepat untuk setiap pengguna akhir tersebut.

Bagian lainnya adalah untuk terhubung ke jaringan lain. Jadi kami terhubung ke 10.000 jaringan lain di seluruh dunia, banyak ISP lokal, misalnya, dan kemudian kami juga mengoperasikan tulang punggung kami sendiri, jadi buat backhaul lalu lintas itu ketika kami perlu pergi ke inti atau ke asal, lakukan itu bahkan lebih cepat. Kami mengakhiri tahun 2021 dengan kapasitas sedikit di atas 100 terabit per detik. Dan itu penting dalam hal penskalaan horizontal untuk peningkatan lalu lintas bagi pelanggan kami dan juga peningkatan serangan terhadap pelanggan kami dan juga pada jaringan kami sendiri.

Salah satu hal yang menarik tentang komputasi selama 30, 40 tahun terakhir adalah transisinya, bolak-balik, dari ujung ke inti ke klien, tergantung di mana masuk akal dan di mana semua daya komputasi berada pada saat itu. Jadi jika Anda berpikir kembali ke internet pra-publik, Anda memiliki mainframe. Anda memiliki banyak daya komputasi pada intinya dan sangat sedikit daya komputasi pada edge dan jumlah bandwidth yang sangat kecil untuk melakukan transisi bolak-balik. Jadi Anda mengirimkan perintah ke mainframe dan itu akan mengirimkan kembali hasil dari perintah tersebut dalam bentuk teks.

Kami beralih dari sana ke banyak kemajuan di titik akhir sehingga Anda mendapatkan banyak klien gemuk– Windows, Microsoft Word, semua hal yang sekarang Anda lakukan banyak perhitungan di titik akhir dan kemudian mengirimkannya kembali ke, biasanya, inti untuk membagikan konten itu.

Saat edge dan core menjadi lebih kuat, Anda mulai melihat aplikasi cloud. Jadi, alih-alih melakukan perubahan itu di perangkat Anda, Anda membuat perubahan di browser web dan disebarkan melalui perangkat lain untuk dibagikan. Dan ini menjadi sangat penting ketika kami memiliki perangkat seluler, terutama perangkat seluler awal yang memiliki lebih sedikit komputasi tetapi lebih banyak bandwidth.

Jadi mengapa ini kritis? Ini benar-benar semua tentang harapan pengguna akan kecepatan. Jadi pengguna selalu menginginkan pengalaman pengguna yang baik. Dan terutama saat ini, gagasan tentang pengalaman pengguna yang baik adalah interaksi instan. Saya mengklik tautan, saya menekan tombol, sesuatu terjadi, dan saya tidak terlalu peduli di mana itu terjadi. Saya bahkan mungkin tidak tahu di mana itu terjadi, tetapi saya ingin itu cepat.

Hal lain yang berubah adalah lingkungan tempat kita menemukan diri kita sendiri. Jadi ada lebih banyak serangan secara signifikan, terutama karena perangkat tersebut menjadi lebih kuat. Dan kemudian kami melihat banyak peraturan yang berubah karena keamanan dan privasi tidak hanya menjadi perhatian utama bagi pengguna tetapi juga bagi pemerintah. Dan inilah mengapa Cloudflare terus menambahkan POP. Kami melihat lebih banyak pengguna, kami melihat lebih banyak lalu lintas, kami melihat lebih banyak serangan, dan kami melihat lebih banyak kasus penggunaan yang dapat kami manfaatkan dan menjadi kuat bagi pengguna akhir tersebut.

PAVAN TIRUPATI: Luar biasa. Bisakah kita menggali pop sedikit? Apa itu POP? Dan apa yang berubah di POPs dari waktu ke waktu? Dan secara khusus menggali implementasi Cloudflare dari POP, apa yang unik?

SERGI ISASI: Terima kasih telah mengembalikannya. Saya sering mengatakan POP, dan saya harus menjelaskan artinya. Ini adalah Titik Kehadiran internet. Dan dalam kasus Cloudflare dan dalam kebanyakan kasus lainnya, ketika Anda mendengar seseorang berbicara tentang POP, artinya adalah tumpukan server, duduk di suatu tempat, yang menjalankan perangkat lunak.

Sejauh apa yang berubah dari waktu ke waktu, sebenarnya lebih mudah untuk berbicara tentang apa yang telah berubah versus apa yang tidak. Dan kita akan membahasnya sedikit. Jadi kami berada di server generasi ke-11 kami. Kami menulis tentang masing-masing iterasi tersebut di blog kami. Jadi kami terus mendapatkan komputer yang lebih cepat di edge, dan itu bagus. Itu berarti biaya yang lebih rendah, itu berarti lebih banyak kemampuan, itu berarti hal-hal yang umumnya lebih baik bagi pengguna akhir.

Salah satu hal menarik yang telah berubah dari waktu ke waktu adalah kami benar-benar mengimplementasikan pada tiga arsitektur CPU yang berbeda– atau sebenarnya dua arsitektur CPU yang berbeda, tiga pabrikan. Jadi kami menjalankan Intel dan AMD, dan kami juga menjalankan ARM di sisi kami.

Hal lain yang telah berubah dari waktu ke waktu adalah kami terus menambahkan lokasi. Tidak jelas bagi saya berapa banyak yang kami miliki saat diluncurkan 10 tahun lebih yang lalu. Itu dalam kisaran selusin. Tapi ada cerita lucu CTO kami yang merupakan penggemar Cloudflare awal, mengenal pendiri kami, tetapi dia menolak untuk bergabung dengan Cloudflare sampai dia mendapatkan POP yang dekat dengan tempatnya di Eropa. Dia berkata, kapan ini datang? Dan kemudian saya akan bergabung.

Lokasi kami tumbuh pertama berdasarkan permintaan. Jadi Anda melihat banyak lalu lintas di suatu wilayah, sebenarnya lebih murah, umumnya, menempatkan perangkat keras di suatu wilayah dan melayani lalu lintas di sana. Jadi kami mulai melakukan itu pada awalnya.

Setelah kami menjadi besar, kami mulai melihat mitra lokal atau ISP mulai meminta kami untuk membuat perangkat keras di wilayah tersebut agar lebih efisien bagi mereka dan pengguna akhir mereka. Jadi itu adalah jenis perubahan laut yang menarik di dunia Cloudflare.

Tujuan awal kami adalah berada dalam jarak 100 milidetik dari pengguna akhir. Dan kemudian kami menyadari bahwa kami bisa berbuat lebih baik. Jadi sekarang kita memiliki sasaran 50 milidetik. Dan saya tidak akan terkejut jika Anda melihat itu semakin kecil seiring berjalannya waktu.

Apa yang tidak berubah adalah bahwa kami, sejak awal, membuat pilihan yang unik bagi kami dan cukup menentukan, yaitu kami akan menjalankan perangkat lunak yang sama di setiap server edge di setiap lokasi. Ini akhirnya menjadi pilihan yang lebih mudah bagi sebagian besar tim teknik kami. Kami tahu apa yang berjalan di setiap perangkat dan Anda dapat memecahkan masalah dan menjalankan berbagai hal dengan lebih efisien di sana. Beberapa tim teknik kami memiliki lebih banyak pekerjaan karena ini juga.

Itu memang membuat banyak hal lebih mudah untuk diukur, baik jangka panjang maupun jangka pendek. Dalam jangka pendek, ini memungkinkan kami untuk memindahkan sumber daya ke layanan yang berbeda sesuai kebutuhan, bergantung pada beban dan apa yang terjadi di lokasi tersebut pada saat itu. Kami dapat menskalakan secara horizontal di setiap mesin.

Dalam jangka panjang, ini memungkinkan kami untuk secara proaktif memutuskan ke mana mesin baru harus pergi karena kami tahu kami perlu menjalankan seluruh tumpukan. Keuntungan besar lainnya, bagi tim teknik kami dan khususnya tim teknik produk kami, adalah kami memiliki kinerja yang konsisten di seluruh layanan. Kami tidak khawatir tentang beberapa lokasi yang lebih dekat dengan jenis pengguna tertentu dan karena itu menjadi lebih cepat dan memiliki pengalaman yang berbeda. Ini akan konsisten di seluruh server dan di seluruh dunia.

Dan salah satu perubahan besar yang kami alami– saat ini mungkin baru berusia tiga tahun– adalah sekarang kami mengizinkan pelanggan untuk menjalankan kode mereka di edge kami melalui produk Worker kami. Dan keuntungan bagusnya adalah ketika pelanggan itu memilih untuk menggunakan produk mereka, mereka benar-benar memilih wilayah dunia. Kami tidak memaksa mereka untuk mengatakan, saya ingin mencalonkan diri di AS Barat atau apa pun. Perangkat lunak mereka digunakan di semua lokasi dan dijalankan sedekat mungkin dengan bola mata mereka.

PAVAN TIRUPATI: Bagus. Jadi bagaimana perbandingan tepi dengan inti?

SERGI ISASI: Tentu. Jadi itu tergantung pada arsitektur Anda. Dan untuk beberapa arsitektur, ujungnya adalah inti dan inti adalah ujungnya. Jika Anda hanya memiliki satu tempat, Anda melakukan semuanya sekaligus.

Namun, secara umum, edge akan menjadi lebih cepat dan lebih efisien untuk komputasi dan core adalah tempat Anda menyimpan rahasia dan konfigurasi dan Anda mendorong data dari core ke edge.

PAVAN TIRUPATI: Dan apakah Cloudflare memiliki inti? Dan jika ya, bagaimana penerapannya?

SERGI ISASI: Sejak hari pertama, ya. Dan kami tidak banyak membicarakannya. Agak menarik. Tetapi jika Anda memikirkannya, kami didirikan pada tahun 2009, jadi menjalankan segala sesuatunya di tepi sangat tidak praktis pada tahun 2009 dan, untuk beberapa hal, tidak praktis sekarang.

Jadi apa yang kita jalankan pada intinya? Manajemen konfigurasi– jadi kami harus mengeluarkan perangkat lunak. dan kami harus melakukannya dari suatu tempat, jadi kami masih mendorong perangkat lunak Cloudflare, semua versi baru kami, kami mendorong kode kami, setiap hari, dari inti hingga tepi kami. Dan kemudian kami juga menjalankan konfigurasi pelanggan yang masih berkomunikasi dengan pusat data inti kami. Dan itu pergi dari sana ke tepi. Dan ini sebenarnya cerita yang menarik di sini dari WP Engine dan perangkat lunak DNS kami.

Jadi pada awalnya, Cloudflare menjalankan PowerDNS, perangkat lunak DNS sumber terbuka. Dan kami mulai membuat sesuatu yang secara internal kami sebut RR DNS, perangkat lunak DNS kami sendiri, pada tahun 2013. Dan perangkat lunak yang sangat efisien. Kami memiliki beberapa zona yang memiliki ratusan ribu catatan dan semuanya berjalan relatif baik dengan persyaratan tersebut. Dan kemudian WP datang dan mereka mengatakan bahwa kami memiliki lebih dari satu juta rekaman di zona kami. Dan memperbarui kecepatan, sehingga kemampuan untuk membuat perubahan dan mendorongnya ke keunggulan kami, sangatlah penting karena itu berarti pelanggan sedang bergabung dan mereka perlu memiliki pengalaman itu. Dan ini adalah kasus tepi yang sebenarnya bagi kami. Jadi kami melihat itu dan berkata, Oke, kami jelas perlu mengubah cara kami mengelola inti kami dan mengirimkan lalu lintas itu ke tepi untuk menangani ukuran konten itu dan kecepatan serta frekuensi Anda memperbaruinya.

Jadi pada tahun 2016, salah satu insinyur DNS kami, Tom Arnfeld, bertanya apakah dia dapat duduk dengan WP Engine untuk benar-benar memahami apa yang Anda inginkan dan mengapa Anda menginginkannya, dan seperti apa tampilannya di tahun 2017, dan tampilannya di 2022, sekarang kita sudah lima tahun. Jadi apa yang kami lakukan pada tahun 2017 sebenarnya adalah menulis ulang seluruh struktur data untuk perangkat lunak DNS kami agar, atas permintaan CEO kami, untuk memindahkan data dari edge seperti sulap. Dan itu sebenarnya salah satu hal di mana kami memiliki pelanggan dengan kebutuhan, kami ingin memenuhi kebutuhan itu, tetapi kami harus memikirkan kembali cara kami memindahkan data dari inti ke tepi.

Hal lain yang masih kami lakukan pada intinya adalah analitik. Jadi telemetri berasal dari tepi ke inti. Pelanggan kami, ketika mereka melihat analitik mereka, mereka pergi ke dasbor atau API, dan itu semua dilayani dari inti.

Seiring waktu, ukuran pelanggan dan peningkatan kecanggihan serangan sebenarnya membuat kami memikirkan kembali cara kami melakukan telemetri. Kami sebelumnya menjalankan, misalnya, semua perangkat lunak pendeteksi DDoS kami pada intinya. Jadi telemetri akan masuk dari tepi, inti akan mengatakan, yang terlihat seperti DDoS, dan akan mengirimkan data kembali ke tepi untuk dimitigasi. Itu cukup untuk beberapa serangan DDoS, tetapi untuk yang lain, kita harus benar-benar membuat keputusan itu dari awal. Jadi kami menambah sistem Gatebot asli kami, yang menjalankan inti dengan beberapa sistem baru, pertengahan tahun lalu, yang benar-benar berjalan di tepi, dan membuat keputusan terlepas dari inti, lalu melaporkan kembali, jadi terus beradaptasi dengan serangan permukaan.

Hal terakhir yang akan saya bicarakan pada intinya adalah kita melakukan sebagian besar pembelajaran mesin pada intinya hari ini. Kami sangat mengandalkan pembelajaran mesin untuk, khususnya, produk keamanan. Tapi kami ingin melakukan lebih dari itu di tepi karena kami melihat, kemungkinan besar, pola yang mirip dengan sistem DDoS. Jadi kami bermitra dengan NVIDIA untuk mulai menjalankan lebih banyak ML kami di edge juga.

PAVAN TIRUPATI: Sergi, Anda menyebutkan DDoS dan keamanan. Saya ingin menggali sedikit, khususnya karena keamanan sangat penting. Apa saja tren dan hal-hal yang Anda lihat?

SERGI ISASI: Tentu, ini sedikit rekor yang rusak dari kami, tetapi serangan DDoS memecahkan rekor. Kami memecahkan rekor itu dari tahun ke tahun. Alasannya adalah ukuran botnet sebenarnya bertambah besar dan memanfaatkan perangkat yang lebih kuat. Jadi jika Anda berpikir tentang seberapa cepat ponsel Anda sekarang atau komputer Anda dibandingkan dengan tahun sebelumnya, masuk akal jika mereka mendapatkan lebih banyak kapasitas untuk meluncurkan serangan besar, throughput yang sangat signifikan, kami melawan a Serangan “2 terabyte per detik” beberapa saat yang lalu– Ini adalah yang terbesar kedua yang pernah kami dengar– dan kemudian juga serangan yang lebih cerdas yang dapat melakukan banyak hal tanpa banyak throughput, tetapi mungkin banyak permintaan dan permintaan yang mahal.

Sungguh yang kita bicarakan di sini lebih kecanggihan dari serangan. Dan stat yang menurut saya paling menarik, sesuatu yang kita

yang baru saja dibicarakan, apakah 8% lalu lintas di tepi kami dikurangi. Jadi sebelum kita melakukan aturan apa pun atau semacamnya, 8% dihilangkan sama sekali, yang berarti bahwa, bagi pelanggan yang berpikir untuk melakukan keamanan di edge, mereka dapat dengan cepat menyingkirkan banyak transaksi dan interaksi ke aplikasi mereka. bahwa mereka benar-benar tidak menginginkan atau membutuhkan karena itu semacam serangan.

PAVAN TIRUPATI: Ya, dan di WP Engine, kami mencoba membuat Advanced Network yang merupakan salah satu penawaran jaringan kami, menjadi default untuk semua pelanggan kami sehingga mereka dapat memanfaatkan lapisan keamanan tambahan ini. Dan kami juga menyaksikan pertumbuhan yang belum pernah terlihat sebelumnya dengan penawaran keamanan kami, GES, yang terkait– lebih selaras dengan pelanggan yang mencari tingkat dan lapisan keamanan tambahan. Dan dilengkapi dengan– GES adalah sesuatu yang dilengkapi dengan firewall aplikasi web dan Argo Smart Routing.

Tapi satu hal yang ingin saya soroti di sini adalah 65% pelanggan WP Engine saat ini tidak berada di salah satu jaringan ini. Argo Smart Routing dan WAF adalah sesuatu yang pasti bisa mereka manfaatkan. Jadi maukah Anda memperluas sedikit tentang cara kerja perutean cerdas dan WAF pada perspektif Cloudflare.

SERGI ISASI: Tentu. Jadi Argo adalah produk yang sangat menarik. Ini sangat unik untuk Cloudflare dan itu adalah sesuatu yang agak membingungkan jika Anda tidak begitu mengenalnya. Jadi Argo mengambil telemetri yang saya bicarakan, telemetri tepi, dan benar-benar mencari rute yang lebih baik di internet. Ada pepatah, secara internal, ini seperti Waze untuk internet, yang menurut saya berfungsi. Ini bukan analogi favorit saya, tapi masuk akal.

Karena terkadang rute tidak efisien dan tidak konsisten. Jadi hari ini, mungkin lebih cepat untuk langsung ke asal dan terkadang tidak. Terkadang lebih masuk akal bagi kami untuk benar-benar beralih dari satu tepi Cloudflare ke tepi lainnya untuk menghindari kemacetan internet.

Poin utama dari Argo adalah mengurangi efisiensi jarak tempuh terakhir baik dari pengguna ke edge dan edge ke origin– karena Anda mungkin tidak menyajikan semua konten Anda dari edge saat ini– sebesar 40%. Dan itu adalah peningkatan besar dengan menekan tombol dan tidak memerlukan perubahan kode apa pun untuk aplikasi.

PAVAN TIRUPATI: Itu sebenarnya cukup berwawasan. Terima kasih, Sergi. Perubahan apa yang Anda lihat untuk basis pelanggan Anda? Apa dampak praktis dari peningkatan serangan dan permukaan serangan yang sebenarnya?

SERGI ISASI: Jadi menurut saya perubahan besar pada tahun 2020 dan memasuki tahun 2021 adalah kita mulai melihat munculnya serangan ransomware dan jenis ransomware yang berbeda, jadi bukan yang mengambil alih titik akhir dan mengenkripsinya, melainkan kita akan menyerang Anda dan menjatuhkan Anda jika Anda tidak membayar kami.

Pada tahun 2020, kami melihat sedikit dari itu. Pada tahun 2021, kami melihat peningkatan tetapi ada perubahan pola. Dan perubahan polanya adalah, daripada menemukan target secara umum, melainkan menemukan target di industri yang sama. Jadi yang menarik adalah kami melihat banyak perusahaan voiceover IP dan teleconference menjadi sasaran. Agak masuk akal, bukan? Jadi karena semua orang lebih sering bekerja dari jarak jauh, layanan ini sangat penting. Dan penting bagi pengguna dan penyedia untuk tetap online, sehingga penyerang memiliki target yang sangat jelas di sana.

Satu hal yang tetap benar adalah kecerdasan bersama itu penting. Sementara kami melihat setiap pelanggan menjadi sasaran, kami melihat pola yang sama masuk dan pola serangan yang sama menuju ke aplikasi tersebut, yang memudahkan orang seperti kami yang melihat lalu lintas tersebut– memudahkan kami untuk memblokir.

PAVAN TIRUPATI: Ya, prediktabilitas atau pola sebenarnya bagus dalam memahami data, jadi saya mengerti. Tapi bagaimana dan di mana para devs pada panggilan ini memikirkan tentang perlindungan secara umum? Apa skenario terburuk yang pernah Anda lihat di masa lalu yang dapat Anda bagikan di sini?

SERGI ISASI: Tentu. Jadi skenario terburuk adalah serangan terfokus. Jadi jika seseorang benar-benar ingin membuat Anda offline, sangat sulit untuk menangani penyerang yang termotivasi seperti itu. Jadi, ini sesuatu yang perlu dipertimbangkan jika Anda menjalankan aplikasi yang kontroversial atau mungkin memiliki semacam musuh. Dan itu banyak hal hari ini.

Serangan yang saya miliki di sini adalah contoh Adidas yang memiliki 17,2 juta permintaan per detik. Jadi ini bukan throughput, ini hanyalah permintaan HTTP yang sebenarnya sah. Ini tidak diperkuat atau dipalsukan. Jadi penyerang ini memiliki akses ke perangkat yang cukup yang dapat membuat koneksi ini dan membuatnya tampak sah– atau sebenarnya, itu sah. Serangan yang sangat terdistribusi. Itu memang memiliki konsentrasi di beberapa wilayah, tetapi terlihat di sebagian besar lokasi kami.

Dan skenario terburuknya adalah mitigasi itu mahal. Itu dilakukan pada layer 7. Jadi kami harus menerima koneksi. Kami harus menghentikan SSL– jadi itu adalah sejumlah jabat tangan bolak-balik– sebelum kami dapat menangkis dan mengidentifikasi serangan versus lalu lintas yang sah. Jadi ini adalah hal yang, jika Anda mencoba menjalankan ini di WAF lokal atau sesuatu seperti itu, itu akan menjadi sangat, sangat mahal hanya untuk menemukan lalu lintas, apalagi menguranginya.

PAVAN TIRUPATI: Bagus. Terima kasih, Sergi. Berpegang teguh pada keamanan, selama masa perang, seperti yang kita saksikan dengan Rusia dan Ukraina sekarang, diperkirakan akan ada peningkatan serangan dunia maya. Faktanya, CIA dan FBI telah mengeluarkan penasehat bersama tentang sifat destruktif dari serangan ini dan betapa rentannya aset dan data penting selama masa-masa ini. Mereka merekomendasikan agar semua organisasi, terlepas dari ukurannya, mengadopsi sikap keamanan yang lebih tinggi. Dan di WP, kami juga melihat tren naik ini dalam serangan.

Apa pendapat Anda tentang kesiapan untuk acara seperti ini? Dan bagaimana kita dapat mempersiapkan diri untuk situasi seperti itu? Beberapa peristiwa besar lainnya selain perang Rusia-Ukraina yang terlintas dalam pikiran adalah peristiwa Log4shell yang kami saksikan tahun lalu, yang memengaruhi cukup banyak aplikasi di seluruh dunia.

SERGI ISASI: Ya, maksud saya, kita harus merespons. Itulah dunia tempat kita berada. Hal-hal terjadi, dan hal-hal yang sangat, sangat buruk terjadi, dan kita harus bereaksi terhadapnya. Sejauh Ukraina berjalan, kami tidak dapat membagikan banyak informasi, tetapi salah satu hal yang dapat kami bagikan adalah, sementara lalu lintas di Ukraina tetap relatif konsisten dari perspektif pengguna secara keseluruhan, kami telah melihat mitigasi firewall meningkat pesat.

Jadi itu berubah dari 8% yang biasa kita bicarakan sebelumnya menjadi 30% dari total permintaan. Dan itu berarti ada lebih banyak lalu lintas serangan yang tercampur dengan lalu lintas pengguna biasa. Dan lagi, seperti contoh sebelumnya, ini adalah mitigasi yang mahal, hal-hal yang harus dilakukan pada lapisan 7 karena sulit untuk mengidentifikasinya dari serangan biasa yang hanya didasarkan pada lapisan 4.

Kami berbicara tentang Log4shell, itu mungkin peristiwa terbesar yang dapat saya ingat dalam waktu yang lama. Jadi ini memukul industri cukup keras. Saya ingat banyak orang, baik di Cloudflare, membaca diskusi internal, dan saya ingat hanya berkata, oh, oh Tuhan, ini luar biasa.

Dan itu adalah kerentanan dan perangkat lunak yang sangat umum yang memungkinkan penyerang memasukkan beberapa karakter arbitrer, dan kemudian kehadiran karakter tersebut akan menyebabkan perangkat lunak pergi dan mengeluarkan permintaan git untuk URL yang dimasukkan penyerang. Jadi semua orang berebut. Anda mungkin tidak mengetahui ketergantungan Anda. Itu semacam pelajaran pertama, adalah mengetahui ketergantungan Anda, mengetahui perangkat lunak apa yang Anda jalankan, dan perangkat lunak apa yang dijalankan perangkat lunak itu.

Tapi hal besarnya adalah ada banyak eksploitasi yang sangat pintar di sini. Jadi ketika kami mengurangi ini untuk pelanggan kami– dan untuk pelanggan Anda– kami memiliki banyak variasi berbeda dari aturan firewall kami yang terus harus diterapkan karena ada konten dan berbagai cara untuk menyandikan konten tersebut.

Salah satu hal yang menurut saya paling menarik dari Log4j adalah kami melihatnya di pipa logging. Jadi, bahkan jika Anda berpikir bahwa aplikasi Anda cukup firewall sehingga tidak akan menerima koneksi dari dunia luar, jika Anda menarik peristiwa log yang memiliki karakter ini di dalamnya, itu akan tetap berjalan dan membuat permintaan itu keluar. Jadi firewall sederhana tidak cukup.

Edge penting di sini dan sangat membantu karena memungkinkan Anda memiliki cara yang cepat dan mudah untuk memulai kontrol terlepas dari apakah Anda yakin apakah Anda rentan atau tidak. Tidak ada kerugian untuk menerapkan kontrol, yang merupakan alasan lain mengapa kami meluncurkannya bahkan untuk pelanggan gratis kami. Jadi titik kontrol tunggal sebenarnya sangat membantu dalam skenario itu.

PAVAN TIRUPATI: Dan apa saja alat atau teknik yang tersedia bagi pelanggan untuk menskalakan lalu lintas dalam skenario ini?

SERGI ISASI: Tentu, jadi untuk skenario apa pun, kami memiliki pekerja di Cloudflare. Ini memungkinkan Anda untuk menjalankan kode Anda di tepi kami dan Anda dapat membangun apa pun yang Anda inginkan dan tidak perlu khawatir tentang penskalaan secara horizontal.

Kami juga memperkenalkan sebuah produk, di awal tahun 2021, bernama Waiting Room. Ruang tunggu adalah sesuatu yang mungkin Anda kenal. Anda pergi untuk membeli sesuatu, dan Anda dimasukkan ke dalam antrian untuk memutuskan apakah barang itu cukup untuk dibeli. Ini juga dapat berfungsi untuk aplikasi. Bisakah Anda terhubung ke situs dan memiliki pengalaman yang baik? Atau Anda harus menunggu?

Ini sebenarnya adalah produk yang sangat menarik yang kami buat. Kami membangunnya di edge dan menggunakan pekerja Cloudflare. Dan itu sulit. Ini mungkin produk yang lebih sederhana untuk dibangun pada intinya. Itu bukan DNA Cloudflare. Kami dapat membuat berbagai hal dengan cepat, dan kami benar-benar melihat penskalaan. Jika Anda mencoba menskalakan sesuatu pada intinya, itu menjadi jauh lebih sulit.

Masalah besar yang kami hadapi saat membangun ruang tunggu adalah kondisi berbagi. Jadi, Anda ingin pengguna memiliki satu pengalaman ruang tunggu, secara global. Dan kami berbicara tentang lebih dari 200 lokasi. Itu tidak mudah.

Jadi saya akan memberi Anda sebuah contoh. Katakanlah ada konser di sini di Bay Area. Sebagian besar pembeli untuk konser itu akan berada di Bay Area, dan kemungkinan besar mereka akan terhubung ke pusat data San Jose kami. Namun, beberapa tidak. Anda akan memiliki segelintir atau beberapa persentase pembeli di seluruh dunia yang terbang untuk konser atau mungkin sedang bepergian pada waktu itu.

Jadi bagaimana Anda membuatnya adil? Anda tidak dapat memiliki antrean untuk pengguna di Bay Area dan antrean untuk pengguna ada di setiap lokasi lainnya. Itu mengharuskan kami untuk berpikir bagaimana kami dapat berbagi keadaan di seluruh penjuru. Dan saya pikir di sinilah masa depan akan semakin maju.

Dan kami menggunakan produk Durable Objects kami sendiri– Anda dapat melihatnya di sini di slide– untuk menyinkronkan dan berbagi status di semua lokasi. Tetapi karena kami, sebagai sebuah industri, ingin memecahkan lebih banyak masalah ini di edge, saya pikir Anda akan mulai melihat lebih banyak kasus penggunaan perangkat lunak di edge di mana status berbagi masih sulit, dan apa yang Anda lakukan tentang konsistensi, apakah itu akhirnya atau langsung? Dan saya pikir itulah masa depan perangkat lunak kami.

PAVAN TIRUPATI: Bagus. Terima kasih, Sergi. Saya tahu, di WP Engine, kami memiliki mentalitas terdepan untuk memastikan bahwa kami memberikan kinerja dan keamanan kepada pelanggan kami. Sergi, apa pemikiran terakhir atau kata-kata nasihat atau pertimbangan atau saran utama Anda untuk para pengembang panggilan yang sedang membangun?

SERGI ISASI: Jadi menurut saya, pertama-tama, Anda membangun di tempat yang tepat. Dan kedua, saya pikir itu untuk menjadi kreatif. Ada banyak hal yang jika Anda bertanya kepada saya, setahun yang lalu, apakah kami dapat melakukannya di ujung tanduk, saya akan menjawab, eh, saya tidak tahu. Saya kira tidak demikian. Dan ada kecepatan inovasi yang lebih cepat yang Anda temukan di sini dan banyak pengembang kreatif yang memikirkan masalah yang Anda pikirkan dan memberikan solusi baik di sisi pelanggan maupun produk.

Hal lain yang menarik adalah jenis berkomunikasi dan berbagi. Kami telah melihat banyak gerakan, terutama di pengembang Discords, menemukan cara baru dan kreatif untuk memecahkan masalah dan membuat lebih banyak hal di edge. Saya pikir, terakhir, sebagai plug untuk Cloudflare, jika ada sesuatu yang tidak dapat Anda lakukan, carilah manajer produk Cloudflare. Kirimi kami email, temukan kami di Twitter, atau apa pun, dan beri tahu kami apa yang ingin Anda buat dan kami akan melihat apakah kami tidak dapat membantu Anda membuatnya.

PAVAN TIRUPATI: Luar biasa. Dan menurut saya wajar untuk mengatakan bahwa edge bukan lagi kasus edge, karena jika keamanan dan performa adalah fokus Anda, maka edge adalah tempatnya.

Jadi terima kasih, Sergi, atas kata-kata hebat tentang edge. Saya harap kalian menemukan sesi ini bermanfaat. Terima kasih telah meluangkan waktu dan bergabung dengan kami. Saya harap Anda memiliki istirahat yang baik hari ini.

PRESENTER: Dan itu adalah penutup untuk DE{CODE} 2022. Saya harap Anda menemukan inspirasi dan pergi dengan lebih banyak keahlian WordPress dan koneksi komunitas baru. Carilah konten yang direkam di situs mulai hari Jumat untuk mengetahui apa pun yang mungkin Anda lewatkan atau menonton video lagi.

Saya ingin mengucapkan terima kasih terakhir kepada mitra sponsor kami– Amsive Digital, Box UK, Candyspace, Draw, Elementary Digital, Illustrate Digital, Kanopi Studios, Springbox, Studio Malt, StrategiQ, WebDev Studios, dan 10Up. Terima kasih banyak atas donasi untuk penggalangan dana DECODE kami. Kami sangat menghargai kemurahan hati Anda.

Sekarang untuk semua orang yang telah berinteraksi dengan kami di Attendee Hub dan sesi kami, kami akan memilih tiga pemenang teratas dan memberi tahu Anda cara mengklaim hadiah di akhir DE{COD}E. Kami berharap dapat bertemu Anda lagi adalah acara kami di masa mendatang, baik secara langsung maupun secara virtual. Kami tidak sabar untuk memberi Anda lebih banyak tentang tren pengembangan WordPress terbaru dan bagaimana Anda dapat menerapkannya untuk membangun situs WordPress lebih cepat. Sekian dari saya. Terima kasih banyak telah bergabung dengan kami dan berhati-hatilah.