Review 1.5: docs: what Windows servers and synthetic checks store, the stricter SQL check, no hub or PDF yet

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

docs/databehandling.md

@@ -104,3 +104,17 @@ Deling er slået fra som standard og er ikke en betingelse for Professional elle
 Agent og webbrugerflade gemmer data i kundens eget repository hos kunden. Her er kunden selv ansvarlig. Repositoriet indeholder de samme typer data som ovenfor, inklusive følsomme målinger (forespørgselstekst, logins, deadlock-grafer), fordi de er nødvendige for at løse problemerne lokalt. Til [analyse af tidsrum](analyse.md) gemmes desuden de tungeste forespørgsler med tekst og forbrug hvert 5. minut i `RawDays` (standard 14 dage); den tekst bruges kun lokalt og indgår aldrig i det, der sendes til SQLInsight Hub. Adgang til webbrugerfladen styres med Windows-login, og databasebrugeren har kun læserettigheder.
 
 Til [rettighedsrevisionen](rettigheder.md) gemmes navne på personer og konti med forhøjede serverrettigheder (også personer i Windows-grupper, slået op i kundens Active Directory af agenten), hvem der har fået eller mistet dem, og hvem der foretog ændringen. Det er personoplysninger. De bliver i kundens repository: ændringsloggen slettes efter `ResolvedFindingDays` (standard 365 dage), og i fund er navnene følsomme målinger, som sendes til SQLInsight Hub og integrations-API'et som `[udeladt]`. Fundets titel og emne indeholder ingen navne. Revisionsrapporten (PDF) dannes kun lokalt.
+
+Til [Windows-servere](windows-servere.md) og [syntetiske tjek](syntetiske-tjek.md) (fra 1.5) gemmes i kundens repository:
+
+| Data | Kan indeholde | Slettes |
+|---|---|---|
+| CPU og hukommelse pr. minut | – | efter `SQLInsight:Servers:SampleDays` (standard 14 dage) |
+| Ledig plads pr. drev | drevbogstaver og etiketter | efter `SQLInsight:Servers:DiskHistoryDays` (standard 35 dage) |
+| Grupperede fejl fra hændelsesloggen med den nyeste tekst som eksempel (højst 500 tegn) | brugernavne, computernavne, stier og IP-adresser | efter `SQLInsight:Servers:EventDays` (standard 90 dage) |
+| Tjenester og planlagte opgaver (navne, status, seneste resultat) | navne på tjenestekonti er ikke med; opgaver pr. bruger kan have brugerens SID i navnet | erstattes ved hver indsamling |
+| Syntetiske tjeks resultater med besked og detaljer | logins i SQL-fejltekster, adresser | efter `SQLInsight:SyntheticChecks:ResultDays` (standard 14 dage) |
+| Et SQL-tjeks login og adgangskode | login'et; adgangskoden kun krypteret til agentens nøgle (som i 1.3) | når tjekket fjernes (login og krypteret adgangskode slettes med det samme) |
+| Fund på servere og tjek | følsomme målinger som ovenfor | når de er løst, og derefter efter `ResolvedFindingDays` (standard 365 dage) |
+
+Fundenes titel og emne indeholder ingen hændelsestekster, fejlbeskeder eller logins; de står kun i følsomme målinger, som integrations-API'et viser som `[udeladt]` (også agentens konto, brugernavne og adresser med forespørgselsparametre). Notifikationer (fx Teams og webhooks) får titel og emne. Fund på servere og syntetiske tjek sendes ikke til SQLInsight Hub og indgår endnu ikke i PDF-rapporterne.

docs/syntetiske-tjek.md

@@ -16,7 +16,7 @@ Tjekkene oprettes under **Servere → Syntetiske tjek** i webbrugerfladen eller
 
 **HTTPS:** certifikatets udløbsdato læses ved hvert tjek – også når certifikatet afvises. Et selvsigneret certifikat kan accepteres med *Accepter ugyldigt certifikat*; udløbsdatoen tjekkes stadig.
 
-**SQL:** forespørgslen skal være én skrivebeskyttet `SELECT` (samme regler som community-reglerne, se [regler.md](regler.md)): ingen `INSERT`, `UPDATE`, `EXEC`, `INTO` osv. Det tjekkes, når tjekket gemmes, og igen, før det køres, og forespørgslen køres i en transaktion, der altid rulles tilbage, med `READ UNCOMMITTED` og `LOCK_TIMEOUT 5000`. Standardforespørgslen virker på SQL Server 2005 og nyere. Det præcise SQL står i [`SQL Scripts/SQLI-SYN-001.sql`](../SQL%20Scripts/SQLI-SYN-001.sql).
+**SQL:** forespørgslen skal være én skrivebeskyttet `SELECT` (samme regler som community-reglerne, se [regler.md](regler.md)): ingen `INSERT`, `UPDATE`, `EXEC`, `INTO` osv., ingen andre sætninger (T-SQL kræver intet semikolon mellem dem, så fx `COMMIT`, `SET`, `DECLARE`, `WRITETEXT` afvises), ingen `NEXT VALUE FOR` (sekvenser rulles ikke tilbage) og ingen låse-hints som `UPDLOCK`, `XLOCK` eller `TABLOCKX`; flere `SELECT` kun med `UNION`, `EXCEPT` eller `INTERSECT`. Kommentarer, tekster og `[navne]` læses, som SQL Server læser dem, så intet kan gemmes i dem. Højst 10.000 rækker læses. Det tjekkes, når tjekket gemmes, og igen, før det køres, og forespørgslen køres i en transaktion, der altid rulles tilbage, med `READ UNCOMMITTED` og `LOCK_TIMEOUT 5000`. Standardforespørgslen virker på SQL Server 2005 og nyere. Det præcise SQL står i [`SQL Scripts/SQLI-SYN-001.sql`](../SQL%20Scripts/SQLI-SYN-001.sql).
 
 ### Dynamics AX-logon
 
