Hesapların ve alt kullanıcıların hiyerarşisi

(Bölüm: Operasyonlar ve Yönetim)

1) Görev ve ilkeler

Hesap hiyerarşisi, kuruluşların ve kişilerin platform kaynaklarına nasıl eriştiğini ve hakların, kotaların, bütçelerin ve sorumlulukların nasıl dağıtıldığını tanımlar.

• Endişelerin Ayrılması: İşletme ağacındaki işletmenin yapısını ve politikalardaki hakları yansıtırız.
• En Az Ayrıcalık: varsayılan - minimum roller, JIT aracılığıyla geçici promosyon.
• Düzenlenebilirlik: roller/kotalar/sınırlar miras alınır ve geçersiz kılınır.
• Kod Olarak Politika: erişim politikaları, kotalar, faturalandırma - sürümlenmiş eserler.
• Denetlenebilirlik - Her eylem bir konu, bağlam ve imza ile ilişkilendirilir.

2) Hiyerarşi referans modeli

Tenant
├─ Account - legally/operationally significant unit
│ ├─ Sub-account - Product/Region/Team/Project
│ │ ├─ Spaces/Projects/Environments: prod/stage/dev
│ │ └─ Roles and Groups (RBAC/ABAC) for People and Services
│ └─ Shares (limits, budgets, keys, integrations)
└─ Marketplace/Integrations/Affiliates (Outer Loops)

• Kiracı: sözleşmelerin sahibi, üst düzey faturalandırma, küresel politikalar ve SSO'lar.
• Hesap: izole edilmiş sorumluluk alanı (marka/ülke/şirket kodu); kendi bütçeleri/sınırları.
• Alt hesap: iş birimi (ürün/akış/komut); Anahtarlarınız, kotalarınız, rolleriniz ve denetiminiz.

3) Yetkilendirme modelleri

RBAC: роли Sahibi/Yönetici/Operatör/Görüntüleyici/Faturalandırma/Uyumluluk.
ABAC: 'Bölge', 'kiracı', 'hesap', 'çevre', 'risk _ skor', 'cihaz _ duruş' атрибуты.
ReBAC: Projeler ve sırlar için "sahip olma/katılma/inceleme" ilişkileri.

Uygulama: Hibrit - okunabilir bir temel olarak RBAC, bağlam kısıtlamaları için ABAC (bölge/zaman/cihaz), kaynak sahipliği için ReBAC.

4) Delegasyon ve miras

Delegasyon aşağı: Kiracı-yönetici, Hesap Yöneticisi rolünü verir, aynı - Alt hesap Bakıcısı.
Geçersiz kılmalar: Kotalar/sınırlar/politikalar ağaçta sıkılaştırılabilir.
Güven Sınırları: PII/Finans - yalnızca Hesap düzeyinde "güven bölgelerinde"; Alt hesap tokenleri/agregaları görür.
Break-glass: Kısa TTL, otomatik uyarı ve post-mortem ile acil erişim.

5) Kotalar, bütçeler, faturalandırma

Kotalar: istekler/sn, etkinlikler/gün, çıkış, depolama, tuşlar/webhook'lar.
Bütçeler: aylık sınırlar ve uyarılar (%80/90/100), otomatik kısma/süspansiyon.
Faturalandırma: Kiracı/Hesap düzeyinde faturalar; Alt hesap ve maliyet merkezleri bölümleri.
Transfer Fiyatlandırması: BUs/bölgeler arasındaki dahili ücretler.
Adil kullanım: kamu sınırları, oran sınırları, "patlamalara" karşı koruma.

6) Kimlikler ve SSO/SCIM

SSO (SAML/OIDC): Kiracı düzeyinde merkezi giriş.
SCIM: Kullanıcıların/grupların otomatik olarak oluşturulması/devre dışı bırakılması ve rollere bağlanması.
JML (Joiner/Mover/Leaver): Başlangıç rollerinin otomatik olarak verilmesi, çeviri sırasında revizyon, işten çıkarıldıktan sonra anında geri çağırma.
MFA/FIDO2: Yöneticiler, finans ve PII'ye erişim için zorunludur.
Aygıt Duruşu: aygıt durum toleransı (şifreleme, EDR).

