Lavorare per le PA - Passare da "Tabaccaio" a "Pentagono"

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, dove X è 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 dalla VM_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ò usare sudo 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ò usare sudo 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"