Detectify under the Hood blog serimizin bir parçası olarak, kısa süre önce yeni motor çerçevemizi ve bunun 0 günlük kritik bir güvenlik açığını bir gün içinde gidermemize nasıl yardımcı olduğunu tanıttık. Bu yazıda problem uzayını derinlemesine inceliyoruz. izleme Müşterilerimizin saldırı yüzeyini oluşturmak ve onlara güvenlik testleri dağıtmak.
İzleme
Detectify olarak izlemenin problem alanını, müşterilerimiz üzerinde uygun güvenlik testlerinin makul bir sıklıkta gerçekleştirilerek doğru verilerin güncel tutulması süreci olarak tanımlıyoruz. Bu birkaç alt kategoriye ayrılabilir. İlk olarak izleme, izleme adını verdiğimiz şeyin tasarlanmasını içerir. monitörlerBunların tamamı hangi testlerin hangi sıklıkta çalıştırılacağını yakalamakla ilgilidir. İkincisi, elimizde dağıtımı izlemekişleri planlamak (çalıştırılacak test grupları) ve bir iş kuyruğu oluşturmak için kullanılır. Son olarak, şu var gözlemlenebilirlik Performansın beklentileri karşıladığını garanti etmek için.
Monitör Tasarımı
Monitörleri tasarlarken çalıştırmak istediğimiz test setlerini ve bunların temposunu tanımlarız. Tüm testler eşit derecede önemli değildir ve ilgilerine bağlı olarak farklı kadanslarda farklı testler planlayabiliriz. Bu, müşterilerimize yönelik trafik miktarını ve sistemlerimizdeki yükü azaltmamızı sağlar.
Bunun bir örneği, gerçekleştirmemiz gereken çok çeşitli HTTP güvenlik açığı testlerimiz olduğundan, ortak HTTP ve HTTPS bağlantı noktalarını günde birkaç kez incelemenin çok önemli olduğu bağlantı noktası keşfidir. Diğer bağlantı noktaları daha az sıklıkta kontrol gerektirebilir ve 65.000 bağlantı noktasının tüm yelpazesi göz önüne alındığında, bunların hepsini aynı monitörle incelemenin hem maliyet açısından hem de müşterilerimiz için trafik etkisi açısından etkisiz olacağı açıkça ortaya çıkıyor.
Motor çerçevemiz, test ettiğimiz bağlantı noktalarını her biri kendi temposunda çalışan çeşitli monitörlere bölmemize olanak tanır. Bu, her şeyi mantıksal bir şekilde test etmemizi sağlar. Bu monitörlerin tasarımı, güvenlik uzmanlarımızdan aldığımız bilgilerin yanı sıra müşterilerimizden topladığımız verilere dayanmaktadır.
Liman keşifleri için örnek monitör tasarımı
Çerçeve açısından bakıldığında, monitör konfigürasyonu her motora özgü olan birkaç şeyden biridir. Çerçeve, her motorun kendi izleme konfigürasyonunu sağlayabileceği bir kanca sağlar. Bu, her birinin bir adı, bir test listesi ve temposu olan bir monitör listesi kadar basit olabilir.
Dağıtımı İzle
Tek amacı dağıtımı izlemek gerçekleştirilecek işleri (hangi testlerin gerçekleştirileceğini) beklenen tempoyu takip edecek şekilde dağıtmaktır. Dağıtım, her monitörün bir sonraki dağıtımın zamanlamasını tutmasıyla, planlı bir şekilde gerçekleşir.
Dağıtım zamanı geldiğinde, kirli monitörler (programlarına göre dağıtılması gerekenler) getirilir ve işler oluşturulur ve mevcut ve bir sonraki dağıtım zamanı arasındaki zamana yayılır. Bu, işleri bu aralığa ancak her zaman farklı zamanlarda dağıtmamıza olanak tanır ve müşterilerimizi trafikten bunaltmaktan kaçınmak için eğriyi düzleştirir. Bu teknik şu şekilde bilinir: yavaş damlama Davetsiz misafir koruma sistemlerinin tetiklenmesini önlemek için testlerin zaman içinde yavaş yavaş yapıldığı güvenlik alanında.
Müşterilerimizin sistemlerinin aşırı yüklenmesini tamamen önlemek için bir parçaya daha ihtiyacımız var: önümüzdeki haftalarda hakkında özel bir blog yazısı yazacağımız hız sınırlayıcımız.
Tüm testlerin mümkün olduğu kadar hızlı çalışacak şekilde planlandığı ve bunları zamana dağıttığımız eğrinin (yeşil) düzleştirildiği ani yükselişlerin (kırmızı) çizimi
İş dağılımı söz konusu olduğunda istisnalar vardır. Birincisi, bir monitörü ilk kez dağıttığımız zamandır: örneğin müşteri Detectify’ı yeni kullanmaya başlamıştır ve tüm kadans aralığını beklemek yerine birkaç dakika içinde sonuç almayı beklemektedir. İkinci istisna, önceden oluşturulmuş bir monitör için yeni bir hedefin keşfedilmesidir. Bu durumda, saldırı yüzeyi büyüdükçe müşterimizi güvende tuttuğumuzdan emin olmak için yeni bulunan hedefi hemen değerlendirmek istiyoruz.
Bana kodu göster
Tipik bir motorun her gün birkaç milyon monitörü yönetmesi gerekebilir ve bu da birçok ilginç zorluğu beraberinde getirir. İlk olarak, bu kadar yüksek bir hacmi beklenen zaman dilimi içinde idare edebilmek için iyi düzeyde bir paralelleştirmeye ihtiyacımız var. İkinci olarak, monitör dağıtımının uygun zamanda gerçekleşmesini sağlamak ve aynı zamanda belirli bir monitör dağıtımını ne zaman gerçekleştirdiğimiz veya bunu bir sonraki ne zaman gerçekleştireceğimiz gibi olayların durumunu da takip edebilmek istiyoruz. Üçüncüsü, monitör dağıtımının öngörülebilir bir yinelenen yükü var ve biz de maliyet optimizasyonumuz için bundan yararlanmak istiyoruz.
Yukarıda sunulan zorluklar göz önüne alındığında, sorunu çözmek için çeşitli teknolojileri ve yaklaşımları araştırdık. Motordan gelen ek gereksinimlerle birlikte izlemeyi çalıştırmaya karar verdik. ECS ve kullanarak PostgreSQL. Bu bölümde monitör dağıtım sorununu iki alt probleme ayırarak bu yöntemleri nasıl kullandığımızı açıklayacağız: kirli monitörleri getirmek ve iş kuyruğuna iş eklemek.
Kirli monitörler getiriliyor
Kirli monitör, beklenen kadans aralığına (yani son dağıtım zamanından şimdiye kadar geçen sürenin kadans aralığından daha uzun olmasına) bağlı olarak yeniden dağıtılmaya hazır olan monitördür.
Son dağıtımdan bu yana geçen süre ritim aralığından uzun olduğunda monitör kirlenir
Bir motor için günlük milyonlarca monitörü yönetmek için dağıtımı paralelleştirmemiz gerekiyor. Amacımız en uzun süre kirli olan monitörlere öncelik vermek; ancak bu yükün tek bir monitör dağıtıcısı ile sıralı olarak taşınması yetersizdir. Bunu çözmek için kuralları yeniden tanımlamamız gerekiyor. En uzun süre kirli olan monitörleri dağıtmayı hedeflesek de bunların dağıtım sırası çok önemli değil.
Monitör dağıtımını, her biri birkaç iş parçacığı çalıştıran ve hepsi kirli monitörlere erişmek için yarışan çeşitli ECS görevlerinde çalıştırarak paralelleştiriyoruz.
Birçok görevdeki birçok iş parçacığı, veritabanından kirli monitörler almak için yarışıyor
Herkesin engellenmesini veya birden fazla iş parçacığının aynı veriler üzerinde çalışmasını önlemek için, ‘güncelleme atlama kilitli olarak seç’ şeklinde bir PostgreSQL özelliği kullanıyoruz.
WITH _dirty_monitors AS ( SELECT m.id from monitor m
WHERE m.latest_distribution_state = ‘WAITING’ AND m.next_distribution_at <= NOW() ORDER BY m.next_distribution_at LIMIT 100 FOR UPDATE SKIP LOCKED
) UPDATE monitor SET latest_distribution_state = ‘RUNNING’, latest_distribution_start_at = NOW() WHERE id = ANY(select dm.id from _dirty_monitors dm) RETURNING …;
Bu özellik, herkesin şu anda kilitli olanları atlarken satır kilitlerini almak için rekabet etmesini sağlamamıza olanak tanır. Örneğin, gelen ilk iş parçacığı ilk 100 satırı kilitleyebilirken, ikinci iş parçacığı sonraki 100 satırı kilitleyerek farklı satırlarda çalışmanın paralel olarak gerçekleşmesine olanak tanır. Bu yaklaşım, monitörlerin dağıtımlarının en iyi çabayı gösterecek şekilde sıralanmasıyla ilgilidir; belirtildiği gibi bu katı bir gereklilik değildir. Öyle olsaydı çözümümüz kesinlikle farklı görünürdü. Bu nedenle, maliyet verimliliğini korurken ve iyi gözlemlenebilirlik eklerken yükü etkili bir şekilde yönetmeyi seçiyoruz. Dağıtım bir monitör için önemli ölçüde gecikmediği sürece sistem, verilerin tazeliği konusunda beklentileri karşılayacaktır.
Konular kilitli satırları atlayacak ve tümü ilk kilitli olmayan satırları alacak
Tahmin edebileceğiniz gibi monitörlerin getirilmesi ve dağıtımı arasında sorunlar ortaya çıkabiliyor. Ancak dağıtımın her zaman devam edeceğini ve monitörlerin asla kaybolmayacağını doğrulamak için kendi kendini onaran önlemler uyguladık.
Amaca yönelik oluşturulmuş iş kuyruğu
İlk adım, her kirli monitör için işlerin zamanında dağıtılmasını sağlamaktı. Daha sonra işleri rastgele bir yere yerleştirmemize ve belirli zamanlardan önce alınmamalarını sağlamamıza olanak tanıyan gerçek iş kuyruğunu oluşturmaya odaklandık. Yani tipik bir ilk giren ilk çıkar kuyruğu değil.
Bir örneğe bakalım. Biri 1, 2 ve 3 numaralı bağlantı noktaları için keşif yapan "example.com" için, diğeri 1, 2, 3 numaralı bağlantı noktaları için aynı keşifleri yapan "detectify.com" için olmak üzere iki monitöre sahip olduğunuzu düşünün. İlk olarak, "example" için monitör. com` dağıtılır ve burada işleri kendi kadans aralığı dahilinde planlar, örneğin port 1 saat 04:00'te, port 2 saat 12:00'de ve port 3'ü saat 20:00'de alır ve onları iş kuyruğuna koyar. Daha sonra bir saat sonra `detectify.com' için iş dağıtımı yapıyoruz ve port 1 saat 16:00, port 2 saat 02:00 ve port 3 11:00 olarak planlanıyor ve iş kuyruğuna ekleniyor. Daha sonra test çalışanlarımızın bu iş kuyruğunu işlemesini istiyoruz. İlk gelen ilk alır yaklaşımını izlemek yerine işçiler, işlerin planlanan yürütme sürelerine göre kuyruğu yeniden sıralayacaklar.
Yürütme zamanına göre sıralanan hesaplanan iş kuyruğu
Test çalışanları yalnızca belirtilen sıraya uymakla kalmamalı; ayrıca planlanan saatlere uymaları gerekir. Örneğin, iş kuyruğunda birden fazla planlanmış iş varsa, çalışanlar işi gerçekleştirme zamanı gelene kadar herhangi bir işlem yapmaktan kaçınmalıdır.
Bu, yeni bulunan hedefleri anında değerlendirme için iş kuyruğunun en üstüne yerleştirerek önceliklendirmemize olanak tanır.
Yeni bulunan hedefin işi kuyruğun en üstüne eklendi
gözlemlenebilirlik
Makalemizde de belirtildiği gibi Motor çerçevesi hakkında önceki makaleMotorlarımızın nasıl performans gösterdiğine ilişkin gözlemlenebilirliğe sahip olmak kritik önem taşıyor.
İzleme sorun alanı söz konusu olduğunda, kaç monitörün ele alındığına, bunların ne kadar geciktiğine ve bunları dağıtmanın ne kadar zaman aldığına dikkat etmek istiyoruz. Bu hususlar güvenilirlik ve ölçeklenebilirlik açısından önemlidir.
Doğal olarak, tamamen güncel kalmak ile kısa anlarda kendinizin geride kalmasına izin vermek arasında bir denge vardır. Kuyruğun çok fazla büyümesini veya çok geride kalmasını önlemek istiyoruz ancak aynı zamanda altyapımızın gereğinden fazla tedarik edilmesini de istemiyoruz.
İzleme gecikmesini görselleştirmek için seçtiğimiz yöntem kovalar kullanmaktır. Bu yaklaşım, belirli eşik değerlerinin gerisinde kalan monitör dağıtımlarının miktarını takip etmemizi sağlar. Bu, 'geçerli zaman – tahmini monitör dağıtım süresi = mevcut gecikme süresi' olarak hesaplanır. Gecikme süreleri 15 dakikalık bölümlere ayrılmıştır.
Dağıtım gecikmesi için gözlemlenebilirlik
Bu verileri oluşturmak için `adlı PostgreSQL özelliğini kullanıyoruz.genişlik_bucket' Bu, geride kaldıkları süreye bağlı olarak monitörlerimizi gruplara yerleştirmeye yardımcı olur.
WITH _monitors_lagging AS (
SELECT id, next_distribution_at from monitor where next_distribution_at <= NOW() AND latest_distribution_state IN (‘WAITING’, ‘RUNNING’)) SELECT count(*), WIDTH_BUCKET(
next_distribution_at, ARRAY(
SELECT GENERATE_SERIES(
NOW() - INTERVAL ‘1 hour’, NOW(),
(15 || ' minutes')::INTERVAL))
) AS bucket
FROM _monitors_lagging
GROUP BY bucket ORDER BY bucket;
Sonra tabii ki eğlence başlangıç İzleme: Bu gecikmeyi hesaplayan çalışanın performansını gözlemliyoruz, çünkü müşteri tabanımızın büyümesi ve saldırı yüzeyinin boyutu nedeniyle bu sorgular ağırlaşabilir.
Daha fazla verimlilik ve sıklık
Yeni izleme sistemimiz, monitör tasarımını doğru şeyleri doğru tempoda etkili bir şekilde test edecek şekilde uyarlamamıza olanak sağladı. Verimlilik açısından, genel performanstan ödün vermeden veya ekibimizi veya müşterilerimizi etkilemeden en önemli testlerimizin sıklığını başarıyla artırdık. Bu sistemin entegre olduğu göz önüne alındığında motor çerçevesisayesinde, bu avantajları tek bir tıklamayla tüm motorlarımızda paylaşabiliyoruz.
Detectify hakkında daha fazla bilgi edinmek ister misiniz? 2 haftalık ücretsiz deneme sürümünü başlatın veya uzmanlarımızla konuşun.
Zaten bir Detectify müşterisiyseniz en son ürün güncellemeleri, iyileştirmeler ve yeni güvenlik testleri için Yenilikler sayfasını kaçırmayın.