Consulente ICT ICT Consultant

Il Problema: L'IA e gli script di sistema "Allucinati"

Immagine realizzata con Gemini AI

Poter generare script PowerShell in pochi secondi chiedendo aiuto a strumenti di IA Generativa è un moltiplicatore di produttività per i sistemisti. Il lato oscuro? Senza le giuste direttive, un LLM (Large Language Model) produrrà codice insicuro, scriverà credenziali in chiaro, o peggio, allucinerà cmdlet distruttivi senza inserire alcun blocco di gestione degli errori.

La Soluzione: Prompt Engineering per Amministratori di Sistema

L'output di un'IA è buono quanto le restrizioni imposte dal prompt (Guardrails). Un prompt ingegnerizzato per ambienti di produzione non si limita a "chiedere" codice, ma impone un framework architetturale rigoroso.

La struttura del Prompt SysAdmin

Evita il classico "scrivimi uno script per aggiungere utenti". Usa un approccio Agentic strutturato in blocchi:

1. System Persona: "Agisci come un Senior Windows System Administrator esperto di automazione sicura."
2. Task Execution: "Scrivi un modulo PowerShell per il provisioning di caselle Exchange."
3. Security Constraints (Cruciale): "NON usare mai testo in chiaro per le password. Implementa Get-Credential. Tutto il codice che agisce sul file system deve essere racchiuso in blocchi Try/Catch. Usa Start-Transcript per loggare ogni singola operazione."

Fissando i vincoli di sicurezza prima dell'elaborazione, l'LLM genererà script pronti per l'enterprise, azzerando le allucinazioni pericolose.

The Problem: AI and "Hallucinated" System Scripts

Image generated with Gemini AI

Being able to generate PowerShell scripts in seconds by asking Generative AI tools is a massive productivity multiplier for sysadmins. The dark side? Without proper directives, an LLM (Large Language Model) will produce insecure code, hardcode credentials in cleartext, or worse, hallucinate destructive cmdlets without including any error handling blocks.

The Solution: Prompt Engineering for System Administrators

The output of an AI is only as good as the restrictions imposed by the prompt (Guardrails). An engineered prompt for production environments doesn't just "ask" for code; it dictates a rigorous architectural framework.

The SysAdmin Prompt Structure

Avoid the classic "write me a script to add users." Use an Agentic approach structured in blocks:

1. System Persona: "Act as a Senior Windows System Administrator expert in secure automation."
2. Task Execution: "Write a PowerShell module for Exchange mailbox provisioning."
3. Security Constraints (Crucial): "NEVER use cleartext for passwords. Implement Get-Credential. All code interacting with the file system must be wrapped in Try/Catch blocks. Use Start-Transcript to log every single operation."

By defining security constraints prior to processing, the LLM will generate enterprise-ready scripts, eliminating dangerous hallucinations.

Il Problema: I Ransomware che cifrano il Disaster Recovery

Immagine realizzata con Gemini AI

Il più grande incubo di un sistemista non è un ransomware che blocca i dati di produzione, ma un ransomware "smart" che, prima di rivelarsi, cerca nel network le share SMB, i NAS e i repository di backup cifrandoli. Se il malware ha accesso in scrittura alla destinazione dei tuoi backup, l'intero piano di Disaster Recovery è annullato.

La Soluzione: Architettura di Backup Immutabile su Linux

Per sconfiggere questa minaccia serve l'immutabilità: un file salvato non deve poter essere modificato, sovrascritto o cancellato, nemmeno dall'utente root. Utilizzando gli attributi nativi dei file system Linux (ext4/xfs), possiamo creare un repository "antiproiettile" a costo zero.

Il comando magico: chattr

Una volta che la tua procedura di backup (es. rsync o un cron job) ha trasferito l'archivio sul server di deposito Linux, aggiungi una riga per bloccare il file a livello di kernel utilizzando il flag +i (immutable):

# Il file di backup viene reso inalterabile
sudo chattr +i /backup/repository/server_db_lunedì.tar.gz

Se un hacker ottiene l'accesso al server ed esegue uno script crittografico, il kernel respingerà l'operazione. Per permettere la rotazione dei vecchi backup, uno script blindato rimuoverà temporaneamente il flag (-i), cancellerà il file obsoleto e rimetterà il lucchetto sui nuovi arrivi.

The Problem: Ransomware Encrypting Disaster Recovery Plans

Image generated with Gemini AI

A sysadmin's biggest nightmare is not ransomware locking production data, but "smart" ransomware that, before revealing itself, searches the network for SMB shares, NAS devices, and backup repositories to encrypt them. If the malware has write access to your backup destination, your entire Disaster Recovery plan is nullified.

The Solution: Immutable Backup Architecture on Linux

To defeat this threat, you need immutability: a saved file must not be modifiable, overwritable, or deletable, not even by the root user. By using native Linux file system attributes (ext4/xfs), we can create a "bulletproof" repository at zero cost.

The Magic Command: chattr

Once your backup procedure (e.g., rsync or a cron job) has transferred the archive to the Linux storage server, append a line to lock the file at the kernel level using the +i (immutable) flag:

# The backup file is made unalterable
sudo chattr +i /backup/repository/server_db_monday.tar.gz

If a hacker gains access to the server and runs a cryptographic script, the kernel will reject the operation. To allow the rotation of old backups, a highly hardened script must temporarily remove the flag (-i), delete the obsolete file, and reapply the lock to the new arrivals.

The Problem: Endless Logs and GDPR Violations

Image generated with Gemini AI

Sysadmins often suffer from digital hoarding. The natural tendency is to indefinitely keep log files (proxy access, web servers, firewalls) "just in case we need them for a future investigation." However, retaining logs containing IP addresses and user-identifiable data without a predefined time limit exposes the company to severe fines for violating the GDPR data minimization principle.

The Solution: Automated Data Lifecycle via Logrotate

IT infrastructure must be engineered (Privacy by Design) to autonomously destroy data when the legal basis for its retention expires. On Linux machines, the definitive tool for this task is logrotate.

Configuring Automated Oblivion

By creating a specific rule within /etc/logrotate.d/, we can instruct the daemon to rotate logs monthly, compress them, and mathematically delete those older than the limits imposed by the legal department (e.g., 6 months).

# Configuration for Apache2 - 6-month retention
/var/log/apache2/*.log {
    monthly
    rotate 6
    compress
    delaycompress
    missingok
    notifempty
}

This way, on the seventh month, the oldest log is permanently purged from the file system, making the company automatically compliant with regulatory audits.