Çakışan iş gereksinimleri yaygın bir sorundur ve bunu bilgi teknolojisi de dahil olmak üzere bir organizasyonun her köşesinde bulabilirsiniz. Bu çatışmaları çözmek bir zorunluluktur, ancak her zaman kolay değildir – bazen yardımcı olan yeni bir çözüm olsa da.
BT yönetiminde güvenlik ve operasyon ekipleri arasında sürekli bir mücadele vardır. Evet, her iki ekip de nihayetinde ihlal edilmesi daha zor olan güvenli sistemlere sahip olmak istiyor. Ancak güvenlik, kullanılabilirlik pahasına gelebilir – ve bunun tersi de geçerlidir. Bu makalede, kullanılabilirlik ve güvenlik çakışmasına ve bu çakışmanın çözülmesine yardımcı olacak bir çözüme bakacağız.
Operasyon ekibi kullanılabilirliğe odaklanır… güvenlik ekipleri kilitlenir
Operasyon ekipleri her zaman istikrara ve dolayısıyla kullanılabilirliğe en büyük öncelik olarak sahip olacaktır. Evet, operasyon ekipleri güvenliği de bir öncelik haline getirecek, ancak yalnızca istikrar veya kullanılabilirliğe dokunduğu sürece, asla mutlak bir hedef olarak değil.
İnanılmaz derecede yüksek bir gereksinim belirleyen “beş dokuzlu” çalışma süresi hedefinde ortaya çıkıyor – bir sistemin çalışıyor ve zamanın %99,999’unda istekleri karşılamak için kullanılabilir durumda olması. Paydaşları mutlu eden övgüye değer bir hedeftir. Yüksek kullanılabilirlik gibi araçlar, sistem veya hizmet düzeyinde yedeklilik sağlayarak burada yardımcı olur, ancak güvenlik hedefleri hızla “beş dokuz” elde etmenin önüne geçebilir.
Güvenlik ekipleri için nihai hedef, sistemleri mümkün olduğunca kilitleyerek saldırı yüzeyini ve genel risk seviyelerini mutlak minimuma indirmektir. Uygulamada, güvenlik ekipleri, bir sistemin yama için iki hafta sonra değil, hemen şimdi kapatılmasını talep edebilir, bu da hemen yama yapmak için kullanılabilirliği azaltır – bunun kullanıcılar için ne gibi sonuçlar doğuracağını boşverin.
Bu yaklaşımın operasyon ekipleri için büyük bir baş ağrısı yaratacağını görmek kolay. Daha da kötüsü, yüksek kullanılabilirliğin operasyon ekiplerinin kullanılabilirlik ve kararlılık hedeflerine ulaşmasına gerçekten yardımcı olduğu durumlarda, şu anda katlanarak artan sayıda sunucu veya hizmetle ilgilenmesi gereken ve tümü koruma ve izleme gerektiren güvenlik ekipleri için işleri daha da kötüleştirebilir.
Hangi en iyi uygulama izlenir?
Operasyonlar ve güvenlik arasında bir çatışma yaratır, bu da iki grubun en iyi uygulamalar ve süreçler gibi konularda hızla karşı karşıya geldiği anlamına gelir. Yama oluşturmayı düşünürken, bakım penceresi tabanlı bir yama politikası, daha az kesintiye neden olur ve yama çalışmaları ile ilişkili kapalı kalma süresi arasında birkaç haftalık bir gecikme olduğu için kullanılabilirliği artırır.
Ancak bir sorun var: Bakım pencereleri, ortaya çıkan tehditlere karşı düzgün bir şekilde savunma yapacak kadar hızlı yama yapmaz, çünkü bu tehditler genellikle ifşa edildikten birkaç dakika sonra (veya ifşadan önce bile, örneğin Log4j) aktif olarak kullanılır.
Sorun, her tür iş yükünde ortaya çıkar ve günün tadı olarak en son DevOps, DevSecOps veya her türlü işlem yaklaşımını kullanmanız gerçekten önemli değildir. Sonuç olarak, kullanılabilirlik veya performans pahasına güvenli işlemler için daha hızlı yama yaparsınız ya da daha yavaş yama yapar ve güvenlikle kabul edilemez riskler alırsınız.
Hızla gerçekten karmaşıklaşıyor
Ne kadar hızlı yama yapılacağına karar vermek sadece başlangıç. Bazen yama yapmak basit değildir. Örneğin, programlama dili düzeyindeki güvenlik açıklarıyla uğraşıyor olabilirsiniz – bu da uygulamalar bu dilde yazılır, örneğin bir PHP güvenlik açığı olan CVE-2022-31626.
Bu olduğunda, kullanılabilirlik ve güvenlik çatışmasına katılan başka bir grup daha vardır: dil düzeyinde bir güvenlik açığıyla iki adımda ilgilenmesi gereken geliştiriciler. İlk olarak, kolay kısım olan söz konusu dil sürümünü güncelleyerek.
Ancak bir dil sürümünü güncellemek yalnızca güvenlik iyileştirmeleri getirmez; diğer temel değişiklikleri de beraberinde getirir. Bu nedenle geliştiricilerin ikinci bir adımdan geçmeleri gerekiyor: uygulama kodunun yeniden yazılmasının getirdiği dil düzeyindeki değişiklikleri telafi etmek.
Bu aynı zamanda bazı durumlarda yeniden test etme ve hatta yeniden sertifikalandırma anlamına gelir. Tıpkı yeniden başlatmayla ilgili kapalı kalma süresinden kaçınmak isteyen operasyon ekipleri gibi, geliştiriciler de kapsamlı kod düzenlemelerinden mümkün olduğunca uzun süre kaçınmak ister çünkü bu, evet, daha sıkı güvenlik sağlayan büyük bir çalışma anlamına gelir – ancak aksi takdirde geliştiricilere zamanları için gösterecek hiçbir şey bırakmaz. .
Mevcut yama yönetimi süreçlerinin neden ekipler arasında çok katmanlı bir çatışmaya neden olduğunu kolayca görebilirsiniz. Tepeden tırnağa bir politika sorunla bir dereceye kadar ilgilenebilir, ancak genellikle sonuçtan kimsenin gerçekten memnun olmadığı anlamına gelir.
Daha da kötüsü, bu politikalar, sistemleri çok uzun süre yamasız bırakarak güvenliği tehlikeye atabilir. Mevcut tehdit düzeyinde riskin kabul edilebilir olduğunu düşünerek haftalık veya aylık aralıklarla sistemleri yamalamak, er ya da geç ciddi bir gerçeklik kontrolüne yol açacaktır.
Anında yama (ve kesinti) ile gecikmeli yama (ve güvenlik açıkları) arasındaki çelişkiyi önemli ölçüde azaltmak veya hatta çözmek için bir yol vardır. Cevap, her düzeyde veya en azından pratik olduğu kadar çok düzeyde kesintisiz ve sürtünmesiz yamada yatmaktadır.
Sürtünmesiz yama çatışmayı çözebilir
Canlı yama, güvenlik ekibinizin araması gereken sorunsuz yama aracıdır. Canlı yama sayesinde, normal bakım pencerelerinin elde etmeyi umabileceğinden çok daha hızlı yama yaparsınız ve güncellemeleri uygulamak için hizmetleri yeniden başlatmanız gerekmez. Çok az veya hiç kesinti süresinin yanı sıra hızlı ve güvenli yama. Kullanılabilirlik ve güvenlik arasındaki çelişkiyi çözmenin basit ve etkili bir yolu.
TuxCare’de kritik Linux sistem bileşenleri için kapsamlı canlı yama ve güvenlik sorunlarına odaklanan çoklu programlama dilleri ve programlama dili sürümleri için yamalar sağlıyoruz ve aksi takdirde kodun yeniden düzenlenmesini zorunlu kılacak dil düzeyinde değişiklikler yapmıyoruz – kodunuz şu şekilde çalışmaya devam edecek: sadece güvenlidir. İşletmeniz desteklenmeyen uygulamalara dayansa bile, bir programlama dili kusuru yoluyla sistemlerinize sızan güvenlik açıkları konusunda endişelenmenize gerek kalmaz ve uygulama kodunu güncellemeniz gerekmez.
Özetlemek gerekirse, kullanılabilirlik ve güvenlik çatışmasında canlı yama, operasyonlar ve güvenlik ekipleri arasındaki gerilimi önemli ölçüde azaltabilecek tek araçtır.