Teknolojilerin kesiştiği nokta!

DevOps Sistem Güvenliğini Nasıl Artırıyor?

Geçtiğimiz beş yılda araştırma, kabul etme ve deneyimleme yoluyla DevOps’a yönelik algı ve bilgi teknolojileri sektöründeki rolü değişiklik gösterdi. 

Geçmişte aksini iddia edenler olduysa da sürekli dağıtımın istikrarı arttırdığı gibi doğru uygulanan DevOps pratikleri de sistem güvenliğini arttırır. 

Gene Kim “DevOps’un Üç Yolu” ile sürekli dağıtım, geliştirme geri bildirimleri için üretim ve sürekli öğrenimi anlatır. Sürekli dağıtım, aşamalı olarak küçük değişikliklerde yazılım geliştirmeyi ve otomatik testlerle her değişikliği bir dağıtım hattında doğrulamayı gerektirir. Bilgisayarlı pipeline yazılım geliştirmeye kıyasla, ekiplere otomatik dağıtım pipeline olmadan güvenliği artırmanın çeşitli yollarını sunar. 

Güvenlik sorunları diğer yazılım regresyonları gibidir. Üretim sırasında ortaya çıkmamaları için önceden test edilebilirler. InfoSec’e otomatik testi uygulamanın birden çok yolu vardır:

  • Bilinen yazılım açıkları ve bilinen sorunlu paketlerin yer aldığı başarısız derlemeler için kapsayıcıyı veya VM görüntülerini tarayın
  • Statik analiz araçlarını tehlike potansiyeli olan sistem çağrıları ve başarısız derlemeleri belirtmek için çalıştırın
  • API belirteçleri veya SSH anahtarları gibi düz metin şifreleri için Lint kodu ve sonuç olarak hata oluşturma
  • Yapay yapılara karşı OSWAP'dakiler gibi uçtan uca testler yapın

Otomatikleşmesinden bu yana dağıtım pipelinelarına bu testlerin eklenmesi “sola kayma” oalrak isimlendirilen önemli bir güvenlik artışı sağlamıştır. Yazılımın; başlangıçtan itibaren, otomatik olarak ve pipeline boyunca güvenli olmasını sağlar.

Çoğu zaman firmaların yola beraber devam etmek için yeteri sayıda InfoSec mühendisleri olmaz. Bu, InfoSec kontrollerinin işlemin sonuna kadar itilmesinden dolayı olumsuz sonuçlar doğurur ve yalnızca yeterli kapasite olduğunda ortaya çıkabilir. Ekipte fazladan bir mühendis olduğunda, mevcut otomatik test takımınızı çalıştırırken bir an düşünün. Otomatik fonksiyonel test önerisinin modern bilgi teknolojisinde gülünç olduğunu kabul edilirken, neden InfoSec testi için aynısına izin veriliyor? Pipeline'a InfoSec testlerinin eklenmesi her değişikliği doğrular ve firmaya göre ölçeklendirir. Pipeline dağıtımı değişim için bir kaç mühendisden daha büyük bir güçtür. Daha da önemlisi, testlerin eklenmesi sorunları herkese açıklar ve regresyonu düzeltmek için sorumluluğu kod yazarına kaydırır.

Otomatik testler bilinen regresyonların üretime girmelerinin önüne geçer. Bununla birlikte, üretimdeki saldırılar ve diğer kötü niyetli faaliyetlere karşı koruyamazlar. Ekiplerin, üretimdeki kötü niyetli aktiviteleri veya diğer kızıl bayrakları gösteren telemetri verilerini izlemesi ve uyarması gerekir. Bu, DevOps'un üretimden gelişime geri bildirim sağlayan ikinci yoludur. Ekipler; gecikme süresi, istek sayımı ve aktif kullanıcılar ve dahası için üretim telemetrisine zaten sahiptirler, bu yüzden InfoSec telemetrisi de aynı şekilde entegre edilmelidir. Örnek verirsek;

  • SSH bağlantıları
  • Kullanıcı girişleri
  • Şifre sıfırlamalar
  • Kötü niyetli SQL sorguları
  • İncelemeler veya başka bir kötü niyetli faaliyeti gösterebilecek hatalı biçimlendirilmiş istekler
  • E-posta adreslerindeli (yada diğer giriş bilgilerindeki) değişiklikler
  • Faturalandırma ve ödeme bilgilerindeki değişimler
  • Yapı güvenliği grubu yada güvenlik duvarı değişiklikleri
  • XSS saldırıları
  • Ağ, yeni sistem kullanıcıları yada düzenlenmiş dosya sağlamaları gibi yapı değişiklikleri
  • Ayrıcalık artışı (ör. sudo calls)

Bu tür telemetri verisi, sistemin üretimde nasıl kullanıldığını anlamak için oldukça kritiktir. Bu görüşe göre, ekipler potansiyel sorunları tanımlayan pipeline'a regresyon testleri ekleyerek eylemde bulunabilir, bu da üretim için güvenlik duruşunun artmasını sağlarlar. Daha da önemlisi, görünürlüğü arttırır. Bir ekibin saldırı altında olduğunu anlaması halinde güvenlik değişikliklerinin ortaya çıkması daha olasıdır.

Etsy'den Nick Galberth, güvenlik telemetrisini çizdikten şu düşüncesini paylaşıyor;

“Bu grafiği göstermenin sonuçlarından biri, geliştiricilerin her zaman saldırıya uğradıklarını fark etmeleriydi! Bu harikaydı, çünkü geliştiricilerin kodlarını yazarken kodlarının güvenliği hakkındaki düşüncelerini değiştirdi. “

