Søren Eggert Lundsteen Olsen
b29ebb424d
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
96 lines
9.4 KiB
Markdown
96 lines
9.4 KiB
Markdown
# Syntetiske tjek
|
||
|
||
Et syntetisk tjek gør det, en bruger eller en applikation gør – forbinder til AOS-porten, henter en side, logger på SQL Server og kører en forespørgsel, slår et navn op, logger på Dynamics AX – med jævne mellemrum, fra agentens server og som agentens konto. Så opdages det også, når **en applikationsserver ikke svarer på det syntetiske tjek, selv om tjenesten kører**: noget, en tjenesteovervågning alene aldrig ser.
|
||
|
||
Tjekkene oprettes under **Servere → Syntetiske tjek** i webbrugerfladen eller med API'et (se [nedenfor](#api)). Agenten kører dem inden for et minut efter oprettelsen og derefter efter tjekkets interval (standard hvert 5. minut, mindst hvert minut). **Kør nu** kører et tjek med det samme. Intet tjek ændrer noget på de servere, det tjekker.
|
||
|
||
## Typer
|
||
|
||
| Type | Hvad agenten gør | Succes |
|
||
|---|---|---|
|
||
| **TCP-port** | Åbner en TCP-forbindelse til server:port (fx AOS'en på 2712) | Porten svarer |
|
||
| **HTTP(S)** | `GET` på adressen, følger op til 5 omdirigeringer, eventuelt som agentens Windows-konto (Enterprise Portal, Reporting Services) | Status 200–399 eller de forventede koder, og eventuelt en forventet tekst i de første 1 MB |
|
||
| **SQL-login og forespørgsel** | Logger på SQL Server (agentens Windows-konto eller et SQL-login), skifter eventuelt database og kører forespørgslen (standard `SELECT 1`) | Login og forespørgsel lykkes; svartiden måles for login og forespørgsel hver for sig |
|
||
| **DNS-opslag** | Slår navnet op | Navnet giver adresser (og en af de forventede, hvis de er angivet) |
|
||
| **Dynamics AX-logon** | Tester AOS-porten, og logger derefter på AX gennem .NET Business Connector, hvis den er installeret på agentens server | Se nedenfor |
|
||
|
||
**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., 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
|
||
|
||
Tjekket gør sit bedste:
|
||
|
||
1. **AOS-porten** (standard 2712) skal svare. Gør den ikke, fejler tjekket.
|
||
2. Er **.NET Business Connector** (AX 2009 eller AX 2012) installeret på agentens server, logger agenten på AX gennem den – **i en separat Windows PowerShell-proces med timeout** (Business Connector er en .NET Framework-komponent og kan ikke indlæses i agenten) – og logger straks af igen. Der logges på som **agentens Windows-konto**, som derfor skal være oprettet som bruger i AX (i det angivne firma); der gemmes ingen adgangskode. Agenten læser intet i AX.
|
||
3. Er Business Connector **ikke** installeret (eller logon-testen slået fra), testes **kun porten**, og resultatet siger det tydeligt: *"Kun porten er testet: .NET Business Connector (AX 2009/2012) er ikke installeret på agentens server, så et AX-logon kan ikke prøves."*
|
||
|
||
Business Connector findes, hvor AX-installeren lægger den (`…\Microsoft Dynamics AX\60\BusinessConnector\Bin`, `…\50\Client\Bin`), eller hvor `SQLInsight:SyntheticChecks:BusinessConnectorPath` peger. AX 2009's Business Connector er bygget til .NET 2.0 og kræver Windows PowerShell 2.0-motoren (.NET Framework 3.5) på agentens server; mangler den, siger resultatet det. Object server angives som i AX-klientens konfiguration (fx `01@aos01:2712`); standard er server:port. Et logon optager kortvarigt en AX-session.
|
||
|
||
Kør agenten som en gMSA eller domænekonto, hvis AX-logon skal testes: computerkontoen `DOMÆNE\AGENTSERVER$` kan normalt ikke oprettes som AX-bruger.
|
||
|
||
## Tjeneste bag tjekket
|
||
|
||
Et tjek kan knyttes til en Windows-server (se [windows-servere.md](windows-servere.md)) og en tjeneste på den, fx AOS'en `AOS60$01` eller IIS `W3SVC`. Fejler tjekket, slår agenten tjenestens tilstand op, og fundet siger forskellen:
|
||
|
||
- *"AOS01 AX-logon svarer ikke, selv om tjenesten AOS60$01 kører"* – tjenesten hænger, er overbelastet, venter på databasen eller er blokeret af en firewall.
|
||
- *"AOS01 AX-logon svarer ikke: tjenesten AOS60$01 er stoppet"*.
|
||
|
||
Tjenesten læses med de samme rettigheder som Windows-serverne (Service Control Manager).
|
||
|
||
## 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
|
||
|
||
| Regel | Fund | Tærskel |
|
||
|---|---|---|
|
||
| SQLI-SYN-001 | Tjekket fejler (Høj) – med tjenestens tilstand, når den kendes | `SQLInsight:SyntheticChecks:FailuresBeforeFinding` 2 fejl i træk |
|
||
| 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. 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 (DCOM/RPC, eller WinRM TCP 5985 med `-WinRM`).
|
||
|
||
## Opbevaring og konfiguration
|
||
|
||
Hver kørsel gemmes i 14 dage (`SQLInsight:SyntheticChecks:ResultDays`). Højst `MaxParallelChecks` (standard 4, 1–32) tjek kører samtidig, og et tjek kører aldrig to gange samtidig. Fejler et tjek uventet, gemmes det som en fejlet kørsel, og det prøves først igen efter sit interval. Timeout pr. tjek er standard 15 sekunder (AX-logon 60), højst 120.
|
||
|
||
```json
|
||
"SyntheticChecks": {
|
||
"Enabled": true,
|
||
"MaxParallelChecks": 4,
|
||
"FailuresBeforeFinding": 2,
|
||
"SlowRunsBeforeFinding": 3,
|
||
"CertificateWarningDays": 21,
|
||
"CertificateCriticalDays": 7,
|
||
"ResultDays": 14,
|
||
"BusinessConnectorPath": null
|
||
}
|
||
```
|
||
|
||
## API
|
||
|
||
| Kald | Svar |
|
||
|---|---|
|
||
| `GET /api/v1/synthetic-checks` | Tjek med seneste resultat |
|
||
| `POST /api/v1/synthetic-checks` | Opret: `name`, `kind` (`Tcp`, `Http`, `Sql`, `Dns`, `AxLogon`), `serverId`, `intervalSeconds`, `timeoutSeconds`, `settings`, `password`; 201 med `runRequestId` |
|
||
| `GET`, `PUT`, `PATCH`, `DELETE /api/v1/synthetic-checks/{id}` | Ét tjek; ret (typen kan ikke ændres); pause; fjern |
|
||
| `POST /api/v1/synthetic-checks/{id}/run` | Kør nu (202, følg `GET /api/v1/agent-requests/{id}`; venter en kørsel allerede, gives den samme; 409 for et tjek på pause). Kører tjekket allerede, venter agenten på den kørsel i stedet for at starte en til |
|
||
| `GET /api/v1/synthetic-checks/{id}/results?hours=24` | Kørsler med svartid, certifikat og tjenestens tilstand |
|
||
| `GET /api/v1/synthetic-checks/{id}/rule-states` | Reglernes udfald |
|
||
|
||
`settings` har felterne for typen: `host`, `port`, `url`, `expectedStatus`, `expectedText`, `useWindowsAuthentication`, `allowInvalidCertificate`, `server`, `database`, `authentication` (`Windows`/`SqlLogin`), `userName`, `encryption`, `trustServerCertificate`, `query`, `expectedAddresses`, `company`, `objectServer`, `configuration`, `businessConnectorLogon`, `serviceName`, `warnMilliseconds`.
|
||
|
||
```powershell
|
||
$h = @{ Authorization = "Bearer $token" }
|
||
$body = @{ name = 'AOS01 AX-logon'; kind = 'AxLogon'; serverId = 3; settings = @{ host = 'aos01'; company = 'DAT'; serviceName = 'AOS60$01' } } | ConvertTo-Json
|
||
Invoke-RestMethod https://sqlinsight.domæne.local/api/v1/synthetic-checks -Method Post -Headers $h -Body $body -ContentType 'application/json'
|
||
```
|
||
|
||
Fejlbeskeder kan nævne logins og servere: for fejlede kørsler er beskeden og følsomme målinger `[udeladt]` i API'et, medmindre `SQLInsight:Web:ApiIncludesSensitiveEvidence` er slået til. Det samme gælder `settings.userName` og en adresses forespørgselsparametre (`https://server/side?[udeladt]`): sendes et tjek tilbage med `PUT`, skal det rigtige login og den hele adresse angives igen (`[udeladt]` afvises). Adresser må højst være 2000 tegn. At ændre kræver scope `config:write` eller `SQLInsight:Web:AdminGroups`.
|