Bulut hizmetlerinin maliyetleri artmaya devam ederken, şirketlerin bu hizmetlerin iş değerinin gerçek anlamdaki fiyat etiketine değip değmeyeceğini belirlemesi gerekiyor.

Değer, bir şeyin bireyler veya kuruluşlar için sahip olduğu değeri veya yararlılığı ifade eder. Sübjektiftir ve kişiden kişiye, işletmeden işletmeye veya bir bağlamdan diğerine değişebilir. Değer, bir şeyin onu elde etmek için gereken maliyet veya çabaya kıyasla sağladığı fayda veya avantajlar olarak görülebilir.

Değer, yalnızca bir mal veya hizmetin fiziksel veya içsel özellikleri tarafından değil, aynı zamanda ona sahip olan veya onu arzulayan kişi veya kuruluşların algı ve tercihleriyle de belirlenir. Genellikle kişisel ihtiyaçlar, arzular, duygular, kültürel etkiler, sosyal normlar ve piyasa koşullarından etkilenir.

Hepimizin asla başkalarıyla uyuşmayan değer algılarımız var. Bu nedenle bazı insanlar 10.000.000 TL’lik otomobil satın alıyor ve çoğu almıyor. Daha yüksek maliyette bile bir değer algısı vardır. Her iki tarafın da kendi algısı olsa da değer etrafında hepimizin ortak kanaatler oluşturması gerektiği düşünülürse iş hayatında bu dinamik devreye giriyor. Bu kıyaslama en çok bulut bilgi işlem hizmetlerini seçmek söz konusu olduğunda uygulanabilir ve bu teknoloji sürekli olarak daha olgun ve pahalı hale geldikçe karar vericiler tarafından dikkate alınması giderek daha önemli hale geliyor.

Değeri ve bulut bilişimi anlama

İşletmeler için değer yaratmak, faaliyetlerinin merkezinde yer alır. Amaç, müşterilerinin ihtiyaç ve isteklerini karşılayan ürün veya hizmetler sunarken, ödenen maliyeti veya bedeli aşan bir fayda elde etmektir. Birçoğu buna değer önerisi diyor ve bulut teknolojisi kullanıcıları gibi müşterileri çekmek ve elde tutmak için çok önemli bir geliyor.

Bulut bilişimde, bir değer eğrisi, farklı bulut hizmeti sağlayıcılarının değer önermelerini analiz edebilir ve karşılaştırabilir. Bu durum, her bir sağlayıcının performans, ölçeklenebilirlik, güvenilirlik, güvenlik, maliyet, kullanım kolaylığı ve destek gibi çeşitli nitelikler üzerinden algılanan değerinin değerlendirilmesine yardımcı olmaktadır. Her müşterinin değer algısı, gereksinimlerine bağlıdır. Örneğin, bir banka bulut güvenliğine prim verirken, bir plastik üreticisi vermeyebilir.

Değeri ve bulut bilgi işlem kavramını en iyi şekilde değerlendirmek için, aşağıdaki şekilde nasıl gösterildiğine bakalım. Bu eğriyi, soldan sağa doğru artan maliyetler etrafında modellediğimize dikkat etmenizde fayda var. Ayrıca, hem algı hem de kanıt (gerçek veriler) olan işletmeye sunulan değeri de modellemiş oluyoruz.

_{Değer eğrisi, şirketlerin bulut hizmetlerinin maliyetlerinin sağladıkları iş değeriyle nerede kesiştiğine karar vermesine yardımcı olabilir.}

“Değer”in değer algısı olduğuna dikkat edin; kanıtlara dayalı olarak hesaplandığında, insan algılarından çok daha güvenilirdir. Örneğin, bir bulut sağlayıcısı, ölçülebilen ek maliyetler için artan performansı destekleyebilir. Ancak bu artan performans için işletmenin değeri, maliyetler arttıkça azalabilir. Bir müşteri veritabanında 0,003 saniyeye karşı ,001 saniye süren bir güncellemenin işletmeye eskisi kadar değer sağlamadığını görebiliriz. .002 saniyelik fark, bu belirli şirket için ayırt edilebilir veya çok fazla gerçek değere sahip olmayacaktır.