7) Servis hesapları ve anahtarları

Alt Hesap + Çevre başına Hizmet Hesabı, paylaşılan sır yok.
İş Yükü Kimliği: Kısa ömürlü belirteçler, alt/fonksiyona bağlanır.
KMS/Vault: gizli rotasyon, rol erişimi, DSSE imzaları.
Webhooks: HMAC/EdDSA imzaları, 'nonce + timestamp', TTL penceresi.

8) Veri modeli (basitleştirilmiş)

'tenant' '{id, name, sso, billing_profile, policies []}'

'hesap' {id, tenant_id, bölge, legal_entity, kotalar {}, bütçeler {}, risk_tier}'

'sub _ account' '{id, account_id, ürün, çevre, anahtarlar [], webhooks [], limits {}}'

'role' {id, scope: tenant 'account' sub _ account, permissions []} '

'üyelik' '{subject _ id, role_id, scope_ref, tl, gerekçe}'

'politika' {type: rbac 'abac' sod 'quota, version, rules, signature}'

'audit _ event' '{kim, ne, nerede, ne zaman, trace_id, imza}'

'quota _ usage' '{scope _ ref, metric, window, used, cap}'

9) API Sözleşmeleri

• 'POST/tenants/{ id }/accounts' - Hesap oluştur (politikalar/kotalar/faturalandırma).
• 'POST/accounts/{ id }/sub-accounts' - bir Alt hesap oluşturun (anahtarlar, webhooks).
• 'PUT/roles/{ id}' - rol politikası; ' POST/members '- bir rol atayın.
• 'POST/access/elevate' - TTL ve gerekçe ile JIT artışı.
• 'GET/kotalar/kullanım' - kullanım/cap; ' POST/kotalar/geçersiz kılma '.

• 'GET/audit/events? kapsam =... '- imzalı günlükler.
• 'GET/status/access' - oyunculuk rolleri/TTL/anahtarlar.
• Вебхуки: 'CotaCapReached', 'RoleExpiring', 'KeyRotationDue', 'PolicyChanged'.

10) RACI (kilit alanlar)

11) Metrikler ve SLO

TTG (Time-to-Grant): 4 saat ≤ medyan standart erişim sorunu

JIT Kapsamı: Ayrıcalıklı işlemlerin %80'ini geçici roller aracılığıyla ≥.
SoD İhlalleri: 0 в prod; Eliminasyon TTR ≤ 24 saat.
Orphaned Access: "Unutulmuş" hakların paylaşımı ≤ 0. 1%.
Kota Doğruluğu: Tahakkukların/kullanım ≥ eşleştirme 99. 99%.
Denetim Bütünlüğü: %100 kritik imza/makbuz etkinliği.

12) Panolar

Erişim Sağlığı: seviyeye göre aktif roller, süresi dolan TTL, SoD ihlalleri.
FinOps: kota kullanımı, bütçe tahmini, çıkış/hesaplama anomalileri.
Güvenlik: anahtar rotasyon, MFA/SSO arızaları, kohort risk oranı.
Uyumluluk: yeniden sertifikalandırma durumu, denetim günlükleri, politika ihlalleri.
İşlemler: MTTR erişim istekleri, yeni komutlar için TTFI.

13) Veri sınırlaması ve gizlilik

Veri Etki Alanları: PII/Finans - Yalnızca hesap seviyesi; Alt hesap - kümeler/belirteçler.
Bölgesellik: Verilerin ve anahtarların bölge başına yerelleştirilmesi (güven bölgeleri).
PII istekleri: yalnızca onaylanmış jablar aracılığıyla; tokenization ve maskeleme.

14) Riskler ve anti-kalıplar

