Bir SaaS Özelliği Olarak Güvenlik Nasıl Yerleştirilir: Bir Kılavuz

Bu yazıda size bir SaaS platformuna ve platformundan daha ayrıntılı ve daha güvenli bağlantıyı nasıl sağlayacağınızı göstereceğim. Nihai sonuç, SaaS platformunun doğal bir uzantısı gibi görünen ve hissettiren bütünsel bir çözümdür ve ya kurumsal odaklı planlar için bir özellik olarak ya da tüm müşterilerinize rekabette fark yaratan bir unsur olarak sunulur. Demoyu çalıştırmak için gereken toplam süre yalnızca birkaç dakikadır. Ayrıca sihrin nasıl çalıştığını açıklamak için perde arkasında olup bitenleri derinlemesine inceleyeceğim.

Öncelikle bu özel ihtiyacın neden ortaya çıktığına dair biraz bilgi vereyim ve geleneksel uygulamalardaki eksiklikleri vurgulayayım. Çünkü o eski yaklaşımlar artık işe yaramıyor.

Güvenliği bir özellik olarak düşünmeye başlamanız gerekir. Mühendislikten sorumlu başkan yardımcısıysanız, ürün yöneticisiyseniz, ürün sahibiyseniz güvenliğe zaman ayırın, geliştiricilerinizin daha iyi, daha güvenli bir altyapı oluşturmasına izin verin.

— Joel Spolsky , Stack Overflow'un Kurucusu

Önümüzdeki on yılın en başarılı ürünleri, statükocu yaklaşımların artık yeterince iyi olmadığının farkına varanlar olacak. Bunun için Joel'in sözüne de güvenmenize gerek yok; Apple'ın yakın zamanda duyurduğu Özel Bulut Bilişiminin ayrıntılarını okuyun. Son yirmi yılın en başarılı şirketlerinden biri güvenlik, gizlilik ve güvenin temel fark yaratan unsurlar olacağını net bir şekilde ifade ediyor.

Hatta TLS gibi protokollerin mevcut kullanımının, müşterilerin beklemesi gereken uçtan uca güvenlik ve gizlilik garantilerini nasıl sağlayamadığını bile tartışıyorlar.

Yıllar önce, kariyerimin ilk aşamalarında yoğun emek gerektiren bir iş olan sistemleri birbirine bağlama üzerinde çalıştım. Şirketimiz büyüyordu ve mevcut binadaki sunucu odasını yeni binaya yeni kurduğumuz sisteme ekleyecektik. Yeni ofis caddenin birkaç blok aşağısındaydı ve özel bir hat kurmak için yerel telekomünikasyon şirketiyle birlikte çalışıyorduk.

O zamanlar iki ayrı ağı birbirine bağlamanın açık ve fiziksel olarak somut bir gerçekliği vardı.

Hepimiz o günlerden yola çıktık. Artık modern teknoloji yığınları daha karmaşıktır; Tüm dünyaya yayılmış, "türünün en iyisi" ürün şirketleri tarafından bulutta çalıştırılan bir dizi birbirine bağlı uygulama. Onlarca yıl boyunca geliştik. Bugün, iki ayrı şirketin aslında tüm ağlarını birbirine bağlamak istemesi nadirdir; her ağdaki belirli uygulamalar ve iş yüklerinin iletişim kurması gerekir.

Yine de sistemlerimizi "güvenli" bir şekilde bağlamanın bir yolu olarak eski yaklaşımları kullanmaya devam ettik.

Kabloların asıl işleyişi ortadan kaldırıldı, ancak biz neredeyse aynı şeyi yapıyoruz. Bu eski yaklaşımlar sizi geçici olarak sayılamayacak kadar çok sayıda ağa maruz bırakır; bu da sömürülmeye hazır muazzam bir saldırı yüzeyidir.

Özel Bir Sisteme Bağlanma İhtiyacı

İnsanların "bulut" veya "şirket içi" derken neyi kastettikleri geçtiğimiz on yılda bulanıklaştı. Herhangi bir karışıklığı önlemek için bizim için varsayımsal bir senaryo oluşturacağım:

