Il restore conserva pool, socket e master PHP-FPM e termina in modo mirato soltanto i processi preesistenti dell'ambiente. L'identità del processo viene verificata con UID, relazione con il master e informazioni che riducono il rischio di agire su un PID riutilizzato.
Il test documentato su due ambienti ha permesso di correlare una risposta 503 al reload condiviso e di verificare che il modello corretto mantenesse risposte HTTP valide sull'altro tenant. È un'evidenza concreta sullo scenario testato, non la promessa che nessun evento di rete o infrastruttura possa mai influire su altri servizi.
Sincronizzazioni del filesystem e reload graceful di Apache restano operazioni su componenti condivisi. Il progetto misura e riduce l'impatto dove può, mantenendo esplicito ciò che non è completamente isolato.
Fliclic conserva le decisioni, le prove e i limiti che hanno motivato le correzioni. Una vulnerabilità risolta non viene ripresentata come aperta senza una regressione concreta; un hardening futuro non viene anticipato come garanzia presente.
Questo metodo permette di concentrare il lavoro sui rischi reali: catene complete dei segreti, effetti condivisi dei workflow, controllo degli alberi mutabili, identità TLS e concorrenza tra operazioni. La sicurezza non è un'etichetta, ma la capacità di dimostrare quali confini vengono applicati e dove occorre ancora intervenire.
