2023'te Güvenliğin Zirvesinde Nasıl Kalınır?

Yayınlanan: 2023-04-09

Güvenlik ve performans, geliştirdiğiniz her proje, site, uygulama ve bileşenin mihenk taşıdır. Ancak bu sürekli değişen ortamda, yenilik yaparken aynı zamanda temel en iyi uygulamaların zirvesinde kalmak zor olabilir.

Bu sohbette, 2023'te güvenlik ve performansı nasıl zirvede tuttuklarını en iyi teknoloji uzmanlarından dinleyin.

Video: 2023'te güvenliğin zirvesinde nasıl kalınır?

Konuşmacılar:

  • Ramadass Prabhakar, Kıdemli Başkan Yardımcısı ve WP Engine'de Baş Teknoloji Sorumlusu
  • Lawrence Edmondson, Barbarian'da CTO
  • Sergi Isasi, Üründen Sorumlu Başkan Yardımcısı, Cloudflare Uygulama Performansı
  • Tim Nash, timnash.co.uk adresinde WordPress Güvenlik Danışmanı
  • Jimmy Squires, space150'de CTO

Deşifre metni:

RAMADASS: Herkese merhaba. Decode'un dördüncü baskısına hoş geldiniz. Her yıl katılımcı sayısındaki artışı görmek harika oldu. Son birkaç yılda, sektör genelinde güvenlik manzarasında önemli bir değişiklik oldu. Güvenlik ihlalleri ve güvenlikle ilgili düzenli haber bültenleri gördük, çünkü hem müşteriler hem de geliştiriciler arasındaki tartışmalarda sık sık gündeme gelen bir konu. Bu nedenle bugün, güvenlik konusunda tutkulu olan ve sorularımızı yanıtlamak ve öğrendiklerini bizimle paylaşmak için burada olan muhteşem bir endüstri uzmanları grubunu bir araya getirdik. Panelistlerimize kısa bir giriş yaparak başlayalım. Lawrence, sana kalmış.

LAWRENCE EDMONDSON: Bizi ağırladığınız için çok teşekkür ederiz. Lawrence Edmondson, Barbarian'ın CTO'su. Barbarian tam hizmet veren bir dijital ajanstır. New York'ta bulunuyoruz.

RAMADASS: Teşekkürler, Lawrence. Sana kalmış, Sergi.

SERGI ISASI: Teşekkürler. Cloudflare'de üründen sorumlu Başkan Yardımcısıyım. Cloudflare olarak, WPE gibi müşterilerimiz ve iş ortaklarımızın internete daha güvenli ve daha hızlı bağlanmasını sağlayan ürünler geliştiriyoruz ve ben San Francisco'dayım.

MODERATÖR: Teşekkürler, Sergi. Ve Tim, size kalmış.

TIM NASH: Burada, Birleşik Krallık'ta bir WordPress güvenlik danışmanıyım. Ve temelde hayatımı geliştiricileri korkutmakla geçiriyorum.

MODERATÖR: Teşekkürler. Ve Jimmy.

JIMMY SQUIRES: Evet, teşekkürler. Ayrıca Minneapolis dışında bir tam hizmet dijital ajansı ve orada CTO olan Space 150 ile birlikteyim.

MODERATÖR: Bugün panelimizde olmayı kabul ettiğiniz için teşekkür ederiz. Bu nedenle, bugün kendi kuruluşunuzda veya ekiplerinizde güvenlik alanında yaptığınız benzersiz bir şey hakkında konuşarak başlamak istiyorum. Öyleyse belki de Sergi ile başlayalım.

SERGI ISASI: Evet, Tim'in geliştiricileri korkuttuğu girişiyle oynayacağım. Cloudflare'da daha çok yapmaya çalıştığımız şeylerden biri, müşterilerimize trafikleri hakkında daha fazla fikir vermek ve operasyonel yükü azaltmaktır. Tarihsel olarak, ağınızı neyin etkileyebileceğini, hangi saldırıları görebileceğinizi bulmak istiyorsanız, bir WAF yerleştirir, onu günlük moduna alır ve ardından bir güvenlik analistinin günlüklere bakmasını sağlarsınız ve ne tespit ettiğini görün. Ve bugünlerde bunu yapmak için çok daha az kaynak var.

Bu nedenle, bu yılki odak noktamız, bugün bu saldırıyı önleyecek ürünü kullanmıyor olsalar bile, üzerlerinde gördüğümüz saldırılar hakkında müşterilerimize fikir vermektir. Böylece uygulamalarının saldırı altında olup olmadığını veya genel olarak iyi durumda olup olmadığını anlayabilirler. Yılın geri kalanında odak noktamız da bu, tüm güvenlik ürünlerimizi tanıtıyoruz ve müşterilerimize ağlarında neler olup bittiğini veya gerçekte neler olup bittiğini ve bunu engellemek isteyip istemediklerini bilmelerini sağlıyoruz.

MODERATÖR: Harika. Kulağa gerçekten güçlü geliyor. Bunun hakkında daha fazlasını duymayı dört gözle bekliyorum. Tim, peki ya sen?

