- Spegnimento
- 4 agosto 2026 alle ore 04:19 UTC
- Autore
- Kamo
- Impegno
- 1c590de
phi access log ha accumulato prove che nessuno guarda. Questo soddisfa §164.312(b) — il sentiero esiste — e non soddisfa nulla circa §164.308(a)(1)(iii)(D), che chiede la revisione, o §164.400-414, il cui orologio non può iniziare finché qualcuno non se ne accorge. Questa è la cosa che nota. Cinque rivelatori nell'ora chiusa, per attore: BULK EXPORT 250 documenti distinti esportati/downloaded/dischiusi MASS READ 200 record distinti letti REPEATED DENIALS 10 tentativi rifiutati (eventi — un rifiuto no record) UFFICIO 20 record distinti al di fuori della settimana del TENANT PLATFORM STAFF ACCESS 1 — un'entità coperta è detto indipendentemente dalla giustificazione I conti sono record DISTINCT, non eventi: PhiAccessAuditor emette una riga LIST per riga di rete, quindi un membro ricaricare la stessa pagina quaranta volte è 2.000 eventi e 50 individui — e "come molti individui" è il numero di una violazione la valutazione è fatta di. Rationale per ogni default è su PhiDetectionSettings; tutti sono configurabili, perché un rivelatore che spara costantemente viene disattivato e un rilevatore muto legge ancora come copertura. L'orario di apertura è valutato nella zona dell'inquilino tramite il suo OFF HOURS ACCESS esistente regola (ore di affari la schermata di sicurezza già raccoglie) cadendo indietro a Organizzazione.timezone. si è verificato at è UTC, quindi un controllo associato UTC sarebbe pagina un inquilino di Sydney ogni mattina di lavoro e non ha mai fatto una pagina a New York. Riutilizza la consegna ciò che esiste: EmailTemplateServiceClient -> EmailService /api/email/templates/send con la nuova chiave canonica PHI ACCESS ALERT, alla indirizza l'org già registrato in org suspicious detection rules .notification emails. Un inquilino che non ha configurato nessuno ottiene il registro di revisione e nient'altro — spedire un indirizzo indovinato rivelerebbe che un nome il membro della forza lavoro è sospettato. Ogni risultato è collegato a un dedicato PHI-DETECTION logger; solo la notifica viene accelerata (6h per rilevatore/tenant/ attore, nel Redis le regole login-anomaly già utilizzare). Porta avvisi identificatori e conti, mai un record. Due scelte strutturali deliberate: - Gli aggregati attraversano un EntityManager, non Spring Data @Query. Primavera I dati convalidano una query dichiarata creandola a repository bootstrap, quindi un errore là fallisce l'avvio del contesto — e un SecurityService che non start prende ogni login con esso, come il 2026-08-03. Qui il caso peggiore è un spazzare i registri e le ripetizioni l'ora prossima. Rimuove anche questo pacchetto dal @EnableJpaRepositories domanda del tutto: nessun fagiolo del repository, nulla Dimentica. PhiDetectionQueryTest controlla ogni percorso di proprietà riflettente da allora nessun test in questo servizio può avviare un contesto. - Ogni query è ostacolata dall'organizzazione. solo phi access log indice utilizzabile è (ORGANIZATION ID, OCCURRED AT); filtraggio in tempo da solo full-scans un solo tavolo che cresce sempre. Scheduling: questo unisce compitoScheduler (4 fili, sched-), che sette spazza già condividere. Non tocca traduzioneEsecutore — il 3-thread/500-queue @Async piscina osservata saturato — e si presenta a nessun esecutore affatto. Orecchio, 5 aggregati raggruppati per lotto di inquilino, nessuna rete I/O all'interno della scansione, e un latch reentrancy in modo da una corsa lenta salta la prossima zecca piuttosto che impilare dietro di esso e starving la piscina che condivide. Nessuna entità o colonna è stata aggiunta o modificata.