Bununla birlikte, güncelleme performansı saniyenin 0,010’una yavaşlarsa, ancak daha düşük bir fiyata düşerse, diğer sistemlerin ihtiyaç duyduğu akış hızı veri güncellemelerini geciktirebilir, dolayısıyla üretkenliği ve geliri etkileyebilir. Maliyet daha düşük olsa bile daha az değere sahip olarak sıralanır.

İşletmeler, bu öznitelikleri bir değer eğrisi üzerinde çizerek, her bir sağlayıcının nasıl bir araya geldiğine dair iç görüler elde edebilir ve hangi bulut hizmetlerinin kendi gereksinimlerine en uygun olduğu konusunda bilinçli kararlar alabilir. Örneğin, bir değer eğrisi, A Sağlayıcısının üstün performans ve ölçeklenebilirlik sunduğunu, ancak B Sağlayıcısından daha maliyetli olduğunu gösterebilir. Ancak, B Sağlayıcısı güvenlik ve maliyet etkinliği konusunda üstün olabilir. Gerçek değer açısından hangisinin işletmeyle daha fazla faydası yada ilgisi var?

Çok fazla işletmede, bu kararların çoğunun işe geri döndürülen gerçek değeri anlamaya değil, duygulara ve hatta iç politikaya dayandığını görüyoruz. Böylece şirket, işletmenin belirli bir bulut hizmetinin kullanımından göreceği değeri etkileyen, yeterince optimize edilmemiş kararlar alıyor. Değer bir bulut (finops) programının parçası olarak izlenmezse bunlar genellikle fark edilmez.

Buradaki amacımız, tek bir bulut hizmeti seçerken veya eksiksiz bir bulut mimarisini yapılandırırken değer ölçümleri hakkında düşünmenizi sağlamak. Çoğu işletme için hareketli bir hedef olduğu için değerin sizin için ne anlama gelmesi gerektiğini tanımlamamız mümkün değil. Bununla birlikte, bunun ne anlama geldiğini ve doğru çözümü seçmek için bazı iç süreçlerinizi nasıl değiştirmesi gerektiğini anlamanın hayati önem taşıdığını söyleyebilirim. 

Günün sonunda bir yatırım yaparken yada karar alırken şu sorunun cevabını verebiliyor olmalıyız “Attığımız taş, ürküttümüz kurbağaya değiyor mu ? ”

Barış YILMAZ

Birçok üretici bir çözüm oluştururken, işletmenin zararına olacak şekilde bir teknoloji seçimini diğerine tercih eder. Çünkü onların öncelikleri farklıdır. Şimdi çok daha objektif olmayı öğrenmemizin zamanı geldi.

Günümüzde En çok Yaşadığım Sorun: Makul görünen ama sonunda bir dizi teknolojiye diğerine karşı çok fazla ön yargılı olan kıdemli Bilgi İşlem uzmanlarıyla çalışmak. Bir genel bulutu diğerine, bir veri tabanını veya yapay zeka sistemini diğerine ve hatta genel buluta karşı, şirket içinde barındırmayı tercih eden insanlardan bahsediyorum.

Muhtemelen bunu ilk elden sektör içinde görmüşsünüzdür. Bu karakterdeki kişiler, platformların veya sistemlerin temel gereksinimlerini tartışmadan önce bazı teknolojilerden nasıl yararlanılacağını tartışarak toplantıya başlar. “Bunun amaçlanan yapı için kesin çözüm olması gerektiğini nasıl tespit ettin?” Bu ve benzeri soruyu sorduğumuzda, ya sorduğum için hayal kırıklığına uğradılar ya da sorumu tamamen görmezden gelip üstünde bile durmazlar.

Ön Yargının Doğuşu

Bu tarz kişiler yada ekip üyeleri çok fazla üretici konferansına katıldığını ve belirli bir teknolojinin, genel bulut sağlayıcısının ve hatta mimarinin ne kadar iyi çalıştığı ve bu teknolojinin kararlı kullanıcıları haline geldiği öğretildiğinde yada dayatıldığında bir inanma/kabullenme gibi görünen ama aslında konumuz olan Ön Yargı oluşmasını sağlar.

Burada şöyle bir yanlış anlaşılma oluşmasın; bu durum, belirli bir teknoloji çözümünün yanlış olduğu anlamına gelmez. Ama sorun şu ki, gereksinimlerden çözümlere çalışmaktan vazgeçtik ve şimdi işler tersine dönmüş durumda.