TIM NASH: Bu yüzden, hem ajanslar hem de daha küçük bireysel web siteleri olmak üzere birçok farklı müşteriyle çalışıyorum. Ve çok sayıda kod incelemesi ve site incelemesi yapıyorum. Ve bu yıla kadar, gerçekten önemseyen insanlarda büyümeyi o kadar görmedim ki, insanlar bir inceleme almaktan ve sadece yapmalarını söylediğin işi yapmaktan oldukça mutlular. Bu nedenle, onlara bir dizi tavsiye verirseniz, sadece takip ederler. Ama gelecek yıl siteye geri dönersem, onlara bir dizi tavsiye daha vermiş olurum. Bu yüzden, bu son yılda insanların soru soracak kadar gerçekten önemsediği bir değişim gördüm. Ve benim için, kod denetimleri bu dosyanın 6, 4, 2 numaralı büyük, uzun satırında atıldı, filan, bu şekilde yapılması gerekiyor.

Bunların hepsinden kurtuldum ve gerçekten eğitime odaklanmaya başladım ve dürüst olmak gerekirse çoğu insanın istediğinin söylenmek olmadığını fark ettim, bu çizgiyi düzeltmelisiniz ama anlatılmak için işte nasıl düzeltileceği oradaki her çizgi. Bu yüzden benim için büyük değişiklik ve büyük odak değişikliği eğitime yönelik oldu. Ve bu sektör genelinde olan bir şey. Bence bu yıl geçen yıldan ve önceki yıllardan daha fazla güvenlik hakkında konuşan daha fazla insan var.

MODERATÖR: Hayır, bu harika. Size balığı vermekten balığı nasıl yakalayacağınızı öğretmeye odaklanmayı gerçekten seviyorum. Yani bu gerçekten-

TIM NASH: Klişe olduğu için ne pahasına olursa olsun bu benzetmeden kaçınmaya çalışıyordum.

MODERATÖR: Teşekkürler.

TIM NASH: aferin.

MODERATÖR: Peki, Jimmy.

JIMMY SQUIRES: Evet, bence o kadar çok şey var ki, bu cevapla ilgili konuşmak için gerçekten belirli bir şeye odaklanmaya karar verdim. API belirteçleri ve erişimle uğraşırken bu, kapsamınızı gerçekten kısıtlıyor. Bence geçen yılki Heroku, GitHub deposu ihlali, yalnızca pek çok şeyin kontrolünün sizde olduğunu hatırlatan gerçekten iyi bir şeydi. Bu nedenle, geliştiricilerimizle çalışırken, hangi platform veya sistemde çalışıyor olursanız olun, bu kapsamlı erişim politikasının önemini onlara hatırlatıyoruz. Çoğu zaman bir geliştirici, yalnızca kolaylık sağlamak için geliştirmenin başlarında gerçekten oldukça geniş açık erişim ister. Ve bazen, hepimizin muhtemelen itiraf etmekten utandığı şeyler, üretimden önce olması gereken seviyeye indirilmez. Bu nedenle, bu güvenlik kapsamlarını gerçekten göz önünde bulundurarak erken başlamak.

MODERATÖR: Teşekkürler Jimmy. Ve Lawrence, geliştiricilerle de çok çalıştığını biliyorum. Öyleyse hepiniz o cephede bunun için ne arıyorsunuz?

LAWRENCE EDMONDSON: Evet, tabii. Sırf Jimmy'nin söylediklerini temel almak için, elbette ikimiz de reklamcılıkta çalışıyoruz. Bu nedenle, bir ürün ortamında çalışmakla reklamcılıkta çalıştığınızda aynı zorlukların çoğunu gördüğümüzü düşünüyorum. Bizim için birçok farklı teknolojiye, birçok farklı teknoloji yığınına dokunuyoruz. Teknik olarak agnostik olmalıyız. Gördüğümüz şey şu ki, tüketiciler artık mobil ve sosyal aracılığıyla birden fazla şekilde etkileşim kuruyor. Birkaç yıl önce masaüstü, sitelere ve içeriğe erişmenin birincil yoluydu. Şimdi tamamen tersine döndü. Masaüstünden mobile geçti ve şimdi sosyal.

Bu nedenle, API katmanlarınız ve uygulama katmanlarınız, kendileriyle ilişkili bir parça sağlıklı paranoya içeren şekillerde kilitlenmelidir. Dolayısıyla, saldırı yelpazesinin büyüdüğünü görüyoruz, bu nedenle DevOps'u programcılar gibi düşünmeye ikna etmenin yeni yollarını arıyoruz, böylece ihlal edilebilecek şeylerin olası yollarını anlıyorlar. Demek bugün yaptığımız şey bu.

MODERATÖR: Bunun için teşekkür ederim. Ve saldırı vektörünün nasıl arttığından bahsettiniz. Ve bu, burada, WP Engine'de sahip olduğumuz bir şeydir, derinlemesine bir savunma mekanizmasını nasıl benimsersiniz'den daha fazla bakıyoruz. Bu nedenle, herhangi bir katmanın güvenli olduğuna güvenmeyin. Peki bunu kodlama ve yazılım yazma şeklinize nasıl dahil edersiniz? Bunun için teşekkür ederim. Hepiniz orada meydana gelen değişen trendden bahsettiğiniz gibi, geçen yıl meydana gelen ihlaller. 2023'e baktığınızda, hepinizin dikkat ettiği bazı ana temalar veya tehditler nelerdir? Ve belki Sergi, bizi başlatabilirsin. Evet.

