Ticari açık kaynağın ilk günlerinde, büyük satıcılar şeffaflığın bir kusur olduğunu iddia ederek güvenliğinden şüphe uyandırdı. Aslında, bu açıklık güçlü toplulukları ve daha hızlı güvenlik iyileştirmelerini körükledi ve OSS’yi tescilli koddan daha güvenli hale getirdi.
Bugün, Fud’un tersi yeni bir tür yanlış bilgilendirme ortaya çıktı: gerçek açık kaynak güvenlik risklerini küçümsüyor zorunlu Endişeyi artırın.
Bugünkü en büyük güvenlik yanlışlığı, Linux ad alanlarının güvenlik sınırları olmasıdır.
Tek sunuculardan paylaşılan çekirdeklere
Buraya nasıl geldik?
Güvenlik sınırları, tek sunuculardan Linux makinelerinin kümelerine iş yüklerini paylaşan evrimden bu yana büyük bir akışta olmuştur. Kubernetes fiili bulut işletim modeli haline gelmiştir ve platform mühendisliğine modern yaklaşımlar, altyapının altında yatan (aka, “çoklu kiracılık”) paylaşım örnekleri etrafında düzenlenmiştir.
Ancak bugün oynanan güvenlik zorlukları Kubernetes öncesi onlarca yıldır.
İnternet yeni olduğu 90’larda, barındırma web siteleri dağıtılmış sistemler için ilk büyük kullanım durumlarından biriydi. CGI komut dosyaları – web sunucuları ve harici veritabanları arasında iletişim için bir standart – dağıtılmış sistem güvenliği için hızla aşırı kullanım durumu haline geldi.
Paylaşılan barındırma ortamlarında keyfi kod çalıştırmak hemen yeni risk sınıflarını ortaya çıkaran bir güvenlik karşıtı olarak kabul edildi. Böylece, barındırma sağlayıcılarının Linux VServer, FreeBSD hapishanesi ve CGI komut dosyalarının sahip olabileceği ev sahibi sistemlere erişimi azaltmak için yeni yaklaşımlar gibi teknolojilere yatırım yapmasına neden oldu.
Bir bakıma, kapların başladığı yer burası. Endüstri, bu teknolojileri henüz yazılım dağıtım açısından düşünmüyordu, ancak cGI komut dosyaları çalıştıran ve izolasyon sınırları oluşturma girişimleri için bu temel gün bir güvenlik sorunundan geliyor.
2004 yılında EC2’nin piyasaya sürülmesiyle ve bulut-yerli hesaplamaya yönelik ilk büyük kilometre taşları ile, konteynerlere ve hapis cezalarına yaklaşım, piyasa EC2 görüntülerini tercih ettiği ve sanal makineler ve cihaz uygulama teslimi X86, üç katmanlı mimari için standart ücret haline geldi.
Docker geldiğinde, uygulama sunumunda en son teknolojiyi bozdu, geliştiriciye verimliliğe büyük bir destek verdi ve geliştiricilerin DEVOP desenlerini tanıtarak hesaplama kaynakları için “sormak” zorunda kalmadıklarını ortadan kaldırdı.
Ancak Docker’ı yazılım dağıtım yöntemi olarak kullanma hareketiyle, endüstri, Web’in 90’lı yıllarda karşılaştığı bu orijinal güvenlik sorununa geri döndü. Uygulamaların ve geliştiricilerin kaynakları birbirlerinin ayak parmaklarına basmadan nasıl paylaşmalarına izin verilecekleri sorusu artık sadece web sitesi sunucularıyla değil, bugün tüm İnternet ve kritik iş sistemlerini etkili bir şekilde çalıştıran modern, konteyner bulut paradigmasıyla sınırlı değildi.
Ad alanlarının asla güvenlik sınırları olması gerekmiyordu
Konteynerizasyonun yükselişiyle, ad alanları süreç ve kaynak izolasyonu sağlamak için birincil mekanizma haline geldi. Ad alanları, bir işlemin dosya sistemi, ağ yığını veya kullanıcı kimlikleri görünümü gibi neyi görebileceğini veya erişebileceğini sınırlayarak ayırma yanılsaması oluşturur.
Bu yanılsama, kaynak yönetimi ve hafif çoklu kiracılık için etkili olmakla birlikte, genellikle bir güvenlik sınırı olarak yanlış yorumlanmıştır ve konteyner ortamlarının gerçekte ne kadar güvenli olduğunun tehlikeli bir şekilde fazla tahmin edilmesine yol açar.
Gerçekte, Linux’taki ad alanları, süreçler için çekirdek kaynaklarını bölmek için mekanizmalardır. Gerçek güvenlik ayrılmasını zorlamıyorlar. Tüm kapsayıcılar aynı temel Linux çekirdeğini paylaşır ve ad alanları belirli çekirdek kaynaklarına erişimi sınırlayabilirken, süreçlerin izole bağlamlarından kaçma olasılığını ortadan kaldırmazlar. Örneğin, çekirdekteki güvenlik açıkları, diğer kapları ve hatta ana bilgisayarın kendisini etkilemek için bir ad alanındaki bir işlemle kullanılabilir.
Ad alanları, bir kale duvarı değil, geliştiriciler için kolaylık bir soyutlamadır. Yalnızca farklı ad alanlarına sahip süreçler olan kaplar, bu zayıflığı devralır, böylece bir güvenlik sınırı tarafından hem teknik olarak yanlış hem de tehlikeli bir şekilde yanıltıcı oldukları varsayımını yapar.
Tüm kaplar tek bir çekirdek üzerinde çalıştığında, bu çekirdekteki herhangi bir güvenlik açığı tüm sistem için tek bir arıza noktası haline gelir. Bu, tüm iç kapıları içeriden açılabilir bırakırken aynı evdeki farklı odalara birden fazla kiracı anahtarı vermek gibidir.
Sanallaştırma ile ilgili sorunu kağıt alamazsınız
Güvenlik şüpheciliğinin evlat edinmeyi bastırmaya çalışmak için kullanıldığı erken açık kaynak döneminden, satıcıların güvenliğin en zor problemi üzerinde kınadığı günümüze tam bir daire geldik.
Günümüzde çoğu konteyner güvenlik stratejisi, zaten çatlamış bir vakfın üstünde duvarlar oluşturuyor. Ad alanında veya Syscall filtreleme katmanında izolasyonun çözülmesi, alçıpanın yapısal bir kusur üzerinde yama yapmak gibidir. İhtiyaç duyulan temel yeniden düşünmektir. Sorunu yığının en düşük katmanında ele alan bir yaklaşıma ihtiyacımız var.
Güvenlik satıcılarının “sanal” terimini sanal makinelere atıfta bulunur veya kapsayıcıların içindeki “sanal iş yükleri” olarak adlandırılan güvenlik izolasyonu önermek için kullanılan bir yakalama olarak kullanmaları şık bir pazarlama haline gelir. Ancak sanallaştırmanın semantiği mimari garantilerinin yerini alamaz.
Sanal bir makine, çekirdek de dahil olmak üzere tüm donanım yığınını soyutladığı için güçlü bir izolasyon sağlar. Konteynerler, aksine, sadece aynı ana bilgisayar çekirdeğinde çalışan işlemlerdir – kaç ad alanı sargısı katmanlı olursa olsun. “Sanal” bir şeyi etiketlemek, özellikle paylaşılan bir çekirdeğin üstüne bindiğinde onu güvenli hale getirmez.
Gerçek izolasyon, kuruluşunuzun çok kiracılık güvenlik geleceği için kazanmanız gereken en önemli mimari savaştır. Namespace tabanlı güvenlik izolasyonunun gerçek olduğuna inanan uyurgezerler arasındaysanız, uyanma zamanı.