GitGuardian ve CyberArk’ın araştırmasına göre, BT karar vericilerinin %79’u bir sır sızıntısı yaşadığını bildirdi; bu oran önceki yılın raporunda %75’ti. Aynı zamanda, yalnızca halka açık GitHub depolarında 12,7 milyondan fazla sabit kodlanmış kimlik bilgisi ile sızdırılan kimlik bilgilerinin sayısı hiç bu kadar yüksek olmamıştı. Bu raporun en rahatsız edici yönlerinden biri, bulunan ve bildirilen geçerli sırların %90’ından fazlasının 5 günden fazla geçerli kalmasıdır.
Aynı araştırmaya göre kuruluşların sızdırılan kimlik bilgilerini düzeltmesi ortalama 27 gün sürüyor. Bunu, insan olmayan kimliklerin sayısının insan kimliklerinden en az 45:1 daha fazla olduğu gerçeğiyle birleştirirseniz, birçok kuruluşun neden sırların yayılmasını durdurmanın bu makine kimliği kriziyle başa çıkmanın bir yolunu bulmak anlamına geldiğini fark ettiğini anlamak kolaydır. Ne yazık ki araştırma, birçok ekibin bu kimliklerin güvenliğinin kime ait olduğu konusunda kafasının karıştığını da gösteriyor. Bu mükemmel bir risk fırtınasıdır.
Rotasyon Neden Bu Kadar Uzun Sürüyor?
Peki, kimlik bilgilerinin rakipler için en kolay saldırı yollarından biri olduğunu bildiğimiz halde neden kimlik bilgilerini döndürmek bu kadar uzun sürüyor? Buna katkıda bulunan en önemli faktörlerden biri, kimlik bilgilerimize nasıl izin verildiğine ilişkin netlik eksikliğidir. İzinler, Kubernetes iş yükü veya mikro hizmet gibi bir varlığın başka bir hizmetten veya veri kaynağından başarılı bir şekilde talep edebileceği belirli şeylere yetki veren şeydir.
Sırların yayılması olayının iyileştirilmesinin ne anlama geldiğini hatırlayalım: Herhangi bir şeyi bozmadan veya şirketinize daha fazla güvenlik riski getirebilecek yeni, çok geniş izinler vermeden bir sırrı güvenli bir şekilde değiştirmeniz gerekir. İnsan olmayan kimliklerinizin ve bunlarla ilişkili sırların yaşam döngüsü hakkında zaten tam bir içgörüye sahipseniz, bu, onları aynı izinlere sahip yeni sırlarla değiştirmek için oldukça basit bir işlemdir. Zaten bu bilgiye sahip değilseniz, bu oldukça zaman alabilir; çünkü bunu ilk olarak oluşturan geliştiricinin hala orada olmasını ve ne yapıldığını belgelediğini ummanız gerekir.
NHI’lerin hakim olduğu ortamlarda izin yönetiminin neden özellikle zorlayıcı olduğuna bakalım, geliştiricilerin ve güvenlik ekiplerinin erişim kontrolü ile üretkenliği dengeleme konusunda karşılaştığı zorlukları inceleyelim ve ortak sorumluluk modelinin nasıl yardımcı olabileceğini tartışalım.
Sırların Yayılmasının Gerçek Sahibi Kim?
Sırların yayılması genellikle erişim anahtarlarının, parolaların ve diğer hassas kimlik bilgilerinin geliştirme ortamları, depolar ve Slack veya Jira gibi hizmetler genelinde çoğalması anlamına gelir. GitGuardian’ın en son Uygulayıcıların Sesi raporu, katılımcıların %65’inin iyileştirme sorumluluğunu doğrudan BT güvenlik ekiplerine yüklediğini vurguluyor. Aynı zamanda, BT liderlerinin %44’ü geliştiricilerin sır yönetimi için en iyi uygulamaları takip etmediğini bildirdi.
Sırlar yayılıyor ve aşırı izin verilen uzun ömürlü kimlik bilgilerinin altında yatan sorunlar, ortak bir sorumluluk modelinde birlikte nasıl daha iyi çalışabileceğimizi bulana kadar bu boşluğa düşmeye devam edecek.
Geliştiricinin İzinlere İlişkin Bakış Açısı
Geliştiriciler, özellikleri hızla oluşturup dağıtma konusunda büyük bir baskıyla karşı karşıyadır. Ancak izinleri en iyi güvenlik uygulamalarıyla dikkatli bir şekilde yönetmek yoğun emek gerektirebilir. Her proje veya uygulamanın sıklıkla kendine özgü erişim gereksinimleri vardır; bunlar araştırmak ve doğru şekilde ayarlamak zaman alır; bu da, uygulamaların yapımı ve dağıtımının yanı sıra neredeyse tam zamanlı bir iş gibi hissettirir. İzinlerin oluşturulmasına ve yönetilmesine yönelik en iyi uygulamalar genellikle ekipler arasında eşit şekilde uygulanmaz, nadiren uygun şekilde belgelenir veya geliştirici uygulamayı çalıştırdıktan sonra tamamen unutulur.
Pek çok durumda geliştiricilerin bu makine kimliklerine çok geniş izinler vermesi sorunu daha da karmaşık hale getiriyor. Bir rapor, verilen izinlerin yalnızca %2’sinin gerçekten kullanıldığını buldu. Neyle karşı karşıya olduklarını daha yakından incelersek bunun nedenini anlamak kolaydır.
Örneğin Amazon Web Services içindeki izinleri yönetmeyi düşünün. AWS’nin Kimlik ve Erişim Yönetimi (IAM) politikaları esneklikleriyle bilinir ancak aynı zamanda gezinmesi de karmaşık ve kafa karıştırıcıdır. IAM, tümü hassas yapılandırmalar gerektiren çeşitli politika türlerini (kimlik tabanlı, kaynak tabanlı ve izin sınırları) destekler. AWS ayrıca kimlik bilgileri için IAM rolleri ve KMS (Anahtar Yönetim Hizmeti) yetkileri dahil olmak üzere her biri kendi benzersiz erişim yapılandırmalarıyla birlikte gelen birden fazla erişim yolu sunar. Bu sistemi öğrenmek küçük bir başarı değildir.
İzinlerin yönetilmesinin zorlaşabileceği bir hizmetin diğer bir yaygın örneği GitHub’dur. API anahtarları, çeşitli kuruluşlardaki veri havuzlarına izinler verebilir, bu da uygun erişim sınırlarının sağlanmasını zorlaştırır. Geliştiricilerin birden fazla kuruluşun üyesi olduğu durumlarda tek bir anahtar, ortamlar arasında istemeden aşırı erişim sağlayabilir. Zaman her zaman işliyor ve birikmiş işler büyümeye devam ederken, işi doğru yapmak için baskı devam ediyor.
Neden Güvenlik Ekipleri Tek Başına Bunu Düzeltemiyor?
Sırların izlenmesi ve döndürülmesi konusunda güvenlik ekiplerine sorumluluk vermek mantıklı görünebilir; sonuçta bu bir güvenlik endişesidir. Gerçek şu ki, bu ekipler genellikle güvenli bir şekilde değişiklik yapmak için gereken proje düzeyindeki ayrıntılı bilgiden yoksundur. Güvenlik ekipleri, uygulamaları çalışır durumda tutmak için hangi belirli izinlerin gerekli olduğunu anlayacak bağlama her zaman sahip olmayabilir. Örneğin, görünüşte küçük bir izin değişikliği, bir CI/CD hattını bozabilir, üretimi kesintiye uğratabilir ve hatta yanlış hizmetin ortadan kalkması durumunda şirket çapında kademeli bir arızaya neden olabilir.
Sır yönetiminin ekipler ve ortamlar arasında dağınık yapısı da saldırı yüzeyini artırır. Gerçekten sorumlu kimse olmadığında erişim kontrollerinde ve denetim izlerinde tutarlılığı korumak çok daha zor hale gelir. Bu parçalanma genellikle aşırı veya güncel olmayan kimlik bilgilerine ve bunlarla ilişkili izinlerin çok uzun süre, muhtemelen sonsuza kadar etkin kalmasına neden olur. Herhangi bir zamanda kimin hangi sırlara meşru veya gayri meşru erişime sahip olduğunu bilmeyi zorlaştırabilir.
Daha Hızlı Rotasyon İçin Ortak Sorumluluk Modeli
Geliştiriciler ve güvenlik ekipleri ortada buluşarak ve ortak bir sorumluluk modeli oluşturarak bu sorunların çözülmesine yardımcı olabilirler. Böyle bir modelde geliştiriciler, CyberArk’ın Conjur Secrets Manager’ı veya HashiCorp’un Vault’u gibi uygun araçlarla izinlerini tutarlı bir şekilde yönetmekten daha fazla sorumlu olurken, aynı zamanda proje düzeyinde gerekli izinlerin izinlerini ve kapsamını daha iyi belgeliyor. Güvenlik ekipleri, sırların rotasyonunu otomatikleştirmek için çalışarak, sırların durumuna açıklık getirmek için uygun gözlemlenebilirlik araçlarına yatırım yaparak ve uzun ömürlü kimlik bilgilerini tamamen ortadan kaldırmak için BT ile birlikte çalışarak geliştiricilere yardımcı olmalıdır.
Geliştiricilerin gereksinimlerinde hangi izinlerin gerekli olduğunu açıkça belgelemesi, güvenlik ekiplerinin daha hızlı ve daha kesin denetimler yapmasına ve düzeltmeleri hızlandırmasına yardımcı olabilir. Güvenlik ekipleri, yeni bir insan dışı kimlik sırrını uygulamaya yönelik en kolay ve en hızlı genel yolun aynı zamanda en güvenli ve en ölçeklenebilir yol olmasını sağlamak için çalışırsa, acil durum rotasyonu gerektiren olaylar çok daha az olacak ve herkes kazanacak.
Geliştiricilerin hedefi, güvenlik ekibinin, uygulamalarının kimlik bilgilerini kendi başlarına, üretimi tehlikeye atmayacaklarını bilerek, güvenle döndürebilmelerini veya güncelleyebilmelerini sağlamak olmalıdır.
İzin Alma Konusunda Ele Alınacak Temel Sorular
Neyin belgelenmesi gerektiğini düşünürken, bu ekipler arası çabanın daha sorunsuz ilerlemesine yardımcı olacak birkaç spesifik veri noktasını burada bulabilirsiniz:
- Kimlik Bilgisini Kim Oluşturdu? – Pek çok kuruluş, özellikle bir anahtar paylaşıldığında veya rotasyona tabi tutulduğunda, kimlik bilgilerinin sahipliğini takip etmekte zorlanır. Bu bilgi, kimlik bilgilerinin döndürülmesinden veya iptal edilmesinden kimin sorumlu olduğunu anlamak için gereklidir.
- Hangi Kaynaklara Erişiyor? – API anahtarları genellikle veritabanlarından üçüncü taraf entegrasyonlara kadar çeşitli hizmetlere erişebilir, bu da izinlerin gereken mutlak minimum değerle sınırlandırılmasını zorunlu hale getirir.
- Hangi İzinleri Veriyor? – İzinler rollere, kaynak tabanlı politikalara ve politika koşullarına bağlı olarak büyük ölçüde değişiklik gösterir. Örneğin, Jenkins’te, ‘Genel/Okuma’ iznine sahip bir kullanıcı genel bilgileri görüntüleyebilirken ‘Genel/Yönetim’ sistem üzerinde tam kontrol sağlar.
- Nasıl İptal Edebiliriz veya Döndürebiliriz? – İptalin kolaylığı platforma göre değişir ve çoğu durumda ekiplerin sistemlerdeki anahtarları ve izinleri manuel olarak takip etmesi gerekir, bu da düzeltmeyi karmaşık hale getirir ve tehditlere maruz kalma süresini uzatır.
- Kimlik Bilgisi Aktif mi? – Bir kimlik bilgisinin hâlâ kullanımda olup olmadığını bilmek kritik öneme sahiptir. NHI’ler uzun ömürlü API anahtarları kullandığında, bu kimlik bilgileri uygun şekilde yönetilmediği sürece süresiz olarak etkin kalabilir ve kalıcı erişim riskleri oluşturabilir.
İzinler Zorludur Ama Bunları Tek Ekip Olarak Yönetebiliriz
GitGuardian raporuna göre ankete katılanların %75’i sır yönetimi yeteneklerine güvendiklerini ifade etse de gerçek genellikle çok farklı. 27 günlük ortalama iyileştirme süresi, güven ile uygulama arasındaki bu boşluğu yansıtıyor. Bir kuruluş olarak sırları ve bunların izinlerini nasıl uygulayacağımızı ve ileteceğimizi yeniden düşünmenin zamanı geldi.
Geliştiriciler güvenlik ve işlevselliği dengelemek için özenle çalışırken, kolaylaştırılmış izin süreçlerinin ve merkezi olmayan veya standartlaştırılmamış belgeleme yollarının eksikliği yalnızca riskleri artırır. Güvenlik ekipleri, projeye özgü ihtiyaçlara ilişkin sınırlı içgörüleri nedeniyle bu sorunları tek başına etkili bir şekilde çözemez. Yolun her adımında geliştiricilerle el ele çalışmaları gerekiyor.
GitGuardian, yeni nesil gizli güvenlik araçlarını oluşturarak güvenlik ve BT ekiplerinin gizli sırların yayılmasını önlemesine yardımcı oluyor. Kodunuzda ve diğer ortamlarda hangi düz metin, uzun ömürlü kimlik bilgilerinin açığa çıktığını bilmek, bu tehdidi ortadan kaldırmak için gerekli bir ilk adımdır. GitGuardian’la bugün başlayın.