Göre “2022 Verizon Veri İhlali Araştırmaları Raporu,” çalıntı kimlik bilgileri, veri ihlallerine yol açan en önemli yoldu. Saldırganlar, kimlik avından veya güvenlik açıklarından yararlanmaktan daha sık olarak, kimlik bilgilerine doğrudan erişim sağlayarak, ön kapıyı kullanarak kurban kuruluşlarına sanal olarak girmelerine izin verir.
Düşük kodlu/kodsuz platformlar, kullanıcıların kimlik bilgilerini paylaşmalarını ve kimlik bilgilerini uygulamalara yerleştirmelerini son derece kolaylaştırır, böylece çalışan hatalarının kimlik bilgilerinin sızmasına neden olma riskini önemli ölçüde artırır. İstemeden, düşük kodlu/kodsuz geliştirme, saldırganların 1 numaralı kaynağı elde etmesini kolaylaştırır.
Düşük Kodlu/Kodsuz Platformlar Verimlilik İçin Güvenlikten Nasıl Ödün Veriyor?
Bir kuruluşta işinizi yapmak için gerekli izinleri almak çok sinir bozucu olabilir. Yeni çalışanların, iş verilerine erişmek, KPI gösterge tablolarını gözden geçirmek veya bir iç iletişim kanalına katılmak için ihtiyaç duydukları tüm izinlere sahip olmak için bir aydan fazla beklemeleri alışılmadık bir durum değildir.
Aynı şey, işletmede yeni bir uygulama kurmak için de geçerlidir, belki daha da kötüsü. İzin isteklerinin genellikle doğrudan yöneticiniz, onların yöneticisi ve veriye/hizmete sahip olan ekip tarafından onaylanması gerekir. Onaylayanlardan bazıları, saat dilimi farkı olan başka bir kıtada olabilir. Verilere/hizmetlere gerekli erişim olmadan bir uygulama oluşturmaya başlamak neredeyse imkansızdır ve bu nedenle beklemeye başlarsınız.
Uygulamanız için doğru erişimi elde etmeyi başardıktan sonra nihayet oluşturmaya hazırsınız. Birkaç ay geçer. Aniden, uygulamanızın başarısız olduğuna dair bir bildirim alırsınız. Hızlı bir analiz, izinlerinin iptal edildiğini gösterir. Kuruluşlar, uygulama üreticisi tarafından açıkça izin istenmediği sürece, genellikle birkaç ayda bir erişimi iptal eden otomatik bir süreç kurar. Bu süreç, düzenlemelere uymak ve aşırı izinleri azaltmak için gereklidir, ancak dezavantajları vardır – yani üretkenliği engelleyebilecek periyodik manuel bir süreç.
Düşük kodlu/kodsuz, her çalışana, özellikle iş profesyonellerine, özel olarak oluşturulmuş uygulamalar ve otomasyonlarla kendi sorunlarını çözme konusunda yetki verme girişimidir. Satıcılar bunu, bina uygulamaları için engelleri sistematik olarak belirleyerek ve kaldırarak yapar. Kodlamayı öğrenmek zor mu yoksa korkutucu mu? Sürükle ve bırak arayüzü, giriş engelini azaltmaya yardımcı olabilir. Entegrasyon zor mu? Çok çeşitli yönetilen bağlayıcılar, bir uygulama programlama arabiriminin (API) ne olduğunu veya onunla nasıl etkileşimde bulunacağını bilme ihtiyacını ortadan kaldıracaktır. İzin istemek sizi yavaşlatıyor mu? Kimlikleri paylaşmak ve mevcut kullanıcı erişiminden yararlanmak hızlı bir alternatif sağlayabilir.
Yeniliği artırmak için, düşük kodlu/kodsuz platformlar, kullanıcılarının mevcut kullanıcı kimliklerinden yararlanmalarına, onu bir uygulamaya yerleştirmelerine ve bunu yaparak kurumsal izin modelini tamamen atlatmasına olanak tanır. Güvenlikte veya BT’de dışarıdan bir izleyici için uygulama mevcut değildir ve onu kullanan herkes aslında onu üreticisinin hesabında çalıştırmaktadır.
Bekle, Ama Nasıl?
Uygulamanın üreticisinin kimliğine bürünmesine izin vermekten daha iyi çözümler olduğunu düşünüyorsanız, kısmen haklısınız.
Son yıllarda, OAuth, uygulama erişimi vermek için fiili standart olmuştur. Bir hizmet olarak yazılım (SaaS) pazarına gittiğinizde, üçüncü taraf entegrasyonunu aldığınızda ve küçük bir oturum açma ve onay açılır penceresiyle istendiğinde, büyük olasılıkla OAuth kullanıyorsunuzdur. OAuth’un birçok farklı izin akışı vardır ve bunların tümü tanıdık açılır pencere deneyimiyle sonuçlanır. Önemli bir ayrım, uygulamaya doğrudan veya şu anda oturum açmış olan kullanıcı adına izin verilip verilmediğidir. Bu küçük bir ayrıntı gibi görünse de, aslında düşük kodlu/kodsuz kimlik sorununun temel nedenidir.
Bir uygulamaya doğrudan izin verildiğinde, izni veren kullanıcının kimliğinden ayrı olarak kendi kimliği verilir. Uygulama kimliği, şüpheli kimlik doğrulama veya erişim kalıpları için izlenebilir ve izinleri herhangi bir zamanda bir güvenlik veya BT yöneticisi tarafından iptal edilebilir. Uygulamanın üzerinde çalıştığı altyapının statik yapısından yararlanmak için IP kısıtlaması gibi kontroller uygulanabilir. Her uygulama, ayrı erişim kısıtlamaları ile ayrı bir kimliğe sahip olabilir ve ayrı ayrı izlenebilir ve üzerinde işlem yapılabilir. Uygulama kimliğinin bir başka yararlı anlamı da yönetici denetimidir.
Ancak, şu anda oturum açmış olan uygulama kullanıcısı adına onay vermenin çok farklı sonuçları vardır. Uygulama, kullanıcı uygulamayı kullandığında sınırlı bir süre için kullanıcının kimliğini kullanarak kaynaklara erişim kazanır. Adına erişim, uygulamanın harici kaynakları sorgularken doğrudan kullanıcının kimliğini kullandığı anlamına gelir. Ayrıca, birden çok uygulamanın kullanılması, hepsinin aynı kimliği, yani kullanıcının kimliğini kullanmasına neden olacaktır. Günlüklere bakan BT veya güvenlik yöneticileri, kullanıcıyı veya kullanıcı tarafından kullanılan herhangi bir uygulamayı kolayca ayırt edemez. Kullanıcılar adına uygulama erişimi vermek, başlangıçta yalnızca bir kullanıcı uygulamayı aktif olarak kullanırken geçici erişime izin verecek şekilde tasarlanmıştır.
Çoğu durumda hizmetler, uygulamaların kullanıcılar adına erişim elde etmesine izin verir, ancak uygulamaların hizmet API’lerine doğrudan erişimini reddeder. Bu, ilginç bir soruyu gündeme getiriyor: Bir uygulama yalnızca bir kullanıcı adına verilere erişebiliyorsa, hiçbir kullanıcı onunla etkileşimde olmadığında verilere nasıl erişebilir? Yaratıcı mühendisler bir çözüm buldu. Uygulama bir kez kullanıcı olarak oturum açar, ardından kimlik doğrulama jetonunu kaydeder ve kullanıcı uygulamadan çıktıktan sonra bile kullanmaya devam eder. Düşük kodlu/kodsuz uygulamalar söz konusu olduğunda, bu kullanıcı genellikle uygulamanın yaratıcısıdır. Bu geçici çözümü önlemek için kullanıcı kimlik doğrulama belirteçlerinin kısa ömürlü olması gerekir. Ancak uygulamada, çoğu hizmet 12 ay boyunca geçerli olan jetonlar verir.
Bir iş uzmanının bir uygulama oluşturduğunu varsayalım. Bir uygulama kimliğinin veya izinlerinin onaylanmasını beklemek yerine, bir kullanıcı adına erişimi kullanırlar – bu durumda, kendileri. Uygulama, bir kez oturum açmalarını (örneğin Salesforce veya SharePoint’e), kendi özel kimlik doğrulama belirteçlerini kaydetmelerini ve istedikleri zaman yeniden kullanmalarını gerektirir. Uygulamayı başka bir kullanıcı kullanıyor olsa bile, üreticisinin kimliğini kullanmaya devam edecektir.
Özel kimliklere sahip düşük kodlu/kodsuz uygulamalar oluşturmanın yolları vardır; örneğin, hizmet hesaplarını kullanarak. Ancak, yöntemler çok yaygın olarak kullanılmamaktadır.
Uygulama kimliğinin yukarıda belirtilen olumlu özelliklerini hatırlayın: Uygulama izlenebilir, verilere erişimi kontrol edilebilir ve ayrıcalıkları iptal edilebilir. Düşük kodlu/kodsuz platformlar yaratıcılarının kimliğiyle gömülü olduğunda bunların hiçbiri doğru değildir. Bir iş profesyonelinin yaptığı her uygulamada, kullanıcı kimliği yerleşik olarak bulunabilir. Erişim günlüklerini analiz eden güvenlik ve BT ekipleri, bu uygulamaların var olduğunu bile bilmeyecek.
Hizmet Olarak Kimliğe Bürünme
Uygulamaların kaynaklara erişmesine izin vermenin bir yolu olarak kullanıcı kimlik doğrulama belirteçlerini kaydetme ve yeniden yürütmenin başka bir anlamı daha vardır: Kullanıcılar arasında basit ve kolay kimlik paylaşımına kapı açarlar. Bu, tipik olarak bağlantılar olarak adlandırılan ortak bir düşük kodlu/kodsuz özellikte kendini gösterir. Bağlantılar, düşük kodlu/kodsuz uygulamaların Slack, NetSuite veya BambooHR gibi kaynaklara nasıl eriştiğidir. Çalışan İK verilerini okumak gibi okuma işlemlerine izin verirler; son satışlarda ERP gibi işlemleri yazmak; ve bir Slack kanalını kalıcı olarak silmek gibi işlemleri silin. Bağlantılar birinci sınıf nesnelerdir, yani bir kullanıcı tarafından oluşturulabilir ve başka bir kullanıcıyla, tüm ekiple ve hatta tüm kuruluşla paylaşılabilir. Teknik olarak konuşursak, bunlar kullanıcı kimlik doğrulama belirteçleri veya sabit kodlanmış kimlik bilgileri etrafındaki sarmalayıcılardır.
Örneğin, bir kullanıcı Microsoft Office ile bir bağlantı oluşturup paylaştığında, bu onların parolalarını paylaşmalarına benzer. Ancak, geliştiricilerden oluşan bir ekip bir proje üzerinde işbirliği yapıyorsa, genellikle bir uygulama kimliğini birbirleriyle paylaşabilmeleri gerekir. Bağlantı paylaşımı, paylaşılan bir projede bir ekipte birlikte çalışmayı sağlar, ancak ne yazık ki kullanıcıların kimliklerini birbirleriyle paylaşmalarına da olanak tanır. Birçok düşük kodlu/kodsuz uygulama, yaratıcının kimliği içine gömülü olarak oluşturulduğundan, kimlik paylaşımı ortak bir risk düşük kodlu/kodsuz platformlar tanıtmak.
Daha da kötüsü, birçok platformda kimlik bilgisi paylaşımı çok kolaydır. Tek bir onay kutusu, sizinle kimliğinizi (örneğin ServiceNow veya Salesforce hesabınızı) tüm kuruluşunuzla paylaşma arasında durur. Bazı durumlarda, bir uygulamayı diğer kullanıcılarla paylaşmak, onun temel bağlantılarını da dolaylı olarak paylaşır.
Bu çok önemli bir nokta. Belirli koşullar altında, bir iş uygulamasına erişim elde eden kullanıcılar, doğrudan izin veya bilgi olmaksızın, dolaylı olarak temeldeki veritabanına doğrudan erişim elde edeceklerdir. Örneğin bir gider yönetimi uygulamasını ele alalım. İnsanların harcama raporlarını göndermek için uygulamayı kullanmalarına izin vermekle, içinde herkesin harcama raporlarının bulunduğu temel veritabanına erişim vermeleri arasında büyük bir fark vardır.
İstemeden, düşük kodlu/kodsuz uygulamalar kimlik bilgilerini oluşturur – saldırganların peşinde olduğu 1 numaralı kaynak – elde etmek daha kolay.
Buradan nereye gidiyoruz?
Gördüğümüz gibi, düşük kodlu/kodsuz platformlar, profesyonellerden iş geliştiricilerine kadar herkes için kurumsal uygulamaların oluşturulmasını kolaylaştırma konusunda birçok zorluğun üstesinden gelmek zorunda kaldı. Bazen çözümler bir maliyetle gelir. Kimlik bilgileri söz konusu olduğunda, hızlı hareket etme yeteneği, ne yazık ki, bir şeyleri kırma yeteneğiyle, yani kurumsal kimlik modeliyle birleştirilir.
Burada, düşük kodlu/kodsuz platformların kuruluş için yarattığı muazzam değerden bahsetmek önemlidir: fikir ve uygulama arasındaki süreyi azaltmak, uygulama geliştirme çıtasını düşürmek ve iş hızını artırmak.
Platformların güvenlik endişelerini kendi başlarına çözmesi beklenemez; platform ve müşterileri arasında paylaşılan bir sorumluluktur. Riski azaltmak için güvenlik ekipleri, kimliklerin kuruluşlarının kullandığı düşük kodlu/kodsuz platformların bir parçası olarak ele alınma yöntemlerine aşina olmalıdır. Çoğu platform, kimlik bilgisi paylaşımı seviyesini azaltacak ve örtük paylaşımı kapatacak şekilde yapılandırılabilir.
Daha da önemlisi, güvenlik ekipleri, düşük kodlu/kodsuz platformların, kuruluşa, uygulama ve kullanıcı kimlikleri arasındaki karışıklık nedeniyle geleneksel izleme yaklaşımlarıyla azaltılamayan doğal yeni bir risk getirdiğini anlamalıdır. Bu nedenle güvenlik ekipleri, iş geliştiricilere rehberlik etmeye, potansiyel olarak riskli uygulamaları incelemeye ve riski azaltmak için harekete geçmeye yatırım yapmalıdır.
