Privilégio de Administrador para os Desenvolvedores

Uma pergunta recorrente no meu trabalho, e que não poderia deixar de faltar na sessão de "Ask the Experts" do TechEd deste ano,é sobre como montar um ambiente e um processo de desenvolvimento onde os desenvolvedores não precisem ter privilégios administrativos nas suas máquinas. Para resumir, os desenvolvedores alegam que precisam ser administradores das suas máquinas para poder fazer o seu trabalho, enquanto a área de segurança invariavelmente resiste a permitir que isso aconteça.

Primeiro permita-me dar razão aos desenvolvedores: eles realmente precisam ter direitos administrativos, e realisticamente não acho que se possa fugir disso. Se você desenvolve um software que precisa de direitos administrativos para ser instalado e/ou configurado -  o que engloba praticamente todos os softwares existentes - você precisa então destes direitos para testá-lo. De outra forma você não poderia reinstalar uma nova versão do componente, ou alterar os parâmetros de configuração para avaliar os diferentes casos.

Privilégios administrativos também são necessários para debugar um processo. Essa é uma condição de segurança garantida pelo sistema operacional, já que debugar significa ter a capacidade de alterar a execução de um processo, o que significa que você na prática comanda este processo. Se um usuário tem permissão de debug na então ele na verdade tem privilégios administrativos, mesmo que nominalmente não faça parte do grupo Administradores.

(O usuário pode debugar os processos rodando com a sua própria conta, sem precisar ser administrador. No entanto nem sempre é possível configurar os processor para rodar com as suas credenciais, e em vários casos isso é possível mas não desejável.)

Uma área de segurança que insista em retirar totalmente os privilégios de administrador dos desenvolvedores está portanto comprando uma luta inglória. Ela está na verdade tentando impedir que uma área que é normalmente vital para o negócio da empresa possa trabalhar, e assim agindo contra os objetivos de negócio da organização. No final não vai conseguir nada a não ser gerar ruído e desgaste inútil.

O que a área de segurança pode fazer então? O seu papel - trazer o risco para um nível aceitável. Se os desenvolvedores precisam ter direitos administrativos, então vamos fazer com que isso não traga riscos em nível intolerável pela organização. O que pode ser feito hoje com bastante sucesso, se você encarar o problema da ótica de gerência de risco e não de como retirar privilégios dos desenvolvedores.

Para começar precisamos identificar estes riscos. Privilégios de administrador dados aos desenvolvedores expõe a organização aos seguintes riscos:

1. O desenvolvedor pode colocar as suas máquinas em situação de não-conformidade, ou seja, desligar ou remover o antivirus, não instalar patches, abrir o firewall, rodar softwares não-autorizados, etc.

2. Ao usar a máquina com privilégios administrativos o desenvolvedor está mais exposto a ser infectado por malware ao navegar na Internet, ler e-mail ou executar de qualquer forma um software malicioso.

Retirar os privilégios administrativos é a forma óbvia de mitigar estes riscos, mas não a única. Outros controles efetivos que a área de segurança pode adotar para mitigá-los são respectivamente a Gerência de Conformidade e o uso do User Account Control do Windows Vista.

Gerência de Conformidade

Trust, but verify.

O princípio por trás de um processo de Gerência de Conformidade é simples: nós damos a você o privilégio de administrador que você precisa, mas você vai ter que seguir as políticas de segurança da organização. Se o seu computador não estiver de acordo com as políticas, nós vamos intervir e colocá-lo de novo em conformidade. Se nós não conseguirmos fazer isso, então tiramos o seu computador da rede. Isso permite à organização perfeitamente mitigar o risco (1) acima, sem retirar os privilégios necessários aos usuários.

Na Microsoft é utilizada uma ferramenta interna que varre toda a rede a cada três horas, identificando os ativos e verificando a conformidade com as políticas de segurança. Um desktop ou laptop por exemplo tem que fazer parte do Active Directory, estar com todas as correções de segurança instaladas, com o antivirus ligado e atualizado, firewall pessoal habilitado, sem os principais programas de P2P, etc. Perto de 90 verificações distintas são feitas nos sistemas deste perfil.

Note que isso não é uma análise de vulnerabilidades. Não estamos preocupados em saber se o sistema está vulnerável a este ou aquele ataques, e uma análise de vulnerabilidades seria de qualquer forma muito mais custosa e poderia gerar vários efeitos colaterais. Estamos verificando somente se o sistema está de acordo com as políticas e normas da organização, e não é necessário ter nenhum agente instalado nos sistemas.

Caso alguma não-conformidade seja encontrada a ferramenta tenta automaticamente remediar o sistema. Por exemplo, se o antivírus foi desligado (por algum motivo desenvolvedores adoram fazer isso), a ferramenta tenta religar o serviço. Se faltam patches, o SMS é acionado para instalar as atualizações necessárias. Na maioria dos casos isso é suficiente e o usuário nem precisa ser notificado.

Se isso a remediação não for possível, como nos casos onde o sistema está fora do Active Directory, a máquina é removida da rede para não se tornar um risco aos demais sistemas. Isso é feito revogando o certificado da máquina, o que faz com que ela perca o acesso a rede Wireless e ao IPsec, e desabilitando a porta de rede via RMON. Exceções podem raramente ser concedidas, mas duram no máximo 3 dias e precisam da assinatura de um VP. Ou seja, resolva o seu problema!

