İlk etapta erişimin verildiğini nereden biliyorsunuz?


Zero Trust Mimarisi için güçlü bir temel olarak güçlü IGA

Bir meslektaşım ve ben yakın zamanda Sıfır Güven Mimarisi (ZTA) hakkında bir tartışma yaptık. Dışarıda herkese uyan tek bir çözüm yok. Sıfır Güven, anahtar teslimi bir çözümden çok bir yolculuktur. Ancak bazı ortak özellikler vardır ve NIST 800-207 standardı veya Microsoft’un Sıfır Güven danışma belgesi, okumaya başlamak için fena yerler değildir. Bununla birlikte, önde gelen IGA çözüm sağlayıcılarından birindeki geçmişim nedeniyle, ZTA tartışılırken Kimlik Yönetişimi ve Yönetiminin (IGA) neden hiç fotoğraflarda yer almadığını merak etmeye başladım. İlke altyapısı her zaman, bir hesabın belirli bir AD grubunun veya Azure rolünün üyesi olması durumunda sorun olmadığını ve “sıfır güvenin” rolünün kimliğin cihazını, konumunu, günün saatini ve diğer geçici faktörleri kontrol etmek olduğunu varsayar. isteği kabul edip etmeyeceğinize, çok faktörlü kimlik doğrulamayı uygulayıp uygulamayacağınıza ve hatta isteği reddetmeye karar verin.

Zero Trust’ın bir şeye güvenebilmesi gerekir

Son 4½ yılı çeşitli IGA taahhütleriyle geçirmiş biri olarak, bir kimliğin verilen erişimlerinin onaylandığına ve aslında en az ayrıcalık ilkesine göre verildiğine her zaman güvenmenin saflık olduğunu üzülerek söylüyorum. Birçok şirkette erişim, e-postalara veya ServiceNow’daki biletlere dayalı olarak hizmet masası tarafından verilir. Kimlik iş değiştirdiğinde veya bir projeden ayrıldığında takip yoktur ve erişimler zaman geçtikçe birikmektedir. Diğer bir zorluk ise erişimlerin role dayalı olmamasıdır. Yeni bir çalışan veya yüklenici bir ekibe katıldığında, genellikle şirkette yıllardır çalışan ve muhtemelen çok fazla erişimi olan bir iş arkadaşıyla aynı erişime sahip olur. Ancak o zaman, elbette, yeni çalışanın veya yüklenicinin çok az erişim hakkı nedeniyle verimli çalışamadığı bir durumdan kaçınırsınız.

Güçlü bir IGA, yalnızca bir IGA çözümü satın alarak elde edilemez. Piyasadaki çoğu IGA satıcısının, IGA çözümüne bir HR kaynağı ve tek bir AD ekleyebileceğiniz “8 haftada çalışır duruma gelen” paketler sunduğunun farkındayım. Bu biraz, sadece dizüstü bilgisayarınıza Word yükleyerek Nobel edebiyat ödülünü kazanabileceğinize inanmaya benziyor.

Güçlü bir IGA çözümü elde etmenin en zor yanı, IGA uygulamasını yapılandırmak (veya en azından yapılandırmaması gerekir) değil, verilerinizi değerlendirmektir:

  • Değerlendirin ve derecelendirin uygulamalar. Hangileri en kritik ve hangileri daha az?
  • Değerlendirin ve derecelendirin yetkiler dizinlerinizde. Yine, hangilerinin en kritik ve hangilerinin daha az kritik olduğunu belirleyin ve uygulamalara yetkiler atayın.
  • değerlendirin Iş rolleri. Kuruluşunuzun büyüklüğüne bağlı olarak bu birkaç veya binlerce olabilir. Her rolü gerçekleştirmek için gerekli olan tüm erişim haklarını tanımlayın.
  • Kime erişim isteklerini kabul et veya reddet? Sadece insan yöneticilerine bırakılmaması gereken kritik erişimler için!
  • Ayrıca periyodik yayınlar için prosedürler oluşturun. incelemelere erişim insanların yanlarında çok fazla bagaj taşımadıklarını doğrulamak için.
  • Betimlemek roller örneğin kurumsal aidiyet, iş unvanı ve coğrafi konum gibi kimlik nitelikleri nedeniyle otomatik olarak verilebilen veya kaldırılabilen.
  • tanımla görevlerinin ayrılması uygulanması gereken politikalardır. Yukarıdaki durumda, yazılımın kontrol işlevleri vardı. Ancak görevler ayrılığı politikalarının olmaması nedeniyle, sosyal hizmetler kurulu çalışanına hayali sosyal projeler oluşturma, ödemeleri kabul etme ve hayali sosyal projeden mali tablo alındığını doğrulama erişimi verildi.
  • Tüm değerlendirmeler tamamlandığında, IGA uygulamanızı ve bununla ilgili süreçleri uygulamaya başlayabilirsiniz. Ve IGA sisteminiz ve etrafındaki tüm süreçler oluşturulduğunda, Sıfır Güven Mimarinizin ilke motoru, kimliklerin gerçekten de talep ettikleri erişim haklarına sahip olduğuna güvenebilir.

