Kodsuz Geliştiricilerin Kendilerini Ayağından Vurmasının 3 Yolu PlatoBlockchain Veri Zekası. Dikey Arama. Ai.

Kodsuz Geliştiricilerin Kendilerini Ayağa Vurabilmelerinin 3 Yolu

Riskten kaçınan kuruluşların, iş kullanıcılarının maliyetli hatalar yapma yeteneğini ciddi şekilde sınırlayabildiği bir dönem vardı. Sınırlı teknik bilgi birikimi, katı izinler ve arka rüzgar eksikliği ile bir işletme kullanıcısının yapabileceği en kötü şey, kötü amaçlı yazılım indirmek veya bir kimlik avı kampanyasına kanmaktı. O günler artık geride kaldı.

Şu günlerde, her büyük hizmet olarak yazılım (SaaS) platformu birlikte gelir doğrudan iş kullanıcıları için tasarlanan ve onlara pazarlanan otomasyon ve uygulama oluşturma yetenekleriyle. Microsoft 365, Salesforce ve ServiceNow gibi SaaS platformları gömülüyor kodsuz/düşük kodlu platformlar mevcut tekliflerine dahil ederek bunları kurumsal onay istemeden doğrudan iş kullanıcılarının ellerine teslim eder. Bir zamanlar yalnızca BT ve geliştirme ekipleri için mevcut olan yetenekler, artık tüm organizasyonda mevcuttur.

Microsoft'un düşük kodlu platformu olan Power Platform, Office 365'te yerleşiktir ve Microsoft'un kuruluştaki güçlü dayanağı ve iş kullanıcıları tarafından benimsenme oranı nedeniyle harika bir örnektir. Kuruluşlar, belki de farkına varmadan geliştirici düzeyindeki gücü, çok daha az güvenlik veya teknik anlayışla, her zamankinden daha fazla kişinin eline veriyor. Ne ters gidebilir ki?

Aslında oldukça fazla. Deneyimlerimden birkaç gerçek dünya örneğini inceleyelim. Bilgiler anonimleştirildi ve işletmeye özgü süreçler çıkarıldı.

Durum 1: Yeni Satıcı? Sadece yap

Çok uluslu bir perakende şirketindeki müşteri hizmetleri ekibi, müşteri verilerini tüketici içgörüleriyle zenginleştirmek istedi. Özellikle, ilk satın alımları sırasında bile onlara daha iyi hizmet verebilmek için yeni müşteriler hakkında daha fazla bilgi bulmayı umuyorlardı. Müşteri hizmetleri ekibi, birlikte çalışmak istedikleri satıcıya karar verdi. Satıcı, daha sonra hizmetleri tarafından geri çekilecek olan zenginleştirme için verilerin kendilerine gönderilmesini istedi.

Normalde, BT burada devreye giriyor. BT'nin satıcıya ve satıcıdan veri almak için bir tür entegrasyon oluşturması gerekir. Bu satıcıya müşteri verileri konusunda güvenilebilmesi ve satın alma işleminin onaylanabilmesi için BT güvenlik ekibinin de dahil olması gerektiği açıktır. Tedarik ve hukuk da önemli bir rol oynayacaktı. Ancak bu durumda işler farklı bir yöne gitti.

Bu özel müşteri hizmetleri ekibi, Microsoft Power Platform uzmanlarıydı. Kaynakları veya onayları beklemek yerine, devam ettiler ve entegrasyonu kendileri oluşturdular: üretimdeki SQL sunucularından müşteri verilerini topladılar, hepsini satıcı tarafından sağlanan bir FTP sunucusuna ilettiler ve zenginleştirilmiş verileri FTP sunucusundan geri getirdiler. üretim veritabanı. Veritabanına her yeni müşteri eklendiğinde tüm süreç otomatik olarak yürütülüyordu. Tüm bunlar, Office 365'te barındırılan sürükle ve bırak arabirimleri aracılığıyla ve kişisel hesapları kullanılarak yapıldı. Lisans cepten ödendi ve bu da tedariki döngünün dışında tuttu.

Müşteri verilerini AWS'de sabit kodlanmış bir IP adresine taşıyan bir grup iş otomasyonu bulduklarında CISO'nun şaşırdığını hayal edin. Yalnızca Azure müşterisi olarak bu, büyük bir kırmızı bayrak uyandırdı. Ayrıca, veriler güvenli olmayan bir FTP bağlantısıyla gönderilip alınıyordu, bu da bir güvenlik ve uyumluluk riski oluşturuyordu. Güvenlik ekibi bunu özel bir güvenlik aracı aracılığıyla bulduğunda, veriler neredeyse bir yıldır kuruluşa girip çıkıyordu.

Durum 2: Ohh, Kredi Kartı Toplama Yanlış mı?

