Ubuntu para funcionários do banco dev [fechado]

Question

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

Para que o apt-get, update etc aconteça apenas em algumas localizações confiáveis de internet ou intranet?

Atualização: adicionada esta 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 quaisquer exceções sejam capturadas rapidamente (como adicionar a lista de fontes), mas outras ações como a instalação de material 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 de sudo sejam tão produtivos quanto possível. (E reduza a dependência em computadores Windows e Mac)

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

    

Answer 1

Esta é uma pergunta muito boa, mas a 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 cada pacote. Mas isso é apenas o começo.

Em seguida, você deseja implementar grupos. Você deseja que os usuários possam fazer as coisas de que precisam sem muita ajuda do suporte. Mas, no setor bancário, você realmente quer que as coisas sejam bloqueadas. De fato, em muitas estruturas corporativas, você quer bloquear as coisas. Portanto, conceder privilégios normais aos usuários sudo 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, a instalação de software é algo que pode fazer com que você seja demitido, de modo que não é um não. Se você precisa de um software, você chama de TI e ele faz isso por você, ou há uma cadeia de requisição ou algo assim.

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

Agora, para desenvolvedores, a questão é um pouco diferente. Talvez eles precisem instalar e talvez precisem de 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 do sudo por comando ou processo (papelada) ou outros meios. Pode haver volumes inteiros sobre coisas como o "2 olhos principais" e como implementá-lo. Mas os logs de auditoria existem e podem ser configurados para atender à maioria das necessidades.

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

    

Answer 2

Configure o seu próprio proxy do repositório debian na sua intranet.

Personalize a instalação do ubuntu para que seu proxy do repositório debian seja a única entrada em /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 esta 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 quaisquer exceções sejam capturadas rapidamente (como adicionar a lista de fontes), mas outras ações como a instalação de material de repositórios conhecidos não são relatadas.

Em sua instalação personalizada, você pode modificar o arquivo /etc/sudoers para que seus usuários tenham permissão para executar sudo apt update e sudo apt install , mas nenhum outro comando inicia com apt . Claro, você também tem que restringir sudo bash (ou qualquer outro shell).

    

Answer 3

Em quase todas as lojas que vi até agora, os desenvolvedores tinham acesso total a 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 (as quais os desenvolvedores normalmente não têm ou precisam de permissões administrativas) e, a partir daí, são implantadas para testar sistemas que tenham acesso à rede interna.

Se essas máquinas são usadas pelos desenvolvedores ou por uma equipe de testes separada, elas dependem da 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áveis (como confirmações de código fonte) .

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