Koşullu Erişim: Hedef kaynaklar

Genel bakış

Hedef kaynaklar (eski adıyla bulut uygulamaları, eylemler ve kimlik doğrulama bağlamı), Koşullu Erişim ilkesindeki önemli sinyallerdir. Koşullu Erişim ilkeleri yöneticilerin belirli uygulamalara, hizmetlere, eylemlere veya kimlik doğrulama bağlamlarına denetim atamasına olanak tanır.

  • Yöneticiler yerleşik Microsoft uygulamaları ve galeri, galeri dışı uygulamalar ve Uygulama Ara Sunucusu aracılığıyla yayımlanan uygulamalar da dahil olmak üzere tüm Microsoft Entra tümleşik uygulamaları içeren uygulamalar veya hizmetler listesinden seçim yapabilir.
  • Yöneticiler, Güvenlik bilgilerini kaydetme veya Cihazları kaydetme veya birleştirme gibi bir kullanıcı eylemine dayalı olarak bir ilke tanımlayabilir ve Koşullu Erişim'in bu eylemlerle ilgili denetimleri zorunlu kılabilmesini sağlar.
  • Yöneticiler, gelişmiş işlevsellik için Genel Güvenli Erişim'den trafik iletme profillerini hedefleyebilir.
  • Yöneticiler, uygulamalarda ek bir güvenlik katmanı sağlamak için kimlik doğrulama bağlamını kullanabilir.

Koşullu Erişim ilkesinin ve hedef kaynaklar panelinin ekran görüntüsü.

Microsoft bulut uygulamaları

Eğer hizmet asıl adı kiracıda görünüyorsa, yöneticiler Microsoft Graph hariç Microsoft bulut uygulamaları için Koşullu Erişim ilkesi atayabilir. Microsoft Graph bir şemsiye kaynağı olarak çalışır. Arka plandaki hizmetleri görmek ve bu hizmetleri ilkelerinizde hedeflemek için Hedef Kitle Raporlaması'nı kullanın. Microsoft 365/Office 365 ve Windows Azure Service Management API gibi bazı uygulamalar birden çok ilgili alt uygulama veya hizmet içerir. Yeni Microsoft bulut uygulamaları oluşturulduğunda, hizmet sorumlusu kiracıda oluşturulur oluşturulmaz uygulama seçim listesinde görünür.

Office 365

Microsoft 365 Exchange, SharePoint ve Microsoft Teams gibi bulut tabanlı üretkenlik ve işbirliği hizmetleri sunar. Koşullu Erişim'de, Microsoft 365 uygulama paketi 'Office 365' altında görünür. Microsoft 365 bulut hizmetleri sorunsuz ve işbirliğine dayalı deneyimler sağlamak için kapsamlı bir şekilde tümleşiktir. Microsoft Teams gibi bazı uygulamalar SharePoint veya Exchange gibi diğer uygulamalara bağlı olduğundan, bu tümleştirme ilke oluştururken karışıklığa neden olabilir.

Koşullu Erişim'deki Office 365 uygulama gruplandırma, bu hizmetlerin tümünü aynı anda hedeflemeyi mümkün kılar. service bağımlılıkları ile ilgili sorunları önlemek için tek tek bulut uygulamalarını hedeflemek yerine Microsoft 365 gruplandırmasını kullanın.

Bu uygulama grubunu hedeflemek, tutarsız ilkeler ve bağımlılıklar nedeniyle ortaya çıkabilecek sorunları önlemeye yardımcı olur. Örneğin: Exchange Online uygulaması posta, takvim ve kişi bilgileri gibi geleneksel Exchange Online verilerine bağlıdır. İlgili meta veriler arama gibi farklı kaynaklar aracılığıyla gösterilebilir. Tüm meta verilerin amaçlandığı gibi korunduğundan emin olmak için yöneticilerin Microsoft 365 uygulamasına ilkeler ataması gerekir.

Yöneticiler, Microsoft 365 paketinin tamamını veya belirli Microsoft 365 bulut uygulamalarını Koşullu Erişim ilkelerinin dışında tutabilirsiniz.

Dahil edilen tüm hizmetlerin tam listesi için bkz. Koşullu Erişim Microsoft 365 uygulama paketinde bulunan Apps.

Windows Azure Hizmet Yönetimi API'si

Windows Azure Hizmet Yönetimi API'sini hedeflediğinizde, portala yakın bir hizmet kümesine verilen belirteçler için ilke uygulanır. Bu gruplandırmada aşağıdaki uygulama kimlikleri yer alır:

  • Azure Resource Manager
  • Microsoft Entra yönetim merkezi ve Microsoft Etkileşim Merkezi'ni de kapsayan Azure portalı
  • Azure Data Lake
  • Application Insights API'si
  • Log Analitiği API

