diff options
Diffstat (limited to 'atividades/provedor')
| -rw-r--r-- | atividades/provedor/backups.md | 54 | ||||
| -rw-r--r-- | atividades/provedor/backups/entrega.md | 93 | ||||
| -rw-r--r-- | atividades/provedor/cert.md | 176 | ||||
| -rw-r--r-- | atividades/provedor/hospedagem.md | 72 | ||||
| -rw-r--r-- | atividades/provedor/hospedagem/carta.md | 73 | ||||
| -rw-r--r-- | atividades/provedor/hospedagem/database.md | 16 | ||||
| -rw-r--r-- | atividades/provedor/hospedagem/plataforma.md | 45 | ||||
| -rw-r--r-- | atividades/provedor/hospedagem/politica.md | 47 | ||||
| -rw-r--r-- | atividades/provedor/hospedagem/recusa.md | 28 | ||||
| -rw-r--r-- | atividades/provedor/hospedagem/termo.md | 105 | ||||
| -rw-r--r-- | atividades/provedor/mensagens.md | 11 | ||||
| -rw-r--r-- | atividades/provedor/mensagens/certs.md | 28 | ||||
| -rw-r--r-- | atividades/provedor/mensagens/downtime.md | 37 | ||||
| -rw-r--r-- | atividades/provedor/servidor.md | 72 | ||||
| -rw-r--r-- | atividades/provedor/sistemas.md | 72 | ||||
| -rw-r--r-- | atividades/provedor/sistemas/dns.md | 19 | ||||
| -rw-r--r-- | atividades/provedor/sistemas/dominios.md | 41 |
17 files changed, 989 insertions, 0 deletions
diff --git a/atividades/provedor/backups.md b/atividades/provedor/backups.md new file mode 100644 index 0000000..c671152 --- /dev/null +++ b/atividades/provedor/backups.md @@ -0,0 +1,54 @@ +# Grupo de Trabalho de Backups + +```eval_rst +.. toctree:: + :maxdepth: 1 + :glob: + + backups/* +``` + +O presente processo estabelece as linhas gerais de funcionamento de um grupo de +trabalho responsável pela realização de backups para o Coletivo, cujos +objetivos são delineados nos critérios que a seguir. + +## Preservação + +O grupo de trabalho deve manter backups do máximo número possível de +camadas/instâncias do Coletivo, preservando os critérios de segurança e +privacidade assim como a Política de Segurança da Informação do Coletivo e +especialmente o seguinte critério de persistência da informação: + +` +Informações armazenados num determinado nível de acesso ou segurança (exemplo, +disco criptografado) devem, por padrão, permanecer nesse mesmo nível ou serem +transferidas para um nível mais seguro, exceto quando constitui informação +desclassificada e permitida para descer de nível. +` + +Do ponto de vista do [RSP](http://rsp.fluxo.info), o GT de Backups deve +proporcionar replicação de camadas que preservem (ou que aumentem o nível, se +possível) suas propriedades de segurança e privacidade no acesso à informação. + +## Otimização de parâmetros + +O grupo de trabalho deve ainda otimizar os seguintes parâmetros ao propiciar a +realização de backups: + +1. Periodicidade. +2. Incrementos. +3. Largura de banda. +4. Segurança e integridade. +5. Espaço em disco. + +## Auditagem + +O grupo de trabalho deve também realizar auditagens periódicas nos backups para +se certificar de sua realização e, se possível, possuir um sistema automático +de relatórios de backups. + +## Dependências + +A realização deste processo depende da realização dos seguintes processos: + +* [Política de segurança da informação](/coletivo/comunicacao/acl). diff --git a/atividades/provedor/backups/entrega.md b/atividades/provedor/backups/entrega.md new file mode 100644 index 0000000..c2cfb75 --- /dev/null +++ b/atividades/provedor/backups/entrega.md @@ -0,0 +1,93 @@ +# Entrega de backups solicitados + +Processo que consiste na entrega de backups solicitados por grupos e pessoas +hospedadas na infra-estrutura do Coletivo. As tarefas envolvidas consistem em: + +1. Obter as solicitações a backups e organizá-las numa tabela, mantendo assim o + Coletivo informado sobre o andamento deste processo. Por possivelmente + existirem backups de qualidades distintas, é preciso perguntar à parte + solicitante, caso necessário, de qual backup os dados precisam ser entegues. +2. Obter, caso existente, o backup solicitado, realizando uma auditoria caso + necessário. +3. Disponibilizar os backups apenas às pessoas responsáveis pelos ou donas dos + dados ou informá-las caso o backup não exista. Informá-las também se o eventual + backup foi ou não auditado e: + a. Caso tenha sido auditado, disponibilizar, em linhas gerais, o procedimento utilizado. + b. Caso não tenha sido auditado, informal qual risco isso representa. + +Auditoria do backup +------------------- + +Quando necessária, a auditoria básica consiste em: + +1. Retirar qualquer código executável que possa ser substituído. +2. Marcar todo o código executável insubstituível como vulnerável, cuja + auditoria é deve ser repassada para o grupo dono do código. +3. Destruição ou modificação de qualquer senha encontrada, mesmo que a mesma se + encontre armazenada de modo cifrado. +4. Auditagem básica de conteúdo: verificação de datas de acesso e escrita a + arquivos, passar anti-virus, etc. +5. Auditagem avançada de conteúdo, se possível. + +Procedimentos mais refinados ficam à cargo da situação e do grupo de trabalho +de entrega de backups solicitados (composto pelas pessoas responsabilizadas +pelas tarefas acima mencionadas). + +Prazos +------ + +O prazo de entrega de backups é proporcional ao tamanho do mesmo e à +necessidade de auditoria: + +* Backups de até 100MB: entrega em até 30 dias. +* Backups de até 1GB: entrega em até 60 dias. +* Backups maiores que 1GB: entrega em até 90 dias. + +No caso de necessidade de auditoria, o prazo de entrega é duplicado. + +Template +-------- + + Conforme solicitado, o último backup disponível de $descricao, datado de $data + e obtido $origem, já está disponível. + + Seguem os dados: + + - URL: https://backups.$dominio/$sitio + - Conta: $sitio + - Senha: $senha + + O https://backups.$dominio atualmente usa um certificado SSL + auto-assinado, cuja impressão digital é + + $fingerprint + + Hashes dos arquivos disponibilizados: + + md5sum: $hashes + sha1sum: $hashes + + Auditoria realizada: + + - Busca e eventual remoção de código executável. + - Mudança de senhas em banco de dados (senhas truncadas). + - Busca por vírus. + + Tarefas não-realizadas porém recomendadas: + + - Checagem do conteúdo do banco de dados (para evitar calúnia ou + desinformação) + - Checagem do conteúdo dos arquivos. + - IMPORTANTE: checagem de usuários para evitar inscrições de + elementos estranhos. + - Checagem da configurações da instância, caso ela seja reinstalada + noutro local. + - Limpeza do spam e desativação de todas as contas desconhecidas + (principalmente relacionadas a spam). + + Observações: + + - Em princípio, não há prazo para a permanência de tal backup + no local disponibilizado. No entanto, pode ser que ele precise + ser apagado para liberar espaço ou nalgum procedimento de + limpeza. Por isso, recomenda-se que sejam baixados o quanto antes. diff --git a/atividades/provedor/cert.md b/atividades/provedor/cert.md new file mode 100644 index 0000000..dcf62a8 --- /dev/null +++ b/atividades/provedor/cert.md @@ -0,0 +1,176 @@ +# Gestão de chave e certificado SSL + +O presente processo trata da gestão de chave e certificado SSL para conexões +ditas seguras entre servidores do Coletivo. + +Considerações +------------- + +O Coletivo reconhece que + +1. O protocolo HTTPS possui sérios problemas de design, impedindo por exemplo + que diferentes certificados possam ser utilizados num mesmo IP. + +2. A indústria da certificação digital representa um sério risco de segurança e + uma [imposição tecnocrata](http://lair.fifthhorseman.net/~dkg/tls-centralization/) à + utilização prática do HTTPS. Ela recria um domínio cartorial no cyberespaço e + pode a qualquer momento [ser utilizada por governos ou corporações para forjar + certificados autenticados](http://web.monkeysphere.info/news/internet_secret_backdoor/) e + com isso [grampear](https://secure.wikimedia.org/wikipedia/en/wiki/Man-in-the-middle_attack) + a conexão entre usuários/as e computadores. + +3. Idealmente, a atitude a ser tomada por um coletivo técnico radical deveria +de não utilizar a indústria da certificação como meio de assegurar a +identificação de seus serviços e máquinas. Deveria, ao invés disso, utilizar +apenas esquemas abertos como + a. Certificadores Comunitários como o [CACert](http://cacert.org). + b. [Monkeysphere](http://web.monkeysphere.info). + c. A simples verificação da impressão digital dos certificados mediante + algum vínculo direto (por exemplo, troca de fingerprints ou validação via + OpenPGP) com os/as administradores das máquinas. + +4. No entanto + a. Nem todos os navegadores acompanham, por padrão, certificados de + entidades comunitárias. É o + [caso do CACert](https://secure.wikimedia.org/wikipedia/en/wiki/Cacert#Inclusion_status). + b. A adoção de ferramentas livres para HTTPS ainda está muito longe de se + tornar comum. No presente, haveria pouca possibilidade de que uma metodologia + livre seja eficiente. Ao invés disso, haveria um involuntário incentivo aos/às + usuários para que aceitem certificados considerados como inválidos pelos + navegadores, o que pode facilitar ainda mais o grampo: se os usuário aceitam + qualquer certificado, então não haveria diferença entre eles aceitarem o + certificado verdadeiro do falso. + +Conclusões +---------- + +Portanto, o Coletivo conclui que + +1. No momento, ainda importante ter um certificado assinado pela indústria da + certificação, isto é, por uma entidade autorizada pelo cartel do SSL. +3. A autoridade certificadora a ser utilizada deve obedecer alguns critérios básicos: + a. Não é diretamente conectada a uma agência governamental. + b. Não possui problemas políticos óbvios. + c. Cujo certificado raíz não está encadeado com certificados que não satisfazem os critérios acima. +2. Dada a sua insuficiência, tal certificação corporativa não deve ser o único + meio para a validação dos certificados SSL e assim esquemas alternativos como o + [Monkeysphere](http://web.monkeysphere.info) devem ser utilizados e + encorajados, de modo que haja um aumento da massa crítica necessária para + tornar tais métodos mais populares. O mesmo se aplica para a verificação da + impressão digital dos certificados. + +Utilização de HTTPS +------------------- + +Conforme o documento [Best Practices for Online Service +Providers](https://www.eff.org/wp/osp), o Coletivo concorda que conexões HTTPS +devem ser utilizadas o máximo possível. + +1. O Coletivo utilizará HTTPS apenas em servidores confiáveis que onde seja + possível armazenar as chaves SSL de forma criptografada. +2. Utilizar, quando possível, cabeçalhos + [HSTS](http://www.debian-administration.org/article/Enabling_HTTP_Strict_Transport_Security_on_debian_servers). +2. Considerando que o certificado vale apenas para um único domínio e seus + subdomínios (isto é, o domínio principal do Coletivo), o Coletivo utilizará + HTTPS por padrão apenas: + a. Para serviços, sistemas e sítios que utilizem o domínio principal do + Coletivo, quando não houver impedimento técnico para tal. + b. Para outros domínios desde que solicitado pela parte hospedada. +3. Considerar a utilização de [entradas CAA no DNS](https://links.fluxo.info/tags/caa). + +Implementação +------------- + +A implementação de HTTPS também deve obedecer a uma suite bem estabelecida. + +Tal escolha deve desabilitar uma série de cifras ruins e habilitar aquelas que +provém [Perfect Forward Secrecy +(PFS)](https://secure.wikimedia.org/wikipedia/en/wiki/Perfect_forward_secrecy). + +Outros protocolos +----------------- + +A utilização do SSL também deve se estender a outras plataformas, como por +exemplo email (via TLS) desde que possível e que atenda critérios análogos aos +anteriores. + +Escolha de autoridade certificadora +----------------------------------- + +Dentre as autoridades certificadoras, o Coletivo escolhe a [Gandi](https://gandi.net) por: + +1. Atender os critérios acima estabelecidos. +2. Diferentemente de outras empresas, possui uma preocupação com privacidade e + comprometimento com serviços de internet alternativos e independentes. +2. [Contribuir com projetos de código aberto](https://secure.wikimedia.org/wikipedia/en/wiki/Gandi#Gandi_supports ), + vide [lista](http://en.gandi.net/supports/). + +No entanto, é importante notar as limitações envolvidas na escolha do Gandi: + + Q: Por que muitos grupos usam GANDI como registrar? + R: Porque naqueles tempos (2000), ter seu próprio domínio era tranquilamente + de 5 a 10 vezes mais caro do que hoje. GANDI acabou com esses preços + introduzindo ofertas muito baratas no mercado. E como em geral temos + pouco ou nenhum dinheiro para colocar em projetos, simplemente compramos + nossos domínios lá. + + Q: O que GANDI significa? + R: Isso é uma curiosidade, mas GANDI significa "Gestion et Attribution + des Noms de Domaines Internet", "Atribuição e gestão de nomes de + domínio de Internet". Como empresa, o modelo de negócios era simples: + praticamente tudo automatizado, praticamente sem suporte e preços + baixos. + + Q: Por que GANDI é vista como uma organização política? + R: Os fundadores originais do GANDI tinham idéias políticas sobre bens + comuns e como todo o negócio de nomes de domínio da Internet era + baseado em escassez virtual. Um deles até escreveu um livro, + "Confessions d'un voleur" ("Confissões de um ladrão") no qual ele + descreve extensamente sobre como fez um monte de dinheiro exatamente + vendendo algo que não existia e que não havia sentido em vender. + + Q: Por que GANDI é visto como "descolado"? + R: Alguns dos fundadores originais também eram envolvidos na cena + alternativa da Internet na França. Parte do dinheiro obtida pelo + GANDI ajudou outros projetos, um dos quais o operador sem fins + lucrativos Gitoyen. + + Q: Onde estão esses fundadores agora? + R: Em algum outro lugar! Como não foram capazes de concordar em onde + o dinheiro deveria ir, os quatro fundadores resolveram vender o + GANDI. Eles fizeram isso até por um preço justo. Tentaram vender + para pessoas que respeitariam o espírito original, e em certo + sentido o fizeram. Parece que o GANDI ainda contribui para + projetos de software livre e relacionados, tanto em tempo de + trabalho quanto em dinheiro. + + Q: Devo confiar no GANDI? + R: Da mesma forma que você confia em qualquer companhia capitalista. + Eles preferirão preservar seu negócio ao invés de ajudar você. + +Responsabilização +----------------- + +O Grupo de Trabalho formado pelas pessoas responsáveis pelo presente processo deve: + +1. Caso o Coletivo disponha de recursos financeiros, manter certificado SSL + assinado para `*.dominio` via [Gandi](https://gandi.net). O Coletivo arcará com + os custos. Caso contrário, adotar a certificação + [CACert](http://www.cacert.org/) como padrão. +2. Manter formas alternativas de certificação via: + a. [Monkeysphere](http://web.monkeysphere.info). + b. A simples verificação da impressão digital dos certificados mediante + algum vínculo direto (por exemplo, troca de fingerprints ou validação via + OpenPGP) com os/as administradores das máquinas. + c. Manter, na medida do possível, o público informado das mundanças nas + haves de acesso, utilizando para isso OpenPGP. Como exemplo, manter uma página + ública e atualizada sobre os atuais certificados utilizados e também informar + rupos e pessoas próximas sobre mudanças em certificados. +3. Opcionalmente, manter também a assinatura via [http://www.cacert.org/ CaCert]. +4. Evitar o vencimento da validade dos certificados, utilizando para isso + métodos como o [http://prefetch.net/articles/checkcertificate.html + ssl-cert-check], implementado por exemplo no + [http://git.fluxo.info/puppet-ssl puppet-ssl]. +5. Observar a aplicação dos critérios e determinações do presente processo, + operando conjuntamente com o GT de [wiki:Camadas Configuração de sistemas + padronizada e centralizada]. diff --git a/atividades/provedor/hospedagem.md b/atividades/provedor/hospedagem.md new file mode 100644 index 0000000..bf8b4ce --- /dev/null +++ b/atividades/provedor/hospedagem.md @@ -0,0 +1,72 @@ +# Hospedagem + +```eval_rst +.. toctree:: + :maxdepth: 1 + :glob: + + hospedagem/* +``` + +Este processo define os procedimentos de hospedagem do Coletivo. A hospedagem +de conteúdo e/ou serviços constitui processo formal e é dividida em dois +níveis: + +1. Grupo de trabalho de uma dada plataforma. +2. Grupo responsável por uma dada hospedagem. + +## Necessidade de formalização + +Como a hospedagem consiste numa atividade sensível, onde é importante dar +alguma garantia a quem se hospeda e da mesma maneira ter garantias contra +possíveis problemas que cada hospedagem pode causar, ambos os níveis devem ser +estabelecidos como processos formais. Além disso, como parte da implementação +deste processo, inclusive sítios já hospedados e plataformas existentes deverão +passar pela formalização. + +A hospedagem está sujeita a comprometimentos (do Coletivo e da parte hospedada) +que satisfaçam a uma Política de Hospedagem do Coletivo. + +## Grupo de uma plataforma + +Ao grupo de trabalho de uma dada plataforma cabe cuidar do funcionamento, +manutenção e segurança de uma dada plataforma de hospedagem. Para cada +plataforma a ser oferecida hospedagem é preciso um grupo de trabalho +responsável. + +A não existência de um grupo de trabalho de uma plataforma não proíbe a +existência de instalações da plataforma para uso interno do Coletivo, mas +impede que a hospedagem de terceiros (isto é, de grupos e indivíduos de fora do +Coletivo) seja realizada. + +## Grupo de uma hospedagem + +Ao grupo de trabalho responsável por uma dada hospedagem cabe cuidar da +hospedagem de um dado grupo/indivíduo. Para que seja possível hospedar um grupo +ou indivíduo numa dada plataforma, é necessário que haja um grupo de trabalho +em funcionamento para essa plataforma. + +O processo formal para cada hospedagem deve conter as seguintes ações: + +1. Apresentação do Coletivo (realizada durante a etapa "discussão" do processo) + através do envio de sua Carta de Hospedagem. +2. Apresentação do grupo ou indivíduo a ser hospedado realizada durante a etapa + "discussão" do processo). +3. Decisão: + * No caso de aprovação da hospedagem pelo Coletivo e após o processo sido + responsabilizado: + 1. A(s) pessoas(s) responsável(is) pela hospedagem deve(m) enviar o + Termo de Comprometimento de Hospedagem e a Política de Hospedagem do Coletivo. + 2. O coletivo ou indivíduo a ser hospedado deve concordar com o Termo de + Comprometimento de Hospedagem, caso contrário a hospedagem não pode ser + realizada. + * No caso de não-aprovação pelo Coletivo ou falta de responsabilização, o + grupo ou indivíduo que seria hospedado deve ser informado da decisão + juntamente com o motivo, se possível. + +## Responsabilização + +Cabe ao grupo de trabalho de uma hospedagem: + +1. Aplicar a Política de Hospedagem do Coletivo junto à parte hospedada. +2. Manter a comunicação entre o Coletivo e a parte hospedada. diff --git a/atividades/provedor/hospedagem/carta.md b/atividades/provedor/hospedagem/carta.md new file mode 100644 index 0000000..10d7f75 --- /dev/null +++ b/atividades/provedor/hospedagem/carta.md @@ -0,0 +1,73 @@ +# Carta de Hospedagem + +A Carta de Hospedagem não apenas estabelece as intenções e princípios que o +Coletivo adota para a hospedagem quanto pode ser utilizada como apresentação +aos grupos e indivíduos canditatos a hospedagem. + + Carta de Hospedagem do $coletivo + -------------------------------- + + O $coletivo é parte de uma intersecção de vários grupos que discutem política e + tecnologia de diferentes formas. Partindo disso, trabalhamos com servidores de + internet, voltados para distintas finalidades de cooperação. Sendo assim, nossa + idéia é colaborar com grupos/projetos que participem de experiências de apoio + mútuo e múltiplo. + + O $coletivo é um projeto autônomo, mantido por um coletivo de voluntários e + voluntárias. Um dos nossos principais objetivos é a construção coletiva de + espaços públicos, comuns entre diversos projetos e grupos que tenham a intenção + de fortalecer e estreitar sua convivência. + + Nossa intenção não é oferecer um "serviço de hospedagem", por isso não estamos + dispostos/as a nos aproximar de grupos que busquem este tipo de serviço. + Queremos que os grupos por nós hospedados colaborem com a construção de uma + vizinhança, um rizoma. De tal maneira que a técnica e a tecnologia não sejam + impedimento para isso, muito pelo contrário. Sendo a tecnologia também uma + construção social, seus propósitos, sua configuração e os processos nos quais + ela interfere não podem prescindir dos desígnios dos grupos sociais onde ela é + manipulada. + + A internet é um ambiente de cooperação, mas também de apropriação e exploração + de bens públicos. Nós entendemos que ela só se torna essencialmente um espaço + público na medida em que as pessoas possam controlar seus meios de produção e + de acesso, o que não ocorre em espaços corporativos ou governamentais. Por isso + buscamos a criação de espaços públicos, não corporativos e não estatais, e + esperamos que os grupos por nós hospedados colaborem com a construção desses + espaços. + + Durante a construção de tais espaços, realizamos discussões nas quais tentamos + desvendar temas como cultura, sociedade, tecnologia, ativismo, mudanças sociais + entre outros. Tais estudos, quando possível, são disponibilizados publicamente. + + Estudamos as implicações políticas da técnica, desenvolvemos sistemas e + instrumentos a partir de outros valores políticos, além de dialogarmos + politicamente dentro da lógica cíclica da teoria/prática. + + Por isso, uma de nossas propostas é o estabelecimento coletivo de uma rede de + apoio mútuo entre os grupos e indivíduos interessados em partilhar de uma mesma + estrutura para compartilhar seus conhecimentos, atividades desenvolvidas e + estudos realizados, de forma a integrar ativamente esta rede. + + Buscamos, portanto, quebrar com a relação prestador de serviço/cliente, pois + não somos prestadores/as de serviço e nem os grupos/indivíduos por nós + hospedados são nossos clientes, ambos fazemos parte de uma mesma rede de + colaboração onde interesses diversos convergem para o fortalecimento dessa + rede, e quem sabe para que esta forma de organização extrapole a própria rede e + contamine assim as demais esferas que compõe a sociedade. + + Pensando na distribuição do conhecimento, e como incentivo a novos grupos + interessados em manter sua própria plataforma de servidores, buscamos divulgar + o máximo da sistematização de organização. + + E lembre-se: para nós, @ $coletivo não é apenas um sistema de hospedagem ou um + mero provedor de serviços. + + Links de interesse: + + - Estudos disponibilizados: http://wiki.$dominio + - Configurações e procedimentos operacionais: http://padrao.$dominio + + Atenciosamente, + Coletivo $coletivo + +[Versão inglesa](/english/hosting/letter). diff --git a/atividades/provedor/hospedagem/database.md b/atividades/provedor/hospedagem/database.md new file mode 100644 index 0000000..c869bb3 --- /dev/null +++ b/atividades/provedor/hospedagem/database.md @@ -0,0 +1,16 @@ +# Checklist para Bases de Dados + +* Fundamental: + * Backups remotos automatizados. + * Acesso web à plataforma apenas via conexão mais segura (https). + * Adequação à legislação (LGPD, Marco Civil etc). + * Minimizar quantidade de dados pessoais coletados e exibidos ao estritamente necessário. + * Acesso restrito para informações pessoais. +* Recomendado: + * Não utilizar "nuvem" corporativa: usar servidor próprio, pois evita o acesso por terceirizados. + * Protocolo (acordo comum) sobre o uso da plataforma pelos pesquisadores(as), incluindo aspectos sobre privacidade. + * Treinamento básico de segurança e privacidade para administradores(as) e alimentadores(as) do sistema. + * Definição sobre licenciamento de dados (direitos autorais) e política de dados abertos. +* Opcional: + * Armazenamento criptografado. + * Backups offline. diff --git a/atividades/provedor/hospedagem/plataforma.md b/atividades/provedor/hospedagem/plataforma.md new file mode 100644 index 0000000..322296e --- /dev/null +++ b/atividades/provedor/hospedagem/plataforma.md @@ -0,0 +1,45 @@ +# Grupo de Trabalho de Hospedagem em $plataforma
+
+O presente processo estabelece o funcionamento do Grupo de Trabalho de
+Hospedagem em `$plataforma` (doravante mencionado apenas como
+'''plataforma'''), consistindo em:
+
+1. Manter instalações atualizadas e em funcionamento da plataforma.
+2. Acompanhar avisos de segurança e atualizações dos aplicativos necessários
+ para o funcionamento da plataforma.
+3. Caso não seja realizado automaticamente, efetuar atualizações de segurança
+ em no máximo '''uma semana''' (incluindo finais de semana e feriados) após as
+ mesmas serem disponibilizadas.
+4. Observar e aplicar os critérios de segurança e privacidade existentes para
+ os/as usuários da plataforma.
+5. Caso possível, atender a pedidos do Coletivo pela instalação adicional da
+ plataforma em locais distintos em virtude de aspectos legais e políticos.
+6. Disponibilizar ao Coletivo informações relacionadas aos procedimentos
+ utilizados pelo grupo de trabalho, manutenções e atualizações que foram ou
+ serão efetuadas.
+
+# Responsabilização
+
+É de responsabilização do grupo de trabalho a realização das tarefas
+anteriormente mencionadas. Não é de responsabilidade do presente grupo de
+trabalho:
+
+1. Manter ou entrar em contato com grupos hospedados.
+2. Prestar suporte aos grupos hospedados.
+
+Não é de responsabilidade do presente grupo de trabalho:
+
+1. Pelo funcionamento de cada instância da plataforma.
+
+Em outras palavras, o presente grupo de trabalho não se responsabiliza pelo uso
+de cada instância da plataforma, mas sim pelo funcionamento, atualização e
+auditoria das instalações globais da plataforma, isto é, o grupo de trabalho
+não lida com instâncias específicas da plataforma mas sim com a infra-estrutura
+da mesma.
+
+# Sobre este texto
+
+O texto deste processo foi redigido utilizando o [Template para Grupo de
+Trabalho de Hospedagem](/organizacao/misc/plataforma). No caso de alterações
+que não dizem respeito apenas ao Grupo e que possam enriquecer tal template,
+favor submetê-las também upstream, isto é, ao texto do template.
diff --git a/atividades/provedor/hospedagem/politica.md b/atividades/provedor/hospedagem/politica.md new file mode 100644 index 0000000..b6cdd8d --- /dev/null +++ b/atividades/provedor/hospedagem/politica.md @@ -0,0 +1,47 @@ +# Política de Hospedagem do Coletivo + + Política de Hospedagem do Grupo + ------------------------------- + + 1. O Coletivo reserva para si o poder de hospedar ou deixar de hospedar + qualquer grupo ou indivíduo a partir dos principios e critérios éticos, + politicos e práticos do Coletivo. + + 2. No caso de deixar de hospedar um grupo ou indivíduo, o Coletivo se + compromete a avisar a parte hospedada com antecedência e disponibilizar os + arquivos envolvidos na hospedagem. + + 3. Grupos e indivíduos só são hospedados pelo Coletivo se mostrarem-se + dispostos a uma relação recíproca de troca de conhecimento e atividades. + + 4. Criada a parceria o Coletivo deve ser informado das ações e rumos que cada + projeto toma caso afetem o Coletivo, assim como o Coletivo se compromete a + informar a parte hospedada de qualquer venha a atingi-la. + + 5. Os termos da parceria devem estar claros no sentido de um comprometimento de + ambos os grupos no suporte, manutenção, e desenvolvimento dos sitios e afins + que venham a ser criados por conta da hospedagem. + + 6. A parte hospedada se responsabiliza pelo conteúdo do sitio, não cabendo ao + Coletivo sofrer as consequências jurídicas de conteúdo impróprio ou ilegal. No + entanto, o Coletivo fará o máximo possível para proteger a identidade e a + privacidade da parte hospedada. + + 7. As relações devem se dar de maneira mais transparente possível, não + existindo informação encoberta ou deturpada por ambas as partes. + + 8. As relações tem como finalidade a solidariedade no conhecimento, a + complementariedade nas ações e nas trocas entre os grupos, devendo ser + imprescíndivel maneiras de ensino-aprendizagem mútuos e de políticas que unam + os grupos em prol de uma mudança sócio-política. + + 9. Coletivo se compromete a informar a parte hospedada ao menos em linhas + gerais sobre os critérios e políticas de privacidade e segurança das + plataformas de hospedagem utilizadas pela parte hospedada. + + 10. Hospedagens de movimentos sociais com atividades sensíveis no país são + encaminhadas, quando possível, a plataformas hospedadas no estrangeiro. + + 11. A hospedagem consiste em cooperação e não prestação de serviços. + +[Versão inglesa](/english/hosting/policy). diff --git a/atividades/provedor/hospedagem/recusa.md b/atividades/provedor/hospedagem/recusa.md new file mode 100644 index 0000000..6dfa6e3 --- /dev/null +++ b/atividades/provedor/hospedagem/recusa.md @@ -0,0 +1,28 @@ +# Modelo de carta de recusa de hospedagem + +Este é um modelo de carta para recusa de hospedagem, no caso de projetos que +não concordamos. Para evitar mal entendidos, é importante termos um carta +ponderada e bem esclarecedora. + + Olá $requisitante, + + Infelizmente não poderemos hospedar o projeto que você requisitou porque: + + - Consideramos que ele não se enquadra nos princípios éticos que adotamos[1]. + + - E/ou então consideramos que ele se enquadra nos tipos de projetos com os + quais mantemos uma postura crítica[2]. + + Acreditamos que não exista uma única forma de luta e muito menos que a nossos + princípios éticos e as nossas críticas representem o ponto de vista "correto". + Nosso ponto de vista apenas representa as conclusões que chegamos após muita + discussão. Tentamos apenas nos manter coerentes com o que acreditamos e é por + isso que não podemos efetuar a sua requisição. + + Não queremos de modo algum que isso signifique que estamos desmerecendo a + atuação do seu projeto ou as coisas que você acredita. + + [1] Vide http://encontro.sarava.org/Principal/ConjuntoDePrincipiosEticos + [2] Vide http://wiki.$dominio + +[Versão inglesa](/english/hosting/refusal). diff --git a/atividades/provedor/hospedagem/termo.md b/atividades/provedor/hospedagem/termo.md new file mode 100644 index 0000000..6826af3 --- /dev/null +++ b/atividades/provedor/hospedagem/termo.md @@ -0,0 +1,105 @@ +# Termo de Comprometimento de Hospedagem + + Olá :) + + Termo de Comprometimento de Hospedagem + -------------------------------------- + + Discutimos e estamos de acordo em oferecer hospedagem conforme sua requisição. + Agora, para que possamos efetivamente manter a hospedagem, é preciso: + + 1. Apresentarmos qual é o nosso comprometimento com relação a essa hospedagem. + 2. Que você e/ou seu grupo concordem com o presente termo de compromisso e com + a nossa Política de Hospedagem. + + Estes são os termos de compromisso mútuo, onde explicitamos qual será nosso + comprometimento com a hospedagem em questão pelo qual a parte hospedada precisa + concordar para que seja possível manter tal relação. + + Caso você concorde com os termos desta carta e aceite nossa Política de + Hospedagem, basta responder afirmativamente que sua hospedagem será iniciada + logo que possível. :) + + Nosso comprometimento + --------------------- + + Por essa hospedagem, nos comprometemos a manter a hospedagem em funcionamento. + A manutenção da hospedagem ocorre através de trabalho voluntário e responsável. + + A infra-estrutura utilizada para hospedagem é estável, porém sujeita + a eventuais intempéries da rede ou mesmo a problemas mais graves. + + Por isso, a hospedagem pode ficar fora do ar de vez em quando. Estamos sempre + atentos e prezamos pela segurança e integridade dos dados hospedados. Porém, + por diversos motivos, não podemos garantir a total disponibilidade ou mesmo a + eternidade destes dados. + + Nos comprometemos, na medida do possível, a manter cópias de segurança dos + dados contidos em nossa infra-estrutura. No entanto, pedimos a você que + mantenha, também na medida do possível, cópias de seus arquivos. + + Nosso grupo é formado por pessoas que desempenham uma série de tarefas. As + atividades mais importantes e cruciais, como a hospedagem, dependem de várias + tarefas e cada uma delas está associada a um grupo de trabalho de pessoas + responsáveis pela sua realização. + + Mesmo assim, pessoas podem deixar de trabalhar num dado grupo de trabalho e + eventualmente alguma tarefa não possa mais ser realizada por falta de um mínimo + de pessoas responsáveis por ela. + + É nesse sentido que garantimos o funcionamento e a realização da hospedagem: de + acordo com a força de trabalho disponível no nosso grupo. Por isso, é possível + que, no futuro, aconteça de termos que encerrar a hospedagem numa dada + plataforma. Mas, se o fizermos, garantimos que não será da noite para o dia e + daremos tempo suficiente para que você e seu projeto possam migrar seus dados + para outro local. + + Nos comprometemos também a informar, mediante solicitação, nossos procedimentos + de acordo com nossa política de transparência. Tais procedimentos variam desde + características de privacidade e segurança das plataformas utilizadas como + também da situação do nosso coletivo. + + Como nossos procedimentos podem variar ao longo do tempo, convém a você nos + solicitar as descrições de procedimentos conforme julgar necessário. + + Temos nossas limitações mas na medida do possível manteremos as coisas + funcionando. :) + + Seu comprometimento + ------------------- + + Esperamos de você e do seu projeto que use o recurso oferecido com sabedoria. + Não peça sítios e ferramentas que você deixará abandonadas e, caso você instale + seu próprio programa, tenha a responsabilidade de deixá-lo atualizado, uma vez + que brechas de segurança no seu espaço podem comprometer outros projetos + hospedados. + + Não se esqueça que a manutenção de um sistema de múltiplos projetos é bastante + trabalhosa e dificil de manter segura e por isso pedimos a colaboração de todo + mundo. Se puder nos comunicar quando for instalar algum software no seu espaço, + ficaríamos muito agradecidos/as :) + + Interfaces de comunicação e compartilhamento + -------------------------------------------- + + Um possível espaço de interação entre os projetos é a Lista da Vizinhança[1] + (inscrição apenas para emails seguros, entre em contato para detalhes). + Cultive-a! Ao hospedarmos grupos e indivíduos, torcemos para que estes também + tornem-se responsáveis por zelar por tais espaços de convivência. + + Nossa vizinhança é também um local de articulação de rede, onde todos os grupos + e indivíduos que compartilham da estrutura por nós mantida se comunicam. + + Se os temas e estudos com os quais nos preocupamos também os/as inspiram, nós + os/as convidamos a participar dessas discussões. Para evitar a centralização + das discussões, propomos que vocês os discutam coletivamente, em seus projetos + e/ou grupos, tornando público os processos e resultados de tais discussões. + Para nós é fundamental tentar construir uma metodologia que possibilite a + disseminação pública de tais discussões. + + [1] $endereco_da_lista_da_vizinhanca + + Em solidariedade, + Coletivo $grupo + +[Versão inglesa](/english/hosting/terms). diff --git a/atividades/provedor/mensagens.md b/atividades/provedor/mensagens.md new file mode 100644 index 0000000..e6fb47d --- /dev/null +++ b/atividades/provedor/mensagens.md @@ -0,0 +1,11 @@ +# Mensagens + +Templates para mensagens. + +```eval_rst +.. toctree:: + :maxdepth: 1 + :glob: + + mensagens/* +``` diff --git a/atividades/provedor/mensagens/certs.md b/atividades/provedor/mensagens/certs.md new file mode 100644 index 0000000..34dad96 --- /dev/null +++ b/atividades/provedor/mensagens/certs.md @@ -0,0 +1,28 @@ +# Informe: mudança de certificado + +De acordo com a política[1] de gestão de certificados X.509 usados nas +comunicações TLS/HTTPS e dada a proximidade do vencimento do certificado atual, +o `$coletivo` gerou um novo certificado SSL validado por +`$certificate_authority`. + +A assinatura SHA1 do novo certificado é + + SHA1 Fingerprint=$fingerprint + +Detalhes sobre o certificado estão em https://www.sarava.org/certs + +Tal informação pode ser verificada nas informações de segurança do seu +navegador ao acessar um sítio com conexão segura. Detalhes a respeito podem ser +encontrados no Manual de Criptografia[2]. + +O certificado é válido para o domínio sarava.org e todos os seus subdomínios. +Assim, está sendo utilizada conexão segura por padrão na maioria dos +subdomínios de `$dominio` (por exemplo `www.$dominio`). + +No entanto, alguns sítios ainda podem estar sem conexão criptografada ou +oferecerem links internos utilizando http. + +Em caso de dúvidas, basta entrar em contato :) + +[1] https://protocolos.fluxo.info/organizacao/comunicacao/cert/ +[2] https://manual.fluxo.info/criptografia/internet diff --git a/atividades/provedor/mensagens/downtime.md b/atividades/provedor/mensagens/downtime.md new file mode 100644 index 0000000..d8f9add --- /dev/null +++ b/atividades/provedor/mensagens/downtime.md @@ -0,0 +1,37 @@ +# Modelo de informe de downtime + +Português +--------- + +Estamos com uma queda inesperada de um de nossos servidores. + +Assim, alguns serviços ficarão inacessíveis nas próximas horas. + + Servidor : servidor.example.org + Problema : não identificado + Tempo estimado : 72 horas + Serviços afetados : + - Todas as listas de discussão. + - Contas de email. + - Todos os vservers hospedados para terceiros/as. + - Todos os sites hospedados nesse servidor. + +Outros serviços e servidores não estão afetados. + +English +------- + +We're having an unexpected downtime in one of our servers. + +Then, some services will be unreachable in the next hours. + + Server : servidor.example.org + Problem : N/A + Expected downtime : 72 hours + Services affected : + - All mailing lists. + - Email accounts. + - All third-party hosted vservers. + - All websites hosted in the server. + +Other servers and services are unaffected. diff --git a/atividades/provedor/servidor.md b/atividades/provedor/servidor.md new file mode 100644 index 0000000..b1415af --- /dev/null +++ b/atividades/provedor/servidor.md @@ -0,0 +1,72 @@ +# Administração do $servidor
+
+Este processo estabelece os critérios de administração do `$servidor`,
+doravante mencionado como `$servidor`, canalizador de fluxos ou simplesmente
+como servidor.
+
+# Classes RSP
+
+O servidor deve estar configurado de acordo com as seguintes classes do
+[Resource Sharing Protocol](https://rsp.fluxo.info):
+
+* `$classe` - `$classe_versao`.
+
+# Política de Administração
+
+0. Criação de Usuários:
+ a. Qualquer integrante do Coletivo pode ter uma conta no servidor, mas caso
+ tenha deve zelar pela segurança da mesma e concordar com a presente política.
+ b. A criação de usuários no servidor deve ser comunicada ao Coletivo e
+ seguir eventuais procedimentos existentes.
+ c. A senha da conta no servidor não pode ser compartilhada com outras contas
+ e deve ser razoavelmente forte.
+ d. Em caso de perda ou roubo de senha, o Grupo de Trabalho do servidor deve
+ ser contatado o quanto antes.
+
+1. Configuração: ao instalar ou efetuar qualquer tipo de configuração na máquina, procure:
+ a. Adicionar, se possível e/ou necessário, a configuração em sistema de
+ gestão servidores que o Coletivo utiliza.
+ b. Documentar os procedimentos utilizados ou informe ao Grupo de Trabalho do servidor.
+
+3. Comunicação: na medida do possível, comunique o Grupo de Trabalho do
+ servidor sobre alterações feitas na sua configuração configuração.
+
+# Quota
+
+O Coletivo alocará para si, em princípio, um limite garantido de `$disco` de
+espaço em disco no servidor. Toda a quantidade adicional de disco existente no
+servidor pode ser disponibilizada para outros grupos afins, mediante processo
+formal e sem garantias de backup.
+
+Quotas de uso de banda, processamento e memória ficam a cargo do Grupo de
+Trabalho do servidor ou de todo o Coletivo conforme necessidade ou mediante
+requisição.
+
+# Responsabilização
+
+Cabe ao Grupo de Trabalho formado pelas pessoas responsáveis por este processo
+seguir a política de administração e ainda:
+
+* Zelar para que o servidor possua o nível de segurança, privacidade e
+ estabilidade escolhidas.
+* Cuidar para que o downtime do servidor não passe de `$downtime`.
+* Efetuar as atualizações de softwares necessárias para o funcionamento básico
+ do servidor.
+
+A responsabilização neste processo não implica o compromisso com a
+administração de todas as camadas, aplicações, configurações e dados que
+existam ou possam existir no servidor, mas apenas com o funcionamento básico do
+servidor.
+
+# Dependências
+
+A realização deste processo depende da realização dos seguintes processos:
+
+* `$dependencia`.
+
+# Sobre este texto
+
+O texto deste processo foi redigido utilizando o [Template para Administração
+de Servidor](/provedor/servidor). No caso de alterações que não dizem respeito
+apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também
+upstream, isto é, ao texto do template.
diff --git a/atividades/provedor/sistemas.md b/atividades/provedor/sistemas.md new file mode 100644 index 0000000..4e076ab --- /dev/null +++ b/atividades/provedor/sistemas.md @@ -0,0 +1,72 @@ +# Configuração de sistemas padronizada e centralizada + +```eval_rst +.. toctree:: + :maxdepth: 1 + :glob: + + sistemas/* +``` + +O presente processo estabelece o funcionamento de uma configuração de sistemas +padronizada e centralizada. Levando em conta que o Coletivo pode lidar com +muitas camadas de canalização informacional, cada um com diversos serviços +configurados, backups locais e remotos e outras especificidades, torna-se +interessante desenvolver um esquema de configuração centralizada, de forma a +tornar fácil a manutenção, replicação e substituição dos ambientes assim como o +compartilhamento de configurações com outros grupos. + +## Divisão de configuração e compartilhamento + +A configuração dos sistemas é dividida da seguinte forma: + +1. Especificação de camadas via [Resource Sharing Protocol + (RSP)](https://rsp.fluxo.info) de acordo com as necessidades e possibilidades + do Coletivo. +2. Configuração efetiva dos sistemas através de aplicação especializada. + +## Compartilhamento de configurações + +No que concerne ao compartilhamento das configurações, a seguinte divisão é +utilizada: + +1. Repositório privado, de acesso restrito ao Coletivo e contendo informações e + configurações cuja publicização é prejudicial ou desnecessária do Coletivo. +2. Repositório público de configurações, denominado de + [http://padrao.sarava.org Padrão Saravá], contendo as configurações cuja + publicização auxilia no intercâmbio com outros grupos. + +Ambos os repositórios devem utilizar controle de versão e o Coletivo ainda é +encorajado a utilizar configurações disponibilizadas por outros grupos, unindo +assim esforços para a economizar trabalho. + +## Implementação + +A configuração efetiva deve ser obtida através do uso de um sistema como o +[Puppet](http://puppetlabs.com), por ter diversos módulos disponíveis, uma +linguagem de configuração bastante flexível e uma comunidade próxima que já o +utiliza. + +As seguintes características de implementação devem ser satisfeitas: + +1. O repositório e o servidor `puppetmaster` devem rodar a partir de uma + instância cuja configuração de camadas é a mais segura do Coletivo e os dados + devem estar disponíveis somente via conexão segura. +2. O repositório '''deve''' ter backups em diversos locais. +3. O controle de versão utilizado para os módulos e demais configurações do `puppet` é o `git`. +4. O `puppet` deve estar rodando no maior número possível de camadas do + Coletivo e obtendo suas configurações do `puppetmaster`. + +## Responsabilização + +É tarefa do Grupo de Trabalho de Configurações, composto pelas pessoas +responsáveis pelo presente processo: + +1. Manter o máximo possível de configurações de sistemas do Coletivo segundo os + critérios estabelecidos no presente processo. +2. Realizar auditoriais periódicas (com base anual) seguida relatório e + atualização da configuração dos sistemas conforme necessário. +3. Manter um [padrão de configuração](https://padrao.fluxo.info) atualizado e + em funcionamento. +4. Alterar, na medida do possível, a configuração dos sistemas e documentações + relacionadas conforme solicitações do Coletivo. diff --git a/atividades/provedor/sistemas/dns.md b/atividades/provedor/sistemas/dns.md new file mode 100644 index 0000000..14404d5 --- /dev/null +++ b/atividades/provedor/sistemas/dns.md @@ -0,0 +1,19 @@ +# Administração de configurações de DNS dos domínios do Coletivo + +Este processo estabelece as linhas gerais para a administração de configurações +DNS dos domínios do Coletivo. + +# Tarefas + +Cabe ao Grupo de Trabalho formado pelas pessoas responsáveis pelo presente +processo: + +1. Manter a configuração de DNS dos domínios do observando os critérios de + segurança cabíveis. +2. Atender as requisições do Coletivo de mudanças de configuração de DNS. + +## Dependências + +A realização deste processo depende da realização dos seguintes processos: + +* [Gerenciamento de domínios](/provedor/sistemas/dominios). diff --git a/atividades/provedor/sistemas/dominios.md b/atividades/provedor/sistemas/dominios.md new file mode 100644 index 0000000..a002e5b --- /dev/null +++ b/atividades/provedor/sistemas/dominios.md @@ -0,0 +1,41 @@ +# Gerenciamento de domínios + +Os domínios utilizados pelo Coletivo constituem seu ''namespace'' no qual podem +definir endereços de acesso público e privado. Sendo indispensáveis para a +autonomia básica do Coletivo e para a possibilidade de hospedagem de outros +grupos, o gerenciamento de domínios constitui um processo de garantia dessa +autonomia, especialmente se levado em conta que o DNS é um sistema +centralizado, pouco transparente, anti-democrático e de tendência +centralizante. + +O presente processo estabelece um grupo de trabalho para o gerenciamento de +domínios, cujas tarefas envolvem: + +1. Renovação dos domínios com '''antecedência''' ao prazo de vencimento da + mesma, solicitando ao grupo de contabilidade os gastos necessários para cumprir + tal tarefa. +2. Aplicação de política de privacidade e segurança à configuração dos + domínios, incluindo auditoria periódica para a verificação dessas + configurações. +3. Registro de novos domínios conforme a necessidade e formalização pelo Coletivo. +4. Manter o Coletivo informado sobre essas tarefas. + +## Responsabilização + +As pessoas responsabilizadas por esse grupo de trabalho precisam ter condições +de realizar operações financeiras internacionais com cartão de crédito. + +## Domínios do Coletivo + +Os domínios do Coletivo são: + +* domínio1 +* domínio2 + +Vale observar que: + +1. Outros domínios podem ser adicionados na lista mediante procedimento formal + para a alteração da mesma. +2. Por esse processo fica automaticamente aprovado o gasto de recursos + financeiros do Coletivo para o pagamento da renovação/registro dos domínios do + Coletivo. |