Az - Temel Bilgiler

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

• Abonelik planlarını kontrol edin!
• Katılın 💬 Discord group veya telegram group veya Twitter’da bizi takip edin 🐦 @hacktricks_live.
• PR göndererek hacking tricks paylaşın: HackTricks ve HackTricks Cloud github repos.

Organizasyon Hiyerarşisi

Yönetim Grupları

• Diğer yönetim gruplarını veya abonelikleri içerebilir.
• Bu, yönetim grubu düzeyinde yönetim kontrolleri (RBAC ve Azure Policy gibi) uygulamayı ve bunların gruptaki tüm abonelikler tarafından devralınmasını sağlar.
• Tek bir dizinde 10.000 yönetim grubu desteklenebilir.
• Bir yönetim grubu ağacı altı seviyeye kadar derinliği destekleyebilir. Bu sınır, kök düzeyini veya abonelik düzeyini içermez.
• Her yönetim grubu ve abonelik sadece bir ebeveyn destekleyebilir.
• Birden fazla yönetim grubu oluşturulabilse de sadece 1 kök yönetim grubu vardır.
• Kök yönetim grubu, diğer tüm yönetim gruplarını ve abonelikleri içerir ve taşınamaz veya silinemez.
• Tek bir yönetim grubundaki tüm abonelikler aynı Entra ID kiracısına güvenmelidir.

Azure Abonelikleri

• Kaynakların (VM’ler, DB’ler…) çalıştırılabileceği ve faturalandırılacağı başka bir mantıksal konteynerdir.
• Ebeveyni her zaman bir yönetim grubudur (ve kök yönetim grubu olabilir) çünkü abonelikler diğer abonelikleri içeremez.
• Sadece bir Entra ID dizinine güvenmektedir.
• Abonelik düzeyinde (veya ebeveynlerinden herhangi birinde) uygulanan izinler, abonelik içindeki tüm kaynaklara devralınır.

Kaynak Grupları

Belgelerden: Bir kaynak grubu, bir Azure çözümü için ilişkili kaynakları tutan bir konteynerdir. Kaynak grubu, çözüm için tüm kaynakları veya yalnızca bir grup olarak yönetmek istediğiniz kaynakları içerebilir. Genel olarak, aynı yaşam döngüsüne sahip kaynakları aynı kaynak grubuna ekleyin, böylece bunları grup olarak kolayca dağıtabilir, güncelleyebilir ve silebilirsiniz.

Tüm kaynaklar bir kaynak grubunun içinde olmalı ve yalnızca bir gruba ait olabilir ve bir kaynak grubu silinirse, içindeki tüm kaynaklar da silinir.

Azure Kaynak Kimlikleri

Azure’daki her kaynak, onu tanımlayan bir Azure Kaynak Kimliğine sahiptir.

Bir Azure Kaynak Kimliğinin formatı şu şekildedir:

• /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}

12345678-1234-1234-1234-123456789012 abonelik kimliği altında myResourceGroup kaynak grubunda myVM adında bir sanal makine için Azure Kaynak Kimliği şu şekilde görünür:

• /subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM

Azure vs Entra ID vs Azure AD Alan Hizmetleri

Azure

Azure, Microsoft’un kapsamlı bulut bilişim platformudur, geniş bir hizmet yelpazesi sunar, sanal makineler, veritabanları, yapay zeka ve depolama dahil. Uygulamaları barındırmak ve yönetmek, ölçeklenebilir altyapılar oluşturmak ve bulutta modern iş yüklerini çalıştırmak için bir temel görevi görür. Azure, geliştiricilerin ve BT profesyonellerinin uygulamaları ve hizmetleri sorunsuz bir şekilde oluşturmasına, dağıtmasına ve yönetmesine olanak tanır ve başlangıçlardan büyük işletmelere kadar çeşitli ihtiyaçlara hitap eder.

Entra ID (eski adıyla Azure Active Directory)