İlke Azure yönetim portalına ve API'ye uygulandığından, Azure API'sine bağımlı olan tüm hizmetler veya istemciler dolaylı olarak etkilenebilir. Örneğin:

  • Azure CLI
  • Azure Data Factory portalı
  • Azure Event Hubs
  • Azure PowerShell
  • Azure Service Bus
  • Azure SQL Veritabanı
  • Azure Synapse
  • Klasik dağıtım modeli API'leri
  • Microsoft 365 yönetim merkezi
  • Microsoft IoT Central
  • Microsoft Defender çok kiracılı yönetimi
  • SQL Yönetilen Örneği
  • Visual Studio abonelikleri yönetici portalı

Dikkat

Windows Azure Hizmet Yönetimi API'si ile ilişkili Koşullu Erişim ilkeleri Azure DevOps'yi daha uzun süre kapsamaz.

Note

Windows Azure Hizmet Yönetimi API'si uygulaması, Azure Resource Manager API çağıran Azure PowerShell için geçerlidir. Microsoft Graph API çağıran Microsoft Graph PowerShell için geçerli değildir.

Azure Kamu için Azure Kamu Bulut Yönetimi API'sini hedeflemeniz gerekir.

Microsoft Yönetici Portalları

Koşullu Erişim ilkesi Microsoft Yönetici Portalları bulut uygulamasını hedeflediğinde, ilke, Microsoft yönetici portallarıyla ilişkili spesifik temel kaynak uygulama kimliklerine verilen belirteçler için zorlanır. Uygulama gruplandırması, bu portalların çağırabileceği veya bağlı olabileceği arka uç hizmetlerini içermez. Yönetici portallarının hizmet bağımlılıklarını belirlemek için Oturum açma günlüklerinde Koşullu Erişim hedef kitle raporlamasını kullanın.

Aşağıdaki uygulamalar Microsoft Yönetim Portallarını içerir:

  • Exchange Yönetim Merkezi uygulama kimliği: 497effe9-df71-4043-a8bb-14cf78c4b63b
  • Azure portalı uygulama kimliği: c44b4083-3bb0-49c1-b47d-974e53cbdf3c
  • Microsoft Office 365 Portalı uygulama kimliği: 00000006-0000-0ff1-ce00-0000000000000
  • Microsoft 365 Güvenlik ve Uyumluluk Merkezi (Koruma Merkezi) uygulama kimliği: 80ccca67-54bd-44ab-8625-4b79c4dc7775