Her şey çalışıyorken sorun yoktur fakat bir problem ya da talep ile karşılaşıldığında bir teknoloji çözüm paketi ortaya koyarsınız ancak, eğer bu paket tamamen optimize edilmiş bir çözüm değilse, yaşam döngüsü boyunca işletmeye milyonlarca liraya mal olacak ve bir noktada çalışmayı durduracak ve düzeltilmesi gerekecektir.

Yeterince optimize edilmemiş çözümler seçmek için başlangıçta hep pozitif geri bildirimler vardır asla bir götü geri bildirim olmaz. Bu nedenle, “Başarı” ilan edilir ve proje lideri, yanlış başarı algısına takiben güçlenen ön yargılarıyla verdiği karar ve çözümlere dayanarak aynı yolda ilerlemeye devam eder. Bu işlevsiz süreç, işleri daha da kötüleştirir ve bir benzetme gerekirse “Teknik anlamda borç yaratır”.

Bu karar verici sistem mimarlarının bir teknoloji yığınını diğerine tercih etmek için masanın altından kesinlikle para aldıklarını söylemiyoruz tabi geneldeki süreç bildiği inandığı çözümün peşinde gitmesidir. Diğer seçeneklere, hatta bulut tabanlı çözümler yerine geleneksel şirket içi çözümlerden yararlanmak veya tam tersi gibi önemli değişikliklere bile akıllarından geçirmediklerinden bahsediyoruz.

Bu bir eğitim/gelişim sorunudur; bulut mimarları yada sorumlu BT Ekipleri diğer seçeneklerle ilgili bilgilerini genişletemiyor ve tek bir çözüm modeline odaklanmasından kaynaklanmaktadır. Ön yargı ayrıca, en fazla reklamı neyin aldığına bağlı olarak genellikle bir çözümü diğerine tercih eden teknoloji basını tarafından da güçlendirilir. Daha eski çözümler genellikle göz ardı edilir ve insanlar bu çözümleri seçmenin trende aykırı olmasından rahatsızlık hissetmesini sağlayacak bir psikolojik ortam oluşur. Unutulan bir konu bir işletmede teknoloji psikoloji ile yönlendirilemez, tamamen reel verilere dayanmalıdır.

Ne yapabilirsin?

Bununla mücadele etmenin en iyi yolu, önce kendi ön yargılarınıza bakmak ve tüm olası çözümleri ve hatta daha az anlaşılanları bile düşündüğünüzden emin olmaktır. Bu makaleyi okuyan birçoğunuz, önce gereksinimleri tam olarak anlamadan, bir teknolojiden diğerine çok hızlı geçtiğinizin farkında bile olmayabilir. 

Bu, hem en iyi duruma getirilmiş çözümlere geçişin doğru süreci hem de orada başka hangi çözümlerin olduğunu görmek açısından bir öğrenme sorunudur. Her teknoloji modelinin olumlu ve olumsuz yanları vardır ve hiçbir şey evrensel olarak uygulanabilir değildir. Bu nedenle, aynı teknoloji çözümünü tekrar tekrar kullandığınızı fark ederseniz, muhtemelen taviz vermiş olursunuz ve teknolojinin bütünsel dünyasını daha iyi anlamanız ve daha katı gereksinimlere ve seçim süreçlerine bağlı kalmanız gerekir.

Son olarak, doğru çözümleri seçerken bu ön yargılara dikkat edin. Ne yaptığınızı anlamadan önce bir teknolojinin en uygun olacağını varsaymak için alanlarında donanımlı insanları aramaktan, sormaktan çekinmeyin. Bir bilgi işlem sürecinin yada yeni yapılacak proje için en iyi olan durum, tamamen optimize edilmiş bir çözüm oluşturup devreye aldığınızda size teşekkür etmeleridir.

Barış YILMAZ

Son on yılda bulut kullanımı arttıkça, bulut kullanıcıları arasında bir öncelik sabit kaldı oda güvenlik. Fakat Bu odak değişiyor.

