Ubuntu para funcionários de desenvolvimento de bancos [fechado]

Existem processos e métodos documentados sobre como executar computadores Ubuntu personalizados (da instalação ao uso diário) para bancos e outras empresas que não desejam que os usuários baixem binários de locais possivelmente inseguros?

Para que o apt-get, update etc aconteça apenas em alguns locais confiáveis ​​da Internet ou intranet?

Atualização: adicionada após a primeira resposta. Esses usuários são suporte, usuários iniciantes de sistemas e desenvolvedores do software do banco ... então alguns deles precisam de privilégios de sudo. Existe uma maneira pronta de monitorá-los para que todas as exceções sejam capturadas rapidamente (como adicionar a lista de fontes), mas outras ações, como instalar coisas de repositórios conhecidos, não são relatadas.

O objetivo é ser seguro, usar o Ubuntu ou um sabor, permitir que desenvolvedores e outros usuários do sudo sejam o mais produtivos possível. (E reduza a dependência em computadores Windows e Mac)

.2. E o pessoal de TI pode atribuir políticas aos usuários para que eles não possam executar algumas ações, como compartilhar uma pasta, mesmo que o usuário sudo? Uma solução completa?

Esta é uma pergunta muito boa, mas sua resposta é muito difícil.

Primeiro, para começar, Timothy Truckle tem um bom ponto de partida. Você executaria seu próprio repositório apt, onde sua equipe de segurança poderia verificar todos os pacotes. Mas isso é apenas o começo.

Em seguida, você deseja implementar grupos. Você gostaria que os usuários pudessem fazer as coisas de que precisam sem muita ajuda do suporte. Mas no setor bancário, você realmente quer que as coisas sejam trancadas. De fato, em muitas estruturas corporativas, você deseja bloquear as coisas. Portanto, conceder privilégios sudo a usuários normais em qualquer nível provavelmente está fora.

O que você provavelmente faria é definir as coisas para que determinados grupos não precisem de permissões elevadas para realizar seus trabalhos.

Novamente, na maioria dos ambientes corporativos, instalar software é algo que pode fazer com que você seja demitido, então isso é um não, não. Se você precisar de um software, ligue para a TI e eles farão isso por você, ou há uma cadeia de requisições ou algo assim.

Idealmente, você nunca precisaria de um funcionário normal para instalar nada ou precisaria de permissões elevadas.

Agora, para os desenvolvedores, a questão é um pouco diferente. Talvez eles precisem instalar e talvez precisem do sudo. Mas suas caixas estão na "rede de perigo" e NUNCA podem se conectar diretamente a sistemas críticos.

A equipe de TI / Suporte precisará do sudo. Mas você pode limitar o acesso ao sudo por comando ou processo (papelada) ou outros meios. Pode haver volumes inteiros sobre coisas como o "princípio dos 2 olhos" e como implementá-lo. Porém, os logs de auditoria existem e podem ser configurados para atender à maioria das necessidades.

Então, voltando à sua pergunta. A resposta de Timothy Truckle é 100% correta, mas a premissa para sua pergunta está errada. Proteger um sistema operacional Linux é muito mais sobre a escolha das configurações necessárias para seu caso de uso específico e menos sobre uma idéia geral de como proteger as coisas.

Configure seu próprio proxy de repositório debian dentro da sua intranet.

Personalize a instalação do ubuntu para que seu proxy do repositório debian seja a única entrada no /etc/apt/sources.list.

Et voila: você tem controle total sobre o software instalado em seus clientes (desde que nenhum usuário tenha permissões de superusuário).

Atualização: adicionada após a primeira resposta. Esses usuários são suporte, usuários iniciantes de sistemas e desenvolvedores do software do banco ... então alguns deles precisam de privilégios de sudo. Existe uma maneira pronta de monitorá-los para que todas as exceções sejam capturadas rapidamente (como adicionar a lista de fontes), mas outras ações, como instalar coisas de repositórios conhecidos, não são relatadas.

Em sua instalação personalizada você pode modificar o /etc/sudoersarquivo para que os usuários têm permissão para executar sudo apt updatee sudo apt installmas nenhum outro comando começando com apt. Obviamente, você também precisa restringir sudo bash(ou qualquer outro shell).

Em quase todas as lojas que vi até agora, os desenvolvedores tinham acesso total às máquinas de desenvolvimento, mas essas máquinas só tinham acesso à Internet e ao repositório de código-fonte.

O código-fonte é registrado e compilado em máquinas confiáveis ​​(nas quais os desenvolvedores geralmente não têm ou precisam de permissões administrativas) e, em seguida, implantado em sistemas de teste que têm acesso à rede interna.

Se essas máquinas são usadas pelos desenvolvedores ou por uma equipe de teste separada, depende da sua organização - mas geralmente o limite entre máquinas confiáveis ​​e não confiáveis ​​é entre máquinas separadas, com a interface entre elas verificável (como confirmações do código-fonte).

Os funcionários da recepção nunca recebem privilégios administrativos. Quando implantamos o Solitaire em todas essas máquinas, as reclamações sobre essa política praticamente cessaram.