Yönetici Portalı gruplandırması, öncelikli olarak, Koşullu Erişim ilkeleri kapsamında bir veya daha fazla yönetici portalını hedeflemenin basitleştirilmiş bir yolu olarak, senaryolarda dahil edilmek üzere tasarlanmıştır (örneğin, MFA'yı zorunlu tutma). Bu gruplandırma, yöneticiler için Microsoft tarafından yönetilen MFA ilkesinde, ilke oluşturmayı kolaylaştırmak amacıyla kullanılır.

Bu seçenek, temel alınan uygulama kimlikleriyle ilişkili tüm arka uç hizmetleri için toplu dışlama mekanizması işlevi görecek şekilde tasarlanmamıştır.

Note

Microsoft Yönetici Portallarını hedefleyen ilkeleri engellemek, bu sayfa şu anda Microsoft 365 yönetici merkezinde bulunduğundan, son kullanıcıların Microsoft 365 kendi kendine yükleme sayfasına erişimini engeller. Alternatif dağıtım seçenekleri hakkında bilgi için bkz. Microsoft 365 Uygulamaları kurumsal dağıtımınızı planlama.

Diğer uygulamalar

Yöneticiler, koşullu erişim ilkelerine Microsoft Entra kayıtlı tüm uygulamaları ekleyebilir. Söz konusu uygulamalar şunları içerebilir:

Note

Koşullu Erişim ilkesi bir hizmete erişim gereksinimlerini belirlediğinden, bunu bir istemci (genel/yerel) uygulamasına uygulayamazsınız. Başka bir deyişle, ilke doğrudan bir istemci (genel/yerel) uygulamasında ayarlı değildir, ancak bir istemci bir hizmeti çağırdığında uygulanır. Örneğin, SharePoint hizmetinde ayarlanan bir ilke, SharePoint çağıran tüm istemciler için geçerlidir. Exchange'da ayarlanan bir ilke, Outlook istemcisini kullanarak e-postaya erişme girişimi için geçerlidir. Bu nedenle istemci (genel/yerel) uygulamalar uygulama seçicide seçilebilir değildir ve Koşullu Erişim seçeneği kiracınızda kayıtlı istemci (genel/yerel) uygulamanın uygulama ayarlarında kullanılamaz.

Bazı uygulamalar seçicide hiç gösterilmez. Bu uygulamaları Koşullu Erişim ilkesine eklemenin tek yolu Tüm kaynaklar (eski adıyla 'Tüm bulut uygulamaları') eklemek veya < kullanarak eksik hizmet sorumlusunu eklemektir New-MgServicePrincipal PowerShell cmdlet'ini veya Microsoft Graph API kullanarak.

Farklı istemci türleri için Koşullu Erişim

Koşullu Erişim, istemcinin kimlik belirteci isteyen gizli bir istemci olması dışında istemcilere değil kaynaklara uygulanır.

  • Herkese açık istemci
    • Genel istemciler, masaüstünde Microsoft Outlook gibi cihazlarda veya Microsoft Teams gibi mobil uygulamalarda yerel olarak çalışan istemcilerdir.
    • Koşullu Erişim ilkeleri genel istemcilerin kendileri için geçerli değildir, ancak istedikleri kaynakları temel alır.
  • Gizli istemci
    • Koşullu Erişim, istemci tarafından istenen kaynaklara ve eğer kimlik belirteci talep ederse gizli istemcinin kendisine uygulanır.
    • Örneğin: Outlook Web Mail.Read ve Files.Read kapsamları için belirteç isterse, Koşullu Erişim Exchange ve SharePoint için ilkeler uygular. Ayrıca, Outlook Web bir kimlik belirteci isterse, Koşullu Erişim Outlook Web için ilkeleri de uygular.

Bu istemci türlerinin oturum açma günlüklerini Microsoft Entra yönetim merkezinden görüntülemek için:

  1. En azından bir Reports Reader olarak Microsoft Entra yönetim merkezi'da oturum açın.
  2. Entra ID>İzleme ve sağlık>Oturum açma günlükleri adresine gidin.
  3. İstemci kimlik bilgisi türü için bir filtre ekleyin.
  4. Oturum açmada kullanılan istemci kimlik bilgilerine göre belirli bir günlük kümesini görüntülemek için filtreyi ayarlayın.

Daha fazla bilgi için Genel istemci ve gizli istemci uygulamaları makalesine bakın.

TÜM kaynaklar için Koşullu Erişim

Kaynak dışlamaları olmadan Tüm kaynaklara (eski adıyla 'Tüm bulut uygulamaları') Koşullu Erişim ilkesi uygulamak, Genel Güvenli Erişim trafik iletme profilleri de dahil olmak üzere web sitelerinden ve hizmetlerden gelen tüm belirteç istekleri için ilkeyi zorunlu kılmasını sağlar. Bu seçenek, Windows Azure Active Directory (00000002-0000-0000-0000-c000-000000000000) gibi Koşullu Erişim ilkesinde tek tek hedeflenemeyen uygulamaları içerir.

Important

Microsoft, bölümünde açıklanan kimlik doğrulaması gibi tüm kullanıcıları ve tüm kaynakları (kaynak dışlamaları olmadan) hedefleyen temel çok faktörlü kimlik doğrulama ilkesi oluşturmanızı önerir.

TÜM kaynaklar ilkesinde kaynak dışlaması olduğunda eski Koşullu Erişim davranışı

Warning

Aşağıdaki Koşullu Erişim davranışı değişiyor. Daha önce ilke zorlamasından dışlanan düşük ayrıcalıklı kapsamlar artık dışlanmayacak. Bu değişiklik, daha önce Koşullu Erişim zorlaması olmadan uygulamaya erişebilen kullanıcıların artık Koşullu Erişim sınamaları alabileceği anlamına gelir. Değişiklik Mart 2026'dan itibaren aşamalı olarak kullanıma sunulacaktır.

herhangi bir uygulama ilkenin dışında tutulursa, kullanıcı erişimini yanlışlıkla engellememek için, belirli düşük ayrıcalık kapsamları daha önce ilke zorlamasına dahil edilmemişti. Bu kapsamlar, Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) ve Microsoft Graph (00000003-0000-0000-c000-000000000000) gibi temel Graph API'lerine yapılan çağrıların, kimlik doğrulamanın bir parçası olarak uygulamalar tarafından yaygın olarak kullanılan kullanıcı profili ve grup üyeliği bilgilerine erişimine izin verir. Örneğin: Outlook Exchange için belirteç istediğinde, geçerli kullanıcının temel hesap bilgilerini görüntüleyebilmek için User.Read kapsamını da ister.

