Aracılığıyla paylaş

Kimlik ve ötesine—Mimarlardan birinin bakış açısı

Bu makalede, Microsoft'un Baş Teknik Mimarı Alex Shteynberg, Microsoft 365 ve diğer Microsoft bulut hizmetlerini benimseyen kurumsal kuruluşlara yönelik en iyi tasarım stratejilerini ele almaktadır.

Yazar hakkında

Alex Shteynberg fotoğrafı.

New York Microsoft Teknoloji Merkezi'nde Baş Teknik Mimarım. Çoğunlukla büyük müşteriler ve karmaşık gereksinimlerle çalışıyorum. Bakış açım ve görüşlerim bu etkileşimleri temel alır ve her durum için geçerli olmayabilir. Ancak deneyimlerime göre, müşterilere en karmaşık zorluklar konusunda yardımcı olabilirsek, tüm müşterilere yardımcı olabiliriz.

Normalde her yıl 100'de fazla müşteriyle çalışıyorum. Her kuruluşun benzersiz özellikleri olsa da eğilimleri ve ortak noktaları görmek ilginçtir. Örneğin, bir eğilim birçok müşteri için sektörler arası ilgidir. Sonuçta, banka şubesi bir kafe ve topluluk merkezi de olabilir.

Rolümde, müşterilerin benzersiz iş hedeflerini ele almak için en iyi teknik çözüme ulaşmalarına yardımcı olmaya odaklanıyorum. Resmi olarak Kimlik, Güvenlik, Gizlilik ve Uyumluluk konularına odaklanıyorum. Bu dokunuşların yaptığımız her şeye dokunmasını seviyorum. Çoğu projeyle ilgilenmem için bana bir fırsat veriyor. Bu etkinlik beni meşgul ediyor ve bu rolün tadını çıkarıyor.

New York City'de yaşıyorum (en iyisi!) ve kültürünün, yemeğinin ve insanlarının (trafik değil) çeşitliliğinden gerçekten keyif alıyorum. Ömrüm boyunca dünyanın çoğunu görmeyi umduğum zaman seyahat etmeye bayılırım. Şu anda vahşi yaşam hakkında bilgi edinmek için Afrika'ya bir gezi araştırıyorum.

Yol gösteren ilkeler

  • Basit genellikle daha iyidir: Teknolojiyle (neredeyse) her şeyi yapabilirsiniz, ancak yapmanız gerektiği anlamına gelmez. Özellikle güvenlik alanında, birçok müşteri daha fazla yük devredici çözümler sunar. Google'ın Stripe konferansındaki bu videodan bu noktanın altını çiziyorum.
  • Kişiler, süreç, teknoloji: İnsanların süreci geliştirmesi için tasarım, önce teknoloji değil. "Mükemmel" çözümler yoktur. Her işletme için farklı olabilecek çeşitli risk faktörlerini ve kararları dengelememiz gerekir. Çok fazla müşteri, kullanıcılarının daha sonra kaçındıkları bir yaklaşım tasarlar.
  • Önce 'neden' ve sonra 'nasıl' üzerine odaklanın: Milyonlarca sorusu olan sinir bozucu 7-yr yaşlı çocuk olun. Sorulabilecek doğru soruları bilmiyorsak doğru yanıta ulaşamayız. Birçok müşteri, iş sorununu tanımlamak yerine işlerin nasıl çalışması gerektiği konusunda varsayımlarda bulunur. Her zaman alınabilecek birden çok yol vardır.
  • Geçmiş en iyi yöntemlerin uzun kuyruğu: En iyi yöntemlerin ışık hızında değiştiğini fark edin. Üç aydan uzun bir süre önce Microsoft Entra baktıysanız, muhtemelen eskimişsinizdir. Buradaki her şey yayından sonra değişebilir. "En iyi" seçenek bugünden itibaren altı ay sonra aynı olmayabilir.

Temel kavramlar

Bu bölümü atlamayın. Bulut hizmetlerini yıllardır kullanan müşteriler için bile bu makalelere geri adım atmam gerektiğini sık sık fark ediyorum. Ne yazık ki, dil kesin bir araç değildir. Genellikle aynı sözcüğü farklı kavramlar veya aynı kavram anlamına gelen farklı sözcükler için kullanırız. Temel terminoloji ve "hiyerarşi modeli" oluşturmak için genellikle aşağıdaki diyagramı kullanıyorum.

Kiracı, abonelik, hizmet ve verilerin çizimi.

Yüzmeyi öğrendiğinizde, okyanusun ortasında değil havuzdan başlamak daha iyidir. Bu diyagramda teknik olarak doğru olmaya çalışmıyorum. Bazı temel kavramların tartışıldığı bir modeldir.

Diyagramda:

  • Kiracı = Microsoft Entra ID örneği. Hiyerarşinin "en üstünde" veya diyagramda Düzey 1'de yer alır. Bu düzeyi, diğer her şeyin gerçekleştiği "sınır" olarak düşünebiliriz (Microsoft Entra B2B bir yana). Tüm Microsoft kurumsal bulut hizmetleri bu kiracılardan birinin parçasıdır. Tüketici hizmetleri ayrıdır. "Kiracı", belgelerde Microsoft 365 kiracısı, Azure kiracısı, WVD kiracısı vb. olarak görünür. Bu çeşitlemelerin müşteriler için karışıklığa neden olduğunu sık sık buluyorum.
  • Diyagramdaki Düzey 2 olan hizmetler/abonelikler tek bir kiracıya aittir. SaaS hizmetlerinin çoğu 1:1'dir ve geçiş olmadan taşınamaz. Azure farklıdır; faturalamayı ve/veya aboneliği başka bir kiracıya taşıyabilirsiniz. Azure aboneliklerini taşıması gereken birçok müşteri vardır. Bu senaryo çeşitli etkilere sahiptir. Aboneliğin dışında bulunan nesneler taşınmaz. Örneğin rol tabanlı erişim denetimi (Azure RBAC), Microsoft Entra nesneleri (gruplar, uygulamalar, ilkeler vb.) ve bazı hizmetler (Azure Key Vault, Veri Tuğlaları vb.). İyi bir iş gereksinimi olmadan hizmetleri geçirmeyin. Geçiş için yararlı olabilecek bazı betikler GitHub'da paylaşılır.
  • Belirli bir hizmetin genellikle bir tür "alt düzey" sınırı veya Düzey 3 (L3) vardır. Bu sınır, güvenlik, ilkeler, idare vb. ayrımını anlamak için kullanışlıdır. Ne yazık ki bildiğim tek tip bir isim yok. L3 için bazı örnek adlar şunlardır: Azure Aboneliği = kaynak; Dynamics 365 CE = örnek; Power BI = çalışma alanı; Power Apps = ortam; ve benzeri.
  • Düzey 4, gerçek verilerin bulunduğu yerdir. Bu 'veri düzlemi' karmaşık bir makaledir. Bazı hizmetler RBAC için Microsoft Entra ID kullanıyor, diğerleri kullanmıyor. Temsilci makalelerine gelince bunu biraz tartışacağım.