Entra ID, kimlik doğrulama, yetkilendirme ve kullanıcı erişim kontrolünü yönetmek için tasarlanmış bulut tabanlı bir kimlik ve erişim yönetim hizmetidir. Office 365, Azure ve birçok üçüncü taraf SaaS uygulaması gibi Microsoft hizmetlerine güvenli erişimi sağlar. Tek oturum açma (SSO), çok faktörlü kimlik doğrulama (MFA) ve koşullu erişim politikaları gibi özellikler sunar.

Entra Alan Hizmetleri (eski adıyla Azure AD DS)

Entra Alan Hizmetleri, Entra ID’nin yeteneklerini, geleneksel Windows Active Directory ortamlarıyla uyumlu yönetilen alan hizmetleri sunarak genişletir. LDAP, Kerberos ve NTLM gibi eski protokolleri destekler ve kuruluşların, yerel alan denetleyicileri dağıtmadan bulutta eski uygulamaları taşımalarına veya çalıştırmalarına olanak tanır. Bu hizmet ayrıca merkezi yönetim için Grup İlkesi’ni destekler ve eski veya AD tabanlı iş yüklerinin modern bulut ortamlarıyla bir arada var olması gereken senaryolar için uygundur.

Entra ID Prensipleri

Kullanıcılar

• Yeni kullanıcılar
• Seçilen kiracıdan e-posta adı ve alanı belirtin
• Görünen adı belirtin
• Parolayı belirtin
• Özellikleri belirtin (ad, unvan, iletişim bilgileri…)
• Varsayılan kullanıcı türü “üye”dir
• Dış kullanıcılar
• Davet etmek için e-posta ve görünen adı belirtin (Microsoft dışı bir e-posta olabilir)
• Özellikleri belirtin
• Varsayılan kullanıcı türü “Misafir”dir

Üyeler & Misafirlerin Varsayılan İzinleri

Bunları https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions adresinde kontrol edebilirsiniz, ancak diğer eylemler arasında bir üye şunları yapabilecektir:

• Tüm kullanıcıları, Grupları, Uygulamaları, Cihazları, Rolleri, Abonelikleri ve bunların genel özelliklerini okumak
• Misafirleri davet etmek (kapalı hale getirilebilir)
• Güvenlik grupları oluşturmak
• Gizli olmayan Grup üyeliklerini okumak
• Sahip olunan gruplara misafir eklemek
• Yeni uygulama oluşturmak (kapalı hale getirilebilir)
• Azure’a 50’ye kadar cihaz eklemek (kapalı hale getirilebilir)

Note

Azure kaynaklarını listelemek için kullanıcının izinlerin açıkça verilmesi gerekir.

Kullanıcıların Varsayılan Yapılandırılabilir İzinleri

