Flaga Superuser (is_superuser)

Flaga Superuser (is_superuser) jest najwyższym poziomem uprawnienia administracyjnego w architekturze platformy Ammonly. Zapewnia bezwarunkowy dostęp do wszystkich modułów, zasobów, konfiguracji systemowych oraz danych poufnych.

Uprawnienie krytyczne

Uprawnienie Superuser powinno być nadawane z najwyższą rozwagą wyłącznie zaufanym administratorom infrastruktury. Użytkownik z tą flagą omija wszelkie ograniczenia profilowe i polityki widoczności rekordów.

---

Spis treści

• 1. Rola i zakres uprawnień Superusera
• 2. Przegląd uprawnień specjalnych
• 3. Architektura weryfikacji w PermissionGuard
• 4. Wyłączność zarządzania Dostępem specjalnym
• 5. Bezpieczeństwo i audytowalność operacji

---

1. Rola i zakres uprawnień Superusera

W przeciwieństwie do standardowych profili ról (a_mod_profiles_records), które precyzyjnie definiują dostęp per moduł i per pole, flaga is_superuser = 1 w tabeli użytkowników a_mod_users_records działa na poziomie jądra aplikacji (App\Core\Engine):

flowchart TD
    Req[Żądanie Użytkownika] --> Guard[PermissionGuard]
    Guard --> Check{is_superuser == 1?}
    Check -->|TAK| Allow[Pełny Dostęp do Zasobu i Akcji]
    Check -->|NIE| Eval[Weryfikacja Profili, Modułów i Właściciela]
    Eval --> Result{Uprawniony?}
    Result -->|TAK| Allow
    Result -->|NIE| Deny[403 PermissionDeniedException]

---

2. Przegląd uprawnień specjalnych

Użytkownik z aktywną flagą Superuser posiada następujące uprawnienia nadrzędne:

1. Dostęp do rekordów Ukrytych (special_access = 0):
   • Jako jedyny widzi i może zarządzać rekordami oznaczonymi jako ukryte (SpecialAccess::HIDDEN).
   • Standardowi użytkownicy nie mają możliwości wykrycia istnienia takich rekordów.
2. Wyłączność na zmianę poziomu Dostępu specjalnego:
   • Zmiana wartości w polu special_access (przenoszenie do archiwum, usuwanie miękkie, ukrywanie, przywracanie) jest dozwolona wyłącznie dla superusera.
3. Pominięcie zakresu właścicielskiego (Owner Scope):
   • Superuser widzi i może edytować wszystkie rekordy we wszystkich modułach, niezależnie od tego, kto jest właścicielem (owner) lub współwłaścicielem (co_owners).
4. Pominięcie reguł modułów prywatnych:
   • Bezpośredni dostęp do modułów oznaczonych jako PRIVATE lub wymagających podwyższonych ról.
5. Dostęp do konfiguracji silnika:
   • Zarządzanie metadanymi modułów (system_modules), definicjami pól (system_fields), słownikami (system_picklists), profilami uprawnień (system_profiles) oraz zadaniami CRON (system_cron).

---

3. Architektura weryfikacji w PermissionGuard

Silnik autoryzacji w klasie App\Core\Engine\Application\Security\PermissionGuard realizuje weryfikację według rygorystycznego protokołu:

// Weryfikacja uprawnień do odczytu modułu
public function assertReadAccess(ModuleMetadata $module, PermissionContext $context): void
{
    if (!$context->isAuthenticated()) {
        throw PermissionDeniedException::superuserRequired($module->name);
    }

    // Superuser natychmiast uzyskuje autoryzację
    if ($context->isSuperuser) {
        return;
    }

    // Pozostali użytkownicy podlegają weryfikacji profilu i reguł modułu
    // ...
}

Podobnie w assertWriteAccess(), obecność flagi $context->isSuperuser pozwala na ominięcie blokad zapisu narzuconych przez reguły współdzielenia i uprawnienia polowe.

---

4. Wyłączność zarządzania Dostępem specjalnym

W kontekście pola Dostęp specjalny superuser posiada wyłączne prawa:

Operacja	Użytkownik Standardowy	Superuser
Odczyt rekordów Widocznych (1)	Zgodnie z uprawnieniami	Pełny dostęp
Odczyt rekordów Zarchiwizowanych (2) / Kosz (3)	Tylko własne / współwłasność	Pełny dostęp
Odczyt rekordów Ukrytych (0)	Brak dostępu (403)	Pełny dostęp
Zmiana wartości pola special_access	Zablokowane (Pole disabled / strip payload)	Dozwolone
Zmiana statusu biznesowego status	Zgodnie z profilem	Pełny dostęp

---

5. Bezpieczeństwo i audytowalność operacji

Wszystkie operacje wykonywane przez superuserów są rygorystycznie rejestrowane w dziennikach audytowych:

• Dziennik odczytów: a_logs_audit_read_records
• Dziennik zmian: a_logs_audit_update_records (ze szczegółowym diffem przed i po zmianie)
• Dziennik usunięć: a_logs_audit_delete_records
• Dziennik logowania i sesji: a_logs_user_auth_records

Dodatkowo, użytkownik nie może odebrać uprawnień superusera samemu sobie, jeżeli w systemie nie ma przynajmniej jednego innego aktywnego superusera.