Birçok müşteriyi (ve Microsoft çalışanlarını) bulduğum diğer kavramlar arasında kafa karışıklığı var veya bunlarla ilgili sorularım var:

  • Herkes hiçbir ücret ödemeden birçok kiracı oluşturabilir. Hizmetin içinde sağlanmış bir hizmete ihtiyacınız yoktur. Bende onlarca var. Her Kiracı adı, Microsoft'un dünya çapındaki bulut hizmetinde benzersizdir (başka bir deyişle, iki kiracı aynı ada sahip olamaz). Hepsi TenantName.onmicrosoft.com biçiminde. Kiracıları otomatik olarak (yönetilmeyen kiracılar) oluşturan işlemler de vardır. Örneğin, bir kullanıcı başka bir kiracıda mevcut olmayan bir e-posta etki alanıyla kurumsal hizmete kaydolduğunda bu sonuç oluşabilir.
  • Yönetilen bir kiracıda, birçok DNS etki alanı bu kiracıya kaydedilebilir. Bu sonuç, özgün kiracı adını değiştirmez. Şu anda kiracıyı yeniden adlandırmanın kolay bir yolu yoktur (geçiş dışında). Kiracı adı teknik olarak kritik olmasa da, bazı kişiler bu gerçeklikle sınırlı hissedebilir.
  • Henüz herhangi bir hizmet dağıtmayı planlamasanız bile kuruluşunuz için bir kiracı adı ayırmanız gerekir. Aksi takdirde, birisi bunu sizden alabilir ve geri almak için basit bir işlem yoktur (DNS adları ile aynı sorun). Müşterilerden bu şekilde çok sık duyuyorum. Kiracı adınızın ne olması gerektiği de bir tartışma makalesi.
  • DNS ad alanınız varsa, bu ad alanlarının tümünü kiracılarınıza eklemeniz gerekir. Aksi takdirde, bu adla yönetilmeyen bir kiracı oluşturulabilir ve bu da yönetilmelerini sağlamak için kesintiye neden olur.
  • DNS ad alanı (örneğin, contoso.com) tek bir kiracıya ait olabilir. Bu gereksinimin çeşitli senaryolar üzerinde etkileri vardır (örneğin, birleştirme veya alma sırasında e-posta etki alanını paylaşma vb.). Dns alt öğesini (div.contoso.com gibi) farklı bir kiracıya kaydetmenin bir yolu vardır, ancak bundan kaçınılmalıdır. Üst düzey etki alanı adı kaydedildiğinde, tüm alt etki alanları aynı kiracıya ait olduğu varsayılır. Çok kiracılı senaryolarda (daha sonra açıklandığı gibi) normalde başka bir üst düzey etki alanı adı (contoso.ch veya ch-contoso.com gibi) kullanmanızı öneririm.
  • Kim kiracıya "sahip olmalıdır"? Kiracılarının sahibini bilmeyen müşterileri sık sık görüyorum. Bu bilgi eksikliği önemli bir kırmızı bayraktır. Microsoft desteğini en kısa sürede arayın. Aynı sorun, bir hizmet sahibinin (genellikle Exchange yöneticisi) kiracıyı yönetmek üzere atandığında olduğu gibi. Kiracı, gelecekte isteyebileceğiniz tüm hizmetleri içerir. Kiracı sahibi, bir kuruluştaki tüm bulut hizmetlerinin etkinleştirilmesi için karar verebilen bir grup olmalıdır. Bir diğer sorun da kiracı sahibi grubunun tüm hizmetleri yönetmesi istendiğinde oluşur. Bu yöntem büyük kuruluşlar için ölçeklendirilmiyor.
  • Alt/süper kiracı kavramı yoktur. Nedense, bu efsane kendini tekrar ediyor. Bu kavram Azure Active Directory B2C kiracıları için de geçerlidir. "B2C ortamım XYZ Kiracımda" veya "Azure kiracımı Microsoft 365 kiracıma taşımak Nasıl yaparım??"
  • Bu belge çoğunlukla ticari dünya çapındaki buluta odaklanır, çünkü çoğu müşteri bunu kullanıyor. Bazen bağımsız bulutlar hakkında bilgi edinmek yararlı olabilir. Bağımsız bulutların, bu tartışmanın kapsamı dışında olan başka etkileri de vardır.

Temel kimlik makaleleri

Microsoft'un kimlik platformu hakkında çok fazla belge vardır: Microsoft Entra ID. Yeni başlayan insanlar için, genellikle bunaltıcı bir histir. Bu konuda bilgi edindikten sonra bile sürekli yeniliğe ve değişikliğe ayak uydurmak zor olabilir. Müşteri etkileşimlerimde, iş hedefleri ile bu endişeleri gidermek için "İyi, Daha İyi, En İyi" yaklaşımlar (ve bu makaleler için insan "uçurum notları" gibi) arasında "çevirmen" olarak görev yapıyorum. Nadiren mükemmel bir yanıt vardır ve "doğru" karar çeşitli risk faktörlerinin bir dengesidir. Sırada müşterilerle tartışma eğiliminde olduğum bazı yaygın sorular ve karışıklık alanları yer almaktadır.

