From 72ec7b2e57794c7bebb6bd44ba4089312409adf9 Mon Sep 17 00:00:00 2001 From: Silvio Rhatto Date: Sun, 17 Jan 2021 15:57:49 -0300 Subject: Feat: refactor, cleanup and organize --- provedor/backups.md | 54 ------------ provedor/backups/entrega.md | 93 -------------------- provedor/cert.md | 176 -------------------------------------- provedor/hospedagem.md | 72 ---------------- provedor/hospedagem/carta.md | 73 ---------------- provedor/hospedagem/database.md | 16 ---- provedor/hospedagem/plataforma.md | 45 ---------- provedor/hospedagem/politica.md | 47 ---------- provedor/hospedagem/recusa.md | 28 ------ provedor/hospedagem/termo.md | 105 ----------------------- provedor/servidor.md | 72 ---------------- provedor/sistemas.md | 72 ---------------- provedor/sistemas/dns.md | 19 ---- provedor/sistemas/dominios.md | 41 --------- 14 files changed, 913 deletions(-) delete mode 100644 provedor/backups.md delete mode 100644 provedor/backups/entrega.md delete mode 100644 provedor/cert.md delete mode 100644 provedor/hospedagem.md delete mode 100644 provedor/hospedagem/carta.md delete mode 100644 provedor/hospedagem/database.md delete mode 100644 provedor/hospedagem/plataforma.md delete mode 100644 provedor/hospedagem/politica.md delete mode 100644 provedor/hospedagem/recusa.md delete mode 100644 provedor/hospedagem/termo.md delete mode 100644 provedor/servidor.md delete mode 100644 provedor/sistemas.md delete mode 100644 provedor/sistemas/dns.md delete mode 100644 provedor/sistemas/dominios.md (limited to 'provedor') diff --git a/provedor/backups.md b/provedor/backups.md deleted file mode 100644 index c671152..0000000 --- a/provedor/backups.md +++ /dev/null @@ -1,54 +0,0 @@ -# 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/provedor/backups/entrega.md b/provedor/backups/entrega.md deleted file mode 100644 index c2cfb75..0000000 --- a/provedor/backups/entrega.md +++ /dev/null @@ -1,93 +0,0 @@ -# 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/provedor/cert.md b/provedor/cert.md deleted file mode 100644 index dcf62a8..0000000 --- a/provedor/cert.md +++ /dev/null @@ -1,176 +0,0 @@ -# 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/provedor/hospedagem.md b/provedor/hospedagem.md deleted file mode 100644 index bf8b4ce..0000000 --- a/provedor/hospedagem.md +++ /dev/null @@ -1,72 +0,0 @@ -# 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/provedor/hospedagem/carta.md b/provedor/hospedagem/carta.md deleted file mode 100644 index 10d7f75..0000000 --- a/provedor/hospedagem/carta.md +++ /dev/null @@ -1,73 +0,0 @@ -# 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/provedor/hospedagem/database.md b/provedor/hospedagem/database.md deleted file mode 100644 index c869bb3..0000000 --- a/provedor/hospedagem/database.md +++ /dev/null @@ -1,16 +0,0 @@ -# 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/provedor/hospedagem/plataforma.md b/provedor/hospedagem/plataforma.md deleted file mode 100644 index 322296e..0000000 --- a/provedor/hospedagem/plataforma.md +++ /dev/null @@ -1,45 +0,0 @@ -# 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/provedor/hospedagem/politica.md b/provedor/hospedagem/politica.md deleted file mode 100644 index b6cdd8d..0000000 --- a/provedor/hospedagem/politica.md +++ /dev/null @@ -1,47 +0,0 @@ -# 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/provedor/hospedagem/recusa.md b/provedor/hospedagem/recusa.md deleted file mode 100644 index 6dfa6e3..0000000 --- a/provedor/hospedagem/recusa.md +++ /dev/null @@ -1,28 +0,0 @@ -# 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/provedor/hospedagem/termo.md b/provedor/hospedagem/termo.md deleted file mode 100644 index 6826af3..0000000 --- a/provedor/hospedagem/termo.md +++ /dev/null @@ -1,105 +0,0 @@ -# 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/provedor/servidor.md b/provedor/servidor.md deleted file mode 100644 index b1415af..0000000 --- a/provedor/servidor.md +++ /dev/null @@ -1,72 +0,0 @@ -# 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/provedor/sistemas.md b/provedor/sistemas.md deleted file mode 100644 index 4e076ab..0000000 --- a/provedor/sistemas.md +++ /dev/null @@ -1,72 +0,0 @@ -# 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/provedor/sistemas/dns.md b/provedor/sistemas/dns.md deleted file mode 100644 index 14404d5..0000000 --- a/provedor/sistemas/dns.md +++ /dev/null @@ -1,19 +0,0 @@ -# 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/provedor/sistemas/dominios.md b/provedor/sistemas/dominios.md deleted file mode 100644 index a002e5b..0000000 --- a/provedor/sistemas/dominios.md +++ /dev/null @@ -1,41 +0,0 @@ -# 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. -- cgit v1.2.3