- Verschifft
- 4. August 2026 um 04:19 UTC
- Autor
- Kamo
- Ausschuss
- 1c590de
phi_access_log hat Beweise gesammelt, die niemand anschaut. Das befriedigt Der Weg existiert und befriedigt nichts - 1644.308(a)(1)(ii)(D), der um Überprüfung bittet, oder -164.400-414, dessen Uhr kann nicht starten, bis jemand es bemerkt. Das ist die Sache, die bemerkt. Fünf Detektoren über die geschlossene Stunde, pro Schauspieler: BULK_EXPORT 250 eindeutige Datensätze exportiert/downloaded/offengelegt MASS_READ 200 verschiedene Datensätze gelesen REPEATED_DENIALS 10 abgelehnte Versuche (events - eine Ablehnung Namen keine Aufzeichnung) OFF_HOURS_ACCESS 20 eindeutige Datensätze außerhalb der TENANT-Woche PLATFORM_STAFF_ACCESS 1 - eine abgedeckte Einheit wird unabhängig von der Begründung informiert Zähler sind DISTINCT-Aufzeichnungen, nicht Ereignisse: PhiAccessAuditor sendet eine LIST-Reihe pro Gitterzeile, so dass ein Mitglied die gleiche Seite vierzig mal neu lädt, ist 2.000 Veranstaltungen und 50 Personen - und "wie viele Personen" ist die Zahl ein Verstoß Es wird bewertet. Rationale für jeden Standard ist auf PhiDetectionSettings; Alle von ihnen sind configmap-tunable, weil ein Detektor, der ständig feuert wird gedämpft und ein gedämpfter Detektor liest sich immer noch als Abdeckung. Off-Hours wird in der Mieterzone über seine bestehende OFF_HOURS_ACCESS beurteilt Regel (Geschäftszeiten der Sicherheits-Bildschirm bereits sammelt) fällt zurück zu Organisation.timezone. erfolgte_at ist UTC, so dass eine UTC-verankerte Überprüfung Seite würde ein Sydney Mieter jeden Arbeitsmorgen und nie Seite ein New Yorker. Zustellung verwendet, was existiert: EmailTemplateServiceClient -- EmailService /api/email/templates/send mit dem neuen PHI_ACCESS_ALERT canonical key, auf dem Adressen der org bereits in org_suspicious_detection_rules .notification_emails. Ein Mieter, der keine konfiguriert bekommt das Überprüfungsprotokoll und nichts anderes - Mailing eine vermutete Adresse würde offenbaren, dass ein benannt Die Belegschaft steht unter Verdacht. Jeder Befund wird bei einem dedizierten protokolliert PHI-DETECTION Logger; nur Benachrichtigung wird gedrosselt (6h pro Detektor/Tenant/ Schauspieler, im Redis verwenden die Login-Anomalie-Regeln bereits). Warnungen tragen Bezeigt und zählt, nie ein Rekord. Zwei bewusste strukturelle Entscheidungen: - Die Aggregate laufen durch einen EntityManager, nicht Spring Data @Query. Frühling Daten validiert eine deklarierte Abfrage, indem sie bei repository bootstrap erstellt wird, also a Fehler dort scheitert Kontext Startup und ein SecurityService, der nicht Start nimmt jedes Login mit ihm, wie am 2026-08-03. Hier ist der schlimmste Fall ein Sweep, dass Protokolle und Wiedererneuerungen nächste Stunde. Es entfernt auch dieses Paket aus dem @EnableJpaRepositories Frage vollständig: kein Repository Bohne, nichts zu vergessen. PhiDetectionQueryTest prüft jeden Eigenschaftsweg reflektierend seit Kein Test in diesem Service kann einen Kontext starten. - Jede Abfrage wird zuerst durch Organisations-ID eingeschränkt. nutzbarer Index ist (ORGANIZATION_ID, OCCURRED_AT); pünktlich filtern voll-scans eine Onend-only-Tabelle, die immer nur wächst. Planung: Dies verbindet TaskScheduler (4 Fäden, Planung), die sieben Sweeps bereits teilen. Es berührt NICHT TranslationExecutor - die 3-thread/500-queue @Async Pool beobachtet gesättigt und unterwirft sich an keinen Vollstrecker. Stündlich, fünf gruppierte Aggregate pro Mieter-Charge, kein Netzwerk-I/O innerhalb des Scans und eine Reentrancy Verriegelung, so dass ein langsamer Lauf überspringt die nächste Zecke statt stapeln dahinter und hungert den Pool teilt es. Keine Entität oder Spalte wurde hinzugefügt oder geändert.