Paniere domande

✅ B. Il principio del minimo privilegio impone accessi giustificati, temporanei e tracciati. Richiedere motivazione documentata protegge il dirigente, il consulente e l'ente. L'accesso temporaneo con log è un compromesso professionale. ❌ A: eseguire senza domande viola il principio del minimo privilegio e la policy di sicurezza. ❌ C: il rifiuto categorico senza dialogo è inappropriato. ❌ D: avvisare il consulente non sostituisce la corretta procedura di autorizzazione.

✅ B. Password in chiaro nei log è una vulnerabilità critica. La segnalazione al responsabile della sicurezza è immediata. La remediation include: correggere il codice (mai loggare credenziali), bonificare i log esistenti (con accesso controllato), valutare se è avvenuto un data breach GDPR. ❌ A: eliminare i log senza valutazione potrebbe distruggere prove di un incidente. ❌ C: l'informativa privacy non risolve il problema tecnico. ❌ D: aspettare di capire chi ha letto ritarda la remediation.

✅ C. I requisiti formali sono necessari ma non sufficienti: un servizio PA deve essere effettivamente usabile (art. 1 L. 4/2004, WCAG). Documentare in verbale tutela la PA e impone al fornitore una remediation formale. ❌ A: accettare un sistema inutilizzabile espone la PA a reclami e inefficienza. ❌ B: il rifiuto senza documentazione non produce azioni concrete. ❌ D: la segnalazione verbale non ha valore contrattuale.

✅ B. La ricezione accidentale non autorizza il trattamento. Azione corretta: segnalare l'errore al mittente (che può valutare il data breach), cancellare l'email, non accedere o trattare i dati ricevuti erroneamente. ❌ A: leggere il contenuto costituisce trattamento non autorizzato. ❌ C: trasferire i dati amplia la violazione. ❌ D: pubblicare internamente aggrava la violazione.

✅ B. Un componente EOL non riceve patch di sicurezza → rischio crescente nel tempo. La remediation pianificata (aggiornamento o sostituzione) è la risposta corretta, con misure compensative nel frattempo (WAF, isolamento, monitoraggio). ❌ A: «se funziona non toccare» non è accettabile per la sicurezza. ❌ C: la decisione tecnica spetta al team IT, non agli utenti finali. ❌ D: la migrazione completa in 30 giorni è spesso irrealistica e va pianificata.

✅ B. Il GDPR (art. 5, 15) permette l'accesso ai dati solo all'interessato o a chi ha delega/procura. Fornire dati di terzi a chi non ha titolo è una violazione. ❌ A: la credibilità non sostituisce il titolo giuridico. ❌ C: la risposta non dipende dal superiore ma dalla norma. ❌ D: anche informazioni parziali potrebbero violare la privacy se riferite a terzi identificabili.

✅ B. Un deploy senza rollback verificato è un rischio operativo inaccettabile per sistemi produttivi. Il test in staging è obbligatorio. Se non c'è tempo, si posticipa. ❌ A: «improvvisare» un rollback durante un incidente è la ricetta per un downtime prolungato. ❌ C: il fornitore non può garantire il rollback senza averlo testato. ❌ D: il canary deployment riduce il rischio ma non sostituisce la procedura di rollback documentata e testata.

✅ C. L. 241/1990 e GDPR coesistono: l'accesso agli atti va bilanciato con la privacy dei terzi. La PA oscura (o nega) i dati dei terzi che non sono strettamente necessari per la tutela del richiedente. ❌ A: l'accesso non è assoluto — le eccezioni includono la privacy di terzi. ❌ B: il rigetto totale è sproporzionato se i dati del richiedente sono accessibili. ❌ D: il Garante non decide le singole richieste di accesso agli atti.

✅ B. Il debito tecnico non gestito aumenta i costi futuri in modo non lineare. La soluzione pragmatica è dedicare una quota fissa dello sprint alla riduzione del debito (refactoring, test, documentazione) e rendere visibile il rischio al management con metriche concrete. ❌ A: ignorare il debito porta a sistemi sempre più fragili e costosi. ❌ C: il big rewrite è raramente la soluzione (spesso genera nuovo debito). ❌ D: il personale aggiuntivo non riduce il debito senza una strategia di prioritizzazione.

