From 292e82a09395782aa9d26056158216470120bfc3 Mon Sep 17 00:00:00 2001 From: Silvio Rhatto Date: Sat, 26 Nov 2016 13:46:02 -0200 Subject: More organizing --- etica.mdwn | 95 +----------------- etica/coletiva.mdwn | 48 ++++++++++ etica/pessoal.mdwn | 96 +++++++++++++++++++ index.mdwn | 2 +- organizacao/comunicacao/cert.mdwn | 122 ------------------------ organizacao/contabilidade/criterios.mdwn | 24 ++--- organizacao/provedor.mdwn | 3 - organizacao/provedor/backups.mdwn | 36 ------- organizacao/provedor/backups/entrega.mdwn | 80 ---------------- organizacao/provedor/hospedagem.mdwn | 39 -------- organizacao/provedor/hospedagem/carta.mdwn | 71 -------------- organizacao/provedor/hospedagem/plataforma.mdwn | 27 ------ organizacao/provedor/hospedagem/politica.mdwn | 47 --------- organizacao/provedor/hospedagem/recusa.mdwn | 26 ----- organizacao/provedor/hospedagem/termo.mdwn | 105 -------------------- organizacao/provedor/servidor.mdwn | 49 ---------- organizacao/provedor/sistemas.mdwn | 41 -------- organizacao/provedor/sistemas/dns.mdwn | 16 ---- organizacao/provedor/sistemas/dominios.mdwn | 26 ----- provedor.mdwn | 3 + provedor/backups.mdwn | 36 +++++++ provedor/backups/entrega.mdwn | 80 ++++++++++++++++ provedor/cert.mdwn | 122 ++++++++++++++++++++++++ provedor/hospedagem.mdwn | 39 ++++++++ provedor/hospedagem/carta.mdwn | 71 ++++++++++++++ provedor/hospedagem/plataforma.mdwn | 27 ++++++ provedor/hospedagem/politica.mdwn | 47 +++++++++ provedor/hospedagem/recusa.mdwn | 26 +++++ provedor/hospedagem/termo.mdwn | 105 ++++++++++++++++++++ provedor/servidor.mdwn | 49 ++++++++++ provedor/sistemas.mdwn | 41 ++++++++ provedor/sistemas/dns.mdwn | 16 ++++ provedor/sistemas/dominios.mdwn | 26 +++++ 33 files changed, 844 insertions(+), 797 deletions(-) create mode 100644 etica/coletiva.mdwn create mode 100644 etica/pessoal.mdwn delete mode 100644 organizacao/comunicacao/cert.mdwn delete mode 100644 organizacao/provedor.mdwn delete mode 100644 organizacao/provedor/backups.mdwn delete mode 100644 organizacao/provedor/backups/entrega.mdwn delete mode 100644 organizacao/provedor/hospedagem.mdwn delete mode 100644 organizacao/provedor/hospedagem/carta.mdwn delete mode 100644 organizacao/provedor/hospedagem/plataforma.mdwn delete mode 100644 organizacao/provedor/hospedagem/politica.mdwn delete mode 100644 organizacao/provedor/hospedagem/recusa.mdwn delete mode 100644 organizacao/provedor/hospedagem/termo.mdwn delete mode 100644 organizacao/provedor/servidor.mdwn delete mode 100644 organizacao/provedor/sistemas.mdwn delete mode 100644 organizacao/provedor/sistemas/dns.mdwn delete mode 100644 organizacao/provedor/sistemas/dominios.mdwn create mode 100644 provedor.mdwn create mode 100644 provedor/backups.mdwn create mode 100644 provedor/backups/entrega.mdwn create mode 100644 provedor/cert.mdwn create mode 100644 provedor/hospedagem.mdwn create mode 100644 provedor/hospedagem/carta.mdwn create mode 100644 provedor/hospedagem/plataforma.mdwn create mode 100644 provedor/hospedagem/politica.mdwn create mode 100644 provedor/hospedagem/recusa.mdwn create mode 100644 provedor/hospedagem/termo.mdwn create mode 100644 provedor/servidor.mdwn create mode 100644 provedor/sistemas.mdwn create mode 100644 provedor/sistemas/dns.mdwn create mode 100644 provedor/sistemas/dominios.mdwn diff --git a/etica.mdwn b/etica.mdwn index 3579d5a..6717c6a 100644 --- a/etica.mdwn +++ b/etica.mdwn @@ -1,96 +1,3 @@ [[!meta title="Ética"]] -Motivação ---------- - -Código é lei? Código pode também ser ética. Se existem [protocolos](https://protocolos.fluxo.info) e [códigos de conduta](https://www.debian.org/vote/2014/vote_002) atuando no nível de grupos, é importante também haver procedimentos de auxílio para relações em nível individual. - -Pressupostos ------------- - -* Como cantou Daminhão Experiência, "O mundo foi bem feito / todo mundo tem defeito". -* Saber quando pisar dentro e fora do quadrado. -* Noções básicas de postura social. - -Cuidados --------- - -Não é a intenção deste breve guia: - -* Se transformar numa rocha inalterável e inflexível de como as relações humanas devem ser. -* Criar um protocolo que dificulte relações e deixe as pessoas apartadas. - -Este guia é mais uma referências de aspectos a serem pensados em relações com pessoas. - -Objetivos ---------- - -Grosso modo: - -* Calma. -* Alegria. -* Agilidade. -* Sangue-bonismo. -* Companheirismo. -* Solidariedade, fraternidade, alteridade, autruísmo. - -Pisando no quadrado -------------------- - -Este é um checklist de procedimentos e código de conduta. Você tem uma ideia de como se portar em cada um desses items? - -* Comunicação implícita e explícita: - * O que pode ser assumido de antemão. - * O que não pode ser assumido de antemão. -* Separação entre aspectos da vida: - * Profissional, político e pessoal. - * Amizades e afinidades. - * Público e privado. -* Lidando com conhecimento: - * Criando um canal e um encorajamento explícito para contatos, sugestões e críticas. - * Fomentando a formação e a inclusão de mais pessoas no ativismo técnico e na difusão do conhecimento. - * Tendo uma melhor comunicação com grupos e pessoas próximas. - * Definir melhor e de forma pública o funcionamento e a participação. -* Relacionamento: - * [Alteridade](http://www.revolucoes.org.br/v1/conferencia/alteridade). - * Generosidade. - * Alimentação. - * Liberdade de associação e de não-associação, tanto para propósitos gerais quanto específicos. - * Responsabilidade e zelo. - * Buscar facilitar as relações e situações, ao invés de dificultar a fluidez dos relacionamentos. - * Comportamentos evitados: trolling, bullying, spamming, etc. - * Gentileza gera gentileza. - * Proceder: humildade, respeito, responsa. - * Assiduidade, pontualidade e atrasos. - * Política de assinatura de chaves. - * Participação em debates e discussões. - * Favores e reciprocidade. - * Fidelidade (compromisso) e lealdade (espontâneo). - * Sobre a confiança (contextual e total) e a alteridade. - * Pronomes de tratamento e linguagem inclusiva. - * Discussão, facilitação, opiniões (e mudança de opiniões), respeito a rodadas e falas: - * Discussão de temas em geral. - * Discussão periódica da relação. - * Comunicação mediada (virtual): - * [Netiqueta](https://tools.ietf.org/html/rfc1855). - * Lei de [Postel](https://en.wikipedia.org/wiki/Jon_Postel): "Be liberal in what you accept, and conservative in what you send". - * Como lidar com ausência de resposta. - * Como a ausência de resposta é interpretada. - * Assuntos públicos, semi-públicos e privados: como lidar com mensagens privadas evitando concentração de informação e canais laterais que possam prejudicar organizações horizontais. - * Emoticons, cordialidade e polidez. - * Quando assinar comunicação, quando não assinar, modo anônimo. - * Comunicação ao vivo: - * Pronomes. - * Cumprimentos (aperto de mão, beijo, saudação). -* Sistematizando formas de lidar com situações diversas: - * [Defence mechanisms](https://en.wikipedia.org/wiki/Defence_mechanisms). - * Círculo Restaurativo. - * Comunicação não-violenta. - * Linguagem inclusiva. - * Situações críticas: como não reproduzir instituições burguesas (tribunal, prisão, manicômio) ou arcaicas (ostracismo, linchamento, etc)? - * Facilitação e resolução de conflitos. - * [Conflito e Consenso](https://docs.indymedia.org/Local/CmiBrasilConflitoConsenso). - * [Conflict resolution](https://simple.wikipedia.org/wiki/Conflict_resolution). - * Referências - * [General Resolution: code of conduct](https://www.debian.org/vote/2014/vote_002). - * [Código de conduta da SquatConf](https://github.com/squatconf/organisation/blob/master/code_of_conduct.md#squatconf-code-of-conduct). +[[!map pages="page(etica*)" show="title"]] diff --git a/etica/coletiva.mdwn b/etica/coletiva.mdwn new file mode 100644 index 0000000..525bd16 --- /dev/null +++ b/etica/coletiva.mdwn @@ -0,0 +1,48 @@ +[[!meta title="Conjunto de Princípios Éticos"]] + +Baseado nos [princípios das mídias e grupos livres](https://encontro.fluxo.info/Principal/ConjuntoDePrincipiosEticos). + +0. Sobre a mobilidade dos princípios: Todos os princípios podem ser a qualquer momento modificados ou abandonados desde que não sejam mais a expressão imanente das relações que se constituem através das ações coletivas. + +1. Sobre a autonomia: grupos e mídias livres renunciam e se recusam a recorrer a qualquer entidade política que não a si próprias para constituir sua legalidade e sua normatividade, por acreditar que a sua única fonte legítima é sua emergencia a partir dos laços de confiança e solidarieade entre participantes e de cada participante com os coletivos por eles constituídos. + +2. Sobre a apropriação pública: As mídias e os grupos livres defendem e promovem a apropriação pública dos meios de produção (rejeita a sua apropriação privada) e, em específico dos meios de produção de bens simbólicos e culturais e aos produtos do trabalho intelectual e imaterial. + +3. Sobre o licenciamento: As mídias e os grupos livres usam licenciamento livre, apoiam explicitamente os novos direitos autorais e consideram especialmente inaceitável a apropriação privada do trabalho intelectual / imaterial. aqui, bem que podia aparecer alguma vinculação das licenças com propostas de escambo, economia solidária, moeadas locais, permacultura, comércio justo... tipo: inventar uma licença que permitisse a circulação em sistemas de mercado não-capitalistas. Talvez, exigindo para isso o consentimento (tácito?) dos envolvidos + +4. Sobre o acesso público: As mídias e os grupos livres criam plataformas de comunicação mediática e espaços simbólicos de acesso público em que se rejeita absolutamente a monopolização vertical da produção mediática; embora estabeleçam princípios éticos e políticos para o acesso aos suportes, não há controle sobre a produção de "conteúdo", permitindo que uma pluralidade de organizações possam se utilizar dos mesmos canais de comunicação. + +5. Sobre a diversidade: As mídias e os grupos livres visam aumentar a diversidade dos pontos de vista e estimular o debate argumentativo, recusa apoiar práticas da política institucional e veda o proselitismo religioso, político-institucional e/ou propaganda comercial. + +6. Sobre a gestão: As mídias e os grupos livres usam e desenvolvem sistematicamente mecanismos de gestão anti-hierárquicos e baseados na geração de consensos a partir da argumentação pública; ou seja, rejeitam (ou evitam ao máximo), como práticas de organização: a representação política e a votação plebiscitária. A divisão funcional é adotada com ponderação, sob avaliação coletiva e de maneira ocasional. + +7. Sobre as invenções: As mídias e os grupos livres propiciam e estimulam a invenção estética, tecnológica e política, na medida em que tomam a organização social, a cultura e o corpo como realidades dignas de serem transformados e aperfeiçoados. Nesse sentido, as mídias e os grupos livres defendem a liberdade de conhecimento e de acesso a ele; para contribuir com a concretização destas liberdades, as mídias e os grupos livres incentivam o uso de softwares livres e a publicação em formatos livres (.ogg para áudio, .png para imagens, etc.) e em, caso isso não seja possível, em formatos proprietários mas que sejam públicos (.rtf e .pdf para textos, .mpg para vídeos, etc.). As mídias e os grupos livres não incentivam o uso de formatos proprietários (.doc para texto, .ppt para apresentação de slides, etc.). + +8. Sobre as pesquisas e as metodologias: As mídias e os grupos livres promovem a pesquisa, o desenvolvimento e pratica de metodologias para a apropriação dos recursos de comunicação pelos públicos, através do que buscam transformar em práticas cotidianas dos cidadãos a produção de comunicação mediática e o seu uso público político. + +9. Sobre a expansão e a organização em redes: A lógica de expansão das mídias e grupos livres segue a de formação dos rizomas (e não da árvores): formam novas organizações quando o contingente de participantes aumenta, adensam as interconexões (comunicação lateral) entre as organizações e evitam que indivíduos e grupos de influência se coloquem no lugar de intermediários políticos. + +10. Sobre doações: Se recebem dinheiro, o fazem apenas como doação, ou seja: qualquer apoiador deve saber que seus recursos não serão empregados senão para os fins estritos de criação de espaços comunicativos livres, sendo vedadas as práticas de mercantismo cultural, social ou político. Tais doações são aceitas apenas se anônimas (isto é, não publicizadas). Dinheiro governamental ou empresarial não é aceito. + +11. Sobre auto-sustentabilidade: As mídias e grupos livres estimulam a geraçãoo de mecanismos de autosustentabilidade (ou "autodependência") local e comunitária. Exemplos: venda de camisetas, comidas, rifas, organização de festas, mostra de videos, etc. Tratam-se de atividades criadas e organizadas para estimular a vivência em coletivo e a escapar das práticas capitalistas. É recomendável que, dentro dos grupos e entre eles, exista uma socialização dos recursos e que os individuos também adotem essa prática, compartilhando recursos pessoais com o coletivo, para criar ambientes de solidariedade comunitária, onde ninguém seja excluído por falta de recursos. + +12. Sobre a gestão financeira: Para garantir essas condições de financiamento, toda a gestão financeira das mídias e grupos livres é publica: tanto as informações contábeis quanto a participação nas decisões são acessíveis às pessoas concernidas nas ações desta organização. + +13. Sobre a privacidade: As mídias e os grupos livres defendem a inviolabilidade da intimidade e a privacidade do indivíduo, especialmente contra sua exploração capitalista, por meio de dispositivos de identificação de padrões comportamentais. No caso da implementação de sistemas emergentes de identificação de padrões de uso nas plataformas das mídias e grupos livres, todos os concernidos têm pleno acesso ao seu funcionamento e os podem alterar sempre que desejarem (através de processos de formação argumentativa de consensos, vide acima). + +14. Sobre a espetacularização: As mídias e os grupos livres não se utilizam da espetacularização ou maravilhização. Quer dizer, realmente estamos precisados de conceituar e expressar verbalmente o que estamos tomando sob "espetacularização" e "maravilhização": quase a totalidade dos grupos de hoje trabalham demais com a espetacularização: as ações que escolhem são as mais espetacularizadas possíveis (tanto é que não vemos os grupos trabalharem com a mesma intensidade em coisas de base ou em estrutura), eles tem uma preocupação imensa em mostrar o que estão fazendo, em trabalhar com mídia, etc. Isso deve ser uma herança da dita mídia tática e de mais um monte de coisa e acho que deveriam ser analisados, tem que ter uma crítica. Porque às vezes os logotipos parecem surgir antes mesmo das ações. + +15. Sobre uma sociedade livre: As mídias e os grupos livres comprometem-se com o projeto de construção de uma sociedade livre, igualitária e com respeito ao meio ambiente. + +16. Sobre a garantia de expressão: As mídias e os grupos livres trabalham no sentido de garantir um espaço para que qualquer pessoa, grupo (de afinidade política, de ação direta, de artivismo) e movimento social - que estejam em sintonia com esses objetivos - possam publicar sua própria versão dos fatos. + +17. Sobre a distinção entre produtor/a e consumidor/a: As mídias e os grupos livres trabalham no sentido de romper o papel de espectador(a) passivo/a e transformando a prática midiática ao romper com a mediação do/a jornalista profissional e com a interferência de editores/as no conteúdo das matérias. + +18. Sobre a transformação da sociedade: As mídias e os grupos livres favorecem conteúdos informacionais sobre transformação social ou que retratem as realidades dos/as oprimidos/as ou as lutas dos novos movimentos. +Sobre a união: As mídias e os grupos livres trabalham no sentido de unir esforços para uma real democratização da sociedade, primando sempre por privilegiar a perspectiva dos/as oprimidos/as. Em função disso, esperamos uma atitude construtiva e tolerante entre os/as participantes do sítio; afinal, queremos juntar forças, não lutar entre nós. + +19. Sobre a intolerância: As mídias e os grupos livres lutam contra o racismo, o sexismo e outros tipos de intolerância. + +20. Sobre a remuneração pelo trabalho: As mídias e os grupos livres funcionam exclusivamente a partir de trabalho voluntário. + +21. Sobre a capitalização sobre trabalho: As mídias e os grupos livres não devem permitir que seus voluntários/as capitalizem em cima do seu trabalho voluntário, seja adicionando tal trabalho em seu currículo ou seja por obter benesses através do uso do nome do grupo ou da mídia livre. diff --git a/etica/pessoal.mdwn b/etica/pessoal.mdwn new file mode 100644 index 0000000..995e903 --- /dev/null +++ b/etica/pessoal.mdwn @@ -0,0 +1,96 @@ +[[!meta title="Ética Pessoal"]] + +Motivação +--------- + +Código é lei? Código pode também ser ética. Se existem [protocolos](https://protocolos.fluxo.info) e [códigos de conduta](https://www.debian.org/vote/2014/vote_002) atuando no nível de grupos, é importante também haver procedimentos de auxílio para relações em nível individual. + +Pressupostos +------------ + +* Como cantou Daminhão Experiência, "O mundo foi bem feito / todo mundo tem defeito". +* Saber quando pisar dentro e fora do quadrado. +* Noções básicas de postura social. + +Cuidados +-------- + +Não é a intenção deste breve guia: + +* Se transformar numa rocha inalterável e inflexível de como as relações humanas devem ser. +* Criar um protocolo que dificulte relações e deixe as pessoas apartadas. + +Este guia é mais uma referências de aspectos a serem pensados em relações com pessoas. + +Objetivos +--------- + +Grosso modo: + +* Calma. +* Alegria. +* Agilidade. +* Sangue-bonismo. +* Companheirismo. +* Solidariedade, fraternidade, alteridade, autruísmo. + +Pisando no quadrado +------------------- + +Este é um checklist de procedimentos e código de conduta. Você tem uma ideia de como se portar em cada um desses items? + +* Comunicação implícita e explícita: + * O que pode ser assumido de antemão. + * O que não pode ser assumido de antemão. +* Separação entre aspectos da vida: + * Profissional, político e pessoal. + * Amizades e afinidades. + * Público e privado. +* Lidando com conhecimento: + * Criando um canal e um encorajamento explícito para contatos, sugestões e críticas. + * Fomentando a formação e a inclusão de mais pessoas no ativismo técnico e na difusão do conhecimento. + * Tendo uma melhor comunicação com grupos e pessoas próximas. + * Definir melhor e de forma pública o funcionamento e a participação. +* Relacionamento: + * [Alteridade](http://www.revolucoes.org.br/v1/conferencia/alteridade). + * Generosidade. + * Alimentação. + * Liberdade de associação e de não-associação, tanto para propósitos gerais quanto específicos. + * Responsabilidade e zelo. + * Buscar facilitar as relações e situações, ao invés de dificultar a fluidez dos relacionamentos. + * Comportamentos evitados: trolling, bullying, spamming, etc. + * Gentileza gera gentileza. + * Proceder: humildade, respeito, responsa. + * Assiduidade, pontualidade e atrasos. + * Política de assinatura de chaves. + * Participação em debates e discussões. + * Favores e reciprocidade. + * Fidelidade (compromisso) e lealdade (espontâneo). + * Sobre a confiança (contextual e total) e a alteridade. + * Pronomes de tratamento e linguagem inclusiva. + * Discussão, facilitação, opiniões (e mudança de opiniões), respeito a rodadas e falas: + * Discussão de temas em geral. + * Discussão periódica da relação. + * Comunicação mediada (virtual): + * [Netiqueta](https://tools.ietf.org/html/rfc1855). + * Lei de [Postel](https://en.wikipedia.org/wiki/Jon_Postel): "Be liberal in what you accept, and conservative in what you send". + * Como lidar com ausência de resposta. + * Como a ausência de resposta é interpretada. + * Assuntos públicos, semi-públicos e privados: como lidar com mensagens privadas evitando concentração de informação e canais laterais que possam prejudicar organizações horizontais. + * Emoticons, cordialidade e polidez. + * Quando assinar comunicação, quando não assinar, modo anônimo. + * Comunicação ao vivo: + * Pronomes. + * Cumprimentos (aperto de mão, beijo, saudação). +* Sistematizando formas de lidar com situações diversas: + * [Defence mechanisms](https://en.wikipedia.org/wiki/Defence_mechanisms). + * Círculo Restaurativo. + * Comunicação não-violenta. + * Linguagem inclusiva. + * Situações críticas: como não reproduzir instituições burguesas (tribunal, prisão, manicômio) ou arcaicas (ostracismo, linchamento, etc)? + * Facilitação e resolução de conflitos. + * [Conflito e Consenso](https://docs.indymedia.org/Local/CmiBrasilConflitoConsenso). + * [Conflict resolution](https://simple.wikipedia.org/wiki/Conflict_resolution). + * Referências + * [General Resolution: code of conduct](https://www.debian.org/vote/2014/vote_002). + * [Código de conduta da SquatConf](https://github.com/squatconf/organisation/blob/master/code_of_conduct.md#squatconf-code-of-conduct). diff --git a/index.mdwn b/index.mdwn index 4268c1a..778951b 100644 --- a/index.mdwn +++ b/index.mdwn @@ -2,7 +2,7 @@ _**Blueprints, boilerplates, modelos, templates! Prontos para usar e se organizar!**_ -Este é um repositório de protocolos e templates de gestão pessoal e coletiva contendo procedimentos, comportamentos e regras simples que, quando combinados, contribuem para a emergência (no sentido de emergir) de padrões complexos de organização coletiva: [Memes](http://pt.wikipedia.org/wiki/Meme) que talvez aumentem a fluidez e a organização de grupos sociais. +Este é um repositório de protocolos e templates de gestão pessoal e coletiva contendo procedimentos, comportamentos e regras simples que, quando combinados, contribuem para a emergência (no sentido de emergir) de padrões complexos de organização coletiva: [Memes](http://pt.wikipedia.org/wiki/Meme), máquinas e para aumentar a fluidez e a organização de grupos sociais. [Saiba como usar](usando)! diff --git a/organizacao/comunicacao/cert.mdwn b/organizacao/comunicacao/cert.mdwn deleted file mode 100644 index 4638698..0000000 --- a/organizacao/comunicacao/cert.mdwn +++ /dev/null @@ -1,122 +0,0 @@ -[[!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. - -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. - -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 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]. diff --git a/organizacao/contabilidade/criterios.mdwn b/organizacao/contabilidade/criterios.mdwn index 6a8596b..d9eaa3f 100644 --- a/organizacao/contabilidade/criterios.mdwn +++ b/organizacao/contabilidade/criterios.mdwn @@ -45,12 +45,10 @@ Os gastos (reembolso, doações, aquisições, etc) são efetuados através de p Com relação à transparência da contabilidade, é adotado o seguinte critério (oriundo dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]): -{{{ -12. Sobre a gestão financeira: Para garantir essas condições de financiamento, - toda a gestão financeira das mídias e grupos livres é publica: tanto as - informações contábeis quanto a participação nas decisões são acessíveis às - pessoas concernidas nas ações desta organização. -}}} + 12. Sobre a gestão financeira: Para garantir essas condições de financiamento, + toda a gestão financeira das mídias e grupos livres é publica: tanto as + informações contábeis quanto a participação nas decisões são acessíveis às + pessoas concernidas nas ações desta organização. Portanto, o Coletivo adota o critério de fornecer/publicar: @@ -60,22 +58,20 @@ Portanto, o Coletivo adota o critério de fornecer/publicar: às pessoas afetadas pela organização do Coletivo (por exemplo, grupos hospedados e parcerios) levando em conta as restrições de privacidade e segurança, isto é, a publicação/disponibilização do balanço é restrita aos grupos e pessoas próximas. -= Remuneração = +## Remuneração Sobre à remuneração pelo trabalho realizado dentro do Coletivo, é adotado o seguinte critério (oriundo dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]): -{{{ -21. Sobre a remuneração pelo trabalho: As mídias e os grupos livres funcionam - exclusivamente a partir de trabalho voluntário. -}}} + 21. Sobre a remuneração pelo trabalho: As mídias e os grupos livres funcionam + exclusivamente a partir de trabalho voluntário. Em outras palavras, o Coletivo não remunera pelo trabalho nele e por ele realizado. A remuneração, contudo, não pode ser confundida com a ajuda de custos. -= Ajuda de custos = +## Ajuda de custos A ajuda de custos é um recurso utilizado para criar um ambiente de igualdade de participação no Coletivo, por exemplo nos casos de custeio de ida à reuniões para pessoas que no momento não estejam em condições de fazê-lo, etc. Assim, integrantes do Coletivo que não possam participar de alguma atividade do Coletivo por não disporem de recursos materiais para fazê-lo podem solicitar ajuda de custos para o Coletivo. -= Lucro e contas bancárias = +## Lucro e contas bancárias O Coletivo não possui fins lucrativos. Por isso, o Coletivo não se utiliza de operações financeiras com o intuito de auferir lucro, mas pode se utilizar de meios lícitos que lhe garantam a atualização monetária. @@ -89,7 +85,7 @@ O Coletivo reconhece as contradições de utilizar o sistema financeiro e por is * Baixo risco. * Rendimentos baixos, uma vez que ela é basicamente apenas uma atualização monetária do dinheiro e por isso é praticamente o fundo de investimentos menos prejudicial à sociedade. -= Licença = +## Licença Como estes critérios se utilizam de trechos oriundos dos [http://encontro.fluxo.org/Principal/ConjuntoDePrincipiosEticos Princípios das mídias e grupos livres]), segue a seguinte licença de manipulação dos mesmos (disponível também [http://encontro.fluxo.org/Principal/Licenca aqui]): diff --git a/organizacao/provedor.mdwn b/organizacao/provedor.mdwn deleted file mode 100644 index f06698e..0000000 --- a/organizacao/provedor.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta title="Provedor de Serviços de Internet - ISP"]] - -[[!map pages="page(organizacao/provedor*)" show="title"]] diff --git a/organizacao/provedor/backups.mdwn b/organizacao/provedor/backups.mdwn deleted file mode 100644 index 88e4173..0000000 --- a/organizacao/provedor/backups.mdwn +++ /dev/null @@ -1,36 +0,0 @@ -[[!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. - -== 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 [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. - -== 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 [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. - -== 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]. diff --git a/organizacao/provedor/backups/entrega.mdwn b/organizacao/provedor/backups/entrega.mdwn deleted file mode 100644 index 860532c..0000000 --- a/organizacao/provedor/backups/entrega.mdwn +++ /dev/null @@ -1,80 +0,0 @@ -[[!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: - - 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/organizacao/provedor/hospedagem.mdwn b/organizacao/provedor/hospedagem.mdwn deleted file mode 100644 index 6f1ecc4..0000000 --- a/organizacao/provedor/hospedagem.mdwn +++ /dev/null @@ -1,39 +0,0 @@ -[[!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: - - 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/organizacao/provedor/hospedagem/carta.mdwn b/organizacao/provedor/hospedagem/carta.mdwn deleted file mode 100644 index e959ff0..0000000 --- a/organizacao/provedor/hospedagem/carta.mdwn +++ /dev/null @@ -1,71 +0,0 @@ -[[!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. - - 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/organizacao/provedor/hospedagem/plataforma.mdwn b/organizacao/provedor/hospedagem/plataforma.mdwn deleted file mode 100644 index 993ee1b..0000000 --- a/organizacao/provedor/hospedagem/plataforma.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -[[!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. - -# 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/organizacao/provedor/hospedagem/politica.mdwn b/organizacao/provedor/hospedagem/politica.mdwn deleted file mode 100644 index f41d224..0000000 --- a/organizacao/provedor/hospedagem/politica.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -[[!meta title="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/organizacao/provedor/hospedagem/recusa.mdwn b/organizacao/provedor/hospedagem/recusa.mdwn deleted file mode 100644 index cf3eb07..0000000 --- a/organizacao/provedor/hospedagem/recusa.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -[[!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. - - 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/organizacao/provedor/hospedagem/termo.mdwn b/organizacao/provedor/hospedagem/termo.mdwn deleted file mode 100644 index 62ecd7e..0000000 --- a/organizacao/provedor/hospedagem/termo.mdwn +++ /dev/null @@ -1,105 +0,0 @@ -[[!meta title="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/organizacao/provedor/servidor.mdwn b/organizacao/provedor/servidor.mdwn deleted file mode 100644 index e8dfa76..0000000 --- a/organizacao/provedor/servidor.mdwn +++ /dev/null @@ -1,49 +0,0 @@ -[[!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. - -# Classes RSP - -O servidor deve estar configurado de acordo com as seguintes classes do [wiki:Camadas/RSP Resource Sharing Protocol]: - - * `$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 [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. diff --git a/organizacao/provedor/sistemas.mdwn b/organizacao/provedor/sistemas.mdwn deleted file mode 100644 index dc1b1a3..0000000 --- a/organizacao/provedor/sistemas.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -[[!meta title="Configuração de sistemas padronizada e centralizada"]] - -[[!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. - -= 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. - -= 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 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. - -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. diff --git a/organizacao/provedor/sistemas/dns.mdwn b/organizacao/provedor/sistemas/dns.mdwn deleted file mode 100644 index 76a76d0..0000000 --- a/organizacao/provedor/sistemas/dns.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -[[!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. - -# Tarefas - -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. - -## Dependências - -A realização deste processo depende da realização dos seguintes processos: - -* [wiki:Camadas/Dominios Gerenciamento de domínios]. diff --git a/organizacao/provedor/sistemas/dominios.mdwn b/organizacao/provedor/sistemas/dominios.mdwn deleted file mode 100644 index 98d2ca8..0000000 --- a/organizacao/provedor/sistemas/dominios.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -[[!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. - -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. diff --git a/provedor.mdwn b/provedor.mdwn new file mode 100644 index 0000000..f06698e --- /dev/null +++ b/provedor.mdwn @@ -0,0 +1,3 @@ +[[!meta title="Provedor de Serviços de Internet - ISP"]] + +[[!map pages="page(organizacao/provedor*)" show="title"]] diff --git a/provedor/backups.mdwn b/provedor/backups.mdwn new file mode 100644 index 0000000..88e4173 --- /dev/null +++ b/provedor/backups.mdwn @@ -0,0 +1,36 @@ +[[!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. + +== 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 [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. + +== 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 [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. + +== 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]. diff --git a/provedor/backups/entrega.mdwn b/provedor/backups/entrega.mdwn new file mode 100644 index 0000000..860532c --- /dev/null +++ b/provedor/backups/entrega.mdwn @@ -0,0 +1,80 @@ +[[!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: + + 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.mdwn b/provedor/cert.mdwn new file mode 100644 index 0000000..4638698 --- /dev/null +++ b/provedor/cert.mdwn @@ -0,0 +1,122 @@ +[[!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. + +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. + +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 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]. diff --git a/provedor/hospedagem.mdwn b/provedor/hospedagem.mdwn new file mode 100644 index 0000000..6f1ecc4 --- /dev/null +++ b/provedor/hospedagem.mdwn @@ -0,0 +1,39 @@ +[[!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: + + 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.mdwn b/provedor/hospedagem/carta.mdwn new file mode 100644 index 0000000..e959ff0 --- /dev/null +++ b/provedor/hospedagem/carta.mdwn @@ -0,0 +1,71 @@ +[[!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. + + 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/plataforma.mdwn b/provedor/hospedagem/plataforma.mdwn new file mode 100644 index 0000000..993ee1b --- /dev/null +++ b/provedor/hospedagem/plataforma.mdwn @@ -0,0 +1,27 @@ +[[!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. + +# 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.mdwn b/provedor/hospedagem/politica.mdwn new file mode 100644 index 0000000..f41d224 --- /dev/null +++ b/provedor/hospedagem/politica.mdwn @@ -0,0 +1,47 @@ +[[!meta title="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.mdwn b/provedor/hospedagem/recusa.mdwn new file mode 100644 index 0000000..cf3eb07 --- /dev/null +++ b/provedor/hospedagem/recusa.mdwn @@ -0,0 +1,26 @@ +[[!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. + + 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.mdwn b/provedor/hospedagem/termo.mdwn new file mode 100644 index 0000000..62ecd7e --- /dev/null +++ b/provedor/hospedagem/termo.mdwn @@ -0,0 +1,105 @@ +[[!meta title="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.mdwn b/provedor/servidor.mdwn new file mode 100644 index 0000000..e8dfa76 --- /dev/null +++ b/provedor/servidor.mdwn @@ -0,0 +1,49 @@ +[[!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. + +# Classes RSP + +O servidor deve estar configurado de acordo com as seguintes classes do [wiki:Camadas/RSP Resource Sharing Protocol]: + + * `$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 [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. diff --git a/provedor/sistemas.mdwn b/provedor/sistemas.mdwn new file mode 100644 index 0000000..dc1b1a3 --- /dev/null +++ b/provedor/sistemas.mdwn @@ -0,0 +1,41 @@ +[[!meta title="Configuração de sistemas padronizada e centralizada"]] + +[[!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. + += 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. + += 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 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. + +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. diff --git a/provedor/sistemas/dns.mdwn b/provedor/sistemas/dns.mdwn new file mode 100644 index 0000000..76a76d0 --- /dev/null +++ b/provedor/sistemas/dns.mdwn @@ -0,0 +1,16 @@ +[[!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. + +# Tarefas + +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. + +## Dependências + +A realização deste processo depende da realização dos seguintes processos: + +* [wiki:Camadas/Dominios Gerenciamento de domínios]. diff --git a/provedor/sistemas/dominios.mdwn b/provedor/sistemas/dominios.mdwn new file mode 100644 index 0000000..98d2ca8 --- /dev/null +++ b/provedor/sistemas/dominios.mdwn @@ -0,0 +1,26 @@ +[[!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. + +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