• Üyeler (belgeler)
• Uygulamaları kaydet: Varsayılan Evet
• Yönetici olmayan kullanıcıların kiracı oluşturmasını kısıtla: Varsayılan Hayır
• Güvenlik grupları oluştur: Varsayılan Evet
• Microsoft Entra yönetim portalına erişimi kısıtla: Varsayılan Hayır
• Bu, portala API erişimini kısıtlamaz (sadece web)
• Kullanıcıların iş veya okul hesaplarını LinkedIn ile bağlamasına izin ver: Varsayılan Evet
• Kullanıcının oturumunu açık tutmasını göster: Varsayılan Evet
• Kullanıcıların sahip oldukları cihazlar için BitLocker anahtarını kurtarmasını kısıtla: Varsayılan Hayır (Cihaz Ayarlarında kontrol edin)
• Diğer kullanıcıları okumak: Varsayılan Evet (Microsoft Graph aracılığıyla)
• Misafirler
• Misafir kullanıcı erişim kısıtlamaları seçenekleri:
• Misafir kullanıcılar, üyelerle aynı erişime sahiptir.
• Misafir kullanıcıların dizin nesnelerinin özelliklerine ve üyeliklerine sınırlı erişimi vardır (varsayılan). Bu, misafir erişimini varsayılan olarak yalnızca kendi kullanıcı profillerine kısıtlar. Diğer kullanıcılar ve grup bilgilerine erişim artık izin verilmez.
• Misafir kullanıcı erişimi, kendi dizin nesnelerinin özelliklerine ve üyeliklerine kısıtlanmıştır en kısıtlayıcı olanıdır.
• Misafirleri davet etme seçenekleri:
• Kuruluşta herhangi biri, misafir kullanıcıları davet edebilir, misafirler ve yönetici olmayanlar dahil (en kapsayıcı) - Varsayılan
• Üye kullanıcılar ve belirli yönetici rollerine atanmış kullanıcılar, misafir kullanıcıları davet edebilir, üyelik izinleri olan misafirler dahil
• Sadece belirli yönetici rollerine atanmış kullanıcılar misafir kullanıcıları davet edebilir
• Kuruluşta hiç kimse, misafir kullanıcıları davet edemez, yöneticiler dahil (en kısıtlayıcı)
• Dış kullanıcıların ayrılması: Varsayılan Doğru
• Dış kullanıcıların kuruluşu terk etmesine izin ver

Tip

Varsayılan olarak kısıtlanmış olsa da, izin verilmiş kullanıcılar (üyeler ve misafirler) önceki eylemleri gerçekleştirebilir.

Gruplar

2 tür grup vardır:

• Güvenlik: Bu tür grup, üyelere uygulamalara, kaynaklara erişim vermek ve lisans atamak için kullanılır. Kullanıcılar, cihazlar, hizmet ilkeleri ve diğer gruplar üye olabilir.
• Microsoft 365: Bu tür grup, işbirliği için kullanılır, üyelere paylaşılan bir posta kutusuna, takvime, dosyalara, SharePoint sitesine vb. erişim verir. Grup üyeleri yalnızca kullanıcılar olabilir.
• Bu, EntraID kiracısının alanıyla bir e-posta adresine sahip olacaktır.

2 tür üyelik vardır:

• Atanmış: Belirli üyeleri bir gruba manuel olarak eklemeye izin verir.
• Dinamik üyelik: Üyelikleri kurallar kullanarak otomatik olarak yönetir, üyelerin özellikleri değiştiğinde grup dahil olmasını günceller.

Hizmet İlkeleri

Bir Hizmet İlkesi, uygulamalar, barındırılan hizmetler ve otomatik araçlarla Azure kaynaklarına erişim için oluşturulmuş bir kimliktir. Bu erişim, hizmet ilkesine atanan rollerle kısıtlanır, böylece hangi kaynakların erişilebileceği ve hangi düzeyde kontrol sağlanır. Güvenlik nedenleriyle, hizmet ilkelerini otomatik araçlarla kullanmak her zaman önerilir, kullanıcı kimliği ile giriş yapmalarına izin vermektense.

Bir hizmet ilkesine doğrudan giriş yapmak mümkündür, bir gizli anahtar (parola), bir sertifika oluşturarak veya üçüncü taraf platformlara (örneğin, Github Actions) federasyon erişimi vererek.

• Parola kimlik doğrulamasını (varsayılan olarak) seçerseniz, oluşturulan parolayı kaydedin çünkü bir daha erişemezsiniz.
• Sertifika kimlik doğrulamasını seçerseniz, uygulamanın özel anahtara erişimi olmasını sağladığınızdan emin olun.

Uygulama Kayıtları

Bir Uygulama Kaydı, bir uygulamanın Entra ID ile entegre olmasına ve eylemler gerçekleştirmesine olanak tanıyan bir yapılandırmadır.

Ana Bileşenler:

1. Uygulama Kimliği (İstemci Kimliği): Azure AD’deki uygulamanız için benzersiz bir tanımlayıcı.
2. Yeniden Yönlendirme URI’leri: Azure AD’nin kimlik doğrulama yanıtlarını gönderdiği URL’ler.
3. Sertifikalar, Gizli Anahtarlar ve Federasyon Kimlik Bilgileri: Uygulamanın hizmet ilkesine giriş yapmak için bir gizli anahtar veya sertifika oluşturmak veya ona federasyon erişimi vermek mümkündür (örneğin, Github Actions).
4. Eğer bir sertifika veya gizli anahtar oluşturulursa, bir kişi hizmet ilkesi olarak giriş yapmak için CLI araçlarıyla uygulama kimliğini, gizli anahtarı veya sertifikayı ve kiracıyı (alan veya kimlik) bilerek giriş yapabilir.
5. API İzinleri: Uygulamanın erişebileceği kaynakları veya API’leri belirtir.
6. Kimlik Doğrulama Ayarları: Uygulamanın desteklediği kimlik doğrulama akışlarını tanımlar (örneğin, OAuth2, OpenID Connect).
7. Hizmet İlkesi: Bir Uygulama oluşturulduğunda (web konsolundan yapıldığında) veya yeni bir kiracıya yüklendiğinde bir hizmet ilkesi oluşturulur.
8. Hizmet ilkesi, yapılandırıldığı tüm istenen izinleri alır.

Varsayılan Onay İzinleri

Uygulamalar için kullanıcı onayı

• Kullanıcı onayını izin vermeyin
• Tüm uygulamalar için bir yönetici gerekecektir.
• Doğrulanmış yayıncılardan, dahili uygulamalardan ve yalnızca seçilen izinleri talep eden uygulamalar için kullanıcı onayına izin verin (Tavsiye Edilir)
• Tüm kullanıcılar, yalnızca “düşük etki” olarak sınıflandırılan izinleri talep eden, doğrulanmış yayıncılardan gelen ve kiracıda kayıtlı uygulamalar için onay verebilir.
• Varsayılan düşük etki izinleri (düşük etki olarak eklemek için kabul etmeniz gerekir):
• User.Read - oturum açma ve kullanıcı profilini okuma
• offline_access - kullanıcının erişim verdiği verilere erişimi sürdürme
• openid - kullanıcıları oturum açtırma
• profile - kullanıcının temel profilini görüntüleme
• email - kullanıcının e-posta adresini görüntüleme
• Uygulamalar için kullanıcı onayına izin ver (Varsayılan)
• Tüm kullanıcılar, herhangi bir uygulamanın kuruluşun verilerine erişmesi için onay verebilir.

Yönetici onay talepleri: Varsayılan Hayır

• Kullanıcılar, onay veremedikleri uygulamalar için yönetici onayı talep edebilir
• Eğer Evet: Onay taleplerini onaylayabilecek kullanıcılar, Gruplar ve Roller belirtilebilir
• Kullanıcıların e-posta bildirimleri ve son kullanma hatırlatmaları alıp almayacaklarını da yapılandırın

Yönetilen Kimlik (Meta Veriler)

Azure Active Directory’deki yönetilen kimlikler, uygulamaların kimliğini otomatik olarak yönetme çözümü sunar. Bu kimlikler, uygulamaların Azure Active Directory (Azure AD) kimlik doğrulaması ile uyumlu kaynaklara bağlanmak amacıyla kullanılır. Bu, uygulamanın meta veri hizmeti ile iletişim kurarak Azure’daki belirtilen yönetilen kimlik olarak hareket etmek için geçerli bir token almasını sağlar, böylece bulut kimlik bilgilerini kodda sabitleme ihtiyacını ortadan kaldırır.

İki tür yönetilen kimlik vardır:

• Sistem atamalı. Bazı Azure hizmetleri, bir hizmet örneği üzerinde yönetilen kimliği doğrudan etkinleştirmenize olanak tanır. Sistem atamalı bir yönetilen kimlik etkinleştirildiğinde, hizmet ilkesi, kaynağın bulunduğu abonelikteki Entra ID kiracısında oluşturulur. Kaynak silindiğinde, Azure otomatik olarak kimliği sizin için silmiştir.
• Kullanıcı atamalı. Kullanıcıların yönetilen kimlikler oluşturması da mümkündür. Bunlar, bir abonelik içindeki bir kaynak grubunun içinde oluşturulur ve EntraID’de abonelik tarafından güvenilen bir hizmet ilkesi oluşturulur. Daha sonra, yönetilen kimliği bir veya daha fazla Azure hizmeti örneğine (birden fazla kaynak) atayabilirsiniz. Kullanıcı atamalı yönetilen kimlikler için, kimlik, onu kullanan kaynaklardan ayrı olarak yönetilir.

Yönetilen Kimlikler, ona bağlı hizmet ilkesine erişmek için sonsuz kimlik bilgileri (parolalar veya sertifikalar gibi) oluşturmaz.

Kurumsal Uygulamalar

Bu, yalnızca hizmet ilkelerini filtrelemek ve atanmış uygulamaları kontrol etmek için Azure’da bir tablodur.

Bu, başka bir “uygulama” türü değildir, Azure’da “Kurumsal Uygulama” olan herhangi bir nesne yoktur, bu sadece Hizmet ilkelerini, Uygulama kayıtlarını ve yönetilen kimlikleri kontrol etmek için bir soyutlamadır.

İdari Birimler

İdari birimler, bir rol üzerinden bir organizasyonun belirli bir bölümüne izin vermeye olanak tanır.

Örnek:

• Senaryo: Bir şirket, bölgesel BT yöneticilerinin yalnızca kendi bölgelerindeki kullanıcıları yönetmesini istiyor.
• Uygulama:
• Her bölge için İdari Birimler oluşturun (örneğin, “Kuzey Amerika AU”, “Avrupa AU”).
• AU’ları, kendi bölgelerindeki kullanıcılarla doldurun.
• AU’lar kullanıcılar, gruplar veya cihazlar içerebilir.
• AU’lar dinamik üyelikleri destekler.
• AU’lar AU’ları içeremez.
• Yönetici Rolleri Atayın:
• Bölgesel BT personeline, kendi bölgesinin AU’suna sınırlı olarak “Kullanıcı Yöneticisi” rolünü verin.
• Sonuç: Bölgesel BT yöneticileri, diğer bölgeleri etkilemeden kendi bölgelerindeki kullanıcı hesaplarını yönetebilir.

Entra ID Rolleri & İzinleri

• Entra ID’yi yönetmek için, Entra ID’yi yönetmek üzere Entra ID prensiplerine atanabilecek bazı yerleşik roller vardır.
• Rolleri https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference adresinde kontrol edin.
• EntraID tarafından AYRICALIKLI olarak işaretlenen roller, dikkatle atanmalıdır çünkü Microsoft’un belgelerde açıkladığı gibi https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference: Ayrıcalıklı rol atamaları, güvenli ve amaçlanan bir şekilde kullanılmadığında ayrıcalık yükselmesine yol açabilir.
• En yüksek ayrıcalıklı rol Küresel Yöneticidir.
• Roller, ince izinleri gruplar ve açıklamalarında bulunabilir.
• İstenilen izinlerle özel roller oluşturmak mümkündür. Ancak bazı nedenlerden dolayı, tüm ince izinler yöneticilerin özel roller oluşturması için mevcut değildir.
• Entra ID’deki roller, Azure’daki rollerden tamamen bağımsızdır. Tek ilişki, Entra ID’deki Küresel Yönetici rolüne sahip prensiplerin Azure’daki Kullanıcı Erişim Yöneticisi rolüne yükseltilebilmesidir.
• Entra ID rollerinde joker karakter kullanmak mümkün değildir.

Azure Rolleri & İzinleri