SERGI ISASI: Tabii. Ve bu kulağa aptalca gelecek çünkü yıl 2023 ve ben DDOS kelimesini söyleyeceğim ama bu yine de bir şey. Ve DDOS dünyasında son dokuz, 12 ayda gerçekten ilginç bir değişim oldu. Hacimsel, bugünlerde gerçekten bir DDOS vektörü değil. Çok daha az yansıma var. Ve bir tehdit aktörünün bakış açısına göre, bir DDOS başlatmak daha kolaydır çünkü çok sayıda kullanıma hazır aracınız vardır, değil mi? Neredeyse komut dosyası TD günlerine geri döndük, ancak ayrıca saldıracak çok daha az güvenliği ihlal edilmiş sisteminiz var. Dolayısıyla, yansıtma yapmaya çalışıyorsanız, sistemlerini düzeltmemiş olabilecek biri tarafından yönetilen çok fazla altyapı yoktur, bu nedenle bir paket alıp 10'a çevirebilirsiniz. Bu artık pek önemli bir şey değil.

Yani 7. katmana geçiyorlar. Ve 7. katmanı başlatmak hem daha pahalı, hem de bunu yapmak için çok fazla CPU'ya ihtiyacınız var, ama aynı zamanda hafifletmek de çok daha pahalı. Bu nedenle, bir tür DDOS koruma sisteminiz varsa, aslında bağlantıyı kabul etmeniz, incelemeniz ve ardından onu daha düşük bir katmana bırakabileceğiniz bir şeye karşı bırakmaya başlamanız gerekir. Bulduklarımız ve geçen ay kaydedilen en büyük Layer 7 DDOS'unu hafiflettik. Bu saldırılardaki büyük tema, daha güçlü cihazlardır.

Dolayısıyla, bugünlerde evde fişe taktığımız tüm şeyleri düşünürseniz, o cihazdaki işlemci üç veya dört yıl öncesine göre çok daha iyi. Böylece kameranız çok daha fazlasını yapar. Yani üzerinde daha güçlü bir CPU var, yönlendiricileriniz bile aslında oldukça güçlü bir makine. Ve bu cihazlardan herhangi bir ödün verilmesi büyük, büyük bir saldırıya izin verebilir, özellikle de bir tanesini tehlikeye atarsanız, artık temelde bağlı olan tüm cihazları tehlikeye atmış olursunuz.

Bugünlerde biraz konuştuğumuz, ancak biraz daha sessiz olan diğer bir şey ise, güvenliği ihlal edilmiş donanım cihazlarından bulut hizmetlerinde güvenliği ihlal edilmiş hesaplara geçtik. Bulut hizmetleri etkin bir şekilde sınırsız CPU'ya sahiptir. Dolayısıyla, birkaç kişinin veya şirketin hesabına erişebilir ve o bulut sisteminde istediğimi çalıştırabilirsem, o zaman son derece büyük bir saldırı başlatabilirim. Rekor kıran saldırılarda gördüğümüz de bu. Yani evet, 2023, hala DDOS, hala bir şey, ama şimdi alt katmanlara karşı 7. katmanda.

MODERATÖR: Teşekkürler. Bu korkutucu ama aynı zamanda güvenlik protokollerimizi geliştirmeye nasıl devam edeceğimize de işaret ediyor ve odak alanı büyümeye devam ediyor. Biliyorum Lawrence, sen ve ben geçmişte yapay zeka hakkında hem bir patlama hem de bir tehdit olarak konuşmuştuk. Üretken yapay zeka hakkındaki düşüncelerinizi ve bunun 2023'te güvenliğin yüzey alanını gerçekten nasıl etkilediğini görmeyi çok isterim.

LAWRENCE EDMONDSON: Bu yüzden çok heyecanlıyım, yapay zeka konusunda çok iyimserim. Barbarian'dayız ama aynı zamanda çok korkutucu. ChatGPT gibi bir şeyin kötü amaçlarla kullanılma potansiyeli. Örneğin, Chat GPT'nin kodunuza yorum yapmasını sağlayabilirsiniz. Ve aslında oldukça iyi bir iş çıkarıyor, hangi dilde ve kodunuzun ne kadar dağınık olduğuna bağlı olarak oldukça iyi bir iş çıkarıyor. Sanırım göreceğimiz bir sonraki şey, Chat GPT için - ve bu zaten başlamış olabilir çünkü her gün, örneğin, Chat GPT bunu yapıyor. Bugün olduğu gibi, Slack'te yanıt verebildiğini ve yanıtları Slack'te bulabildiğini gördüm.

Bu yüzden, güvenlik açısından Chat GPT'deki bir sonraki şeyin, Chat GPT'nin istismarları bulmasını sağlamak ve bulduğu zayıflıklardan gerçekten faydalanmak için kötü amaçlı koda gerçekten kod yazmasını sağlamak olduğunu düşünüyorum. Yani bunu görüyoruz, özellikle bunun hafızadaki potansiyeli. Yani hafıza saldırıları her zaman bir imza bırakmaz. Geleneksel virüsler ve virüs tarayıcıları, bir saldırının imzalarını aramak için çalışırlar. Bellek saldırılarında, uygulamaya saldırıyorsunuz. Tampon taşması gibi bir şey yapıyorsun. Uygulamayı çalışma zamanında tehlikeye atmak istiyorsunuz. Chat GPT'nin aslında bunu yapmaya hazır olduğunu düşünüyorum. Ve bence ilk büyük ölçekli ChatGPT istismarının gerçekleştiğini görmemiz an meselesi.

