Lista dei controlli per la distribuzione

Internet è un ambiente ostile. Prima di distribuire il tuo progetto Django, dovresti prenderti del tempo per revisionare le tue configurazioni, tenendo a mente sicurezza, performance ed gestione operativa.

Django include molte caratteristiche di sicurezza. Alcune sono built-in e sempre abilitate. Altre sono opzionali perchè non sono sempre appropriate o perchè non sono pratiche in fase di sviluppo. Per esempio, forzare HTTPS può non andare bene per tutti i siti ed è molto poco pratico per lo sviluppo locale.

Le ottimizzazioni di performance sono un’altra categoria di tradeoff con la convenienza. Per esempio, il caching è utile in produzione, meno per lo sviluppo locale. Anche l’error reporting deve essere molto differente.

La seguente lista di controlli include configurazioni come:

  • devono essere configurate correttamente in Django affinché forniscano il livello di sicurezza atteso;
  • ci si aspetta che siano differenti per ogni ambiente;
  • abilita le funzionalità di sicurezza opzionali;
  • Abilita le ottimizzazioni per le prestazioni
  • fornisce le segnalazioni dell’errore.

Molte di queste impostazioni sono sensibili e dovrebbero essere trattate come confidenziali. Se stai rilasciando il codice sorgente del tuo progetto, una pratica comune è quella di pubblicare impostazioni adeguate per lo sviluppo ed usare moduli di impostazioni privati per la produzione.

Lancia manage.py check --deploy

Alcuni dei check descritti qui sotto possono essere automatizzati utilizzando l’opzione check --deploy. Assicurati di lanciarla sul file di impostazioni della produzione come descritto nella documentazione delle opzioni.

Configurazioni critiche

SECRET_KEY

La chiave segreta deve essere un valore casuale grande e deve essere tenuta segreta.

Assicurati che la chiave utilizzata in produzione non sia usata da altre parte ed evita di farne un commit verso il software di controllo dei sorgenti. Questo riduce il numero di vettori dai quali un attaccante potrebbe acquisire la chiave.

Invece di fare hardcoding della chiave segreta nelle tuo modulo di impostazioni, cosidera di caricarla da una variabile d’ambiente:

import os

SECRET_KEY = os.environ["SECRET_KEY"]

o da un file:

with open("/etc/secret_key.txt") as f:
    SECRET_KEY = f.read().strip()

Se stai utilizzando la rotazione delle chiavi per i segreti, puoi usare SECRET_KEY_FALLBACKS:

import os

SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
SECRET_KEY_FALLBACKS = [
    os.environ["OLD_SECRET_KEY"],
]

Assicurati che le vecchie chiavi siano rimosse prontamente da SECRET_KEY_FALLBACKS.

Changed in Django 4.1:

L’impostazione SECRET_KEY_FALLBACKS è stata aggiunta per supportare la rotazione delle chiavi per i segreti.

DEBUG

Non devi mai abilitare la modalità debug in produzione

Stai certamente sviluppando il tuo progetto con DEBUG = True, perchè abilita comode feature come i traceback completi nel browser.

Per un ambiente di produzione, tuttavia, è un’idea davvero cattiva, perchè espone molte informazioni sul progetto: stralci di codice sorgente, variabili locali, impostazioni, librerie utilizzate ecc…

Configurazione dipendente dall’ambiente

ALLOWED_HOSTS

Quando DEBUG = False, Django non funziona affatto senza un valore adatto di ALLOWED_HOSTS.

Questa impostazione è necessaria per proteggere il tuo sito da alcuni attacchi CSRF. Se usi una wildcard, devi fare la tua validazione dell’header HTTP Host o altrimenti assicurarti di non essere vulnerabile a questa categoria di attacchi.

Dovresti anche configurare il web server che sta davanti a Django per validare l’host. Dovrebbe rispondere con una pagina di errore statica o ignorare richieste di host sbagliati invece di inoltrare le richieste a Django. In questo modo eviterai errori spuri nei log di Django (o email, se hai l’error reporting configurato in quel modo). Per esempio, su nginx potresti voler impostare un server di default che restituisca «444 No Response» per gli host sconosciuti:

server {
    listen 80 default_server;
    return 444;
}

CACHES

