447 lines
24 KiB
Markdown
447 lines
24 KiB
Markdown
# Déploiement Production — Diagnostics multi-serveurs (T19/T20)
|
||
|
||
> Statut : préparation (aucun déploiement réel effectué). Document de référence pour le
|
||
> futur déploiement contrôlé du Diagnostic Center central et de l'API métier/mobile chez
|
||
> chaque client. Aucune valeur de secret (clé, mot de passe) n'est contenue ici.
|
||
|
||
---
|
||
|
||
## 1. Responsabilités des composants (§30)
|
||
|
||
| Composant | Rôle | Installation |
|
||
|---|---|---|
|
||
| **Omika.Api** | API métier/mobile installée **chez chaque client** (licence, bootstrap, métier, `POST /api/diagnostics`). Le mobile ne connaît QUE cette API. | Serveur du client |
|
||
| **Omika.Diagnostics.Api** | API **centrale**, installée **uniquement sur le serveur Omika**. Reçoit les lots des serveurs clients (`POST /api/v1/diagnostics/batches`), authentifie (ClientCode + ApiKey), impose le ClientCode authentifié, écrit le spool central. Aucune logique métier. | Serveur central Omika |
|
||
| **Omika.Diagnostics.Worker** | Import du spool central JSONL → PostgreSQL (`diagnostic_event`). Déduplication par `event_id`. | Serveur central Omika |
|
||
| **Omika.Diagnostics.Web** | Interface de consultation/administration (Dashboard, Diagnostics, Erreurs, Télémétrie, Référentiel, **Clients Diagnostics**, Système). | Serveur central Omika |
|
||
|
||
Le **mobile** ne connaît jamais `Omika.Diagnostics.Api/Worker/Web`, ni PostgreSQL Diagnostics, ni aucune
|
||
clé central. Le **serveur client** ne connaît jamais la ConnectionString PostgreSQL centrale
|
||
(§43) : seul le composant central autorisé détient cette configuration.
|
||
|
||
---
|
||
|
||
## 2. Architecture de flux
|
||
|
||
```
|
||
APPAREILS MOBILES ──HTTPS──▶ SERVEUR DU CLIENT
|
||
Omika.Api (+ Omika.Worker métier)
|
||
└─▶ Spool local borné (DiagnosticsForwarding.Spool)
|
||
└─▶ DiagnosticsForwarder (BackgroundService dans Omika.Api)
|
||
└─ HTTPS ──▶ SERVEUR OMIKA CENTRAL
|
||
Omika.Diagnostics.Api
|
||
└─▶ Spool central (Diagnostics:Central)
|
||
└─▶ Omika.Diagnostics.Worker
|
||
└─▶ PostgreSQL omika_diagnostics
|
||
└─▶ Omika.Diagnostics.Web
|
||
```
|
||
|
||
---
|
||
|
||
## 3. Services Windows cibles (§51)
|
||
|
||
### Serveur client
|
||
- `OmikaApi` (process Omika.Api ; contient le forwarder de diagnostics — **aucun service dédié**).
|
||
- `OmikaWorker` (Worker de synchronisation métier, service réel existant).
|
||
- API Licence / service existant (inchangé).
|
||
|
||
### Serveur central Omika
|
||
- `OmikaDiagnosticsApi` (API centrale, Kestrel).
|
||
- `OmikaDiagnosticsWorker` (import JSONL → PostgreSQL).
|
||
- `OmikaDiagnosticsWeb` (interface, Kestrel derrière reverse proxy Apache).
|
||
- PostgreSQL (`omika_diagnostics`).
|
||
|
||
Les noms de services sont posés par les scripts d'activation serveur (`sc.exe` / `New-Service`)
|
||
et doivent correspondre aux valeurs `UseWindowsService(...)` du code.
|
||
|
||
---
|
||
|
||
## 4. Ports (§52)
|
||
|
||
| Service | Port local Développement | Port Production (à confirmer selon convention existante) |
|
||
|---|---|---|
|
||
| Omika.Api (client) | 5097 | défini par `Kestrel:Endpoints` / `appsettings.Production.json` (loopback derrière Apache) |
|
||
| Omika.Diagnostics.Api (central) | 5098 | à définir (loopback Kestrel derrière Apache/HTTPS) |
|
||
| Omika.Diagnostics.Web (central) | 5080 | à définir (loopback Kestrel derrière Apache/HTTPS) |
|
||
| PostgreSQL | 5432 | 5432 (loopback central uniquement) |
|
||
|
||
**Règle** : les services web sont exposés en **HTTPS** via le reverse proxy Apache ; Kestrel reste
|
||
en HTTP sur loopback. Aucun port n'est choisi arbitrairement : la convention Apache/Kestrel
|
||
existante de `omika.applilogik.fr` s'applique.
|
||
|
||
---
|
||
|
||
## 5. HTTPS (§37/§38)
|
||
|
||
- Le flux **serveur client → API centrale** est **HTTPS uniquement** en Production.
|
||
- `DiagnosticsForwarding:Endpoint` doit être une URL **`https://…`**.
|
||
- **Règle T20** : si l'environnement est **Production** et que l'Endpoint est en **`http://`**,
|
||
le forwarder **refuse l'envoi** (log explicite une fois), le **métier continue** (fail-open),
|
||
le spool local est conservé. `Omika.Api` n'est **jamais** arrêté à cause de Diagnostics.
|
||
- Le certificat TLS réel n'est **pas** configuré dans ce document (à poser sur le reverse proxy).
|
||
|
||
---
|
||
|
||
## 6. Configuration Omika.Api (§31/§32/§33/§34/§35)
|
||
|
||
Section `DiagnosticsForwarding` (dans `src/Omika.Api/appsettings.json`, surchargée par variables
|
||
d'environnement / `appsettings.Production.json` **non versionné**) :
|
||
|
||
| Clé | Défaut | Rôle |
|
||
|---|---|---|
|
||
| `DiagnosticsForwarding:Enabled` | `false` | Kill switch. **`DiagnosticsForwarding__Enabled=true` uniquement lors du déploiement serveur client.** |
|
||
| `DiagnosticsForwarding:Endpoint` | `""` | URL centrale absolue **HTTPS** (ex. `https://…/api/v1/diagnostics/batches`). Laisser vide tant qu'aucune URL réelle. |
|
||
| `DiagnosticsForwarding:ApiKey` | `""` | **Secret** à installer sur le serveur client via `DiagnosticsForwarding__ApiKey`. Jamais dans Git/log/rapport. |
|
||
| `DiagnosticsForwarding:TimeoutSeconds` | `10` | Timeout réseau d'un envoi (le forwarder est background : jamais de blocage métier). |
|
||
| `DiagnosticsForwarding:BatchSize` | `100` | Événements max par lot. |
|
||
| `DiagnosticsForwarding:MaxBatchBytes` | `524288` | Taille max d'un lot (premier seuil). |
|
||
| `DiagnosticsForwarding:RetryInitialSeconds` | `15` | Backoff initial. |
|
||
| `DiagnosticsForwarding:RetryMaxMinutes` | `30` | Plafond du backoff. |
|
||
| `DiagnosticsForwarding:Spool:MaxFileSizeMb` | `10` | Rotation de fichier. |
|
||
| `DiagnosticsForwarding:Spool:MaxTotalSizeMb` | `1024` | Quota disque total. |
|
||
| `DiagnosticsForwarding:Spool:RetentionDays` | `14` | Rétention. |
|
||
|
||
Le défaut `Enabled=false` est **volontaire** (sécurité, opt-in). Aucun placeholder fictif
|
||
(`https://diagnostics.exemple.fr`) ne doit devenir une valeur réelle accidentellement.
|
||
|
||
---
|
||
|
||
## 7. Configuration Omika.Diagnostics.Api (§36)
|
||
|
||
Section `Diagnostics` (dans `src/Omika.Diagnostics.Api/appsettings.json`, surchargée par variables) :
|
||
|
||
| Clé | Défaut | Rôle |
|
||
|---|---|---|
|
||
| `ConnectionStrings:DiagnosticsDatabase` (ou `Diagnostics:ConnectionString`) | `""` | PostgreSQL central (secret, injecté serveur). |
|
||
| `Diagnostics:Central:Directory` | `logs/diagnostics-central` | **Spool central** — en Production, chemin explicite (voir §9). |
|
||
| `Diagnostics:Central:MaxRequestBodyBytes` | `524288` | Corps de requête borné. |
|
||
| `Diagnostics:Central:MaxEventsPerBatch` | `100` | Événements max par lot. |
|
||
| `Diagnostics:Central:SchemaVersion` | `1` | Version de schéma de transport. |
|
||
|
||
URL/port : via `ASPNETCORE_URLS` (ou `Kestrel:Endpoints`) derrière le reverse proxy HTTPS.
|
||
|
||
---
|
||
|
||
## 8. Spool client — emplacement Production (§40)
|
||
|
||
Le service Windows peut démarrer depuis `C:\Windows\System32` : **ne jamais dépendre du current
|
||
working directory**. Utiliser un chemin explicite configurable :
|
||
|
||
```
|
||
C:\ProgramData\Omika\Diagnostics\Spool
|
||
```
|
||
|
||
(via `Observability:Remote:Directory` / `DiagnosticsForwarding` — à poser dans la configuration
|
||
serveur client). Le quota (`MaxTotalSizeMb`) et la rétention (`RetentionDays`) évitent un
|
||
remplissage disque : à quota atteint, les fichiers les plus anciens sont supprimés (log du
|
||
nombre), jamais le fichier actif, jamais d'échec métier.
|
||
|
||
---
|
||
|
||
## 9. Spool central — emplacement Production (§41)
|
||
|
||
Même réflexion pour `Omika.Diagnostics.Api` :
|
||
|
||
```
|
||
C:\ProgramData\Omika\Diagnostics\Central
|
||
```
|
||
|
||
(via `Diagnostics:Central:Directory`). Le Worker central lit ce dossier (import JSONL → PostgreSQL,
|
||
checkpoint `import-checkpoint.json`).
|
||
|
||
---
|
||
|
||
## 10. Permissions Windows (§42)
|
||
|
||
Principe de moindre privilège (jamais Administrateur inutilement) :
|
||
|
||
| Compte service | Dossier | Droits |
|
||
|---|---|---|
|
||
| `OmikaApi` | `C:\ProgramData\Omika\Diagnostics\Spool` | lecture + écriture |
|
||
| `OmikaDiagnosticsApi` | `C:\ProgramData\Omika\Diagnostics\Central` | lecture + écriture |
|
||
| `OmikaDiagnosticsWorker` | `C:\ProgramData\Omika\Diagnostics\Central` | lecture (checkpoint → écriture du checkpoint selon le dossier) |
|
||
|
||
---
|
||
|
||
## 11. PostgreSQL (§43/§54)
|
||
|
||
- Base dédiée `omika_diagnostics`. PostgreSQL **ne doit jamais être exposé** aux serveurs clients :
|
||
seuls les composants centraux autorisés y accèdent (firewall : loopback central uniquement).
|
||
- Rôles : voir migrations `003`/`004`/`009`/`010` (`omika_diagnostics_owner`, `_worker`, `_web`, `_api`).
|
||
- `omika_diagnostics_api` (LOGIN) : **Omika.Diagnostics.Api** — `SELECT` + `UPDATE(last_seen_at_utc)` sur `diagnostics_clients` uniquement. **Aucun** droit sur `diagnostics_users`.
|
||
- `omika_diagnostics_web` (LOGIN) : **Omika.Diagnostics.Web** — `SELECT` sur `diagnostic_event` ; `SELECT`/`INSERT`/`UPDATE` sur `diagnostics_clients` (admin `/Clients`) ; `SELECT`/`INSERT`/`UPDATE` (colonnes `password_hash`, `role`, `enabled`, `updated_at_utc`, `password_changed_at_utc`, `last_login_at_utc`) + `USAGE` séquence sur `diagnostics_users` (admin `/Users` + login).
|
||
- `omika_diagnostics_worker` (LOGIN) : **Omika.Diagnostics.Worker** — `INSERT`/`SELECT`/`DELETE` sur `diagnostic_event` ; **aucun** droit sur `diagnostics_clients` ni `diagnostics_users`.
|
||
- Le serveur client **NE DOIT PAS** connaître la ConnectionString PostgreSQL centrale.
|
||
|
||
---
|
||
|
||
## 12. Migrations — inventaire (§44/§45/§46)
|
||
|
||
Ordre d'application sur le serveur central : `001 → 002 → 003 → 004 → 005 → 006 → 007 → 008 → 009 → 010`.
|
||
|
||
| Fichier | But | Développement appliqué ? | Production nécessaire ? |
|
||
|---|---|---|---|
|
||
| `001_diagnostics_schema.sql` | `diagnostic_event` + `telemetry_metric_hourly` + index + déduplication `event_id`. | Oui | Oui |
|
||
| `002_actor_key.sql` | Colonnes `actor_key`/`actor_key_version` (HMAC pseudonymisation). | Oui | Oui |
|
||
| `003_diagnostics_roles.sql` | Rôles/grants serveur (`owner`/`worker`/`web`), moindre privilège. | **Non** (à exécuter sur le serveur PostgreSQL Production, en superuser) | Oui |
|
||
| `004_diagnostics_retention.sql` | Grant `SELECT, DELETE` au worker pour la rétention bornée. | **Non** (idem, serveur Production) | Oui |
|
||
| `005_diagnostics_client_context.sql` | Colonnes `client_code`/`server_instance`/`environment`. | Oui | Oui |
|
||
| `006_diagnostics_device_license.sql` | Colonnes appareil/licence. | Oui | Oui |
|
||
| `007_diagnostics_usage.sql` | Colonnes `screen_code`/`feature_code`. | Oui | Oui |
|
||
| `008_diagnostics_clients.sql` | Table `diagnostics_clients` (registre des serveurs clients, hash SHA-256). | Oui | Oui |
|
||
| `009_diagnostics_clients_grants.sql` | Ownership + GRANT moindre privilège de `diagnostics_clients` (`_api`/`_web`), rôle `omika_diagnostics_api`. | **Non** (serveur PostgreSQL Production, superuser) | Oui |
|
||
| `010_diagnostics_web_users.sql` | Table `diagnostics_users` (utilisateurs Web) + ownership `omika_diagnostics_owner` + GRANT moindre privilège `_web` uniquement (aucun droit API/Worker). | **Non** (serveur PostgreSQL Production, superuser) | Oui |
|
||
|
||
**003/004/009/010** : contiennent des `CREATE ROLE` / `ALTER ROLE` / `GRANT` au niveau **serveur/instance**.
|
||
Elles ne sont **pas** appliquées sur le PC de développement (elles exigent le superuser PostgreSQL
|
||
Production et fixent les comptes de service). Elles devront être exécutées **sur le serveur
|
||
PostgreSQL Production**, dans l'ordre, **avant** le pointage des comptes de service
|
||
Worker/Web/Api (`omika_diagnostics_worker` / `omika_diagnostics_web` / `omika_diagnostics_api`),
|
||
puis les mots de passe posés manuellement (`\password`, jamais dans un script/log).
|
||
Ne pas les exécuter localement « pour du vert ».
|
||
|
||
> **T22** : `008` crée `diagnostics_clients` **après** `003`/`004`, donc sans ownership ni GRANT
|
||
> applicatif. `009` transfère la propriété à `omika_diagnostics_owner` (même propriétaire logique
|
||
> que `diagnostic_event`/`telemetry_metric_hourly`), crée le rôle `omika_diagnostics_api` (absent du
|
||
> modèle `003`), et pose les GRANT minimum identifiés par l'audit des consommateurs réels :
|
||
> API = `SELECT` + `UPDATE(last_seen_at_utc)` ; Web = `SELECT`/`INSERT`/`UPDATE(enabled, api_key_hash,
|
||
> key_prefix, key_created_at_utc)` + `USAGE` séquence ; Worker = aucun. `009` est idempotent
|
||
> (re-exécutable sans erreur) et utilise `current_database()` pour `GRANT CONNECT` (portable,
|
||
> testé sur `omika_diagnostics_preprod`).
|
||
|
||
---
|
||
|
||
## 13. Authentification ApiKey — audit final (§55/§56)
|
||
|
||
- Clé : **32 octets aléatoires**, **Base64Url**, préfixe **`omkdiag_`**.
|
||
- Stockage : **SHA-256 hexadécimal (64)** uniquement (`diagnostics_clients.api_key_hash`) + `key_prefix`.
|
||
- Vérification : `CryptographicOperations.FixedTimeEquals` ; hash factice si client inconnu (anti-timing).
|
||
- **401** : client inconnu OU mauvaise clé (indistinguables). **403** : client désactivé.
|
||
- **Tenant autoritaire** : tout ClientCode payload ≠ authentifié → **400** + anomalie (jamais de confiance au payload).
|
||
- Réponses sans fuite : jamais de hash, de clé, de stacktrace, ni l'existence précise d'un client.
|
||
|
||
---
|
||
|
||
## 14. Procédure — nouveau client Production (§73)
|
||
|
||
1. `Omika.Diagnostics.Web` → **Clients Diagnostics** (Admin).
|
||
2. **Nouveau client**.
|
||
3. Saisir le **CodeClient exact** (ex. `BATIK.01`, normalisé `UPPER(TRIM)`).
|
||
4. **Créer le client** → la clé est générée.
|
||
5. **Copier immédiatement** la clé (bouton « Copier »).
|
||
6. Installer la clé sur le serveur client : variable `DiagnosticsForwarding__ApiKey`.
|
||
7. Configurer `DiagnosticsForwarding__Endpoint` (URL centrale **HTTPS**).
|
||
8. Activer : `DiagnosticsForwarding__Enabled=true`.
|
||
9. Redémarrer `OmikaApi`.
|
||
10. Vérifier `last_seen_at_utc` dans Clients Diagnostics.
|
||
11. Vérifier un diagnostic réel (Dashboard / Diagnostics).
|
||
|
||
---
|
||
|
||
## 15. Clé perdue (§74)
|
||
|
||
La clé **n'est pas récupérable** (hash seul stocké). Si elle n'a pas été copiée :
|
||
faire **Régénérer la clé**, puis mettre à jour le serveur client avec la nouvelle clé.
|
||
|
||
---
|
||
|
||
## 16. Rotation de clé (§75)
|
||
|
||
Version V1 : **régénération → ancienne clé immédiatement invalide**. Pendant l'intervalle où le
|
||
serveur client n'a pas encore la nouvelle clé, les envois échouent en `401` et le **spool local
|
||
s'accumule** (backlog borné, reprise automatique). Acceptable.
|
||
|
||
---
|
||
|
||
## 17. Panne centrale (§76)
|
||
|
||
- **Ne pas arrêter** `OmikaApi` (le métier continue).
|
||
- **Ne pas vider** le spool manuellement (les événements seront renvoyés).
|
||
- Vérifier l'espace disque (quota/rétention bornent le spool).
|
||
- Vérifier les logs du forwarder.
|
||
- Attendre le rétablissement : reprise automatique (backoff borné 15 s → 30 min).
|
||
|
||
---
|
||
|
||
## 18. Disque spool (§77)
|
||
|
||
- `MaxTotalSizeMb` (défaut 1024) : quota disque total ; à dépassement, suppression des fichiers
|
||
les plus anciens (jamais le fichier actif, log du nombre supprimé).
|
||
- `RetentionDays` (défaut 14) : purge des fichiers plus anciens.
|
||
- `MaxFileSizeMb` (défaut 10) : rotation de fichier.
|
||
- **Fail-open absolu** : aucune de ces opérations ne bloque le métier.
|
||
|
||
> **Validation empirique T22** (pipeline réel, panne centrale simulée) :
|
||
> - Quota `MaxTotalSizeMb=1` : 6000 événements fake (~3,6 Mo) → `DiagnosticsForwarder a abandonné
|
||
> 14 fichier(s) de spool`, spool final 768 Ko (≤ 1 Mo), fichier actif préservé, `/health` 200
|
||
> (aucun crash métier), Working Set stable ~115–125 Mo (backlog sur disque ≠ RAM).
|
||
> - Rétention `RetentionDays=1` : fichier ancien (-2 j) supprimé, fichier récent + fichier actif
|
||
> conservés, central DOWN pendant tout le test (la maintenance ne dépend pas du central).
|
||
> - **Correctif T22** : `EnforceBounds` (quota/rétention) était appelé uniquement quand le spool
|
||
> était vide ; pendant une panne centrale (backlog jamais vide), le quota n'était donc pas
|
||
> appliqué. Il est désormais appelé à chaque passe du forwarder, indépendamment du backlog.
|
||
> Test : `ForwardOnce_BacklogOverQuota_StillEnforcesBounds`.
|
||
|
||
---
|
||
|
||
## 19. Ordre de démarrage (reprise/rollback)
|
||
|
||
**Démarrage central** : PostgreSQL → `OmikaDiagnosticsWorker` → `OmikaDiagnosticsApi` →
|
||
`OmikaDiagnosticsWeb`.
|
||
|
||
**Démarrage client** : `OmikaWorker` (métier) → `OmikaApi` (métier + forwarder).
|
||
|
||
**Rollback** : `DiagnosticsForwarding__Enabled=false` + redémarrage `OmikaApi` coupe immédiatement
|
||
tout envoi central sans toucher au métier ni au spool (aucune perte de données).
|
||
|
||
---
|
||
|
||
## 20. Dépendance SQLite (mobile / Desktop local)
|
||
|
||
> Mise à jour **T22** — audit + correctif CVE.
|
||
|
||
- **Version retenue** : `Microsoft.Data.Sqlite 10.0.10` (inchangé) + **`SQLitePCLRaw` 2.1.12**
|
||
épinglé transitivement (`Directory.Packages.props`, `CentralPackageTransitivePinningEnabled=true`).
|
||
- **Raison** : `SQLitePCLRaw.lib.e_sqlite3 2.1.11` (transitif de `Microsoft.Data.Sqlite 10.0.10`)
|
||
embarque une bibliothèque SQLite native < 3.50.2, vulnérable à **CVE-2025-6965 /
|
||
GHSA-2m69-gcr7-jv3q** (troncature d'entier dans `findOrCreateAggInfoColumn`, `resolve.c`).
|
||
Correctif = SQLite native **3.50.2**, livré par le patch **2.1.12** (famille 2.x, drop-in,
|
||
ABI-compatible). **Pas** de saut vers SQLitePCLRaw 3.x (breaking) ni vers
|
||
`Microsoft.Data.Sqlite 11` (majeur).
|
||
- **Projets concernés** : `Omika.App.Local` (offline-first : cache métier, brouillons, sync,
|
||
`DiagnosticOutboxSqliteStore`) → `Omika.App` → têtes `Omika.App.Desktop` / `Omika.App.Android` /
|
||
`Omika.App.iOS`. Aucun impact sur `Omika.Api`, `Omika.Worker` ni les projets Diagnostics.
|
||
- **Validation** :
|
||
- `dotnet restore` OK ; `dotnet list package --include-transitive --vulnerable` →
|
||
**« aucun package vulnérable »** ; arbre confirmé `SQLitePCLRaw.* = 2.1.12`.
|
||
- Tests SQLite/Outbox ciblés : **148/148**.
|
||
- Builds Release : `Omika.App.Desktop` 0 erreur, `Omika.App.Android` 0 erreur.
|
||
- `Omika.App.Desktop` (Debug, flux dev) démarré réellement : ouverture `omika.db` OK +
|
||
bootstrap `DEV BOOTSTRAP` OK (aucun crash SQLite).
|
||
|
||
> **Surface réellement exposée** : la vulnérabilité nécessite une requête SQL construite avec un
|
||
> nombre extrême de termes d'agrégation ; Omika n'exécute que des requêtes applicatives fixes et
|
||
> paramétrées (jamais de SQL utilisateur), sur une base **locale** non accessible à distance. Le
|
||
> correctif 2.1.12 est néanmoins appliqué (moindre coût, aucun risque de régression constaté).
|
||
|
||
---
|
||
|
||
## 21. Gestion des utilisateurs Diagnostics.Web (T23)
|
||
|
||
### 21.1 Distinction fondamentale
|
||
|
||
| Concept | Définition | Identifiant | Stockage |
|
||
|---|---|---|---|
|
||
| **Utilisateur Diagnostics** | personne qui ouvre `Omika.Diagnostics.Web` | `username` | `diagnostics_users` (hash PBKDF2-SHA256) |
|
||
| **Client Diagnostics** | serveur client qui envoie des événements | `ClientCode` | `diagnostics_clients` (hash SHA-256) |
|
||
|
||
Les deux registres sont **totalement séparés** et ne doivent jamais être confondus.
|
||
|
||
### 21.2 Modèle utilisateur
|
||
|
||
- Table `diagnostics_users` (migration `010`) : `id`, `username` (unique, insensible à la casse),
|
||
`password_hash`, `role` (`Support` / `Admin`), `enabled`, `created_at_utc`, `updated_at_utc`,
|
||
`password_changed_at_utc`, `last_login_at_utc`.
|
||
- **Aucun mot de passe en clair** : seule la colonne `password_hash` existe. Le hash est produit
|
||
par `DiagnosticPasswordHasher` (PBKDF2-SHA256, 100 000 itérations, sel aléatoire).
|
||
- **Aucune suppression physique** (V1) : un utilisateur est **désactivé** (`enabled=false`), jamais `DELETE`.
|
||
|
||
### 21.3 Rôles
|
||
|
||
| Rôle | Accès |
|
||
|---|---|
|
||
| **Support** | Dashboard, Diagnostics, Erreurs, Traces, Synchronisation, Telemetry, Parc, Versions, Référentiel, Mon compte. |
|
||
| **Admin** | Tout Support + **Clients Diagnostics** + **Utilisateurs** + **Système**. |
|
||
|
||
`/System`, `/Clients` et `/Users` sont **Admin uniquement**. Un Support y obtient un refus
|
||
(redirection `/AccessDenied`). Un Admin conserve tous les droits de consultation Support.
|
||
|
||
### 21.4 Actions d'administration (`/Users`, Admin uniquement)
|
||
|
||
- **Création** : saisie `username` + `password` + `confirmation` + `rôle`. Le Web hache
|
||
automatiquement (`DiagnosticPasswordHasher.Hash`) ; l'Admin ne génère/copie **jamais** un hash.
|
||
- **Désactivation / Réactivation** (`enabled=false/true`).
|
||
- **Changement de rôle** `Support → Admin` / `Admin → Support`.
|
||
- **Réinitialisation du mot de passe** (nouveau mot de passe + confirmation → hash + UPDATE).
|
||
|
||
### 21.5 Protections
|
||
|
||
- **Dernier Admin** : impossible de désactiver ou rétrograder le dernier Admin actif
|
||
(« Impossible de retirer le dernier administrateur actif. »).
|
||
- **Auto-désactivation** : un Admin ne peut pas désactiver son propre compte.
|
||
- **Auto-rétrogradation** : un Admin ne peut pas retirer son propre rôle Admin.
|
||
|
||
### 21.6 Règles de validation
|
||
|
||
- **Username** : obligatoire, `trim`, unicité insensible à la casse, borné (≤ 64), caractères
|
||
`lettres / chiffres / . / - / _`.
|
||
- **Mot de passe** : non vide, **≥ 12 caractères**, confirmation identique. Pas de politique de
|
||
complexité superflue (V1).
|
||
|
||
### 21.7 Connexion (login hybride)
|
||
|
||
1. Si le `username` existe dans `diagnostics_users` → la DB est **autoritaire** (jamais de fallback).
|
||
- Vérification PBKDF2 (`DiagnosticPasswordHasher.Verify`) ; `enabled=false` → refus.
|
||
2. Sinon → fallback opérateurs `DiagnosticsAuth:Operators` (bootstrap temporaire).
|
||
3. Message d'échec **générique** : « Identifiants invalides. » (jamais « inconnu » / « désactivé » / « mauvais mot de passe »).
|
||
|
||
- `last_login_at_utc` est mis à jour (best-effort) après un login DB réussi.
|
||
- Anti-bruteforce léger (in-memory, mono-instance) : 5 échecs / 5 min → blocage 10 min
|
||
(clé = username + IP). Aucun Redis, aucune session distribuée.
|
||
- Anti-timing : hash factice calculé quand le username est inconnu (même principe que l'ApiKey).
|
||
- Cookie : `HttpOnly`, `SameSite=Lax`, `Secure=Always` hors Développement, expiration 12 h
|
||
(glissante). Production = HTTPS.
|
||
- Un utilisateur désactivé avec un cookie existant est re-déconnecté à la prochaine
|
||
re-vérification DB (fréquence bornée ~60 s, cache mémoire mono-instance) ; au pire ~1 minute
|
||
de grâce, jamais « plusieurs jours ».
|
||
|
||
### 21.8 « Mon compte » (`/Account`)
|
||
|
||
- Tout utilisateur authentifié peut changer **son propre** mot de passe :
|
||
`mot de passe actuel` (vérifié réellement) + `nouveau` + `confirmation`. En cas de mot de passe
|
||
actuel faux → refus **sans** modifier le hash.
|
||
- Les opérateurs bootstrap (configuration) ne peuvent pas changer leur mot de passe ici.
|
||
|
||
---
|
||
|
||
## 22. Bootstrap du premier Admin Production (T23)
|
||
|
||
Production démarre **sans** utilisateur DB. Conserver la possibilité de configurer
|
||
temporairement un opérateur bootstrap (`DiagnosticsAuth:Operators`) pour créer le premier Admin DB.
|
||
|
||
### 22.1 Générer le hash bootstrap (hors ligne, pas d'endpoint Web)
|
||
|
||
Outil console dédié (jamais un endpoint Web anonyme) :
|
||
|
||
```
|
||
dotnet run --project tools/Omika.DiagnosticHashTool -- "<mot-de-passe-bootstrap>"
|
||
# ou, pour éviter de laisser le mot de passe dans l'historique du shell :
|
||
dotnet run --project tools/Omika.DiagnosticHashTool -- --stdin
|
||
```
|
||
|
||
> ⚠️ Le **mot de passe** bootstrap ne doit **jamais** être dans Git, dans le rapport, ni dans un
|
||
> `appsettings` versionné. Seul le **hash** est placé dans la configuration / le secret store
|
||
> Production.
|
||
|
||
### 22.2 Procédure premier déploiement (12 étapes)
|
||
|
||
1. Déployer `Omika.Diagnostics.Web` (services + reverse proxy HTTPS, cf. §3-§5).
|
||
2. Configurer **temporairement** l'opérateur bootstrap Admin (hash seulement) :
|
||
`DiagnosticsAuth__Operators__0__Username` / `...__PasswordHash` / `...__Roles__0=Admin`.
|
||
3. Démarrer le service `OmikaDiagnosticsWeb`.
|
||
4. Se connecter avec l'opérateur bootstrap.
|
||
5. Aller sur **`/Users`**.
|
||
6. Créer l'**Admin DB permanent** (username + mot de passe + rôle `Admin`).
|
||
7. Se **déconnecter**.
|
||
8. Tester le login avec l'**Admin DB** (plus le bootstrap).
|
||
9. **Retirer** l'opérateur bootstrap de la configuration (`DiagnosticsAuth:Operators = []`).
|
||
10. Redémarrer le service `OmikaDiagnosticsWeb`.
|
||
11. Confirmer que le **bootstrap est refusé** (login → « Identifiants invalides. »).
|
||
12. Confirmer que l'**Admin DB fonctionne** (Dashboard / Diagnostics / Clients / Users).
|
||
|
||
### 22.3 Installation Production neuve
|
||
|
||
Si PostgreSQL Diagnostics Production est créé **de zéro** : appliquer **`001 → 010`** dans l'ordre
|
||
(jamais uniquement les dernières). Si une installation existe déjà : appliquer **uniquement les
|
||
migrations manquantes**, dans l'ordre.
|