• Roller, prensiplere bir kapsamda atanır: prensip -[ROLÜ VAR]->(kapsam)
• Gruplara atanan roller, grubun tüm üyeleri tarafından devralınır.
• Rolün atandığı kapsama bağlı olarak, rol, kapsama dahil diğer kaynaklara devralınabilir. Örneğin, bir kullanıcı A’nın bir abonelikte rolü varsa, o rolü, abonelikteki tüm kaynak gruplarında ve kaynak grubundaki tüm kaynaklarda olacaktır.

Yerleşik roller

Belgelerden: Azure rol tabanlı erişim kontrolü (Azure RBAC), kullanıcılara, gruplara, hizmet ilkelerine ve yönetilen kimliklere atayabileceğiniz birkaç Azure yerleşik rolü vardır. Rol atamaları, Azure kaynaklarına erişimi kontrol etmenin yoludur. Yerleşik roller, kuruluşunuzun özel ihtiyaçlarını karşılamıyorsa, kendi Azure özel rollerinizi oluşturabilirsiniz.

Yerleşik roller yalnızca amaçlandıkları kaynaklara uygulanır, örneğin, Hesaplama kaynakları üzerindeki bu 2 yerleşik rol örneğine bakın:

Bu roller, yönetim grupları, abonelikler ve kaynak grupları gibi mantıksal konteynerler üzerinde de atanabilir ve etkilenen prensipler, bu konteynerlerin içindeki kaynaklar üzerinde bu rollere sahip olacaktır.

• Burada tüm Azure yerleşik rollerinin bir listesini bulabilirsiniz.
• Burada tüm Entra ID yerleşik rollerinin bir listesini bulabilirsiniz.

Özel Roller

• Özel roller oluşturmak da mümkündür.
• Bunlar bir kapsam içinde oluşturulur, ancak bir rol birden fazla kapsamda (yönetim grupları, abonelikler ve kaynak grupları) olabilir.
• Özel rolün sahip olacağı tüm ince izinleri yapılandırmak mümkündür.
• İzinleri hariç tutmak mümkündür.
• Hariç tutulan bir izne sahip bir prensip, izin başka bir yerde verilse bile onu kullanamaz.
• Joker karakter kullanmak mümkündür.
• Kullanılan format bir JSON’dur.
• actions, kaynak tanımları ve ayarları oluşturma, güncelleme veya silme gibi yönetim işlemleri için izinleri ifade eder.
• dataActions, kaynak içindeki veri işlemleri için izinlerdir ve size kaynağın içindeki gerçek verileri okuma, yazma veya silme izni verir.
• notActions ve notDataActions, rolün belirli izinlerini hariç tutmak için kullanılır. Ancak, bunlar onları reddetmez, eğer farklı bir rol bunları veriyorsa, prensip bunlara sahip olacaktır.
• assignableScopes, rolün atanabileceği kapsamların bir dizisidir (yönetim grupları, abonelikler veya kaynak grupları gibi).

Özel bir rol için izinlerin JSON örneği:

{
"properties": {
"roleName": "",
"description": "",
"assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"],
"permissions": [
{
"actions": [
"Microsoft.DigitalTwins/register/action",
"Microsoft.DigitalTwins/unregister/action",
"Microsoft.DigitalTwins/operations/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/write",
"Microsoft.CostManagement/exports/*"
],
"notActions": [
"Astronomer.Astro/register/action",
"Astronomer.Astro/unregister/action",
"Astronomer.Astro/operations/read",
"Astronomer.Astro/organizations/read"
],
"dataActions": [],
"notDataActions": []
}
]
}
}

İzinler Sırası

• Bir prensibin bir kaynağa erişim sağlaması için ona açık bir rol verilmesi gerekir (herhangi bir şekilde) bu izni vermek için.
• Açık bir reddetme ataması, izni veren rolun önceliğine sahiptir.

Küresel Yöneticisi

Küresel Yöneticisi, Entra ID kiracısı üzerinde tam kontrol sağlayan bir Entra ID rolüdür. Ancak, varsayılan olarak Azure kaynakları üzerinde herhangi bir izin vermez.

