Kaynak koduna gömülü sırlar, geliştiriciler ve çalıştıkları kuruluşlar için risk oluşturur. Sırlar, hem kullanıcı hem de hizmet hesaplarını ele geçirmek için kullanılabilir ve bu da hassas verilerin açığa çıkmasına, operasyonel risklere ve finansal veya itibarsal zarara yol açabilir.
Sabit kodlanmış sırları tespit etmek için kullanılabilecek birçok ticari ve açık kaynak projesi vardır, ancak açığa çıkan sırları kaldırarak, gizleyerek veya döndürerek hafifletmek son derece zordur. Örneğin, bulut ortamınızdaki bir hizmete bağlı bir sırrın döndürülmesi, söz konusu hizmetin sırrın algılanmadığı başka bir kod tarafından tüketilmesi durumunda uygulamanız genelinde hizmet reddine neden olabilir. Bu, sır bir sır yönetimi hizmetinde güvenli bir şekilde saklansa bile geçerli olabilir.
Bir kaynak kodu deposunda sırlara sahip olma riski, sırrın bu depoyu klonlayan diğer kullanıcılara anında açık olmasıdır. Deponun git geçmişindeki dosyalar veya taahhütler taranarak tüm tarihsel sırlar tespit edilebilir.
Bu nedenle, sırları dosyalarda veya git geçmişinde açığa çıkmadan önce hafifletmek daha arzu edilen bir yaklaşımdır. Ardışık hatsız güvenlik, sırları kaynak kodu havuzlarından uzak tutarak “sıfır yeni sabit kodlanmış sır” politikası uygular.
Sabit Kodlanmış Sırlar Geleneksel Olarak Nerede Tespit Edilir?
Tipik bir kod teslim akışı, bir geliştiricinin kod deposunun en son sürümünü klonlaması veya indirmesi ve yerel depoda değişiklikler yapmasıyla başlar. Kod değişikliklerini uzak depoya geri göndermek genellikle bir dizi kontrol ve tarayıcı başlatır; örneğin GitHub, Checks API’yi desteklerken Azure DevOps, hizmet web kancalarını destekler. Yeni özellikler (veya düzeltmeler) üretime dağıtılmadan önce, geliştiricinin kod dalının ana dalla birleştirilmesi gerekir; bu, genellikle uygulamanın düzgün şekilde çalışmasını sağlamak için başka bir kontrol ve yapı/CI ardışık düzenini tetikler. birleştirmek. Örneğin, kod birleştirildikten sonra işlem hattını hızlandırmak için kapsayıcı derlemeleri şu anda gerçekleşebilir.
Gizli tarama kontrolleri, geliştirici iş akışında birkaç yerde uygulanabilir: IDE eklentileri, ön taahhüt kancaları, ön alım kancaları, tarayıcıya web kancaları ve CI/CD ardışık düzeni. Her yöntemin artıları ve eksileri vardır.
IDE eklentileri. Geliştiriciler kod yazarken sırlar taranabilir. Git geçmişine işlenmiş sırlardan kaçınmaya yardımcı olmak için etkili bir yaklaşımdır, ancak mühendislik organizasyonlarındaki çeşitli IDE araçları ve sürümleri nedeniyle, geliştiricilerin %100’ünün bunu kullanacağını garanti etmek zordur. Bu yaklaşım, herhangi bir istemci tarafı güvenlik denetimi için ciddi bir dezavantaj olan, geliştiricilerin bu denetimi atlayabileceği anlamına gelen bir zorlama yeteneğinden yoksundur.
Ön taahhüt kancaları. Otomatik betikler, kod yerel git geçmişine işlenmeden önce çalışır. Bu kontrol, IDE eklentileriyle aynı artılara ve eksilere sahiptir. Ek olarak, bir çekme isteğinde önerilen kod değişikliklerinden kaynaklanan taahhütler, geliştirici tarafından kabul edilirlerse taranmayabilir.
Ön alma kancaları. Bunlar, taahhüt öncesi kancalar gibidir, ancak kaynak kodu yönetimi (SCM) tarafında çalışırlar. Bu da %100 kapsama ulaşılabileceği anlamına gelir. Ancak, GitHub gibi bulut tabanlı tekliflerin sağlayamadığı temel işletim sistemine yönetici erişimi gerektirirler.
Tarayıcıya web kancaları. Bu, %100 kapsama da sağlayabildiği için etkili bir yaklaşımdır. Web kancaları, push olaylarının başarılı bir şekilde yürütülmesini engelleyemese de, hızlı bir şekilde teslim edilirler ve hem bulutta hem de şirket içi dağıtımlarda kolayca dağıtılabilirler, bu da onları çok popüler kılar. GitHub Checks API’sinin sonuçlarının depoya erişimi olan tüm kullanıcılar tarafından görülebildiğini unutmayın; bu, bir sır açığa çıkarsa diğerlerinin de öğreneceği anlamına gelir.
Boru hattı. Veri havuzlarının %100’ünü tarayan sırları uygulamak zordur çünkü işlem hatları genellikle kod değişiklikleri gerektirir. Ek olarak, bir koşucunun bir işi başlatması ve yürütmesi zaman alır, bu da acil gizli hafifletme söz konusu olduğunda onu daha az etkili hale getirir. Web kancalarında olduğu gibi, ardışık düzenlerin sonuçları havuza erişimi olan tüm kullanıcılar tarafından görülebilir.
‘Sıfır Yeni Sabit Kodlanmış Sırlar’ Nerede Gelir?
Sıfır yeni sır kavramı oldukça basittir. Böyle bir politikayı uygulayan bir hizmetin aşağıdakiler göz önünde bulundurularak oluşturulması gerekir:
- Gizli hafifletme hizmetinize abone olun: tüm depolardaki tüm önemli olaylarör. kod gönderme, çekme istekleri ve denetim etkinliklerine abone olun.
- Başlamak bant dışı otomatik git tabanlı korkuluklarbir dalı önceden itilmiş duruma sıfırlamak gibi.
- Sağlamak kod iticiye izole geri bildirim, en düşükte. Yeni gizli bulgunun gereksiz kullanıcılara sunulmadığından emin olun.
Bu aynı zamanda ardışık düzensiz güvenlik olarak da bilinir. Ardışık düzensiz bir uygulamada, bir dizi kontrol ve hizmet, kod uzak havuza gönderilirken gizli dizi algılamayı işler. Geliştirici, kodu yerel şubeden uzak depoya ittiğinde, gizli algılama komut dosyasını çalıştıran ardışık düzensiz güvenlik hizmetine bir web kancası gönderilir. Herhangi bir sır bulunmazsa, kod normal şekilde gönderilir.
Ancak, bir sır algılanırsa hizmet, dalı push öncesi durumuna sıfırlar. Bu şekilde, sırları içeren taahhütlere, havuzun taahhüt geçmişini kurcalayan rakipler erişemez. Geliştirici daha sonra özel olarak bilgilendirilir ve değişikliklerin nasıl yedekleneceği ve kodun düzeltilebilmesi için nasıl getirileceği konusunda talimatlar verilir – hem sabit kodlanmış gizli ifşa riskini en aza indirmek hem de geliştiricinin herhangi bir lekelenmesini önlemek için.
Ardışık düzensiz bir yaklaşımla etkinleştirilen sıfır yeni sabit kodlu sır ilkesi, geliştiriciler geçmiş sırların birikmiş iş yükünü çözmek için çalışırken yeni sırların açığa çıkmasını önlemede etkili olabilir. Böyle bir politika, %100 kapsam, yeni iletilen gizli dizileri saniyeler içinde azaltma yeteneği ve kodu gereksiz taraflara ifşa etmeden harekete geçmesi için geliştiriciye doğrudan geri bildirim sunar.