Permissões do Windows para desenvolvedores?

Trabalho em uma empresa da Fortune 500 como desenvolvedor de software para Windows em P&D. Atualmente, a TI corporativa está se preparando para uma implantação Win7 em toda a empresa e, como parte dela, está procurando bloquear completamente os direitos de administrador em todas as caixas (incluindo nossas estações de trabalho de desenvolvimento).

Fui encarregado de trabalhar com eles para tornar a transição o mais suave possível. Sorte minha.

Eu gostaria de saber se existem recursos publicados ou outros altamente respeitados por aí que eu possa usar para:

1. descobrir onde desenhar uma linha na areia
2. respaldo minha posição.

Pessoalmente, minha opinião é que somos pesquisa e desenvolvimento e nosso trabalho é fazer coisas que estão "prontas para uso". Portanto, precisamos de direitos de administrador. No entanto, tendo iniciado minha carreira como administrador do Windows, estou ciente de seus objetivos e do que eles precisam alcançar. O que eu preciso descobrir e fazer backup é uma maneira de criar o ambiente de uma maneira que a TI e a P&D possam conviver com ele e continuar executando seus trabalhos de maneira produtiva.

VMs de desenvolvimento com direitos de administrador local definitivamente ajudarão muito, mas não em todos os casos, uma vez que interagimos com muito hardware personalizado.

O CIO que promove essas mudanças é definitivamente um tipo de pessoa de "pura TI", com conhecimento limitado do processo de desenvolvimento, por isso preciso de algumas referências que seriam apropriadas para compartilhar com alguém assim.

Não pretendo reunir muitas opiniões pessoais (muitas das quais já foram compartilhadas aqui ), preciso mesmo de white papers, artigos de revistas, trabalhos acadêmicos etc. para usar para defender a alta gerência.

Como você está indo especificamente para o Windows 7, você deve se esforçar para ser administrador em suas próprias caixas. Existem duas boas razões para impedir que os desenvolvedores sejam administradores:

• pelo mesmo motivo que impede que todos os outros sejam administradores, para que o malware não faça coisas realmente terríveis se for executado
• para que eles não escrevam aplicativos que só funcionem se você for um administrador

Com o UAC, nada disso acontecerá, pois os aplicativos iniciados não serão executados como administrador, a menos que você os peça deliberadamente. Portanto, há pouco risco de permitir que você tenha uma conta de administrador.

Alguns chefes têm um terceiro motivo - não quero que você instale jogos ou ferramentas não autorizadas. Sem discutir os méritos dessa razão, observarei que ela geralmente permanece inalterada. Você precisa de acesso de administrador para instalar o que está escrevendo, configurar o IIS, reconfigurar sua máquina para vários tipos de teste (por exemplo, editar seu arquivo host) e os dois motivos "reais" para evitar o acesso de administrador não se aplicam mais ao Windows 7 Portanto, você deve ser administrador.

Honestamente, acho que será um caso difícil de se fazer. Depois que a alta gerência decide, é bem difícil fazer com que eles mudem. Se eles permitissem mais privilégios em sua máquina, alguém poderia acessar e executar as ações que todo esse plano foi projetado para impedir.

Isso pode ajudar:

• http://www.slate.com/id/2226279/pagenum/all/
• /server/232416/should-dev-be-admin-on-their-computer
• http://avecto.com/blog/2010/09/the-pros-and-cons-of-windows-7-application-control-with-applocker/

PS: Boa sorte!

Uma opção é solicitar estações de trabalho de teste que permitam acesso administrativo.

Outra opção é fazer exatamente o que eles dizem. Então, quando o próximo projeto chegar, você não estará fazendo nenhum progresso, porque você precisará ir à TI para cada pequena alteração. Explique isso ao líder do projeto e ele providenciará os direitos de administrador rapidamente.

Uma terceira opção é verificar se o seu departamento está representado no projeto de migração do Win7. Nesse caso, entre em contato com seu representante e pergunte se ele pode adicionar direitos administrativos à lista de requisitos do seu departamento.

Uma quarta opção é negociar. O projeto de migração geralmente precisa de desenvolvimento para atualizar seu software para o Win7. Pode ser possível condicionar uma atitude de apoio aos direitos de administrador no novo ambiente.

Não consigo imaginar tentar desenvolver sem ser um administrador local, no entanto, acho que as necessidades variarão dependendo das tarefas de desenvolvimento e de como o processo de desenvolvimento e a cadeia de ferramentas são padronizados no seu local de trabalho.

