Este artigo também está disponível em:
Este artigo foi traduzido usando tradução automática. Ele pode conter alguns erros ou traduções estranhas. Ainda assim, achamos que é útil para você ler este artigo de ajuda em seu idioma nativo. Informe-nos se este artigo foi útil ou se você tem algum outro comentário, na parte inferior do artigo.

Este documento contém os princípios orientadores de como no Easy LMS mantemos a segurança e a privacidade de nossos clientes.

A segurança vem em camadas e nós temos cinco princípios orientadores que nos permitem ter mais e melhores camadas de segurança dentro de nossa organização e de nosso produto. Cada um destes cinco princípios será discutido separadamente neste documento. Nossos cinco princípios principais de segurança são:

Priorizar o princípio da segurança
Discutir o princípio da segurança
Nenhum princípio de software não mantido
Pelo menos o princípio dos 4 + 2 olhos
Princípio do acesso menos privilegiado

Priorizar o princípio da segurança

O que quer que façamos, nós consertamos a segurança primeiro.

Nenhum software está sem bugs, e mesmo que façamos nosso melhor esforço para ter a mais alta qualidade possível de nosso produto, não somos exceção a isso. Isto significa que às vezes encontramos (potencial) problemas de segurança dentro do nosso sistema. Sempre que o problema está presente em nossa instalação de produção, o bug logado tem prioridade máxima para garantir que não haja backlog de problemas de segurança não resolvidos. Se múltiplos problemas de segurança forem encontrados, então a questão de segurança com a maior severidade é dada prioridade.

No cenário em que uma questão de segurança é encontrada antes de pousar em nosso ambiente de produção, existe um processo para garantir que novas implantações do código vulnerável sejam evitadas até que a segurança seja resolvida. Como isso pode nos impedir de implantar novos recursos, estas questões também têm prioridade para correções.

Nós frequentemente dizemos que é mais seguro do que arrependido. Nós pensamos que garantir um produto seguro não se trata de remendar problemas que são encontrados, mas de garantir que estes problemas nunca existiriam em primeiro lugar. Portanto, pensamos que a segurança deve ser uma prioridade desde os primeiros estágios de desenvolvimento para projetar a segurança diretamente em nosso produto ao invés de remendar as coisas depois.

Discutir o princípio de privacidade/segurança

Se não pensarmos e discutirmos sobre como melhorar, nunca o faremos._

Embora a segurança seja discutida e implementada no coração do nosso software, nós pensamos que sempre há espaço para melhorias. Ter uma conversa nos ajuda a nos manter focados e afiados em como abordamos a segurança. Além disso, uma discussão é uma maneira de transformar boas idéias em grandes idéias, e bons projetos em grandes projetos. Mais importante, já que sempre há espaço para melhorias, uma discussão pode nos permitir descobrir o que nós necessário melhorar ao invés do que nós podemos melhorar. A segurança é sempre tão forte quanto a parte mais fraca e quando se trata de melhorar a segurança, somente as melhorias na sua parte mais fraca irão realmente melhorar a sua segurança. Portanto, acreditamos que a conversão contínua deve ser sempre mantida viva sobre o que é nossa parte mais fraca, e como podemos melhorar isso.

Nenhum princípio de software não-mantido/descondicionado

_Nosso software não é seguro se a plataforma em que ele funciona não é.

Nós não inventamos a roda, e certamente não escrevemos nosso próprio sistema operacional. Portanto, sim, nós dependemos do código de terceiros. Isto significa que nós também precisamos ter certeza de que este código é seguro. Para o sistema operacional (um sabor linux), o ambiente da linguagem de programação (php / nó), nosso servidor http (apache) e sistemas de banco de dados (MariaDB), nós nos certificamos de que sempre usamos uma versão que no mínimo ainda receba patches de segurança. Isto significa que nosso software é atualizado regularmente para ser executado em uma versão atualizada. Além disso, ele garante que nós permaneçamos seguros durante todo o tempo, como para estes componentes, nós exigimos que os patches de segurança sejam instalados automaticamente.