TIM NASH: Bunun gerçekten olmasını nasıl tasavvur edersin? Çünkü ChatGPT'nin özünde, bir sunucuya yönelik bir dizi API isteği olduğu açıktır. Ve hey, bana bazı kötü niyetli kodlar üret diyen bir talep gönderiyorsunuz. Geri iade ediyor. Demek istediğim, zaten kötü amaçlı kod üreten birçok insan var. O zaman bunun zaten var olan kötü amaçlı koddan daha kötü olmasını nasıl sağlarsınız?

LAWRENCE EDMONDSON: Yani tam olarak bu. Halihazırda öğrenilecek büyük bir havuz var. Yani ChatGPT, aslında ne yaptığına bakar – modeli eğitmeniz gerekir. Bu nedenle, zamanla mühendisler modeli, birisi bunu söylediğinde aslında kastettiklerinin bu olduğunu anlayacak şekilde eğitirler. Yani bağlamı anlayın. Yani tam olarak öyle, ama farklı bir şekilde. Modeli gerçekten kod yazması ve gerçekte ne anlama geldiği konusunda eğitiyor. Ve bazı diller çok kolaydır. Yani PHP, PHP'de kod yazmak oldukça kolay. Bu yorumlanmış diller çok daha kolaydır. Çok daha karışık, ama Java gibi derlenmesi gereken bir şey yapmak yerine, ne demek istediğimi anlıyor musunuz?

Bu yüzden bence bunu yapmanın kolay bir yolu, chatGPT 3'e dayalı bir model oluşturmak olacaktır, aslında onu eğitiyorsunuz – sözdizimi işlerinden geçiyorsunuz, tüm temel bilgisayar bilimi şeylerinden geçiyorsunuz ve sonra onu alıyorsunuz. bir adım yukarı ve git, tamam, bu NPM paketlerinde bu istismarlar var. Onu arayın ve gerçekten bir yol bulun – bu güvenlik açıkları var, üzgünüm ve bu güvenlik açıklarından yararlanmanın bir yolunu arayın. Garanti ederim, böyle bir şeyin olduğunu görmekten çok uzakta değiliz.

MODERATÖR: Teşekkürler Lawrence. Bence çok gelişmekte olan bir alan. Bu alanda ilginç olan şey, AI ile ilgili olarak, genel olarak, hem onu ​​ne için kullanabileceğiniz konusunda bir dengeye sahip olması, hem de bu imzaları onu önlemek için gerçekten kullanmak ve bizi nasıl önleyebileceğinizi görmek için ondan öğrenmek olsun. zayıf kod veya savunmasız kod yazmak. Ve aynı zamanda, tıpkı insanların hakkında konuştuğunu gördüğümüz gibi, hey, ilk eklentimi Chat GPT ile beş dakikada yazdım, bence evet, bu daha çok insanların kötü amaçlı yazılım oluşturmasını sağlamaya mı başlıyor? Daha hızlı? Ama bence her iki yönü de var.

Daha çok, kod yazmada daha iyi olmak ve daha güvenli kod yazmak için bu araçlardan herhangi birini kullanmaya nasıl devam edeceğiniz hakkında. Ve biliyorum Tim, bu senin için bir tutku alanı. Secure Code'un 2023'te nasıl geliştiğini gördüğünüz ve bu alanda ne yaptığınız hakkında biraz daha konuşmak ister misiniz?

TIM NASH: Demek istediğim, birçok yönden Chat GPT buna iyi bir örnek. Bir saldırı vektörü düşünüyorsam, dürüst olacağım, toplu tarama yapmasını, kötü bir oyuncu olarak pek çok şeyi beslemesini düşünmüyordum. Bunu, zamandan tasarruf etmeye çalışan ve Chat GPT'ye bir şeyler besleyen ve onu atan ve yazılan, üretilmekte olan, herhangi bir test yazmamış olan tüm kodu tam olarak anlamayan ortalama bir kod geliştirici olarak düşünüyordum. onunla git Bu sadece hızlı bir şey, sadece hızlı bir komut dosyası, her şey yolunda. Üretime giriyor, iyi değil ve hepsi yanıyor.

Şimdi bu, ne olursa olsun her geliştiricinin her gün yaptığı bir şeyle tamamen aynı. Chat GPT bunu değiştirmiyor ama biraz daha kolay etkinleştiriyor. Veriyor - daha az engel var.

