Lavorare per le PA - Passare da "Tabaccaio" a "Pentagono"
TL;DR: Cliente che di punto in bianco ha dovuto re-implementare N politiche e procedure di sicurezza ed ha provocato solo M disagi, con X "work-around" su operazioni che facevamo quotidianamente e tranquillamente comunque con una buona base di hardening.
TS;WM: Accade spesso che un cliente vuole avere i nostri applicativi ospitati sui propri server piuttosto che sui nostri (per policy, decisioni interne, cazzate varie, ...)
Generalmente questo implica una procedura di accesso mediante una VPN (spesso con client Windows-only, porcod) e/o un IP autorizzato verso la/le macchina/e finale/i.
Con questo Cliente è stato così da anni, dove essenzialmente:
- Connessione VPN con singola utenza per tutti coloro che dovevano accedere alle VM
- Messa a disposizione di Y VM, dove ognuna di loro ha il nostro applicativo per un gruppo specifico del Cliente (A-Cliente, B-Cliente, ...)
- Ogni VM con credenziali univoche di accesso, accessibile solo ed esclusivamente dalla loro VPN
- Utenza SSH atta solo alla modifica delle cartelle e sottocartelle dove risiede la root dell'applicativo
- Utenza SQL che permetteva le connessioni in maniera diretta dalla VPN (senza fare l'idraulico SSH)
Chiariamo un punto:
Le politiche e le procedure di sicurezza necessitano di essere rivisitate, rivalutate e riadattate in periodi. Comprendo benissimo e sono il primo a mettere la sicurezza ai primi posti se non al primissimo, ma quando si fanno scelte del cazzo, che non hanno tenuto conto del nulla, che vanno solo a distruggere le normali procedure operative, che fanno solo perdere tempo per delle sciocchezze, per le attese, per le incomprensioni, per le incompetenze, ... non lo accetto ed è puramente s-n-e-r-v-a-n-t-e.
L'IT Security del Cliente ha pensato bene di stravolgere il mondo. Attualmente, per connetterci anche solo ad una di queste fottutissime VM, questo è l'iter:
- Ognuno di noi ha una propria utenza VPN (
domaingroup\UsernameX
, doveX
è un numero) - Connettersi alla login page di CyberArk (per la gestione PAM) mediante
UsernameX
ed una password (all'inizio verrà data una temporanea, dopo il primo login verrà richiesta di essere cambiata con una permanente a nostra scelta secondo determinati requisiti) - Sulla dashboard appaiono le VM che l'utenza
UsernameX
può accedere, cliccare su[Connect]
, scaricare ed aprire il file.rdp
di turno che fa millemila tunnel SSH dallaVM_CyberArk_Windows
alla VM di turno e finalmente accedervi, mediante shell o WinSCP - Dal file
.rdp
si ha accesso con un'utenza veramente scarna che non può usaresudo
e non può modificare file e cartelle dell'applicativo - Per poter compiere queste azioni, bisogna cambiare utenza, non accessibile da SSH. (Ergo: RDP --> utenza_1 non sudo -->
su - utenza_2
--> utenza_2 che può usaresudo
ma con pochi privilegi) - L'utenza SQL a disposizione è solo applicativa e "locale", ergo solo dalla VM al DB_Server, per richiederne una "diretta" (ergo VPN --> DB_Server) bisogna:
- Concordare la data per una videocall
- Compilare un documento insieme al reparto IT
- Attendere i DBA ed il team di IT Security per chiarire chi-cosa-come-quando-perché fare
- Forse fornirci questa utenza
- Altrimenti occorre fare dalla VM che, per grazia di Dio, permette di usare un client CLI o robe magiche mediante tunnel SSH (lo stesso team IT ci ha detto di fare tunnel SSH °_°)
Prima di tutto questo però, sono occorse:
- Videocall per capire un minimo della situazione nuova
- Creare un file di censimento dove ho dovuto scrivere tutte le operazioni che dobbiamo svolgere sulle macchine (comandi, cartelle, permessi, ... TUTTO)
- Attendere le risposte da parte dei vari team IT con un thread mail composto da 80 MESSAGGI
Tutto ciò per un ambiente totalmente di collaudo che non può comunicare con altri sistemi in produzione.
Non so se ho fatto intendere quant'è la frustrazione per questa situazione totalmente disorganizzata, ma è parecchia.
Siamo passati da:
"Ok mi connetto alla VPN, tempo 5 minuti e faccio X"
a:
"Cristo Dio sono passati 10 minuti e sto ancora al login della VM"