Küresel Yöneticisi rolüne sahip kullanıcılar, Kök Yönetim Grubunda Kullanıcı Erişim Yöneticisi Azure rolüne ‘yükseltme’ yapma yeteneğine sahiptir. Bu nedenle, Küresel Yöneticiler tüm Azure abonelikleri ve yönetim gruplarında erişimi yönetebilir.
Bu yükseltme sayfanın sonunda yapılabilir: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties

Atama Koşulları & MFA

belgelere göre: Şu anda, blob depolama veri eylemleri veya kuyruk depolama veri eylemleri olan yerleşik veya özel rol atamalarına koşullar eklenebilir.

Reddetme Atamaları

Rol atamaları gibi, reddetme atamaları da Azure kaynaklarına erişimi kontrol etmek için kullanılır. Ancak, reddetme atamaları bir kaynağa erişimi açıkça reddetmek için kullanılır, kullanıcı bir rol ataması aracılığıyla erişim verilmiş olsa bile. Reddetme atamaları, rol atamalarının önceliğine sahiptir; bu, bir kullanıcıya bir rol ataması aracılığıyla erişim verilmişse ancak aynı zamanda bir reddetme ataması aracılığıyla açıkça erişimi reddedilmişse, reddetme atamasının öncelikli olacağı anlamına gelir.

Rol atamaları gibi, reddetme atamaları etkilenen prensipleri ve reddedilen izinleri belirten bir kapsam üzerinde uygulanır. Ayrıca, reddetme atamaları durumunda, reddin çocuk kaynaklara miras alınmasını önlemek mümkündür.

Azure Politikaları

Azure Politikaları, organizasyonların kaynaklarının belirli standartlara ve uyumluluk gereksinimlerine uygun olmasını sağlamalarına yardımcı olan kurallardır. Azure’daki kaynaklar üzerinde ayarları uygulamak veya denetlemek için kullanılır. Örneğin, yetkisiz bir bölgede sanal makinelerin oluşturulmasını engelleyebilir veya tüm kaynakların izleme için belirli etiketlere sahip olmasını sağlayabilirsiniz.

Azure Politikaları proaktiftir: uyumsuz kaynakların oluşturulmasını veya değiştirilmesini durdurabilir. Ayrıca reaktiftir, mevcut uyumsuz kaynakları bulmanıza ve düzeltmenize olanak tanır.

Anahtar Kavramlar

1. Politika Tanımı: Ne yapılmasına izin verildiğini veya neyin gerekli olduğunu belirten, JSON formatında yazılmış bir kural.
2. Politika Ataması: Bir politikanın belirli bir kapsamda (örneğin, abonelik, kaynak grubu) uygulanması.
3. Girişimler: Daha geniş bir uygulama için bir araya getirilmiş politika koleksiyonu.
4. Etkisi: Politika tetiklendiğinde ne olacağını belirtir (örneğin, “Reddet”, “Denetle” veya “Ekle”).

Bazı örnekler:

1. Belirli Azure Bölgeleri ile Uyum Sağlama: Bu politika, tüm kaynakların belirli Azure bölgelerinde dağıtılmasını sağlar. Örneğin, bir şirket tüm verilerinin GDPR uyumluluğu için Avrupa’da saklanmasını isteyebilir.
2. İsimlendirme Standartlarını Uygulama: Politikalar, Azure kaynakları için isimlendirme kurallarını uygulayabilir. Bu, büyük ortamlarda kaynakları isimlerine göre düzenlemeye ve kolayca tanımlamaya yardımcı olur.
3. Belirli Kaynak Türlerini Kısıtlama: Bu politika, belirli türde kaynakların oluşturulmasını kısıtlayabilir. Örneğin, maliyetleri kontrol etmek için belirli VM boyutları gibi pahalı kaynak türlerinin oluşturulmasını engellemek için bir politika ayarlanabilir.
4. Etiketleme Politikalarını Uygulama: Etiketler, kaynak yönetimi için kullanılan Azure kaynakları ile ilişkili anahtar-değer çiftleridir. Politikalar, tüm kaynaklar için belirli etiketlerin mevcut olmasını veya belirli değerlere sahip olmasını zorunlu kılabilir. Bu, maliyet takibi, sahiplik veya kaynakların kategorize edilmesi için faydalıdır.
5. Kaynaklara Kamu Erişimini Sınırlama: Politikalar, belirli kaynakların, örneğin depolama hesapları veya veritabanlarının, kamu uç noktalarına sahip olmamasını zorunlu kılabilir, böylece yalnızca organizasyonun ağı içinde erişilebilir olmalarını sağlar.
6. Güvenlik Ayarlarını Otomatik Olarak Uygulama: Politikalar, tüm VM’lere belirli bir ağ güvenlik grubunu uygulamak veya tüm depolama hesaplarının şifreleme kullanmasını sağlamak gibi kaynaklara güvenlik ayarlarını otomatik olarak uygulamak için kullanılabilir.

Azure Politikalarının Azure hiyerarşisinin herhangi bir seviyesine eklenebileceğini unutmayın, ancak genellikle kök yönetim grubunda veya diğer yönetim gruplarında kullanılır.

Azure politika json örneği:

{
"policyRule": {
"if": {
"field": "location",
"notIn": ["eastus", "westus"]
},
"then": {
"effect": "Deny"
}
},
"parameters": {},
"displayName": "Allow resources only in East US and West US",
"description": "This policy ensures that resources can only be created in East US or West US.",
"mode": "All"
}

İzin Mirası

Azure’da izinler hiyerarşinin herhangi bir parçasına atanabilir. Bu, yönetim gruplarını, abonelikleri, kaynak gruplarını ve bireysel kaynakları içerir. İzinler, atandıkları varlığın içindeki kaynaklar tarafından miras alınır.

Bu hiyerarşik yapı, erişim izinlerinin verimli ve ölçeklenebilir bir şekilde yönetilmesini sağlar.

Azure RBAC vs ABAC

RBAC (rol tabanlı erişim kontrolü), önceki bölümlerde gördüğümüz şeydir: Bir kaynağa erişim sağlamak için bir ilkeye rol atamak.
Ancak, bazı durumlarda daha ince ayrıntılı erişim yönetimi sağlamak veya yüzlerce rol atanmasını yönetimini basitleştirmek isteyebilirsiniz.

Azure ABAC (özellik tabanlı erişim kontrolü), belirli eylemler bağlamında özelliklere dayalı rol atama koşulları ekleyerek Azure RBAC üzerine inşa edilmiştir. Bir rol atama koşulu, rol atamanıza ekleyebileceğiniz isteğe bağlı bir ek kontrol olup daha ince ayrıntılı erişim kontrolü sağlar. Bir koşul, rol tanımı ve rol ataması kapsamında verilen izinleri filtreler. Örneğin, bir nesneyi okumak için nesnenin belirli bir etikete sahip olmasını gerektiren bir koşul ekleyebilirsiniz.
Belirli kaynaklara koşullar kullanarak açıkça erişimi reddedemezsiniz.

Referanslar

• https://learn.microsoft.com/en-us/azure/governance/management-groups/overview
• https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions
• https://abouttmc.com/glossary/azure-subscription/#:~:text=An%20Azure%20subscription%20is%20a,the%20subscription%20it%20belongs%20to.
• https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#how-azure-rbac-determines-if-a-user-has-access-to-a-resource
• https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

• Abonelik planlarını kontrol edin!
• Katılın 💬 Discord group veya telegram group veya Twitter’da bizi takip edin 🐦 @hacktricks_live.
• PR göndererek hacking tricks paylaşın: HackTricks ve HackTricks Cloud github repos.