Sağlama

Microsoft Entra ID, kimlik dünyanızdaki idare eksikliğini çözmez! Kimlik idaresi , bulut kararlarından bağımsız olarak kritik bir öğe olmalıdır. İdare gereksinimleri zaman içinde değişir, bu nedenle bir araç değil, bir programdır.

Connect ile Microsoft Identity Manager (MIM) ve başka bir şey (üçüncü taraf veya özel) karşılaştırması Microsoft Entra? Şimdi ve gelecekte sorunlardan kurtulup Microsoft Entra Connect'i kullanmaya devam edin. Bu araçta, kendine özgü müşteri yapılandırmalarını ve sürekli yenilikleri ele almak için her türlü akıllı vardır.

Daha karmaşık bir mimariye yönlendirebilecek bazı uç durumlar:

  • Aralarında ağ bağlantısı olmayan birden çok AD ormanım var. Bulut Sağlama adlı yeni bir seçenek vardır.
  • Active Directory'm yok ve yüklemek de istemiyorum. Microsoft Entra Connect, LDAP'den eşitlemek için yapılandırılabilir (iş ortağı gerekebilir).
  • Aynı nesneleri birden çok kiracıya sağlamam gerekiyor. Bu senaryo teknik olarak desteklenmemektedir ancak "aynı" tanımına bağlıdır.

Varsayılan eşitleme kurallarını (nesneleri filtreleme, öznitelikleri değiştirme, alternatif oturum açma kimliği vb.) özelleştirmeli miyim? Bundan kaçının! Kimlik platformu yalnızca onu kullanan hizmetler kadar değerlidir. Her türlü çatlak yapılandırmayı yapabilirsiniz ancak bu soruyu yanıtlamak için uygulamalar üzerindeki etkisine bakmanız gerekir. Posta özellikli nesneleri filtrelerseniz, çevrimiçi hizmetler için GAL tamamlanmamış olur; uygulama belirli özniteliklere dayanırsa, bu öznitelikleri filtrelemenin öngörülemeyen etkileri vardır ve bu şekilde devam eder. Bu bir kimlik ekibi kararı değil.

XYZ SaaS Tam Zamanında (JIT) sağlamayı destekliyor, neden eşitlememi istiyorsunuz? Önceki paragrafa bakın. Birçok uygulamanın işlevsellik için "profil" bilgilerine ihtiyacı vardır. Posta özellikli tüm nesneler kullanılamıyorsa GAL'niz olamaz. Aynı durum, Microsoft Entra ID ile tümleştirilmiş uygulamalarda kullanıcı sağlama için de geçerlidir.

Kimlik Doğrulama

Parola karması eşitleme (PHS) ile geçişli kimlik doğrulaması (PTA) ve federasyon karşılaştırması.

Genellikle federasyonla ilgili tutkulu bir tartışma olur. Daha basit genellikle daha iyidir ve bu nedenle bunu yapmak için iyi bir nedeniniz yoksa PHS kullanın. Aynı kiracıdaki farklı DNS etki alanları için farklı kimlik doğrulama yöntemleri de yapılandırılabilir.

Bazı müşteriler genellikle şunlar için federasyon + PHS'yi etkinleştirir:

Bazı yanlış algıları netleştirmek için müşterilere genellikle istemci kimlik doğrulama akışında yol gösteririm. Sonuç aşağıdaki resme benzer ve bu, etkileşimli oraya varma işlemi kadar iyi değildir.

Örnek beyaz tahta konuşması.

Bu beyaz tahta çizimi, güvenlik ilkelerinin bir kimlik doğrulama isteğinin akışı içinde nereye uygulandığını gösterir. Bu örnekte, Active Directory Federasyon Hizmeti (AD FS) aracılığıyla uygulanan ilkeler ilk hizmet isteğine uygulanır, ancak sonraki hizmet isteklerine uygulanmaz. Bu davranış, güvenlik denetimlerini mümkün olduğunca buluta taşımak için en az bir nedendir.

Hatırlayabildiğim kadar uzun süredir çoklu oturum açma (SSO) hayalinin peşindeyiz. Bazı müşteriler , "doğru" federasyon (STS) sağlayıcısını seçerek çoklu oturum açmayı başarabileceklerine inanıyor. Microsoft Entra ID SSO özelliklerini etkinleştirmeye önemli ölçüde yardımcı olabilir, ancak hiçbir STS sihirli değildir. Kritik uygulamalar için hala kullanılan çok fazla "eski" kimlik doğrulama yöntemi vardır. Microsoft Entra ID iş ortağı çözümleriyle genişletilmesi bu senaryoların çoğunu ele alabilir. SSO bir strateji ve bir yolculuk. Uygulamalar için standartlara geçmeden oraya ulaşamazsınız. Bu makaleyle ilgili olarak, sihirli bir yanıtı olmayan parolasız kimlik doğrulamasına yönelik bir yolculuk vardır.

Çok faktörlü kimlik doğrulaması (MFA) bugün çok önemlidir (daha fazlası için burada ). Buna kullanıcı davranışı analizini eklediğinizde en yaygın siber saldırıları önleyen bir çözümünüz vardır. Tüketici hizmetleri bile MFA gerektirmek üzere hareket ediyor. Yine de modern kimlik doğrulama yaklaşımlarına geçmek istemeyen birçok müşteriyle görüşüyorum. Duyduğum en büyük bağımsız değişken, kullanıcıları ve eski uygulamaları etkilediğini ifade ediyor. Bazen iyi bir tekme müşterilerin ilerlemelerine yardımcı olabilir - Exchange Online duyurulan değişiklikler. Müşterilerin bu geçişte yardımcı olması için birçok Microsoft Entra raporu kullanıma sunulmuştur.

İzin

