DevOps Conf 2024 - Roma - 10 mag 2024
https://devopsconf.dotnetdev.it
Gli strumenti che usiamo per lo sviluppo e il rilascio sono essenziali per controllare i processi in uso e garantire che soddisfino requisiti aziendali, legali, e regolamentari.
In questa sessione illustrerò come passare da norme (policies) astratte a implementationi su piattaforme come Azure DevOps o GitHub delle stesse così da poter prevenire prima e verificare poi il corretto svolgimento delle operazioni. E diventare amici del direttore Rischi e Audit.
Come implementare la governance nella vostra piattaforma e lavorare felici senza l'audit tra i piedi
1.
2. Implementatori (engineer, sviluppatori, DevOps, SRE)
Teorici (Architetti, Principal)
Pianificatori (Project Manager, Manager, Principal)
A quale categoria appartenete?
3. I nostri problemi
● 1500 Licenze Visual Studio
● 100 Teams
● 1350 Applicazioni
● 10 TB in Azure DevOps Databases
● 4000 Git repositories
● 5000 Azure DevOps Pipelines
● 1200 Octopus Deploy Projects
● 1300 Octopus Deploy Tentacles
● Diecine di milioni di righe di codice
● Escluso il mainframe
● Migrazione a Services: 6 mesi, 50 script per 3500 righe
● HIPPA, CCPA, GDPR-UK
● 7 anni di conservazione
giuliovdev@hotmail.com
@giulio_vian
4. Definizione
● IT governance (ITG) is defined as the processes that ensure the effective and efficient use of IT in
enabling an organization to achieve its goals. IT demand governance (ITDG—what IT should work on)
[…omiss…]. IT supply-side governance (ITSG—how IT should do what it does) is concerned with
ensuring that the IT organization operates in an effective, efficient and compliant fashion, and it is
primarily a CIO responsibility.
— Gartner Information Technology Glossary
● Sicurezza
○ ISO 27001 (Information Security)
○ NIS2 (Network and Information Security Directive)
○ DORA (Digital Operational Resilience Act)
● Privacy
○ GDPR (General Data Protection Regulation)
○ CCPA (California Consumer Privacy Act)
○ HIPAA (Health Insurance Portability and Accountability Act)
● Garanzie
○ PCI DSS (Payment Card Industry Data Security Standard)
○ Basilea II & III
○ SOX (Sarbanes–Oxley Act)
13. Esempio di Actions Workflow
$auditResponse = curl --silent --header "Authorization:
Bearer ${env:MY_TOKEN}" --header "Accept:
application/vnd.github+json" --header "X-GitHub-Api-
Version: 2022-11-28" --request GET --url
"https://api.github.com/${env:ENTERPRISE_ORGANIZATION_FILTER
}/audit-
log?phrase=operation:create+action:repo+created:>=${cutoverD
ate}" | ConvertFrom-Json
$violations = $auditResponse | where { $_.action -eq
'repo.create' } | where { $_.repo -notmatch
$env:VALID_REPONAME_REGEX } | select
external_identity_username,org,repo,created_at
14. Esempio di notifica
Si lascia al lettore il facile
compito di inviare una mail con
allegato all’indirizzo aziendale,
in quanto di semplice soluzione
15. Quale toolchain fu usata
● Una SBOM è impraticabile
● DYI
● Per Hosted Agents/Runners
○ ImageOS ubuntu22 / win22
○ ImageVersion 20240407.1.0
○ https://github.com/actions/runner-images/releases
Foto: Dave & Margie Hill Kleerup
16. Confidenza
↑ CERTO
firma crittografica storicizzata
con chiavi multiple
↑ FIDUCIA
registrazioni alterabili da un
amministratore
↓ DEBOLE
registrazioni facilmente alterabili
da chiunque abbia accesso
↓ NESSUNA
18. Policies tipiche per SDLC
● No a vulnerabilità critiche o di grado elevato
● 100% dei test eseguiti con successo
● No a segnalazioni di qualità del codice di grado elevato
● Esame di sicurezza SAST / SCA / DAST non antecedente i tre giorni al rilascio
● Test di performance entro un margine del 20% dall’obiettivo
● Codice rivisto da una persona diversa dall’autore
● Separazione delle responsabilità
○ Approvazione al rilascio da persona diversa dall’autore
○ Separation of Duties
19. Policies “esterne” al SDLC
● Architetturali
○ Applicazioni esposte ad Internet devono usare XYZ per l’autenticazione
● Configurazione
○ La scadenza dei certificati SSL non può essere superiore all’anno
20. Violazioni permesse
● Situazioni d’emergenza dove si permette una temporanea inosservanza delle regole
● Per ogni policy deve essere possible registrare la violazione
○ Chi l’ha autorizzata, quando, perché
21. In sintesi
Ogni regola (policy) ha la funzione di limitare i rischi
Difficile farlo senza intaccare la velocità
e la semplicità operativa
Cardini nella prevenzione e nel riconoscimento
Chiaramente una semplificazione perché:
ci troviamo di fronte ad un grafo diretto con cicli
manca il flusso in ingress
Analogia della condotta:
Il flusso è incanalato in tubi (governance)
Controllato da valvole
Serbatoi di accumulo
Punti di distribuzione
Minimizzare le perdite (shift-left)
Scroll Fragment of The Odyssey (Roman, fr Egypt, 100-1 BC). Papyrus. A fragment of Book 10, ll. 397-404 (in the palace of Circe)