Linux: sysadmins produtivos sem raiz (protegendo a propriedade intelectual)?

Question

Existe alguma maneira de tornar produtivo um syadmin Linux produtivo sem lhe dar acesso root completo?

Esta questão vem de uma perspectiva de proteger a propriedade intelectual (IP), que no meu caso, é inteiramente código e / ou arquivos de configuração (ou seja, pequenos arquivos digitais que são facilmente copiados). Nosso molho secreto nos fez mais sucesso do que o nosso tamanho pequeno sugeriria. Da mesma forma, somos uma vez mordidos, duas vezes tímidos por alguns ex-funcionários inescrupulosos (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 nos dar o risco de dar a uma pessoa mais acesso do que elas absolutamente precisam fazer o seu trabalho".

No 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 (os verdadeiros donos 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 do administrador do Linux. Fazemos uso extensivo de GPG para código e arquivos de texto sensíveis ... mas o que impede um administrador de (por exemplo) su'ing para um usuário e pular em sua sessão tmux ou GNU Screen e ver o que está fazendo? / p>

(Nós também temos acesso à Internet desabilitado em todos os lugares que poderiam entrar em contato com informações confidenciais. Mas, nada é perfeito, e poderia haver buracos abertos para administradores de sistemas inteligentes ou erros no lado do administrador de rede. Há, claro, inúmeras outras medidas em vigor, mas elas estão além do escopo desta questão.

O melhor que posso fazer é basicamente usar contas personalizadas com sudo , semelhante ao descrito em Vários sysadmins Linux funcionando como root . Especificamente: ninguém, exceto os proprietários da empresa, teria acesso direto à raiz. Outros administradores teriam uma conta personalizada e a capacidade de sudo para raiz. Além disso, o registro remoto seria instituído e os registros iriam para um servidor que somente os proprietários da empresa poderiam acessar. Ver o registro desativado acionaria algum tipo de alerta.

Um sysadmin inteligente provavelmente ainda pode encontrar alguns buracos nesse esquema. E isso de lado, ainda é reativo ao invés de proativo . O problema com o nosso IP é tal que os concorrentes poderiam utilizá-lo muito rapidamente e causar muitos danos em um curto espaço de tempo.

Então, ainda melhor seria um mecanismo que limitasse o que o administrador pode fazer. Mas reconheço que este é um equilíbrio delicado (particularmente à luz da solução de problemas e da 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 sensíveis gerenciam esse problema? Por exemplo, sysadmins 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 aparecer. Uma, supõe-se que esta seja uma questão técnica , e as práticas de contratação da IMO tendem mais para questões sociais . Mas, dois, direi o seguinte: acredito que fazemos tudo o que é razoável para contratar pessoas: entrevista com várias pessoas na empresa; verificação de antecedentes e referência; Todos os funcionários assinam vários documentos legais, incluindo um que diz que leu e compreendeu nosso manual, detalhando detalhadamente as preocupações com PI. Agora, está fora do escopo desta questão / site, mas se alguém puder propor práticas de contratação "perfeitas" que filtrem 100% dos maus atores, eu sou todo ouvidos. Os fatos são: (1) Eu não acredito que haja um processo de contratação tão perfeito; (2) as pessoas mudam - o anjo de hoje pode ser o diabo de amanhã; (3) tentativa de roubo de código parece ser um pouco rotineira nessa indústria.

    

Answer 1

O que você está falando é conhecido como o risco "Mal Sysadmin". O longo e curto dele é:

• Um sysadmin é alguém que tem privilégios elevados
• Tecnicamente adeptos, a um nível que os torne um bom 'hacker'.
• Interagindo com sistemas em cenários anômalos.

A combinação dessas coisas torna essencialmente impossível impedir ações mal-intencionadas. Até mesmo a auditoria se torna difícil, porque você não tem 'normal' para comparar. (E francamente - um sistema quebrado pode ter quebrado a auditoria também).

Existem várias etapas de mitigação:

• Separação de privilégios - você não pode impedir que um cara com raiz faça qualquer coisa no sistema. Mas você pode tornar uma equipe responsável pela rede e outra responsável pelos 'sistemas operacionais' (ou Unix / Windows separadamente).
• Limite o acesso físico ao kit a uma equipe diferente, que não recebe contas de administrador ... mas cuide de todo o trabalho das "mãos".
• Separe a responsabilidade "desktop" e "servidor". Configure a área de trabalho para inibir a remoção de dados. Os administradores de desktop não têm capacidade de acessar o sensível, os administradores do servidor podem roubá-lo, mas precisam saltar pelos obstáculos para sair do prédio.
• Auditoria para um sistema de acesso restrito - syslog e auditoria de nível de evento, para um sistema relativamente inviolável ao qual eles não têm acesso privilegiado. Mas coletar isso não é suficiente, você precisa monitorá-lo - e, francamente, há um monte de maneiras de "roubar" informações que podem não aparecer em um radar de auditoria. (Caçador contra caçadores)
• aplica a encriptação 'em repouso', pelo que os dados não são armazenados 'no claro' e requerem um sistema em direto para aceder. Isso significa que as pessoas com acesso físico não podem acessar um sistema que não está sendo monitorado ativamente e que, em um cenário "anômalo" em que um administrador de sistema está trabalhando, os dados ficam menos expostos. (por exemplo, se o banco de dados não estiver funcionando, os dados provavelmente não serão legíveis)
• Regra de dois homens - se você está bem com sua produtividade sendo aleijado e sua moral também. (Sério - já vi isso acontecer, e o estado persistente de trabalhar e ser observado torna as condições de trabalho extremamente difíceis).
• Verifique seus sysadmins - várias verificações de registros podem existir dependendo do país. (Criminal records check, você pode até achar que você pode solicitar uma habilitação de segurança em alguns casos, o que acionará a verificação)
• Cuide de seus administradores - a última coisa que você quer fazer é dizer a uma pessoa "confiável" que não confia neles. E você certamente não quer estragar o moral, porque isso aumenta a chance de comportamento malicioso (ou "não-muito-negligência, mas um deslize de vigilância"). Mas pague de acordo com a responsabilidade, assim como o conjunto de habilidades. E considere 'vantagens' - que são mais baratas que o salário, mas provavelmente valorizam mais. Como café grátis ou pizza uma vez por semana.
• e você também pode tentar aplicar condições de contrato para inibi-lo, mas tenha cuidado com o que precede.

Mas bem fundamentalmente - você precisa aceitar que isso é uma coisa de confiança, não uma coisa técnica. Seus sysadmins sempre serão potencialmente muito perigosos para você, como resultado desta tempestade perfeita.

    

Answer 2

Tudo dito até aqui é uma coisa boa, mas há uma maneira não-técnica 'fácil' que ajuda a negar um administrador de sistemas desonestos - o princípio dos quatro olhos que basicamente requer que dois sysadmins estejam presentes para qualquer acesso elevado.

EDITAR: Os dois maiores itens que eu vi nos comentários estão discutindo o custo e a possibilidade de conluio. Uma das maneiras mais importantes que considerei para evitar esses dois problemas é com o uso de uma empresa de serviços gerenciados usada apenas para verificação de ações tomadas. Feito corretamente, os técnicos não se conheceriam. Assumindo que a habilidade técnica que um MSP deveria ter seria fácil o suficiente para ter um sinal de ações tomadas ... talvez até tão simples quanto um sim / não para qualquer coisa nefasta.

    

Answer 3

Se as pessoas realmente precisarem de acesso de administrador a um sistema, não há muito o que fazer para restringir as atividades nessa caixa.

O que a maioria das organizações faz é confiança, mas verifica - você pode dar às pessoas acesso a partes do sistema, mas você usa contas de administrador nomeadas (por exemplo, você não dá acesso direto a < em> root ) e depois auditar suas atividades para um log que eles não podem interferir.

Há um ato de equilíbrio aqui; talvez seja necessário proteger seus sistemas, mas você também precisa confiar nas pessoas para fazer o trabalho delas. Se a empresa era "mordida" anteriormente por um funcionário inescrupuloso, isso poderia sugerir que as empresas que contratam práticas são pobres de alguma forma, e essas práticas foram presumivelmente criadas pelos "altos executivos". A confiança começa em casa; o que eles estão fazendo para corrigir suas escolhas de contratação?

    

Answer 4

Sem se colocar em uma reviravolta mental insana para tentar encontrar uma maneira de dar poder de sysadmin sem dar a eles poder (é provável que seja factível, mas acabaria sendo defeituoso 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 em que você está preocupado estão divididos e apenas as pessoas no topo têm o poder de vê-los. Esta é essencialmente sua resposta. Você deve ter vários administradores, e NENHUM deles deve ser um administrador em sistemas suficientes para montar a imagem completa. É claro que você precisaria de pelo menos 2 ou 3 admins para cada peça, no caso de um admin estar doente ou em um acidente de carro ou algo assim. Talvez até os desconcertem. digamos que você tenha 4 administradores e 8 informações. admin 1 pode acessar sistemas que possuem a parte 1 e 2, admin 2 pode chegar aos pedaços 2 e 3, admin 3 pode chegar a 3 e 4, e admin 4 pode chegar a 4 e 1. Cada sistema tem um administrador de backup, mas não admin é capaz de comprometer a imagem completa.

Uma técnica que os militares usam também é a limitação de dados em movimento. 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 uma aprovação documentada específica dos altos escalões antes que qualquer pessoa possa colocar quaisquer dados sobre qualquer coisa que possa levar ao derramamento de informações. Ao mesmo tempo, você garante que o tráfego de rede entre sistemas diferentes seja limitado por firewalls de hardware. Seus administradores de rede que controlam os firewalls não têm acesso aos sistemas que estão roteando, por isso não conseguem acessar especificamente as informações, e os administradores do servidor / estação de trabalho asseguram que todos os dados de e para um sistema estejam configurados para serem criptografados. que seus administradores de rede não podem tocar na rede e obter acesso aos dados.

Todos os laptops / estações de trabalho devem ter discos rígidos criptografados, e cada funcionário deve ter um armário pessoal para trancar as unidades / laptops no final da noite para garantir que ninguém chegue cedo e saia atrasado e ganhe acesso a algo que eles não deveriam.

Cada servidor deve, no mínimo, estar em seu próprio rack bloqueado, se não em seu próprio quarto bloqueado, de modo que apenas os administradores responsáveis por cada servidor tenham acesso a ele, já que no final do dia o acesso físico supera todos.

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 apenas um administrador por um período de tempo predeterminado (IE 6 meses, 1 ano, 2 anos) permitiria limitar o tempo que alguém teria para tentar juntar todas as partes do seu IP.

Meu design pessoal seria algo como ... 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.

Hardrives criptografados para todas as estações de trabalho que tocarão no IP. com um diretório de "projeto" específico na unidade, que é o único diretório no qual os usuários podem colocar seus projetos. No final de cada noite, eles precisam sanear seus diretórios de projeto com uma ferramenta de exclusão segura e, em seguida, são removidos. trancado (só para ficar seguro).

Cada bit do projeto tem um administrador diferente atribuído a ele, portanto, um usuário só interage com o administrador da estação de trabalho ao qual está atribuído, se a designação do projeto for alterada, se os dados forem apagados e se for designado 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 você quiser.

    

Answer 5

Seria semelhante ao desafio de contratar um zelador para um prédio. O zelador consegue ter todas as chaves, pode abrir qualquer porta, mas a razão é que o zelador precisa que eles façam o trabalho. O mesmo com os administradores do sistema. Simetricamente, pode-se pensar nesse problema antigo e observar como a confiança é concedida historicamente.

Embora não exista uma solução técnica simplificada, o fato de que não existe nenhum não deve ser uma razão pela qual não tentamos nenhuma, uma agregação de soluções imperfeitas pode dar resultados um pouco melhores.

Um modelo em que a confiança é obtida :

• Conceder menos permissões para começar com
• Aumentar gradualmente as permissões
• Coloque um honeypot e monitore o que acontece nos próximos dias
• Se o administrador de sistemas reportar isso em vez de tentar abusar dele, é um bom começo

Implementar vários níveis de poderes administrativos :

• Nível 1: pode modificar a camada inferior dos arquivos de configuração
• Nível 2: pode modificar uma camada ligeiramente superior de arquivos de configuração
• Nível 3: pode modificar uma camada um pouco mais alta de arquivos de configuração e configurações do sistema operacional

Sempre crie um ambiente em que o acesso total de uma pessoa não seja possível :

• Dividir sistemas em clusters
• Forneça poderes de administrador do cluster a grupos diferentes
• Mínimo de 2 grupos

Use a regra de dois homens ao fazer alterações essenciais de alto nível :

• link
• Requer um administrador do cluster1 e cluster2 para alterações principais

Confie e verifique :

• Registrar tudo
• Monitoramento e alerta de log
• Verifique se todas as ações são distinguíveis

Papelada :

• Peça-lhes que assinem uma papelada para que o sistema jurídico possa ajudá-lo, processando-o se o machucarem. Você dá mais incentivo para não fazê-lo

Answer 6

É muito difícil proteger os hosts contra aqueles com acesso administrativo. Embora ferramentas como PowerBroker tentem fazer isso, o custo é adicionar algo que pode quebrar AND adicionando barreiras às tentativas de corrigi-lo. A disponibilidade do seu sistema WILL diminui quando você implementa algo assim, então defina antecipadamente essa expectativa como o custo de proteger as coisas.

Outra possibilidade é ver 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 um substituto automaticamente. Isso exigirá bastante trabalho no lado do aplicativo para torná-los executados nesse modelo, mas ele pode resolver muitos problemas operacionais e de segurança. Se mal feito, pode criar alguns problemas de segurança significativos, para obter ajuda experiente, se você seguir esse caminho.

    

Answer 7

Esta é a sua discussão básica: link

Você divide sua responsabilidade por ter engenheiros de segurança cujo trabalho é fazer configurações e instalações do sistema, mas eles não obtêm credenciais ou acesso a máquinas na 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 quando eles recebem uma máquina quebrada retirada de serviço.

Faça uso de um sistema de autenticação centralizado com uma auditoria strong como Vault e faça uso de suas operações de criptografia. Distribua dispositivos Yubikey para tornar as chaves absolutamente privadas e ilegíveis.

As máquinas são apagadas ou manipuladas por operações e segurança em conjunto, e se você sentir necessidade de supervisão executiva.

    

Answer 8

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. Então, você precisará de uma maneira de criptografar os arquivos para que os administradores não possam vê-los, mas os arquivos ainda poderão ser usados pelas equipes que devem vê-los. Verifique a criptografia transparente da Vormetric ( link )

O modo 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 do httpd, executando o daemon do servidor da Web, pode ver os arquivos não criptografados". Em seguida, um administrador com suas credenciais raiz pode tentar ler os arquivos e obter apenas a versão criptografada. Mas o servidor da Web e as ferramentas necessárias precisam vê-los sem criptografia. Ele pode até mesmo verificar o binário para tornar mais difícil para o administrador se locomover.

É 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 sobre ela.

    

Answer 9

A única maneira prática é restringir quem pode fazer o quê com o sudo. Você poderia também fazer a maior parte do que você quer 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 sysadmin, eles têm que assinar um NDA, se eles quebrarem sua promessa, leve-os ao tribunal. Isso não pode impedir que eles roubem segredos, mas quaisquer danos que causem ao fazê-lo são recuperáveis no tribunal.

Os administradores de sistema 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 autorização é menos propenso a roubar ou trapacear.

    

Answer 10

Outra maneira de diminuir o risco (usar próximo aos mencionados antes, não em vez de) é pagar um bom dinheiro para seus administradores de sistema. Pague-os tão bem que eles não querem roubar o seu IP e deixar você.

    

Answer 11

Estou a pensar que esta questão pode não ser possível responder totalmente sem mais alguns detalhes, como:

Quantos sysadmins você espera manter "restrito"?

O que as pessoas precisam de acesso "sysadmin" para fazer?

Antes de mais nada, esteja ciente do que você pode fazer com o sudo. Com o sudo, você pode permitir que permissões elevadas executem apenas um único comando (ou variações, como comandos que começam com "mount -r", mas outros comandos não são permitidos). Com as chaves SSH, você pode atribuir credenciais que permitem que uma pessoa execute somente um determinado comando (como "sudo mount -r / dev / sdd0 / mídia / backup"). Portanto, há uma maneira relativamente fácil de permitir que praticamente qualquer pessoa (que tenha uma chave SSH) possa fazer algumas operações específicas sem deixá-las fazer absolutamente todo o resto.

As coisas ficam um pouco mais desafiadoras se você quiser que os técnicos realizem correções do que está quebrado. Isso normalmente requer uma quantidade maior de permissões e, talvez, acesso para executar uma ampla variedade de comandos e / ou gravar em vários arquivos.

Sugiro considerar a abordagem de sistemas baseados na Web, como o CPanel (que é usado por vários ISPs) ou sistemas baseados em nuvem. Muitas vezes, eles podem fazer com que os problemas de uma máquina desapareçam, fazendo com que a máquina inteira desapareça. Assim, uma pessoa pode executar um comando que substitui a máquina (ou restaura a máquina para uma imagem em boa situação), sem necessariamente dar à pessoa acesso para ler muitos dados ou fazer pequenas alterações (como combinar uma pequena correção com a introdução de uma porta traseira não autorizada). Então, você precisa confiar nas pessoas que fazem as imagens, mas você está reduzindo quantas pessoas precisa confiar para fazer as coisas menores.

Em última análise, porém, uma certa quantidade de confiança precisa ser fornecida a um número diferente de zero de pessoas que ajudam a projetar o sistema e que operam no nível mais alto.

Uma coisa que as grandes empresas fazem é confiar em coisas como servidores SQL, que armazenam dados que podem ser acessados remotamente por um número maior de máquinas. Então, um número maior de técnicos pode ter acesso root completo em algumas máquinas, sem ter acesso root aos servidores SQL.

Outra abordagem é ser grande demais para falhar. Não pense que grandes militares ou corporações gigantescas nunca têm incidentes de segurança. No entanto, eles sabem como:

• recuperar,
• limite o dano (separando coisas valiosas)
• têm contra-medidas, incluindo ameaças de litígio
• têm processos para ajudar a limitar a exposição indesejável à imprensa e têm planos de como influenciar o giro de quaisquer histórias negativas que se desenvolvam

A suposição básica é que o dano que ocorre é simplesmente um risco e custo de seus negócios. Eles esperam continuar a operar, e os desenvolvimentos e melhorias contínuos ao longo dos anos limitarão a quantidade de danos que um único incidente provavelmente afetará de fato em seu valor de longo prazo durante um período de tempo.

    

Answer 12

Fazer uma verificação proativa é muito difícil.

Soluções como O link (não trabalho para a Dell e outras soluções semelhantes estão disponíveis) é muito eficaz para impor a responsabilidade do sysadmin.

    

Answer 13

Coloque a máquina de administração raiz na sala trancada com duas chaves e dê apenas uma para cada um dos dois administradores. Os administradores sempre trabalharão juntos, observando as atividades uns dos outros. Deve ser a única máquina que contém a chave privada para efetuar login como root.

Algumas atividades podem não precisar de direitos de root, portanto, apenas parte do trabalho exigiria ir àquele ambiente para "programação em pares"

Você também pode gravar atividades em vídeo naquela sala principalmente para ter certeza de que ninguém trabalha sozinho (isso é facilmente visível). Além disso, certifique-se de que o local de trabalho seja de tal forma que a tela seja facilmente visível para ambas as pessoas (talvez uma tela de TV grande com as fontes grandes).