Wikipedia başına , "yetkilendirmek" bir erişim ilkesi tanımlamaktır. Birçok kişi buna bir nesneye (dosya, hizmet vb.) erişim denetimleri tanımlama özelliği olarak bakar. Mevcut siber tehdit dünyasında bu kavram, çeşitli tehdit vektörlerine tepki verebilen ve bunlara yanıt olarak erişim denetimlerini hızlı bir şekilde ayarlayabilen dinamik bir politikaya hızla gelişmektedir. Örneğin, olağan dışı bir konumdan banka hesabıma erişirsem ek onay adımları alıyorum. Bu gerçekliğe yaklaşmak için yalnızca ilkenin kendisini değil, tehdit algılama ve sinyal bağıntı yöntemleri ekosistemini de göz önünde bulundurmamız gerekir.

Microsoft Entra ID ilke altyapısı Koşullu Erişim ilkeleri kullanılarak uygulanır. Bu sistem, dinamik kararlar almak için diğer tehdit algılama sistemlerinden gelen bilgilere bağlıdır. Basit bir görünüm aşağıdaki çizime benzer olacaktır:

Microsoft Entra ID'da ilke altyapısı.

Tüm bu sinyallerin birleştirilmesi aşağıdaki gibi dinamik ilkelere olanak tanır:

  • Cihazınızda bir tehdit algılanırsa, verilere erişiminiz yalnızca indirme özelliği olmadan web'e indirilir.
  • Alışılmadık derecede yüksek miktarda veri indiriyorsanız, indirdiğiniz her şey şifrelenir ve kısıtlanır.
  • Yönetilmeyen bir cihazdan bir hizmete erişirseniz, yüksek oranda hassas verilere erişiminiz engellenir ancak başka bir konuma kopyalama olanağı olmadan kısıtlanmamış verilere erişmenize izin verilir.

Bu genişletilmiş yetkilendirme tanımına katılıyorsanız ek çözümler uygulamanız gerekir. Hangi çözümleri uygulayabileceğiniz, ilkenin ne kadar dinamik olmasını istediğinize ve öncelik vermek istediğiniz tehditlere bağlıdır. Bu tür sistemlere bazı örnekler şunlardır:

Microsoft Entra ID ek olarak, çeşitli hizmet ve uygulamaların kendi özel yetkilendirme modelleri vardır. Bu modellerden bazıları daha sonra temsilci seçme bölümünde ele alınmıştır.

Denetim

Microsoft Entra ID ayrıntılı denetim ve raporlama özelliklerine sahiptir. Ancak bu raporlar genellikle güvenlik kararları almak için gereken tek bilgi kaynağı değildir. Temsilci seçme bölümünde bu konuyla ilgili daha fazla tartışmaya bakın.

Exchange yok

Panik yapmayın! Exchange kullanım dışı bırakılmıyor (veya SharePoint vb.). Hala temel bir hizmet. Demek istediğim, bir süredir teknoloji sağlayıcılarının kullanıcı deneyimlerini (UX) birden çok hizmetin bileşenlerini kapsayacak şekilde geçirmesi. Microsoft 365'te, e-posta eklerinin SharePoint Online veya OneDrive'da depolandığı "modern ekler" basit bir örnektir.

E-postaya dosya ekleme.

Outlook istemcisine baktığınızda, yalnızca Exchange'i değil, bu deneyimin bir parçası olarak "bağlı" olan birçok hizmeti görebilirsiniz. Örnek olarak Microsoft Entra ID, Microsoft Search, Uygulamalar, Profil, uyumluluk ve Microsoft 365 grupları verilebilir.

Açıklama balonları içeren Outlook arabirimi.

Yaklaşan özelliklerin önizlemesi için Microsoft Akıcı Çerçeve hakkında bilgi edinin. Artık önizlemede Teams konuşmalarını doğrudan Outlook'ta okuyabilir ve yanıtlayabilirim. Aslında Teams istemcisi bu stratejinin en önemli örneklerinden biridir.

Genel olarak, Microsoft 365 ile Microsoft bulutlarındaki diğer hizmetler arasında net bir çizgi çizmek zorlaşıyor. Tek bir bileşen kullansalar bile yaptığımız her şeyde toplam yenilikten yararlanabilecekleri için bunu müşterilere büyük bir avantaj olarak alıyorum. Oldukça havalı ve birçok müşteri için çok fazla etki var.

Bugün birçok müşteri BT grubunun "ürünler" etrafında yapılandırıldığını düşünüyorum. Her ürün için bir uzmana ihtiyacınız olduğu için şirket içi bir dünya için mantıklıdır. Ancak, bu hizmetler buluta taşındığından bir daha bir Active Directory veya Exchange veritabanında hata ayıklamak zorunda olmadığım için mutluyum. Otomasyon (temel olarak bulut) yinelenen bazı el ile işleri kaldırır (fabrikalara ne olduğuna bakın). Ancak, bu görevler hizmetler arası etkileşimi, etkisini, iş gereksinimlerini vb. anlamak için daha karmaşık gereksinimlerle değiştirilir. Öğrenmeye istekliyseniz bulut dönüştürmenin etkinleştirdiği harika fırsatlar vardır. Teknolojiye atlamadan önce, BT becerilerinde ve ekip yapılarındaki değişikliği yönetme hakkında müşterilerle sık sık konuşuyorum.

Tüm SharePoint hayranları ve geliştiricileri için lütfen "SharePoint Online'da XYZ'yi nasıl yapabilirim?" sorusunu durdurun. İş akışı için Power Automate 'i (veya Flow'ı) kullanın, çok daha güçlü bir platform. 500 K öğe listenize daha iyi bir UX oluşturmak için Azure Bot Framework'i kullanın. CSOM yerine Microsoft Graph kullanmaya başlayın. Microsoft Teams , SharePoint'i ve daha fazlasını içerir. Listeleyebileceğiniz başka birçok örnek daha var. Dışarıda muazzam ve harika bir evren var. Kapıyı açın ve keşfetmeye başlayın.

