Como posso evitar que um administrador de servidor possa ver dados?

Question

Estou executando o Apache Tomcat em um servidor Windows 2003 e tenho dados armazenados em um banco de dados mySQL.

Como posso evitar que um administrador de servidor veja dados?

    

Answer 1

Você não pode, na verdade.

O usuário "Administrador" em uma máquina Windows possui controle total da máquina. Isso é "como é".

Alguém provavelmente sugerirá que você criptografe os dados no banco de dados. Supondo que as chaves para essa criptografia estejam localizadas em algum lugar desse computador (já que o aplicativo não terá acesso a elas), o "Administrador" pode simplesmente pegar essa chave e descriptografar os dados.

Alguém sugerirá que você use algum tipo de permissão de arquivo. Isso também não funcionará-- o "Administrador" pode apenas mudá-las.

Se você não puder dar ao seu usuário "Administrador" uma conta limitada com a qual ele possa realizar todas as atividades do dia-a-dia, mas caso contrário não seja um "Administrador", a única resposta é "não armazene esse tipo de dados lá ". Qualquer "resposta" que envolva o usuário "Administrador" mantendo seus direitos "Administrador" não lhe dará nenhuma proteção real.

Uma edição para o bem de JimB:

JimB deixou alguns comentários que eu acho que merecem uma resposta mais longa do que eu posso dar em um comentário, então estou lançando uma edição aqui.

Respondi à pergunta do pôster com precisão técnica em relação aos privilégios concedidos ao grupo "Administradores" do Windows. O autor do pôster certamente está livre para gastar todo o tempo que ele quiser "ajustando" as permissões de segurança padrão no sistema operacional para tentar (a) remover o grupo "Administradores" dos privilégios equivalentes a raiz (que, eu esperaria, Microsoft diria a você para não fazer) ou (b) criar um grupo com menos privilégios que poderia executar todas as funções de administração do servidor diárias necessárias, mas de outra forma não seria um "Administrador".

A menos que as necessidades do "administrador do servidor" do cartaz sejam muito básicas, eu diria que o cartaz vai acabar entrando em território desconhecido e não documentado.

Talvez o cartaz precise de um "administrador do servidor" que possa executar apenas operações básicas no computador servidor, e a senha do "Administrador" pode ser definida como uma string arbitrariamente complexa e armazenada em um cofre bloqueado. Essa é uma estratégia possível, se os requisitos de negócios do pôster são: um "administrador de servidor" permite tal coisa.

Se os requisitos do pôster forem mais complexos, esperaria que um LOT de ACLs (no sistema de arquivos, registro, gerenciador de objetos global e gerenciador de controle de serviço, pelo menos) precisassem ser alterados acomodar um membro não pertencente ao grupo "Administradores" com uma grande aproximação das habilidades de um membro do grupo "Administradores". O pôster também perderia a utilidade do bem conhecido BUILTIN \ Administrators SID também.

Eu ficaria chocado se não houver algumas suposições sendo executadas no sistema operacional Windows NT sobre os privilégios prontos para uso atribuídos aos membros do grupo "Administradores". A tentativa de tirar privilégios do grupo BUILTIN \ Administrators é, a meu ver, pedindo instabilidade e problemas com o SO.

Eu não fiz nenhuma declaração sobre a "política de negócios" reforçando a segurança. Eu não sei o que JimB saiu do meu post ou comentários que lhe deram essa ideia. A política de negócios não pode alterar a maneira como o código funciona, e todas as minhas declarações estão relacionadas a como o código funciona.

A auditoria de que uma violação ocorreu não atenua a violação. Você pode saber que alguém violou a confidencialidade, mas nenhum mecanismo de auditoria pode informar quantas cópias dos bits confidenciais foram feitas depois que a confidencialidade foi violada. É booleano - ou a confidencialidade foi violada ou não. A auditoria pode dizer isso e nada mais.

Uma empresa pode tentar "reforçar a segurança" em toda a "política de negócios" que gostaria, mas a menos que essa "política de negócios" seja coerente com a forma como o código e a realidade operam, é muito sem sentido.

    

Answer 2

O acima, mas gostaria de acrescentar que um administrador antiético não vale nada. Se você não confia em seu administrador de sistema para não espiar (exceto quando necessário para completar suas tarefas), então você realmente precisa encontrar um substituto.

    