• Initech Platformu: Sizin işlettiğiniz bir SaaS platformudur. Esnek ve ölçeklenebilirdir ve büyük bulut sağlayıcılarından birinde barındırılır. Müşteriler, bir dizi yararlı ölçüm üzerinde görünürlük sağladığı ve doğrudan geliştirme iş akışlarına yararlı geri bildirimler sağladığı için DevOps süreçlerini iyileştirmek için platformu satın alıyor.

• ACME Corp: Bu, Initech'in desteklemek istediğiniz büyük bir müşterisidir. Çeşitli yerlerde çok sayıda altyapı işletiyorlar. Klasik anlamda kendi veri merkezlerinin içinde olma anlamında "şirket içi" mi? Büyük bulut sağlayıcılarından birinin kendi VPC'sinin içinde mi? Önemli değil! Müşteri sistemleri, Initech'in kontrol etmediği, erişimimizin olmadığı ve genel internetten doğrudan erişilemeyen bir veya daha fazla ağda çalışıyor.

Geliştirici İş Akışlarında Proaktif Katılım

Initech Platformunun ilk versiyonunu oluştururken, ürün pazarına uygunluğunu kanıtlamak için birlikte çalışılacak çok sayıda potansiyel müşteri var. Başlıca sürüm kontrol sistemi sağlayıcılarının (örneğin, GitHub, GitLab, Bitbucket vb.) genel API'leriyle entegre olacak, olaylara tepki vermek için taahhüt/web kancalarını kullanacak, sonuçları iş akışına aktaracak ve her şey beklendiği gibi çalışacak.

Ürün pasif olduğunda ve ACME Corp'taki bir kişi tarafından başlatılan olaylara basitçe tepki verdiğinde bu harikadır. Birçok hizmet, dünyadaki dış değişiklikleri değerlendirerek ve müşterileri için iyileştirmeler sağlama konusunda proaktif davranarak değer sağlamak ister.

Birçok bağımlılık veya güvenlik tarama hizmetini düşünün; yeni bir güvenlik açığının ifşa edilmesi durumunda, etkilenen tüm depolarda mümkün olan en kısa sürede bir çekme/birleştirme isteği oluşturmak isterler. Genel API'lere sahip tam olarak yönetilen VCS hizmetleri, bunu etkinleştirmenin yollarını sağlar, ancak bu ürünlerin kendi kendine barındırılan sürümleri, genel olarak erişilebilen bir API'ye sahip değildir.

Bu sistemleri kendi kendine barındırmayı tercih eden müşteriler genellikle büyük işletmelere yöneliyor, bu nedenle şimdi bazı zor kararlarla karşı karşıyayız: Initech, ürünlerini bu yüksek değerli müşterilere satamayacak mı? Müşteriler, ürünün en değerli özelliklerinden birinin eksik olduğu, küçültülmüş bir versiyonunu satın almak zorunda mı kalıyor? Yoksa onlardan Initech'e erişim sağlamak için güvenlik ve ağ oluşturma duruşlarının bazı yönlerini yeniden değerlendirmelerini mi istiyoruz?

Özel Verilere Erişim

Initech'in özel raporlama çözümünü görüntülemek için bir veritabanını sorgulaması gerekiyor. Neredeyse her Müşteri Veri Platformu (CDP) veya görselleştirme aracında aynı sorun olduğundan bu, Initech'e özgü bir sorun değildir: Müşteriler, özel verilerini genel internetten erişilebilir kılmak istemezler, bu nedenle genellikle bir özel bir alt ağdaki veritabanı.

Güncel Yaklaşımlarımızın Sorunları

Daha önce de söylediğim gibi, modern teknoloji yığınları bir dizi birbirine bağlı uygulamaya dönüştü. Ancak bu uygulamaları birbirine bağlama şeklimiz, onlarca yıl önce ağları birbirine bağlama şeklimize göre yalnızca çok az değişti. Bu yaklaşımlar kullanışlı ve tanıdık olsa da hiçbir zaman bugün sahip olduğumuz kullanım durumları için tasarlanmamıştır.