SERGI ISASI: Evet, yani Yığın Taşması gibi kopyalayıp yapıştırmakla pek aynı şey değil, sanırım bahsettiğin şey bu, Tim, temelde kod için yaptığım tek şey bu. Ama hem olumlu hem de olumsuz olarak kesinlikle verimlilik artışı olduğunu düşünüyorum. Ancak, daha ince değişikliklere ve daha çok imza tabanlı motorun gerçekten yetişemeyeceği bir şeyin daha hızlı kullanılmasına izin verdiğini düşünüyorum. Yani, gerçekten algılama yaparken, geçmişte gördüğüm bir şeyle doğrudan eşleştirmenin aksine, bu geçmişte gördüğüm bir şeye benziyor mu diyen bir sisteme ihtiyacınız var. Ve bu aslında algılama tarafında da muhtemelen en iyi şekilde ML veya AI veya buna ne demek istiyorsanız, hizmet eder.

Otomatik trafiğin temelde botlarda olduğunu öğrendik. İmza tabanlı algılamayı nasıl atlattıklarını öğrenmenin en iyi yolu makine öğrenimidir. Ama şimdi, bunun kötü olduğunu kesinlikle biliyorum'dan, muhtemelen otomatik olacak veya muhtemelen daha önce gördüğüm bir imza gibi görünecek, ancak tam olarak eşleşmeyecek'e geçiyorsunuz.

MODERATÖR: Harika. Teşekkür ederim. Eklenen bağlam için teşekkürler, Sergi ve Tim. Bu nedenle, katılımcılarımız arasında bugün burada bulunan birçok geliştirici ve ajansımız var. Ve pek çok kişi, özellikle tehdit vektörleri açısından senaryolar değişirken en iyi uygulamaları oluşturmayı düşünüyor. Peki, bir site, uygulama veya platform oluştururken ya da yeni bir projeye başlarken tavsiye edebileceğiniz bazı en iyi uygulamalar nelerdir? Peki insanların dikkat etmesi gereken bazı şeyler nelerdir?

SERGI ISASI: Yani buna başlayabilirim. Operasyonel tarafta, geliştirme tarafından daha fazla olacaktır. Sanırım burada vaaz ettiğimiz şeylerden biri, kötü bir şey olacağını varsaymak. Yani bir gedik geliyor, buna öylece şaşırıp gidemezsin. Bir noktada olması muhtemeldir. Ve anahtarımız - yani, bunun için bir çalıştırma kitabı oluşturun. Dolayısıyla, bu gerçekleştiğinde, hem tespit hem de müdahale yoluyla hangi kişilerle iletişime geçeceğinizi ve yanıtınızın ne olacağını bilin, aynı zamanda müşterilerinizi etkiliyorsa onlarla iletişim kurun. Ve bu noktada, Cloudflare'de çok iyi yaptığımızı düşünüyorum ve bu markamızın bir parçası oldu ve bize çok iyi hizmet ettiğini düşünüyorum, herhangi bir konuda olabileceğiniz kadar açık sözlü, açık ve iletişimsel olmak. o oldu.

Açıklık, ister bir yazılım ihlali isterse bir olay açısından yaptığınız bir hata olsun, bir şey meydana geldiğinde müşterilerle güveni yeniden tesis etmek için çok önemli olmuştur. Bunun arkasına saklanmak asla doğru bir karar değildir.

MODERATÖR: Evet.

JIMMY SQUIRES: Bence başka bir şey daha var - artık herkes açıkça uzakta ve özellikle geliştirme ekiplerinde, aslında bir projenin başlangıcında beyaz tahta ve mimari planlama yapmak için zaman harcıyoruz. Gereksinimlere dalmak ve geliştirme hikayelerini ele almak çok kolay, ancak meslektaşlarınızla zaman geçirmek için meydan okumak, bundan nasıl yararlanılabilir? Senaryoları çalıştırın. Uygulamanın farklı bölümlerini nasıl desteklemek istediğimizle ilgili pek çok iyi sohbete yol açan birçok senaryo planlaması yapıyoruz.

LAWRENCE EDMONDSON: Ve tam da bu konuda, kimsenin bilip bilmediğini bilmiyorum ama MPM aslında paylaşılanların en büyük deposudur – uygulama kitaplıklarının en büyük deposudur, ancak bu aynı zamanda en büyük riski de taşıdığı anlamına gelir. Bu nedenle, NPM kullanıyorsak yeni bir projeyi üstlenirken çok farkında olduğumuz bir şey, güvenlik açıklarına baktığımızdan, üretmeye zorladığımız sürümleri kilitlediğimizden emin olmaktır. Bir güncelleme yapıyoruz, bunun uyumlu ama aynı zamanda çok güvenli bir şey olduğundan emin oluyoruz. Açık tehdit yok, çünkü NPM'de çok sayıda güvenlik açığı gördük. Yani dikkat edilmesi gereken tek şey bu.

TIM NASH: Sanırım her şeyi tekrarlıyoruz.

JIMMY SQUIRES: Devam et Tim.

TIM NASH: Sanırım bunu, yıllardır geliştirme döngülerinde gerçekten güvenin tamamen kırıldığı fikrine çeviriyoruz. İnsanlar şimdi bunun farkına varıyorlar. Ve örneğin WordPress'te çalışan bir PHP geliştiricisiyseniz, orada oturup eylemleri ve filtreleri çağırırsınız, ancak bu eylemlere ve filtrelere güvenmemelisiniz. Gelen herhangi bir veriyi doğrulamalı, kontrol etmelisiniz. Sanitize edilmelidir. Ancak veri tabanından çıktığında, yine de ona güvenmemelisiniz.

