Altyapı Kod Olarak (IaC), makine tarafından okunabilen tanım dosyaları aracılığıyla teknoloji altyapısının yönetimini ve sağlanmasını otomatikleştirerek modern DevOps’ta yaygın olarak benimsenen bir uygulama haline gelmiştir.
IaC’yi varsayılan olarak güvenli hale getirmek için ne yapabiliriz?
IaC için güvenlik iş akışları
Öncelikle IaC için güvenlik iş akışlarının genellikle birden fazla adım ve uygulamadan oluştuğunu düşünelim.
IaC kodu, birleştirmeden önce değişikliklerin izlenip incelendiği Git gibi sürüm kontrol sistemlerinde saklanır ve bu da tutarlılığı artırmaya yardımcı olur. Güvenlik politikaları ve yapılandırma kontrolleri genellikle otomatikleştirilir ve her bir commit veya çekme isteğinin dağıtımdan önce güvenlik politikalarına göre doğrulanmasını sağlamak için CI/CD kanallarına entegre edilir.
Diğer güvenlik en iyi uygulamalarının (en az ayrıcalık ilkesi, tehdit modellemesi ve tespiti, çalışma zamanı izleme ve denetim ve günlük kaydı gibi) yanı sıra, kuruluşlar ayrıca yeni altyapının mevcut kaynakları değiştirerek veya eski IaC şablonlarını kullanarak değil, güncellenmiş, güvenli özelliklere göre sağlanmasını sağlamalıdır. Tüm bu iş akışları ve otomasyonlar, kuruluşların modern ortamlarda tutarlı altyapıyı daha kolay bir şekilde dağıtmalarını sağlamada hayati bir rol oynamıştır.
Güvenlik açıkları IaC’nin doğasında vardır
Ne yazık ki, güvenlik politikalarını IaC’de koda dönüştürmek, öncelikle insan hatasından kaynaklanan birkaç potansiyel sorun içerir. Güvenlik ekipleri veya geliştiriciler güvenlik politikalarını manuel olarak IaC koduna çevirdiğinde, daha sonra birden fazla ortama yayılabilecek önemli bir hata veya yanlış yorumlama riski vardır.
İnsan hatası potansiyeline ek olarak, bu süreç aynı zamanda emek yoğun olup geliştirme ve dağıtım süreçlerini yavaşlatır. Ve ne yazık ki, bu manuel dönüşümler IaC’nin sunmayı vaat ettiği verimlilik kazanımlarının bir kısmını ortadan kaldırabilir.
Bir diğer önemli zorluk ise güvenlik politikalarının kaçınılmaz olarak evrim geçirmesi ve karşılık gelen IaC’yi manuel olarak güncellemenin daha fazla insan hatası potansiyeli yaratmasıdır. Genel olarak güncellenmezlerse, altyapı güncel olmayan güvenlik standartlarıyla çalışıyor olabilir.
Ayrıca, altyapı daha karmaşık hale geldikçe, güvenlik politikalarını manuel olarak yönetmek ve uygulamak giderek daha zor ve hataya açık hale gelir çünkü daha fazla potansiyel arıza noktası ortaya çıkarır. Daha karmaşık uygulamalar ayrıca genellikle istenmeyen çatışmalar yaratmadan yönetilmesi zor olabilen birden fazla birbirine bağımlı bileşene sahiptir. Ve tüm bunlar ekibinizin hem güvenlik politikaları hem de IaC kodlaması konusunda derin bir anlayışa sahip olmasına bağlıdır.
IaC’yi tarama
Dağıtımdan önce IaC şablonlarını taramak tartışmasız önemlidir; potansiyel güvenlik sorunlarını geliştirme sürecinin erken aşamalarında belirlemenin etkili bir yoludur. Güvenlik ihlallerini önlemeye ve bulut altyapınızın en iyi güvenlik uygulamalarıyla uyumlu olmasını sağlamaya yardımcı olabilir. CI/CD boru hatlarınıza entegre edilmiş IaC tarama araçlarınız varsa, her kod commit veya çekme isteğiyle otomatik taramalar çalıştırabilir ve hataları erken yakalayabilirsiniz.
Dağıtım sonrası taramalar, altyapıyı operasyonel ortamında değerlendirdikleri için önemlidir; bu da geliştirme ve test ortamlarında tanımlanmayan sorunların bulunmasıyla sonuçlanabilir. Bu taramalar ayrıca kaynaklar arasındaki beklenmeyen bağımlılıkları veya çatışmaları da tanımlayabilir.
Bu sorunları gidermek için yaptığınız tüm manuel düzeltmeler, mevcut IaC şablonlarınızı güncellemenizi de gerektirecektir, aksi takdirde bu şablonları kullanan tüm uygulamalar aynı yerleşik sorunlarla dağıtılacaktır. Ve bu sorunları üretim ortamlarında belirlemek genel güvenlik açısından önemli olsa da, maliyetlerinizi artırabilir ve ekibinizin hem uygulamaya hem de IaC’ye manuel düzeltmeler uygulamasını gerektirebilir.
Otomasyon hedefi ıskalayabilir
Bazı araçlar, güvenlik yamalarını otomatik olarak uygulayarak IaC’ye manuel düzeltme ihtiyacını en aza indirmek için otomatik düzeltme özellikleri sunar. Ne yazık ki, düzeltmeyi otomatikleştirmek farklı bir sorun kümesi yaratabilir. Örneğin, otomatik düzeltme araçları şu nedenlerle yetersiz kalabilir:
- Her uygulama veya ortamın benzersiz bağlamını tam olarak hesaba katmayan, uygulamaları bozan veya başka sorunlara yol açan değişikliklere yol açabilen önceden tanımlanmış kurallara ve algoritmalara göre çalışın.
- Sorunlara neden olup olmadıklarını tespit etmeden aşırı kısıtlayıcı düzeltmeler uygulayın. Örneğin, yükseltilmiş ayrıcalıklar gerektiren bir Kubernetes pod’u için ayrıcalıkları azaltmak, çalışmayan bir uygulamayla sonuçlanabilir.
- Yapılandırma kaymasından kaynaklanan tutarsızlıkların hesaba katılmaması, daha fazla kaymaya ve potansiyel uygulama kararsızlığına yol açar.
- Kritik ve kritik olmayan sorunlar arasında ayrım yapılamaması, hizmet kullanılabilirliğini ve bütünlüğünü etkileyebilecek gereksiz hatta zararlı değişikliklere yol açıyor.
- Temel sebepler yerine semptomları ele alın, aksi takdirde altta yatan sorun çözülmediği için tekrarlayan sorunlar ortaya çıkar.
- Ayrıntılı karar alma gerektiren karmaşık senaryolar için düzeltmeleri uygulamada zorluk yaşanır; karmaşık sorunlar genellikle insan müdahalesi gerektirir.
- Bir düzeltme yeni saldırı vektörleri açarsa veya mevcut güvenlik önlemlerini zayıflatırsa yeni güvenlik açıkları ortaya çıkar.
Otomatik düzeltme kulağa ideal geliyor ancak uygulamalarınızın güvenilirliğini ve kullanılabilirliğini etkileyebilecek sayısız istenmeyen sonuca yol açabilir.
Uygulamayı güvenliğin kaynağı haline getirin
Tüm bu güvenlik hususları akılda tutulduğunda, bu kadar çok manuel adım varken altyapıyı varsayılan olarak nasıl güvenli hale getiririz?
Bir öneri, uygulamaya altyapı için gerçeğin kaynağı olarak bakmaktır. Bu nasıl görünüyor?
Bir geliştirici bir uygulama yazdığında, sürekli olarak seçimler yapar. Örneğin: Uygulamanın hangi veritabanına erişmesi gerekir? Uygulamanın çalışmak için hangi diğer kaynaklara bağlanması gerekir? Her karar, onu destekleyecek bir altyapı gerektirir ve bu altyapının tamamı geliştiricinin kullanımına sunulmalıdır. Ve sadece bu değil; bir geliştiricinin erişebildiği altyapının, halihazırda alınmış kararlara dayalı olarak ilgili güvenlik standartlarına uyması gerekir.
Uygulamayı gerçeğin kaynağı olarak kullanarak şunları yapabilirsiniz:
- Bir geliştiricinin bir uygulama için gereken tüm güvenlik politikalarını bilmesi ihtiyacını ortadan kaldırın
- Bunu desteklemek için doğru altyapının mevcut olduğundan emin olun
- Geliştiricilerin tüm gereksinimleri kodlamayı hatırlamaları ihtiyacını ortadan kaldırın
- Güvenlik ve uyumluluk politikalarıyla uyumlu olduğundan emin olmak için IaC’nin her bir satırını denetleme ihtiyacını ortadan kaldırarak güvenlik ekiplerinin zamanından tasarruf edin
- Altyapı yapılandırmasının doğrudan uygulamanın gereksinimleriyle uyumlu olduğundan emin olun
- Uygulama ve altyapı arasındaki uyumsuzluk riskini en aza indirin
Bu yaklaşım, bir uygulamanın ne gerektirdiğini standartlaştırarak dağıtımınızı kolaylaştırarak verimliliği ve otomasyonu iyileştirir. Ayrıca, güvenlik ve uyumluluk politikalarını uygulamayı ve en az ayrıcalıklı erişim kontrollerinin yerinde olmasını garantilemeyi çok daha basit hale getirir.
Varsayılan olarak güvenli IaC mümkündür
IaC uygulama dağıtımının birçok zorluğunu çözerken, güvenlik politikalarını manuel olarak IaC’ye dönüştürmek için hala insanlara güvenir. Ancak, altyapıyı uygulama kodunun kendisinden üreten araçları kullanarak IaC’yi soyutlayabilirseniz, IaC’yi varsayılan olarak güvenli hale getirebilirsiniz.
Uygulamanın bağlamını altyapıya entegre ederek kuruluşlar, güvenlik açıkları ve yanlış yapılandırmalar konusunda endişelenmeyi bırakıp bunun yerine uygulama geliştirmeye ve sunmaya odaklanabilirler.