Düz model: tüm - "admins" olaylar ve sızıntılar.
Paylaşılan sırlar: izlenemezlik ve incelemelerin imkansızlığı.
SoD yok: Bir kişi ödemeleri/limitleri oluşturur ve onaylar.
Yerleştirilmemiş ortamlar: prod'daki dev tuşları; Test ve gerçek verileri karıştırma.
"Sonsuz" roller: TTL/yeniden sertifikalandırma yok - risk birikimi.
Zayıf kotalar: Bir alt hesap herkesin kapasitesini "yiyor".

15) Olay oyun kitapları

Alt hesap anahtarının bozulması: derhal iptal, bağımlılıkların döndürülmesi, kotaların yeniden hesaplanması, son 7-30 günün denetimi.
Kotaların aşılması: otomatik kısma/duraklatma, mal sahibinin bildirimi, geçici bütçe sınırı.
SoD'nin ihlali: Operasyonun engellenmesi, rolün geçici olarak kaldırılması, politikanın araştırılması ve düzeltilmesi.
Webhook'ların ikamesi: imza olmadan/TTL dışında alım yasağı, yeniden anahtar, durum-uç nokta mutabakatı.

16) Onboarding ve yaşam döngüsü

1. Kiracı başlatma: SSO/SCIM, fatura profili, global politikalar.

2. Hesap Oluşturma - Bölgeler, Kotalar, Bütçeler, Veri Bölgeleri, Temel Roller

3. Alt hesap: anahtarlar/webhook'lar, takım rolleri, entegrasyonlar.
4. JML/Yeniden Sertifikalandırma: hakların üç ayda bir gözden geçirilmesi, "uyuyanların" otomatik olarak kaldırılması.
5. EOL: arşiv, anahtar geri çağırma, mülkiyet transferi, fatura kapatma.

17) Uygulama kontrol listesi

• Uzlaştırıcı Kiracı> Hesap> Alt hesap ağacı ve miras kuralları.
• Rolleri (RBAC) ve bağlam politikalarını (ABAC), SoD matrisini tanımlayın.
• SSO/SCIM, JML süreçleri ve JIT güçlendirmeleri başlatın.
• Kota/bütçe/sınır kurallarını girin ve uyarın.
• KMS/Vault, rotasyonlar ve paylaşılan sırları dağıtın.
• Kod olarak ilkeleri, imzalı sürümleri ve WORM günlüklerini ekleyin.
• Yönetim API'lerini/webhook'larını, durum uç noktalarını ve denetimi yapılandırın.
• Erişim/FinOps/Güvenlik/Uyumluluk panoları oluşturun.
• Davranış GameDay: anahtar sızıntısı, kota fırtına, IdP hatası, SoD ihlali.
• Rolleri düzenli olarak yeniden sertifikalandırın ve sınırları gözden geçirin.

18) SSS

Hesap ve Alt Hesap arasındaki sınır nerede tutulur?
Finans/uyumluluk/düzenleme (Hesap) değiştiğinde ve Alt hesap - ekip/ürün/çevre hakkında.

Birkaç Alt hesabın kotalarını "yapıştırmak" mümkün mü?
Evet, havuzlar ve öncelikler aracılığıyla, ancak kapasite "yanık" sigortaları ile.

Geçici erişim nasıl hızlı bir şekilde verilir?
Ayrıcalıklı oturumlar için MFA ve TTL ile JIT uygulaması, otologasyon ve post-mortem.

Çarşamba günleri farklı anahtarlara ihtiyacım var mı?
Gerekli: Ağların ve hakların izolasyonu ile dev/stage/prod için ayrı Servis Hesapları/anahtarları.

Özet: Hesapların ve alt kullanıcıların hiyerarşisi yönetilebilirliğin bir çerçevesidir: varlıkların okunabilir bir yapısı, miras alınan politikalar, katı kotalar ve faturalandırma, güvenli kimlikler ve kanıtlanabilir denetim. RBAC/ABAC/ReBAC, JIT/SoD ve policy-as-code hibridini uygulayarak, ürün, ekip ve bölgeye göre ölçeklendirildiğinde hızlı giriş, öngörülebilir maliyetler ve sürdürülebilir güvenlik kazanacaksınız.