Flexera, Bulut alt yapısı kullanımı için karar vericilerle ilgili bu zamana kadar yapmış olduğu anketlerde, ilk defa “Güvenlik” konusunda karar almada zorlandıklarını belirtmediler. 8 Mart 2023’te yayınlanan Flexera 2023 Bulut Durumu Raporu’nda açıklandığı gibi , tüm kuruluşlardan yanıt verenlerin %82‘si, bulut harcamalarını yönetme konusundaki en büyük zorluğun, güvenlik odağını %79 oranında geride bırakarak bulut harcamalarını yönetmek olduğunu belirtmişler.

Bu değişen zorluklar, kuruluşların bulut hizmetlerine artan güvenleri ile ilişkili daha büyük harcamaları yönetmeye ihtiyaç duyarken bulut güvenliği konusunda giderek daha rahat hale gelmelerinin bir sonucu olarak yorumlamak doğru bir tanım olacağı kanaatindeyim. Kaynak veya uzmanlık eksikliği, yanıt verenlerin %78’i tarafından en önemli bulut sorunu olarak bildirildi ve bu, günümüz işletmeleri için üçüncü büyük bulut alt yapısı kullanımı sorunu haline geldiğini göstermektedir.

Ankete katılanların yaklaşık yarısı (%45), ekonomik belirsizlik nedeniyle beklenen bulut kullanım ve harcamalarının planlanandan biraz veya önemli ölçüde daha yüksek olduğunu belirttiğinden, bulut maliyet yönetimine odaklanma belki de şaşırtıcı değil. Günümüzün ekonomik dengesizliği, bulutu benimseme ve harcamalar güçlü olmaya devam ederken, işletmelerin ilgili giderlerin, giderek daha fazla göze batması anlamına geliyor.

Yine de kuruluşlar, yenilikçi programlar ve artan gelirlerin peşinde koşmaya devam ediyor. Peki bu buluta güvenmelerini nasıl etkiler? Bu yılın raporu — Flexera’nın bulut kullanıcılarının günümüzün bulut kullanım deneyimlerindeki eğilimleri göstermek için (genel, özel ve çoklu bulut) deneyimlerine ve iç görülerine yönelik 12. yıllık araştırması—dünya genelindeki 750 BT uzmanı ve yönetici liderin yanıtlarından yararlanarak, sektörlerin ve kullanım durumlarının geniş bir kesitini temsil ediyor.

2023’ün en önemli bulut trendlerinden bazılarına bir göz atarak, maliyet bilincine sahip kuruluşların dijital dönüşüm girişimlerini güçlendirmeye nasıl yardımcı olabileceğini ortaya koyuyor.

Buluta güven artmaya devam ediyor

Bulutu benimseme giderek yaygınlaştıkça, tüm iş yüklerinin ve verilerin yarısından fazlası artık genel bulutta bulunuyor. Ankete katılanların yaklaşık üçte ikisi (%65), şirketlerinin genel bulut kullanım düzeyinin yoğun olduğunu belirtiyor (2022 raporundaki %63 olduğuğu için bu oran artmış gözüküyor). 10 kişiden birden fazlası (%11) tek bir genel bulut kullandığını bildiriyor. Ankete katılanların çoğunluğu (%86) çoklu bulut kullanıyor (%12’si birden fazla genel bulut kullanıyor ve %72’si hibrit bulut kullanıyor). Çoklu buluta olan bu güven, geçen yılın bulgularına göre küçük bir düşüş gösterse de hala talep büyük.

Birden fazla bulut kullanan katılımcılar arasında, en çok kullanılan iki çoklu bulut uygulaması, farklı bulutlarda silolara alınmış uygulamalar (%44 rapor edildi) ve olağanüstü durum kurtarma (DR) veya bulutlar arasında yük devretme (%42) oldu. Tüm kuruluşlarda en çok kullanılan çoklu bulut araçları güvenlik araçları olarak göze çarpıyor (%30 ile rapor edilmiştir), ardından maliyet optimizasyonu (finops) araçları (%29) gelmektedir. Kuruluşlar arasında (1.000 veya daha fazla çalışanı olan kuruluşlar), bu araçlara olan güven önemli ölçüde artıyor; %68’i maliyet optimizasyon araçlarını kullanıyor ve %63’ü güvenlik araçlarını kullanıyor.