Answer 3

Em geral, você pode fazer com que as contas administrativas não possam fazer as coisas, mas os administradores geralmente podem ativá-las para que possam.

Por exemplo, você pode negar o acesso de leitura a um diretório para o Administrador do usuário, mas o administrador pode se dar acesso novamente se quiser.

Então, com isso, acho que você pode (mas não tenho certeza), apenas negar acesso de leitura aos bancos de dados editando os privilégios do MySQL para o usuário root no banco de dados MySQL. Mas isso não é segurança real. Ou, você não pode dar ao administrador qualquer uma das senhas do MySQL, mas elas provavelmente encontrarão uma maneira de visualizar os dados se tiverem acesso ao servidor (ou até mesmo redefinir a senha do root).

    

Answer 4

Os pontos levantados por Evan são uma das razões pelas quais os administradores de sistemas obtêm verificações de antecedentes tão pesadas no meu trabalho. Em última análise, todos têm que confiar em seus dados para nós, e cada um tem seus próprios requisitos para "confiança". Em alguns sistemas, é possível bloquear o sysadmin, mas o Windows não é um sistema desse tipo.

Há algumas coisas que você pode fazer no nível aplicativo para ofuscar seus dados de administradores de sistemas intrometidos, como usar tabelas com dados criptografados neles. Isso depende de ter as chaves de criptografia e os dados em diferentes domínios sysadmin embora, caso contrário, não há muito sentido. Um exemplo disso seria um aplicativo Tomcat / PHP em execução em um servidor Linux e, com a idade dos sysadmins do Linux, com o banco de dados em MS-SQL, sob a idade dos sysadmins da Microsoft. Presumindo que os administradores do Linux / MS não conspiram, é menos provável que os dados sejam rastreados.

    

Answer 5

Você pode negar ao administrador o acesso a qualquer coisa que desejar. Administrador simplesmente tem, por padrão, direitos sobre praticamente tudo. O que você não pode remover (pelo menos eu nunca fiz isso - pode, na verdade, ser possível, mas eu não recomendaria) é a capacidade do administrador de se apropriar dos arquivos em questão e lê-los - no entanto, isso é verdade. auditável e irreversível - não há poder de propriedade de concessão.

administrador é uma conta especial, mas não é equivalente a root em uma caixa unix. Isso é tão errado equívoco.

Você também pode usar o em um mês ou mais quando 2008 R2 sair.

    

Answer 6

A maioria dos sistemas operacionais comuns (Linux, Windows, Mac OS X) não pode fazer isso diretamente. Há sempre uma conta que pode fazer tudo no sistema (administrador ou raiz) e essa conta é necessária para muitas tarefas administrativas. De jeito nenhum, realmente.

Para tornar isso possível, você precisa de algo como um sistema operacional seguro de vários níveis ou um que suporte < a href="http://en.wikipedia.org/wiki/Mandatory_access_control"> Controles de acesso obrigatórios . Algo como SELinux, ou Trusted Solaris, ou Controle obrigatório de integridade no Windows Vista.

Ainda assim, isso é muito complexo para configurar e pode causar problemas de compatibilidade com aplicativos que não foram escritos tendo em mente as restrições. E, finalmente, alguém ainda terá que ter acesso para alterar as configurações de segurança.

Portanto, embora seja tecnicamente possível, você deve avaliar cuidadosamente se vale a pena as complicações e despesas extras.

    

Answer 7

Acesse a folha de pagamento de estações de trabalho designadas às quais o administrador em particular não tem direitos nem acesso físico.

Criptografar / descriptografar o lado cliente de dados para que, ao chegar / sair do servidor, ele sempre seja criptografado. É somente descriptografado no final do cliente e somente quando o usuário fornece a senha ou chaves adequadas.

Construa um programa cliente que criptografe os dados antes de enviá-los ou copie o código de o projeto de gerenciamento de senha OpenSource ClipperZ . O ClipperZ usa o javascript para fazer essa criptografia no navegador. Escusado será dizer, use apenas um webbrowser sandboxed bloqueado muito selinux com um perfil firefox especificamente configurado apenas para folha de pagamento. Não e-mail. Nada mais.

Você pode até considerar ainda ter o servidor criptografado para mitigar alguns formulários de rootkits do lado do cliente - especialmente um man-in-the-browser.