Se stai usando una cache, i parametri di connessione potrebbero essere differenti tra sviluppo e produzione. Django ha come default il local-memory caching per processo, che può non essere desiderabile.

I server di cache spesso hanno una autenticazione debole. Accertati che accettino connessioni solo dai server delle applicazioni.

DATABASES

I parametri di connessione al database saranno probabilmente differenti tra sviluppo e produzione.

Le password dei database sono molto sensibili. Dovresti proteggere esattamente come SECRET_KEY.

Per la massima sicurezza, verifica che il database accetti connessioni solo dai server applicativi.

Se non hai configurato i backup per il tuo database, fallo immediatamente!

STATIC_ROOT and STATIC_URL

I file statici sono automaticamente serviti dal server di sviluppo. In produzione, devi definire una directory STATIC_ROOT dove collectstatic li copierà.

Vedi Come gestire file statici (Es. immagini, JavaScript, CSS) per ulteriori informazioni.

MEDIA_ROOT e MEDIA_URL

I file multimediali sono caricati dagli utenti. Sono insicuri! Assicurati che il tuo webserver non li interpreti mai. Per esempio, se un utente carica un file .php, il server web non dovrebbe eseguirlo.

Adesso è un buon momento per verificare la tua strategia di backup per questi files.

HTTPS

Ogni sito web che permette agli utenti di fare login, dovrebbe applicare HTTPS per evitare la trasmissione degli access token in chiaro. In Django, gli access token includono il login/password, i cookie di sessione ed i token di reimpostazione della password. (Non puoi proteggere gran che i token di reimpostazione della password se li invii per email).

Proteggere aree sensibili quali l’account utente o l’amministrazione non è sufficiente, perchè lo stesso cookie di sessione viene usato sia per HTTP che per HTTPS. Il tuo web server deve redirigere tutto il traffico HTTP ad HTTPS, e trasmettere solo richieste HTTPS a Django.

Quando hai disposto HTTPS, abilita le seguenti impostazioni.

Ottimizzazione delle prestazioni

Impostare DEBUG = False disabilita molte feature che sono utili solo in fase di sviluppo. Inoltre, puoi mettere a punto le seguenti impostazioni.

Sessioni

Considera di usare cached sessions per migliorare la performance.

Se usi le sessioni su database, pulisci le vecchie sessioni regolarmente per evitare di memorizzare dati non necessari.

CONN_MAX_AGE

Abilitare le connessioni persistenti ad database può portare ad una piacevole riduzione dei tempi quando ci si connette agli account del database per una parte significativa del tempo di processamento della richiesta.

Questo aiuta molto su virtual host con prestazioni di rete limitate.

TEMPLATES

Abilitare il loader dei template in cache spesso migliora drasticamente le performance, perchè evita che il template venga compilato tutte le volte che deve essere mostrato. Quando DEBUG = False, il loader dei template con cache è abilitato automaticamente. Vedi django.template.loaders.cached.Loader per avere più informazioni.

Segnalazione errore

Nel momento in cui fai push del codice in produzione, si spera sia robusto, ma non puoi aver ragione degli errori che non ti aspetti. Per fortuna, Django cattura gli errori e te li notifica in accordo.

LOGGING

Verifica la configurazione del sistema di logging prima di mettere il tuo sito in produzione, e verifica che funzioni come previsto appena inizi a ricevere del traffico.

Vedi Logging per dettagli sul logging.

ADMINS e MANAGERS

ADMINS will be notified of 500 errors by email.

MANAGERS saranno notificati riguardo agli errori 404. IGNORABLE_404_URLS può aiutare a filtrare report spuri.

Vedi Come gestire il report degli errori per dettagli sul report degli errori via email.

La segnalazione degli errori via email non scala molto bene

Considera di usare un sistema di monitoraggio degli errori come Sentry, prima che la tua inbox sia inondata da errori. Sentry può anche aggregare i log.

Personalizza la vista degli errori di default

Django include viste e template per molti codici di errore HTTP. Potresti voler fare override dei template creando i seguenti templati nella directory radice dei template: 404.html`, 500.html, 403.html e``400.html``. Le viste predefinite di errore dovrebbero essere sufficienti per il 99% delle applicazioni ma le puoi anche customize them .

Back to Top