Çoğu uygulamanın benzer bir bağımlılığı vardır ve bu nedenle bu düşük ayrıcalık kapsamları Tüm kaynaklar ilkelerinde otomatik olarak dışlanır. Daha önce dışlanan kapsamlar aşağıdaki gibi listelenir, uygulamaların bu izinleri kullanması için onay gereklidir.

  • Yerel istemciler ve Tek sayfalı uygulamalar (SPA) aşağıdaki düşük ayrıcalık kapsamlarına erişebilir:
    • Azure AD Graph: email, offline_access, openid, profile, User.Read
    • Microsoft Graph: email, offline_access, openid, profile, User.Read, People.Read
  • Gizli istemciler, Tüm kaynaklar ilkesinden dışlanmışsa aşağıdaki düşük ayrıcalık kapsamlarına erişebilir:
    • Azure AD Graph: email, offline_access, openid, profile, User.Read, User.Read.All,User.ReadBasic.All
    • Microsoft Graph: email, offline_access, openid, profile, User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden

"Bir TÜM kaynaklar ilkesinde kaynak dışlaması olduğunda yeni Koşullu Erişim davranışı"

Önceki bölümde listelenen kapsamlar artık dizin erişimi olarak değerlendirilir ve Koşullu Erişim değerlendirme amacıyla Azure AD Graph (kaynak: Windows Azure Active Directory, kimlik: 00000002-0000-0000-c000-000000000000) ile eşlenir.

Bir veya daha fazla kaynak dışlaması olan tüm kaynakları hedefleyen Koşullu Erişim ilkeleri veya açıkça AD Graph Azure hedefleyen ilkeler, istemci uygulamasının yalnızca bu kapsamları istediği kullanıcı oturum açma akışlarında uygulanır. Bir uygulama yukarıda listelenenlerin dışında herhangi bir ek kapsam istediğinde davranışta bir değişiklik olmaz.

Etkiyi değerlendirme, etkilenen uygulamaları tanımlama ve eski davranışların korunması hakkında yönergeler için bkz. Kaynak dışlamaları içeren ilkeler için geliştirilmiş zorlama.

Note

Azure AD Graph kullanımdan kaldırma kiracınızda kayıtlı Azure AD Graph (Windows Azure Active Directory) kaynağını etkilemez.

Kullanıcı deneyimi

İstemci uygulamalarının yalnızca yukarıda listelenen kapsamları istediği kullanıcı oturum açma akışlarında, kullanıcılar artık Koşullu Erişim zorlukları (MFA veya cihaz uyumluluğu gibi) alabilir. Tam zorluk, ilkelerinizde yapılandırılan ve Tüm kaynakları veya Azure AD Graph’i açıkça hedefleyen (kaynak dışlamaları içerebilen veya içermeyen) erişim denetimlerine bağlıdır.

Aşağıdaki örnekte, kiracının aşağıdaki ayrıntıları içeren bir Koşullu Erişim ilkesi vardır:

  • Tüm kullanıcıları ve Tüm kaynakları hedefleme
  • Gizli istemci uygulaması ve Exchange Online için kaynak dışlamaları
  • MFA, izin denetimi olarak yapılandırıldı

Örnek senaryolar

Örnek senaryo Kullanıcı etkisi (önce → sonra) Koşullu Erişim değerlendirmesi
Kullanıcı, openid ve profil kapsamları isteyen Visual Studio Code masaüstü istemcisinde oturum açar. Önce: Kullanıcıdan MFA
istenmiyorSonra: Kullanıcıdan MFA istendi		 Koşullu Erişim artık zorlama hedef kitlesi olarak Windows Azure Active Directory kullanılarak değerlendirilir.
Kullanıcı Azure CLI kullanarak oturum açar, bu da yalnızca User.Read ister. Önce: Kullanıcıdan MFA
istenmiyorSonra: Kullanıcıdan MFA istendi		 Koşullu Erişim artık zorlama hedef kitlesi olarak Windows Azure Active Directory kullanılarak değerlendirilir.
Kullanıcı, yalnızca User.Read ve People.Readisteklerinde bulunan gizli bir istemci uygulaması (ilkeden hariç) aracılığıyla oturum açar. Önce: Kullanıcıdan MFA
istenmiyorSonra: Kullanıcıdan MFA istendi		 Koşullu Erişim artık zorlama hedef kitlesi olarak Windows Azure Active Directory kullanılarak değerlendirilir.

Aşağıdaki örneklerde gösterildiği gibi, bir istemci uygulaması daha önce listelenenlerin dışında bir kapsam istediğinde davranışta bir değişiklik yoktur.

Örnek senaryolar

Örnek senaryo Kullanıcı etkisi Koşullu Erişim değerlendirmesi
Kullanıcı, offline_access ve SharePoint erişim (Files.Read) isteyen gizli bir istemci uygulamasında (ilke dışındadır) oturum açar. Davranışta değişiklik yok Koşullu Erişim, SharePoint kaynağına göre uygulanmaya devam eder.
Kullanıcı OneDrive masaüstü eşitleme istemcisinde oturum açar. OneDrive offline_access ve Exchange Online erişimi (Mail.Read) ister. Davranışta değişiklik yok koşullu erişim zorlanmaz çünkü Exchange Online ilkenin dışında tutulur.

