534 lines
22 KiB
Markdown
534 lines
22 KiB
Markdown
# Prompt: NIS2 Agile — Big Simulation (10 Aziende, Copertura Totale)
|
||
|
||
## Obiettivo
|
||
|
||
Implementare `simulate-nis2-big.php` nella root del progetto.
|
||
Script SSE/CLI identico per struttura a `simulate-nis2.php` (stessi helper, stessa architettura),
|
||
ma con **10 aziende**, **1 consulente cross-org**, **1 big company ad alta criticità**
|
||
e copertura completa di **ogni endpoint API** della piattaforma NIS2 Agile.
|
||
|
||
Il simulatore deve:
|
||
- Usare gli stessi helper: `simLog()`, `simPhase()`, `simDone()`, `api()`, `ensureUser()`, `ensureOrg()`, `dbSeedUser()`, `autoResetDemo()`, `readEnvValue()`
|
||
- Supportare `NIS2_SSE=1` e `IS_CLI`/`IS_WEB` (stesso pattern)
|
||
- Auto-reset dei dati demo all'avvio (org_id > 4, email `%.demo%`)
|
||
- Completare in < 120 secondi su Hetzner (tutte le API su localhost)
|
||
- Raggiungere **✓200+ ✗0** al termine
|
||
|
||
Wrapper pubblico: `public/simulate-nis2-big.php` (identico a `public/simulate-nis2.php` ma con path `/../simulate-nis2-big.php`).
|
||
UI: aggiungere una card "BIG" in `simulate.html` che chiama `?sim=big`.
|
||
|
||
---
|
||
|
||
## Le 10 Aziende Demo
|
||
|
||
### A) InfraTech Italia S.p.A. — BIG COMPANY (slug: `infratech`)
|
||
La più grande e critica. Deve ricevere la copertura più ampia di scenari.
|
||
|
||
```php
|
||
'infratech' => [
|
||
'name' => 'InfraTech Italia S.p.A.',
|
||
'legal_form' => 'S.p.A.',
|
||
'vat_number' => '12345678901',
|
||
'ateco_code' => '61.10',
|
||
'ateco_desc' => 'Telecomunicazioni fisse',
|
||
'employees' => 5800,
|
||
'annual_turnover' => 820000000, // 820M€
|
||
'sector' => 'digital_infrastructure',
|
||
'nis2_type' => 'essential',
|
||
'city' => 'Milano',
|
||
'province' => 'MI',
|
||
'region' => 'Lombardia',
|
||
'complexity' => 'CRITICA',
|
||
'users' => [
|
||
['first'=>'Dott. Marco', 'last'=>'Visconti', 'email'=>'ceo@infratech-spa.demo', 'role'=>'org_admin'],
|
||
['first'=>'Ing. Serena', 'last'=>'Colombo', 'email'=>'ciso@infratech-spa.demo', 'role'=>'compliance_manager'],
|
||
['first'=>'Dott. Giorgio', 'last'=>'Ferri', 'email'=>'board@infratech-spa.demo', 'role'=>'board_member'],
|
||
['first'=>'Elena', 'last'=>'Mazzi', 'email'=>'auditor@infratech-spa.demo','role'=>'auditor'],
|
||
['first'=>'Luca', 'last'=>'Pavan', 'email'=>'staff@infratech-spa.demo', 'role'=>'employee'],
|
||
],
|
||
]
|
||
```
|
||
|
||
**Rischi (10 — tutti i livelli likelihood/impact da 2 a 5):**
|
||
- Ransomware su backbone nazionale — cyber, likelihood=5, impact=5, art.21.2.b
|
||
- Compromissione OT/SCADA nodi rete — cyber, likelihood=4, impact=5, art.21.2.b
|
||
- Attacco DDoS volumetrico su DNS primario — operational, likelihood=5, impact=4, art.21.2.c
|
||
- Zero-day su firewall perimetrale (CVE critica) — cyber, likelihood=3, impact=5, art.21.2.e
|
||
- Insider threat: dipendente con accesso privilegiato — human, likelihood=3, impact=4, art.21.2.i
|
||
- Supply chain software — fornitore firmware compromesso — supply_chain, likelihood=2, impact=5, art.21.2.d
|
||
- Data breach 2M utenti finali — compliance, likelihood=3, impact=5, art.21.2.b
|
||
- Failure Business Continuity — centro dati primario fuori — operational, likelihood=2, impact=5, art.21.2.c
|
||
- Phishing dirigenti (CEO Fraud / BEC) — human, likelihood=4, impact=3, art.21.2.g
|
||
- Furto certificati TLS wildcard — cyber, likelihood=2, impact=4, art.21.2.h
|
||
|
||
**Policy (6):** incident_response, access_control, cryptography, business_continuity, supply_chain_security, network_security
|
||
|
||
**Fornitori (6 — inclusi critical=1):**
|
||
- TelecomHW S.p.A. — hardware_vendor, risk=critical, critical=1
|
||
- SecurityOps S.r.l. — security_service, risk=high, critical=1
|
||
- CloudBackbone EU — cloud_provider, risk=critical, critical=1
|
||
- SoftwareCore AG — software_vendor, risk=high, critical=1
|
||
- LogisticIT S.r.l. — managed_service, risk=medium, critical=0
|
||
- CertSecurity S.r.l. — consulting, risk=low, critical=0
|
||
|
||
**Asset (5 — da creare con AssetController):**
|
||
- Backbone fibra ottica nazionale — type=network, criticality=critical
|
||
- Data Center Milano Nord — type=datacenter, criticality=critical
|
||
- Sistema OT/SCADA gestione rete — type=ot_system, criticality=critical
|
||
- Piattaforma DNS primaria e secondaria — type=server, criticality=high
|
||
- VPN corporate + MFA infrastruttura — type=software, criticality=high
|
||
|
||
**Training (2 corsi + assegnazioni a tutti i 5 utenti):**
|
||
- "NIS2 Sicurezza Infrastrutture Critiche" — mandatory, 8h
|
||
- "Incident Response & Art.23 Procedure" — mandatory, 4h
|
||
|
||
**Incidenti (3 — con piena timeline Art.23):**
|
||
1. **Ransomware backbone** (critical, tipo=cyber_attack):
|
||
- early_warning (24h), notification (72h), final_report (30d)
|
||
- Timeline: detection → containment → recovery → lessons_learned
|
||
- AI classify
|
||
2. **DDoS DNS** (high, tipo=availability):
|
||
- early_warning (24h), notification (72h)
|
||
- Timeline: detection → mitigation
|
||
3. **Insider threat accesso abusivo** (medium, tipo=unauthorized_access):
|
||
- Solo notification (72h) — scoperto dopo 48h
|
||
|
||
**NCR/CAPA (2 — da assessment gap):**
|
||
- NCR "Assenza MFA su sistemi OT" — severity=critical, da assessment, con CAPA (azione correttiva 30gg)
|
||
- NCR "Gestione patch firmware incompleta" — severity=high, con CAPA (azione correttiva 60gg)
|
||
|
||
**Whistleblowing (2):**
|
||
- Segnalazione anonima: "Accesso abusivo a dati cliente da parte di dipendente IT" — alta priorità
|
||
- Segnalazione anonima: "Procedure backup non rispettate su DC secondario"
|
||
|
||
**Normative ACK:** tutte le normative presenti (loop su GET /api/normative/pending → POST /{id}/ack)
|
||
|
||
**API Key:** creare api_key con scope `read:all` per integrazione esterna
|
||
**Webhook:** creare subscription su evento `incident.created`, testare delivery
|
||
|
||
---
|
||
|
||
### B) MedSalute Network S.p.A. (slug: `medsalute`)
|
||
```
|
||
sector=health, nis2_type=essential, employees=2200, turnover=95M€
|
||
city=Roma, 3 utenti (org_admin, compliance_manager, auditor)
|
||
Rischi: 6 (privacy pazienti, HIS fermo, supply chain LIS, phishing staff, IoT medici, GDPR breach)
|
||
Policy: 3 (data_protection, business_continuity, access_control)
|
||
Fornitori: 4 (LIS critico, HIS critico, cloud backup, device IoT)
|
||
Incidente: 1 — data breach cartelle cliniche (significant, Art.23 completo)
|
||
Whistleblowing: 1 — "Accesso cartelle di pazienti VIP da personale non autorizzato"
|
||
Training: 1 corso, assegnato a tutti gli utenti
|
||
```
|
||
|
||
### C) DistribuzionePlus S.p.A. (slug: `distribuzione`)
|
||
```
|
||
sector=energy, nis2_type=essential, employees=1400, turnover=210M€
|
||
city=Torino, 3 utenti (org_admin, compliance_manager, board_member)
|
||
Rischi: 6 (SCADA compromise, blackout selettivo, supply chain firmware, DDoS RTU, insider, physical breach)
|
||
Policy: 3 (incident_response, network_security, business_continuity)
|
||
Fornitori: 4 (SCADA vendor, telco primaria, backup provider, consulenza sicurezza)
|
||
Incidente: 1 — anomalia SCADA rilevata (critical, timeline 24h/72h)
|
||
Training: 1 corso mandatory
|
||
```
|
||
|
||
### D) BancaRegionale Digitale S.p.A. (slug: `bancaregionale`)
|
||
```
|
||
sector=banking, nis2_type=essential, employees=3100, turnover=180M€
|
||
city=Milano, 3 utenti (org_admin, compliance_manager, auditor)
|
||
Rischi: 6 (frode bonifici, credential stuffing, API banking compromise, SWIFT anomalia, ransomware core banking, DDoS app mobile)
|
||
Policy: 4 (incident_response, access_control, cryptography, fraud_prevention)
|
||
Fornitori: 4 (core banking, payment gateway, SOC esterno, cloud DR)
|
||
Incidente: 1 — tentativo frode bonifici (significant, Art.23 72h)
|
||
Training: 1 corso, assegnazioni a tutti
|
||
```
|
||
|
||
### E) AquaPura Servizi S.r.l. (slug: `aquapura`)
|
||
```
|
||
sector=drinking_water, nis2_type=essential, employees=380, turnover=28M€
|
||
city=Venezia, 2 utenti (org_admin, compliance_manager)
|
||
Rischi: 5 (compromissione impianto trattamento, SCADA acquedotto, DoS sistemi controllo, supply chain reagenti, physical intrusion)
|
||
Policy: 2 (incident_response, business_continuity)
|
||
Fornitori: 3 (SCADA vendor, laboratorio analisi, manutenzione impianti)
|
||
Nessun incidente (solo rischi e assessment)
|
||
Training: 1 corso
|
||
```
|
||
|
||
### F) LogisticaRapida S.r.l. (slug: `logistica`)
|
||
```
|
||
sector=transport, nis2_type=important, employees=620, turnover=45M€
|
||
city=Bologna, 2 utenti (org_admin, compliance_manager)
|
||
Rischi: 5 (GPS spoofing, fleet management compromise, ransomware TMS, supply chain carrier, API partner malicious)
|
||
Policy: 2 (incident_response, supply_chain_security)
|
||
Fornitori: 3 (TMS provider, GPS tracking, carrier network)
|
||
Training: 1 corso
|
||
```
|
||
|
||
### G) SmartCity Solutions S.r.l. (slug: `smartcity`) — PMI
|
||
```
|
||
sector=ict_services, nis2_type=important, employees=145, turnover=12M€
|
||
city=Firenze, 2 utenti (org_admin, compliance_manager)
|
||
Rischi: 4 (IoT smart city exploit, data lake breach, API pubblica abusata, supply chain sensori)
|
||
Policy: 2 (incident_response, data_protection)
|
||
Fornitori: 2 (IoT platform, cloud analytics)
|
||
Training: 1 corso
|
||
```
|
||
|
||
### H) EduDigital S.r.l. (slug: `edudigital`) — PMI voluntary
|
||
```
|
||
sector=ict_services, nis2_type=voluntary (voluntary_compliance=true), employees=80, turnover=6M€
|
||
city=Bologna, 2 utenti (org_admin, compliance_manager)
|
||
Rischi: 3 (breach dati studenti, piattaforma LMS down, phishing docenti)
|
||
Policy: 1 (data_protection)
|
||
Fornitori: 2 (LMS provider, cloud hosting)
|
||
Training: 1 corso
|
||
```
|
||
|
||
### I) AgriTech Innovazione S.r.l. (slug: `agritech`) — PMI voluntary
|
||
```
|
||
sector=food, nis2_type=voluntary (voluntary_compliance=true), employees=45, turnover=3.5M€
|
||
city=Verona, 2 utenti (org_admin, compliance_manager)
|
||
Rischi: 3 (sensori IoT campo compromessi, sistema ERP agricolo, supply chain tracciabilità)
|
||
Policy: 1 (incident_response)
|
||
Fornitori: 2 (IoT provider, ERP vendor)
|
||
Training: 1 corso
|
||
```
|
||
|
||
### J) ManufacturingPro S.p.A. (slug: `manufacturing`) — Manifatturiero
|
||
```
|
||
sector=manufacturing, nis2_type=important, employees=950, turnover=78M€
|
||
city=Brescia, 3 utenti (org_admin, compliance_manager, auditor)
|
||
Rischi: 5 (OT fabbrica compromessa, ERP SAP credential leak, supply chain componenti, ransomware produzione, GDPR lavoratori)
|
||
Policy: 3 (incident_response, access_control, business_continuity)
|
||
Fornitori: 4 (SAP hosting, OT vendor, logistica, certificazione)
|
||
Training: 1 corso
|
||
```
|
||
|
||
---
|
||
|
||
## Consulente Cross-Org
|
||
|
||
```php
|
||
'consultant' => [
|
||
'first' => 'Avv. Federica', 'last' => 'Montanari',
|
||
'email' => 'consultant@nis2agile-big.demo',
|
||
'role' => 'consultant',
|
||
]
|
||
```
|
||
|
||
Deve essere aggiunto come `consultant` a **tutte e 10 le organizzazioni** tramite `POST /api/organizations/{id}/invite`.
|
||
|
||
---
|
||
|
||
## Scenari / Fasi da Implementare
|
||
|
||
### FASE 0 — Auto-Reset + Health Check
|
||
- Chiama `autoResetDemo()` identico a `simulate-nis2.php`
|
||
- Health check API
|
||
|
||
### FASE 1 — Registrazione & Onboarding (10 aziende)
|
||
Per ogni azienda:
|
||
1. `dbSeedUser()` + login per ogni utente
|
||
2. `ensureOrg()` → crea organizzazione
|
||
3. `PUT /api/organizations/{id}` → aggiorna dati (employees, turnover, vat, ateco)
|
||
4. `POST /api/organizations/{id}/classify` → classifica NIS2 (sector, nis2_type, voluntary se applicable)
|
||
5. Aggiungi gli utenti extra (compliance_manager, auditor, board_member) via invite
|
||
|
||
Dopo tutte le aziende:
|
||
6. Crea e logga il consulente
|
||
7. `POST /api/organizations/{id}/invite` per tutte le 10 org → ruolo consultant
|
||
|
||
### FASE 2 — Gap Assessment 80 Domande (tutte le 10 aziende)
|
||
Per ogni azienda:
|
||
1. `POST /api/assessments/create`
|
||
2. `GET /api/assessments/{id}/questions` → ottieni le 80 domande
|
||
3. Rispondi alle 80 domande con valori realistici per settore:
|
||
- Big company (infratech): 40% implemented, 30% partial, 20% not_implemented, 10% not_applicable
|
||
- Essential medio: 30% implemented, 40% partial, 25% not_implemented, 5% not_applicable
|
||
- PMI voluntary: 20% implemented, 30% partial, 40% not_implemented, 10% not_applicable
|
||
4. `POST /api/assessments/{id}/complete`
|
||
5. `POST /api/assessments/{id}/ai-analyze` → chiamata AI (ok se rate-limited, skip con warn)
|
||
|
||
### FASE 3 — Risk Register (tutte le 10 aziende)
|
||
Per ogni azienda:
|
||
1. Crea tutti i rischi definiti (likelihood, impact, category, nis2_article)
|
||
2. Per infratech: `POST /api/risks/ai-suggest` → suggerimenti AI
|
||
3. Per i rischi critical/high: `POST /api/risks/{id}/treatments` → aggiungi treatment (mitigate)
|
||
4. `GET /api/risks/matrix` → verifica matrice
|
||
|
||
### FASE 4 — Policy (tutte le 10 aziende)
|
||
Per ogni azienda:
|
||
1. Per ogni policy: `POST /api/policies/create` (status=draft)
|
||
2. `POST /api/policies/{id}/approve` → approva
|
||
3. Per infratech: `POST /api/policies/ai-generate` → genera AI una policy aggiuntiva
|
||
|
||
### FASE 5 — Supply Chain (tutte le 10 aziende)
|
||
Per ogni azienda:
|
||
1. `POST /api/supply-chain/create` per ogni fornitore
|
||
2. `POST /api/supply-chain/{id}/assess` → valutazione sicurezza (security_score random 30-85)
|
||
3. `GET /api/supply-chain/risk-overview` → verifica panoramica rischi
|
||
|
||
### FASE 6 — Training (tutte le 10 aziende)
|
||
Per ogni azienda:
|
||
1. `POST /api/training/courses` → crea corso
|
||
2. `POST /api/training/assign` → assegna a tutti gli utenti dell'azienda
|
||
3. `GET /api/training/compliance-status` → verifica stato
|
||
|
||
### FASE 7 — Asset (tutte le 10 aziende + dettaglio infratech)
|
||
Per ogni azienda:
|
||
1. Crea almeno 2 asset (server/software/network)
|
||
Per infratech: crea tutti e 5 gli asset definiti con criticality=critical
|
||
|
||
### FASE 8 — Incidenti con Timeline Art.23 (aziende selezionate)
|
||
|
||
**InfraTech — Incidente 1 (Ransomware Backbone):**
|
||
```
|
||
POST /api/incidents/create → {type:'cyber_attack', severity:'critical', title:'Ransomware su backbone nazionale', affected_services:'Backbone fibra', estimated_users_affected:2000000}
|
||
POST /api/incidents/{id}/ai-classify
|
||
POST /api/incidents/{id}/timeline → {phase:'detection', notes:'Rilevato da SIEM alle 03:47'}
|
||
POST /api/incidents/{id}/early-warning → early_warning (24h obbligatoria — utenti>500, durata>4h, cyber)
|
||
POST /api/incidents/{id}/timeline → {phase:'containment', notes:'Isolamento segmenti compromessi'}
|
||
POST /api/incidents/{id}/notification → notification (72h)
|
||
POST /api/incidents/{id}/timeline → {phase:'recovery', notes:'Ripristino da backup cold standby'}
|
||
POST /api/incidents/{id}/final-report → final report (30d)
|
||
```
|
||
|
||
**InfraTech — Incidente 2 (DDoS DNS):**
|
||
```
|
||
POST create → {type:'availability', severity:'high', ...}
|
||
POST early-warning + notification
|
||
```
|
||
|
||
**InfraTech — Incidente 3 (Insider):**
|
||
```
|
||
POST create → {type:'unauthorized_access', severity:'medium', ...}
|
||
POST notification (solo 72h)
|
||
```
|
||
|
||
**MedSalute — Incidente Data Breach:**
|
||
```
|
||
POST create → {type:'data_breach', severity:'high', affected_users:15000}
|
||
POST ai-classify
|
||
POST early-warning + notification + final-report
|
||
```
|
||
|
||
**DistribuzionePlus — Incidente SCADA:**
|
||
```
|
||
POST create → {type:'availability', severity:'critical'}
|
||
POST early-warning + notification
|
||
```
|
||
|
||
**BancaRegionale — Incidente Frode:**
|
||
```
|
||
POST create → {type:'fraud', severity:'high'}
|
||
POST notification
|
||
```
|
||
|
||
### FASE 9 — NCR/CAPA (infratech + medsalute + manufacturing)
|
||
|
||
Per **infratech** (2 NCR):
|
||
```
|
||
POST /api/ncr/create → {title:'Assenza MFA su sistemi OT', severity:'critical', source:'assessment', assessment_id:{id}}
|
||
POST /api/ncr/{id}/capa → {description:'Implementazione MFA hardware entro 30gg', due_date:'+30d', responsible_email:'ciso@infratech-spa.demo'}
|
||
POST /api/ncr/create → {title:'Gestione patch firmware incompleta', severity:'high'}
|
||
POST /api/ncr/{id}/capa → {description:'Processo patch management OT', due_date:'+60d'}
|
||
```
|
||
|
||
Per **medsalute** (1 NCR):
|
||
```
|
||
POST /api/ncr/create → {title:'Log accessi cartelle cliniche incompleto', severity:'high'}
|
||
POST /api/ncr/{id}/capa → {due_date:'+45d'}
|
||
```
|
||
|
||
Per **manufacturing** (1 NCR):
|
||
```
|
||
POST /api/ncr/create → {title:'Segmentazione rete OT/IT assente', severity:'critical'}
|
||
POST /api/ncr/{id}/capa
|
||
```
|
||
|
||
### FASE 10 — Whistleblowing (infratech + medsalute)
|
||
|
||
**InfraTech — Segnalazione 1:**
|
||
```
|
||
POST /api/whistleblowing/submit → {anonymous:true, description:'Accesso abusivo dati cliente da dipendente IT reparto NOC', category:'data_breach'}
|
||
GET /api/whistleblowing/{id} con tracking_code
|
||
POST /api/whistleblowing/{id}/assign → assegna a compliance_manager
|
||
POST /api/whistleblowing/{id}/close → {resolution:'Indagine interna completata. Dipendente sanzionato.'}
|
||
```
|
||
|
||
**InfraTech — Segnalazione 2:**
|
||
```
|
||
POST /api/whistleblowing/submit → {anonymous:true, description:'Procedure backup DC secondario non rispettate da 3 mesi'}
|
||
POST /api/whistleblowing/{id}/assign
|
||
(lascia aperta — non chiudere, per testare stato 'in_progress')
|
||
```
|
||
|
||
**MedSalute — Segnalazione:**
|
||
```
|
||
POST /api/whistleblowing/submit → {anonymous:true, description:'Accesso cartelle pazienti VIP da personale non autorizzato', category:'unauthorized_access'}
|
||
POST /api/whistleblowing/{id}/assign + close
|
||
```
|
||
|
||
### FASE 11 — Audit Trail & Hash Chain (tutte le org)
|
||
```
|
||
GET /api/audit/logs?organization_id={id} per ogni org → verifica presenza log
|
||
POST /api/audit/export (infratech) → export certificato JSON con hash SHA-256
|
||
GET /api/audit/logs?organization_id={infratech_id}&limit=50 → verifica hash chain
|
||
```
|
||
|
||
Verifica che dopo tutti gli scenari, infratech abbia > 50 audit_log entries.
|
||
|
||
### FASE 12 — Controlli Compliance & Evidenze (infratech)
|
||
```
|
||
GET /api/audit/controls → lista tutti i controlli NIS2
|
||
PUT /api/audit/controls/{id} → aggiorna status=implemented per 5 controlli critici
|
||
POST /api/audit/evidence/upload → carica evidenza (base64 di un PDF simulato) per 2 controlli
|
||
GET /api/audit/report → report compliance
|
||
GET /api/audit/iso27001-mapping → mapping ISO 27001
|
||
GET /api/audit/executive-report → report esecutivo HTML
|
||
GET /api/audit/export → export CSV
|
||
```
|
||
|
||
### FASE 13 — Normative ACK (infratech + medsalute)
|
||
```
|
||
GET /api/normative/pending → lista aggiornamenti NIS2 da confermare
|
||
Per ogni normativa pending: POST /api/normative/{id}/ack → conferma lettura
|
||
GET /api/normative/stats → verifica stato
|
||
```
|
||
|
||
### FASE 14 — API Keys & Webhook (infratech)
|
||
```
|
||
POST /api/webhooks/api-keys → crea API key con scope read:all, nome 'Big Sim Integration Key'
|
||
GET /api/webhooks/api-keys → verifica creazione
|
||
|
||
POST /api/webhooks/subscriptions → crea subscription {event:'incident.created', url:'https://webhook.site/nis2-test', active:true}
|
||
POST /api/webhooks/subscriptions/{id}/test → testa delivery (ok anche se 4xx dal webhook.site)
|
||
GET /api/webhooks/deliveries → verifica log delivery
|
||
```
|
||
|
||
### FASE 15 — Services API (con API key infratech)
|
||
Usa l'API key creata nella FASE 14:
|
||
```
|
||
GET /api/services/status → health check con API key
|
||
GET /api/services/compliance-summary → riepilogo compliance
|
||
GET /api/services/risks-feed → feed rischi (JSON)
|
||
GET /api/services/incidents-feed → feed incidenti
|
||
GET /api/services/controls-status → stato controlli
|
||
GET /api/services/assets-critical → asset critici
|
||
GET /api/services/suppliers-risk → fornitori a rischio
|
||
GET /api/services/policies-approved → policy approvate
|
||
```
|
||
|
||
### FASE 16 — Dashboard & Report (infratech)
|
||
```
|
||
GET /api/dashboard/overview
|
||
GET /api/dashboard/compliance-score
|
||
GET /api/dashboard/upcoming-deadlines
|
||
GET /api/dashboard/recent-activity
|
||
GET /api/dashboard/risk-heatmap
|
||
GET /api/reports/executive-report → report HTML esecutivo
|
||
```
|
||
|
||
### FASE 17 — Feedback AI (consulente su infratech)
|
||
Con JWT del consulente + X-Organization-Id di infratech:
|
||
```
|
||
POST /api/feedback/submit → {tipo:'bug', priorita:'alta', descrizione:'Dashboard non mostra score per org con >5000 dipendenti', page_url:'/dashboard.html'}
|
||
GET /api/feedback/mine → verifica ai_risposta popolata
|
||
```
|
||
|
||
### FASE 18 — B2B Provisioning (SIM-06 equivalente)
|
||
```
|
||
POST /api/invites/create (con API key admin:licenses) → crea invite token
|
||
POST /api/services/provision → provisioning B2B con invite_token, crea org + user + api_key
|
||
```
|
||
|
||
---
|
||
|
||
## Struttura Contatori Attesi
|
||
|
||
Al termine della simulazione, il DB deve contenere (org_id > 4):
|
||
|
||
| Tabella | Min atteso |
|
||
|---------|-----------|
|
||
| organizations | 11 (10 + 1 B2B) |
|
||
| users | 30+ (utenti demo) |
|
||
| assessments | 10 |
|
||
| assessment_responses | 800 (80 × 10) |
|
||
| risks | 55+ (media 5-6 per org + 10 infratech) |
|
||
| risk_treatments | 15+ |
|
||
| incidents | 6+ |
|
||
| incident_timeline | 20+ |
|
||
| policies | 25+ |
|
||
| suppliers | 30+ |
|
||
| training_courses | 10+ |
|
||
| training_assignments | 30+ |
|
||
| assets | 25+ (5 infratech + 2 × 9 altre) |
|
||
| compliance_controls | aggiornati |
|
||
| non_conformities | 4 |
|
||
| capa_actions | 4 |
|
||
| whistleblowing_reports | 3 |
|
||
| audit_logs | 200+ |
|
||
| api_keys | 1+ |
|
||
| webhook_subscriptions | 1+ |
|
||
| feedback_reports | 1+ |
|
||
|
||
**Target step totali: ✓200+ ✗0 ⚠<5**
|
||
|
||
---
|
||
|
||
## Costanti da Definire
|
||
|
||
```php
|
||
define('SIM_VERSION', '2.0.0');
|
||
define('SIM_NAME', 'NIS2 Agile Big Simulation');
|
||
define('DEMO_PWD', 'NIS2Demo2026!'); // stessa password sim base
|
||
define('DEMO_EMAIL', getenv('NIS2_DEMO_EMAIL') ?: 'demo@nis2agile.it');
|
||
```
|
||
|
||
---
|
||
|
||
## Note Implementative
|
||
|
||
1. **Stesso pattern di `simulate-nis2.php`** — copia gli helper in testa al file, NON include il file base
|
||
2. **`autoResetDemo()` identica** — cancella org_id > 4 + rate limiter files
|
||
3. **`dbSeedUser()` identica** — INSERT ON DUPLICATE KEY UPDATE
|
||
4. **Ogni API call wrappata in `apiOk()`** — se fallisce → `warn()` non `fail()` (continua simulazione)
|
||
5. **Timeout curl = 30s** per ogni chiamata
|
||
6. **AI calls opzionali** — avvolte in try/catch, `warn()` se rate-limited (non bloccano)
|
||
7. **Loop COMPANIES** — stessa struttura `foreach ($COMPANIES as $slug => $comp)`
|
||
8. **State globale `$S`** — stesso schema: `$S['orgs'][$slug]`, `$S['users'][$email]`, `$S['stats']`
|
||
9. **Webhook test** — se delivery fallisce (es. webhook.site down) → `warn()` non `fail()`
|
||
10. **Fase 15 Services API** — usa `$apiKey` salvato dopo FASE 14, header `X-API-Key`
|
||
|
||
---
|
||
|
||
## File da Creare / Modificare
|
||
|
||
| File | Azione |
|
||
|------|--------|
|
||
| `simulate-nis2-big.php` | CREA — script principale (~1500 righe) |
|
||
| `public/simulate-nis2-big.php` | CREA — wrapper proc_open identico all'altro |
|
||
| `public/simulate.html` | MODIFICA — aggiungi card "BIG (10 aziende)" |
|
||
|
||
---
|
||
|
||
## Verifica Finale
|
||
|
||
Il simulatore deve stampare a fine run un riepilogo DB:
|
||
|
||
```
|
||
=== VERIFICA DB ===
|
||
✓ organizations: N (atteso ≥11)
|
||
✓ utenti demo: N (atteso ≥30)
|
||
✓ assessments: N (atteso =10)
|
||
✓ assessment_responses: N (atteso =800)
|
||
✓ rischi: N (atteso ≥55)
|
||
✓ incidenti: N (atteso ≥6)
|
||
✓ policy: N (atteso ≥25)
|
||
✓ fornitori: N (atteso ≥30)
|
||
✓ non_conformities: N (atteso ≥4)
|
||
✓ whistleblowing: N (atteso ≥3)
|
||
✓ audit_logs: N (atteso ≥200)
|
||
```
|
||
|
||
Se un contatore è sotto la soglia → `warn()` con dettaglio.
|