Büyük bir BT satıcısındaki İK ekibi, çalışanların bağışladıkları her doları denkleştirerek şirketin devreye girmesiyle, çalışanların en sevdikleri hayır kurumuna bağışta bulunmaya teşvik edildiği, yılda bir kez düzenlenen bir "Give Away" kampanyasına hazırlanıyordu. Geçen yılın kampanyası büyük bir başarıydı, dolayısıyla beklentiler tavan yapmıştı. Kampanyayı güçlendirmek ve manuel süreçleri kolaylaştırmak için yaratıcı bir İK çalışanı, tüm süreci kolaylaştıran bir uygulama oluşturmak için Microsoft'un Power Platform'unu kullandı. Kaydolmak için bir çalışan, kurumsal hesabıyla uygulamaya giriş yapar, bağış tutarını gönderir, bir hayır kurumu seçer ve ödeme için kredi kartı bilgilerini verir.

Kampanya, çalışanların rekor katılımı ve İK çalışanlarının çok az el emeği gerektirdiği büyük bir başarıydı. Ancak nedense güvenlik ekibi işlerin gidişatından memnun değildi. Güvenlik ekibinden bir çalışan, kampanyaya kayıt olurken, olması gerektiği gibi görünmeyen bir uygulamada kredi kartlarının tahsil edildiğini fark etti. Soruşturmanın ardından, bu kredi kartı detaylarının gerçekten de uygunsuz bir şekilde ele alındığını tespit ettiler. Kredi kartı ayrıntıları, varsayılan Power Platform ortamında depolandı; bu, tüm çalışanlar, satıcılar ve yükleniciler dahil olmak üzere tüm Azure AD kiracısının kullanımına açık olduğu anlamına gelir. Ayrıca, basit düz metin dize alanları olarak depolandılar.

Neyse ki veri işleme ihlali, güvenlik ekibi tarafından kötü niyetli aktörler veya uyumluluk denetçileri tarafından fark edilmeden önce keşfedildi. Veri tabanı temizlendi ve finansal bilgileri düzenlemeye göre düzgün bir şekilde işlemek için uygulamaya yama yapıldı.

3. Durum: Neden Gmail'i Kullanamıyorum?

Bir kullanıcı olarak, hiç kimse kurumsal veri kaybı önleme denetimlerinden hoşlanmaz. Gerektiğinde bile, günlük operasyonlara sinir bozucu sürtüşmeler getirirler. Sonuç olarak, kullanıcılar her zaman onları atlatmaya çalıştı. Yaratıcı iş kullanıcıları ile güvenlik ekibi arasındaki uzun süreli çekişmelerden biri kurumsal e-postadır. Kurumsal e-postayı kişisel bir e-posta hesabıyla veya kurumsal takvimi kişisel bir takvimle senkronize etme: Güvenlik ekiplerinin bunun için bir çözümü var. Yani, e-posta iletimini engellemek ve veri yönetişimini sağlamak için e-posta güvenliği ve DLP çözümleri koyuyorlar. Bu sorunu çözer, değil mi?

Peki hayır. Tekrarlanan bir bulgu büyük işletmelerde ve küçük işletmelerde, kullanıcıların kurumsal e-postalarını ve takvimlerini kişisel hesaplarına iletmek için e-posta denetimlerini atlayan otomasyonlar oluşturduğunu tespit etti. E-postaları iletmek yerine, verileri bir hizmetten diğerine kopyalayıp yapıştırırlar. İş kullanıcıları, her hizmette ayrı bir kimlikle oturum açarak ve kopyala-yapıştır sürecini kodsuz olarak otomatikleştirerek güvenlik kontrollerini kolaylıkla atlar ve güvenlik ekiplerinin öğrenmesinin kolay bir yolu yoktur.

Power Platform topluluğu bile geliştirdi şablonları herhangi bir Office 365 kullanıcısının alıp kullanabileceği.

Büyük güç büyük sorumluluk getirir

İş kullanıcısı yetkilendirmesi harika. İş kolları BT için beklememeli veya geliştirme kaynakları için savaşmamalıdır. Ancak, işletme kullanıcılarına herhangi bir rehberlik veya korkuluk olmaksızın geliştirici düzeyinde güç veremeyiz ve her şeyin yoluna girmesini bekleyemeyiz.

Güvenlik ekiplerinin iş kullanıcılarını eğitmesi ve uygulama geliştiricileri olarak bu uygulamalar "kodsuz" kullanılarak oluşturulmuş olsa bile yeni sorumluluklarının farkına varmalarını sağlamaları gerekir. Güvenlik ekipleri ayrıca, hepimizin yaptığı gibi, iş kullanıcıları bir hata yaptığında bunun tam gelişmiş veri sızıntılarına veya uyumluluk denetim olaylarına dönüşmemesini sağlamak için korkuluklar ve izlemeler yerleştirmelidir.

Zaman Damgası:

Den fazla karanlık okuma