Uygulamaların çoğu, önceden listelenen kapsamların ötesinde kapsamlar istemektedir ve uygulama açıkça ilkeden dışlanmadığı sürece koşullu erişim zorlamasına zaten tabidir. Böyle durumlarda davranışta bir değişiklik olmaz.

Kasıtlı olarak yalnızca daha önce listelenen kapsamları istemek üzere tasarlanmış olan ve Koşullu Erişim sınamalarını işleyecek şekilde tasarlanmamış özel uygulamaların, Koşullu Erişim zorluklarını işleyebilmeleri için güncelleştirilmesi gerekebilir. Uygulama ayrıntıları için Microsoft Koşullu Erişim geliştirici kılavuzuna bakın.

Düşük ayrıcalıklı kapsam zorlaması değişikliğinden etkilenen uygulamaları tanımlama

Uygulamalar, önceden listelenen kapsamlardan yalnızca bir veya daha fazlasını istemek için önceden yetkilendirilebilir. Etkilenen uygulamaları tanımlamak için aşağıdaki seçenekleri kullanın.

Kiracınızda bu değişiklikten etkilenen kapsamlardan yalnızca bir veya daha fazlasını isteme yetkisine sahip tüm uygulamaları listelemek için aşağıdaki PowerShell betiğini kullanın.

Note

Uygulamalar dinamik olarak (yönetici onayıyla) ek kapsamlar isteyebilir. Bu betik bu tür uygulamaları tanımlamaz.

# ==============================
# Inventory of apps whose delegated consent grants include ONLY
# the OIDC scopes + specific directory scopes listed below.
#
# Enhancements incorporated:
#  - Supported both PowerShell 5.1 and 7.x
#  - Add user sign-in count (last 7 days) per app
#
# Output:
#  - ServicePrincipalObjectId (oauth2PermissionGrants.clientId = SP object id)
#  - AppId
#  - AppDisplayName
#  - AppOwnerOrganizationId (for classification)
#  - Scopes (union of delegated scopes granted)
#  - UserSigninsLast7Days (Successful + Failed)
# ==============================

$TenantId = Read-Host "Enter your Microsoft Entra tenant ID (GUID)"

$BaselineScopes = @(
  "openid", "profile", "email", "offline_access",
  "User.Read", "User.Read.All", "User.ReadBasic.All",
  "People.Read", "People.Read.All",
  "GroupMember.Read.All", "Member.Read.Hidden"
)

Disconnect-MgGraph -ErrorAction SilentlyContinue

Connect-MgGraph -TenantId $TenantId -Scopes @(
  "DelegatedPermissionGrant.Read.All",
  "Directory.Read.All",
  "Reports.Read.All"
)

# ------------------------------
# Pull oauth2PermissionGrants (paging)
# ------------------------------
$uri = "https://graph.microsoft.com/beta/oauth2PermissionGrants?`$select=clientId,scope,consentType"
$grants = @()
while ($uri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $uri
  $grants += $resp.value
  $uri = $resp.'@odata.nextLink'
}

# ------------------------------
# Build baseline-only candidate set (Jun: HashSet per clientId)
# ------------------------------
$scopesByClient = @{}  # key: clientId (SP objectId), value: HashSet[string] (case-insensitive)

foreach ($g in $grants) {
  $cid = $g.clientId.ToString().Trim()
  if (-not $cid) { continue }

  if (-not $scopesByClient.ContainsKey($cid)) {
    $scopesByClient[$cid] = [System.Collections.Generic.HashSet[string]]::new(
      [System.StringComparer]::OrdinalIgnoreCase
    )
  }

  foreach ($s in ($g.scope -split '\s+')) {
    if ($s -and $s.Trim().Length -gt 0) {
      [void]$scopesByClient[$cid].Add($s.Trim())
    }
  }
}

$candidates = foreach ($cid in $scopesByClient.Keys) {
  $scopes = $scopesByClient[$cid]
  if ($scopes.Count -le 0) { continue }

  $outside = $scopes | Where-Object { $_ -notin $BaselineScopes }
  if ($outside.Count -eq 0) {
    [PSCustomObject]@{
      ServicePrincipalObjectId = $cid
      Scopes = ($scopes -join ' ')
    }
  }
}

# ------------------------------
# Pull per-app sign-in summary for last 7 days (Graph REST via Invoke-MgGraphRequest)
# Endpoint: GET /beta/reports/getAzureADApplicationSignInSummary(period='D7')
# In this API output, 'id' corresponds to the appId (clientId)
# ------------------------------
$signInSummary = @()
$signInUri = "https://graph.microsoft.com/beta/reports/getAzureADApplicationSignInSummary(period='D7')"

while ($signInUri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $signInUri

  if ($resp -and $resp.value) {
    $signInSummary += $resp.value
  }

  # Paging (if present)
  $signInUri = $resp.'@odata.nextLink'
}