Para bibliotecas que usamos em nosso código, usamos ferramentas automatizadas sempre que possível para garantir que estas tenham uma versão atualizada, mas mais importante ainda, uma versão segura. Na prática nós usamos 'npm audit' para garantir que nossos pacotes node.js estejam atualizados. E nós usamos 'roave/security-advisors' para garantir que nossas bibliotecas de php estejam seguras.

Pelo menos o princípio dos 4 + 2 olhos

Todas as mudanças, por mais triviais que pareçam, devem ser verificadas quanto à qualidade.

Para manter a qualidade que almejamos, nós acreditamos que não importa as circunstâncias, nosso software nunca deve ser apressado. Isto significa que um ciclo completo de revisão é necessário para cada mudança que fazemos em nosso produto. Isto significa que o código precisa ser visto e aprovado por pelo menos dois desenvolvedores e depois testado por um de nossos testes. Este princípio está ancorado em nosso fluxo de trabalho. Antes que o código possa ser implantado em um ambiente de encenação ou produção, ele precisa passar por um pedido de puxar. Os pedidos de puxar devem ser analisados por pelo menos outro desenvolvedor. A fusão real de volta é feita por alguém de nossa equipe de testes. Portanto, um desenvolvedor não é, em princípio, capaz de fazer a fusão de uma solicitação de pull back. A segurança é (obviamente) parte do ciclo de revisão. O outro desenvolvedor irá avaliar o código para ver se há questões relacionadas à segurança. O testador também testa os erros comuns de segurança para evitar vazamentos desnecessários em nosso sistema.

Uma menção especial deve ser feita sobre a administração da infra-estrutura/sistema. Como o ciclo de desenvolvimento do código permite avaliar a segurança e a qualidade antes de atingir a produção, nós nos esforçamos para gerenciar toda a nossa infra-estrutura como código. Isto nos permite automatizar a maioria dos recursos, o que significa que cometemos menos erros humanos. Além disso, um único administrador de sistema pode fazer mudanças sem notificação que podem afetar a segurança de nosso sistema.

Princípio do acesso menos privilegiado

Toda pessoa deve ter acesso apenas ao que precisa e todo programa deve ter acesso apenas ao que precisa.

A maneira mais confiável de prevenir qualquer forma de vazamento de dados é certificando-se de que não há nenhum dado para vazar. A próxima melhor coisa é garantir que ninguém possa acessar as informações desnecessárias. Por exemplo, um desenvolvedor não precisa ter acesso aos nossos dados de produção para desenvolver novos recursos. Da mesma forma, um tradutor só precisa ver o que pode ser traduzido em nosso sistema, e não requer acesso à nossa base de códigos ou informações do cliente. Nosso objetivo é garantir que qualquer pessoa em nossa organização só possa ver e executar as tarefas que são necessárias para seu papel.

O princípio do acesso menos privilegiado aplica-se aos seres humanos, mas também é aplicado aos sistemas e serviços. Se uma parte do nosso sistema for comprometida, nosso objetivo é minimizar o impacto que ela pode ter. Portanto, nosso objetivo é separar os serviços que só podem acessar as informações que eles precisam. Por exemplo, nós não precisamos processar informações de pagamento ao exibir conteúdo de aprendizado. Portanto, os sistemas responsáveis pelo conteúdo de aprendizado não devem ter acesso ao nosso sistema de pagamento. Além disso, isto também é possível para outros serviços. Nosso objetivo é desconectar os serviços da internet pública, se possível. Isto é feito preferencialmente colocando os serviços em uma rede privada, da qual eles só podem ser acessados a partir dessa rede. Se o serviço não se destina ao uso público, mas se destina a ser acessado pela internet, trabalhamos com uma lista branca de endereços IP, para minimizar a exposição.

Notas finais

Nós acreditamos que um esforço contínuo é necessário para manter um alto nível de segurança. Este esforço significa que ele não deve permanecer com princípios, mas que estes princípios devem ser incorporados em todos os nossos processos de fluxo de trabalho. Desta forma, podemos garantir que a segurança tenha prioridade dentro de nossa organização.
Este artigo foi útil?
Cancelar
Obrigado!