Genel buluta yapılan harcama, yanıt verenlerin yaklaşık dörtte biri (%24) için yılda 12 milyon doları aşıyor. Ankete katılanların yaklaşık beşte biri (%18) mevcut bulut harcamalarının planlanan bütçelerini aştığını bildirdi. Bulut harcamalarının daha da artmaya devam etmesi bekleniyor ve katılımcıların %30’u bulut harcamalarının önümüzdeki 1 yılda artmasını bekliyor.

Bulutta Hakimiyet Savaşı Devam Ediyor

Amazon Web Services (AWS) ve Microsoft Azure, bulut sağlayıcıları paketinin liderleri olmaya devam ediyor. Liderliklerini diğer rakiplerin önüne geçirirken, pazar liderleri olarak yakın bir rekabeti sürdürdüler. 

2022 raporunda Azure, benimseme oranlarında AWS’yi geçti. 2023’te AWS yine lider durumda: AWS’de önemli iş yükleri çalıştıran kurumsal katılımcıların %46’sı, Azure’da önemli iş yükleri çalıştıranların oranı ise %41. Her kuruluşun bulut kullanım düzeyine dayalı olarak genel bulut sağlayıcısının benimsenmesi, kuruluşların olgunlaştıkça pazar liderlerine doğru yöneldiklerini gösteriyor. AWS, bulutu daha uzun süredir kullanan ve yoğun bulut kullanıcısı olan kuruluşlar tarafından daha sık kullanılmaya devam ediyor.

Şu anda bu sistemleri deneyen veya kullanmayı planlayan yanıtı verenlerin sayısıyla ölçüldüğü üzere, beklenen büyümenin en yüksek miktarını gören genel bulut sağlayıcıları söz konusu olduğunda, Google Bulut Platformu ve Oracle Bulut Altyapısı %28 oranında berabere kaldığı görülüyor.

Bulut Maliyetlerinin Kontrol Edilmesi Bir Zorluk Olmaya Devam Ediyor

Tahmin edilen ve israf olarak görülen bulut harcaması, 2022’de bildirildiği üzere %32’den biraz düşerek %28 seviyesinde araştırmada görülmektedir. Ancak maliyetleri optimize etme ve israfı en aza indirme ihtiyacı devam etmektedir. İş yüklerini genel buluta taşımak, nihayetinde maliyetleri artırabilecek zorluklar sunmaya devam ediyor.

Buluta geçişte karşılaşılan en büyük zorluklar arasında:

• Uygulama bağımlılıklarını anlamak (%49 olarak rapor edildi),
• Teknik fizibiliteyi değerlendirmek (%46 olarak rapor edildi)
• Doğru boyutlandırma veya en iyi bulut sunucusunu seçmek (%42 olarak rapor edildi)

Uygulamaları yönetme ve maliyetleri optimize etme gibi geçiş sonrası zorluklar, bulut maliyetlerini en iyi şekilde optimize etmek için geçiş sürecindeki tüm aşamaları anlamanın önemini de göstermektedir.

Ülkemizde genelde bu maliyetlerin sorumlulukları IT departmanlarının sorumluluklarında kalırken, globalde bu yaklaşım çok daha farklı olduğu görülüyor. Ülkemizde de bu yönde ilerlemeler mevcut ama henüz yeterli değil.

Barış YILMAZ

Her firmanın IT operasyonlarının “Güvenlik” gündemi mutlaka vardır. Bu güne kadar “Güvenlik” kavramı ağırlıklı “Network” yani aslında “Erişim” üzerinden şekillenmiş bunun çevresinde odaklanmıştır. Teknoloji hızla dönüştükçe ve farklı yaklaşımlar ortaya çıktıkça burada da ciddi bir dönüşüm oluşmaktadır. Güvenlik konusunda farklı ürün ve çözümler özelinde ayrıca bir şeyler karalayacağım fakat günümüzde kafa karışıklığı sebep olan “Mikro Servis” güvenliği yada “Konteyner” güvenliği konusudur.

Öncelikle bu kavramları kafalarda netleştirmek için hepimizin bildiği, uyguladığı, dizayn ettiği geleneksel yaklaşımlarımızı bir kenara koyup kıyaslama yapmadan bu konuyu incelemek daha verimli olacağını tecrübe ettiğimi söyleyebilirim.