Pela minha experiência, geralmente há uma equipe de desenvolvimento sênior que precisará instalar várias ferramentas de desenvolvimento (às vezes em horários estranhos) para prototipar rapidamente ou solucionar problemas críticos. Eles quase certamente precisam de acesso de administrador local para instalar, depurar, trabalhar com serviços etc.

A equipe restante poderá sobreviver sem ela, se o seu conjunto de ferramentas for bastante constante e dependendo do que eles desenvolvem / depuram / implantam. Minha sugestão seria reunir um pequeno conjunto de sua equipe sênior de desenvolvedores, explicar o problema e suas opções, e fazer com que levassem alguns dias para considerá-lo, e depois ter uma reunião de planejamento para determinar que tipo de acesso a equipe deve ter.

De uma perspectiva pura de TI e de desenvolvimento, muitas empresas resolvem o problema desta maneira:

Coloque todas as caixas de desenvolvimento em uma rede separada. A rede de desenvolvimento pode estar completamente isolada (sem internet e sem intranet). Nesse caso, os desenvolvedores têm uma caixa corporativa separada usada para email e comunicações oficiais - ou seja, acesso à Internet e intranet. Essa solução tem seus próprios desafios, pois certos IDEs (como o Eclipse) e outras ferramentas de desenvolvimento supõem que você tenha uma conexão ativa com a Internet para obter atualizações e plugins. Ainda a grande maioria das ferramentas de desenvolvimento sabe que existem redes isoladas.

Outra variação dessa abordagem é ter a rede de desenvolvimento em uma sub-rede. Você tem acesso indireto à Internet e intranet por meio de um firewall DMZ rigoroso, mas ainda assim os desenvolvedores têm acesso de administrador local.

Considere dar duas contas aos desenvolvedores.

A primeira é uma conta de usuário não privilegiada normal, que é a única a ser usada em todo o trabalho diário (incluindo desenvolvimento de software). A outra é uma conta de administrador local, que possui apenas privilégios de administrador em máquinas específicas. Isso só deve ser necessário ao instalar coisas ou ajustar as configurações da máquina.

Garanta que os serviços do dia-a-dia, como o servidor proxy da Internet, o email e assim por diante, reconheçam apenas a conta normal, para que os desenvolvedores não possam usar o administrador local o tempo todo. Sempre que forem necessários privilégios de administrador, o UAC será exibido e oferecerá ao desenvolvedor a chance de inserir os detalhes de login do administrador local para prosseguir.

O desenvolvimento de software é uma fera fundamentalmente diferente de qualquer outro uso de um computador, e deve ser tratado como tal.

A capacidade de escrever seu próprio código e, mais importante ainda, rastrear sua execução de código na depuração, exige que você tenha permissões no computador que, em qualquer outro contexto, representariam um risco enorme à segurança local. Reformulado em forma de som:

Permissões necessárias para o desenvolvimento de software não são apropriadas para usuários comuns.

Para fazer seu trabalho, você precisa ser um administrador local. Mas, sendo administrador local e contornando a política de segurança, teoricamente você representa um risco para o resto da rede. Portanto, essa preocupação também precisa ser abordada. A maneira como as empresas críticas à segurança resolvem esse problema é impondo duas regras simples:

1. Programadores são acesso de administrador local em sua máquina de desenvolvimento.
2. Máquinas de desenvolvimento não estão conectadas à rede da empresa.

O desempenho da segunda regra depende do departamento de TI. Às vezes, a máquina de desenvolvimento é isolada por si só, sem entrada ou saída de rede (vista em vários prestadores de serviços de defesa) e, às vezes, a máquina é conectada a uma rede "Convidada" ou "DMZ" para permitir acesso à Internet (download de patches, acesso à documentação) , etc.) sem colocar a rede da empresa em risco indevido.

Agora, você encontrará alguma fonte oficial sobre isso? Eu acho que depende de quem você vê como oficial . A opinião sobre este assunto é basicamente unânime. Mas é tão bem compreendido que raramente é afirmado. É como perguntar: “ Meu carro deve ter um freio de mão ? ” Você não encontrará fontes autorizadas falando sobre o assunto, porque elas têm coisas melhores a fazer e todo mundo já sabe a resposta.

Você pode usar um ambiente virtual?

Se você não está fazendo coisas pesadas em gráficos, executar o MSVC no vmware ou no virtualbox é bom (se você tiver muita memória RAM), então você pode ter um administrador no ambiente virtual e a instalação 'deles' está bloqueada