# appId -> total sign-ins (7d)
$signInCountByAppId = @{}
foreach ($s in $signInSummary) {
  $appId = $s.id
  if (-not $appId) { continue }

  # PS5.1-safe null handling
  $success = 0
  $failed  = 0
  if ($null -ne $s.successfulSignInCount) { $success = [int]$s.successfulSignInCount }
  if ($null -ne $s.failedSignInCount)     { $failed  = [int]$s.failedSignInCount }

  $signInCountByAppId[$appId] = $success + $failed
}

$resultsTenantOwned = @()
$resultsNotTenantOwned = @()

# ------------------------------
# Filter to tenant-owned or external apps; enrich with appId/displayName + sign-in counts
# ------------------------------
foreach ($c in $candidates) {
  try {
    $spUri = "https://graph.microsoft.com/beta/servicePrincipals/$($c.ServicePrincipalObjectId)?`$select=id,appId,displayName,appOwnerOrganizationId"
    $sp = Invoke-MgGraphRequest -Method GET -Uri $spUri

    $signinCount7d = 0
    if ($sp.appId -and $signInCountByAppId.ContainsKey($sp.appId)) {
      $signinCount7d = $signInCountByAppId[$sp.appId]
    }

    $row = [PSCustomObject]@{
      ServicePrincipalObjectId = $c.ServicePrincipalObjectId
      AppId                   = $sp.appId
      AppDisplayName          = $sp.displayName
      AppOwnerOrganizationId  = $sp.appOwnerOrganizationId
      Scopes                  = $c.Scopes
      UserSigninsLast7Days    = $signinCount7d
    }

    if ($sp.appOwnerOrganizationId -eq $TenantId) {
      $resultsTenantOwned += $row
    }
    else {
      $resultsNotTenantOwned += $row
    }
  }
  catch {
    # Ignore non-enumerable / missing service principals
  }
}

# ------------------------------
# Output
# ------------------------------
'=== Tenant-owned apps whose delegated consent grants include ONLY baseline scopes + user sign-ins (last 7 days) ==='
$resultsTenantOwned |
  Sort-Object UserSigninsLast7Days -Descending |
  Format-Table -AutoSize

'=== External apps whose delegated consent grants include ONLY baseline scopes + user sign-ins (last 7 days) ==='
$resultsNotTenantOwned |
  Sort-Object UserSigninsLast7Days -Descending |
  Format-Table -AutoSize

Dizin bilgilerini koruma

Note

Aşağıdaki bölüm, düşük ayrıcalıklı kapsam zorlaması değişikliği yayılımı tamamlanana kadar geçerlidir.

Bir önerilen temel MFA politikası, iş nedenlerinden dolayı yapılandırılamıyorsa ve kuruluşunuzun güvenlik politikası dizinle ilgili düşük ayrıcalık kapsamlarını (User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden) içermek zorundaysa, Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) hedefleyen ayrı bir Koşullu Erişim politikası oluşturun. Windows Azure Active Directory (Azure AD Graph olarak da adlandırılır), kullanıcılar, gruplar ve uygulamalar gibi dizinde depolanan verileri temsil eden bir kaynaktır. Windows Azure Active Directory kaynağı Tüm kaynaklar eklenir, ancak aşağıdaki adımlar kullanılarak Koşullu Erişim ilkelerine tek tek hedeflenebilir:

  1. Microsoft Entra yönetim merkeziAttribute Tanım Yöneticisi ve Attribute Atama Yöneticisi olarak oturum açın.
  2. Entra ID>Özel güvenlik öznitelikleri adresine gidin.
  3. Yeni bir öznitelik kümesi ve öznitelik tanımı oluşturun. Daha fazla bilgi için bkz. Microsoft Entra ID'da özel güvenlik özniteliği tanımlarını ekleme veya devre dışı bırakma.
  4. Entra ID>Enterprise apps adresine gidin.
  5. Uygulama türü filtresini kaldırın ve 00000002-0000-0000-c000-000000000000 ile başlayan Uygulama Kimliği arayın.
  6. Windows Azure Active Directory>Özel güvenlik öznitelikleri>Add assignment öğesini seçin.
  7. İlkede kullanmayı planladığınız öznitelik kümesini ve öznitelik değerini seçin.
  8. Entra ID>Conditional Access>Policies adresine gidin.
  9. Var olan bir ilkeyi oluşturun veya değiştirin.
  10. Hedef kaynaklar>Kaynaklar (eski adı bulut uygulamaları)>'i dahil et, >'i seçin,'u seçin.>Filtreyi düzenle.
  11. Filtreyi daha önceki öznitelik kümenizi ve tanımınızı içerecek şekilde ayarlayın.
  12. Erişim denetimleri altında Ver, >Erişim ver seçeneğini seçin, Kimlik doğrulama gücü gerektir'i seçin, Çok faktörlü kimlik doğrulama seçeneğini belirleyin ve ardından Seç 'i seçin.
  13. Ayarlarınızı onaylayın ve Etkinleştirme politikasınıSadece Raporla olarak ayarlayın.
  14. İlkenizi etkinleştirmek için Oluştur'u seçin.