Bu verileri veritabanına koymuş olsanız bile, çıkan verilere güvenmemelisiniz. Bir üçüncü taraf kitaplığına bir şey aktarıyorsak, o NPM, o besteci paketi veya başka bir WordPress eklentisi olsun, hemen kontrolümüzden çıkar, ona tekrar güvenmeyiz. Ama geri geldiğinde kontrol etsek bile yine de güvenmiyoruz. Ve bir geliştirici olarak, her bir veri parçasına güvenilmemesi ve sonuna kadar izole edilmesi gerektiği ve verili her noktada güvenlik kontrollerini yapmanız gerektiği zihniyetiyle yola çıkarsanız, ortaya çıkarsınız. çok daha güvenli bir sistemle. Biraz daha yavaş bir sistemle çıkabilirsiniz. Biraz daha sinir bozucu ve yaptığınız şeyin aslında yardımcı olduğundan daha fazla soruna neden olmadığından emin olmak için çok daha fazla test gerektiren bir sistemle karşılaşabilirsiniz.

MODERATÖR: Evet.

TIM NASH: Karmaşıklığı ekleyin, ancak sonunda çok daha güvenli bir sistem elde edersiniz. Ve çoğu insan için istedikleri de bu.

LAWRENCE EDMONDSON: Evet.

MODERATÖR: Evet. Kesinlikle haklısın. Bu, gelen başka hiçbir kod parçasına güvenmemekle ilgili. Ve Jimmy ve Sergi'nin bahsettiği şeye göre, bir plana sahip olmak ve mimari bir bakış açısıyla veya operasyonel bir bakış açısıyla, ancak güvenlik güvenli kodlama mekanizmaları veya bir olay oyun kitabına sahip olmak gibi tüm bunları genel pratiğinizde bir araya getirmek. Bu yüzden Tim, senden daha fazlasını duymakla çok ilgileniyorum – çok fazla eğitim yapıyorsun, dünya çapında çok fazla öğretmenlik yapıyorsun. İnsanlar projeler üzerinde çalışmaya başlarken gördüğünüz yaygın hatalar veya sizin yapmış olabileceğiniz hatalar nelerdir, ben onlardan çok yaptım.

TIM NASH: Söyleyecektim ki, konuşacağım her hatadan oldukça eminim. Ve en büyüğü ve en basiti iyi insan olmaktır. Çoğu geliştirici iyi niyetli olduğunu varsayar. Çoğu kişi, başvurularını, başvurularını nasıl yazdıysanız öyle kullanacağınızı varsayar. Şimdi oldukça sık olarak, belge yazmıyoruz, bu nedenle kullanıcının uygulamayı nasıl kullanacağı hakkında hiçbir fikri yok, ancak bu ayrı bir sorun. Kötü bir oyuncu gelir ve herhangi bir hatayı alır ve gider, bu bir böcek değildir, kötü bir oyuncu için bu bir özelliktir. Bu bir fırsat. Geliştiricinin beklemediği bir şey yapıyor, dolayısıyla buna giden potansiyel bir yol var.

Ve genel olarak, tekrar tekrar gördüğünüz bir şey, "bakın, bir dizi birim testiniz var" dediğinizde. Ah harika. Ama sen sadece olumlu şeyleri, istediğin sonucu test ettin. Bu sınırların dışına çıkarsak ne olacağını test etmediniz. İşlerin patronunuzun istediği gibi çalıştığından emin olmak için az önce test ettiniz. Yani gerçekten sahip olduğunuz şey kabul testleri, şüpheli kabul testleri. Ve sonra tüm temellere geri döner. Bir geliştirici olarak, buna geri döndü, şeylere güvenmeyin. Ve özellikle bir WordPress geliştiricisiyseniz, WordPress aslında insanlardan yapmalarını istediğimiz tüm standart güvenlik şeylerini yapmak için bazı gerçekten iyi yardımcı işlevlere sahiptir.

Ve bu onları kullanmayı öğretmek ve öğrenmekle ilgili. Kod incelemeleri yaparken defalarca aynı sorunları göreceğim. Ve bunu bir kod parçasında bir kez görürsem, aynı kod kümesinde 1.000 kez göreceğim. Ve şöyle şeyler olacak, evet pekala, sayfada herhangi bir eski şeyin görünmesine izin verdik. İçinde bir şey olup olmadığını kontrol etme zahmetine girmedik. Evet, veri tabanına bir şeyler koyduk. Oh bak, bir SQL sorgusu gibi görünebilir, olmayabilir.

Tüm bu tür şeyleri düzeltmesi kolaydır ve düzeltmesi için gereken araçları zaten verdik. Ve bunları düzeltmememizin nedeni genellikle insanların bunların olmasına izin vermemeleri gerektiğini bilmemeleri değil, sadece tembelleşmemiz, işleri hızlı yapmamız, Stack Overflow'tan kod kapmamızdır. Chat GPT'nin bizim için bir şeyler yapmasını sağlıyoruz, her şeyi kontrol etmiyoruz. Ve bu durumdan bir çok güvenlik sorunu çıkıyor, acele etmeliyim. acele etmeliyim Acele etmeliyim, bunu halletmeliyim. Bir sonraki şeye geçiyorum, bir sonraki şeye geçiyorum.