Diğer yaygın etki uyumluluk alanındadır. Bu hizmetler arası yaklaşım birçok uyumluluk ilkesini tamamen karıştırıyor gibi görünüyor. "Tüm e-posta iletişimlerini bir eBulma sistemine günlüğe kaydetmeliyim" diyen kuruluşlar görüyorum. E-posta artık yalnızca e-posta değil diğer hizmetlere açılan bir pencere olduğunda bu ifade gerçekten ne anlama geliyor? Microsoft 365,uyumluluk için kapsamlı bir yaklaşıma sahiptir, ancak insan ve süreçleri değiştirmek genellikle teknolojiden çok daha zordur.

Başka birçok kişi ve sürecin etkileri vardır. Bence bu faktör kritik ve çok tartışılmamış bir alan. Belki de başka bir makalede daha fazlası.

Kiracı yapısı seçenekleri

Tek kiracı ve çok kiracılı

Genel olarak, çoğu müşterinin yalnızca bir üretim kiracısı olmalıdır. Birden çok kiracının zor olmasının birçok nedeni vardır ( Bing araması verin) veya bu teknik incelemeyi okuyun. Aynı zamanda, birlikte çalıştığım birçok kurumsal müşterinin BT öğrenmesi, testi ve denemesi için başka bir (küçük) kiracısı var. Azure Lighthouse ile kiracılar arası Azure erişimi daha kolay hale getiriliyor. Microsoft 365 ve diğer birçok SaaS hizmeti, kiracılar arası senaryolar için sınırlara sahiptir. Microsoft Entra B2B senaryolarında dikkate alınması gereken çok şey vardır.

Birçok müşteri bir birleşme ve alımdan (M&A) sonra birden çok üretim kiracısına sahip olur ve birleştirmek ister. Bugün bu basit değildir ve Microsoft Danışmanlık Hizmetleri (MCS) veya bir iş ortağı artı üçüncü taraf yazılım gerektirir. Gelecekte çok kiracılı müşterilerle çeşitli senaryoları ele almak için devam eden mühendislik çalışmaları vardır.

Bazı müşteriler birden fazla kiracıyla gitmeyi tercih edebilir. Bu dikkatli bir karar olmalı ve neredeyse her zaman iş nedeni odaklı olmalıdır! Bazı örnekler aşağıdaki nedenleri içerir:

  • Farklı varlıklar arasında kolay işbirliği gerektiren ve güçlü yönetim ve diğer yalıtım gereksinimlerinin bulunduğu bir holding türü şirket yapısı.
  • Bir alımdan sonra, iki varlığı ayrı tutmak için bir iş kararı velanır.
  • Müşterinin üretim ortamını değiştirmeyen müşterinin ortamının simülasyonu.
  • Müşteriler için yazılım geliştirme.

Bu çok kiracılı senaryolarda müşteriler genellikle bazı yapılandırmaları kiracılar arasında aynı tutmak veya yapılandırma değişiklikleri ve kaymaları hakkında rapor vermek ister. Bu genellikle el ile yapılan değişikliklerden kod olarak yapılandırmaya geçiş anlamına gelir. Microsoft Premiere desteği, şu genel IP'yi temel alan bu tür gereksinimler için bir atölye sunar: https://Microsoft365dsc.com.

Multi-Geo

Multi-Geo'ya veya Multi-Geo'ya değil. Asıl soru bu. Microsoft 365 Multi-Geo ile veri yerleşimi gereksinimlerini karşılamayı seçtiğiniz coğrafi konumlarda bekleyen verileri sağlayabilir ve depolayabilirsiniz. Bu özellik hakkında birçok yanlış algı vardır. Aşağıdaki noktaları göz önünde bulundurun:

  • Performans avantajları sağlamaz. Ağ tasarımı doğru değilse performansı daha kötü hale getirebilir. Cihazları verilerinize değil Microsoft ağına "yakın" alın.
  • GDPR uyumluluğu için bir çözüm değildir. GDPR, veri hakimiyetine veya depolama konumlarına odaklanmaz. Veri hakimiyeti veya depolama konumları için başka uyumluluk çerçeveleri vardır.
  • Yönetim temsilcisi seçme (aşağıya bakın) veya bilgi engellerini çözmez.
  • Çok kiracılı ile aynı değildir ve daha fazla kullanıcı sağlama iş akışı gerektirir.
  • Kiracınızı (Microsoft Entra ID) başka bir coğrafyaya taşımaz.

Yönetim temsilcisi

Çoğu büyük kuruluşta görev ayrımı ve rol tabanlı erişim denetimi (RBAC) gerekli bir gerçekliktir. Önceden özür dileyeceğim. Bu etkinlik bazı müşterilerin istediği kadar basit değildir. Müşteri, yasal, uyumluluk ve diğer gereksinimler farklıdır ve bazen dünya çapında çakışıyor. Basitlik ve esneklik genellikle birbirinin karşı tarafındadır. Yanlış anlamadım, bu amaç için daha iyi bir iş yapabiliriz. Zaman içinde önemli geliştirmeler yapıldı (ve olacak). 379.230 belgesini okumadan iş gereksinimlerinize uygun modeli bulmak için yerel Microsoft Teknoloji Merkezinizi ziyaret edin! Burada, neden böyle olduğunu değil, düşünmeniz gereken şeylere odaklanıyorum. Plan yapmak için beş farklı alan ve karşılaştığım bazı yaygın sorular geliyor.

Microsoft Entra ID ve Microsoft 365 yönetim merkezleri

