90 milyon aktif kullanıcısı olan GitHub, hem açık kaynak hem de özel kurumsal kod havuzları için en popüler kaynak kodu yönetim aracıdır. Temel altyapının önemli bir parçasıdır ve dünyadaki en hassas varlıkların ve verilerin bazılarının koruyucusudur.
Saldırganların giderek daha fazla kaynak kodunun peşinden gitmesi şaşırtıcı değil. Okta gibi bazı durumlarda kaynak koduna erişmeye çalışıyor olabilirler. Daha sıklıkla, saldırganlar bir sonraki saldırıda kullanmak üzere hassas bilgiler ararlar.
Özel kaynak koduna erişim sağlayabilen bir saldırgan, bu güvenlik açıklarını inceleyebilir ve sonraki saldırılarda bu güvenlik açıklarından yararlanabilir. Saldırganlar, Amazon Web Services (AWS), Microsoft Azure veya Google Cloud Platform’da (GCP) barındırılan bulut hizmetlerine ve veritabanlarına erişim elde etmek için GitHub’da depolanmış olabilecek sabit kodlanmış anahtarları, parolaları ve diğer kimlik bilgilerini de toplayabilir. Çalınan tek bir havuz, fikri mülkiyet, geçerli kimlik bilgileri ve üretim yazılımında istismar edilmeye hazır güzel bir güvenlik açıkları listesi sağlayabilir.
Özellikle özel GitHub depolarını hedef aldığı bilinen bir saldırı grubu olan Shiny Hunters, bu tekniği kullanarak birden fazla şirketi ihlal etti ve verilerini çeşitli Dark Web pazarlarında sattı.
Kuruluşun GitHub Ortamının Güvenliğini Sağlama
GitHub’ın kuruluşun altyapısının kritik bir parçası olduğuna şüphe yok, ancak onu kilitlemek karmaşık ve zorlu bir kimlik güvenliği sorunu. GitHub modelinin güzelliği, sınırsız işbirliğine izin vermesi, ancak aynı zamanda modern BT güvenliğindeki en büyük baş ağrılarından birini yaratmasıdır.
Bir düşünün: 2022’de uzaktan teknik bilgiye sahip herkesin bir GitHub hesabı var. GitHub hesabınızı her şey için kullanabilirsiniz. Bu hesapları kişisel yan projeler, açık kaynak katkıları ve nihai olarak işverenlerimize ait olan kamu ve özel kod havuzlarındaki çalışmalarımız için kullanabiliriz. Bu, tek bir kimlik için çok ağır bir yük!
GitHub kimliğinizi yalnızca GitHub’ın kendisi dışındaki diğer web sitelerinde ve hizmetlerde kullanmak için “GitHub ile oturum aç” özelliğini de kullanabilirsiniz. Ve dahası da var: GitHub, yalnızca web sitesinde oturum açmamanız; Ayrıca HTTPS ve SSH üzerinden GitHub kimliğinizi gerektiren git işlemleri aracılığıyla GitHub’ın sunucularından yerel makinenize kod çeker, gönderir ve klonlarsınız.
Açıkça GitHub, geçen yıl git işlemleri için kullanıcı adlarının ve parolaların kullanımdan kaldırıldığını açıkladığında bu güvenlik uygulamalarını fark etti – doğru yönde atılmış bir adım.
GitHub’ınızı Güvenli Hale Getirmek İçin 7 İpucu
GitHub, ortamı kilitlemek için araçlar sağlarken kuruluşların bunları nasıl kullanacaklarını bilmesi gerekir. Ne yazık ki, en önemli güvenlik özelliklerinden bazıları GitHub Enterprise gerektirir. Bununla birlikte, daha iyi GitHub güvenliği için yedi ilkeyi burada bulabilirsiniz.
- İş için kişisel hesaplara izin vermeyin. Anlıyoruz, şirketinizin birkaç halka açık deposu var ve bir sonraki iş görüşmenizde bazı kamu katkılarını göstererek güvenilirliğinizi artırabilirsiniz. Kişisel GitHub hesabınız, markanızın bir parçasıdır. Ne yazık ki, bu aynı zamanda bugün GitHub kullanan kuruluşlardaki en büyük boşluklardan biridir: Kişisel hesapların iş amaçlı kullanımını katı bir şekilde düzenlemezler. Ne kadar cazip gelse de, kişisel hesaplar iş için kullanılmamalıdır. Kişisel GitHub hesabınızı oluşturmak için kullandığınız kişisel Gmail adresine kimlerin erişebileceğini kontrol etmenin hiçbir yolu yoktur.
- Şirket SSO’su aracılığıyla kimlik doğrulaması gerektir. Ne yazık ki GitHub, SSO Utanç Duvarı’nda belirgin bir şekilde görünüyor. Bu doğru — çoklu oturum açma (SSO) entegrasyonu için fazladan ödeme yapmanız gerekiyor. GitHub Enterprise’a sahip olduğunuzda, GitHub’ı şirketinizin Okta, Azure AD veya Google Workspace gibi SSO’suna bağlayabilir ve yalnızca SSO aracılığıyla kimlik doğrulamaya izin vermek için kuruluşunuzu kilitleyebilirsiniz.
- Tüm hesaplarda 2FA gerektir. SSO’nuz aracılığıyla iki faktörlü kimlik doğrulamayı (2FA) zorunlu kılsanız ve ayrıca SSO kimlik doğrulaması gerektirseniz bile, en güvenli seçenek kuruluşunuzdaki tüm GitHub kullanıcıları için 2FA’yı zorunlu kılmaktır. TOA sağlayıcınızdaki muafiyet grupları ve ilke istisnaları, SSO MFA’nın atlanmasını kolaylaştırabilir.
- Git işlemleri için SSH Anahtarlarını kullanın. GitHub, kişisel erişim belirteçleri (PAT’ler) ile ayrıntılı izin denetimi sunmuş olsa da, bu belirteçler genellikle düz metin olarak kopyalandığından kimlik avına açık olmaya devam ediyor. Kuruluşunuz, git işlemleri için kimlik doğrulama amacıyla SSH anahtarlarını kullanarak, SSH anahtarlarının nasıl sağlanacağını yönetmek için dikkatli PKI kullanabilir. Ayrıca bunu şirketinizin cihaz yönetimine ve kendi sertifika yetkilinize (CA) bağlayabilir.
- Rolleri kullanarak havuz üyesi ayrıcalıklarını kısıtlayın. GitHub, en az ayrıcalık ilkesine göre atanabilen birkaç farklı havuz rolü sunar. Temel izinler kuruluş düzeyinde kontrol edilebilir. Her zaman bir üyenin üretken olması için ihtiyaç duyduğu en az ayrıcalıklı rolü atamaya özen gösterin. Herkesi yönetici yapmayın.
- Dışarıdan ortak çalışanlara izin vermeyin. Yüklenicilerle çalışmak, büyük yazılım projelerini yönetmenin normal bir parçasıdır. Ancak, GitHub’da dışarıdan ortak çalışanları çevreleyen yönetişim, kuruluşunuzu güvende tutmak için yetersizdir. Bunun yerine, dışarıdaki ortak çalışanları şirketinizin SSO’su aracılığıyla kimlik doğrulaması yapmaya zorlayın ve havuz yöneticilerinin onları doğrudan kuruluşunuzun havuzlarına davet etmesine izin vermeyin.
- Denetle, analiz et ve yeniden denetle. Hiçbir organizasyon mükemmel değildir; En iyi politikalar yürürlükte olsa bile, hesaplar çatlaklardan düşer ve hatalar yapılır. GitHub kuruluşunuzu kilitlemeden önce bile, erişimini kullanmayan atıl hesapları aramak ve depolarınızdaki ayrıcalıklı rol sayısını sınırlamak için düzenli bir denetim süreci uygulamaya zaman ayırın. Ortamınız kilitlendikten sonra, SSO’nuzun dışında bir şekilde kimlik doğrulaması yapan veya 2FA kullanmayan bir kullanıcı gibi ilke ihlallerine dikkat edin.
Okta’nın GitHub deposunun ihlali, kuruluşlardaki kimlikleri korumanın ne kadar zor olduğunun güçlü bir örneğidir, ancak benzersiz değildir. Her gün, çalışanlar ve yükleniciler hesap devralma yaşadıklarında ne olduğunu görüyoruz. Zayıf kimlik doğrulamanın, kişisel e-posta hesapları için gevşek politikaların ve kimlik saldırısı yüzeyinin sürekli genişleyen boyutunun etkilerini görüyoruz.
Ne yazık ki, bu son olay, 2023’te izlenmesi gereken, artan kimlikle ilgili ihlal eğiliminin yalnızca bir parçası.