Role i uprawnienia w Open Mercato: przewodnik ładu dostępu

Osiemnaście pojęć ładu dostępu

Przed użyciem nazwij principal, zakres, właściciela decyzji, dowód i wykluczone znaczenia.

• 1. identity
• 2. authentication
• 3. authorization
• 4. role
• 5. feature
• 6. wildcard grant
• 7. Role ACL
• 8. User ACL override
• 9. effective access
• 10. tenant scope
• 11. organization scope
• 12. delegation boundary
• 13. superadmin or break-glass access
• 14. machine identity
• 15. joiner, mover, leaver lifecycle
• 16. segregation of duties
• 17. access review
• 18. acceptance evidence

Model rozumowania o efektywnym dostępie

Użyj tego modelu do prześledzenia etapów. Nie pokazuje on, że każda bieżąca trasa wykonuje wszystkie etapy w jednakowy sposób.

Zapisz bieżący mechanizm, możliwą lukę, dowód odbioru, odpowiedzialnego właściciela oraz stan natywny, konfigurowalny, własny, integracyjny lub wdrożeniowy.

1. 1

   principal

2. 2

   authenticated context

3. 3

   tenant

4. 4

   organization

5. 5

   global superadmin check

6. 6

   User ACL if present, otherwise assigned roles

7. 7

   role ACL aggregation

8. 8

   enabled-module filter

9. 9

   wildcard match

10. 10

    all required route features

11. 11

    route and domain scope guard

12. 12

    data query

13. 13

    allow or deny

Agregacja ról i pierwszeństwo wyjątku użytkownika

Bez User ACL bieżący kod łączy unikalne uprawnienia ról, status superadmin i zakres organizacji. Jedna rola bez ograniczenia może rozszerzyć cały wynik. Gdy istnieje User ACL, bieżący loadAcl używa wyłącznie jego uprawnień, organizacji i flagi superadmin. Granty ról są pomijane. Dokumentacja zawiera język addytywny, dlatego ten konflikt należy ponownie sprawdzić przy aktualizacji.

Bieżąca trasa User ACL usuwa rekord, gdy nie pozostaje żadne efektywne uprawnienie ani superadmin, więc wyjątek ograniczony do organizacji nie jest tam utrwalany. Wysłana lista uprawnień zastępuje zapisaną listę.

Porównaj rolę wielokrotnego użytku z rzadkim, sprawdzanym i ograniczonym w czasie wyjątkiem zastępującym. Zapisz zachowane i celowo utracone granty roli.

• reuse
• clarity
• exceptions
• review cost
• drift risk
• revocation
• organization reach
• debugging
• recommended use

Uprawnienie i izolacja danych to osobne kontrole

Oddziel uprawnienie funkcjonalne, kontekst tenantu, ACL organizacji, wybraną organizację, helper zakresu trasy, regułę własności domenowej i rzeczywisty filtr zapytania. Bieżący TC-AUTH-049 pokazuje wąski wyjątek: lista organizacji roli jest zapisana, lecz testowana lista organizacji directory pozostaje w zakresie tenantu. Ten test nie pokazuje, jak każda inna trasa obsługuje tę listę.

Listy wymaganych uprawnień trasy są zwykle warunkiem all-of. Globalne i zgodne wildcardy modułu upraszczają administrację, lecz rozszerzają ryzyko przyszłych funkcji; wildcard jednego modułu nie nadaje drugiego. Znaczenie ma też filtr aktywnych modułów. Ukryta nawigacja wpływa na UX. Nie zapewnia autoryzacji serwera.

Nazwij feature, sprawdzenie tenantu, filtr organizacji lub danych, własność celu, przypadki allow i deny, wyjątek uprzywilejowany, dowód i właściciela.

• 1. page navigation
• 2. API list
• 3. API item
• 4. create
• 5. edit
• 6. delete
• 7. bulk action
• 8. import
• 9. export
• 10. search
• 11. report or dashboard
• 12. attachment
• 13. background job
• 14. scheduler
• 15. webhook
• 16. integration
• 17. portal
• 18. AI tool
• 19. support or admin tool
• 20. custom route

Sześć hipotetycznych archetypów ról

Zdefiniuj odpowiedzialność, dozwolone i zabronione rodziny działań, zakres danych, autorytet akceptacji, status człowieka lub maszyny, wrażliwe połączenia, przegląd, tryb awaryjny i dowód odbioru. To nie są role dostarczane jako domyślne.

Domyślne granty, aktualizacja i delegowanie

Setup może utworzyć superadmin, admin i employee, a aktywne moduły wnoszą defaultRoleFeatures, także dla własnych nazw ról. Historia setupu wpływa na wynik. auth sync-role-acls idempotentnie dodaje brakujące deklarowane granty; nie odbiera nadmiarowych ani starych uprawnień i nie uzgadnia polityki docelowej. Sprawdź źródło, zdecyduj role, wykonaj sync lub migrację, diff, testy pozytywne i negatywne, akceptację, dowód i kolejny przegląd.

Zapisz granicę grantów i organizacji aktora, chroniony cel i sprawdzenie tenantu, ryzyko resztkowe, zgodę, monitoring i warunek stop. Samo auth.acl.manage nie upoważnia do szerszego dostępu.

