Dire che una piattaforma “è sicura” non spiega quali rischi affronta, quali controlli applica o dove restano limiti. Fliclic descrive invece i confini che costruisce: chi può accedere ai file, quale processo esegue PHP, a quale database appartengono le credenziali, quanto spazio può usare un ambiente e come un'operazione amministrativa evita di fidarsi di percorsi modificabili dal tenant.
Questi livelli lavorano insieme. Un permesso filesystem non corregge un workflow root progettato male; un pool PHP dedicato non sostituisce una quota kernel; TLS senza verifica d'identità completa non garantisce la stessa proprietà di una connessione autenticata end-to-end.
Ogni ambiente dispone di un utente Linux e di un gruppo dedicati. I processi PHP applicativi vengono eseguiti con l'identità del tenant, i file sono ricondotti a quell'identità e le directory condivise con il web server hanno permessi definiti per funzione.
Questa separazione riduce la possibilità che un'applicazione acceda direttamente ai contenuti di un altro ambiente. Non equivale a una virtualizzazione completa: più tenant condividono kernel, web server e master PHP-FPM della stessa versione. Per questo identità e permessi devono essere affiancati da controlli sul runtime e sulle operazioni amministrative.
I database sono associati al servizio e al nodo corretto, con account dedicati allo schema. I workflow di creazione, duplicazione, eliminazione e restore verificano identità e relazioni prima di operare.
Il gate web per l'amministrazione del database controlla dominio, indirizzo autorizzato, stato del servizio e presenza di un database attivo appartenente all'ambiente. Le query usano parametri e un esito incerto porta al rifiuto.
Il gate non sostituisce le credenziali MySQL e non prova da solo che l'intera applicazione centrale sia priva di errori. La separazione ulteriore tra le credenziali usate per le verifiche di accesso e quelle necessarie alle automazioni del nodo resta un'area di hardening: non viene presentata come già completata.
