IAC Taraması: Harika, Gözden Geçirilmiş Bir Öğrenme Fırsatı

Kod olarak altyapı (IaC) hakkında okuduğunuz her şey, onun nasıl çalıştığına veya gerçekten inşa edilmesini istediğiniz şekilde oluşturulduğundan neden emin olmak istediğinize odaklanır.

Bunlar kritik alanlardır. Peki bu yaklaşımı organizasyonumuzda nasıl kullanacağımız konusunda yeterince düşünüyor muyuz?

As Melinda Marks ESG'den bir şirket raporunda, teknolojiyi benimsemeye devam ettikçe "kuruluşların %83'ünün IaC şablonu yanlış yapılandırmalarında bir artış yaşadığı" belirtiliyor.

Cloud Security Alliance'ın yaptığı çalışmalardan biliyoruz (“Bulut Bilişime Yönelik En Büyük Tehditler: Egregious Eleven“) ve diğerleri gibi, yanlış yapılandırmalar bulutta en büyük risk olmaya devam ediyor.

IaC aşağıdakiler için desteklenir: azaltmak
Altyapının oluşturulmasını sistematik hale getirerek, ekiplerin istediklerini ve yalnızca istediklerini inşa etmelerini sağlayan bir düzeyde titizlik ve süreç ekleyerek yanlış yapılandırmaları ortadan kaldırın. Takımların ~%83'ü bunu göremiyorsa, ortada daha derin bir sorun var demektir.

DevOps felsefesinin Dev ve Ops parçalarının bir arada olduğu daha küçük ekiplerde bu mantıklıdır. IaC, bu küçük ekiplerin yaptıkları her şeyi açıklamak için aynı dili (kodu) kullanmalarına olanak tanır.

Bu nedenle Terraform veya AWS CloudFormation gibi araçlardan bile daha yüksek düzeyde soyutlamalar görüyoruz. AWS CDK'si ve benzeri projeler cdk8'ler. Bu üst düzey soyutlamalar geliştiriciler için daha rahattır.

Bir bulut hizmetinin ops/SRE/platform perspektifi, aynı hizmetin geliştirici perspektifinden son derece farklı olacaktır. Bir geliştirici, bir sıraya alma hizmetine bakacak ve arayüzüne dalacaktır; eklenecek basit bir uç nokta ve okunacak bir uç nokta mı var? Satılmış. Bu kolay bir entegrasyon.

Bu operasyonel bakış açısı kenarları bulmayı amaçlamaktadır. Peki bu kuyruk ne zaman sınırına ulaşıyor? Performans sabit mi yoksa yük altında radikal bir şekilde değişiyor mu?

Evet, örtüşen kaygılar var. Ve evet, bu basitleştirilmiş bir görünüm. Ama fikir geçerli. IaC pek çok sorunu çözüyor ancak aynı zamanda ekipler arasındaki kopukluğu da yaratıp güçlendirebiliyor. Daha da önemlisi, inşa etmeye çalıştığınız şeyin amacı ile inşa ettiğiniz şeyin gerçekliği arasındaki boşluğu vurgulayabilir.

Sonuç olarak, güvenlik kaygılarının sıklıkla arttığı yer burasıdır.

Çoğu araç (ticari veya açık kaynak) altyapı şablonlarındaki yanlış şeyleri belirlemeye odaklanır. Bu
iyi bir yapıdır. Yapımı Re-Tweet
kötü olurdu. Bu araçlar, bu sonuçları sürekli entegrasyon/sürekli teslim (CI/CD) hattının bir parçası olarak üretmeyi amaçlamaktadır.

Bu harika bir başlangıç. Ancak aynı dil sorununu yansıtıyor.

Kim Konuşuyor ve Kim Dinliyor?

