Temsilcili izin stratejisi geliştirme

Bu makale, bir geliştirici olarak uygulamanızdaki izinleri yönetmek ve Sıfır Güven ilkeleri kullanarak geliştirmek için en iyi yaklaşımı uygulamanıza yardımcı olur. Kaynaklara erişmek için yetkilendirme alma bölümünde açıklandığı gibi, temsilcili izinler, bir uygulamanın bir kullanıcı adına hareket etmesi ve yalnızca kullanıcının erişebileceği şeylere erişmesine izin vermek için temsilci erişimiyle kullanılır. İzinle ilişkili tüm verilere erişmek için, bir uygulamaya izin vermek için doğrudan erişime sahip Uygulama izinlerini kullanın. Uygulama izinlerini yalnızca yöneticiler ve hizmet sorumlularının sahipleri onaylayabilir.

İzin ve onay modelleri öncelikli olarak bir uygulamayı ifade eder. İzin ve onay işlemi, kullanıcının yapabilecekleri üzerinde hiçbir denetime sahip değildir. Uygulamanın gerçekleştirmesine izin verilen eylemleri denetler.

Aşağıdaki Venn diyagramına başvurun. Temsilci izinleriyle, kullanıcının hangi eylemleri gerçekleştirebildiği ve uygulamanın yapmasına izin verilen eylemler arasında bir kesişim vardır. Bu kesişim, uygulamanın bağlı olduğu etkin izindir. Temsilci izni kullandığınızda geçerli izinler bunu sınırlar.

"Venn diyagramı açıklaması: Sol daire metni: Uygulamalara uygulamanın işlem aralığı için onay verilir. Sağ daire metni: Kullanıcılar, kendi kuruluşlarının yönettiği işlemler için izinlere sahiptir. Çemberlerin kesişim metni: Etkili izinler: uygulama izinlerinin ve kullanıcı yetkilerinin kesişimi.

Örneğin, uygulamanın önünde kullanıcıları olan uygulamanız, kiracıdaki her kullanıcının profilini güncelleştirme izni alır. Bu, uygulamanızı çalıştıran herkesin başka birinin profilini güncelleştirebileceği anlamına gelmez. Yönetici uygulamanıza User.ReadWrite.Allverme kararı alırsa, herhangi bir kullanıcı profilini güncelleştirirken uygulamanızın doğru işlemleri yaptığına inanır. Uygulamanız değişiklikleri günlüğe kaydedebilir ve bilgileri düzgün bir şekilde korur. Yönetici, kullanıcı hakkında değil uygulama hakkında bir değer yargısı yapar.

En az ayrıcalık yaklaşımı

API'ler karmaşık olabilir. Basit API'lerde çok fazla işlem olmayabilir. Microsoft Graph gibi karmaşık API'ler, bir uygulamanın kullanmak isteyebileceği birçok isteği kapsüller. Uygulamanın okuma hakkı olması, güncelleştirme hakkına sahip olması gerektiği anlamına gelmez. Örneğin, Microsoft Graph'ta binlerce API vardır. Kullanıcının profilini okuma izniniz olması nedeniyle, tüm OneDrive dosyalarını silme izninizin de olması gerekmez.

Geliştirici olarak şunları yapmalısınız:

• uygulamanın hangi API'leri çağırdığı bilin.
• API belgelerini ve API'nin hangi izinleri gerektirdiğini anlayın.
• görevlerinizi gerçekleştirmek için mümkün olan en düşük izni kullanın.

API'ler genellikle kuruluş veri depolarına erişim sağlar ve bu verilere erişmek isteyen kötü aktörlerin dikkatini çeker.

İşi yapmak için en az ayrıcalıklı kümeyi aradığınızdan emin olmak için istediğiniz izinleri değerlendirin. Daha yüksek ayrıcalık izinleri istemekten kaçının. Bunun yerine, Microsoft Graph gibi API'lerin sağladığı çok sayıda izni dikkatlice değerlendirerek ele alın. gereksinimlerinizi karşılamak için en düşük izinleri bulun ve kullanın. Kullanıcının profilini güncelleştirmek için kod yazmıyorsanız, uygulamanız için bunu istemezsiniz. Yalnızca kullanıcılara ve gruplara erişiyorsanız, dizindeki diğer bilgilere erişim istemezsiniz. Kullanıcı e-postasına erişen bir kod yazmazsanız, kullanıcı e-postasını yönetmek için izin istemezsiniz.

Sıfır Güven uygulama geliştirme aşamasında:

• Uygulamanızın amacını ve neye ihtiyacı olduğunu tanımlayın.
• Kötü aktörlerin güvenliği tehlikeye atmadığından emin olun ve uygulamanızı istemediğiniz şekilde kullanın.
• Gereksinimlerinizi tanımladığınız onay isteklerinde bulunabilirsiniz (örneğin, kullanıcının postasını okuyun).

İzin ve onayda kullanıcı ve kiracı yöneticisi rolleri

İsteklerinizi onaylayan kişiler iki kategoriye ayrılır: izin isteklerini her zaman onaylayan yöneticiler ve yönetici olmayan normal kullanıcılar. Ancak kiracı yöneticileri, kiracılarında yönetici onayı gerektiren izinler ve bir kullanıcının hangi izinlere izin verebileceği konusunda son söz sahibidir.

BIR API tasarımcısı izin için yönetici onayı gerektirdiğinde, bu izin her zaman yönetici onayı gerektirir. Kiracı yöneticisi bunu geçersiz kılamaz ve yalnızca kullanıcı onayı gerektirir.

BIR API tasarımcısı kullanıcı onayı gerektiren izinleri tanımladığında, kiracı yöneticisi API tasarımcısının kullanıcı onayı önerilerini geçersiz kılabilir. Kiracı yöneticileri, kiracıdaki geniş çapta kontrol mekanizması ile bunu yapabilir: her şey yönetici izni gerektirir. İzin ve onay yönetimi ile kullanıcı onaylarını daha ayrıntılı bir şekilde geçersiz kılabilir. Örneğin, kullanıcıların doğrulanmış yayımcılardan gelen kullanıcı onayı isteklerini onaylamasına izin verebilir, ancak diğer yayımcılardan izin vermezler. Başka bir örnekte, kullanıcının oturum açmasına ve profilini okumasına izin User.Read verebilir, ancak posta veya dosyalar için izin isteyen uygulamalar için yönetici onayı gerektirebilir.

API tasarımcıları öneride bulunur ancak son söz kiracı yöneticileri tarafından belirlenir. Bu nedenle, geliştirici olarak uygulamanızın yönetici onayı gerektirdiğini her zaman bilemezsiniz. Bunu planlamak ve tasarlamak güzel. Belirteç isteğinde bulunurken herhangi bir nedenle reddedilebileceğini unutmayın. Kodunuzda bir belirteç alınamamasını zarif bir şekilde işlemek gerekir çünkü uygulamanızı çalıştıran müşterilerinizin veya kullanıcılarınızın kiracı yöneticileri, izinlerin ne zaman yönetici onayı gerektirdiğine karar verir.

JavaScript MSAL kullanma örneği

Bu örnekteki kimlik doğrulaması için JavaScript Microsoft Kimlik Doğrulama Kitaplığı'mızı (MSAL) kullanarak kullanıcının tüm uygulama mantığının tarayıcıdan yürütüldüğü tek sayfalı bir uygulamada (SPA) oturum açarsınız.

İlgili Hızlı Başlangıç makalesinden bir kod örneği indirip çalıştırabilirsiniz. JavaScript tek sayfalı uygulamasının (SPA) kullanıcılarda nasıl oturum açabileceğini ve Kod Değişimi için Proof Key (PKCE) ile yetkilendirme kodu akışıyla Microsoft Graph'ı nasıl çağırabileceğini gösterir. Kod örneği, Microsoft Graph API'sini veya herhangi bir web API'sini çağırmak için erişim belirteci alma işlemini gösterir.

Aşağıdaki örnek kodda gösterildiği gibi, tamamen tarayıcıda çalışan bir uygulamanın genel istemci olması gerektiğinden genel istemci örneği oluşturursunuz. Kod tarayıcıdayken kullanıcı uygulamanızın iç bileşenlerini ele alabilir.

// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);

Ardından MSAL kitaplığımızı kullanırsınız. MSAL JavaScript'te oturum açmak için belirli bir API vardır. Tarayıcıda belirli özellikleri kullanan iki API vardır. Bunlardan biri, bir açılır pencere deneyimiyle oturum açmaktır; diğeri ise tarayıcı yeniden yönlendirme deneyimiyle oturum açmaktır.

Aşağıdaki kod örneğinde gösterildiği gibi, oturum açma penceresi, signIn işlevini çağırarak kullanıcının gerçekleştirmesi gereken kimlik doğrulamasını işler.

function signIn() {

    /**
     * You can pass a custom request object. This overrides the initial configuration. For more information, visit:
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
     */

    myMSALObj.loginPopup(loginRequest)
        .then(handleResponse)
        .catch(error => {
            console.error(error);
        });
}

