Portuguese translation

1 files changed, 111 insertions, 28 deletions

diff --git a/best_practices_pt.mdwn b/best_practices_pt.mdwn
index 57f8d6e..8f3e74a 100644
--- a/best_practices_pt.mdwn
+++ b/best_practices_pt.mdwn
@@ -1,61 +1,144 @@
-# Best Practises
+# Anexo: Referências de boas práticas
 
-*Oficina de Boas Praticas 3 Abril 2013*
+Traduções: [[Castellano|best practices es]] [[Português|best practices pt]]
 
-Traduções: [[Inglés|best practices]] [[Espanhol|best practices es]]
+*Esse anexo contêm o texto da política com boas práticas específicas adicionadas abaixo das seções correspondentes. É um trabalho em andamento. Por favor, colabore!*
+
+Obviamente, cada nível de segurança/privacidade requer que você mantenha o seu software atualizado dos problemas de segurança conhecidos.
 
 # E-mail com Exim
 
-## Nvel 1
+## Nível 1
 
 …
 
-## Nvel 2
+## Nível 2
 
-### tls requerido com servidores parceiros, certificado verificados com 'fingerprint'
+### O TLS é requerido com o nível 2 dos servidores parceiros. Os certificados são verificados com impressão digital.
 
- * [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt)
+* [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt)
 
 # E-mail com Postfix
 
