Uygulama izinleri stratejisi geliştirme

Sıfır Güven ilkeleri kullanarak geliştirmeyi öğrenirken, Kaynaklara erişmek için yetkilendirme alma ve Temsilci izinleri stratejisi geliştirme konularını gözden geçirdikten sonra bu makaleye başvurun. Uygulamalarınızın kimliğini doğrulamak ve yetkilendirmek, izinleri ve onayları yönetmek için Microsoft kimlik platformu kullandığınızda kimlik bilgileri yönetimine yönelik uygulama izinleri yaklaşımınızı tanımlayın.

Hiçbir kullanıcı dahil olmadığında, uygulamanıza her zaman önceden atanmış izinleri verildiğinden etkili bir izin modeline sahip olmazsınız.

  • Uygulama, izin isteyen uygulama olduğunu kanıtlar. Uygulamanız aşağıdaki yöntemlerden biriyle kendi kimliğini kanıtlıyor:

  • Uygulama her zaman önceden yönetici onayı gerektirir. Uygulamanız kapsamla birlikte bu izni istemektedir .default . Yöneticinin uygulamaya atamış olduğu izinleri istemektedir.

  • Trans kullanıcı işlevselliği. Varsayılan olarak, User.ReadWrite.All uygulamanızın her kullanıcının profilini güncelleştirmesine izin verir. Uygulama izni olarak, uygulamanızın kiracıdaki her kullanıcının profilini okumasına ve güncelleştirmesine olanak tanır.

  • Uygulamaya verilen izinler her zaman kullanılan izinlerdir. Temsilci izninin aksine, uygulama izinleri belirli bir kullanıcının yapabilecekleriyle sınırlanmamıştır.

Uygulama izinlerini sınırlama

Bir uygulamayı genel erişimden daha azla sınırlamanın üç yolu vardır.

  • Microsoft Teams uygulamaları, bir uygulamanın kuruluştaki tüm ekiplere erişmek yerine belirli bir ekise erişmesine olanak tanıyan kaynağa özgü onay (RSC) içerir. RSC, uygulamanızın API uç noktalarını kullanmasına ve belirli kaynakları yönetmesine olanak tanıyan bir Microsoft Teams ve Microsoft Graph API tümleştirmesidir. İzin modeli, Teams ve Sohbet sahiplerinin uygulamanızın Teams ve Sohbet verilerine erişmesi ve bunları değiştirmesi için onay vermesine olanak tanır.

  • Microsoft Exchange yöneticileri, bir PowerShell betiğiyle uygulama erişimini belirli posta kutularıyla sınırlamak için Exchange uygulama ilkeleri oluşturabilir. Belirli bir uygulamayı veya Mail.Read erişimi olan belirli posta kutularıyla Calendar.Read sınırlandırabilir. Örneğin, tek bir posta kutusunu okuyabilen veya kuruluştaki herkesten değil, yalnızca bir posta kutusundan posta gönderebilen bir otomasyon oluşturmanıza olanak tanır.

  • SharePoint'in, SharePoint'e bir uygulamayla erişmeye yönelik ayrıntılı izinlere izin vermek için belirli bir kapsam olarak Seçilen Siteler'i vardır. Varsayılan olarak, uygulamanızda herhangi bir SharePoint site koleksiyonuna erişimi olmayan diğer izin sonuçlarından biri yerine uygulamanızı seçme Sites.Selected . Yönetici, uygulamanıza Okuma, Yazma veya Okuma ve Yazma izinleri vermek için site izinleri uç noktasını kullanır.

Uygulama kimlik bilgilerini yönetme

Kimlik bilgisi hijyeni, uygulamanızın olası bir ihlalden hızla kurtulmasını sağlayabilir. Aşağıdaki en iyi yöntemler, kapalı kalma süresini önlerken ve meşru kullanıcıları etkilerken algılama ve düzeltme gerçekleştiren uygulamalar geliştirme konusunda size yol gösterir. Bu öneriler, sizi bir güvenlik olayına yanıt vermeye hazırlarken ihlal varsayma Sıfır Güven ilkesini destekler.

  • Koddan ve yapılandırmadan tüm gizli dizileri kaldırın. Azure platformunu kullanırken Anahtar kasasına gizli diziler yerleştirin ve Azure kaynakları için Yönetilen Kimlikler aracılığıyla bunlara erişin. Bir risk oluşursa kodunuzu gizli dizi döndürmelerini işlemek için dayanıklı hale getirin. BT yöneticileri, uygulamanızı kaldırmadan veya yasal kullanıcıları etkilemeden gizli dizileri ve sertifikaları kaldırabilir ve döndürebilir.

  • Gizli dizileri yönetmek için güvenli bir işlem yapılmadığı sürece istemci gizli dizileri yerine sertifikaları kullanın. Saldırganlar, istemci gizli dizilerinin daha az güvenli bir şekilde işlenme eğiliminde olduğunu ve sızdırılan gizli dizi kullanımını izlemenin zor olduğunu bilir. Sertifikalar daha iyi yönetilebilir ve tehlikeye atılırsa iptal edilebilir. Gizli dizileri kullandığınızda, bunlar için güvenli bir dokunmadan dağıtım ve geçiş işlemi oluşturun veya kullanın. Gizli dizileri belirli bir süre sonu süresiyle (örneğin, bir yıl, iki yıl) kullanın ve hiçbir zaman dolmamasını sağlayın.

  • Uygulamanızda dayanıklılık oluşturmak için sertifikaları ve gizli dizileri düzenli olarak dağıtarak acil durum geçişi nedeniyle kesintiyi önler.

Sonraki adımlar