Bu uygulama aynı zamanda üretim öncesi test ve uygunluk kontrollerinin yeterli olmadığı senaryolara yardımcı olmaktadır. Accelerate, üretim InfoSec telemetrisinin değerini gösteren bir ATM satıcısının sıkıntılı bir vaka incelemesini içerir. Şirket ATM'lerinin planlanmayan zamanlarda bakım moduna alındığını fark etti. Bu, saldırganın makineden fiziksel olarak para çıkarmasını sağladı. Bir geliştirici yıllar önce arka kapıyı kurdu. Görünürde, bu tür arka kapıları önceden tespit etmek zor ya da neredeyse imkansız. Bununla birlikte, üretim telemetrisi anormalliği tespit etti ve ekibi uyardı. Ekip, sahtekarlığı proaktif olarak buldu ve planlanan nakit denetim sürecinden önce sorunu çözdü.

Bu örnekler DevOps uygulamalarının sistem güvenliğini nasıl geliştirdiğini göstermektedir. İlk olarak, yazılımın diğer tüm yönleri gibi, dağıtım pipeline'ına otomatik testler ekleyin. İkincisi, doğrudan geliştirme değişikliklerini yönlendirmek için üretime telemetri ekleyin. Üçüncü yol, yazılım geliştirme sürecini daha da iyileştirmek için öğrenme ve deneyimlemedir. Ama malesef ki bazen ekipler bu yönü göz ardı ederler. DevOps geri bildirim döngüleri kurar ve üçüncü yöntem sürekli olarak onları zorlukları azaltmaları, bug sayısını düşürmeleri ve / veya değişen koşullara uyum sağlamaları için geliştirir.

Uyum ve denetim ortak bir ızdırap noktasıdır. Dokümantasyonun yapılması ve manuel incelemelerin gerçekleştirimesi gerektirdiği için süreci yavaşlatır. Bu işlemi durdurmak zorunda değildir. Otomasyon, zorlukları gidererek uyum ve denetim sürecini büyük ölçüde iyileştirebilir. Google SRE Kitabı zorluğu, “manuel, tekrarlayan, otomatikleştirilebilir, taktiksel, kalıcı değerden yoksun ve bir hizmet büyüdükçe doğrusal olarak boyutlanan bir üretim hizmetini yürütmeye bağlı iş türü” olarak tanımlamaktadır. Accelerate, 18F ve Cloud.gov örnek olay incelemesini içerir.

Örnek olay incelemesi, sistem güvenlik planlarını (SSP) yazmak için otomatik bir süreç uygulayan ve belirlenen otoriteden çalışma hakkı elde eden bir devlet kurumunu göstermektedir. SSP planları gözden geçirilmelidir. Genellikle yüz sayfa uzunluğunda ve oldukça ayrıntılıdırlar. Dinamik bir bulut ortamında bunları manuel olarak oluşturmak ve sürdürmek mümkün değildir. 18F; PDF'lere dönüştürülebilen veya iç ve dış gözden geçirme için ölçülmeyen çalışma saatleri tasarrufu sağlayan (ve süreçte mutluluğu artıran), PDF'lere dönüştürülebilen veya GitBooks olarak yayınlanan YML'de bir SSP'yi otomatik olarak meydana getiren bir araç yarattı. Özel sektördeki IT kuruluşları daha rahat düzenleme seviyelerine eğilimlidirler. Ne olursa olsun, mevcut zorlukları ve haracanan eforu azaltmak için  aynı uyum ve denetim tekniklerini kullanmak mümkündür ve kullanılmaları da gerekir.

Aşağı yönlü denetim ve uygunluk süreçlerinde de benzer yaklaşımlar kullanılabilir. Telemetri sistemleri üretiminin InfoSec verilerini içerdiği göz önüne alırsak, incelemeler sırasında denetçilere kendi kendilerini gösterebilirler. Kod, dağıtım pipeline'ı ve diğer otomasyonu kullanarak uygunluk raporları oluşturmak mümkündür. Bu yaklaşım da yine; tüm katılımcılar için zararı azaltır, isabetliliği arttırır ve daha fazla denetimin tamamlanmasını en iyi şekilde sağlar. 

DevOps, modern IT'nin yazılım oluşturması, test etmesi ve göndermesi için en iyi yoldur. Üç Yol, yazılım geliştirme sorunlarına nasıl ve niçin yaklaşılacağını anlamak için bir framework sunmaktadır. InfoSec'in değiştirilmesi ve geliştirilmesi, bulutun ve sürekli dağıtımın yazılıma yaptıklarından çok farklı değildir. Her şey artan sıklığın zorluğu azalttığı fikrinden kaynaklanıyor. Ekiplerin her üç ayda bir dağıtımı yapmaktan, her geliştiricinin günlük dağıtımı ölçmeye yönlendiğini gördü. Bu şaşırtıcı bir hız artışıydı. InfoSec sonuçlarına üç yolu uygulayarak aynı değişikliği etkileyebilir: otomatik test, üretim telemetrisi ve de sürekli öğrenme ve iyileştirme. Her üçünün de uygulanması, nihayetinde endüstri genelinde güvenlik zeminini yükselten bir sürekli doğrulama kültürü oluşturuyor. Bu kulağa, bugün ve gelecekte güvenliği artıracak bir ders kitabı konusu gibi geliyor.

Sitemizi kullanarak çerezlere (cookie) izin vermektesiniz. Detaylı bilgi için Çerez Politika'mızı inceleyebilirsiniz.