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ı olacaktır. Kaynaklara erişmek için yetkilendirme alma bölümünde açıklandığı gibi, temsilcili izinler, bir uygulamanın yalnızca kullanıcının erişebileceği erişime erişerek bir kullanıcı adına işlem yapmalarına izin vermek için temsilci erişimiyle birlikte kullanılır. Uygulama izinleri , bir uygulamanın iznin ilişkilendirildiği tüm verilere erişmesine izin vermek için doğrudan erişimle birlikte kullanılır. Uygulama izinlerini yalnızca yöneticiler ve hizmet sorumlularının sahipleri onaylayabilir.

İzin ve onay modelleri öncelikli olarak bir uygulamaya başvurur. İ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 ne yapma izni olduğu ve uygulamanın ne yapması için izin verilenler 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 izinlerle sınırlanır.

"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. Daire metninin kesişimi: Etkili izinler: uygulama izinlerinin ve kullanıcı özelliklerinin 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 saldırganların 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 izinde dikkatli bir şekilde ç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 yazmazsanı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 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, API tasarımcısının kullanıcı onayı önerileri kiracı yöneticisi tarafından geçersiz kılabilir. Kiracı yöneticileri bunu kiracıdaki bir "büyük anahtar" ile yapabilir: her şey yönetici onayı 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ı isteklerine izin vermelerine 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, bir geliştirici olarak uygulamanızın yönetici onayı gerektirdiğini her zaman bilemezsiniz. Bunu planlamak ve tasarlamak güzeldir, ancak belirteç isteğinde bulunurken herhangi bir nedenle reddedilebileceğini unutmayın. Müşterilerinizin veya kullanıcılarınızın uygulamanızı çalıştırdığı kiracı yöneticileri izinlerin yönetici onayı gerektirdiğine karar verdiğinden, kodunuzda belirteç almama durumunu düzgün bir şekilde işlemeniz gerekir.

JavaScript MSAL kullanma örneği

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

İlgili Hızlı Başlangıç makalesinden bir kod örneği indirip çalıştırabilirsiniz. JavaScript tek sayfalı uygulamasının (SPA) kod değişimi için Proof Key (PKCE) ile yetkilendirme kodu akışını kullanarak kullanıcılarda nasıl oturum açabileceğini ve 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şturacaksınız. 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ı kullanacaksı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 açılır penceresi işlevi çağırarak kullanıcının gerçekleştirmesi gereken kimlik doğrulamasını signIn işler.

function signIn() {

    /**
     * You can pass a custom request object below. This will override 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 kullanacağınız bir deseni 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 verebilirse, 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 vermemiştir). Bu nedenle, AcquireTokenSilent uygulamaya kullanıcı etkileşimi gerektiren bir hata gönderir. Uygulamanız hatayı aldığında, çağrısına AcquireTokenPopupgeri dönersiniz.

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 ilerlemek 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ıda açıklanan ö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 almak, 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ştirmek, kimlik bilgileri yönetimine yönelik uygulama izinleri yaklaşımınıza karar vermenize yardımcı olur.
• Belirteçleri özelleştirmek, Microsoft Entra belirteçlerinde alabileceğiniz bilgileri ve en az ayrıcalıkla uygulama sıfır güven güvenliğini artırırken esnekliği ve denetimi geliştirmek için belirteçleri özelleştirmeyi açıklar.
• 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ı atayarak esnekliği ve denetimi artırırken uygulama sıfır güven güvenliğini en az ayrıcalıkla artırmayı gösterir.
• 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.