Mikro Servis mimarisi aslında içinde birden çok süreç ve akış barındıran devamlı yaşayan bir döngü. Bu döngünün içerisinde bizim geleneksel mimaride ayrı ayrı yaşattığımız sürdürdüğümüz bütün süreçler aslında kendi için bölümlenmiş ama tek bir çerçeve altın da birleştirişmiş diyebiliriz. Aşağıdaki görsel algoritmik olarak bu sürecin nasıl işlediğini sade bir bir biçimde aktarmaktadır.

Tarihsel olarak, uygulamaların ve altyapının güvenliğini sağlamak, geliştiriciler (uygulama yazanlar), IT operasyon mühendisleri (uygulamaları dağıtan ve yöneten) ve bilgi güvenliği analistleri (siber güvenlik uzmanları) gibi farklı paydaş türleri arasında işbirliği gerektiriyordu. 

DevSecOps Nedir ? Diye bir açıklama yapmak istersek, DevSecOps güvenliği, yazılım teslim yaşam döngüsünde rol oynayan tüm paydaşların ortak sorumluluğu haline getiren bir stratejidir.

DevSecOps’un temel amacı, güvenliğin bir “Çerçevede” bırakılmak veya sonradan düşünülmek yerine, yazılım tesliminin her aşamasına entegre edilmesini sağlamaktır . Pratikte bu, güvenlik değerlendirmesi ve optimizasyonunun (yazılım tesliminde ilk aşama olan) kodlama sürecinde başladığı ve test, hazırlama, devreye alma ve yönetim süreçleri boyunca devam ettiği anlamına gelir.

Aşağıdaki görsel ile yazı başındaki görseli tamamladığımızda ise aşağıdaki gibi bir güvenlik kapsamı ve işlevleri karşımıza çıkmaktadır. Burada da hem bu yazımda faydalandığım hemde aşağıdaki görseldeki süreci işleten Sysdig ürünü örnek olarak gösterebiliriz.

DevSecOps, DevOps’un temelindeki ilkeleri temel alır . DevOps, geliştiricileri ve IT operasyon mühendislerini, uygulama kalitesini düşürebilecek veya kullanıcı deneyiminin olumsuz etkileyebilecek yanlış iletişimleri ve gecikmeleri önlemek için geliştirme döngüsünün tüm aşamalarında yazılım tesliminin ortak mülkiyetini almaya teşvik eder. DevOps ayrıca yazılım planlama, kodlama, oluşturma, test etme, devreye alma ve yönetim süreçlerini sürekli bir “sonsuzluk döngüsüne” dönüştürmeyi hedefliyor.

Ancak DevOps tek başına güvenliği kapsamaz. 2000’lerin sonlarında DevOps felsefesi ortaya çıktığında, yalnızca geliştirme ve IT operasyonlarını entegre etmeye odaklandı.

DevSecOps, denkleme güvenlik ekleyerek DevOps’u genişletir . DevSecOps’u benimseyen işletmeler, yalnızca geliştiriciler ve IT Ops ekipleri arasındaki işbirliğini değil, aynı zamanda güvenlik uzmanları arasındaki işbirliğini optimize etmeye çalışır. Ve nihayetinde, geliştirme, operasyonlar ve güvenlik arasındaki engelleri yıkmak ve bilgi yaymak için çalışırlar, böylece bu alanlar tek bir paylaşılan uzmanlık alanında birleşir.

Faydalar

Ne tür bir iş yürütürseniz yürütün, DevSecOps, güvenlik sonuçlarını iyileştiren bir dizi temel avantaj sunar:

• Proaktif güvenlik : DevSecOps, güvenlik sorunlarının önüne geçmeyi kolaylaştırır . Başından itibaren güvenli olan uygulama mimarileri tasarlayarak ve yalnızca güvenlik ekiplerini değil, aynı zamanda geliştiricileri ve BT mühendislerini de güvenlik risklerini en iyi nasıl önleyebileceklerine dair kendi bakış açılarını getirmeye hazırlayarak işletmelerin bir tespit-yanıt modelinin ötesine geçmesine yardımcı olur.
• Güvenlik üzerinde ortak mülkiyet : DevSecOps ile, hem güvenlik başarılarının hem de başarısızlıklarının sorumluluğu tüm paydaşlar tarafından toplu olarak paylaşılır . Kültürel bir bakış açısıyla, geliştiricilerin, BT mühendislerinin ve güvenlik ekiplerinin bir ihlal olduğunda birbirlerini suçlamalarından veya aslında tamamen kendi başlarına başaramadıkları güvenlik kazanımlarının hakkını vermelerinden daha sağlıklıdır.
• Kolaylaştırılmış uygulama teslimi : İşletmeler, güvenliği en baştan uygulama teslimine dahil etmek için DevSecOps’u kullandıklarında, güvenlik araçlarının veya süreçlerinin uygulama teslimini yavaşlatma riskini azaltırlar. Örneğin, DevSecOps, güvenlik analistlerinin , uygulamanın devreye alınmasından hemen önce ortaya çıkan bir güvenlik kusurunu tespit etmek için geliştiricilerden uygulama kodunu yeniden yazmalarını istemeyeceği anlamına gelir. DevSecOps ile bu tür sorunlar daha erken ele alınabilir ve bu da daha güvenilir ve tutarlı uygulama teslim döngülerine yol açar.
• Tekrarlanabilir güvenlik süreçleri : DevSecOps, çeşitli paydaşların güvenliğe yaklaşması için sistematik bir yol sağlayarak güvenlik süreçlerinin tekrarlanabilir ve güvenilir olmasına yardımcı olur . Başka bir deyişle, DevSecOps, güvenliği geçici, duruma göre bir işlemden, işletmenin herhangi bir bölümündeki herhangi bir uygulama teslim döngüsüne uygulanabilen sistematik bir süreçler grubuna dönüştürür.
• SBOM görünürlüğü : DevSecOps, güvenlik sürecindeki birden fazla paydaşın etkili bir şekilde birlikte çalışmasına yardımcı olarak işletmelerin, yazılımın tüm aşamalarında yazılım oluşturmaya giden tüm bileşenleri ve kaynakları belgeleyen Yazılım Malzeme Listeleri veya SBOM’lar oluşturmasına yardımcı olabilir.

DevSecOps Nasıl Çalışır?

DevSecOps katı bir uygulama veya araç seti değildir. Bunun yerine, işletmelerin güvenliğe yaklaşım biçimini yöneten bir kavram veya felsefedir. Ekiplerin DevSecOps’u eyleme geçirme şekli, desteklemeleri gereken uygulama türleri ve altyapı ve karşılaştıkları belirli risk türleri veya uyumluluk zorunlulukları gibi faktörlere bağlı olarak değişir. Bu nedenle, ” DevSecOps nasıl çalışır?” sorusuna verilecek evrensel bir yanıt yoktur. “

Ancak ekiplerin DevSecOps’u kullanmaya başlamasına yardımcı olabilecek eyleme dönüştürülebilir yaklaşımlar vardır. DevSecOps’un işletmenizde çalışmasını sağlamak istiyorsanız, genellikle aşağıdaki öğeleri tanımlamanız gerekir:

• DevSecOps hedeflerini belirleyin : Öncelikle, neden DevSecOps’u benimsediğinizi ve özellikle bundan ne elde etmeyi umduğunuzu belirleyin. Örneğin, güvenlik sorunları tarafından tetiklenen daha az yazılım teslim gecikmesi mi yoksa toplam güvenlik ihlallerinde bir azalma mı? DevSecOps’un hedefleri bir işletmeden diğerine değişir, bu nedenle DevSecOps’a başlamak için kendi hedefinizi belirlemek önemlidir.
• Bir DevSecOps çerçevesi oluşturun : Bir DevSecOps çerçevesi, DevSecOps’a yaklaşımınızı yönetecek belirli prosedürleri ve kuralları tanımlar. Örneğin, DevSecOps çerçeveniz, Kod Olarak Altyapı (IaC) şablonlarının içlerindeki güvenlik açıklarını önlemek için nasıl yapılandırıldığına ilişkin ilkeler oluşturabilir. Veya bir uygulamanın dağıtılmadan önce hangi otomatikleştirilmiş güvenlik testlerinden geçmesi gerektiğini tanımlayabilir.
• DevSecOps süreçlerini başlatın : Bir DevSecOps çerçevesine sahip olduğunuzda, belirli DevSecOps süreçlerinin sorumluluğunu üstlenecek belirli ekip üyelerini atayarak bunu eyleme geçirebilirsiniz .
• DevSecOps’u Ölçün : Bir DevSecOps girişimi başladıktan sonra, girişimin başarısını sürekli olarak ölçmek en iyi uygulamadır. DevSecOps hedeflerinizi ne kadar iyi karşıladığınızı belirlemek ve zaman içinde DevSecOps etkinliğindeki değişiklikleri ölçmek için ölçümler toplayın.

