Regra de segurança número um: Você provavelmente está violando isso agora
Agora você já ouviu a Regra de Segurança Zero o suficiente para conhecê-la de cor . Você sabe de cor, certo?
Só por precaução, deixe-me refrescar sua memória:
NÃO CONFIARÁS NAS INFORMAÇÕES DO USUÁRIO. SEMPRE.
Excelente. Agora que estabelecemos e esclarecemos essa regra fundamental, vamos falar sobre a Regra de Segurança Um. Porque, como você deve ter adivinhado, há mais de uma regra de segurança. Então, vamos passar para a regra um, certo?
REGRA DE SEGURANÇA UM: NÃO CODIFICARÁS CREDENCIAIS. SEMPRE.
Em uma era de controle de acesso via tokenização (popular para APIs) e identidade federada, essa regra raramente é quebrada para aplicativos públicos. Onde essa regra é frequentemente quebrada e ignorada é dentro da organização. E isso está rapidamente se tornando um problema à medida que a NetOps intensifica o uso de scripts e automação para fazer sua parte na otimização da TI em suporte às iniciativas de transformação digital de sua organização.
Deixe-me ilustrar com um dos exemplos muito reais que encontrei na Internet. Digo uma porque não tenho tempo nem largura de banda para fornecer uma lista abrangente. A prática é tão difundida.
À sua direita, você verá uma gafe de segurança extremamente comum: credenciais em texto simples e codificadas. Não há sequer um comentário reconhecendo que isso é inaceitável em um ambiente de trabalho, nem um aceno de cabeça em direção à necessidade de usar um método de autenticação mais seguro.
Isso me incomoda profundamente no contexto do lado do NetOps porque o raio de alcance é significativamente maior quando você está mexendo com a rede corporativa compartilhada.
Uma das razões pelas quais vemos esse tipo de problema de segurança é porque, embora seja verdade que o NetOps está adotando a automação, ele não está necessariamente adotando-a estrategicamente. O que estamos vendo é uma porcentagem significativa de profissionais de NetOps que estão pegando Python e combinando-o com um método tradicional de configuração e gerenciamento baseado em CLI.
Assim como eles digitariam as credenciais na linha de comando, eles colocam essas mesmas credenciais em um script e pronto.
No final das contas, isso será um problema. Veremos alguém tirar proveito dessa prática e ela estará em nossos feeds de notícias por dias. Porque esse tipo de coisa já aconteceu antes. Lembra do OneLogin ? Embora eles não estivessem armazenando scripts com credenciais, eles estavam armazenando arquivos com credenciais. Você pode imaginar a bagunça que isso fez.
O problema é que a NetOps pode se sentir bastante confiante em colocar credenciais de linha de comando em um script, mas onde esse script vai parar? É administrado como deveria ser? Gosta de infraestrutura como código? Ele é versionado e mantido em um repositório?
Você deve se lembrar de uma pesquisa da comunidade Network to Code que mostrou uma alta taxa de adoção entre NetOps para (espere...) Github.
Então vamos nos perguntar: onde está nosso repositório? É fora do local? No local? Como ele é protegido e qual o raio de explosão caso alguém o pegue?
Precisamos, para manter e atender o negócio, dimensionar as operações por meio de scripts e automação. A NetOps precisa se mover nessa direção, mas não deve fazê-lo sem considerar seriamente as ramificações das credenciais de texto simples armazenadas, bem, em qualquer lugar.
No mínimo, os scripts devem exigir a entrada de credenciais na invocação. Credenciais nunca devem ser armazenadas em um arquivo ou no script e certamente nunca em texto simples. O ideal seria usar uma solução de gerenciamento de credenciais mais avançada para forçar a autenticação e usar a tokenização em scripts internos. Mas sei que agora estamos apenas no momento inicial da adoção em massa da automação em NetOps, e temos que dar um passo de cada vez.
Com isso em mente, pelo menos exija credenciais na invocação. Se isso for muito difícil com sua implementação atual, talvez seja hora de dar um passo para trás e dar uma olhada em sua estratégia geral de automação para TI. A primeira pergunta é: você tem uma? Ou o que você está fazendo é uma resposta tática (e primária) às demandas do negócio?
Porque a solução a longo prazo não deve – não pode – ser credenciais em texto simples em cada script. Além do risco óbvio de segurança, considere a dívida técnica que você está contraindo. Se você tiver que alterar credenciais, terá que alterá-las em todos os lugares . Leva tempo e esforço para localizá-los. Tempo e esforço você provavelmente não tem, caso contrário não estaria tão ansioso para reservar tempo adotando a automação em primeiro lugar.
Então, por favor, não viole a Regra de Segurança Um. Seja mais seguro e inteligente do que isso. A automação não deve ser uma resposta tática aos requisitos de escala e velocidade. Deve ser – e é – estratégico, e isso significa estar mais atento às ramificações de longo prazo de como você o está implementando.