Permissões de acesso just-in-time para a equipe operacional são uma prática recomendada de segurança. Mas como você os gerencia para incidentes e interrupções? Afinal, ao criar aplicativos modernos, o gerenciamento de permissões de acesso durante eventos operacionais é complicado.
As práticas recomendadas de segurança especificam que os engenheiros — desenvolvedores e engenheiros de operações — devem ter o menor acesso possível ao aplicativo de produção e sua infraestrutura. Afinal, às vezes, os requisitos de negócios ou os regulamentos do setor exigem que o acesso à produção seja severamente restrito. Contudo, mesmo sem requisitos do setor ou de negócios, as práticas recomendadas de segurança, como o princípio do privilégio mínimo, determinam que os engenheiros tenham o menor acesso possível à produção. E isso inclui os engenheiros responsáveis pelo gerenciamento de problemas operacionais de plantão.
No entanto, isso pode se tornar um problema quando um engenheiro de plantão precisa lidar com um problema em um aplicativo de produção. Quando as permissões são rigidamente controladas, os engenheiros de plantão ocasionalmente precisam de permissões adicionais para resolver problemas de produção. Às vezes, atos simples, como reinicializar um servidor de produção, estão além das permissões normais de um engenheiro de plantão, contudo, podem ser necessários em uma emergência.
E em caso de emergência?
Então, como os engenheiros de plantão realizam essas atividades durante uma emergência? Ao realizar um escalonamento de permissões de acesso just-in-time. Esta é uma ação que concede temporariamente a um engenheiro permissões adicionais para realizar procedimentos de emergência que normalmente estariam além de suas permissões.
Mas como um engenheiro pode escalar suas permissões sem que a capacidade de escalar suas próprias permissões se torne uma vulnerabilidade de segurança?
Há quatro maneiras de realizar o escalonamento de permissões de acesso just-in-time que podem conceder a seus engenheiros de plantão as permissões de que precisam. Isso, limitando as vulnerabilidades de segurança inerentes à concessão de permissões adicionais. No entanto, vale lembrar que cada um tem vantagens e desvantagens.
BTG ou Break the Glass
O modelo BTG ou Break the Glass permite que um engenheiro de plantão solicite a um processo do sistema um escalonamento de permissões de acesso just-in-time, a ser usado apenas em situação de emergência. Quando o engenheiro solicita essas permissões adicionais, um sistema automatizado concede as permissões necessárias.
Contudo, imediatamente registra a solicitação e envia uma notificação ao gerenciamento apropriado para informá-los sobre a solicitação. Como o engenheiro está ciente dessa notificação, ele sabe que só pode “Quebrar o vidro” durante uma emergência real e que terá que explicar suas ações posteriormente, como durante uma próxima revisão de incidente. Portanto, isso torna improvável que alguém solicite essas permissões adicionais, exceto quando absolutamente necessário.
Esse modelo é normalmente muito fácil de implementar em um ambiente de produção e permite aos engenheiros a flexibilidade necessária durante uma emergência. No entanto, o processo de revisão é um processo reativo, não um processo proativo. Ou seja, o gerenciamento só pode revisar o que aconteceu que levou o engenheiro a escalar suas permissões após o fato. Então, se um engenheiro insatisfeito solicitar a um BTG permissões de acesso just-in-time para realizar uma atividade nefasta, a administração só saberá depois que ela ocorrer, não antes. Por causa disso, o modelo BTG é ótimo para ambientes moderadamente seguros. Em contrapartida, não é aceitável quando é necessário um alto nível de segurança ou proteção contra possíveis ações ruins de funcionários.
Encaminhamento registrado
No modelo de escalonamento registrado, quando um engenheiro precisa executar determinadas atividades privilegiadas além de seu nível de permissão normal, ele usa comandos específicos que são registrados e monitorados para acesso inadequado. Por exemplo, se um engenheiro requer acesso a uma rede privada protegida, ele pode fazer login em um bastion host, um servidor que dá acesso à rede privada protegida. Contudo, o bastion host registra todas as atividades que o engenheiro realiza, disponibilizando-as para exame após o evento. A intenção é garantir que nenhum agente mal-intencionado entre e execute ações inadequadas na rede protegida, mas atividades legítimas ainda possam ocorrer normalmente.
Semelhante ao modelo BTG, o modelo de escalonamento registrado permite que qualquer engenheiro com permissões apropriadas acesse a rede de produção para quaisquer propósitos apropriados, não apenas uma emergência. No entanto, esses usuários só têm acesso dentro de um ambiente de “casa de vidro”. Ou seja, um ambiente onde cada ação tomada fica visível para análise posterior. Isso oferece muitas das mesmas vantagens do modelo BTG, mas com desvantagens semelhantes. Ou seja, a administração saberá sobre a atividade nefasta somente depois que ela ocorrer e não tem capacidade de preveni-la de antemão.
Escalação de duas pessoas
O escalonamento de duas pessoas é um aprimoramento do modelo BTG. Afinal, o escalonamento do BTG é permitido somente se duas pessoas independentes estiverem trabalhando juntas no problema e ambas autorizarem o escalonamento. Então, por política, todas as ações que eles realizam no BTG devem ser revisadas por ambas as partes. Não obstante, ambas as partes devem estar envolvidas em todas as atividades de escalonamento realizadas.
Esta é uma grande melhoria na segurança em relação ao modelo BTG básico, porque principalmente elimina o funcionário insatisfeito de poder prejudicar a produção simplesmente emitindo uma escalação de BTG. Ao invés disso, dois funcionários devem trabalhar juntos para realizar proativamente quaisquer ações. Portanto, nenhum funcionário pode danificar um sistema sem ter um segundo funcionário como cúmplice, o que melhora significativamente a segurança geral.
Entretanto, o modelo de escalonamento de duas pessoas pode ser mais difícil de aplicar, devido aos requisitos de política que as pessoas devem seguir para que seja eficaz. Afinal, deve ser insustentável para um engenheiro trabalhar com outro engenheiro para conceder acesso ao BTG para duas pessoas e, em seguida, permitir que o engenheiro solitário use o acesso exclusivo e não monitorado. Tal problema anula o propósito do modelo de escalonamento de duas pessoas.
Ferramentas de escopo limitado
Para segurança máxima, ferramentas de escopo limitado são o melhor modelo. Isso envolve a criação de ferramentas personalizadas que executam atividades específicas necessárias para fornecer manutenção operacional a um aplicativo de produção. Então, se você precisar executar alguma ação além de seus recursos normais, chame a ação usando uma ferramenta projetada sob medida para realizar esse acesso.
Por exemplo, se um engenheiro de plantão precisar reinicializar um servidor de produção, ele normalmente efetuará login no servidor de produção como “raiz” e reinicializará o servidor. Isso requer um nível de permissões inaceitável na maioria dos ambientes de produção. No entanto, imagine um console da Web que dê a um engenheiro de operações a capacidade de pressionar um botão para iniciar uma reinicialização dos servidores de produção. Ou seja, eles podem, usando suas permissões normais, executar uma ação específica que normalmente exigiria permissões escalonadas de acesso just-in-time.
Prós e contras
A vantagem do modelo de ferramentas de escopo limitado é que ele fornece ao usuário os recursos exatos de que ele precisa e apenas esses recursos. Isso preserva o princípio da permissão mínima, no entanto, oferece ao operador os recursos específicos necessários. A ferramenta personalizada normalmente também oferece os benefícios do modelo de escalonamento registrado. Afinal, acompanha quem usa a ferramenta e quando ela é usada. Afinal, assim as atividades envolvidas podem ser rastreadas e examinadas posteriormente durante uma revisão de incidente.
Entretanto, a desvantagem do modelo de ferramentas de escopo limitado é que ele não fornece um modelo genérico de escalonamento de permissões de acesso just-in-time. Ela dá acesso apenas a recursos específicos que foram imaginados com antecedência, usando ferramentas criadas para permitir essa ação. Então, se você precisar executar alguma ação que exija permissões escalonadas e nenhuma ferramenta estiver disponível para executar essa ação, você, como engenheiro de operações, pode estar simplesmente sem sorte.
Como tal, embora as ferramentas de escopo limitado sejam o melhor e mais seguro modelo geral, muitas vezes não são usadas sozinhas. Na verdade, elas costumam ser usadas em conjunto com um dos outros modelos para permissões imprevistas que podem ser necessárias. No entanto, isso pode diminuir as vantagens de segurança inerentes a esse modelo.
Qual modelo é melhor?
Esses quatro métodos são práticas recomendadas. No entanto, funcionam apenas para algumas empresas e são inaceitáveis para outras. Então, na prática, geralmente é empregada uma combinação de vários métodos. Ao selecionar os processos, complexidades e monitoramento operacional apropriados para seus negócios e setor, você pode implementar o escalonamento de permissões de acesso just-in-time sem comprometer indevidamente seu aplicativo e sua segurança.
