Hierarchia rachunków i podwykonawców

(Sekcja: Operacje i zarządzanie)

1) Zadania i zasady

Hierarchia kont określa, w jaki sposób organizacje i ludzie uzyskują dostęp do zasobów platformy oraz w jaki sposób rozdzielane są prawa, kwoty, budżety i obowiązki.

• Oddzielenie obaw: odzwierciedlamy strukturę działalności w drzewie podmiotu oraz prawa w polityce.
• Najmniejszy przywilej: domyślny - minimalne role, tymczasowa promocja za pośrednictwem JIT.
• Kompozycyjność: role/kwoty/limity są dziedziczone i nadrzędne.
• Policy-as-Code: polityka dostępu, kwoty, rozliczenia - artefakty wersjonowane.
• Audytability - Każde działanie jest skorelowane z tematem, kontekstem i podpisem.

2) Model referencyjny hierarchii

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)

• Najemca: właściciel kontraktów, rachunków wysokiego szczebla, globalnych polityk i systemów SSO.
• Konto: odizolowany obszar odpowiedzialności (kod marki/kraju/przedsiębiorstwa); własne budżety/limity.
• Subkonta: jednostka robocza (produkt/strumień/polecenie); Twoje klucze, kwoty, role i audyt.

3) Modele autoryzacji

RBAC: рола Owner/Admin/Operator/Viewer/Billing/Compliance.
ABAC: атрита „region”, „najemca”, „rachunek”, „środowisko”, „risk _ score”, „device _ posture”.
ReBAC: „posiada/uczestniczy/ocenia” relacje dla projektów i tajemnic.

Praktyka: hybryda - RBAC jako podstawa do odczytu, ABAC dla ograniczeń kontekstowych (region/czas/urządzenie), ReBAC dla własności zasobów.

4) Przekazanie uprawnień i dziedziczenie

Delegacja w dół: Najemca-administrator daje rola Administrator konta, to samo - Opiekun subkont.
Przekroczenia: Kwoty/limity/zasady mogą zostać zaostrzone w dół drzewa.
Granice powiernicze: PII/Finance - tylko w „strefach powierniczych” na poziomie rachunku; Subkont widzi żetony/agregaty.
Break-glass: dostęp awaryjny z krótkim TTL, auto-alert i pośmiertnie.

5) Kwoty, budżety, rozliczenia

Kwoty: żądania/sek, wydarzenia/dzień, wyjście, przechowywanie, klucze/haki webowe.
Budżety: miesięczne czapki i wpisy (80/90/100%), auto-throttling/zawieszenie.
Faktury: faktury na poziomie najemcy/konta; Sekcje subkont i centrów kosztów.
Ceny transferowe: opłaty wewnętrzne między przedsiębiorstwami/regionami.
Uczciwe użytkowanie: ograniczenia publiczne, limity stawek, ochrona przed wybuchami.

6) Tożsamości i SSO/SCIM

SSO (SAML/OIDC): scentralizowane wejście na poziomie lokatora.
SCIM: automatyczne tworzenie/dezaktywowanie użytkowników/grup i wiązanie z rolami.
JML (Joiner/Mover/Leaver): automatyczna emisja ról startowych, rewizja podczas tłumaczenia, natychmiastowe wycofanie po zwolnieniu.
MFA/FIDO2: obowiązkowe dla administratorów, finansów i dostępu do PII.
Postawa urządzenia: tolerancja stanu urządzenia (szyfrowanie, EDR).

7) Konta serwisowe i klucze

Konto usługi na Subkont + Środowisko, brak wspólnych tajemnic.
Identyfikacja obciążenia pracą: żetony krótkotrwałe, wiążące się z dnem/funkcją.
KMS/Vault: tajny obrót, dostęp do ról, podpisy DSSE.
Haki internetowe: podpisy HMAC/EdDSA, „nonce + timestamp”, okno TTL.

8) Model danych (uproszczony)

"najemca" {id, name, sso, billing_profile, policies []} "

{id, tenant_id, region, legal_entity, kwoty {}, budżety {}, risk_tier}'

„sub _ account” „{id, account_id, produkt, środowisko, klucze [], haki internetowe [], limity {}}”

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

„uzasadnienie” „{subject _ id, role_id, scope_ref, ttl, justification}”

„policy” „{typ: rbac 'abac' sod 'quota, wersja, zasady, podpis}”

„audit _ event” „{who, what, where, when, trace_id, signature}”

„quota _ use” „{scope _ ref, metric, window, used, cap}”

9) Umowy API

• „POST/najemcy/{ id }/accounts” - utwórz konto (zasady/kwoty/rozliczenia).
• "POST/accounts/{ id }/subkont' - utwórz subkont (klucze, haki internetowe).
• "PUT/roles/{ id}" - polityka roli; " POST/members "- przypisać rolę.
• „POST/access/elevate” - zwiększenie JIT z TTL i uzasadnienie.
• "GET/kwoty/wykorzystanie" - wykorzystanie/pułap; " PO/kwoty/nadwyżka ".

• "GET/audyt/wydarzenia? zakres =... "- podpisane dzienniki.
• „GET/status/access” - role aktorskie/TTL/keys.
• Веска: „ CapReached”, „wygasający”, „rotacyjny”, „odmieniony”.

