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.