Bunun yerine, bugün işlerin nasıl yürümesi gerektiğine yaklaşmak için, işlerin eskiden çalışma biçiminde mümkün olan en küçük değişiklikleri yapmaya çalışıyorlar.

Sistemleri Kamu İnternetine Yerleştirme

Çoğu özel sistem için varsayılan dağıtım seçeneği, bunları genel IP adresi olmayan, özel bir alt ağa sahip özel bir ağda konumlandırmaktır. Bunun çok iyi nedenleri var! Initech'in bu özel sisteme bağlanmasının en kolay yolu ACME Corp'tan internetten erişilebilen genel bir IP adresi veya ana bilgisayar adı sağlamasını istemek olacaktır.

Bu kötü.

Bir sistemi başlangıçta dünyayla bağlantısı olmayan özel bir ağa yerleştirmenin tüm iyi nedenleri anında ortadan kalkar. Bu sisteme artık tüm halka açık internet üzerinden erişilebiliyor ve bu da binlerce potansiyel korsanın sürekli olarak sisteme girmeyi denemesine ve kaba kuvvetle girmesine veya basitçe DoS yapmasına olanak tanıyor. Sızdırılan tek bir kimlik bilgisi, CVE veya sahiplenilmeye başka bir konu kadar uzaktasınız.

Ters Proxy'ler

Diğer bir yaklaşım ise sistemin önüne ters proxy koymaktır. Sadece nginx ve HA Proxy gibi bir şeyden bahsetmiyorum; Bu tanıma uyan çok sayıda barındırılan veya yönetilen hizmet kategorisi de vardır.

Bunun avantajı, ACME Corp'un artık özel bir sistemi doğrudan halka açık internete koymamasıdır. Ters proxy ayrıca potansiyel DoS saldırılarını azaltmak için hız sınırlaması veya erişim kısıtlamalarına ince ayar yapma yeteneği de ekler. Bu, derinlemesine bir savunma iyileştirmesidir, ancak ACME Corp, hâlâ tüm halka açık internetin proxy'ye erişmesine ve ona saldırmaya çalışmasına izin veriyor.

Güvenliği ihlal edilirse, proxy'nin yaptığını yapar: Trafiğin amaçlanan hedefe geçmesine izin verir.

IP İzin Listeleri

Initech'in istek göndereceği IP'lerin bir listesini sağlaması ve ACME Corp'un güvenlik duvarını ve yönlendirme kurallarını yalnızca bu IP adreslerinden gelen isteklere izin verecek şekilde yönetmesini sağlaması, Initech'in artan bir iyileştirmesidir. Ancak bu pek de bir gelişme değil.

Initech'te mevcut uygulama örnekleriniz ve IP adreslerinizle sıkı bir bağlantıya sahip olmak istemeyeceksiniz; Müşterileri sürekli olarak yeni IP adresleri konusunda bilgilendirmeye gerek kalmadan altyapıyı gerektiği gibi ölçeklendirebilme esnekliğine sahip olmak isteyeceksiniz.

Dolayısıyla IP adresleri büyük olasılıkla bir NAT ağ geçidine veya proxy sunucusuna ait olacaktır. ACME Corp, erişimi yalnızca bir veya iki kaynak IP adresine kilitlemenin yalnızca bir veya iki uzak makinenin ağlarına erişebileceği anlamına geldiğini varsayabilir.

Gerçek şu ki, uzak ağdaki NAT ağ geçidi veya proxy aracılığıyla istek gönderebilen her şeye artık ACME Corp ağına da erişim izni verilecek. Bu, tek bir uygulamanın veya makinenin girmesine izin vermiyor; Uzak bir ağın tamamına izin verdiniz.

