Azure'da SaaS iş yükleri için kimlik ve erişim yönetimi
Uygulama kimliği SaaS iş yükleri için kritik bir alandır çünkü verileri korumaya yönelik ilk savunma hattı görevi görür. Genellikle bir projenin geç zamanlarına kadar göz ardı edilir, ancak uygulamanın diğer öğeleriyle ilgili birçok karar sağlam bir kimlik stratejisine bağlıdır. Müşterilerinizin verilerini korumaya yardımcı olmak için kimliğin önemini hafife almayın.
SaaS iş yükleri bağlamında iki farklı kimlik türü vardır.
Müşteri kimliği ve erişim yönetimi (CIAM) olarak da bilinen uygulama kimliği, son kullanıcıların SaaS uygulamanızın kimliğini doğrulamasını ve kullanmasını sağlar. Kullanıcıların bir uygulama kimliği sağlayıcısında oturum açması için iki ana yöntem vardır:
Federasyon kimlikleri. Kullanıcılar, başka bir kimlik sağlayıcısı tarafından tutulan mevcut kimlik bilgileriyle oturum açar. Bu sağlayıcı Google, Facebook veya LinkedIn gibi bir sosyal kimlik sağlayıcısı ya da müşterilerinizin Kullandığı Microsoft Entra veya Okta gibi bir kurumsal kimlik sağlayıcısı olabilir. Kullanıcının hesabının bakımı, federasyon kimlik sağlayıcısının sorumluluğundadır.
Yerel kimlikler. Kullanıcılar yalnızca uygulamanız için bir hesap oluşturur. Hesabın güvenliği kullanıcı adı ve parola, geçiş anahtarı veya diğer kimlik doğrulama yöntemleriyle sağlanır. Kullanıcının hesabının bakımı sizin sorumluluğunuzdadır.
Kurumsal kimlik , iç kullanıcıların ve iş yüklerinin kimliğini iş üretkenliği araçları, iç araçlar veya hizmetler ve Azure hizmetlerinde doğrulamak için kullanılan kimlik çözümüdür. şirket içi kullanıcılarınız ve iş yükleriniz için kurumsal kimlik çözümünü kullanarak iş üretkenlik araçları, iç araçlar veya hizmetler ve Azure hizmetlerinde kimlik doğrulaması yaparsınız.
SE:05 Kimlik ve erişim yönetimi bölümüne bakın.
Uygulama ve kurumsal kimlikler farklı amaçlara hizmet eder ve farklı kimlik sağlayıcıları kullanabilir. Bu makalede, her iki tür de SaaS iş yükü ortamınızda bulunma olasılığı yüksek olsa da, uygulama kimliğine yönelik tasarım konuları ele alınmaktadır.
Kimlik yönetimiyle ilgili iki sorun vardır: kimlik doğrulaması (kullanıcının kimliğini doğrulama) ve yetkilendirme (kimliğe dayalı izinler verme). Bu makalenin ilk üç bölümü SaaS için kimlik doğrulamasına odaklanır. Son bölümde SaaS sağlayıcıları için yetkilendirme konusunda dikkat edilmesi gerekenler ele alınıyor.
Çok kiracılı bir uygulamada kimlik
Çok kiracılı bir uygulamada kiracı verilerini ayrı tutmak kritik önem taşır. Bu segmentasyon, etkin kullanıcı kimlik doğrulaması ve yetkilendirme seçiminize göre belirlenir. Ayrıca kiracı modeli seçimi, kimlik sağlayıcısı hakkındaki kararlarınızı önemli ölçüde etkiler. Birincil çevreniz olarak kimliğin önceliğini belirleyin.
Segmentasyon için SE:04 Önerileri'ne bakın.
Tasarımla ilgili dikkat edilecek noktalar
Uygulamanızın kiracı ve dağıtım modellerini anlayın. Kimlik stratejinizi etkileyen nüanslar olabilir. Örneğin, Dağıtım Damga DamgaLarı deseninin her damga pulunda bir kimlik sağlayıcısı gerektirdiği yanlış bir algıdır. Çoğu kimlik sağlayıcısı için genellikle alternatif bir yalıtım modeli kullanabilirsiniz.
Çok kiracılı kimlik sağlayıcınızı seçtiğinizde hataların etkisini değerlendirin. Yanlış yapılandırmalar potansiyel olarak tüm kiracılar için uygulamanızın tamamını düşürebilir. Ek yük maliyetlerini olası etki yarıçapı riskine karşı tartın.
Çözümünüzü bir müşterinin Azure ortamına dağıtır ve onlar adına yönetirseniz, kurumsal kimlik sağlayıcısıyla tümleştirmeniz gerekebilir. Bu yönleri net bir şekilde kavrayın:
- Uygulama kiracılarınızla etkileşime geçtiğinde kullanıcı türleri ve erişim gereksinimleri. Örneğin, A kullanıcısı yalnızca kiracı 1'de oturum açmak için erişime ihtiyaç duyabilir, ancak B kullanıcısına hem kiracı 1'de hem de kiracı 2'de oturum açmak için erişim gerekebilir.
- Kimlik sağlayıcınız için geçerliyse veri yerleşimi düzenlemeleri ile uyumluluk. Bazı durumlarda, bir kimlik sağlayıcısı tarafından depolanan veriler düzenlemelere tabi olabilir. Birçok kimlik sağlayıcısı bu senaryo için belirli yönergeler ve özellikler sağlar. Bu senaryoyla ilgili olup olmadığını değerlendirin ve uyumluluğu sağlamak için gerekli adımları uygulayın.
Tasarım önerileri
| Öneri | Avantaj |
|---|---|
| Kimlik sağlayıcınızın çözümü birden çok kiracı için bölümlemeye yönelik en iyi yöntemlerini ve yönergelerini izleyin. | Kiracı yalıtımı, güvenlik ve uyumluluk hedeflerinize ulaşmanıza yardımcı olur. |
| Aynı kullanıcı için birden çok hesap kullanmaktan kaçının. Kullanıcının birden çok kiracıya erişmesi gerekse bile tek bir kimlik bilgileri kümesine sahip tek bir hesabı olmalıdır. Aynı kullanıcı için birden çok hesap oluşturmak yerine gerektiğinde her kiracıya erişim izni verin. | Aynı kullanıcı için birden çok hesap oluşturmak, güvenlik risklerini artırır ve aynı yazılım için birden çok kullanıcı adını ve parolayı hatırlaması gereken kullanıcıların kafasını karıştırabilir. |
| Veri yerleşimi göz önünde bulundurulduğunda, kullanıcı verilerinin ayrı konumlarda nasıl depolanabileceğinizi planlayın. Diğer coğrafyalardaki kullanıcılarınız için ayrı bir dağıtım damgası dağıtırsanız, ayrı kimlik sağlayıcılarına da ihtiyacınız olabilir. Gerekirse, kullanıcıların verilerinin nerede depolandığını belirlemek için bir yolunuz olduğundan emin olun. Böylece, gerekirse oturum açmak için bunları doğru bölgeye yönlendirebilirsiniz. |
Kullanıcıları konumlarına uygun oturum açma deneyimine yönlendirerek uyumluluk gereksinimlerinizi destekleyebilecek ve kullanıcı deneyimini geliştirebileceksiniz. |
Kimlik sağlayıcısı seçimi
Her kimlik sağlayıcısı benzersiz özellikler, sınırlamalar, fiyatlandırma modelleri ve uygulama desenleri sunar. Microsoft Entra ve Okta, popüler hizmet olarak kimlik (IDaaS) seçenekleridir. Keycloak ve Authentik gibi başka açık kaynak sağlayıcıları da vardır.
Tasarımla ilgili dikkat edilecek noktalar
Kimlik gereksinimlerinizi belgeleyin. Uygulamanızın şimdi ihtiyaç duyduğu ve gelecekte ihtiyaç duyacağı özellikleri listeleyerek başlayın. Dikkate alınması gereken tipik özellikler şunlardır:
-
- Müşterilerin kimlik çözümleriyle tümleştirmek için federasyon kimlik sağlayıcısı desteği. Bu özellik, yeni kimlikler oluşturmaktan kaçınmanızı sağlar.
- Markanızı korumak için genel görünümü değiştirmek için özelleştirilebilir oturum açma/kaydolma akışı. Bu özellik, oturum açma/kaydolma işlemine özel iş mantığı ekleme olanağı da sağlar.
- Kiracı yalıtımını korumak için kiracı verilerinin ayrı silolara ayrılması.
- Güvenlik yönetimi için oturum açma günlüklerini korumak veya dışarı aktarmak için desteği denetleyin.
Önemli
Kimlik çözümünün maliyetini değerlendirirken planlanan kullanıcı büyümenizi göz önünde bulundurun. Bir çözüm uzun vadede uygun maliyetli veya ölçeklenebilir olarak kalmayabilir, ancak şimdilik yararlı olabilir. İhtiyaç duyulacaksa kullanabileceğiniz bir geçiş planına sahip olun.
Örneğin, bir çözüm 500 kullanıcı için uygun fiyatlı olabilir, ancak 5 milyon için sürdürülebilir olmayabilir. Minimum kurulum gerektiriyorsa ve kullanıcı dostu ve geçişi kolaysa, maliyetleri ölçeklendirmek farklı bir çözüme geçmeyi gerekçelendirene kadar doğru seçim olmaya devam edebilir.
Kimlik sağlayıcısı özelliklerini kapsamlı bir şekilde araştırın. Kimlik çözümünün gerekli özellikler listenizle eşleştiğinden emin olun. Şu anda federasyon kimliği gibi karmaşık senaryolara ihtiyacınız olmasa bile gelecekteki gereksinimleri göz önünde bulundurun. İşletmeler arası (B2B) SaaS çözümleri için, federasyon kimliği muhtemelen sonunda gerekli olacaktır.
Yönetim ek yükünü dikkate alır. Farklı kimlik sağlayıcıları için farklı yönetim ek yükü düzeyleri gerekir. İyi bilinen IDaaS çözümleri genellikle barındırma, bakım ve güvenliği işlediği için daha az ek yüke sahiptir. Ancak, açık kaynak çözümünün ek yükü, çözüm özel gereksinimlerinize daha uygunsa faydalı olabilir.
Tasarım önerileri
| Öneri | Avantaj |
|---|---|
| Kendi kimlik çözümünüzü oluşturmayın. Kimlik son derece özelleştirilmiş bir alandır ve kimlik çözümü oluşturmak karmaşık ve pahalıdır. Güvenli ve güvenilir bir kimlik çözümü oluşturmak zordur. | Kendi sağlayıcınızı oluşturmanın kötü modelinden kaçınacak ve çözümünüzün güvenliğini, güvenilirliğini ve operasyonel verimliliğini artıracaksınız. |
| Kimlik sağlayıcıları tarafından sunulan özelliklerin yetenek matrisini oluşturun ve kimlik gereksinimlerinizle eşleyin. | Sınırlı bir kimlik özellikleri kümesiyle kısıtlanmadan gelişme olanağınızın olmasını sağlayacaksınız. |
| açık kaynak çözümleri yerine IDaaS seçeneklerini tercih edin. bir açık kaynak çözümü barındırmak, önemli operasyonel ek yük ve güvenlik risklerine neden olur. Ancak, bir sağlayıcının karşılayabildiği uyumluluk, veri yerleşimi veya güvenilirlik için belirli gereksinimleri karşılamak için bu seçeneği belirleyebilirsiniz. Daha fazla bilgi için bkz . IDaaS kimlik sağlayıcıları. |
IDaaS kimlik sağlayıcısı kullanarak gereksiz karmaşıklıktan kaçınabilir ve çabalarınızı temel işinize odaklayabilirsiniz. |
Federasyon kimliği
Çoklu oturum açma (SSO) olarak da bilinen federasyon kimliği, kullanıcıların başka bir yerde zaten kullandıkları kimlik bilgileriyle oturum açmasına olanak tanır. Uygulama kimliği sağlayıcınızla müşterinin mevcut kimlik sağlayıcısı arasında bir güven ilişkisi kurarak federasyon kimliğini etkinleştirirsiniz. Federasyon kimliği, özellikle B2B'de SaaS çözümleri için yaygın bir gereksinimdir, çünkü müşteriler çalışanlarının kurumsal kimlik bilgilerini kullanmasını tercih eder. B2B çözümleri için merkezi kimlik yönetimi ve otomatik yaşam döngüsü yönetimi gibi çeşitli avantajlar sunar. B2C SaaS ürünlerinde, kullanıcıların mevcut kimlik bilgileriyle oturum açmasına olanak sağlamak için sosyal kimlik sağlayıcılarıyla tümleştirme yaygın bir yöntemdir.
Denge: Karmaşıklık ve operasyonel verimlilik. Federasyon kimlik sağlayıcılarıyla çalışarak, kullanıcılarınızın kimliklerini yönetmenin karmaşıklığını boşaltmış olursunuz. Ancak, başka bir kimlik sağlayıcısıyla tümleştirme maliyetini alırsınız. Operasyonel çalışmalarınızı nereye odaklamak istediğinize karar verin.
Federasyon kimliği uygulamak başlangıçta basit olsa da, desteklenen kimlik sağlayıcılarının sayısı arttıkça daha karmaşık hale gelir. Özellikle her müşteri benzersiz bir kimlik sağlayıcısı kullanıyorsa dikkatli planlama gereklidir. Aynı kimlik sağlayıcısını kullansalar bile, belirli yapılandırma ayrıntıları nedeniyle genellikle her müşteri için benzersiz güven ilişkileri gerekir.
Bu görüntüde, uygulamanız, uygulama kimliği sağlayıcınız ve kimlik federasyonu kullanarak uygulamayı seçebileceğiniz aşağı akış kimlik sağlayıcıları arasındaki ilişki gösterilir.
Tasarımla ilgili dikkat edilecek noktalar
Desteklemeniz gereken kimlik sağlayıcılarının türlerini ve sayısını tahmin edin. Statik sayıda sosyal kimlik sağlayıcısına veya her müşteri için benzersiz federasyon kimlik sağlayıcılarına ihtiyacınız olabilir. Müşterilerinizin tümleştirme için OpenID Connect (OIDC), Güvenlik Onaylama İşaretleme Dili (SAML) veya her ikisini birden kullanıp kullanmayacağını bilmeniz gerekir.
Oturum açma deneyiminin haritasını çıkarma. Kaydolma ve oturum açma işleminin kullanıcı akışını görselleştirin. Kullanıcı akışı tasarımınızı değiştirebilecek özel gereksinimleri not edin. Örneğin:
Özel markalama. Beyaz etiketleme veya müşteri başına özel oturum açma etki alanları.
Özel bilgiler. Birden çok kiracıya erişimi olan kullanıcılar için kiracı seçimi gibi, kaydolma veya oturum açma sırasında ek kullanıcı bilgileri toplama.
Kimlik sağlayıcısı seçimi. Ona güvenen çok sayıda federasyon kimlik sağlayıcısına sahip tek bir uygulama kimlik sağlayıcısı kullanıyorsanız, sağlayıcı seçmeye karar verin. Bu seçim bir düğme aracılığıyla el ile veya bilinen kullanıcı bilgilerine göre otomatik olarak yapılabilir. Sağlayıcı sayısı arttıkça otomatik seçim daha pratik hale gelir. Bu özellik Ev Bölgesi Bulma olarak bilinir.
Tasarım önerileri
| Öneri | Avantaj |
|---|---|
| İhtiyacınız olan federasyon kimlik sağlayıcısı sayısını karşılayacak şekilde ölçeklenebilen bir kimlik sağlayıcısı seçin. Sağlayıcının aşılamaz sabit sınırlarını unutmayın. |
Kimlik çözümünüzün büyüdükçe ölçeklenebilmesini sağlayacaksınız. |
| Her federasyon kimlik sağlayıcısının eklemeyi planlayın ve süreci mümkün olduğunca otomatikleştirin. Kuruluşunuzla müşterileriniz arasındaki bu işbirliği çalışması, genellikle OIDC veya SAML protokolleri aracılığıyla bir güven ilişkisi kurmak için bilgi alışverişi yapmaktır. |
Kimlik tümleştirmesi hem siz hem de müşterileriniz için zaman ve çaba gerektirebilir. Süreci planlayarak operasyonel verimliliğinizi artıracaksınız. |
| Fiyatlandırma ve iş modelinizdeki federasyon kimliğinin karmaşıklığını ve maliyetini yansıtın. Müşterilerin kendi kimlik sağlayıcılarını kullanmasına izin vermek, birden çok federasyon kimlik güveni ilişkisi sürdürme yükü nedeniyle operasyonel karmaşıklığı ve maliyetleri artırır. Kuruluşların federasyon oturum açmasına olanak tanıyan daha yüksek bir katman için ödeme yapmalarına yönelik SaaS çözümlerinde yaygındır. |
Müşterinin kimlik sağlayıcısıyla federasyon, SaaS çözümlerinde gizli bir maliyet olabilir. Bunu planlayarak, uygulama sırasında beklenmeyen maliyetlerden kaçınmış olursunuz. |
| Oturum açma akışı sırasında kullanıcının kimlik sağlayıcısının nasıl seçileceğini planlayın. Home Realm Discovery kullanmayı göz önünde bulundurun. Microsoft Entra ID yerleşik Ev Bölgesi Bulma sağlar. |
Müşteri deneyiminizi kolaylaştıracak ve kullanıcıların doğru oturum açma işlemine yönlendirildiğinden emin olacaksınız. |
Yetkilendirme
Kullanıcı yetkilendirmesi, genellikle birden çok kiracının verilerini depolayan SaaS uygulamaları için çok önemlidir. Kullanıcıların, diğer kiracıların verilerine yanlışlıkla erişmeden yalnızca kendi verilerine erişme yetkisine sahip olacağını açıkça tanımlayın. Ayrıca, kiracı içinde ayrıntılı yetkilendirme sağlayarak kullanıcıların güncelleştirmeleri veya diğer verilere erişimi kısıtlarken belirli bilgileri okumasına veya erişmesine olanak tanıyabilirsiniz.
Tasarımla ilgili dikkat edilecek noktalar
Kullanım örneği için doğru yetkilendirme modelini seçin. İki ana tür vardır:
- Rol tabanlı yetkilendirme. Kullanıcılara roller veya gruplar atanır ve belirli özellikler belirli rollerle sınırlıdır. Örneğin, yöneticiler herhangi bir eylem gerçekleştirebilir, ancak diğer rollerdeki kullanıcılar sınırlı izinlere sahiptir.
- Kaynak tabanlı yetkilendirme. Her kaynağın kendi izinleri vardır. Bir kullanıcı bir kaynağın yöneticisi olabilir ancak başka bir kaynağa erişimi olmayabilir.
Yetkilendirme verilerinin depolandığı yere karar verin. Uygulamanızın yetkilendirme verileri şu durumlarda depolanabilir:
- Kimlik sağlayıcınız. Uygulamanıza verilen belirteçte talep olarak izinler oluşturarak yerleşik gruplardan veya rollerden yararlanın. Uygulamanız daha sonra bu belirteç taleplerini kullanarak yetkilendirme kurallarını zorunlu kılabilir.
- Uygulamanız. Kendi yetkilendirme mantığınızı geliştirin ve kullanıcı izinlerini bir veritabanında veya benzer bir sistemde depolayarak ayrıntılı rol tabanlı veya kaynak düzeyinde yetkilendirme denetimleri sağlayın.
Denge: Karmaşıklık, esneklik ve güvenlik. Yetkilendirme verilerini bir kimlik sağlayıcısında depolamak ve belirteç talepleri aracılığıyla gezinmek genellikle kendi yetkilendirme sisteminizi yönetmekten daha kolaydır. Ancak, talep tabanlı yetkilendirme esnekliğinizi sınırlar ve taleplerin yalnızca bir belirteç yeniden verildiğinde yenilendiğini kabul etmeniz gerekir ve bu da değiştirilen izinlerin uygulanmasında gecikmeye neden olabilir.Temsilci yönetiminin etkisini değerlendirin. SaaS uygulamalarının çoğunda, özellikle B2B uygulamalarında rol ve izin yönetimi müşterilere devredilir. Bu işlevsellik olmadan, müşteriler kullanıcılarının izinlerini sık sık değiştirirse yönetim ek yükünüzü artırabilirsiniz.
Çok kiracılı erişimi değerlendirin. Bazı sistemlerde tek bir kullanıcının birden çok kiracıdaki verilere erişmesi gerekebilir. Örneğin danışmanların birden çok kiracıdan verilere erişmesi gerekebilir. Müşterilerin bu kullanıcılara nasıl erişim verileceğini ve oturum açma akışınızın kiracılar arasında seçim ve geçiş yapmayı nasıl destekleyeceğini planlayın.
Tasarım önerileri
| Öneri | Avantaj |
|---|---|
| Erişime açıkça izin verilmediği sürece kullanıcıların kiracı sınırları boyunca verilere erişmesini engelleyin. | Başka bir kiracının verilerine yetkisiz erişim, hatta yanlışlıkla erişim, önemli bir güvenlik olayı olarak görülebilir ve platformunuzda müşteri güvenini aşındırabilir. Gereksiz erişimin engellenmesi, bu durumlardan kaçınmanıza yardımcı olur. |
| Veriler statikse ve seyrek değişiyorsa, kimlik sağlayıcısında depolayın. Kullanıcı yazılımı kullanırken sık sık değişiklikler yapılması gerekiyorsa yetkilendirme verilerini uygulamanızda depolayın. | Yetkilendirme verileriniz için en iyi veri deposunun seçilmesi operasyonel verimliliğinizi artırır ve ölçeklenebilirlik gereksinimlerinizi karşılamanıza yardımcı olur. |
| İzin yönetimini müşterilere devrederseniz, izinlerini yönetmeleri için açık bir yöntem sağlayın. Örneğin, kullanıcı izinlerini değiştirmek için yalnızca kiracı yöneticileri tarafından erişilebilen bir web portalı oluşturun. | Müşterilerinize daha fazla denetim sağlayacak ve destek ekibinizin gereksiz operasyonel yükünden kaçınacaksınız. |
Ek kaynaklar
Çok kiracılılık, SaaS iş yüklerini tasarlamaya yönelik temel bir iş metodolojisidir. Bu makaleler kimlik ve erişim yönetimi hakkında daha fazla bilgi sağlar:
- Çok kiracılı çözümlerde kimlikle ilgili mimari konular
- Çok kiracılı çözümlerde kimlik için mimari yaklaşımlar
Sonraki adım
İşlem barındırma modelinizi, operasyonel yönlerinizi ve hizmet düzeyi sözleşmelerinizi ve hedeflerinizi karşılamanıza yardımcı olmak için teknoloji seçeneklerini nasıl iyileştireceğinizi öğrenin.