@@ -41,7 +41,7 @@ Tjenesten læses med de samme rettigheder som Windows-serverne (Service Control
 
 ## Adgangskoder
 
-Et SQL-login's adgangskode krypteres i webbrugerfladen i det øjeblik, den modtages, med **agentens offentlige nøgle** – præcis som i 1.3 (se [servere-og-databaser.md](servere-og-databaser.md#sql-login-adgangskoder)). Kun agenten kan læse den; den vises aldrig igen og returneres aldrig af API'et (kun `hasPassword`). Den er bundet til server, port og login: ændres de, skal den indtastes igen. Kan agenten ikke bruge den (fx efter en geninstallation), siger tjekket det, og den indtastes igen. HTTP-, TCP-, DNS- og AX-tjek bruger ingen adgangskoder.
+Et SQL-logins adgangskode krypteres i webbrugerfladen i det øjeblik, den modtages, med **agentens offentlige nøgle** – præcis som i 1.3 (se [servere-og-databaser.md](servere-og-databaser.md#sql-login-adgangskoder)). Kun agenten kan læse den; den vises aldrig igen og returneres aldrig af API'et (kun `hasPassword`). Den er bundet til server, port og login: ændres de, skal den indtastes igen. Kan agenten ikke bruge den (fx efter en geninstallation), siger tjekket det, og den indtastes igen. Fjernes tjekket, slettes login og krypteret adgangskode med det samme. HTTP-, TCP-, DNS- og AX-tjek bruger ingen adgangskoder.
 
 ## Regler
 
@@ -51,11 +51,11 @@ Et SQL-login's adgangskode krypteres i webbrugerfladen i det øjeblik, den modta
 | SQLI-SYN-002 | Tjekket svarer langsomt (Middel) | tjekkets *Langsomt svar over (ms)*; `SlowRunsBeforeFinding` 3 gange i træk |
 | SQLI-SYN-003 | TLS-certifikatet udløber (Middel; Høj inden for `CertificateCriticalDays` 7; Kritisk når udløbet) | `CertificateWarningDays` 21 |
 
-Ét tabt svar giver ingen alarm; to i træk gør. Fundet løses, når tjekket lykkes igen. Fund vises på tjekkets side og sammen med serverfundene, sendes som notifikationer og findes i API'et.
+Ét tabt svar giver ingen alarm; to i træk gør. Fundet løses, når tjekket lykkes igen. Fund vises på tjekkets side og sammen med serverfundene, sendes som notifikationer og findes i API'et. Fundets titel nævner tjekket og tjenestens tilstand, aldrig fejlbeskeden (den står som følsom måling). Fund sendes ikke til SQLInsight Hub og indgår endnu ikke i PDF-rapporterne.
 
 ## Firewall
 
-Fra agentens server: de porte, tjekkene bruger (fx TCP 2712 til AOS'en, 80/443 til HTTP(S), 1433 eller instansens port til SQL Server, 53 til DNS). Tjenestens tilstand: som Windows-serverne (WinRM TCP 5985 eller DCOM/RPC).
+Fra agentens server: de porte, tjekkene bruger (fx TCP 2712 til AOS'en, 80/443 til HTTP(S), 1433 eller instansens port til SQL Server, 53 til DNS). Tjenestens tilstand: som Windows-serverne (DCOM/RPC, eller WinRM TCP 5985 med `-WinRM`).
 
 ## Opbevaring og konfiguration
 

docs/windows-servere.md

@@ -117,7 +117,7 @@ Som SQL Servers fejllog (se [fejllog.md](fejllog.md)) grupperes hændelserne pr.
 
 Hver regel har sit eget script i [`SQL Scripts/`](../SQL%20Scripts/) (fx `SQLI-WIN-006.sql`) med de præcise CIM/WQL-forespørgsler og en skrivebeskyttet PowerShell-linje, der efterprøver dem.
 
-Fund på servere vises på serverens side, under **Aktive fund på servere og syntetiske tjek** på siden Windows-servere, sendes som notifikationer (med link til fundet) og findes i API'et. De sendes ikke til SQLInsight Hub.
+Fund på servere vises på serverens side, under **Aktive fund på servere og syntetiske tjek** på siden Windows-servere, sendes som notifikationer (med link til fundet) og findes i API'et. De sendes ikke til SQLInsight Hub og indgår endnu ikke i PDF-rapporterne.
 
 ## Opbevaring