Existe alguma maneira de tornar produtivo um syadmin Linux experiente sem dar a ele acesso root completo?
Esta questão vem de uma perspectiva de proteção da propriedade intelectual (PI), que no meu caso, é totalmente código e/ou arquivos de configuração (ou seja, pequenos arquivos digitais que são facilmente copiados). Nosso molho secreto nos tornou mais bem-sucedidos do que nosso tamanho pequeno poderia sugerir. Da mesma forma, somos uma vez mordidos, duas vezes tímidos com alguns ex-funcionários sem escrúpulos (não administradores de sistema) que tentaram roubar IP. A posição da alta administração é basicamente: "Confiamos nas pessoas, mas por interesse próprio, não podemos correr o risco de dar a qualquer pessoa mais acesso do que o estritamente necessário para realizar seu trabalho".
Do lado do desenvolvedor , é relativamente fácil particionar fluxos de trabalho e níveis de acesso de forma que as pessoas possam ser produtivas, mas ver apenas o que precisam ver. Apenas as pessoas de topo (proprietários reais da empresa) têm a capacidade de combinar todos os ingredientes e criar o molho especial.
Mas não consegui encontrar uma boa maneira de manter esse sigilo de IP no lado administrativo do Linux. Fazemos uso extensivo de GPG para código e arquivos de texto confidenciais ... mas o que impede um administrador de (por exemplo) processar um usuário e acessar sua sessão tmux ou GNU Screen e ver o que ele está fazendo?
(Também desativamos o acesso à Internet em todos os lugares que possam entrar em contato com informações confidenciais. Mas, nada é perfeito e pode haver falhas abertas para administradores de sistema inteligentes ou erros no lado do administrador da rede. Ou até mesmo o bom e velho USB. Existem alguns é claro que existem várias outras medidas em vigor, mas essas estão além do escopo desta questão.)
O melhor que posso fazer é basicamente usar contas personalizadas com sudo , semelhante ao que é descrito em Multiple Linux sysadmins working as root . Especificamente: ninguém, exceto os proprietários da empresa, teria acesso root direto. Outros administradores teriam uma conta personalizada e a capacidade de sudo na raiz. Além disso, o registro remoto seria instituído e os logs iriam para um servidor que só os proprietários da empresa poderiam acessar. Ver o log desativado dispararia algum tipo de alerta.
Um administrador de sistema inteligente provavelmente ainda poderia encontrar alguns buracos neste esquema. Além disso, ainda é reativo em vez de proativo . O problema com o nosso IP é tal que os concorrentes podem usá-lo muito rapidamente e causar muitos danos em pouco tempo.
Portanto, ainda melhor seria um mecanismo que limitasse o que o administrador pode fazer. Mas reconheço que esse é um equilíbrio delicado (principalmente à luz da solução de problemas e correção de problemas de produção que precisam ser resolvidos agora ).
Não posso deixar de me perguntar como outras organizações com dados muito confidenciais gerenciam esse problema. Por exemplo, administradores de sistemas militares: como eles gerenciam servidores e dados sem poder ver informações confidenciais?
Editar: na postagem inicial, pretendia abordar preventivamente os comentários sobre "práticas de contratação" que estão começando a surgir. Primeiro, isso deveria ser uma questão técnica , e as práticas de contratação da IMO tendem mais para questões sociais . Mas, dois, vou dizer o seguinte: acredito que fazemos tudo o que é razoável para contratar pessoas: entrevista com váriospessoas da empresa; verificações de antecedentes e referências; todos os funcionários assinam vários documentos legais, incluindo um que diz que leram e entenderam nosso manual, que detalha as questões de propriedade intelectual em detalhes. Agora, está fora do escopo desta pergunta/site, mas se alguém puder propor práticas de contratação "perfeitas" que filtrem 100% dos maus atores, sou todo ouvidos. Os fatos são: (1) não acredito que exista um processo de contratação tão perfeito; (2) as pessoas mudam - o anjo de hoje pode ser o demônio de amanhã; (3) tentativa de roubo de código parece ser algo rotineiro neste setor.
Tudo o que foi dito até agora é bom, mas há uma maneira 'fácil' e não técnica que ajuda a negar um administrador de sistema desonesto - o princípio dos quatro olhos que basicamente requer que dois administradores de sistema estejam presentes para qualquer acesso elevado.
EDIT: Os dois maiores itens que vi nos comentários estão discutindo custos e a possibilidade de conluio. Uma das maiores maneiras que considerei para evitar esses dois problemas é o uso de uma empresa de serviços gerenciados usada apenas para verificação das ações tomadas. Feito corretamente, os técnicos não se conheceriam. Assumindo a proeza técnica que um MSP deveria ter, seria fácil ter uma aprovação das ações tomadas.. talvez até tão simples quanto um sim/não para qualquer coisa nefasta.
Se as pessoas realmente precisam de acesso administrativo a um sistema, há pouco que você possa fazer para restringir suas atividades nessa caixa.
O que a maioria das organizações faz é confiar, mas verifique - você pode dar às pessoas acesso a partes do sistema, mas usa contas de administrador nomeadas (por exemplo, você não dá a elas acesso direto ao root ) e, em seguida, audita suas atividades em um log que eles não pode interferir.
Há um ato de equilíbrio aqui; você pode precisar proteger seus sistemas, mas também precisa confiar nas pessoas para fazer seu trabalho. Se a empresa foi anteriormente "mordida" por um funcionário sem escrúpulos, isso pode sugerir que as práticas de contratação da empresa são ruins de alguma forma, e essas práticas foram presumivelmente criadas pelos "altos gerentes". A confiança começa em casa; o que eles estão fazendo para corrigir suas escolhas de contratação?
O que você está falando é conhecido como o risco "Evil Sysadmin". O longo e curto é:
A combinação dessas coisas torna essencialmente impossível interromper ações maliciosas. Mesmo a audição se torna difícil, porque você não tem nenhum 'normal' para comparar. (E francamente - um sistema quebrado pode muito bem ter quebrado a auditoria também).
Há um monte de medidas mitigadoras:
sysloge auditoria em nível de evento, para um sistema relativamente inviolável ao qual eles não têm acesso privilegiado. Mas coletar não é suficiente, você precisa monitorar - e, francamente, há várias maneiras de 'roubar' informações que podem não aparecer em um radar de auditoria. (Caçador contra guarda-caças)Mas fundamentalmente - você precisa aceitar que isso é uma coisa de confiança, não uma coisa técnica. Seus administradores de sistema sempre serão potencialmente muito perigosos para você, como resultado dessa tempestade perfeita.
Sem se colocar em uma reviravolta técnica insana para tentar encontrar uma maneira de dar poder a um administrador de sistema sem dar poder a eles (provavelmente é possível, mas acabaria sendo falho de alguma forma).
Do ponto de vista da prática de negócios, há um conjunto de soluções simples. Não é uma solução barata, mas simples.
Você mencionou que os pedaços de IP com os quais você está preocupado estão divididos e apenas as pessoas no topo têm o poder de vê-los. Esta é essencialmente a sua resposta. Você deve ter vários administradores e NENHUM deles deve ser administrador em sistemas suficientes para montar a imagem completa. É claro que você precisaria de pelo menos 2 ou 3 administradores para cada peça, caso um administrador esteja doente ou em um acidente de carro ou algo assim. Talvez até mesmo escaloná-los. digamos que você tenha 4 administradores e 8 informações. o administrador 1 pode acessar os sistemas que possuem as partes 1 e 2, o administrador 2 pode acessar as partes 2 e 3, o administrador 3 pode acessar as partes 3 e 4 e o administrador 4 pode acessar as partes 4 e 1. Cada sistema tem um administrador reserva, mas não admin é capaz de comprometer a imagem completa.
Uma técnica que os militares também usam é a limitação da movimentação de dados. Em uma área sensível, pode haver apenas um único sistema capaz de gravar um disco ou usar uma unidade flash USB, todos os outros sistemas são restritos. E a capacidade de usar esse sistema é extremamente limitada e requer aprovação documentada específica por superiores antes que alguém tenha permissão para colocar quaisquer dados em qualquer coisa que possa levar ao vazamento de informações. Junto com o mesmo token, você garante que o tráfego de rede entre diferentes sistemas seja limitado por firewalls de hardware. Seus administradores de rede que controlam as paredes de incêndio não têm acesso aos sistemas que estão roteando, portanto, não podem obter acesso específico às informações, e os administradores de seu servidor/estação de trabalho garantem que todos os dados de e para um sistema sejam configurados para serem criptografados,
Todos os laptops/estações de trabalho devem ter discos rígidos criptografados, e cada funcionário deve ter um armário pessoal no qual eles são obrigados a trancar os drives/laptops no final da noite para garantir que ninguém chegue cedo/sai tarde e tenha acesso a algo eles não deveriam.
Cada servidor deve, no mínimo, estar em seu próprio rack trancado, senão em sua própria sala trancada, para que apenas os administradores responsáveis por cada servidor tenham acesso a ele, pois no final das contas o acesso físico supera tudo.
Em seguida, há uma prática que pode prejudicar/ajudar. Contratos limitados. Se você acha que pode pagar o suficiente para continuar atraindo novos talentos, a opção de manter cada administrador apenas por um período pré-determinado (ou seja, 6 meses, 1 ano, 2 anos) permitiria limitar quanto tempo alguém teria para tentar juntar todas as peças do seu IP.
Meu design pessoal seria algo parecido com... Divida seus dados em quantas partes, digamos, para ter um número 8, você tem 8 servidores git, cada um com seu próprio conjunto de hardware redundante, cada um administrado por um conjunto diferente de administradores.
Harddrives criptografados para todas as estações de trabalho que irão tocar o IP. com um diretório "projeto" específico na unidade que é o único diretório em que os usuários podem colocar seus projetos. No final de cada noite, eles são obrigados a limpar seus diretórios de projeto com uma ferramenta de exclusão segura, então os discos rígidos são removidos e trancado (só por segurança).
Cada parte do projeto tem um administrador diferente atribuído a ele, portanto, um usuário só interagiria com o administrador da estação de trabalho ao qual está atribuído; se a atribuição do projeto mudar, seus dados forem apagados, eles receberão um novo administrador. Seus sistemas não devem ter recursos de gravação e devem usar um programa de segurança para impedir o uso de unidades flash USB para transferir dados sem autorização.
tire disso o que quiser.
Seria semelhante ao desafio de contratar um zelador para um prédio. O zelador consegue ter todas as chaves, pode abrir qualquer porta, mas o motivo é que o zelador precisa delas para fazer o serviço. Mesmo com os administradores do sistema. Simetricamente, pode-se pensar nesse antigo problema e observar as formas pelas quais a confiança é concedida historicamente.
Embora não haja uma solução técnica clara, o fato de não haver nenhuma não deve ser uma razão para não tentarmos nenhuma, uma agregação de soluções imperfeitas pode dar ótimos resultados.
Um modelo onde a confiança é conquistada :
Implementar vários níveis de poderes administrativos :
Sempre crie um ambiente onde o acesso total por uma pessoa não seja possível :
Use a regra Two-man ao fazer alterações principais de alto nível :
Confie e comprove :
Papelada :
É muito difícil proteger hosts contra aqueles com acesso administrativo. Embora ferramentas como o PowerBroker tentem fazer isso, o custo é adicionar algo mais que pode quebrar E adicionar barreiras às tentativas de corrigi-lo. A disponibilidade do seu sistema VAI cair quando você implementar algo assim, então defina essa expectativa antecipadamente quanto ao custo de proteger as coisas.
Outra possibilidade é verificar se seu aplicativo pode ser executado em hosts descartáveis por meio de um provedor de nuvem ou em uma nuvem privada hospedada localmente. Quando um quebra, em vez de enviar um administrador para consertá-lo, você o joga fora e cria automaticamente um substituto. Isso exigirá muito trabalho do lado do aplicativo para fazê-lo funcionar neste modelo, mas pode resolver muitos problemas operacionais e de segurança. Se mal feito, pode criar alguns problemas de segurança significativos, portanto, obtenha ajuda experiente se você seguir esse caminho.
Esta é sua discussão básica: https://security.stackexchange.com/questions/7801/keeping-secrets-from-root-on-linux
Você divide sua responsabilidade tendo engenheiros de segurança cujo trabalho é fazer configurações e instalações do sistema, mas eles não obtêm credenciais ou acesso às máquinas em produção. Eles também executam sua infraestrutura de auditoria.
Você tem administradores de produção que recebem os sistemas, mas não têm as chaves para inicializar a máquina sem que as políticas do SELinux estejam ativas. A segurança não obtém as chaves para descriptografar dados confidenciais armazenados em repouso no disco para quando eles retiram uma máquina quebrada do serviço.
Faça uso de um sistema de autenticação centralizado com auditoria forte como o Vault e faça uso de suas operações criptográficas. Distribua dispositivos Yubikey para tornar as chaves absolutamente privadas e ilegíveis.
As máquinas são limpas em caso de quebra ou tratadas por operações e segurança juntas e, se você sentir necessidade, supervisão executiva.
Os administradores, pela natureza do trabalho, têm acesso a tudo. Eles podem ver todos os arquivos no sistema de arquivos com suas credenciais de administrador. Portanto, você precisará criptografar os arquivos para que os administradores não possam vê-los, mas os arquivos ainda podem ser usados pelas equipes que devem vê-los. Procure Vormetric Transparent Encryption ( http://www.vormetric.com/products/transparent-encryption )
A maneira como funcionaria é que ele fica entre o sistema de arquivos e os aplicativos que o acessam. O gerenciamento pode criar a política que diz "Apenas o usuário httpd, executando o daemon do servidor da web, pode ver os arquivos não criptografados". Em seguida, um administrador com suas credenciais de root pode tentar ler os arquivos e obter apenas a versão criptografada. Mas o servidor da Web e quaisquer ferramentas necessárias os veem sem criptografia. Ele pode até mesmo fazer a soma de verificação do binário para tornar mais difícil para o administrador contornar.
É claro que você deve ativar a auditoria para que, no caso de um administrador tentar acessar os arquivos, uma mensagem seja sinalizada e as pessoas saibam disso.
A única maneira prática é restringir quem pode fazer o quê com sudo. Você também poderia fazer a maior parte do que deseja com o selinux, mas provavelmente levaria uma eternidade para descobrir a configuração correta, o que pode torná-la impraticável.
Acordos de não divulgação. Contrate um administrador de sistema, eles têm que assinar um NDA, se quebrarem sua promessa, leve-os ao tribunal. Isso pode não impedi -los de roubar segredos, mas quaisquer danos que causem ao fazê-lo são recuperáveis no tribunal.
Administradores de sistemas militares e governamentais precisam obter autorizações de segurança de diferentes graus, dependendo da sensibilidade do material. A ideia é que alguém que pode obter uma liberação tem menos probabilidade de roubar ou trapacear.
Outra maneira de diminuir o risco (use ao lado dos mencionados antes, não em vez de) é pagar um bom dinheiro aos administradores de sistema. Pague-os tão bem que eles não querem roubar seu IP e deixá-lo.