Garip bir şekilde, pek çok geliştirici için, aslında onlara sadece zaman ve alan vererek, ne yaptığınızı gerçekten kontrol etmek için zaman ayırmakta sorun yoktur, böylece işler düştüğünde – ve devreye girdiğim durumlarda, Geri dönüyorum ve diyorum ki, tüm bunlar ve geliştiriciler mahçup görünüyor. Gidiyorlar, evet, bunların hepsini biliyoruz. Sadece zamanımız yoktu.

Bu yüzden umarım, insanlara daha fazla zaman vermek ve aslında onlara, özellikle WordPress'te zaten sahip olduğumuz araçları vermek. WordPress, bir WordPress eklentisinde veya temasında karşılaşabileceğiniz en yaygın güvenlik sorunları için gerçekten mükemmel bir dizi yardımcı işleve sahiptir. Yani mesele sadece bunları öğrenmek ve ardından onları gerçekten uygulamak için zaman harcamakla ilgili.

MODERATÖR: Evet. Ve bence bu gerçekten güçlü, zaman ayırın. Çoğu zaman, geliştiriciler neyin düzeltilmesi gerektiğini bilir. Bu yüzden onlara zaman vermek. Yani gerçekten bu mesajı beğendim. Ve Jimmy, bunu ajansındaki kendi iş akışına taşıdığını biliyorum. Uyguladığınız güvenli iş akışı uygulamalarından biraz daha bahsetmek ister misiniz?

JIMMY SQUIRES: Evet, kesinlikle. Ve gerçekten, Sergi'nin söylediği bir şeye sahip olmak, bir plana sahip olmak, aslında geliştirme ekibinizin takip etmesi için yönergelere ve standartlara sahip olmakla başlar. Kulağa muhtemelen çok basit geldiğini biliyorum, ancak birçok kuruluş gördüm ve yıllar boyunca işe aldığımız birçok mühendisten bunun var olmadığını duydum. Geldikleri iş yerinde örgütlenme yoktu.

Yani yapmaktan hoşlandığımız şey, standart bir dizi yönergemiz var, tüm yeni mühendislerimizin bunu baştan sona okuması gerekiyor. Sarf malzemesi olmayacak kadar ağır değil. Markdown'da tutmayı seviyoruz, bu yüzden hepsi bir depoda. Muhtemelen bir noktada kaynağı açacağız. Orada gerçekten tescilli olan hiçbir şey yok ve o zaman herkesi buna katkıda bulunmaya teşvik ediyoruz. Bunu tüm mühendislere soruyorum.

Bu nedenle, yönergelerimizde bile, ekleyebileceğimiz, daha iyi olabileceğimiz ve bunu sürekli olarak geliştirebileceğimiz noktalarda delikler açın. Ancak bununla zaman geçirmek, OWASP gibi bazı temel şeyler, bu gerçekten eski bir uygulamadır, ancak bunları göz önünde bulundurarak başvurunuzla birlikte gözden geçirmek. Tim'in dediği gibi, gerçekten zaman alıyor ve bununla zaman ayırmakta sorun yok. AI sohbetine bir nokta daha eklemek istedim. Geçen hafta birkaç mühendisimiz ile konuşurken aslında bir olay yaşandı. Bu, aslında birim testi için Chat GPT kullandığımız bir şey. Tim'e göre, bir işlevi alıp onu ilginç şekillerde keşfederek, o birim testinin en iyi yazarı olmayacağınız bir birim testi yazmak için Chat GPT gibi bir şeyden nasıl yararlanabilirsiniz? Önleyici bir şekilde AI'dan çok daha fazla yararlanabileceğimiz yeri düşündüğüm yer burasıdır.

LAWRENCE EDMONDSON: Evet. Bizim tarafımızda yaptığımız şey, bence kontrol listeleri ve bir oyun kitabına sahip olmak harika. SonarQube gibi otomatik araçlar kullanıyoruz ve sadece astarlama ile kodun kalitesini yükseltmek için gerçekten yerinde astarlama ve bunun gibi şeyler yapıyoruz, ama aynı zamanda kodun daha güvenli olduğundan emin olmak için SonarQube kullanıyoruz. güvenlik açıkları ve bunun gibi şeyler için. Daha önce de belirttiğim gibi, sadece dilin doğası gereği, bazı dillerde istismar bulmanın diğerlerinden daha kolay olduğunu düşünüyorum. Ve ayrıca, bu kod tabanına katkıda bulunan kodlayıcıların kalitesinin tipik olarak olduğu belirli çerçeveler - bunu genellikle Açık Kaynak'ta görüyoruz, burada tıpkı şöyle - gerçekten çalışmış insanlara kıyasla çok sayıda Yığın Taşması kopyalama ve yapıştırma işlemi oluyor. CS ve ne yaptıklarını gerçekten biliyorlar. Yani bu gördüğüm şeylerden sadece biri.