Güvenlik Araçları

Her kuruluşun DevSecOps yolculuğu benzersiz olduğundan, her işletmenin ihtiyaç duyduğu evrensel bir DevSecOps araçları seti yoktur. Ancak, genel olarak, çoğu DevSecOps girişimi, DevSecOps araçlarının aşağıdaki temel kategorilerinden yararlanacaktır:

• Statik uygulama güvenlik testi (SAST) : SAST çözümleri, bir uygulamanın içeriğini tarayarak ve değerlendirerek uygulama kaynak kodundaki ve ikili dosyalardaki kusurları ve güvenlik açıklarını belirlemeye yardımcı olur. SAST, bir uygulama dağıtıma doğru ilerlemeden önce riskleri yakalamak için yazılım tesliminin ilk aşamalarında en kullanışlıdır.
• Yazılım bileşimi analizi (SCA) : SCA araçları, kullandığınız açık kaynak paketleri veya modüller gibi üçüncü taraf yazılımların bileşenlerini tanımlamanıza yardımcı olur. DevSecOps için SCA, üçüncü taraf bağımlılıklarının diğer uygulamalara entegre edilmeden önce güvenli olmasını sağlamaya yönelik önemli bir araç türüdür.
• Dinamik uygulama güvenlik testi (DAST) : DAST araçları, uygulamaların statik sürümlerini incelerken ekiplerin gözden kaçırmış olabileceği güvenlik açıklarını ve zayıflıkları tespit etmek için canlı uygulamalara karşı güvenlik testleri gerçekleştirir.
• Etkileşimli uygulama güvenlik testi (IAST) : IAST, hem SAST hem de DAST öğelerini birleştiren daha yeni bir güvenlik aracı kategorisidir. Genel olarak, IAST araçları riskleri belirlemek için (bu onları DAST’a benzer kılar) dinamik güvenlik testi kullanır, ancak aynı zamanda riskleri onları tetikleyen kaynak koduna (bu da onları SAST’a benzer kılar) kadar izlemeye çalışır.

Belirli ortam türlerini destekleyen DevSecOps ekipleri ek araçlar kullanmak isteyecektir. Örneğin, bulut iş yükleri için Bulut Güvenliği Duruş Yönetimi (CSPM) araçları, bulut ortamlarına güvenlik riskleri getirebilecek yapılandırma hatalarını tespit etmek için kullanışlı araçlardır, bu araçları kullanılabilir. Aynı şekilde, Kubernetes üzerinde dağıtılan iş yükleri için DevSecOps ekipleri, ayrıcalıklı konteynerler gibi Kubernetes mimarisine özgü riskleri tespit edebilen güvenlik araçlarından yararlanmalıdır.

Sysdig Secure

Barış YILMAZ

Kuruluşlar, Kubernetes tarafından yönetilen iş yükleri için HCI’yı giderek daha fazla benimsiyor. HCI üzerinde Kubernetes çalıştıran kuruluşlar 2020’de %29‘dan 2021’de %45‘e sıçrayarak önemli bir artış gösterdi. Birçoğu, Kubernetes’ten HCI’yı benimseme planlarını gerçekleştiriyor ve ardından bunu en sık olarak uç konumlarda dağıtıyor gibi görünüyor. HCI, modern uygulamaları kompakt bir form faktöründe çalıştırmak için gereken tüm özellikleri sağladığından, bu trendlerin devam edeceğine inanıyoruz.

Bu yapılan araştırmalara baktığımızda aslında karmaşık olan mikro servis mimarilerinin bu dezavantajını HCI yapıları sayesinde ciddi manada ortadan kaldırdığı ortaya konmuştur. Ek olarak mikro servis mimarisinin ana çıkış mottosu olan kaynak optimizasyonu ve ihtiyaca göre büyüme hedefleriyle birebir örtüştüğü için bu trend uzun bir süre aynı ivme kesinlikle artacaktır.

Barış YILMAZ