sábado, 9 de julho de 2011

Alinhando as expectativas (Cont. I)

Você pode tentar ler esse post isoladamente, mas estou escrevendo mantendo uma certa ordem. Recomendo a leitura do post anterior para que esse conteúdo faça mais sentido.

Continuando o detalhamento das expectativas, abordaremos nesse post os próximos ambientes e a expectativa sobre eles.

Detalhando as expectativas de segurança

Produção, Médio Valor


  • Backup

Nesse tipo de ambiente podemos questionar modelos muito complexos de backup, se você classificou bem seu ativo, a perda parcial de dados não deveria ser algo com o qual não se possa conviver. Entretanto esses dados precisam de um nível mínimo de cuidado, não adianta implementar um esquema de backup simplesmente por pro-forma. Assim, deve-se garantir que o processo de backup e restore sejam tão eficientes quanto o backup de ambientes de alto valor, mas podemos abrir mão da frequência, ou seja, não há necessidade de se executar backups diários. A simples possibilidade de se espaçar os intervalos de backup vai reduzir substancialmente o custo dessa operação, tornando-a mais compatível com o tipo de ativo a que se destina. 


Outra coisa que precisamos levar em conta é que tratando-se de um ativo de médio valor, além de estarmos disposto a aceitar uma certa perda em caso de falha, devemos buscar a possibilidade de utilizar janelas de backup durante as quais o sistema fica congelado para alterações, pois essa é a maneira mais barata de se garantir a integridade do dado que será submetido a mídia de backup. Substituindo a feature do sistema de alto valor, que deve garantir a existência de uma imagem consistente do dado para ser guardado a todo momento, por uma feature mais simples que congela as alterações e só permite novas alterações após o backup terminado.

  • Disponibilidade

Alguns sistemas podem se dar ao luxo de não garantir a tão falada disponibilidade de 99.999% (acredite esses três últimos noves custam muito caro). 
Mas tenha certeza de que a indisponibilidade do seu sistema seja realmente algo com que você possa conviver. O nosso amigo ai do lado não ficaria muito feliz com problemas de disponibilidade do sistema dele.
Um artifício de bom custo benefício para melhorar a disponibilidade é a utilização de caches sempre que possível. Diferente de um sistema que garanta alta disponibilidade esses mecanismos vão mitigar indisponibilidades do seu sistema. 

  • Controle de acesso

Assim como todos os demais aspectos, o controle de acesso pode ser menos regrado. Por exemplo, em situações extremas, uma solicitação de acesso a um ativo de alto valor ficaria parada até que todas as etapas do fluxo de autorização do acesso fossem cumpridas, em contrapartida, para ativos de médio valor, o acesso temporário poderia ser concedido desde que aprovado em primeira instância, podendo ser removido o acesso caso não autorizado em última instância pelo owner no ativo. Mas garanta que seu ativo realmente não requer um controle rigoroso de acesso. Utilizar a estratégia errada pode comprometer a segurança. Não é por ser de médio valor que o ativo tem que seguir todas as políticas desse nível, alguns aspectos do nível superior podem ser seguidos, sendo esse o principal deles.

  • Log Server

Mesmo para os ativos de médio valor, deve-se avaliar a questão dos logs. Existem informações de acesso que podem ser requisitadas para atividades de investigação, ou mesmo por auditorias e a centralização dessas informações facilita o acesso as mesmas. Sem mencionar que a operação é feita de forma centralizada, muito mais simples de ser gerida (monitoração do espaço em disco ocupado, gerenciamento do backup, acesso as informações de execução das aplicações para viabilizar aos desenvolvedores a identificação mais clara dos eventos e falhas do sistema em produção que por ventura eles estiverem depurando etc.)


Em contrapartida, cada ativo pode optar por gerar e gerenciar seus logs localmente, mas esse tipo de estratégia para empresas com muitos ativos implica em um esforço muito grande para manter o controle da quantidade de disco disponível por exemplo. Conceder acesso de leitura para os desenvolvedores nesse cenário pode se tornar um tremendo desafio pois os acessos ficaram literalmente espalhados por todos os ativos. Isso enfraquece substancialmente a segurança e potencializa em muito a existência de acessos não autorizados aos ambientes pela dificuldade que se apresentará em se verificar todos os acesso em todos os ambientes contra os diversos processos de solicitação de acesso.

  • Hardening

Se para os ativos de alto valor você deve ter uma meta em termos de hardening bastante agressiva, para os ativos de médio valor basta garantir que os itens mais óbvios como configurações default, senhas padrão, falha ou falta de controle de acesso não existam no ambiente. Não havendo um grande interesse por parte dos atacantes (ativos de médio valor) seu ambiente não será extremamente alvejado pelos mesmos. Havendo um nível adequado de dificuldade para invadir o ambiente, é bastante lógico esperar que os atacantes procurarão alvos mais promissores ou mais fáceis de serem atingidos.

  • Sistemas

Para os sistemas ainda devemos ter o controle do processo de Gestão de Mudança, entretanto, sendo o ativo destinado a um ambiente com menos critérios (ou critérios mais amenos) de promoção a produção, ele necessitará de um menor nível de controle, por exemplo: um sistema destinado a um ambiente para ativos de alto valor que não seja capaz de suportar o controle de acesso adequado, ou o nível de backup exigido, ou tenha vulnerabilidades de baixo a médio impacto conhecidas que não podem ser corrigidas, teria sua entrada em produção barrada. Esse mesmo sistema com as mesmas características poderia ser promovido a produção se destinado a ambientes com menor nível de exigência, como ambiente de médio valor. A expectativa sobre o nível do sistema tem apenas que ser compatível com a expectativa de operação do mesmo.


Por exemplo, no sistema de eliminação da sede (primeira ilustração desse tópico), nosso usuário (piriquito amarelo) entende como aceitável o bug que quase o afoga quando ele comete um erro na "entrada de dados" (abertura da torneira) e já está posicionado o bico na "saída" do sistema. Como mitigação durante o treinamento, o usuário foi alertado para não colocar o "bico" no dispositivo de saída antes de regular apropriadamente a saída, mas não há como proteger o usuário de um erro operacional. Para ser aceito no ambiente de alto valor a solução teria que ser completamente remodelada, conforme vemos ao lado.


Conclusão
Vencemos mais uma etapa. Agora entendemos que a segurança orientada a negócios tem uma visão bastante prática e não preza nem pelo controle total, nem pela ausência de controles, mas simplesmente pelo nível de controle adequado as necessidades e anseios do negócio.

Nenhum comentário:

Postar um comentário