Yerleşik rollerin uzun ve büyüyen bir listesi vardır. Her rol, belirli eylemlerin gerçekleştirilebilmesine izin vermek için birlikte gruplandırılmış rol izinlerinin bir listesinden oluşur. Bu izinleri her rolün içindeki "Açıklama" sekmesinde görebilirsiniz. Alternatif olarak, Microsoft 365 Yönetici Merkezi'nde bu izinlerin daha insan tarafından okunabilir bir sürümünü görebilirsiniz. Yerleşik rollerin tanımları değiştirilemez. Genel olarak bu rolleri üç kategoride gruplandırıyorum:

  • Genel yönetici: Bu "tüm güçlü" rol, diğer sistemlerde olduğu gibi yüksek oranda korunmalıdır. Tipik öneriler şunlardır: kalıcı atama yok ve Microsoft Entra Privileged Identity Management (PIM) kullanma; güçlü kimlik doğrulaması ve benzeri. İlginçtir ki, bu rol varsayılan olarak her şeye erişmenize izin vermez. Genellikle, uyumluluk erişimi ve Azure erişimi hakkında daha sonra tartışılan karışıklıklar görüyorum. Ancak, bu rol her zaman kiracıdaki diğer hizmetlere erişim atayabilir.
  • Belirli hizmet yöneticileri: Bazı hizmetler (Exchange, SharePoint, Power BI vb.) Microsoft Entra ID üst düzey yönetim rollerini kullanır. Bu davranış tüm hizmetler arasında tutarlı değildir ve daha sonra ele alınan hizmete özgü daha fazla rol vardır.
  • İşlevsel: Belirli işlemlere (konuk davet eden, vb.) odaklanan rollerin uzun (ve büyüyen) bir listesi vardır. Düzenli aralıklarla, bu rollerin daha fazlası müşteri ihtiyaçlarına göre eklenir.

Her şeye temsilci seçmek mümkün değildir (boşluk azalsa da), bu da Genel yönetici rolünün bazen kullanılması gerektiği anlamına gelir. Bu rolün kişi üyeliği yerine kod olarak yapılandırma ve otomasyon dikkate alınmalıdır.

Not: Microsoft 365 yönetim merkezi daha kullanıcı dostu bir arabirime sahiptir ancak Microsoft Entra yönetici deneyimine kıyasla özelliklerin bir alt kümesine sahiptir. Her iki portal da aynı Microsoft Entra rollerini kullandığından, değişiklikler aynı yerde gerçekleşir. İpucu: Tüm Azure dağınıklığı olmadan kimlik yönetimi odaklı bir yönetici kullanıcı arabirimi istiyorsanız kullanın https://aad.portal.azure.com.

Adında ne var? Rolün adından varsayımlarda bulunmayın. Dil kesin bir araç değildir. Amaç, hangi rollerin gerekli olduğuna bakmadan önce temsilci olarak atanması gereken işlemleri tanımlamak olmalıdır. Birini "Güvenlik Okuyucusu" rolüne eklemek, her şeyin güvenlik ayarlarını görmesine neden olmaz.

Özel roller oluşturma özelliği yaygın bir sorudur. Bu özellik bugün Microsoft Entra sınırlıdır (daha sonra açıklandığı gibi), ancak zamanla özellikler artacaktır. Bu özel rollerin Microsoft Entra ID'deki işlevler için geçerli olduğunu düşünüyorum ve hiyerarşi modelini "aşağı" yayamayabilirim (daha önce açıklandığı gibi). "Özel" ile ne zaman ilgilensem, "basit daha iyidir" müdürüme geri dönme eğilimindeyim.

Sık sorulan bir diğer soru da rollerin bir dizinin alt kümesine göre kapsam oluşturabilmesidir. Bir örnek, "Yalnızca AB'deki kullanıcılar için Yardım Masası Yöneticisi" gibi bir örnektir. Yönetim Birimleri bu senaryoya yöneliktir. Daha önce açıklandığı gibi, bu kapsamların Microsoft Entra ID'daki işlevler için geçerli olduğunu düşünüyorum ve "aşağı" yayılmayabilir. Bazı rollerin kapsamının (genel yöneticiler, hizmet yöneticileri vb.) kapsamı anlamlı değildir.

Bugün, tüm bu roller doğrudan üyelik (veya Microsoft Entra PIM kullanıyorsanız dinamik atama) gerektirir. Bu, müşterilerin bu rolü doğrudan Microsoft Entra ID yönetmesi gerektiği ve bu rollerin bir güvenlik grubu üyeliğine dayanabileceği anlamına gelir. Yükseltilmiş haklarla çalışması gerekeceğinden bu rolleri yönetmek için betikler oluşturmayı pek sevmem. Genellikle ServiceNow gibi işlem sistemleriyle veya Saviynt gibi iş ortağı idare araçlarını kullanarak API tümleştirmesi öneriyorum. Zaman içinde bu sorunu çözmek için mühendislik çalışmaları devam edecek.

PIM Microsoft Entra birkaç kez bahsettim. Şirket içi denetimler için karşılık gelen bir Microsoft Identity Manager (MIM) Privileged Access Management (PAM) çözümü vardır. Ayrıca Privileged Access Workstations (PAW) ve Microsoft Entra ID Yönetimi de bakmak isteyebilirsiniz. Aynı zamanda tam zamanında, yeterli ve dinamik rol yükseltmeyi etkinleştirebilen çeşitli üçüncü taraf araçlar da vardır. Bu özellik genellikle ortamın güvenliğini sağlamaya yönelik daha büyük bir tartışmanın parçasıdır.

Bazen senaryolar bir role dış kullanıcı eklemeyi çağırır (önceki çok kiracılı bölüme bakın). Bu sonuç düzgün çalışır. Microsoft Entra B2B, belki de başka bir makalede müşterilere yol gösteren başka bir büyük ve eğlenceli makaledir.

Microsoft Defender XDR ve Microsoft Purview portalları

Email & Microsoft Defender portalındaİşbirliği rolleri ve Microsoft Purview portalındaki*Microsoft Purview çözümleri için rol grupları, Microsoft Entra rollerden ayrı ve ayrı olan bir "rol grupları" koleksiyonu. Bu rol gruplarından bazıları Microsoft Entra rolleriyle (örneğin, Güvenlik Okuyucusu) aynı ada sahip olduğundan, ancak farklı üyelikleri olabileceğinden bu durum kafa karıştırıcı olabilir. Microsoft Entra rollerini kullanmayı tercih ediyorum. Her rol grubu bir veya daha fazla "rolden" oluşur (aynı sözcüğü yeniden kullanma hakkında ne demek istediğimi görün?) ve e-posta özellikli nesneler olan Microsoft Entra ID üyeleri vardır. Ayrıca, rolle aynı ada sahip bir rol grubu oluşturabilirsiniz. Bu rol, bu rolü içerebilir veya içermeyebilir (bu karışıklığı önleyin).