-## Nvel 1
+## Nível 1
+
+### Se o servidor adiciona o endereço IP de um usuário que está enviando um e-mail através do seu serviço em qualquer lugar do e-mail, o usuário/a é informado sobre isso.
+
+Não é uma questão de configuração do servidor: você deve usar seus canais de comunicação para passar essa informação para os seus usuários/as (p.e. newsletter, lista de anúncio). Os novos usuários/as devem ser informados, como parte do processo de abertura de nova conta. Você pode também explicar sobre isso em seu site.
+
+### As conexões entre o usuário e o servidor são sempre criptografadas.
+
+* Do lado do servidor: [Configurar o Postfix para usar o certificado X.509](http://koti.kapsi.fi/ptk/postfix/postfix-tls-cacert.shtml) acessado em 3 de Abril de 2013
+* Do lado do cliente: Peça para seu provedor a documentação :)
+
+### Usar (Start)TLS para trocar e-mails com outros servidores, sempre que disponível
+
+* Isso é chamado de criptografia *oportunística*.
+
+### O servidor deve ter seu próprio certificado X.509 assinado por uma das autoridades certificadoras.
+
+Há muitos problemas com o ecossistema X.509, parcialmente explicados aqui: http://lair.fifthhorseman.net/~dkg/tls-centralization/
+
+Dependendo do quão bem seus usuários entendem os certificados X.509, nós recomendamos 4 diferentes cenários:
+
+a. Autoridade Certificadora Comercial: geralmente é um serviço pago, mas os usuários/as não ficaram confusos porque seus clientes de e-mails já vem com certificados comerciais, então não haverǽ nenhuma mensagem de alerta sobre certificados não confiáveis. Isso não necessariamente aumenta a segurança da conexão uma vez que um atacante pode emitir certificados, pois uma autoridade certificadora pode ser desonesta ou um Estado, por exemplo. Veja a [Seção de Segurança na Wikipedia](https://en.wikipedia.org/wiki/X.509#Security) para mais detalhes.
+
+b. CaCert: os usuários ainda precisarão validar e instalar o certificado de raíz do CaCert, por que não é incluido em nenhum cliente de e-mail. Mas eles podem já terem feito esse procedimento para utilizar outros provedores. Há também um pacote Debian que torna-o fácil para usuários do Debian/Ubuntu instalarem.
+
+c. Certificados auto assinados/Autoridade própria: motivo contra: não está incluído nos clientes padrões de e-mail dos seus usuários. Eles precisam instalar os certificados (raíz). Se eles não controlam ("pinning") os certificados e possuem outras autoridades comerciais instaladas, você terá nada mais do que problemas. Você arrisca ensinar os seus usuários a ignorar as mensagens de alerta de segurança. Se propriamente aplicado por seu coletivo de cripto-ninjas, isso *pode* ser mais seguro.
+
+d. Monkeysphere: você pode usar as chaves OpenPGP (certificados) para autenticar serviços. Essa é uma solução tecnicamente excelente, no entanto, não é suportada por softwares comuns. Se você têm usuários/as com superpoderes, nós recomendamos experimentar. Mais informações no [site do Monkeysphere](http://monkeysphere.info/)
+
+## Nível 2
+
+### O servidor não adiciona o endereço IP de um usuário/a que está enviando um e-mail através do seu serviço, em nenhum lugar do e-mail.
+
+* [IPs nos cabeçalhos](https://we.riseup.net/debian/mail#postfix)
+
+### O TLS é requerido com o nível 2 dos servidores parceiros. Os certificados são verificados com a impressão digital.
+
+Uma solução equivalente é implementar uma conexão IPsec entre os coletivos relevantes, assim torna desnecessário o uso do TLS.
+Para implementar isso, você precisa saber as impressões digitais atualizadas dos certificados dos grupos que você planeja cooperar dessa forma. Há várias maneiras de se fazer isso, mas depende tanto de um contexto social e técnico, então não iremos detalhá-los aqui, apenas afirmar que isso é um requerimento. Fixar ("pinning") essas impressões digitais e atualizá-las quando mudarem pode ser um aborrecimento (ao menos que um protocolo e uma implementação segura e automatizada para esse propõsito venha a ser desenvolvida).
+
+* [Postfix TLS LEIAME](http://www.postfix.org/TLS_README.html)
+
+## Nível 3
+
+### O e-mail é também disponível como um serviço oculto (hidden service) do Tor.
+
+* [Torproject: Tor Hidden Service documentation](https://www.torproject.org/docs/tor-hidden-service.html.en) → adaptar para as necessidades do servidor de e-mail.
+* Cliente: [torbirdy](https://trac.torproject.org/projects/tor/wiki/torbirdy) é uma extensão útil para fazer uso do serviço oculto.
+
+# Sistemas de arquivos e Armazenamento
+
+## Nível 1
+
+* Os dados do/a usuário/a não são acessíveis publicamente, eles são armazenados criptografados, usando uma senha forte. Veja os documentos de boas práticas para detalhes. Isso inclui e-mails, banco de dados, arquivos de listas, sites restritos e outros.
+
+No GNU/Linux, cryptsetup:
+
+* [Como configurar um sistema de arquivos criptografado em várias etapas?](http://www.debian-administration.org/articles/469)
+* [Configurando um sistema Debian criptografado](http://madduck.net/docs/cryptdisk/)
+
+## Nível 2
+
+### A swap é armazenada criptografada.
+
+Para isso você pode usar cryptsetup também.
+
+### O sistema operacional e sua configuração é armazenada criptografada com uma senha forte. Veja os documentos de boas práticas para os detalhes.
 
-### Se o servidor adiciona a direo IP de um usurio enviando um e-mail atravs de seu servio em qualquer parte do e-mail, o usurio  informado sobre isso.
+Hoje você pode usar muitos instaladores de Sistema Operacional que conseguem isso.
 
-No  um caso de configurao de servidor: voc deveria usar seus canais de comunicao para passar esta informao aos usurios (exemplo: newsletter, anncio da lista de e-mail). Novos usurios deveriam ser informados como parte do proceso de criao de conta. Voc deveria ter isto explicado no seu website.
+Não confie nos discos rígidos que possuem uma camada de discos criptografada, eles são frequentemente mal implementados ou podem vir com backdoors, por exemplo.
 
-### As conexes entre o usurio e o servidor deveriam ser sempre encriptadas.
+## Nível 3
 
-* Lado servidor: [Configurar Postfix para usar certificado X.509](http://koti.kapsi.fi/ptk/postfix/postfix-tls-cacert.shtml) de Abril 3 2013
-* Lado cliente: Pea ao seu provedor por documentao :D
+* A swap é criptografada com uma chave aleatória na inicialização.
+* Criar uma área da swap criptografada
 
-### Use (Start)TLS para intercambiar e-mails com outros servidores disponveis em qualquer lugar.
+http://www.microhowto.info/howto/create_an_encrypted_swap_area.html
+https://we.riseup.net/debian/encrypted-swap
+http://linux.die.net/man/5/crypttab -> seção "swap"
 
-### O servidor deve ser seu prprio certificado X.509 assinado por um entre as autoridades de certificado asignadas.
+# Boas práticas (antigo)
 
-H muitos problemas com o ecossistema X.509, parcialmente explicado [aqui](http://lair.fifthhorseman.net/~dkg/tls-centralization/)
+## E-mail
 
-Dependendo do quo seus usurio entendem certificados X.509, recomendamos 4 cenrios diferentes:
+* [IPs no cabeçalho](http://riseuplabs.org/privacy/postfix/): o endereço de IP da casa do/a usuário/a não deve aparecer no cabeçalho do e-mail *nível 2*
+* Se aparecer, os/as usuários/as devem ser informados sobre isso e *nível 1* talvez mostrar o IP do servidor ao invés de localhost com o [hack do riseup](http://riseuplabs.org/privacy/postfix/)
+* A conexão entre o servidor e o usuário/a sempre é criptografada. *Nível 2*
+* A opção de comunicação não-criptografada entre o usuário/a e o servidor deve estar visivelmente marcada como insegura. *Nível 1*
+* [StartTLS-postfix](http://metatron.sh/kmw/Transformers/PostfixCacertVerifyHowto) ou [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt) starttls com outros servidores parceiros, certificados verificados versus cacert/... *nível 1*
+* [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt) - o TLS é requirido com outros servidores parceiros, certificados verificados com impressão digital *nível 2*
 
-a. Certificado Comercial: geralmente custa dinheiro, mas os usurios no se confundem pois os clientes de e-mail j vem com certificados comerciais, ento no haver estas mensagem de cuidado ou perigo relacionadas a certificados que no so confiveis. No aumenta a segurana da conexo, pois o adversrio pode expedir certificados pois uma autoridade de certificado pode ser dbia ou ser um estado, por exemplo. Olhe a esta pgina na Wikipedia https://pt.wikipedia.org/wiki/X.509 para mais detalhes.
+## Os certificados e as chaves são criptografados para os serviços baseados em stream
 
-b. CaCert: Os usurios ainda necesitaro validar e instalar certificados CaCert de root pois ele ainda no estar incluido em nenhum cliente de e-mail. Mas eles j podem ter feito este passo para outros provedores. Tambm h um pacote Debian que faz isso mais fcil de instalar para usurios Debian/Ubuntu.
+* As chaves privadas são armazenadas criptografadas *Nível 2*
+* As chaves privadas são somente armazenadas criptografadas e off-site *Nível 3*
+* Comunicação baseada em stream usa apenas uma configuração bem estabelecida de parâmetros criptográficos (cifras, message digests, algoritmos de criptografia assimética, etc). Veja os documentos de boas práticas para detalhes. *Nível 1*
 
-c. Certificados self-signed (auto-assinados): no esto includos em clientes de e-mail padro. Eles devem instalar certificados root. Se eles no usarem "pinning" de certificado, mas tiverem outro certificado comercial ainda instalado, voc no ganhar nada alm de confuso. Voc se arrisca a ensiar seus usurios em trespassar mensagems de alarme de segurana. Se corretamente aplicado pelo seu coletivo de crypto-ninjas, isto *pode* ser mais seguro.
+Se você estiver usando mod_ssl com apache e uma chave RSA para o servidor, sugerimos:
 
-d. Monkeysphere: Vocpode usar chaves openPGP (certificados) para autenticar servios. Isto  tecnicamente uma soluo excelente, ainda que no realmente reconhecido por softwares populares. Se voc tiver conhecimento, recomendamos que tente. Mais informao em http://monkeysphere.info/
+<code>SSLCipherSuite TLSv1:!MD5:!EXP:!LOW:!NULL:!MEDIUM:!ADH:!DSS</code>
 
-## Nvel 2
+## Log
 
-### O servidor no adiciona a IP do usurio enviando um e-mail atravs deste servio em nenhum lugar deste e-mail.
+* Os logs contendo informação de identificação do usuário/a são armazenados criptografados ou apenas na memória. De outro modo os usuários devem ser informados sobre isso. *Nível 1*
+* Os logs não possuem nenhuma informação identificação do usuário/a. *Nível 3*
 
-* [IPs nos cabealhos]( https://we.riseup.net/debian/mail#postfix )
+Logs do Apache sem nenhum endereço IP: [mod_removeip](http://riseuplabs.org/privacy/apache/)
 
-### TLS  requerido com outros servidores que cumpram o level 2. Certificados so verificados com uma 'fingerprint'.
+Usando Debian com Apache2:
 
-A soluo equivalente  implementar um link de IPsec entre os coletivos relevantes, o que faz o uso de TLS desnecessrio.
+      apt-get install libapache2-mod-removeip
+      a2enmod removeip
+      /etc/init.d/apache2 force-reload
 
-De maneira a implementar isto, voc precisa saber
+* Os logs contendo informação sobre as atividades não-individuais dos usuários/as são armazenados criptografados ou apenas memória. *Nível 1*
+* Os logs não possuem nenhum informação sobre as atividades não-individuais dos usuários/as. *Nível 2*
+* Os logs do sistema (não relacionados com as atividades dos usuários/as) são armazenados criptografados ou apenas na memória. *Nível 2*
 
-In order to implement this, you need to know the up-to-date fingerprints of the certificates of the groups that you plan to cooperate with in this way. There are many ways to do this, but it depends too much on social and technical context so we will not detail them here, only state that it is a requirement. Pinning those fingerprints and updating them when changed can be a hassle (unless an automated and secure protocol and implementation for this purpose becomes available).
+Acompanha "Sistemas de arquivos e Armazenamento Nível 2"
 
+* Os logs do sistema (não relacionados com as atividades do usuário) não são armazenados. *Nível 3*