Daha da endişe verici olanı, IP kaynak adreslerinin önemsiz derecede sahtekarlık yapmasıdır. Potansiyel bir saldırgan, iyi biçimlendirilmiş bir istek oluşturabilir, kaynak adresini taklit edebilir ve ACME Corp ağına veri veya talimat gönderebilir. Initech dahil SaaS satıcıları da kaçınılmaz olarak mevcut IP adreslerinin listesini belgelemek zorundadır, böylece denenecek ve taklit edilecek hazır bir IP listesi bulunur.

IP filtrelemeye yaklaşımınız ne kadar karmaşıksa, bir saldırganın onu tehlikeye atmak için o kadar karmaşık olması gerekir, ancak bunların hiçbiri mükemmel değildir. Geçmişte insanların IP sahtekarlığının aslında yalnızca DDoS saldırıları için olduğunu, çünkü çoğu durumda saldırganın yanıt alamayacağını ve dolayısıyla yararlı bir şey yapamayacağını iddia ettiğini duydum.

Bağladığımız sistemleri düşünün; değerli verileri görev bilinciyle oluşturmayacak/güncelleştirmeyecek/yok etmeyecek sıfır ateşle ve unut API çağrısının bulunduğundan ne kadar eminsiniz? İyi güvenlik, verilerin açığa çıkmasını önlemekten daha fazlasıdır; aynı zamanda onu korumak ve bütünlüğünü garanti altına almakla da ilgilidir.

Büyük bir finans kurumu gibi değerli bir hedefseniz, saldırganların MitM saldırıları başlatmak ve iletişim akışlarını engellemek için bu gibi yaklaşımları kullanma motivasyonu vardır. Müşterileriniz, potansiyel müşterileriniz ve değerli hedefleriniz varsa, bu sizi de değerli bir hedef haline getirir.

