- Ya
- 4 Agosti 2026, 03:47 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 472ab30
God mode activated silently and lasted as long as the session. That is the control a covered entity's security review pushes hardest on, because "your staff can read our patient data" is always asked and an unjustified, unbounded elevation has no answer to it. - POST /api/security/session/god-mode now requires a typed justification to step UP. Stepping DOWN never does — a control that gates the safe action is a control that keeps operators elevated. - Both edges are recorded through PhiAccessRecorder with the justification and platformStaff(true). Identifiers only; the justification is the operator's own words about why, never anything they went on to read. - The window is 30 minutes and NON-SLIDING. The expiry is an absolute instant in the session body, not a TTL, so the sliding session refresh cannot extend it, and re-asserting from a second tab returns the original expiry rather than buying another window. - KSessionService.getSession masks an elapsed flag, so all ~10 existing `session.get("godModeActive")` gates honour the time-box without changing. GET /session/god-mode writes the clear through to Redis (doing it inside getSession would recurse) and is what the UI polls for the countdown. Deliberately fails OPEN on the audit write: god mode is how support fixes production, and refusing an elevation because phi_access_log blinked is worse than a row the recorder has already logged loudly. No entity or @Column changed. PhiResourceType gains no constant either — it is @Enumerated(STRING) with a CREATE TABLE value whitelist that ddl-auto:update never widens, so a new constant would fail every insert until KamoInitializer was run by hand. The elevation is recorded against the operator's own MEMBER record with a **************** prefix instead.