Bir anlamda, bu izinler Exchange rol grupları modelinin bir evrimidir. Ancak Exchange Online kendi rol grubu yönetim arabirimine sahiptir. Exchange Online'daki bazı rol grupları kilitlenir ve Microsoft Entra ID veya Microsoft Defender XDR ve Microsoft Purview portallarından yönetilir, ancak diğerleri aynı veya benzer adlara sahip olabilir ve Exchange Online (karışıklığa ek olarak) içinde yönetilir. Exchange yönetimi için kapsamlara ihtiyacınız yoksa Exchange Online kullanıcı arabirimini kullanmaktan kaçınmanızı öneririz.

Özel roller oluşturamazsınız. Roller, Microsoft tarafından oluşturulan hizmetler tarafından tanımlanır ve yeni hizmetler kullanıma sunulduğunda büyümeye devam eder. Bu davranış, kavram olarak Microsoft Entra ID uygulamalar tarafından tanımlanan rollere benzer. Yeni hizmetler etkinleştirildiğinde, bunlara erişim izni vermek veya bunlara temsilci atamak için genellikle yeni rol gruplarının oluşturulması gerekir (örneğin, insider risk yönetimi).

Bu rol grupları doğrudan üyelik gerektirir ve Microsoft Entra grupları içeremez. Ne yazık ki bugün bu rol grupları Microsoft Entra PIM tarafından desteklenmemektedir. Microsoft Entra roller gibi, bu rol gruplarının API'ler veya Saviynt gibi bir iş ortağı idare ürünü veya diğerleri aracılığıyla yönetilmesini önerme eğilimindeyim.

Microsoft Defender portalı ve Microsoft Purview portalı rolleri Microsoft 365'e yayılmıştır ve bu rol gruplarının kapsamını ortamın bir alt kümesine (Microsoft Entra ID yönetim birimleriyle yapabileceğiniz gibi) ekleyemezsiniz. Birçok müşteri nasıl altdelem yapabileceklerini soruyor. Örneğin, "yalnızca AB kullanıcıları için bir DLP ilkesi oluşturun." Bugün, Microsoft Defender XDR ve Microsoft Purview portallarında belirli bir işlev üzerinde haklarınız varsa, kiracıda bu işlevin kapsadığı her şey üzerinde haklarınız vardır. Ancak, birçok ilke ortamın bir alt kümesini hedeflemeye yönelik özelliklere sahiptir (örneğin, "bu etiketleri yalnızca bu kullanıcılar için kullanılabilir hale getirme"). Doğru idare ve iletişim, çakışmaları önlemek için önemli bir bileşendir. Bazı müşteriler, Microsoft Defender XDR ve Microsoft Purview portallarında alt teslimi ele almak için "kod olarak yapılandırma" yaklaşımını uygulamayı tercih eder. Bazı belirli hizmetler alt teslimi destekler (sonraki bölüme bakın).

Hizmete Özgü