Sanal Özel Ağlar (VPN'ler)

VPN'ler, çalışanların ofis dışındayken "kurumsal ağa" bağlanmalarına olanak tanıyan birçok şirkette yaygın bir çözümdür. Ayrıca diğer sistemlerin mevcut bir ağa bağlanmasına izin vermek için de kullanılırlar.

Burada bahsettiğimiz kullanım durumu farklıdır. Bu, iki ayrı şirketin, bir SaaS ürününün ve müşterilerinin birbirleriyle iletişim kurabilmesine izin vermekle ilgilidir.

Bu durumların çoğunda, bağlantının her iki ucunda birbiriyle konuşabilmesi gereken yalnızca bir sistem vardır. Bunun yerine, tüm ağları birbirine bağlamak için tasarlanmış bir araca ulaşıyoruz. Bu, bir şirketteki yönlendiriciden diğer şirketteki yönlendiriciye sanal bir yama yönlendirmesi çalıştırmak gibidir.

Eğer sizden bunun fiziksel versiyonunu yapmanızı, yani üretim ortamınızdaki bir kabloyu doğrudan başka bir şirketin üretim ortamına bağlamanızı isteseydim, muhtemelen buna biraz ara verirdiniz. Çok fazla duraklama. Ve iyi bir sebepten dolayı. Ancak VPN'ler "sanal" ve "özel"dir ve çok kolaydır (kabloyu çalıştırmaya kıyasla) ve o kadar her yerde bulunurlar ki, üzerinde pek düşünmüyoruz.

Yapmanız gereken tek şey, her ağa bir şeyi bağlamaksa, çok kesin olması gereken bir görev için çok kör bir araç kullanmışsınız demektir.

Kesin görevi hala bir VPN kullanarak yapabilirsiniz, ancak her ağda yalnızca açılmasını istediğiniz kapının tüm kapılarını kapatmak için yürürlükte olduğundan emin olmanız gereken ağ düzeyinde kontrol katmanları ve yönlendirme kuralları vardır. Bu, tasarlandıkları amaçta mükemmel olan araçlara ve yaklaşımlara sahip olduğumuzun bir başka örneğidir, ancak onları gelişen ihtiyaçlarımızla çalışmaya zorlamak için bunları nasıl kullandığımız konusunda giderek artan adımlar atıyoruz.

Bunu güvenli bir şekilde yapmak, daha karmaşık katmanlar oluşturmak ve bu katmanlardaki tüm ayrıntıları her zaman doğru şekilde elde edeceğimizi ummak anlamına gelir. Yanlış anlaşılması, asıl niyetin ötesinde geçişli erişim risklerini taşır.

Ağa Güvenemezsiniz

Güvenlik programınıza ne kadar zaman, insan ve para yatırırsanız yatırın, ağınızın neredeyse kesinlikle kolaylıkla istismar edilebilecek bir güvenlik açığına maruz kalacağını söylesem ne dersiniz? …

Sektör verileri, dünyanın en büyük işletmelerinin %1'inden azının, ağlarını bu yeni ve ortaya çıkan tehdide karşı korumak için henüz herhangi bir adım atmadığını gösteriyor…

Tarih bize yapılacak doğru şeyin, yapılması en kolay şey olması gerektiğini öğretti. Bu, özellikle yazılım geliştiriciler ve kasıtlı olarak kötü amaçlı bileşenlerden koruma açısından kritik öneme sahiptir. Güvenlik teknolojisine yönelik bu yavaş benimseme eğrisi, kötü aktörlerin potansiyeli görmesine, yenilik yapmasına ve siber suçların olağanüstü büyümesine yön vermesine etkili bir şekilde olanak sağladı

— Mitchell Johnson , Sonatip

Bu yaklaşımların her birindeki sorun, güvenli olduğunu varsaymanın birçok ek varsayım gerektirmesidir: İnternetteki hiç kimsenin sizi tehlikeye atmaya çalışmayacağı, isteklerin kaynak IP'sine güvenebileceğiniz, uzak ağın yalnızca iyi aktörlerden oluştuğu. , bu varsayımların hem şimdi hem de gelecekte süresiz olarak doğru olmaya devam edeceğini… ve tüm bu varsayımların aynı zamanda bağlandığınız her ağ, bağlandıkları tüm ağlar ve tüm ağlar için de geçerli olduğunu…

ACME Corp'un bakış açısından bunun nasıl görünebileceğine bir göz atın:

Artık birbirine bağlı olan yalnızca iki ağ ve iki şirket değil; birçok ağ var. Her SaaS satıcısının kullandığı kendi hizmet seti olacaktır ve bu da bunu daha da artırır. Sadece ağa güvenmemekle kalmaz, başkalarınınkine de güvenemezsiniz. Bu resimdeki herhangi bir katılımcı, bu riski ağ(lar) üzerinden iletmekten yalnızca bir ağ yanlış yapılandırması veya tehlikeye atılmış bağımlılıktan uzaktır.

Ve bu resim bu problemin fraktalının en yakınlaştırılmış örneğidir! Uzaklaştığınızda her satıcı kendi müşteri grubuna, kendi satıcılarına, kendi müşterilerine bağlanır... risk yüzey alanı katlanarak büyür.

Öyleyse Hadi Çözelim!

Birkaç dakika içinde güvenliği ürünümüze bir özellik olarak ekleyebiliriz! Daha odaklı ve ayrıntılı bir çözüm sunarak güvenlik çıtasını yükselteceğiz. Ayrıca ACME Corp gibi müşterilerden ağ düzeyinde değişiklikler yapmalarını isteyerek sorunları onlara yüklemeyi de bırakacağız.

Bunun yerine, güvenli bağlantıyı uygulama düzeyindeki bir soruna kaydıracağız ve Initech Platformunu olması gereken belirli yerlere genişleterek bütünsel bir ürün deneyimi sunacağız.

Buradaki örnekte, Initech Platform'un, ACME Corp tarafından yönetilen, şirket içinde barındırılan bir GitHub Enterprise sunucusuyla nasıl bağlantı kurabileceği anlatılacaktır. Nihai sonuç şöyle görünecektir:

Gerekli tüm parçaları döndürmek yalnızca birkaç dakika sürer! Bunu nasıl yapacağınızı öğrenmek için, kendi kendine barındırılan aracının temelini oluşturmaya yönelik kod turumuza göz atın.