Gerência de Conformidade é talvez o controle/processo que mais reduza os riscos de segurança para uma organização (junto com senhas fortes e patch management), e sempre me admira ver organizações que investem fortunas em coisas como IDS/IPS ou biometria antes de fazer a lição de casa neste ponto. Para saber mais sobre como a Microsoft faz Gerência de Conformidade, veja o paper em https://www.microsoft.com/technet/itshowcase/content/securingitenviron.mspx.

User Account Control (UAC)

Umas das mudanças mais perceptíveis e radicais implementadas no Windows Vista é que os usuários não são mais por default administradores do sistema. E na verdade mesmo se a conta fizer parte do grupo de Administradores, o seu token de logon é criado sem este privilégio e o usuário é "rebaixado" a usuário comum. O privilégio é concedido somente ao executar alguma tarefa que realmente necessite desse privilégio, e depois de uma  confirmação pelo usuário.

O risco (2) é então bastante mitigado. O desenvolvedor pode ler o seu e-mail, escrever código e navegar na Internet usando o seu usuário sem estar exposto a maior parte dos tipos de malware. Ao precisar instalar um componente ou debugar código, ele eleva o seu privilégio - somente para aquele processo e somente enquanto for necessário. A necessidade de elevação é detectada de forma automática, e a curva de aprendizado e eventuais incompatibilidades se reduzem drasticamente.

Ter os desenvolvedores rodando com o UAC tem o benefício adicional de educar os próprio a desenvolverem softwares que funcionem bem com o UAC, e não fiquem exigindo desnecessariamente privilégios elevados. Pensando bem, talvez este seja o maior ganho ;)

Em resumo, retirar os privilégios administrativos dos desenvolvedores é remar contra próprio o negócio da empresa, e a área de segurança deve focar no objetivo final que é manter os riscos em um nível aceitável. Gerência de Conformidade e o UAC são controles efetivos que podem ser utilizados para este fim.

P.S. Existem outros riscos relacionados a um ambiente de desenvolvimento, como o vazamendo de código, que eu não tratei aqui porque não estão relacionados diretamente ao uso de privilégios administrativos. Mas vamos discutí-los em uma outra oportunidade.

Comments

• Anonymous
  January 04, 2007
  Me identifiquei muito com este post... Há 14 meses atrás, na implementação de segurança para a área de desenvolvimento, tive uma discussão (de alto nível) sobre como abordar esta questão. Por falta de ferramentas, liberamos os desenvolvedores no grupo de administradores locais e criamos um ambiente de homologação sem estes direitos... Este ambiente de homologação foi criado como uma forma de validar a aplicação antes do deploy para o ambiente de produção (estações e servidores), de forma a que rodasse plenamente sem os direitos administrativos. Em março iremos iniciar a validação com o Vista e espero que o UAC minimize meus problemas de segurança :-)

• Anonymous
  January 04, 2007
  Cima, esses processos realmente são "estado da arte" quando se consegue implementar. Agora usar o LUA do Aaron Margosis por exemplo, para criar um usuário apenas com o perfil necessário somente para executar a função de desenvolvedor, também mitiga muitos riscos. Eu acho que a área de segurança deve aplicar controles para garantir o least privilege. Porque sabemos que o ambiente implementado pela microsoft hoje é uma exceção.

• Anonymous
  January 07, 2007
  Olá Fernando, permita-me discordar de uma afirmação tua: "Primeiro permita-me dar razão aos desenvolvedores: eles realmente precisam ter direitos administrativos, e realisticamente não acho que se possa fugir disso" Eu reescreveria ressaltando que NEM TODO desenvolvedor precisa de privilégios administrativos, talvez ainda QUASE NENHUM desenvolvedor precisa. Existem N formas de contornar isso e já vi dois ambientes (USP e EDS) configurados para tal, sem dar direito algum à programador algum. Primeiramente, é possível depurar sim programas sem direitos de admin. Existe um grupo local próprio para isso (Debugger Users ou coisa parecida - que não deve ser suficiente para alguns tipos de tarefas mais específicas, mas no geral serve). Depois, para poder testar a instalação de componentes e do próprio software existem técnicas mais interessantes, como usar máquinas virtuais por exemplo. Elas garantem que o ambiente de teste seja totalmente isolado do ambiente de desenvolvimento sem ter que gastar com mais hardware (e veja que software de virtualização já não é um problema hoje). Eu ainda diria (opinião minha mesmo), que é melhor não ter direitos de admin ao programar. Isso desestimula a usar nos programas recursos dos quais ele não vai ter quando o programa final for executado com credenciais de usuário comum, evitando depois mensagens de erro estranhas e absurdas. Além disso, separar os dois ambientes (desenvolvimento e teste) é um ponto chave para desenvolver um sistema de qualidade... já vi isso em alguns livros de engenharia de software. =) No entanto, não sou xiita o suficiente pra dizer "senha de admin pra programador nunca!". Existem situações e situações. O desenvolvimento de drivers e qualquer outra coisa de baixo nível é um exemplo disso. Nunca brinquei com nada em baixo nível no Windows, mas imagino que seja um trabalho considerável (ainda assim, conheço alguns amigos que já desenvolveram drivers mesmo sem conta alguma de admin, provavelmente desenvolvendo em uma máquina e testando em outra). Eu já escrevi um pouco sobre o assunto no meu blog, e o Aaron Margosis tem um específico sobre isso. Mas não era nada tão profundo quando o que li aqui... gostei, tá de parabéns! []s, Vinicius Canto - MVP