10) RACI (obszary kluczowe)

11) Metryka i SLO

TTG (Time-to-Grant): mediana standardowego problemu dostępu ≤ 4 godziny

JIT Coverage: ≥ 80% transakcji uprzywilejowanych poprzez role tymczasowe.
SoD Violates: 0 морова; Eliminacja TTR ≤ 24 h.
Dostęp osierocony: udział praw „zapomnianych” ≤ 0. 1%.
Dokładność kwot: suma rozliczeń międzyokresowych/wykorzystanie ≥ 99. 99%.
Kompletność audytu: 100% krytyczna aktywność podpisu/odbioru.

12) Deski rozdzielcze

Dostęp Zdrowie: aktywne role według poziomu, wygasające TTL, naruszenia SoD.
FinOps: wykorzystanie kwot, prognoza budżetowa, anomalie typu egress/compute.
Bezpieczeństwo: rotacja klucza, awarie MFA/SSO, wskaźnik ryzyka kohort.
Zgodność: status ponownej certyfikacji, dzienniki audytu, naruszenia zasad.
Operacje: żądania dostępu MTTR, TTFI dla nowych poleceń.

13) Rozgraniczenie danych i prywatność

Domeny danych: PII/Finance - tylko poziom konta; Subkonta - kruszywa/żetony.
Regionalność: lokalizacja danych i kluczy na region (strefy zaufania).
Wnioski PII: wyłącznie za pośrednictwem zatwierdzonych jabs; tokenizacja i maskowanie.

14) Zagrożenia i działania zapobiegawcze

Płaski model: wszystkie - „admins →” incydenty i przecieki.
Wspólne tajemnice: niewykrywalność i niemożność przeprowadzania recenzji.
Brak SoD: Jedna osoba tworzy i zatwierdza płatności/limity.
Środowiska niepakowane: klucze dev w prod; test mieszania i rzeczywiste dane.
„Nieskończone” role: brak TTL/rekertyfikacja → kumulacja ryzyka.
Słabe kwoty: jeden subkontynent „zjada” zdolność każdego.

15) Playbooks incydentu

Kompromis klucza subkont: natychmiastowe odwołanie, rotacja zależności, ponowne obliczenie kwot, audyt ostatnich 7-30 dni.
Przekroczenie kwot: automatyczne ograniczanie/pauzowanie, powiadomienie właściciela, tymczasowy limit budżetowy.
Naruszenie SoD: blokowanie operacji, czasowe usunięcie roli, zbadanie i ustalenie polityki.
Zastąpienie haków internetowych: zakaz odbioru bez podpisu/poza TTL, ponowny klucz, pojednanie z punktem końcowym.

16) Wsiadanie na pokład i cykl życia

1. Inicjalizacja najemcy: SSO/SCIM, profil rozliczeniowy, polityka globalna.

2. Utwórz konto - regiony, kwoty, budżety, strefy danych, role bazowe

3. Subkont: klucze/haki internetowe, role zespołu, integracje.
4. JML/Recertyfikacja: kwartalny przegląd praw, automatyczne usuwanie „podkładów”.
5. EOL: archiwum, odzyskiwanie kluczy, przeniesienie własności, zamknięcie rozliczeń.

17) Lista kontrolna wdrażania

• Reconcile Najemca → Konto → Zasady subkont drzewa i dziedziczenia.
• Opisz role (RBAC) i polityki kontekstowe (ABAC), matryca SoD.
• Uruchom SSO/SCIM, procesy JML i zwiększa JIT.
• Wprowadź kwoty/budżety/zasady pułapu i wpisz.
• Wdrożyć KMS/Skarbiec, rotacje, i wspólne tajemnice.
• Zawierać polityki jako kod, podpisane wydania i dzienniki WORM.
• Konfiguruj interfejsy zarządzania API/haki internetowe, punkty końcowe stanu i audyt.
• Budować dostęp/FinOps/Bezpieczeństwo/Zgodność deski rozdzielcze.
• Conduct GameDay: key leak, quota storm, IdP failure, SoD violation.
• Regularne weryfikowanie ról i przeglądy limitów.

18) FAQ

Gdzie zachować granicę między kontem a subkontem?
W przypadku zmiany finansów/zgodności/regulacji (rachunków) oraz subkonta - o zespole/produkcie/środowisku.

Czy możliwe jest „klejenie” kwot kilku subkont?
Tak, przez baseny i priorytety, ale z pojemnością „wypalić” bezpieczniki.

Jak szybko wydać tymczasowy dostęp?
Aplikacja JIT z MFA i TTL, autologia i pośmiertnie dla uprzywilejowanych sesji.

Czy w środy potrzebuję różnych kluczy?
Wymagane: oddzielne konta serwisowe/klucze dla dev/stage/prod z izolacją sieci i praw.

Podsumowanie: hierarchia rachunków i podwykonawców stanowi ramy możliwości zarządzania: czytelna struktura podmiotów, odziedziczona polityka, rygorystyczne kwoty i rozliczenia, bezpieczne tożsamości i wiarygodne audyty. Wdrażając RBAC/ABAC/ReBAC, JIT/SoD i hybrydę policy-as-code, zyskasz szybkie wejście na pokład, przewidywalne koszty i zrównoważone bezpieczeństwo po skalowaniu przez produkt, zespół i region.