aboutsummaryrefslogtreecommitdiff
path: root/policy_pt.mdwn
blob: 3fddb5be20fb26aed59cff1ab48f877c69638758 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
__Compromisso dos Provedores com a Privacidade: _Versão 1.0___

Traduções: [[Castelhano|policy_es]], [[Inglês|policy]]

[[!toc levels=2]]

# Preâmbulo

Este documento contém vários aspectos sociais e técnicos que devem levar a um tratamento mais seguro dos dados privados dos usuários.

À luz da vigilâcia crescente e medidas repressivas estabelecidas por muitos governos na primeira década deste milênio, é cada vez mais necessário melhorar o entendimento e a consciência dos usuários/as sobre as questões relacionadas à privacidade, assim como os níveis de privacidade  oferecidos por coletivos técnicos e grupos.

Com esse rascunho, estamos tentando criar mais transparência para nossos usuários/as. Esse documento determina o que os usuários/as podem esperar dos coletivos técnicos e grupos que o assinam, em termos de uso de criptografia, registro de IPs e armazenamento de dados.
Outra razão para escrever esse documento é encorajar a conscientização sobre a privacidade/segurança entre nós. Esse rascunho deve ser usado para pressionar administradores/as de sistema, coletivos e grupos para fazerem a coisa certa. De forma a reduzir o trabalho envolvido, os coletivos técnicos assinantes e grupos devem compartilhar o conhecimento e escrever padrões que possam ser implementados por outros coletivos técnicos e grupos.

Dito isso, tenha em mente que:

1. O fato de um coletivo técnico ou grupo assinar esse documento não é uma garantia por si só; como usuário/a, você deverá ter uma relação de confiança com o coletivo técnico ou grupo, baseado em relações pessoais, não em assinaturas. Seus dados só podem estar tão seguros como as pessoas que mantém o servidor que os hospeda.

2. Não existe um servidor perfeitamente seguro! Erros humanos e bugs de software podem expor seus dados, revelar sua identidade, enviar você para a cadeia e matar o seu gato.

3. Nada que seu coletivo técnico ou grupo preferido faça será suficiente para protegê-lo/a do escrutínio intenso e direto de uma poderosa organização. Se você suspeita que está sendo alvo de vigilância especial, você precisa agarrar a sua privacidade com as suas próprias mãos.
 
# Descrição dos níveis de segurança

_O computador é para a indústria de informação aproximadamente o que uma usina de energia é para a indústria elétrica. -- Peter Drucker_

Não existe nenhum serviço que seja ao mesmo tempo perfeitamente seguro e que também proteja totalmente a privacidade dos usuários/as finais. A política definida abaixo portanto foi feita para enumerar os diferentes níveis de segurança e privacidade. Cada coletivo técnico deve tentar alcançar o nível mais alto possível. Mesmo o nível mais alto definido, a configuração ideal pode estar além do que está proposto nesse documento. Em muitos casos será impossível preencher alguns pontos devido a vários problemas: técnicos, sociais, recursos etc. Os níveis definidos tem a intenção de tornar mais fácil para os usuários/as dos serviços entenderem, e como resultado, tomarem decisões melhores sobre a segurançá e a privacidade de seus dados. Devem também servir como guias para administradores/as de sistema que precisem de uma visão geral dos vários aspectos envolvidos nessas importantes questões e de alguns objetivos que eles possam esforçar-se para atingir.

A política define três níveis de segurança e privacidade. O primeiro nível (nível 1) contém requisitos básicos para os serviços, é definido como menos seguro e provendo menos garantia de privacidade que o "nível 2". Preenchendo os requisitos do nível mais alto (nível 3) será o maior desafio para coletivos técnicos e irá, na maior parte dos casos, proteger os dados dos usuários melhor. As seguintes descrições dos níveis tem a intenção de dar uma visão geral breve das diferenças principais entre cada um dos níveis. Por favor consulte a lista específica de requisitos para maiores detalhes. E atenção, quanto mais alto o nível, mais difícil é de alcançar ou para os usuários verificarem.

## Resumo do _nível 1_

* As conexões com todos os serviços são criptografadas por padrão. Se uma conexão não criptografada alternativa for oferecida, ela deve ser marcada visivelmente para avisar os usuários/as.
* Os e-mails enviados através do serviço podem incluir informações que identifiquem o usuário/a (por exemplo, o endereço IP do host de origem)
* Somente os dados que ainda não são publicamente acessíveis devem ser armazenados criptografados (por exemplo, dados privados do usuário/a)
* É possível que registros (logs) com dados que identifiquem os usuários/as sejam armazenados sem criptografia.
* A adequação com essa política é revisada pelos administradores/as pelo menos uma vez por ano.

## Resumo do _nível 2_

* As conexões entre usuários/as e o serviço é sempre criptografada.
* Os e-mails não contém informações que identifiquem o usuário/a.
* Nenhuma informação que identifique os usuários/as é armazenada em registros (logs).
* O sistema operacional do serviço e suas configurações só são armazenados criptografadas.
* A adequação com essa política é revisada pelos administradores/as pelo menos uma vez a cada seis meses.

