Lista de verificação para distribuiçãoLink para este cabeçalho
A internet é um ambiente hostil. Antes de distribuir um projeto Django, você deve perder algum tempo para revisar suas configurações, com segurança, desempenho, e operações em mente.
O Django inclui muitos security features. Agumas são embutidas e sempre habilitadas. Outras são opcionais porque nem sempre são apropriadas, ou porque são inconvenientes para desenvolvimento. Por exemplo, forçar HTTPS talvez não seja bom para todos os websites e não prático para desenvolvimento local.
Otimização de desempenho são outra categoria de “perde-ganha” com a conveniência. Por exemplo, “cache” é útil em produção, mas não em desenvolvimento. Necessidades de relatórios de erros também são amplamente diferentes.
As seguinte lista de verificação inclui configurações que:
devem ser configuradas propriamente para que o Django forneça o nível esperado de segurança.
espera-se que sejam diferentes em cada ambiente.
habilitam características de segurança opcionais;
habilitam otimização de desempenho.
fornece relatório de erro.
Muitas destas configurações são sensíveis e devem ser tratadas confidencialmente. Se você está publicando o código fonte do seu projeto, uma prática comum é publicar configurações adequadas para desenvolvimento, e usar o módulo de configuração para produção.
Execute manage.py check --deployLink para este cabeçalho
Algumas das verificações descritas abaixo podem ser automatizadas usando a opção check --deploy. Assegure-se de executá-lo com o arquivo de configuração como descrito na documentação de configuração.
Configurações críticas.Link para este cabeçalho
SECRET_KEYLink para este cabeçalho
A chave secreta deve ser um valor randômico e longo e deve ser mantido em segredo
Tenha ceteza que a chave usada em produção não é usada em nenhum outro local e evite “commitar” isso no código fonte. Isso reduz o número de vetores dos quais um atacante possa acessar a chave.
Ao invés de “hardecodear” a chave secreta no módulo de configuração, considere carrega-lo de uma variável de ambiente:
import os
SECRET_KEY = os.environ['SECRET_KEY']
ou de um arquivo:
with open('/etc/secret_key.txt') as f:
SECRET_KEY = f.read().strip()
DEBUGLink para este cabeçalho
Nunca habilite o debug em produção
Certamente você desenvolvimento seu projeto com DEBUG = True, já que isso habilita características convenientes como “tracebakcs” no seu browser.
Para o ambiente de produção, embora, isso é realmente uma má idéia, porque ele abre uma série de informações sobre seu projeto: dicas de seu código fonte, variáveis locais, configurações, bibliotecas usadas, etc.
Configurações específicas de configuraçõesLink para este cabeçalho
ALLOWED_HOSTSLink para este cabeçalho
Quando DEBUG = False, o Django não irá funcionar de maneira alguma sem um valor adequado para o ALLOWED_HOSTS.
Essa configuração é requerida para proteger seu site de ataques CSRF. Se usar um caracter corínga, você deve fazer sua própria validação do cabeçalho HTTP do Host, ou de outra maneira tenha certeza que você não está vulnerável a esse tipo de ataque.
Deve-se também configurar o servidor Web que está a frente do Django para validar o host. Ele deve responder com um erro de página estática ou ignorar a requisição para hosts incorretos ao invés de repassar o request para o Django. Desta maneira evitará erros espurios no seu log do Django (ou emails se tiver configurado para isso). Por exemplo, no nginx talvez configure o servidor padrão para retornar “444 no response” quando host não reconhecido:
server {
listen 80 default_server;
return 444;
}
CACHESLink para este cabeçalho
Se você estiver usando um “cache”, os parâmetros de conexão do embiente de desenvolvimento talvez sejam diferentes dos parâmetros de produção. O padrão do Django é “per-processo” local-memory caching o qual talvez não seja o desejável.
Servidores de “cache” tem em geral uma autenticação fraca. Assegure-se que somente aceite conexões de seus servidores de aplicações.
Se estiver usando Memcached, considere usar sessões cacheadas para melhorar o desempenho.
DATABASESLink para este cabeçalho
Parâmetros de conexões de bancos de dados são provavelmente diferentes em desenvolvimento e em produção.
Senhas de bancos de dados são muito sensíveis. Você deve protegê-las tal como o SECRET_KEY.
Para máxima segurança, certifique que os servidores de bancos de dados somente aceitem conexões de seus servidores de aplicação.
Se não configurou backup para seu banco de dados, faça isso já!
STATIC_ROOT e STATIC_URLLink para este cabeçalho
Arquivos estáticos são automaticamente servidos pelo servidor de desenvolvimento. Em produção, você deve definir o diretório STATIC_ROOT onde o collectstatic irá copiá-los.
Veja Gerenciamento de arquivos estáticos (ex.: imagens, JavaScript, CSS) para mais informações.
MEDIA_ROOT e MEDIA_URLLink para este cabeçalho
Arquivos de media são enviados por usuários. Eles não são confiáveis! Assegure-se que seu servidor web nunca tente interpretá-los. Por exemplo, se um usuário enviar um arquivo .php, o servidor web não deve executá-lo.
Agora é uma boa hora para verificar sua estratégia de backup para estes arquivos.
HTTPSLink para este cabeçalho
Qualquer website que possibilita autenticação de usuários deveria exigir HTTPS em todo o site para evitar a transmissão de tokens planos. No Djano, os tokes de acesso incluem o login/senha, a “cookie” da sessão e o token de reset de senha. (Não é possível fazer muito para proteger bem os tokens de reset de senha se são enviados via email).
Proteger áreas sensíveis como a conta do usuário e o admin não são sificientes, porque o mesmo “cookie” de sessão é usado para HTTP e HTTPS. Seu servidor WEB deve redirecionar todas as requisições HTTP para HTTPS, e somente transmitir requests HTTPS para o Django.
Uma vez que tenha configurado HTTPS, habilite as seguintes configurações.
Otimizações de desempenho.Link para este cabeçalho
A Configuração DEBUG = False desabilita muitas características que são úteis somente em desenvolvimento. Além disso, você pode ajustar as seguintes configurações.
CONN_MAX_AGELink para este cabeçalho
Habilitando persistent database connections pode resultar em um bom aumento de velocidade no tempo de processamento de requisições quando se conecta a contas do banco de dados.
Isso ajuda muito em Hosts virtualizados com desempenho de rede limitado.
TEMPLATESLink para este cabeçalho
Habilitando o cache do carregador de “templates” muitas vezes aumenta o desempenho dramaticamente, já que isso evita compilar cada template todas as vezes que precisa ser renderizado. Veja o template loaders docs para mais informações.
Relatório de erroLink para este cabeçalho
Na hora em que o código é enviado para produção, espera-se robustez, mas não podemos ter erros inexperados. Menos mal, o Django pode capturar estes erros e noticá-los de acordo.
LOGGINGLink para este cabeçalho
Reveja a sua configuração de log antes de colocar seu website em produção, e verifique se este está funcionando como esperado tão logo receba algum tráfego.
Veja Logging para detalhes de log.
ADMINS e MANAGERSLink para este cabeçalho
ADMINS será notificado de erros do tipo 500 por email.
MANAGERS serão notificados de erros do tipo 404. IGNORABLE_404_URLS pode ajudar a filtrar erros ilegítimos.
Veja Relatório de erro para detalhes sobre relatórios de erros por email.
Customize as views de erro padrãoLink para este cabeçalho
O Django inclui várias “views” e “templates” padrão para vários erros HTTP. Talvez você queira sobrescrever os templates padrão criando os seguintes templates na raiz do seu diretório de template: 404.html, 500.html, 403.html, and 400.html. As “views” padrão devem bastar para 99% das aplicações Web, mas se desejar customizá-las, veja essas instruções as quais também contém detalhes sobre os templates padrão.
Opções PythonLink para este cabeçalho
É fortemente recomendável que os processos Python que executam a aplicação Django use a opção -R ou com a variável de ambiente PYTHONHASHSEED definida como random. Essa opção está por padrão habilitada a começar com o Python 3.3.
Essas opções ajudam a proteger seu site de ataques de “negação de serviço” (DoS) disparados por entradas cuidadosamente elaboradas. Como um ataque que pode aumentar drasticamente o uso da CPU causando um cenário de pior desempenho quando cria instâncias de dict. Veja oCERT advisory #2011-003 para mais informações.