Bir IaC aracı bir sorunu vurguladığında bunu kim ele alacak? Eğer geliştirme ekibi söz konusuysa, bunun neden bir sorun olarak işaretlendiğini bilmek için yeterli bilgiye sahip mi? Operasyon ekibi söz konusu ise, sorunun sonuçları raporda belirtiliyor mu?

Geliştiriciler için genellikle IaC testinin başarılı olmasını sağlayacak şekilde yapılandırmayı ayarlamaları gerekir.

Operasyonlar için genellikle testlerin geçip geçmediği meselesidir. Eğer öyleyse, bir sonraki göreve geçin. Bu her iki takıma da bir darbe değil; daha ziyade beklentiler ile gerçeklik arasındaki uçurumu vurguluyor.

İhtiyaç duyulan şey bağlamdır. IaC güvenlik araçları, (umarız) inşa edilmek üzere olan şeyin görünürlüğünü sağlar. Amaç sorunları durdurmak önce üretime geçiyorlar.

Günümüzün IaC güvenlik araçları, ele alınması gereken gerçek sorunları vurgulamaktadır. Bu araçların çıktısını almak ve bunu koddan sorumlu ekibe özel ek bağlamla zenginleştirmek, bazı özel otomasyonlar için mükemmel bir fırsattır.

Bu aynı zamanda dil boşluğunun kapatılmasına da yardımcı olacaktır. Araçlarınızdan elde edilen çıktı, işleri daha karmaşık hale getirmek için esas olarak üçüncü bir dildedir ve geliştirme veya operasyon hedef kitlesine anlamlı gelecek şekilde iletilmesi gerekir. Çoğu zaman her ikisi de.

Örneğin, bir tarama, bir güvenlik grubu kuralının açıklamasının olmadığını işaretlediğinde bu neden önemlidir? Sadece "Bağlam için bir açıklama ekleyin" yazan bir uyarı almak kimsenin daha iyi geliştirme yapmasına yardımcı olmaz.

Bu bayrak türü, bulutta kurulum yapan ekipleri eğitmek için harika bir fırsattır. Güvenlik grubu kurallarının mümkün olduğunca spesifik olması gerektiğine dair bir açıklama eklemek, kötü niyetli saldırı olasılığını azaltır. Güçlü kural örneklerine referanslar verin. Niyetini bilmeden bunu söylerseniz diğer ekipler güvenlik onayının geçerliliğini test edemez.

Güvenlik herkesin sorumluluğundadır; dolayısıyla geliştiriciler ve operasyonlar arasındaki dil farkını kabul etmek, ekiplerinize öngörü sağlayan basit otomasyonlar eklemeye yönelik bunun gibi fırsatları öne çıkaracaktır. Bu, inşa ettikleri şeyin iyileştirilmesine yardımcı olacak ve sonuç olarak daha iyi güvenlik sonuçları elde edilmesini sağlayacaktır.

Yazar Hakkında

Ben dijital dünyayı ve onun üzerimizdeki etkisini anlamanıza yardımcı olmaya çalışan bir adli bilim adamı, konuşmacı ve teknoloji analistiyim. Günlük kullanıcılar için çalışmalarım dijital dünyanın zorluklarını açıklamaya yardımcı oluyor. Sosyal medyayı kullanmanın gizliliğiniz üzerinde ne kadar büyük bir etkisi var? Yüz tanıma gibi teknolojilerin toplumlarımızda kullanılmaya başlanması ne anlama geliyor? Bu ve bunun gibi soruların cevaplanmasına yardımcı oluyorum. Teknoloji geliştiren kişilerin işlerine güvenlik ve gizlilik merceğini uygulamalarına yardımcı oluyorum, böylece kullanıcıların bilgileri ve davranışları hakkında daha net kararlar verebilmelerini sağlıyorum. Gizlilik ve güvenlik söz konusu olduğunda dağ gibi bir kafa karışıklığı var. Olmamalı. Güvenliğin ve gizliliğin anlaşılmasını kolaylaştırıyorum.