✅ B. Usare dati reali in ambiente di test viola il GDPR: i dati sono raccolti per una finalità (il servizio) non compatibile con il test. La soluzione corretta è la generazione di dati sintetici o la pseudonimizzazione/anonimizzazione robusta. ❌ A: «cancellare dopo» non risolve il problema durante il test (accessi non autorizzati, log). ❌ C: il mascheramento nell'UI non protegge i dati nel DB di test. ❌ D: il consenso non sarebbe sufficiente: la finalità test non è compatibile con quella originale.

✅ C. Il conflitto di priorità va gestito in modo trasparente: comunicare a tutti gli stakeholder, far emergere la priorità (che è una decisione di business, non tecnica) e concordare l'ordine. ❌ A: lavorare in parallelo su task che richiedono focus divide la qualità. ❌ B: FIFO senza comunicazione lascia i manager senza visibilità sui ritardi. ❌ D: la gerarchia formale non è sempre il criterio giusto per la priorità operativa.

✅ C. Una stima senza requisiti è fiction. Comunicarlo chiaramente e proporre un mini-analisi per produrre una stima fondata è la risposta professionale. ❌ A: la stima generosa crea false aspettative e spreco. ❌ B: una stima rapida non fondata verrà presa come impegno e causerà problemi. ❌ D: dichiarare l'impossibilità totale non è costruttivo — l'analisi di 1-2 giorni è una proposta concreta.

✅ B. Il rallentamento progressivo è un segnale da analizzare proattivamente (approccio SRE/ITIL: problem management, non solo incident). Diagnosticare la causa radice prima del punto di rottura evita l'indisponibilità. ❌ A: aspettare il crash è reattivo e costoso. ❌ C: aggiungere risorse senza diagnosi può mascherare il problema senza risolverlo. ❌ D: aspettare le segnalazioni degli utenti è troppo tardivo e danneggia la fiducia.

✅ B. La «risoluzione» del fornitore deve essere verificata con test concreti. Le segnalazioni degli utenti sono prove da documentare e riportare al fornitore con evidenze (screenshot, log, video). ❌ A: chiudere il ticket basandosi solo sulla dichiarazione del fornitore viola la verifica di qualità. ❌ C: verificare il lato utente è corretto MA non sostituisce la verifica tecnica. ❌ D: aspettare è inaccettabile se gli utenti sono impattati.

✅ B. Il funzionario proattivo segnala le lacune (ownership collettiva della qualità) e propone soluzioni. L'autorizzazione formale tutela il dipendente e garantisce visibilità. ❌ A: l'inerzia di fronte a un rischio noto è irresponsabile. ❌ C: agire senza comunicare impedisce al management di avere visibilità e prendersi responsabilità. ❌ D: aspettare l'incidente è il peggio scenario (danno reale + «avevi notato il rischio e non hai detto nulla?»).

Un allegato inatteso da mittente sconosciuto con urgenza fittizia è un classico phishing. Procedura: NON aprire l'allegato, segnalare al referente sicurezza/CERT interno. Eliminare senza segnalare non protegge l'organizzazione. Rispondere al mittente conferma l'account attivo.

Le credenziali hardcoded sono vulnerabilità critica (OWASP A07). Priorità: informare il responsabile, rimuovere URGENTEMENTE, sostituire con secrets manager, verificare se già esposte in git history o repository pubblici.

In caso di data breach con rischio per gli interessati: 1) notificare al Garante entro 72h, 2) valutare notifica agli interessati se rischio elevato, 3) attivare incident response, 4) documentare. La notifica è obbligatoria, non discrezionale.

La valutazione corretta include: interoperabilità (art. 68-69 CAD), formati aperti, accessibilità WCAG 2.1 AA (L. 4/2004), sicurezza, portabilità dati (no vendor lock-in), conformità GDPR, costo totale di proprietà.