diff options
Diffstat (limited to 'provedor')
| -rw-r--r-- | provedor/backups.md | 40 | ||||
| -rw-r--r-- | provedor/backups/entrega.md | 45 | ||||
| -rw-r--r-- | provedor/cert.md | 129 | ||||
| -rw-r--r-- | provedor/hospedagem.md | 67 | ||||
| -rw-r--r-- | provedor/hospedagem/carta.md | 4 | ||||
| -rw-r--r-- | provedor/hospedagem/plataforma.md | 46 | ||||
| -rw-r--r-- | provedor/hospedagem/recusa.md | 4 | ||||
| -rw-r--r-- | provedor/servidor.md | 65 | ||||
| -rw-r--r-- | provedor/sistemas.md | 73 | ||||
| -rw-r--r-- | provedor/sistemas/dns.md | 13 | ||||
| -rw-r--r-- | provedor/sistemas/dominios.md | 41 |
11 files changed, 358 insertions, 169 deletions
diff --git a/provedor/backups.md b/provedor/backups.md index 88e4173..6b87420 100644 --- a/provedor/backups.md +++ b/provedor/backups.md @@ -1,10 +1,15 @@ [[!meta title="Grupo de Trabalho de 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. +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 == +## 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: +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, @@ -13,24 +18,29 @@ 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 [http://rsp.sarava.org RSP], 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. +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 == +## Otimização de parâmetros -O grupo de trabalho deve ainda otimizar os seguintes parâmetros ao propiciar a realização de backups: +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. +1. Periodicidade. +2. Incrementos. +3. Largura de banda. +4. Segurança e integridade. +5. Espaço em disco. -== Auditagem == +## Auditagem -O grupo de trabalho deve também realizar [wiki:Backups/Auditagem 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. +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 == +## Dependências A realização deste processo depende da realização dos seguintes processos: - * [wiki:Comunicacao/Politica Política de segurança da informação]. +* [Política de segurança da informação](/coletivo/comunicacao/acl). diff --git a/provedor/backups/entrega.md b/provedor/backups/entrega.md index 860532c..668c851 100644 --- a/provedor/backups/entrega.md +++ b/provedor/backups/entrega.md @@ -1,34 +1,47 @@ [[!meta title="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: +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. +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. +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). +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: +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. +* 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. diff --git a/provedor/cert.md b/provedor/cert.md index d66061f..10ff30c 100644 --- a/provedor/cert.md +++ b/provedor/cert.md @@ -1,69 +1,109 @@ [[!meta title="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. +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 +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. + 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. +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). +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). +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. +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/). +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: @@ -113,11 +153,24 @@ 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 chaves de acesso, utilizando para isso OpenPGP. Como exemplo, manter uma página pública e atualizada sobre os atuais certificados utilizados e também informar grupos 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.sarava.org/?p=puppet-ssl.git;a=summary 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]. +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 index 6f1ecc4..310fef7 100644 --- a/provedor/hospedagem.md +++ b/provedor/hospedagem.md @@ -1,39 +1,64 @@ [[!meta title="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: +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. +1. Grupo de trabalho de uma dada plataforma. +2. Grupo responsável por uma dada hospedagem. -= Necessidade de formalização = +## 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. +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. +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 = +## 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. +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. +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 = +## 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. +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. +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 = +## 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. +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 index e959ff0..0136326 100644 --- a/provedor/hospedagem/carta.md +++ b/provedor/hospedagem/carta.md @@ -1,6 +1,8 @@ [[!meta title="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. +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 -------------------------------- diff --git a/provedor/hospedagem/plataforma.md b/provedor/hospedagem/plataforma.md index 993ee1b..0e6b864 100644 --- a/provedor/hospedagem/plataforma.md +++ b/provedor/hospedagem/plataforma.md @@ -1,27 +1,45 @@ [[!meta title="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.
+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:
+É 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.
+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.
+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.
+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.
+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/recusa.md b/provedor/hospedagem/recusa.md index cf3eb07..2c86170 100644 --- a/provedor/hospedagem/recusa.md +++ b/provedor/hospedagem/recusa.md @@ -1,6 +1,8 @@ [[!meta title="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. +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, diff --git a/provedor/servidor.md b/provedor/servidor.md index e8dfa76..8ad8278 100644 --- a/provedor/servidor.md +++ b/provedor/servidor.md @@ -1,49 +1,72 @@ [[!meta title="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.
+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 [wiki:Camadas/RSP Resource Sharing Protocol]:
+O servidor deve estar configurado de acordo com as seguintes classes do
+[Resource Sharing Protocol](https://rsp.fluxo.info):
- * `$classe` - `$classe_versao`.
+* `$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.
+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.
+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.
+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.
+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.
+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:
+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.
+* 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.
+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`.
+* `$dependencia`.
# Sobre este texto
-O texto deste processo foi redigido utilizando o [wiki:PageTemplates/AdministracaoDeServidor Template para Administração de 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.
+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 index dc1b1a3..5e41c16 100644 --- a/provedor/sistemas.md +++ b/provedor/sistemas.md @@ -2,40 +2,65 @@ [[!map pages="page(organizacao/provedor/sistemas*)" show="title"]] -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. +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 = +## Divisão de configuração e compartilhamento A configuração dos sistemas é dividida da seguinte forma: - 1. Especificação de camadas via [http://rsp.sarava.org Resource Sharing Protocol] (RSP) de acordo com as necessidades e possibilidades do Coletivo. - 2. Configuração efetiva dos sistemas através de aplicação especializada. +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 = +## Compartilhamento de configurações -No que concerne ao compartilhamento das configurações, a seguinte divisão é utilizada: +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. +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. +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 = +## Implementação -A configuração efetiva deve ser obtida através do uso do [http://reductivelabs.com/trac/puppet/ Puppet], por ter diversos módulos disponíveis, uma linguagem de configuração bastante flexível e uma comunidade próxima que já o utiliza. +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 o [http://padrao.sarava.org Padrão Saravá] 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. +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 index 76a76d0..f7bc6aa 100644 --- a/provedor/sistemas/dns.md +++ b/provedor/sistemas/dns.md @@ -1,16 +1,19 @@ [[!meta title="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. +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: +Cabe ao Grupo de Trabalho formado pelas pessoas responsáveis pelo presente +processo: - 1. Manter a configuração de DNS dos [wiki:Camadas/Dominios domínios do Coletivo] observando os critérios de segurança cabíveis. - 2. Atender as requisições do Coletivo de mudanças de configuração de DNS. +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: -* [wiki:Camadas/Dominios Gerenciamento de domínios]. +* [Gerenciamento de domínios](/provedor/sistemas/dominios). diff --git a/provedor/sistemas/dominios.md b/provedor/sistemas/dominios.md index 98d2ca8..0d2c661 100644 --- a/provedor/sistemas/dominios.md +++ b/provedor/sistemas/dominios.md @@ -1,26 +1,41 @@ [[!meta title="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. +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: +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. +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 = +## 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. +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 = +## Domínios do Coletivo Os domínios do Coletivo são: - * domínio1 - * domínio2 +* 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. +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. |