Geçen ay yazdım bir makale Az kodlu/kodsuz platformların kimlik bilgisi paylaşımını bir hizmet olarak nasıl sundukları, bunu neden yaptıkları ve bunun dışarıdan nasıl göründüğü hakkında saldırganın bakış açısı. Bu makalede, bu uzlaşmanın sonuçlarına ve bunun günümüz işletmelerini nasıl etkilediğine odaklanacağım.
İşte bu nedenle kurumsal kimlik bilgilerinizi başka biriyle paylaşmak kötü bir uygulamadır. Bir defaya mahsus kullanıcı davranışı analizi için üretim günlüklerini sorgulamak amacıyla kimlik bilgilerimi bir meslektaşıma iletmek istediğimi varsayalım. Tipik bir kuruluşta, birine 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 sinirlenebilir. "Tek istediğim bu küçük tek seferlik sorguyu yapmaktı ve zaten bir aydır bekliyordum!" diyebilirlerdi. Sorguyu onlar için çalıştırabilirim ancak kendi günlük görevlerimin arasında boğulmuş durumdayım ve tek seferlik sorgular genellikle karmaşık hale geliyor.
Elimde hızlı bir çözüm kaldı: Kullanıcı adımı/şifremi meslektaşımla paylaşabilirim. Eğer MFA sınavına girerlerse memnuniyetle onaylarım. Sorguyu çalıştırmak için zaman harcamam gerekmiyor ve iş arkadaşımın engellemesi kalkıyor. Herkes kazanır! Sağ?
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 olmakla birlikte, kuruluşunuzun bir dizi gizlilik ve güvenlik standardıyla uyumlu kalması ve şirketin güvenlik taahhüdünü sürdürerek müşteri güvenini sürdürmesi de aynı derecede hatta daha da önemlidir. .
Üst düzey kurumsal hedefler sizi ikna etmiyorsa BT veya güvenlik alanındaki merkezi yönetim ekiplerini düşünün. Bu ekipler operasyonlarını ve güvenlik stratejilerini her kullanıcının kendine özgü bir kimliğe sahip olduğu gerçeğine dayandırıyor. BT ekipleri, her kullanıcının tek bir kurumsal IP'den veya kurumsal dizüstü bilgisayardan aynı anda oturum açacağını varsayan ağ oluşturma ve erişim politikaları oluşturuyor; güvenlik ekipleri olayları kullanıcı kimliğine göre ilişkilendiriyor; finans ekipleri kullanıcı başına maliyet raporlarını ve kişisel bulut ortamlarını topluyor olabilir. Kimlik bilgisi paylaşımı, diğerlerinin yanı sıra tüm bu varsayımları baltalıyor. Çevrimiçi kimliğin temel anlamını ortadan kaldırır.
Gerçek Dünyadan Bir Örnek
Az 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ş genelindeki çalışanların bir müşteri vakasına katıldığında, genellikle müşteri hakkındaki destek vaka geçmişi ve en son satın alma işlemleri gibi önemli bilgileri kaçırdıklarını fark etti. Bu, müşteri deneyimini olumsuz etkiler çünkü vaka, sorunu çözebilecek doğru çalışana yönlendirilirken sorununu tekrar tekrar açıklamak zorunda kalırlar.
Bunu geliştirmek için Jane, şirket çalışanlarının, müşterinin destek vakasıyla ilgilenmekten sorumlu ekibin bir parçası olması durumunda müşterilerle ilgili bu önemli bilgileri görüntülemesine olanak tanıyan bir uygulama oluşturdu. Öncelikle, Jane'in bir ihtiyacı belirlemesine ve bütçe istemeden veya BT kaynak tahsisini beklemeden kendi başına çözmesine olanak tanıyan az kodlu/kodsuz yöntemin gücünü kabul edelim.
Uygulamayı oluştururken Jane'in birden fazla sorun üzerinde çalışması gerekiyordu; bunlardan en büyüğü izinlerdi. Kuruluş genelindeki çalışanların, ihtiyaç duydukları bilgileri almak için müşteri veritabanını sorgulamaya doğrudan erişimi yoktur. Eğer öyle olsaydı Jane'in bu uygulamayı geliştirmesine gerek kalmazdı. 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 kullanacak ve ardından sonuçları kullanıcıya gönderecektir. Bu kimlik bilgisi yerleştirme özelliği, geçen ay araştırdığımız 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 rol tabanlı erişim kontrolünü (RBAC) kurduğunuzdan emin oldu.
Uygulama, önemli bir iş sorununu çözdü ve böylece kuruluş genelinde kullanıcıların hızla benimsemesini sağladı. İnsanlar, konuşma için doğru bağlamı kullanarak müşterilerine daha iyi hizmet verebildikleri için mutluydu. Müşteriler de memnundu. Jane uygulamayı oluşturduktan bir ay sonra uygulama, kuruluş genelinde yüzlerce kullanıcı tarafından kullanıldı ve müşteri memnuniyeti oranları arttı.
Bu arada SOC'de, üretim müşteri veri tabanındaki anormal aktiviteyi gösteren yüksek önem dereceli 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ı kazımaya çalıştığını ve kuruluş genelindeki birden fazla IP adresinden birden fazla müşteri hakkındaki bilgileri sorguladığını gösterdi. Sorgu modeli çok karmaşıktı; Bir veritabanı silinirken görmeyi beklediğiniz basit bir numaralandırma modeli yerine, aynı müşterinin verileri birden çok kez, bazen farklı IP adresleri aracılığıyla ve farklı tarihlerde sorgulandı. Bu, güvenlik izleme sistemlerini karıştırmaya çalışan bir saldırgan olabilir mi?
Hızlı bir araştırmanın ardından Amy çok önemli bir bilgiyi ortaya çıkardı: Tüm IP adresleri ve tarihlerdeki tüm bu sorgular, müşteri hizmetleri ekibinden Jane adında biri olan tek bir kullanıcı kimliğini 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ı veya yanlış gelen e-postaya mı güvendi? Ancak Jane, Amy'ye yakın zamanda geliştirdiği uygulamadan bahsettiğinde ikisi de bir bağlantı olabileceğini fark etti. SOC analisti Amy, düşük kodlu/kodsuz konusuna aşina değildi, bu nedenle AppSec ekibine ulaştılar. Ekip, Jane'in yardımıyla Jane'in uygulamasında Jane'in kimlik bilgilerinin gömülü olduğunu anladı. Veritabanı açısından bakıldığında herhangi bir uygulama yoktu; yalnızca çok sayıda sorgu yürüten Jane vardı.
Jane, Amy ve AppSec ekibi bir çözüm bulunana kadar uygulamayı kapatmaya karar verdi. Kuruluş genelindeki uygulama kullanıcıları, bu uygulamaya güvenmeye başladıkları için hayal kırıklığına uğradılar ve müşteriler de bunu hissediyordu.
Amy konuyu kapatıp bulgularını belgelediğinde, müşteri hizmetlerinden sorumlu başkan yardımcısı müşteri memnuniyeti oranındaki düşüşten memnun değildi ve Jane'den kalıcı bir çözüm aramasını istedi. Platformun belgelerinin ve kuruluşun Mükemmeliyet Merkezi ekibinin yardımıyla Jane, yerleşik kimliğini uygulamadan kaldırdı, uygulamayı, veritabanını sorgulamak için her kullanıcının kimliğini kullanacak şekilde değiştirdi ve kullanıcıların yalnızca ilişkili oldukları müşteri vakaları için izin almasını sağladı. . Yeni ve geliştirilmiş versiyonunda uygulama, müşteri veri tabanını sorgulamak için her kullanıcının kimliğini kullanıyordu. Jane ve uygulama kullanıcıları, uygulamanın tekrar çevrimiçi olmasından memnundu; Amy ve AppSec ekibi, Jane'in kimliğinin artık paylaşılmamasından memnundu ve şirket, müşteri memnuniyeti oranının yeniden yükselmeye başladığını gördü. Her şey yolundaydı.
İki hafta sonra SOC, üretim müşterisi veritabanına anormal erişim konusunda başka bir uyarı aldı. Aynı veri tabanı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. Bu kullanıcı yine Jane'di. Ancak bu sefer güvenlik ekibi ve Jane, uygulamanın kullanıcı kimliklerini kullandığını biliyordu. Neler oluyor?
Soruşturma, orijinal uygulamanın örtülü olarak paylaşıldı Jane'in uygulamanın kullanıcılarıyla kimliği doğrulanmış veritabanı oturumu. Uygulamayı bir kullanıcıyla paylaşarak, o kullanıcı şuraya doğrudan erişim elde etti: bağ, düşük kodlu/kodsuz platform tarafından sağlanan, kimliği doğrulanmış bir veritabanı oturumunu çevreleyen bir sarmalayıcı. Kullanıcılar bu bağlantıyı kullanarak kimliği doğrulanmış oturumdan doğrudan yararlanabiliyordu; artık uygulamayı kullanmaları gerekmiyordu. Birkaç kullanıcının bunu fark ettiği ve amaçlanan davranışın bu olduğunu düşünerek sorgularını çalıştırmak için Jane'in kimliği doğrulanmış veritabanı oturumunu kullandıkları ortaya çıktı. Bağlantıyı doğrudan kullanmak onlara yalnızca atandıkları müşteri vakaları için değil, veritabanına tam erişim sağladığı için bu çözümü sevdiler.
Bağlantı silindi ve olay sona erdi. SOC analisti, Jane'in bağlantısını kullanan kullanıcılara ulaşarak, depoladıkları tüm müşteri verilerini atmalarını sağladı.
Düşük Kodlu/Kodsuz Güvenlik Sorununun Çözümü
Yukarıdaki hikaye çok uluslu bir B2C şirketinin gerçek hayattan bir senaryosudur. Gizliliği korumak için bazı ayrıntılar atlandı veya değiştirildi. İyi niyetli bir çalışanın farkında olmadan kimliğini diğer kullanıcılarla nasıl paylaşabildiğini ve bunun BT, güvenlik ve iş genelinde çok çeşitli sorunlara neden olabileceğini gördük. Geçen ay incelediğimiz gibi, kimlik bilgisi paylaşımı az kodlu/kodsuzun önemli bir özelliğidir. Bu bir istisna değil, normdur.
As Düşük kodlu/kodsuz, bilinçli veya bilinçsiz olarak kuruluşta gelişmeye devam ediyorGüvenlik ve BT ekiplerinin iş geliştirme görüşmelerine katılması çok önemlidir. Az kodlu/kodsuz uygulamalar, benzersiz güvenlik zorlukları setive onların üretken doğası, bu zorlukların her zamankinden daha hızlı bir şekilde akut hale geldiği anlamına geliyor.
