Nameserver autorevoli
La zona è distribuita su quattro nameserver autorevoli, separati per rete e dominio e raggiungibili tramite IPv4 e IPv6. La delega del dominio padre corrisponde ai nameserver dichiarati dalla zona.
Site engineering
Come è costruito il sito www.openmilanese.it.
Un sito statico progettato con gli stessi principi applicati alle infrastrutture di produzione: semplicità, separazione delle responsabilità, sicurezza per impostazione predefinita e possibilità di verifica e rollback.
Obiettivo: pubblicare contenuti professionali senza introdurre componenti dinamici lato server, tracciamento nel browser o dipendenze esterne non necessarie.
Primo livello pubblico
La pubblicazione comincia prima del server web.
Prima che un browser possa negoziare TLS o richiedere una pagina, il dominio deve essere correttamente delegato, risolto in modo affidabile e protetto lungo la catena DNS. Dominio e DNS costituiscono quindi il primo livello dell’architettura pubblica del sito.
DNSSEC lungo la catena
Il record DS nel dominio padre collega crittograficamente la delega alle chiavi della zona. I resolver validanti possono così verificare autenticità e integrità delle risposte DNS senza confondere questa protezione con cifratura o riservatezza.
Pubblicazione IPv4 e IPv6
Il dominio e il servizio web sono pubblicati tramite record A e AAAA. I client compatibili possono raggiungere direttamente il sito su IPv6, mantenendo IPv4 per l’interoperabilità con le reti che non dispongono ancora di connettività IPv6 completa.
Emissione dei certificati controllata
I record CAA limitano alle Certification Authority autorizzate l’emissione di certificati ordinari e wildcard per il dominio. Un contatto dedicato riceve eventuali segnalazioni relative a richieste non conformi.
Autenticazione della posta
Microsoft 365 gestisce la ricezione. SPF limita i mittenti autorizzati, DKIM firma i messaggi e DMARC richiede allineamento rigoroso con policy di rifiuto, inviando i rapporti a un indirizzo dedicato.
DNS come componente infrastrutturale
Deleghe, firme DNSSEC, record applicativi, autorizzazioni CAA e autenticazione della posta devono restare coerenti con i servizi pubblicati. Migrazioni e dismissioni vengono quindi gestite considerando propagazione, dipendenze e ripristino.
Non vengono utilizzati record wildcard: ogni hostname pubblico deve essere definito intenzionalmente nella zona. Il servizio autorevole risponde su UDP e TCP e non espone trasferimenti pubblici della zona o risoluzione ricorsiva.
Principi progettuali
Semplice non significa improvvisato.
La riduzione dei componenti è una scelta architetturale. Ogni elemento mantenuto deve avere uno scopo chiaro, un comportamento osservabile e una procedura di sostituzione o rollback.
Meno componenti esposti
Nessun CMS, database, runtime applicativo o pannello amministrativo pubblico. Il sito serve soltanto risorse statiche necessarie alla consultazione.
Privacy per progettazione
Nessun cookie, sistema pubblicitario, font remoto o analytics eseguito nel browser. Le pagine non richiedono account e non raccolgono dati tramite form.
URL e comportamento espliciti
Canonical, hreflang, redirect permanenti, pagina 404 e cache policy sono definiti e verificati, evitando dipendenze da comportamenti impliciti del web server.
Rilasci ripetibili e reversibili
Ogni pacchetto dichiara una versione, include checksum, script di deploy e controlli post-pubblicazione. Prima della sostituzione viene creato un backup timestampato.
Separazione delle responsabilità
Ogni policy nel punto corretto.
Il frontend e il backend non duplicano indiscriminatamente le stesse funzioni. La configurazione riflette il percorso reale della richiesta.
- HAProxy, frontend pubblico
- Terminazione TLS, pubblicazione HTTPS, HSTS, selezione del backend e gestione del confine esposto a Internet.
- Apache, backend HTTP
- DocumentRoot, redirect canonici assoluti, pagina di errore, header di sicurezza relativi ai contenuti, compressione e cache policy.
- Contenuti statici
- Semantica HTML, accessibilità, metadati SEO, dati strutturati, collegamenti linguistici e riferimenti ad asset locali versionati.
- Processo di rilascio
- Backup, sincronizzazione atomica del contenuto, permessi, verifica della configurazione Apache e test end-to-end sugli URL pubblici.
Apache riceve HTTP dal proxy. Per questo i redirect che devono essere pubblicamente HTTPS utilizzano destinazioni assolute e non dipendono dallo schema osservato sulla connessione backend.
Sicurezza HTTP
Difese coerenti con un sito statico.
Le policy riducono capacità non necessarie del browser e rendono esplicite le origini autorizzate. Non sostituiscono patching e hardening, ma completano il modello di pubblicazione.
Content Security Policy
Risorse limitate all’origine del sito; framing, oggetti, form, connessioni applicative, media e worker non necessari sono disabilitati.
Policy del browser
nosniff, referrer limitato, divieto di framing, isolamento cross-origin e disabilitazione delle funzionalità non usate tramite Permissions Policy.
Trasporto sul frontend
HTTPS e HSTS sono gestiti da HAProxy, che costituisce il punto di terminazione TLS. Il backend non presenta certificati al client pubblico.
Canale di segnalazione
Il percorso standard /.well-known/security.txt pubblica un contatto, una policy e una data di scadenza verificabile.
Prestazioni e cache
Contenuto aggiornabile, asset conservabili.
Le pagine HTML devono poter cambiare rapidamente; gli asset immutabili possono invece essere conservati a lungo dal browser.
Rivalidazione immediata
Le pagine HTML possono essere memorizzate dal browser, ma devono essere rivalidate prima di ogni riutilizzo. Navigazione, metadati e contenuti aggiornati diventano quindi disponibili senza attendere scadenze lunghe.
Cache-Control: no-cache, max-age=0, must-revalidateNomi versionati e cache annuale
CSS, JavaScript e immagini principali includono una data nel nome. Quando il contenuto cambia, cambia anche l’URL; quello precedente resta realmente immutabile.
site.20260803.css · site.20260803.js · lab.20260801.css → max-age=31536000, immutableSEO tecnica
Indicizzazione basata su URL canonici.
Le versioni italiana e inglese sono collegate in modo simmetrico e la sitemap espone esclusivamente le destinazioni che devono essere indicizzate.
- Canonical assoluto per ogni pagina indicizzabile.
hreflangitaliano, inglese ex-default.- Sitemap XML con sole pagine canoniche e data di modifica.
- Dati strutturati per sito, profilo, persona, articolo e breadcrumb.
- Open Graph e Twitter Card con immagine locale.
- Redirect HTTP 301 per gli URL di compatibilità.
Pubblicazione
Un rilascio è una sequenza verificabile.
Il pacchetto non contiene soltanto i file pubblici: include gli strumenti necessari a installare, controllare e, se necessario, ripristinare la versione precedente.
- SorgentiContenuti e configurazione mantenuti nello stesso pacchetto.
- VersioneNumero di release e nomi degli asset aggiornati.
- ChecksumSHA-256 dei file distribuiti per verificarne l’integrità.
- DeployBackup, sincronizzazione, permessi e configurazione Apache.
- VerificaStato HTTP, redirect, canonical, header, cache e contenuti attesi.
./verify.sh https://www.openmilanese.it
Privacy essenziale
Ciò che non serve non viene raccolto.
La scelta di un sito statico elimina alla radice molte categorie di trattamento e riduce il numero di soggetti e servizi coinvolti nella consultazione. I normali log tecnici del servizio e le email inviate volontariamente sono descritti nell’informativa dedicata.
Leggi l’informativa privacy →- Nessun cookie tecnico o di profilazione impostato dal sito.
- Nessun Web Storage o identificatore persistente nel browser.
- Nessun account, login o area personale.
- Nessun form web o database di contatti.
- Nessun font, CDN o script caricato da terze parti.
- Nessun analytics eseguito nel browser.
- Nessun contenuto pubblicitario o sistema di remarketing.
Security reporting
Segnalazioni di sicurezza
Vulnerabilità, malfunzionamenti o comportamenti anomali del sito possono essere segnalati a webmaster@openmilanese.it. Phishing, spam, impersonificazione o altri abusi riconducibili al dominio possono essere segnalati a abuse@openmilanese.it. Entrambi i contatti sono pubblicati nel file standard security.txt.
Informazioni utili
- URL o risorsa interessata;
- descrizione del comportamento osservato;
- passaggi minimi per riprodurlo;
- impatto tecnico stimato;
- eventuali header o timestamp pertinenti.
Limiti della verifica
- non compromettere disponibilità o integrità del servizio;
- non accedere a dati oltre quanto strettamente necessario;
- non trasmettere credenziali o dati personali di terzi;
- non eseguire attività distruttive o persistenti;
- non presumere ricompense o riconoscimenti pubblici.
Questa pagina descrive il canale di contatto per la sicurezza del sito personale www.openmilanese.it; non costituisce un programma bug bounty né una promessa di tempi di risposta.