Note

Bu ilkeyi yukarıdaki kılavuzda açıklandığı gibi yapılandırın. İlkenin oluşturulmasında açıklanan sapmalar (kaynak dışlamalarını tanımlama gibi) düşük ayrıcalık kapsamlarının dışlanmasına ve ilkenin amaçlandığı gibi uygulanmamasıyla sonuçlanabilir.

Genel Güvenli Erişim ile tüm internet kaynakları

Tüm internet kaynakları ile Global Secure Access seçeneği, yöneticilerin Microsoft Entra İnternet Erişimi kullanarak internet erişim trafiği iletme profilini hedeflemesine olanak tanır.

Genel Güvenli Erişim'deki bu profiller, yöneticilerin trafiğin Microsoft Entra İnternet Erişimi ve Microsoft Entra Özel Erişim üzerinden nasıl yönlendirileceğine yönelik tanımlama ve denetleme olanağı sağlar. Trafik iletme profilleri cihazlara ve uzak ağlara atanabilir. Bu trafik profillerine Koşullu Erişim ilkesi uygulama örneği için Microsoft 365 trafik profiline Koşullu Erişim ilkeleri uygulama makalesine bakın.

Bu profiller hakkında daha fazla bilgi için Genel Güvenli Erişim trafik iletme profilleri makalesine bakın.

Tüm aracı kaynakları (Önizleme)

Koşullu Erişim ilkesinin Tüm aracı kaynaklarına uygulanması, aracı kimliği şema sorumlularına ve aracı kimliklerine yönelik tüm belirteç istekleri için ilkeyi zorlar.

Kullanıcı eylemleri

Kullanıcı eylemleri, kullanıcının gerçekleştirdiği görevlerdir. Koşullu Erişim iki kullanıcı eylemini destekler:

  • Güvenlik bilgilerini kaydetme: Bu kullanıcı eylemi, kullanıcılar güvenlik bilgilerini kaydetmeye çalıştığında Koşullu Erişim ilkelerinin kuralları zorlamasına olanak tanır. Daha fazla bilgi için bkz. Birleşik güvenlik bilgileri kaydı.

Note

Yöneticiler güvenlik bilgilerini kaydetmek için kullanıcı eylemlerini hedefleyen bir ilke uygularsa ve kullanıcı hesabı bir Microsoft kişisel hesaptan (MSA) konuksa, 'Çok faktörlü kimlik doğrulaması gerektir' denetimi, MSA kullanıcısının güvenlik bilgilerini kuruluşa kaydetmesini gerektirir. Konuk kullanıcı Googlegibi başka bir sağlayıcıdan geliyorsa erişim engellenir.

  • Cihazları kaydetme veya bağlama: Bu kullanıcı eylemi, kullanıcıların cihazları Microsoft Entra ID'ye kaydedip bağladıklarında Koşullu Erişim ilkesini zorunlu kılabilmesi için yöneticilerin yetki vermesini sağlar. Yöneticilerin, kiracı genelindeki bir ilkeden daha fazla ayrıntı düzeyine sahip cihazları kaydetmek veya birleştirmek için çok faktörlü kimlik doğrulamasını yapılandırmasına olanak tanır. Bu kullanıcı eylemiyle ilgili üç önemli nokta vardır:
    • Require multifactor authentication ve Require auth strength bu kullanıcı eylemiyle kullanılabilen tek erişim denetimleridir ve diğer tüm erişim denetimleri devre dışı bırakılır. Bu kısıtlama, Microsoft Entra cihaz kaydına bağımlı olan veya Microsoft Entra cihaz kaydı için geçerli olmayan erişim denetimleriyle çakışmaları önler.
      • Kurumsal Windows Hello ve cihaza bağlı geçiş anahtarları desteklenmez çünkü bu senaryolar cihazın zaten kayıtlı olmasını gerektirir.
    • Client apps, Filters for devices ve Device state koşulları, Koşullu Erişim ilkelerini zorunlu kılmak için Microsoft Entra cihaz kaydına bağımlı olduklarından bu kullanıcı eylemiyle kullanılamaz.

Warning

Koşullu Erişim ilkesi Cihazları kaydetme veya birleştirme kullanıcı eylemiyle yapılandırılmışsa, Entra IDCihazlarGenel BakışCihaz Ayarları öğesini Hayır olarak ayarlayın. Aksi takdirde, bu kullanıcı eylemine sahip Koşullu Erişim ilkeleri düzgün bir şekilde uygulanmaz. Cihaz ayarlarını yapılandırma bölümünde bu cihaz ayarı hakkında daha fazla bilgi edinin.