Cephe hattından hikayeler

İGA alanında çalışan herkesin ne yapılmaması gerektiğine dair “ön cepheden hikayeler” anlatmasını beklerdim. İşte ZTA’nın kendi verilerine güvenebilmesini sağlamak için güçlü bir IGA çözümünün önemini anlamanıza yardımcı olacak birkaç tanesi.

Rol tabanlı erişim sabit denetim bulgularını uyguluyor musunuz?

Geçenlerde finans sektöründe bir müşteri için çalışıyordum. Çeşitli iş rollerini değerlendirmek ve işleri gerçekleştirmek için neyin gerekli olduğunu tanımlamak nedeniyle binlerce erişim hakkının kaldırıldığı bir IGA projesini neredeyse iki yıldır yürütüyorlardı. IGA sistemleri, kayıtlı herhangi bir onayı olmayan tüm değerlendirilmiş erişim haklarını kolayca işaretledi. Ayrıca birkaç tanesini hızlı bir şekilde tanımlamayı başardık. aktif Şirketten uzun süre önce ayrılmış olan çalışanlara ait çeşitli sunucular ve veritabanları üzerinde yönetici haklarına sahip AD hesapları! Projenin, mali denetim otoritesinin (FSA) denetim açıklamalarından sonra başlatılması şaşırtıcı değil. Projenin önemli bir kısmı yakl. 200 iş rolü. Genel bir kural olarak, IGA uygulamasında yalnızca iş rollerini talep edilebilir hale getirdik. Daha önce düşük düzeyli yetkilendirmelerde verilmiş olan tüm erişimlerin iptal edildiği ve erişimin iş rolü düzeyinde tekrar istenmesi ve onaylanması gerekiyordu.

Görevler Ayrılığı politikalarının uygulanmaması nedeniyle 17 milyon ABD doları çalındı

Görevler ayrılığını zorunlu kılan kurallar göz ardı edildiğinde, güvenlik üzerinde ciddi bir etkisi olabilir. Danimarka’da bu, 2018’de sosyal hizmetler kurulunun bir çalışanının 17 milyon ABD doları devlet finansmanına eşdeğer miktarda parayı çaldığı yüksek profilli bir davayla sonuçlandı. Çalışan sistemlere girmedi, ancak kendi hesaplarına para transfer etmesine ve daha sonra veritabanlarından eylemlerini ifşa eden günlük girişlerini kaldırmasına olanak tanıyan sistemlere ve Oracle veritabanlarına başvurdu ve bunlara erişim aldı. Sosyal hizmetler kurulu tüm Sıfır Güven eserlerini yerleştirmiş olsa bile, yerinde güçlü bir IGA olmadığı için suç eylemlerini gerçekleştirebilirdi.

Bu hesap kime ait?

Yetkilerin değerlendirilmesi genellikle nispeten basittir. Bir kuruluşun, kullanıcı hesaplarının AD tabanlı olmadığı, ancak en azından hesap kimliğinin genellikle AD hesap adına eşit veya benzer olduğu uygulamaları olabilir. Bununla birlikte, birincil AD hesabıyla hiçbir ilişkisi olmayan hesap adlarının kullanıldığı bazı önemli uygulamaların olduğu Avrupa’daki büyük bir Telekom ile çalışıyorum. Bunlar AD tabanlı olsa bile, ancak kullanıcıların bu uygulamalar için farklı hesapları vardı – aslında, AD’de 25 farklı hesap türü belirledik! Bu hesapları İK sistemindeki gerçek çalışanlar ve yüklenicilerle eşleştirmek çok fazla araştırma gerektirdi. Açıkçası, şirketten ayrılan çalışanlar ve yüklenicilerin hesaplarının kapatıldığından emin olmakla ilgili sorunlar da vardı.

Baskı Dostu, PDF ve E-posta



Source link