Tożsamości, konta i sekrety¶
Podmioty¶
NORBI rozróżnia człowieka, urządzenie, usługę, workera, agenta, providera i narzędzie. Nazwa wyświetlana nie jest tożsamością. Każdy principal ma stabilne ID, status, metody uwierzytelnienia, role i przypisania capability. Agent i provider są odrębnymi principalami od workera, który faktycznie uruchamia adapter.
Karta modułu Identity & Accounts¶
| Pole | Kontrakt |
|---|---|
| Odpowiedzialności | enrollment, auth, sessions, roles, capabilities, account metadata, credential handles, revoke/rotation. |
| Wejścia | identity proof, device posture, role assignment, account consent, requested action/destination. |
| Wyjścia | authenticated principal, scoped session, capability facts, credential handle, audit record. |
| Zależności | OS identity, local IdP/passkeys, secure vault, Policy, Approval, device registry. |
| Uprawnienia | admin role i capability assignment oddzielone; model nie ma endpointów modyfikacji. |
| Autonomia | automatyczne expiry/revoke po incydencie; enrollment i poszerzenie scope wymagają człowieka. |
| Walidacja | MFA/passkey, session binding, least privilege, periodic access review, no-secret leakage. |
| Awaria | break-glass offline credentials, recovery codes poza systemem AI, revoke sessions i read-only. |
Uwierzytelnienie człowieka¶
Preferowane są passkeys/WebAuthn, uwierzytelnienie systemu operacyjnego oraz MFA dla zdalnego Control Plane. Sesja ma urządzenie, IP/overlay identity, czas, risk context i expiry. Approval wysokiego ryzyka może wymagać step-up auth. Telefon może zatwierdzać tylko w uwierzytelnionej aplikacji/PWA i zgodnie z klasą; krytyczna promocja lub recovery może wymagać lokalnego Approval Center.
Role opisują obowiązki, a capability zakres wykonania. Administrator UI nie musi mieć publish_external; operator renderu nie ma dostępu do HR. Capability assignment zapisuje kto, dlaczego, na jaki okres i z jakim scope. Puste scope oznacza brak uprawnienia, nie globalny dostęp.
Accounts Registry¶
Rekord konta zawiera platformę, etykietę, typ, ownera, dozwolone tools/actions/destinations/data classes, consent, auth method, credential handle, verified/rotated/expiry i status. Nie zawiera hasła, tokenu, cookies, private key ani recovery code.
Rozdzielone scopes: read, draft, upload, send, publish, delete, admin. Przykładowo agent może czytać publiczną skrzynkę i tworzyć drafty, lecz send wymaga innego capability. Revoke konta unieważnia pending jobs, approvals i sessions związane z account ID.
Credential Broker¶
- Adapter prosi o account ID, exact action i destination.
- Capability Engine sprawdza principal/tool/account/action/destination.
- Approval Broker sprawdza właściwą decyzję.
- Credential Broker tworzy process-scoped handle albo brokered session.
- Adapter używa go bez możliwości odczytania surowej wartości, o ile platforma na to pozwala.
- Handle wygasa lub jest revoke po zakończeniu.
Sekret nie trafia do promptu, logu, approvala, artifactu ani błędu. Redakcja usuwa nagłówki, tokeny w query, cookies i body zawierające credentials. External AI nie otrzymuje credential handles, ponieważ nie jest adapterem wykonawczym.
Worker enrollment¶
Nowy worker zaczyna jako pending. Operator weryfikuje urządzenie, system, secure boot/patch level zależnie od klasy, certyfikat i deklarowane adapters. Worker ma device identity i krótkotrwałe certyfikaty. Advertisement nie poszerza roli. Utracony lub podejrzany worker jest draining/suspended/revoked, a leases i handles są unieważniane.
Przykładowe polecenia¶
- „Pokaż, które narzędzia mogą użyć konta sprzedażowego do wysyłki.”
- „Unieważnij sesje utraconego telefonu i usuń jego lokalny cache przy następnym kontakcie.”
- „Zarejestruj worker jako pending i przygotuj raport posture, ale go nie aktywuj.”
- „Obniż zakres konta serwisowego do odczytu; nie zmieniaj innych kont.”
Walidacja i ryzyka¶
Testy obejmują session fixation, CSRF, replay, token expiry, revoked account podczas lease, pomyłkę tenant/project, log redaction, exception trace, clipboard i memory dump exposure tam, gdzie możliwe. Access review wskazuje nieużywane i szerokie przypisania. Sekret testowy ma sentinel i nie może pojawić się w żadnym output; skan źródeł nie jest dowodem ochrony runtime.
Scenariusz awaryjny¶
Po podejrzeniu kompromitacji: revoke principal, sessions, account handles, grants i worker leases; zatrzymanie komunikacji; rotacja po stronie sejfu/platformy; analiza receiptów; ograniczenie systemu do read-only. Break-glass dane są przechowywane offline poza zasięgiem modeli i normalnych usług. Użycie break-glass jest fizycznie/lokalnie kontrolowane, audytowane po przywróceniu i nie tworzy trwałego wyjątku polityki.