Kimlik doğrulama bağlamı

Kimlik doğrulama bağlamı, uygulamalarda verilerin ve eylemlerin güvenliğini sağlar. Bu uygulamalar özel uygulamalar, iş kolu (LOB) uygulamaları, SharePoint veya Microsoft Defender for Cloud Apps tarafından korunan uygulamaları içerir. Rol etkinleştirme sırasında Koşullu Erişim ilkelerini zorunlu kılmak için Microsoft Entra Privileged Identity Management (PIM) ile de kullanılabilir.

Örneğin, bir kuruluş dosyaları öğle yemeği menüsü veya gizli barbekü sosu tarifi gibi SharePoint sitelerde depolayabilir. Herkes öğle yemeği menüsü sitesine erişebilir, ancak gizli barbekü sosu tarifi sitesine erişen kullanıcıların yönetilen bir cihaz kullanması ve belirli kullanım koşullarını kabul etmeleri gerekebilir. Benzer şekilde, çok faktörlü kimlik doğrulaması gerçekleştirmek veya uyumlu bir cihaz kullanmak için PIM aracılığıyla ayrıcalıklı bir rolü etkinleştiren bir yönetici gerekebilir.

Kimlik doğrulama bağlamı kullanıcılarla veya iş yükü kimlikleriyle çalışır, ancak aynı Koşullu Erişim ilkesinde çalışmaz.

Kimlik doğrulama bağlamlarını yapılandırma

Entra ID>Conditional Access>Authentication context adresine giderek kimlik doğrulama bağlamlarını yönetin.

Kimlik doğrulama bağlamlarının yönetimini gösteren ekran görüntüsü.

Kimlik doğrulama bağlamı tanımı oluşturmak için Yeni kimlik doğrulama bağlamı'na tıklayın. Kuruluşlar en fazla 99 kimlik doğrulama bağlamı tanımı (c1-c99) oluşturabilir. Şu öznitelikleri yapılandırın:

  • Display name Microsoft Entra ID ve kimlik doğrulama bağlamlarını kullanan uygulamalar arasında kimlik doğrulama bağlamını tanımlamak için kullanılan addır. Gereken kimlik doğrulama bağlamlarının sayısını azaltmak için güvenilir cihazlar gibi kaynaklar arasında kullanılabilecek adları kullanın. Azaltılmış bir kümeye sahip olmak, yeniden yönlendirme sayısını sınırlar ve son kullanıcı için daha iyi bir deneyim sağlar.
  • Açıklama , ilkeler hakkında daha fazla bilgi sağlar. Bu bilgiler, yöneticiler ve kaynaklara kimlik doğrulama bağlamları uygulayanlar tarafından kullanılır.
  • Uygulamalarda yayımla onay kutusu seçildiğinde, kimlik doğrulama bağlamını uygulamalara duyurur ve atanmak üzere kullanılabilir hale getirir. Seçili değilse, kimlik doğrulama bağlamı aşağı akış kaynakları için kullanılamaz.
  • ID yalnızca okunabilir ve isteğe özgü kimlik doğrulama bağlamı tanımları için belirteçlerde ve uygulamalarda kullanılır. Sorun giderme ve geliştirme kullanım örnekleri için burada listelenmiştir.

Koşullu Erişim ilkesine ekle

Yöneticiler, Atama hedefi>kaynakları'na gidip Bu ilkenin ne için geçerli olduğunu seçinmenüsünden Kimlik doğrulama bağlamı'nı seçerek Koşullu Erişim ilkelerinde yayımlanan kimlik doğrulama bağlamlarını seçebilir.

Bir politikaya Koşullu Erişim kimlik doğrulama bağlamı ekleme yöntemini gösteren ekran görüntüsü

Kimlik doğrulama bağlamı silme

Bir kimlik doğrulama bağlamı silinmeden önce, hiçbir uygulamanın bunu kullanmadığından emin olun. Aksi takdirde uygulama verilerine erişim korunmaz. Kimlik doğrulama bağlamı Koşullu Erişim ilkelerinin uygulandığı durumlar için oturum açma günlüklerini denetleyerek bunu onaylayın.

Bir kimlik doğrulama bağlamı silmek için, atanmış Koşullu Erişim ilkeleri olmadığından ve uygulamalarda yayımlanmadığından emin olun. Bu, kimlik doğrulama bağlamının yanlışlıkla silinmesini engeller.

Kimlik doğrulama bağlamlarıyla kaynakları etiketleme

Kimlik doğrulama bağlamlarını kullanma hakkında daha fazla bilgi edinmek için aşağıdaki makalelere bakın.

İlgili içerik

  • Last updated on