TIM NASH: Hemen hemen her gün Stack OverFlow kullandığımı kesinlikle kendim adına belirtmemiz gerektiğini düşünüyorum. Ve bu yüzden hepimiz suçluyuz. Üzerine sövüp saymak güzel, ama sanmıyorum– yani, kodlamaya ilk başladığım zamanı hatırlıyorum. Bir dergi aldım ve dergiden kod yazıp Enter'a basıyordum. Hala bunu yapmaya devam edersek ve Yığın Taşması veya benzeri bir şeye sahip olmasaydık, web'in bugün gerçekten çalıştığını hayal edemiyorum.

Sergi: Hayır, hızlandırıcı. Ve umarım yapay zeka bunun bir sonraki aşamasıdır. Ama evet, eğlenceli bir meme.

MODERATÖR: Teşekkürler. Yani biraz değişiyor. Sektörde Headless ve Headless uygulamaları çevresinde meydana gelen çok fazla ivme var. Ayrıca bugün diğer kanallarımızdan bazılarında veya diğer oturumlarda Headless'tan bahsettiğini gördük. Dolayısıyla, WP Engine'de Atlas ile çalışmaya başladığımızda, birçok geliştiriciyle tanıştık ve güvenlik her zaman temel motivasyon kaynağı oldu. Peki, Headless ile güvenliği nasıl görüyorsunuz? Ve biliyorum Jimmy, bu, etrafında bazı projeler yaptığın bir alan. Bu konudaki fikrinizi almak isteriz.

JIMMY SQUIRES: Evet, Headless'ta çok iş yapıyoruz. Bence bu noktada neredeyse tüm projelerimiz muhtemelen Başsız mimari yaklaşımını benimsiyor. Güvenlikle ilgili olduğu için sadece birkaç noktaya değinmek istiyorum. Bence ilki, bir Headless mimarisini seçtiğinizde, genellikle başlangıçta kendinizi daha çok açık kaynak kampına koyuyorsunuz. Ve tabii ki neyin daha güvenli olduğu, açık kaynak mı yoksa kapalı kaynak mı olduğu konusunda pek çok tartışma var. Doğası gereği daha güvenli olan OSS projeleri kampına girme eğilimindeyim. Yani, dev bir topluluğa sahip olduğunuz Next, WordPress gibi çerçeveleri seçiyorsunuz. Ve bu, sadece maruz kalma yoluyla kendisini daha fazla güvenliğe ödünç verme eğilimindedir.

Bence bu bir. Bence ikincisi Statik Üretim gibi bir şey. Yani inşa edilen birçok web sitesi ve ürün, büyük bir içerik yönetiminin dinamik doğasına, geleneksel anlamda yekpare bir sisteme ihtiyacınız yok. Cloudflare gibi bir şeyden yararlanabilir ve bu uygulamanın büyük bölümlerini gerçekten statik olarak oluşturarak vektörler ve maruz kalma için ayak izinizi azaltabilirsiniz. Yani biz bunun büyük hayranlarıyız. Ve sonra, elbette, bununla birlikte tüm performans avantajlarını da elde edersiniz. Bunlar, Headless mimarisi hakkında belirtmek istediğim birkaç nokta. Ancak güvenlik açısından sevdiğimiz daha birçok neden var. Ama bence bunlar muhtemelen en göze çarpan alanlardan ikisi.

TIM NASH: Bir tür geri dönüş yapmak ve insanlara arka tarafta hala bir içerik yönetim sistemi olduğunu hatırlatmak istiyorum. Ve Headless'ın tamamen güvenli olduğunu çok sık duyuyorum. Sanki, evet, ancak doğrudan web sitesinden aramadığınız için hala orada duran açıkta kalan WordPress örneği, evet, hala admin.yoursite.com'da. Ve siz – ah evet, pekala, artık güvendeyiz, bu yüzden onu güncel tutma konusunda endişelenmemize gerek yok çünkü bu web sitesi değil. Sanki, hayır, hayır, daha önce yaptığınız her şeye hala ihtiyacınız var ve şimdi diğer tarafımız da var.

Demek istediğim, Başsız, uzun süredir var olan ve çok ivme kazanan bir şey için harika bir terimdir, ancak bunu WordPress'in bir REST API'si olmadan önce yapıyorduk. En azından statik bir site elde etmek için içeriği WordPress'ten Jekyll gibi şeylere aktarıyorduk. Ve bunu yapmanın asıl nedeni, WordPress sistemini veya içerik yönetim sisteminizi ağınızın içinde değiştirmekti. Böylece onu kilitleyebilir ve büyük, korkutucu ağdan uzak tutabilirsiniz.

Artık Headless çözümleri sunan çok sayıda barındırma şirketi alıyoruz. And that infrastructure is now out in the cloud again. So we've sort of moved the big benefit for Headless. And we're slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it's the only move for widespread adoption. So there's a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can't just rely on it being–

TIM NASH: Just because something's got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn't mean that everything is secure. It means that you have a different paradigm. And that's what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that's you're very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What's your recommendation?

LAWRENCE EDMONDSON: I guess I'll start off. My recommendation would be very simple. Security should be everyone's business. I think a lot of times, security doesn't become a topic or consideration until there's a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It's 2023, we shouldn't be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it's something that's not easily compromised. But that's what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what's exposed. Know what's on the internet and make sure that the proper– at least aware of what's there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi's point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. Teşekkür ederim. And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody's responsibility. Give people the time and space to actually do their jobs properly and you'll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone's responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. Thank you and bye.