## Resumo do _nível 3_

* Todos os serviços também estão disponíveis como serviços ocultos (hidden services) do Tor
* Não são armazenados registros (logs).
* A adequação a esta política é revisada pelos administradores/as pelo menos uma vez a cada três meses.


# Módulos

Obviamente, cada nível de segurança/privacidade requer que você mantenha o seu software atualizado dos problemas de segurança conhecidos.

## O que fazer em caso de incêndio?

### Nível 1

* Tenha certeza que você tenha meios de se comunicar com os usuários/as quando o servidor ficar offline. Isso pode ser um canal alternativo de comunicação (p.e. e-mail alternativo, telefone, ...) ou uma página web de status  off-site.

## E-mail

### 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.
* As conexões entre o usuário/a e o servidor são sempre criptografadas.
* Usar (Start)TLS para trocar e-mails com outros servidores, sempre que disponível
* O servidor deve ter seu próprio certificado SSL assinado por uma das autoridades certificadoras. Veja os documentos de boas práticas para mais detalhes.

### 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.
* O TLS é requerido com o nível 2 dos servidores parceiros. Os certificados são verificados com a impressão digital.

### Nível 3

* O e-mail é também disponível como um serviço oculto (hidden service) do Tor.

## Webmail 

### Nível 1

* As conexões entre o servidor e o usuário/a são sempre criptografadas.
* Se o endereço de IP do usuário aparece nos cabeçalhos do e-mail, esse fato é visivelmente marcado como inseguro.

### Nível 2

* Todas as sessões deve ser armazenadas como cookies. Os IDs das sessões não podem ser localizadas na URL.
* O endereço de IP do usuário/a não aparece em nenhum cabeçalho de e-mail.


### Nível 3

* Devido ao fato que scripts do lado do cliente, como um Javascript, podem revelar o endereço de IP do usuário/a (essa é a razão porque usuários do Tor geralmente desativam-o), o Webmail é funcional sem isso.
* O algoritmo de ID da sessão e os cookies não usam ou armazenam o endereço de IP dos usuários/as, nem em texto puro ou embaralhado. As sessões não são restritas para um endereço de IP (uma vez que isso impediria o acesso com ferramentas de anonimato como o Tor).
* O webmail está também disponível como um serviço oculto (hidden service) do Tor

## Os certificados e as chaves são criptografados para os serviços baseados em stream

### Nível 1

* A 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 2

* As chaves privadas são apenas armazenadas criptografadas.

### Nível 3

* As chaves privadas são somente armazenadas criptografadas e off-site.

## Sistema de arquivos e Armazenamento

### Nível 1

Os dados do 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.

### Nível 2

* A swap é armazenada criptografada.
* O sistema operacional e sua configuração é armazenada criptografada com uma senha forte. Veja os documentos de boas práticas para detalhes.

### Nível 3

* A swap é criptografada com uma chave aleatória na inicialização.

## Logs

### Nível 1

* Os logs são armazenados criptografados ou apenas na memória.

### Nível 2

* Os logs são anonimizados e não contém nenhuma informação que pode identificar as atividades dos usuários.

### Nível 3

* Nenhum log de nenhum tipo é armazenado.

## Usuários

### Nível 1

* Os usuários/as são aconselhados sobre boas práticas e senhas. Veja os documentos de boas práticas para detalhes.

### Nível 2

* Os usuários/as são forçados a usarem senhas fortes, elas são medidas por um algoritmo bem conhecido de força de senha. Veja os documentos de boas práticas para detalhes.
* As contas de terminal para usuários/as são apenas em vservers, compartimentos separados ou ambientes similares. Nenhum usuário final possui um login no servidor que provê serviços sensíveis. Veja os documentos de boas práticas para detalhes.

### Nível 3

* As contas de terminal são isoladas dos outros usuários: cada conta shell do usuário existe num ambiente chroot, o qual não é visível para o ambiente de outro usuários (arquivos, processos, etc.).

## Avaliação do cumprimento da política

### Nível 1

* Auto-avaliação anual: verificar no mínimo a cada doze meses se os requisitos que deveriam ter sido alcançados realmente foram.

### Nível 2

* Auto-avaliação semestral: verificar no mínimo a cada seis meses se os requisitos que deveriam ter sido alcançados realmente foram. 

### Nível 3

* Auto-avaliação trimestral: verificar no mínimo a cada três meses se os requisitos que deveriam ter sido alcançados realmente foram. 

## Verificação

A atual versão dessa política é assinada com uma chave OpenPGP ([keyserver](https://keys.mayfirst.org/pks/lookup?op=get&search=0xCE8BA23183EC5CB69760E02F8BC0E739D0645843)). Os detalhes da chaves são esses:


    pub   4096R/D0645843 2011-12-28 [expires: 2013-01-31]
          Key fingerprint = CE8B A231 83EC 5CB6 9760  E02F 8BC0 E739 D064 5843
    uid                  Providers Commitment for Privacy

O arquivo assinado está [[aqui|policy-signed.txt]].