Certo, pessoal de NetOps. Agora que vocês estão automatizando tudo e criando scripts a todo vapor, é hora de um lembrete amigável sobre segurança. Não estou falando de firewalls, WAF ou outros serviços de segurança que vocês talvez sejam responsáveis por implantar e gerenciar. Estou falando dos scripts e códigos que vocês criarão ao embarcar nessa jornada de transformação digital.
Hoje, gostaria de relembrar a Regra Zero de Segurança. Para refrescar a memória:
REGRA ZERO DE SEGURANÇA: NÃO CONFIE JAMAIS NAS ENTRADAS DO USUÁRIO.
Uma regra bem simples, não é?
Deveria ser, mas não é. Incidente de segurança após incidente de segurança no mundo dos negócios pode ser atribuído à violação da Regra Zero de Segurança. As violações dessa regra são frequentes nos exemplos de código disponibilizados aos desenvolvedoresenquanto pesquisam e aprendem novas linguagens e frameworks e, infelizmente, isso também está se infiltrando no empolgante novo universo de NetOps.
Permitam-me apresentar a Prova A:
Agora, para sermos justos, pelo menos este script tem a decência de avisar que os dados não são validados. Isso é bom, porque, em seguida, ele realiza todo tipo de manipulação remota das configurações dos roteadores com base nos dados de entrada.
Minha ressalva quanto a isso é que o código foi criado para ajudar a orientar as equipes de NetOps sobre como começar a usar scripts para automatizar dispositivos de rede em produção e apenas faz uma menção superficial à validação de dados, sem fornecer nenhuma informação útil sobre como fazer isso.
Para conferir algumas boas dicas sobre como validar endereços IP em Python, consulte esta discussão no Stack Overflow.
Mas, Lori, isso é scripting, estamos fazendo coisas pela CLI e, fala sério, qual é o risco disso?
É difícil abandonar velhos hábitos.
Há dois problemas em ignorar a Regra Zero de Segurança.
Primeiro, os dias da CLI estão contados, meu amigo. A API é a nova CLI, e a maioria dos frameworks de automação está adotando o uso de APIs RESTful para provisionar e gerenciar dispositivos e serviços de rede. Isso significa pilhas de aplicativos e analisadores. Significa dispositivos potencialmente vulneráveis a ataques, pois sua configuração pode ser alterada por meio de uma API que pode conter vulnerabilidades.
Como prova de que não estou exagerando, apresento este comunicado da Cisco sobre a amplamente discutida vulnerabilidade do Apache Struts. O consenso é que passar entradas não sanitizadas para o framework Struts desencadeia todo tipo de problema.
Mas, caso o potencial de exploração não seja suficiente para fazer você se preocupar em aplicar a Regra Zero de Segurança, vale destacar que não sanitizar as entradas pode ter um impacto muito mais amplo do que apenas em um único dispositivo. Considere o que sabemos sobre a interrupção do Amazon S3 no início de 2017:
Às 9h37 (horário do Pacífico), um membro autorizado da equipe do S3, seguindo um procedimento estabelecido, executou um comando destinado a remover um pequeno número de servidores de um dos subsistemas do S3 usados no processo de faturamento. Infelizmente, um dos parâmetros do comando foi inserido incorretamente, e um conjunto de servidores maior do que o pretendido foi removido.
-- Resumo da interrupção do serviço Amazon S3 na região da Virgínia do Norte (US-EAST-1)
O número que ele inseriu no script era muito maior do que pretendia. Mas scripts que aceitam cegamente qualquer valor fornecido pelo operador (ignorando a Regra Zero de Segurança) estão fadados a, mais cedo ou mais tarde, causar esse tipo de erro. Uma simples verificação pelo script — embora reconhecidamente incômoda — poderia ter evitado que o problema virasse assunto no Twitter por mais de uma semana.
Na rede, em produção, muitas vezes enxergamos a segurança sob a ótica da autorização. Bob tem autorização para realizar esta ação? Alice pode executar este script? E precisamos disso; continua sendo fundamental.
Mas, à medida que aceleramos nossa jornada (interna) de transformação digital, adotamos mais frameworks e usamos APIs e scripts para automatizar ao máximo o provisionamento e o gerenciamento, também precisamos, sem dúvida, considerar a segurança sob a perspectiva do desenvolvimento.
E a primeira dessas regras é a Regra Zero de Segurança: NÃO CONFIE JAMAIS NA ENTRADA DO USUÁRIO.
Sempre valide as entradas. Isso não só oferece segurança adicional, como também pode evitar que uma boa automação dê errado.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...