• 1. assign an existing low-risk role
• 2. edit exact grants
• 3. grant a module wildcard
• 4. grant unrestricted organization reach
• 5. grant ACL-management authority
• 6. grant tenant administration
• 7. grant global wildcard or superadmin

Dostęp uprzywilejowany, cykl życia i przegląd

Bieżący kod rozpoznaje globalne zachowanie superadmin. Traktuj je jako wyjątkowy dostęp break-glass: minimalna liczba osób, oddzielne tożsamości dzienne i administracyjne, silne uwierzytelnienie, kontrola poświadczeń, wybór zakresu, logi, alerty, przegląd, odwołanie, odzyskanie i brak kont wspólnych. Aktywacja czasowa pozostaje decyzją projektu, dopóki nie zostanie wdrożona i potwierdzona.

Zapisz trigger, wnioskodawcę, akceptującego, działanie na tożsamości, tenant i organizację, rolę, override, sesje, dowód, termin, wyjątek i recenzenta. Core ma create, update, password, session i transakcyjne sprzątanie przy delete, lecz nie ma ogólnego pola isActive. Nie wymyślaj kroku deactivate.

• joiner
• mover
• leaver

Pytania o rozdział obowiązków

• requester and approver
• order and credit or refund
• catalog and price approval
• import and reconciliation
• role design and role assignment
• key creation and key use
• audit review and audit administration
• deployment and production access
• project-specific conflicts

Przeglądaj użytkowników, przypisania ról, Role ACL, User ACL, zakres organizacji, superadminów, ACL managers, nieaktywne tożsamości, sesje, klucze, mapowania IdP, role portalu, delegowanie AI i własne guardy. Sprawdzony core nie zawiera uniwersalnego silnika SoD ani harmonogramu przeglądów.

Tożsamości techniczne i oddzielne domeny zaufania

Przypisz odpowiedzialną decyzję i dowód odbioru dla konkretnego poświadczenia technicznego.

• 1. owner
• 2. purpose
• 3. tenant
• 4. organization
• 5. roles
• 6. exact inherited features
• 7. creator
• 8. one-time secret custody
• 9. expiry
• 10. last use
• 11. rotation
• 12. revocation
• 13. incident response
• 14. cache invalidation
• 15. evidence
• 16. review trigger

Bieżące API keys przechowują hash sekretu i publiczny prefix wraz z tenantem, opcjonalną organizacją, rolami, twórcą, last use, opcjonalnym terminem i soft delete. Pełny sekret wraca przy utworzeniu; uwierzytelnienie odrzuca klucze usunięte lub wygasłe i rozwiązuje bieżący zakres, a usunięcie unieważnia odpowiednie cache. Tworzenie jest ograniczone grantami aktora. Bieżący kod nie określa domyślnych ograniczeń IP, integracji z vaultem, automatycznej rotacji, dual control, wykrywania anomalii ani oddzielenia service account. O tych kontrolach decyduje wdrożenie.

Zapisz provisioning, uwierzytelnienie, mapowanie uprawnień, zakres, odwołanie sesji lub klucza, dowód i właściciela granicy zaufania. Enterprise SSO, SCIM i MFA są opcjonalne oraz zależne od edycji i konfiguracji.

• staff auth
• customer portal
• API keys
• AI session keys
• enterprise SSO and SCIM
• enterprise MFA

Trzy syntetyczne scenariusze dostępu

Wczytaj strukturalny rekord, aby sprawdzić rozszerzenie, zastąpienie, ochronę sekretu, termin, dowody odmowy i odpowiedzialność.

Pakiet odbioru menedżera

Podaj setup, principal, tenant i organizację, operację, wymagane features, oczekiwany wynik i zakres danych, dowód, wynik zabroniony, wymuszoną awarię, sprzątanie, właściciela i kryterium pass.

• 1. no-role denial
• 2. single exact grant
• 3. all-of with one missing grant
• 4. module wildcard
• 5. global wildcard
• 6. disabled-module grant
• 7. multiple-role feature union
• 8. multiple-role organization widening
• 9. user override replacement
• 10. user override removal
• 11. organization-only override attempt
• 12. same-tenant assignment
• 13. cross-tenant denial
• 14. cross-organization data denial
• 15. protected superadmin target
• 16. bounded delegator
• 17. out-of-scope wildcard
• 18. unrestricted-organization escalation
• 19. stale ACL edit
• 20. cache invalidation
• 21. role deletion with users
• 22. joiner
• 23. mover
• 24. leaver and session revocation
• 25. API-key create
• 26. API-key use
• 27. API-key expiry
• 28. API-key revoke
• 29. API-key rotation
• 30. custom route
• 31. hidden navigation with server denial
• 32. background capability helper
• 33. SSO role mapping
• 34. SCIM deprovisioning
• 35. MFA and break-glass
• 36. portal separation
• 37. AI delegated key
• 38. upgrade sync
• 39. periodic access review

Zatrzymaj lub odłóż

• no accountable policy owner.
• unknown critical route guard.
• feature-only check with unproven data filter.
• cross-tenant denial not tested.
• cross-organization denial not tested.
• unexplained wildcard.
• user override without expiry or review.
• superadmin used for daily work.
• unbounded or unreviewed ACL manager.
• shared machine key.
• unknown secret custody.
• no leaver and session process.
• stale default grants after upgrade.
• unowned segregation conflict.
• optional SSO or MFA represented as active without proof.
• audit evidence too weak for the stated need.