Gestione server remoto: accessi, prove e registri per un server mai toccato
Un server in un datacenter non si vede e non si tocca. Si governa con tre cose: accessi ordinati, prove ripetute e registri che qualcuno legge davvero.
Gestione server remoto: cosa cambia quando la macchina non è nella stanza accanto
Un server remoto si gestisce con tre strumenti: accessi nominativi e protetti, prove ripetute a scadenze fisse e registri conservati fuori dalla macchina. Senza la possibilità di guardarlo, vale solo ciò che è scritto, verificato o tracciato: il resto è una convinzione.
Chi ha un server in una stanza, ogni tanto lo guarda: una spia accesa, una ventola rumorosa. Nella gestione di un server remoto, in un datacenter o in cloud, nessun segnale del genere arriva da solo. La macchina sembra a posto finché un giorno il gestionale non risponde, e a quel punto bisogna scoprire in fretta chi ha le credenziali, dove sono le copie e cosa è stato cambiato per ultimo.
Come collegarsi a un server remoto in modo che regga nel tempo
Su un server Linux il canale normale è SSH. Su Windows Server si usa il desktop remoto, che però non andrebbe esposto direttamente su Internet. Collegarsi è facile. Collegarsi bene richiede qualche scelta.
- Chiavi al posto delle password. Con SSH l'accesso a chiave toglie di mezzo i tentativi a indovinare la password, che chi guarda i registri di un server raggiungibile da Internet vede comparire di continuo. Quando si disattiva l'accesso con password, si tiene aperta una seconda sessione già collegata: se la configurazione è sbagliata, non ci si chiude fuori.
- Un account per persona. Se tre tecnici usano lo stesso utente, nei registri si legge «admin» e basta. E quando uno di loro lascia l'incarico, non si può revocare solo il suo accesso.
- Passare da una VPN. L'amministrazione del server dovrebbe essere raggiungibile solo dall'interno di una VPN, o da indirizzi autorizzati dal firewall, non da qualunque connessione.
- Privilegi minimi. Si entra con un utente normale e si ottengono i permessi amministrativi solo per il comando che serve.
Una scelta che consiglio senza esitare: vietare l'accesso SSH diretto come root. Si fa con una riga di configurazione e si toglie il bersaglio più ovvio, quello che chiunque provi a indovinare per primo.
Ne manca una, che si scopre sempre tardi: la console di emergenza messa a disposizione dal fornitore del datacenter o del cloud. Serve quando un errore di rete o di firewall chiude fuori anche voi. Provate ora a entrarci, e annotate dove sono le credenziali. Provarci mentre il server è irraggiungibile è il modo peggiore di scoprire che nessuno le ha.
Come accedere da remoto al pc, e perché con un server è diverso
Chi cerca «come accedere al computer da remoto» di solito pensa a un programma di controllo remoto, con schermo condiviso e mouse che si muove. Per un server è raramente la strada giusta. Un server lavora senza che nessuno guardi uno schermo: si amministra da riga di comando, e ogni operazione lascia una traccia testuale.
Dove serve un'interfaccia grafica, si apre il canale solo per il tempo necessario e solo da rete autorizzata, e si chiude la sessione a fine lavoro. Il programma di controllo remoto lasciato sempre acceso, con una password condivisa da anni, è un classico dei sistemi cresciuti senza regia. Se ne avete uno, fate l'elenco di chi lo usa e di chi lo ha installato. Se nessuno sa rispondere, avete già trovato la prima cosa da sistemare. Dove è disponibile, aggiungete l'autenticazione a più fattori.
Le prove: come sapere che il server funziona senza vederlo
L'assenza di allarmi non dimostra che tutto vada bene. Può voler dire che il monitoraggio non controlla la cosa giusta. Per questo servono prove, cioè verifiche che qualcuno ripete a scadenze note.
Immaginate un disco che si riempie piano nell'arco di mesi. Nessun guasto, nessun avviso, poi una notte il database non riesce più a scrivere. Una soglia d'attenzione sulle risorse l'avrebbe segnalato con largo anticipo. Su come trovare cosa occupa lo spazio c'è un approfondimento: cosa fare quando un server è pieno.
Le prove minime, da concordare con chi gestisce il sistema:
- Disponibilità: i servizi rispondono dall'esterno, non solo dal server stesso.
- Risorse: disco, memoria e processore con soglie che avvisano prima del limite.
- Scadenze: certificati TLS, domini e licenze, che scadono sempre nel momento peggiore.
- Ripristino: una copia viene davvero rimessa in funzione in un ambiente di prova, con un esito scritto.
L'ultima è quella che si salta più volentieri. Il giorno in cui si prova a ripristinare, capita di scoprire che la copia c'è ma manca la cartella con i file caricati dagli utenti, oppure che nessuno ricorda la chiave per decifrarla. Meglio scoprirlo in una prova programmata. Il metodo è descritto in come verificare che i backup si possano ripristinare.
I registri nella gestione di un server remoto
I registri (log) sono i file in cui il sistema annota accessi, errori, riavvii, servizi che partono e si fermano. Su una macchina che non vedete mai sono l'unico testimone. Bastano poche abitudini perché siano utili.
Conservarli fuori dal server. Se la macchina viene compromessa o si rompe, i registri locali vanno con lei, ed erano proprio quelli che servivano. Inviarne una copia a un altro sistema è semplice e cambia molto.
Decidere per quanto tempo. Senza una regola, o il disco si riempie di file vecchi o i dati utili spariscono troppo presto. La rotazione dei registri è un'operazione ordinaria, tra quelle descritte in le operazioni ordinarie di gestione di un server Linux.
Tenere l'orologio allineato. Se server, firewall e applicazione segnano orari diversi, mettere in fila gli eventi di una notte diventa un lavoro da detective. La sincronizzazione dell'ora va verificata come tutto il resto.
Guardarli davvero. Un registro che nessuno legge occupa solo spazio. Si stabilisce quali eventi meritano un avviso: accessi falliti ripetuti, accessi da luoghi insoliti, servizi che si riavviano da soli.
Il registro delle modifiche: quello scritto da persone
Esiste un secondo registro. Ogni intervento (un aggiornamento, un cambio di configurazione, un permesso modificato) andrebbe annotato con data, autore, motivo e modo per tornare indietro. Sembra burocrazia finché due fornitori toccano la stessa macchina e il servizio smette di funzionare senza che nessuno sappia perché.
Non serve uno strumento complicato: un documento condiviso, accessibile all'azienda e non solo al fornitore, basta. Conta che account, dati e documentazione restino all'azienda: se dipendono da una sola persona, il rischio non è tecnico ma organizzativo. Da qui parte anche l'inventario di ciò che c'è da proteggere.
Se vi accorgete che accessi, prove e registri richiedono più attenzione continua di quanta ne possiate dedicare internamente, potete valutare una gestione dell'infrastruttura affidata a un team esterno, con perimetro e responsabilità scritti prima.
Da dove cominciare
Prendete un foglio e scrivete, per ogni server, tre cose: chi può entrare e con quale account, dove finiscono i registri, quando è stata fatta l'ultima prova di ripristino. Le caselle vuote sono il vostro elenco di lavoro, e conviene chiuderle partendo dall'ultima. Per un confronto sul metodo, anche solo per rivedere insieme quel foglio, Forgiant è disponibile.
Domande frequenti
Come ci si collega a un server remoto?
Su Linux si usa di norma SSH, preferibilmente con chiavi al posto delle password. Su Windows Server si usa il desktop remoto, ma solo attraverso una VPN o da indirizzi autorizzati dal firewall.
Perché ogni persona deve avere un account personale sul server?
Perché i registri possano dire chi ha fatto cosa. Con un account condiviso non si ricostruisce chi ha fatto una modifica, e quando una persona lascia l'incarico non si può revocare solo il suo accesso.
Ogni quanto vanno fatte le prove su un server remoto?
Dipende da quanto il servizio è critico, e la cadenza va concordata con chi gestisce il sistema. Il controllo di disponibilità e risorse è continuo, la prova di ripristino si pianifica a date fisse e se ne conserva l'esito scritto.