Geçen ay, düşük kodlu/kodsuz platformların bir hizmet olarak kimlik bilgisi paylaşımını nasıl sunduğu, bunu neden yaptıkları ve bunun nasıl göründüğü hakkında bir makale yazdım. saldırganın bakış açısı. Bu makalede, bu uzlaşmanın etkilerine ve günümüzde işletmeleri nasıl etkilediğine odaklanacağım.
Kurumsal kimlik bilgilerinizi başka biriyle paylaşmanın kötü bir uygulama olmasının nedeni işte budur. Diyelim ki, bir kerelik kullanıcı davranışı analizi için üretim günlüklerini sorgulamak üzere kimlik bilgilerimi bir meslektaşıma iletmek istiyorum. Tipik bir kuruluşta, birisine yeni bir veri kaynağını sorgulama izni vermek, özellikle üretim veya hassas veriler söz konusu olduğunda, uzun bir erişim inceleme süreci anlamına gelebilir. Meslektaşım kolayca hüsrana uğrayabilir. “Tek istediğim bu küçük tek seferlik sorguyu yapmaktı ve şimdiden bir aydır bekliyorum!” diyebilirlerdi. Sorguyu onlar için çalıştırabilirim, ancak kendi günlük görevlerim arasında sıkışıp kaldım ve tek seferlik sorgular karmaşıklaşıyor.
Elimde hızlı bir çözüm kaldı: Kullanıcı adımı/şifremi meslektaşımla paylaşabilirim. Bir MFA mücadelesi alırlarsa, memnuniyetle onaylarım. Sorguyu çalıştırmak için zaman harcamak zorunda değilim ve iş arkadaşımın engellemesi kaldırılıyor. Herkes kazanır! Doğru?
Analizinizde haklısınız ama büyük resmi kaçırıyorsunuz. İş arkadaşınızın kullanıcı davranışı analizini yaptırması kuruluş için önemli olsa da, kuruluşunuzun bir dizi gizlilik ve güvenlik standardı ile uyumlu kalması ve şirketin güvenlik taahhüdünü koruyarak müşteri güvenini sürdürmesi eşit derecede önemlidir. .
Üst düzey kurumsal hedefler sizi ikna etmiyorsa, BT veya güvenlikteki merkezi yönetim ekiplerini düşünün. Bu ekipler, operasyonlarını ve güvenlik stratejilerini, her kullanıcının kendi benzersiz kimliğine sahip olduğu gerçeğine dayandırır. BT ekipleri, her kullanıcının aynı anda bir kurumsal IP’den veya kurumsal dizüstü bilgisayardan oturum açacağını varsayan ağ ve erişim ilkeleri oluşturuyor; güvenlik ekipleri, olayları kullanıcı kimliğine göre ilişkilendiriyor; finans ekipleri, kullanıcı ve kişisel bulut ortamı başına maliyet raporlarını toplayabilir. Kimlik bilgisi paylaşımı, diğerlerinin yanı sıra tüm bu varsayımları baltalar. Çevrimiçi kimliğin temel anlamını ortadan kaldırır.
Gerçek Dünyadan Bir Örnek
Düşük kodlu/kodsuz dünyasına dönelim ve gerçek dünya senaryosunu inceleyelim. Büyük bir kuruluşta, müşteri hizmetleri ekibinden ilham alan bir çalışan olan Jane, kuruluştaki çalışanlar bir müşteri vakasında yer aldığında, genellikle müşteriyle ilgili destek vakası geçmişi ve en son satın alma işlemleri gibi önemli bilgileri kaçırdıklarını fark etti. Bu, müşterinin deneyimini bozar, çünkü müşteri, vaka sorunu çözebilecek doğru çalışana yönlendirilirken sorunlarını tekrar tekrar açıklamak zorunda kalır.
Bunu geliştirmek için Jane, şirket çalışanlarının, müşterinin destek yazışmasını ele almaktan sorumlu ekibin bir parçası olduklarında, müşterilerle ilgili bu önemli bilgileri görüntülemelerine olanak tanıyan bir uygulama oluşturdu. İlk olarak, Jane’in bir bütçe istemeden veya BT kaynak tahsislerini beklemeden bir ihtiyacı belirlemesine ve kendi başına ele almasına olanak tanıyan düşük kodlu/kodsuz sistemin gücünü kabul etmek için bir dakikanızı ayıralım.
Uygulamayı oluştururken Jane, en büyük sorun izinler olmak üzere birden çok sorun üzerinde çalışmak zorunda kaldı. Kuruluştaki çalışanlar, ihtiyaç duydukları bilgileri almak için müşteri veritabanını sorgulamak için doğrudan erişime sahip değildir. Yapsalardı, Jane’in bu uygulamayı oluşturması gerekmeyecekti. Bu sorunun üstesinden gelmek için, Jane veritabanına giriş yaptı ve kimliği doğrulanmış oturumunu doğrudan uygulamaya yerleştirdi. Uygulama bir kullanıcıdan istek aldığında, bu sorguyu yürütmek için Jane’in kimliğini kullanır ve ardından sonuçları kullanıcıya döndürür. Bu kimlik bilgisi yerleştirme özelliği, geçen ay keşfettiğimiz gibi, düşük kodlu/kodsuz platformların önemli bir özelliğidir. Jane, uygulamada her kullanıcının yalnızca atandığı müşteri vakalarına erişebileceği şekilde rol tabanlı erişim denetimi (RBAC) kurduğundan emin oldu.
Uygulama, önemli bir iş sorununu çözdü ve böylece kuruluş genelinde hızlı bir şekilde kullanıcı benimsemesini sağladı. İnsanlar, konuşma için doğru bağlama sahip olarak müşterilerine daha iyi hizmet verebildikleri için mutluydular. Müşteriler de mutluydu. Jane uygulamayı oluşturduktan bir ay sonra, müşteri memnuniyet oranlarının artmasıyla birlikte, kuruluş genelinde yüzlerce kullanıcı tarafından kullanılmaya başlandı.
Bu arada SOC’de, üretim müşteri veritabanı çevresinde anormal aktivite gösteren yüksek önemde bir uyarı tetiklendi ve deneyimli bir güvenlik analisti olan Amy’ye atandı. Amy’nin ilk araştırması, dahili bir kullanıcının tüm veritabanını sıyırmaya çalıştığını ve kuruluş genelinde birden fazla IP adresinden birden fazla müşteri hakkında bilgi sorguladığını gösterdi. Sorgu kalıbı çok karmaşıktı; bir veritabanı kazınırken görmeyi beklediğiniz basit bir numaralandırma modeli yerine, aynı müşterinin verileri, bazen farklı IP adresleri aracılığıyla ve farklı tarihlerde birden çok kez sorgulandı. Bu, güvenlik izleme sistemlerini karıştırmaya çalışan bir saldırgan olabilir mi?
Hızlı bir araştırmadan sonra, Amy çok önemli bir bilgiyi ortaya çıkardı: Tüm IP adresleri ve tarihlerindeki tüm bu sorgular, müşteri hizmetleri ekibinden Jane adında biri olan tek bir kullanıcı kimliği kullanıyordu.
Amy, neler olduğunu sormak için Jane’e ulaştı. İlk başta, Jane bilmiyordu. Kimlik bilgileri çalındı mı? Yanlış bağlantıya mı tıkladı yoksa yanlış gelen e-postaya mı güvendi? Ancak Jane, Amy’ye yakın zamanda yaptığı uygulamadan bahsettiğinde, ikisi de bir bağlantı olabileceğini anladı. SOC analisti Amy, düşük kodlu/kodsuz konulara aşina değildi, bu yüzden AppSec ekibine ulaştılar. Jane’in yardımıyla ekip, Jane’in başvurusunda Jane’in kimlik bilgilerinin gömülü olduğunu anladı. Veritabanının bakış açısından, hiçbir uygulama yoktu – sadece Jane vardı, bir sürü sorgu yürütüyordu.
Jane, Amy ve AppSec ekibi, bir çözüm bulunana kadar uygulamayı kapatmaya karar verdi. Kuruluştaki uygulama kullanıcıları, uygulamaya güvenmeye başladıkları için hüsrana uğradı ve müşteriler de bunu hissediyordu.
Amy konuyu kapatıp bulgularını belgelese de, müşteri hizmetleri başkan yardımcısı müşteri memnuniyet oranındaki düşüşü görmekten memnun değildi, bu yüzden Jane’den kalıcı bir çözüm aramasını istediler. Jane, platformun belgeleri ve kuruluşun Mükemmellik Merkezi ekibinin yardımıyla, gömülü kimliğini uygulamadan kaldırdı, uygulamayı her kullanıcının kimliğini kullanarak veritabanını sorgulamak için değiştirdi ve kullanıcıların yalnızca ilişkili oldukları müşteri vakaları için izin almalarını sağladı. . Yeni ve geliştirilmiş versiyonunda uygulama, müşteri veritabanını sorgulamak için her kullanıcının kimliğini kullandı. Jane ve uygulama kullanıcıları, uygulamanın tekrar çevrimiçi olduğu için mutluydu, Amy ve AppSec ekibi, Jane’in kimliğinin artık paylaşılmadığı için mutluydu ve kuruluş, müşteri memnuniyet oranının yeniden yükselmeye başladığını gördü. Her şey yolundaydı.
İki hafta sonra, SOC, üretim müşteri veritabanına anormal erişim konusunda başka bir uyarı aldı. Aynı veritabanındaki önceki uyarıya şüpheli bir şekilde benziyordu. Yine, kuruluş genelindeki IP adresleri, veritabanını sorgulamak için tek bir kullanıcının kimliğini kullanıyordu. Yine, bu kullanıcı Jane’di. Ancak bu sefer güvenlik ekibi ve Jane, uygulamanın kullanıcının kimliklerini kullandığını biliyordu. Neler oluyor?
Soruşturma, orijinal uygulamanın dolaylı olarak paylaşıldı Jane’in uygulamanın kullanıcılarıyla kimliği doğrulanmış veritabanı oturumu. Uygulamayı bir kullanıcıyla paylaşarak, bu kullanıcı uygulamaya doğrudan erişim elde etti. bağ, düşük kodlu/kodsuz platform tarafından sağlanan kimliği doğrulanmış bir veritabanı oturumunun etrafındaki bir sarmalayıcı. Kullanıcılar, bu bağlantıyı kullanarak, kimliği doğrulanmış oturumdan doğrudan yararlanabilir – artık uygulamadan geçmek zorunda değillerdi. Görünüşe göre birkaç kullanıcı bunu öğrenmiş ve amaçlanan davranış olduğunu düşünerek, sorgularını çalıştırmak için Jane’in kimliği doğrulanmış veritabanı oturumunu kullanıyormuş. Bağlantıyı kullanmaları, yalnızca atandıkları müşteri durumları için değil, doğrudan veritabanına tam erişim sağladığı için bu çözümü sevdiler.
Bağlantı silindi ve olay sona erdi. SOC analisti, depoladıkları tüm müşteri verilerini atmadıklarından emin olmak için Jane’in bağlantısını kullanan kullanıcılara ulaştı.
Düşük Kodlu/Kodsuz Güvenlik Sorununun Ele Alınması
Yukarıdaki hikaye, çok uluslu bir B2C şirketinin gerçek hayat senaryosudur. Gizliliği korumak için bazı ayrıntılar atlandı veya ayarlandı. İyi niyetli bir çalışanın farkında olmadan kimliğini diğer kullanıcılarla paylaşarak BT, güvenlik ve işletme genelinde bir dizi soruna neden olduğunu gördük. Geçen ay keşfettiğimiz gibi, kimlik bilgisi paylaşımı, düşük kodlu/kodsuz olmanın önemli bir özelliğidir. İstisna değil, normdur.
Düşük kodlu/kodsuz, kuruluşta bilinçli veya bilinçsiz olarak çiçek açmaya devam ederken, güvenlik ve BT ekiplerinin iş geliştirme görüşmesine katılması çok önemlidir. Düşük kodlu/kodsuz uygulamalar bir benzersiz bir dizi güvenlik sorunuve üretken yapıları, bu zorlukların her zamankinden daha hızlı akut hale geldiği anlamına gelir.