Daha önce belirtildiği gibi, birçok müşteri daha ayrıntılı bir temsil modeli elde etmek için aramaktadır. Yaygın bir örnek: "XYZ hizmetini yalnızca Bölüm X kullanıcıları ve konumları için yönetme" (veya başka bir boyut). Bunu yapabilme özelliği her hizmete bağlıdır ve hizmetler ve yetenekler arasında tutarlı değildir. Ayrıca, her hizmetin ayrı ve benzersiz bir RBAC modeli olabilir. Bu modellerin tümünü tartışmak yerine (bu işlem sonsuza kadar sürer), her hizmet için ilgili bağlantılar ekliyorum. Bu liste tamamlanamadı, ancak başlamanıza neden olabilir.

  • Exchange Online - (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online - (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams - (/microsoftteams/itadmin-readiness)
  • eBulma - (.. /compliance/index.yml)
    • İzin Filtreleme - (.. /compliance/index.yml)
    • Uyumluluk Sınırları - (.. /compliance/set-up-compliance-boundaries.md)
    • eBulma (Premium) - (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Multi-geo - (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 – (/dynamics365/)

Not

Bu bağlantı, belgelerin köküne bağlantıdır. Yönetici/temsilci modelinde varyasyonları olan birden çok hizmet türü vardır.

  • Power Platform - (/power-platform/admin/admin-documentation)

    • Power Apps - (/power-platform/admin/wp-security)

      Not

      yönetici/temsilci modellerinde varyasyonları olan birden çok tür vardır.

    • Power Automate - (/power-automate/environments-overview-admin)

    • Power BI - (/power-bi/service-admin-governance)

      Not: Veri platformu güvenliği ve temsilcisi (Power BI bir bileşendir) karmaşık bir alandır.

  • Intune - (/mem/intune/fundamentals/role-based-access-control)

  • Uç Nokta için Microsoft Defender - (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (.. /security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps - (/cloud-app-security/manage-admins)

  • Stream - (/stream/assign-administrator-user-role)

  • Bilgi engelleri - (.. /compliance/information-barriers.md)

Etkinlik Günlükleri

Microsoft 365'in birleşik bir denetim günlüğü vardır. Bu çok ayrıntılı bir günlük, ancak adı çok fazla okumayın. Güvenlik ve uyumluluk gereksinimleriniz için istediğiniz veya ihtiyacınız olan her şeyi içermeyebilir. Ayrıca, bazı müşteriler Denetim (Premium) ile çok ilgileniyor.

Diğer API'ler aracılığıyla erişilen Microsoft 365 günlüklerine örnek olarak aşağıdaki özellikler verilebilir:

Öncelikle bir güvenlik ve uyumluluk programı için gereken tüm günlük kaynaklarını belirlemek önemlidir. Ayrıca, farklı günlüklerin farklı satır içi saklama sınırlarına sahip olduğunu unutmayın.

Yönetici temsilcisi açısından bakıldığında, Microsoft 365 etkinlik günlüklerinin çoğunda yerleşik bir RBAC modeli yoktur. Bir günlüğü görme izniniz varsa, içindeki her şeyi görebilirsiniz. Müşteri gereksinimine yaygın bir örnek: "Etkinliği yalnızca AB kullanıcıları için sorgulayabilmek istiyorum" (veya başka bir boyut). Bu gereksinimi sağlamak için günlükleri başka bir hizmete aktarmamız gerekir. Microsoft bulutunda bunu Microsoft Sentinel veya Log Analytics'e aktarmanızı öneririz.

Üst düzey diyagram:

güvenlik ve uyumluluk programı için günlük kaynaklarının diyagramı.

Diyagram, Günlükleri Event Hubs'a ve/veya Azure Depolama'ya ve/veya Azure Log Analytics'e göndermeye yönelik yerleşik özellikleri temsil eder. Henüz tüm sistemlerde bu kullanıma uygun sistem yok. Ancak bu günlükleri aynı depoya göndermek için başka yaklaşımlar da vardır. Örneğin bkz. Microsoft Sentinel ile Teams'inizi koruma.

Tüm günlüklerin tek bir depolama konumunda birleştirilmesi, çapraz bağıntılar, özel saklama süreleri, RBAC modelini desteklemek için gereken verilerle artırma gibi ek faydalar içerir. Veriler bu depolama sistemine eklendikten sonra, uygun bir RBAC modeline sahip bir Power BI panosu (veya başka bir görselleştirme türü) oluşturabilirsiniz.

Günlüklerin yalnızca bir yere yönlendirilmesi gerekmez. Microsoft 365 GünlükleriniPower BI'da Microsoft Defender for Cloud Apps veya özel bir RBAC modeliyle tümleştirmek de yararlı olabilir. Farklı depoların farklı avantajları ve hedef kitleleri vardır.

Microsoft Defender XDR adlı bir hizmette güvenlik, tehditler, güvenlik açıkları vb. için zengin bir yerleşik analiz sistemi olduğunu belirtmek gerekir.

Birçok büyük müşteri bu günlük verilerini üçüncü taraf bir sisteme (örneğin, SIEM) aktarmak ister. Bu sonuç için farklı yaklaşımlar vardır, ancak genel olarak Azure Event Hubs ve Graph iyi başlangıç noktalarıdır.

Azure

Genellikle Microsoft Entra ID, Azure ve SaaS arasında yüksek ayrıcalıklı rolleri ayırmanın bir yolu olup olmadığı sorulur (örneğin: Microsoft 365 için Genel Yönetici ancak Azure'da değil). Pek değil. Tam yönetim ayrımı gerekiyorsa çok kiracılı mimari gereklidir, ancak bu önemli bir karmaşıklık ekler (daha önce açıklandığı gibi). Tüm bu hizmetler aynı güvenlik/kimlik sınırının bir parçasıdır (hiyerarşi modelinde gösterildiği gibi).

Aynı kiracıdaki çeşitli hizmetler arasındaki ilişkileri anlamak önemlidir. Azure, Microsoft 365 ve Power Platform'a (ve genellikle şirket içi ve üçüncü taraf bulut hizmetlerine) yayılan iş çözümleri oluşturan birçok müşteriyle çalışıyorum. Yaygın örneklerden biri:

  1. Bir dizi belge/görüntü/vb üzerinde işbirliği yapmak istiyorum (Microsoft 365)
  2. Her birini bir onay işlemi aracılığıyla gönderme (Power Platform)
  3. Tüm bileşenler onaylandıktan sonra, bu öğeleri birleşik bir teslim edilebilir (Azure) (Azure) olarak bir araya getirerek Microsoft Graph API burada en iyi arkadaşınızdır. İmkânsız değildir, ancak birden çok kiracıyı kapsayan bir çözüm tasarlamak çok daha karmaşıktır.

Azure Role-Based Access Control (RBAC), Azure için ayrıntılı erişim yönetimi sağlar. RBAC kullanarak, kullanıcılara işlerini gerçekleştirmek için gereken en az izni vererek kaynaklara erişimi yönetebilirsiniz. Ayrıntılar bu belgenin kapsamı dışındadır, ancak RBAC hakkında daha fazla bilgi için bkz. Azure'da rol tabanlı erişim denetimi (RBAC) nedir? RBAC, Azure için idare konusunda dikkat edilmesi gerekenlerin yalnızca bir parçasıdır. Bulut Benimseme Çerçevesi daha fazla bilgi edinmek için harika bir başlangıç noktasıdır. Arkadaşım Andres Ravinet'in müşterilere yaklaşıma karar vermek için çeşitli bileşenlerde adım adım yol gösteren şeklini seviyorum. Çeşitli öğeler için üst düzey görünüm (gerçek müşteri modeline ulaşmak kadar iyi değil) şöyledir:

Temsilcili yönetim için Azure bileşenlerinin üst düzey görünümü.

Yukarıdaki resimde görebileceğiniz gibi, diğer birçok hizmet tasarımın bir parçası olarak düşünülmelidir (örneğin: Azure İlkeleri, Azure Blueprints, Yönetim Grupları vb.).

Son

Bu makale kısa bir özet olarak başladı ve beklediğimden daha uzun bir süre sona erdi. Umarım artık kuruluşunuz için temsilci modeli oluşturma konusunda ayrıntılı bir bakışa başlamaya hazırsınızdır. Bu konuşma müşterilerle çok yaygındır. Herkes için çalışan bir model yoktur. Müşteriler genelinde gördüğümüz yaygın desenleri belgelemeden önce Microsoft mühendisliğinden birkaç planlı geliştirme bekleniyor. Bu arada, microsoft hesabı ekibinizle birlikte çalışarak en yakın Microsoft Teknoloji Merkezi'ne bir ziyaret ayarlayabilirsiniz. Orada görüşürüz!

  • Last updated on