Uygulamanız kullanıcı hakkında görünen adı veya kullanıcı kimliği gibi bilgiler alabilir. Ardından, uygulamanızın MSAL kitaplıklarımız genelinde kullandığınız bir düzeni izleyerek Microsoft Graph'ten kullanıcının tam profilini okuma yetkisine sahip olması gerekir.

Aşağıdaki örnek kodda gösterildiği gibi, uygulamanız çağrısı AcquireTokenSilentyaparak yetkilendirmeyi almaya çalışır. Microsoft Entra Id kullanıcıyla etkileşim kurmadan belirteci verebiliyorsa, AcquireTokenSilent uygulamanızın kullanıcı adına Microsoft Graph'e erişmesi için gereken belirteci döndürür.

function getTokenPopup(request) {

    /**
     * See here for more info on account retrieval: 
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
     */
    request.account = myMSALObj.getAccountByUsername(username);
    
    return myMSALObj.`AcquireTokenSilent`(request)
        .catch(error => {
            console.warn("silent token acquisition fails. acquiring token using popup");
            if (error instanceof msal.InteractionRequiredAuthError) {
                // fallback to interaction when silent call fails
                return myMSALObj.`AcquireTokenPopup`(request)
                    .then(tokenResponse => {
                        console.log(tokenResponse);
                        return tokenResponse;
                    }).catch(error => {
                        console.error(error);
                    });
            } else {
                console.warn(error);
            }
    });
}

Ancak Microsoft Entra ID genellikle kullanıcıyla etkileşim kurmadan belirteci veremez (örneğin, kullanıcı parolasını değiştirmiştir veya onay vermez). Bu nedenle, AcquireTokenSilent uygulamaya kullanıcı etkileşimi gerektiren bir hata gönderir. Uygulamanız hata aldığında, AcquireTokenPopup çağrısını geri çağırırsınız.

Bu noktada, Microsoft Entra Id kullanıcıyla bir konuşma yapar, böylece kullanıcının kimliğini doğrulayabilir ve uygulamanızı kullanıcı adına işlem yapma yetkisi verebilir (örneğin, bir MFA yapın, parolasını sağlayın, onay verin). Ardından uygulamanız ilerlemesi için gereken belirteci alır.

Bir kuruluşun Sıfır Güven yolculuğunun birincil adımı, yalnızca kullanıcı kimliği ve parola yerine daha güçlü kimlik doğrulama yöntemlerini benimsemektir. Yukarıdaki örnek kod, bir kuruluşun kuruluşun seçtiği daha güçlü kimlik doğrulama yöntemine geçmesine tamamen olanak tanır. Örneğin, çok faktörlü kimlik doğrulaması, FIDO2 anahtarıyla tamamen parolasız, Microsoft Authenticator.

Sonraki adımlar

• Kaynaklara erişmek için yetkilendirme alma, uygulamanız için kaynak erişim izinleri alırken Sıfır Güven en iyi şekilde nasıl sağlayacağınızı anlamanıza yardımcı olur.
• Uygulama izinleri stratejisi geliştirme , kimlik bilgileri yönetimine yönelik uygulama izinleri yaklaşımınıza karar vermenize yardımcı olur.
• Jetonları özelleştirme, Microsoft Entra jetonlarında alabileceğiniz bilgileri açıklar. Uygulama Sıfır Güven güvenliğini en az ayrıcalıkla artırırken esnekliği ve denetimi geliştirmek için belirteçlerin nasıl özelleştirileceği açıklanır.
• Belirteçlerde grup taleplerini ve uygulama rollerini yapılandırma, uygulama rol tanımlarıyla uygulamalarınızı yapılandırmayı ve uygulama rollerine güvenlik grupları atamayı gösterir. Bu yöntemler, en az ayrıcalıkla uygulama Sıfır Güven güvenliğini artırırken esnekliği ve denetimi geliştirmeye yardımcı olur.
• API Koruması, api'nizi kayıt, izin ve onay tanımlama ve Sıfır Güven hedeflerinize ulaşmak için erişimi zorlama yoluyla korumaya yönelik en iyi yöntemleri açıklar.
• Başka bir API'den API çağırmak, başka bir API'yi çağırması gereken bir API'niz olduğunda Sıfır Güven sağlamanıza ve bir kullanıcı adına çalışırken uygulamanızı güvenli bir şekilde geliştirmenize yardımcı olur.
• Yetkilendirme en iyi yöntemleri , uygulamalarınız için en iyi yetkilendirme, izin ve onay modellerini uygulamanıza yardımcı olur.
• Güvenli uygulamalar oluşturmak için uygulama geliştirme yaşam döngünüzde Sıfır Güven kimlik ve erişim yönetimi geliştirme en iyi yöntemlerini kullanın.