From 1cee6da91e04e0d8c27451c05dc8f45ca662f34f Mon Sep 17 00:00:00 2001 From: Silvio Rhatto Date: Wed, 18 Nov 2015 20:44:42 -0200 Subject: Completa o roteiro --- aulas/ambientes.rst | 4 +-- aulas/devops.rst | 8 ++--- aulas/metodologias.rst | 4 +-- aulas/reinventando.rst | 64 ++++++++++++++++++++++++------------- aulas/seguranca.rst | 85 ++++++++++++++++++++++++++++++++++++-------------- 5 files changed, 112 insertions(+), 53 deletions(-) (limited to 'aulas') diff --git a/aulas/ambientes.rst b/aulas/ambientes.rst index a1c2760..49b9b40 100644 --- a/aulas/ambientes.rst +++ b/aulas/ambientes.rst @@ -259,8 +259,8 @@ Roteiro do screencast: #. Crie a estrutura básica do seu projeto. -2.5 Referências ---------------- +2.5 - Referências +----------------- - `Guia Foca Linux `_. - `Solarized - Ethan Schoonover `_. diff --git a/aulas/devops.rst b/aulas/devops.rst index 9f03acc..8605666 100644 --- a/aulas/devops.rst +++ b/aulas/devops.rst @@ -12,8 +12,8 @@ Imagens: * https://upload.wikimedia.org/wikipedia/commons/b/b5/Devops.svg -5.2 Ambientes reprodutíveis ---------------------------- +5.2 - Ambientes reprodutíveis +----------------------------- 5.2 - Ambientes ~~~~~~~~~~~~~~~ @@ -104,8 +104,8 @@ Roteiro do screencast: * Mostrar softwares e serviços de integração contínua. * Criar um protótipo local e simples de teste e integração contínua. -5.7 Atividades --------------- +5.7 - Atividades +---------------- #. Crie um ambiente de desenvolvimento vagrant para o seu projeto. #. Experimente o PuPHPet para gerar uma configuração mais complexa de ambiente virtual de desenvolvimento. diff --git a/aulas/metodologias.rst b/aulas/metodologias.rst index 3848275..98f7a15 100644 --- a/aulas/metodologias.rst +++ b/aulas/metodologias.rst @@ -185,8 +185,8 @@ Imagens: #. Bônus: esboce um documento simples de escopo para o seu projeto. Ele pode ser um importante guia nas fases iniciais. -1.9 Referências ---------------- +1.9 - Referências +----------------- - `Best coding practices - Wikipedia, the free encyclopedia `_. - `Best practices for software development projects `_. diff --git a/aulas/reinventando.rst b/aulas/reinventando.rst index 089bb83..af8e3fb 100644 --- a/aulas/reinventando.rst +++ b/aulas/reinventando.rst @@ -4,52 +4,72 @@ 7.1 - Patterns -------------- -* TDD. -* Separando código de dados, sobretudo dados sigilosos! -* Desacoplamento. -* Filosofia UNIX: - * Pequenos softwares/bibliotecas. - * Que fazem uma coisa bem. +7.1 - O que são e por quê usar? +------------------------------- + +* Design Patterns são "formas" de desenvolvimento reutilizáveis e consideradas como boas práticas. +* A lista de patterns conhecidos é long demais para este curso +* Daremos alguns exemplos ilustrativos que atendem o nosso critério de simplicidade. +* São recomendações! Mais importante que usá-las é ter capacidade crítica para determinar quais fazem ou não sentido para o seu projeto. + +7.2 - Exemplos +-------------- + +Daremos breves exemplos em três campos: + +* Design: separação de código de dados, sobretudo dados sigilosos! +* Metodologia : DDD e TDD: documentar e testar antes, durante ou depois? +* Implementação: Filosofia UNIX: + * Pequenos softwares e bibliotecas (desacoplamento). + * Que fazem bem uma coisa. * E que podem ser facilmente combinados. -7.2 - Antipatterns ------------------- +7.2 - Anti-patterns +------------------- + +São o oposto das design patterns: formas de desenvolvimento não recomendadas. Exemplos: +* O mito da pessoa-mês (Lei de Brooks). * Hype: cuidado com o ciclo dos modismos! -* Linearidade: o mito da pessoa-mês (Lei de Brooks). * Inferno de dependências. * Bitrot: decaimento natural do código! -7.3 - Inventando, reinventando e desinventando ----------------------------------------------- +7.3 - Documentação: lendo e escrevendo +-------------------------------------- -Hora de converter nosso projeto blogático para uma plataforma com mais funcionalidades! +* Documente não só para os outros, mas para você mesmo(a) no futuro. +* Quanto mais próxima a documentação está do código, mais difícil dela se desatualizar. +* Docblocks / heredocs: podem ser convertidos em documentação indexada, referenciada e navegável. +* Documente procedimentos enquanto você os realiza. Roteiro do screencast: -:: +* Concluindo a documentação do blogático, fazendo um commit e um release tag. - cd ~/projetos/blogatico - cp -r ../boaspraticas/_templates/ikiwiki/* . - make +7.4 - Inventando, reinventando e desinventando +---------------------------------------------- -7.4 - Documentação: lendo e escrevendo --------------------------------------- +* Caso tenha acompanhado este curso desde o começo e construiu nosso projeto/invento "blogático" desde o ínicio, agora você tem um software para documentar seu aprendizado em desenvolvimento. Acontece que ele é bem simples. E se você quiser algo mais completo e que seja uma solução pronta, já disponível? -* Quanto mais próxima a documentação está do código, mais difícil dela se desatualizar. -* Docblocs / heredocs. -* Documente procedimentos enquanto você os realiza. +* Agora é hora de converter nosso projeto blogático para uma plataforma com mais funcionalidades! Roteiro do screencast: :: - sudo apt-get install ttyrec + cd ~/projetos/blogatico + cp -r ../boaspraticas/_templates/ikiwiki/* . + make 7.5 - Atividades ---------------- +#. Consulte as referências por diversos design patterns e antipatterns. Quais patterns você acha mais interessantes? Quais antipatterns são mais perigosos? +#. Crie a documentação do seu projeto. Pense que ela será lida por uma audiência bem geral que nunca ouviu falar do projeto e será determinante para que decidam se irão usá-lo ou não. + 7.6 - Referências ----------------- * `Versionamento Semântico 2.0.0 `_. +* `On Documentation-Driven Development // Collective Idea | Crafting web and mobile software based in Holland, Michigan `_. +* `Readme Driven Development `_. diff --git a/aulas/seguranca.rst b/aulas/seguranca.rst index aae2b36..2915480 100644 --- a/aulas/seguranca.rst +++ b/aulas/seguranca.rst @@ -1,27 +1,35 @@ 6. Segurança e privacidade ========================== -6.1 - Segurança começa no desenvolvimento +6.1 - Segurança da informação +----------------------------- + +* Confidencialidade. +* Integridade. +* Disponibilidade. +* Autenticidade. + +6.2 - Segurança começa no desenvolvimento ----------------------------------------- +* Segurança: para fins do nosso curso, é a proteção da aplicação. +* Privacidade: proteção dos dados em poder da aplicação. * Criptografia é só uma parte das práticas seguras. -* Modelagem de ameaças e testes de penetração: inverta os papéis: e se você fosse o/a atacante? -* A dificuldade de se encontrar vulnerabilidades. -* Segurança por isolamento ajuda, mas botar a aplicação dentro de um cordão sanitário protege mais o ambiente de hospedagem do que a aplicação. +* Obscuridade não é segurança: disclosures são saudáveis no desenvolvimento. -6.2 - Use bibliotecas criptográficas consolidadas! --------------------------------------------------- +6.3 - Modelagem de ameaças e auditoria +-------------------------------------- -* Erros de implementação são grandes fontes de brechas de segurança. -* Caso você precise implementar primitivas criptográficas no seu código, use bibliotecas existentes! -* Encapsule as conexões das suas aplicações em canais criptografados. -* TLS é o protocolo mais consolidado e adequado, apesar de não ser perfeito. +* É fácil (e barato) produzir e difícil (e caro) encontrar vulnerabilidades. +* Modelagem de ameaças (teoria) e testes de penetração (prática): inverta os papéis: e se você fosse o/a atacante? +* Segurança por isolamento ajuda, mas botar a aplicação dentro de um cordão sanitário protege mais o ambiente de hospedagem do que a aplicação. -6.3 - Princípio das permissões mínimas --------------------------------------- +6.4 - Exemplo e ameaça e o princípio das permissões mínimas +----------------------------------------------------------- -* Comece o desenvolvimento com o mínimo de permissões necessárias para a sua aplicação e libere o acesso conforme necessário. -* Permissões de arquivos são propriedades no sistema de arquivo! +* Exemplo de ameaça: o(a) atacante tem permissão de escrita no código da aplicação. +* Mitigação: forneça o mínimo de permissões necessárias para a sua aplicação e libere o acesso conforme necessário. +* Atenção! Permissões de arquivos são propriedades no sistema de arquivo! * Elas não são necessariamente preservadas com a cópia de arquivos entre sistemas! Roteiro do screencast: @@ -39,20 +47,51 @@ Roteiro do screencast: # Mudando a posse de arquivos e pastas chown -6.4 - Criptografia básica +6.5 - Criptografia básica ------------------------- -* Assinaturas digitais. -* Comunicação cifrada. -* Checagem de integridade de código no git e em geral. +* Criptografia não é tudo em segurança, porém é o requisito básico e essencial. +* Ameaça: machine-in-the-middle. +* Mitigação: + * Comunicação cifrada: HTTPS. + * Checagem de integridade de código no git e em geral (assinaturas e checksums). -6.5 - Certificados x509 para SSL/TLS/HTTPS ------------------------------------------- +6.6 - Use bibliotecas criptográficas consolidadas! +-------------------------------------------------- -* `Let's Encrypt `_. +* Erros de implementação são grandes fontes de brechas de segurança. +* Caso você precise implementar primitivas criptográficas no seu código, use bibliotecas existentes! +* Encapsule as conexões das suas aplicações em canais criptografados. +* TLS é o protocolo mais consolidado e adequado, apesar de não ser perfeito. + +6.7 - HTTPS +----------- + +6.7 - O que é +~~~~~~~~~~~~~ -6.6 - Atividades +* HTTPS: HTTP em cima de uma conexão SSL/TLS. +* Padrão dos anos 90 e melhorado desde então. +* Bem implementado: oferece segurança da informação num nível aceitável, porém não oferece anonimato. +* Mal implementado: só oferece ilusão de segurança. +* Movimento crescente para tornar HTTPS padrão em todos os sites! + +6.7 - Certificados para HTTPS +----------------------------- + +* No HTTPS, a autenticidade é obtida usando uma "cadeia de certificação" provida por autoridades certificadoras. +* Checagem feita no navegador. +* É um esquema altamente vulnerável: a qualquer momento o castelo de cartas pode ruir. +* As alternativas a esse modelo ainda são incipientes. + +6.8 - Atividades ---------------- -6.7 - Referências +#. Faça um pequeno documento de modelagem de ameaças para o seu projeto. Coloque-o na forma de "ameaça/mitigação". Organize cada par ameaça/mitigação segundo probabilidade decrescente de ocorrência e custo crescente de implementação, facilitando a implementação de cada medida de segurança. +#. Desafio: caso seu projeto seja uma aplicação web, obtenha um certificado e configure uma conexão HTTPS. + +6.9 - Referências ----------------- + +* `Let's Encrypt `_. +* `Segurança da informação – Wikipédia, a enciclopédia livre `_. -- cgit v1.2.3