Segurança e Servidor Multiutilizador

Este capítulo reúne o que o OmniDB faz para proteger as credenciais guardadas e um servidor partilhado multiutilizador, e o que isso significa para si como administrador ou utilizador. Para instalar e expor o servidor, consulte Implementar o omnidb-server; para a gestão de palavras-passe pela linha de comandos, consulte Ferramenta de Configuração do OmniDB.

“Modo servidor”, a seguir, significa o omnidb-server iniciado sem -A — uma instância multiutilizador em que as pessoas iniciam sessão a partir de um browser, quer escute apenas em loopback, quer num endereço de rede (-H). A aplicação de ambiente de trabalho é sempre de utilizador único.

As palavras-passe guardadas são encriptadas

As palavras-passe de bases de dados guardadas numa ligação, as palavras-passe/frases-passe SSH e as chaves privadas SSH são encriptadas (AES-256-GCM) antes de serem escritas na base de dados de utilizador do OmniDB, omnidb.db. A chave de encriptação não é guardada nesse ficheiro: é mantida no armazenamento de segredos do sistema operativo — o Keychain do macOS, o Credential Manager do Windows ou o Secret Service do Linux —, pelo que uma cópia do omnidb.db sozinha não as revela.

Onde não houver nenhum armazenamento de segredos acessível (tipicamente, um servidor Linux sem interface gráfica), o OmniDB guarda a chave num ficheiro chamado .connection_secret_key (legível apenas pelo seu proprietário) na pasta pessoal do OmniDB; a partir do momento em que esse ficheiro existe, é sempre usado. Nesse caso:

• faça cópia de segurança do ficheiro de chave juntamente com o omnidb.db e proteja ambos da mesma forma;
• se a chave se perder, os segredos guardados não podem ser recuperados — as ligações continuam a existir, mas as suas palavras-passe e chaves SSH têm de ser introduzidas novamente.

As entradas não encriptadas existentes de versões anteriores são encriptadas automaticamente da primeira vez que uma versão mais recente arranca. Se preferir não guardar nenhuma palavra-passe, deixe-a vazia no formulário da ligação: o OmniDB pede-a quando for necessária e mantém-na apenas em memória, durante 30 minutos, para a sua sessão (consulte Criar Utilizadores e Ligações).

A conta admin inicial

Uma nova instalação em modo servidor cria um superutilizador, admin, com uma palavra-passe aleatória que é mostrada uma única vez na saída de registo do servidor:

omnidb-server: initialized a new app database — initial login: admin / <password> (shown only once; change it under Settings, or run: omnidb-server --set-password admin)

Inicie sessão com ela e altere-a em Definições > Palavra-passe, ou defina antecipadamente uma palavra-passe à sua escolha a partir da linha de comandos:

omnidb-server --set-password admin [-d /path/to/homedir]

A aplicação de ambiente de trabalho nunca mostra uma página de início de sessão; inicia sessão automaticamente no seu próprio servidor local, acessível apenas em loopback.

Proteção do início de sessão e sessões

• Após 10 tentativas de início de sessão falhadas para o mesmo nome de utilizador, ou a partir do mesmo endereço de cliente, num período de 15 minutos, as tentativas seguintes são recusadas com Demasiadas tentativas de início de sessão falhadas. Tente novamente dentro de 15 minutos. Os contadores são mantidos em memória e repostos quando o servidor reinicia. Atrás de um proxy inverso, o endereço do cliente é o endereço do proxy.
• Eliminar um utilizador termina de imediato todas as sessões desse utilizador, e retirar o estatuto de superutilizador tem efeito imediato. Alterar uma palavra-passe (nas Definições ou com --set-password) aplica-se de imediato aos novos inícios de sessão; uma palavra-passe alterada nas Definições também termina as outras sessões desse utilizador.

Restrições no modo servidor

Como todas as ligações de um servidor multiutilizador são abertas pelo processo do servidor, na máquina do servidor, algumas opções de ligação que leriam ficheiros do próprio servidor estão restringidas:

• As ligações SQLite (uma base de dados SQLite é um ficheiro no servidor) só podem ser criadas e usadas por superutilizadores do OmniDB. Não podem apontar para dentro da própria pasta pessoal do OmniDB, e os URIs file: são rejeitados.
• As cadeias de ligação do PostgreSQL não podem usar os parâmetros passfile, servicefile, service, sslkey, sslcert, sslrootcert, sslcrl ou sslcrldir.

Estas restrições não se aplicam à aplicação de ambiente de trabalho, onde os ficheiros são seus.

Ligações públicas

Uma ligação marcada como Ligação pública? pode ser usada por todos os utilizadores do OmniDB no servidor, mas só o seu proprietário a pode editar. Para todos os outros:

• a palavra-passe guardada nunca é enviada para o browser deles, e uma palavra-passe incluída na cadeia de ligação é mostrada mascarada;
• Testar ligação testa sempre o servidor, a porta e a base de dados guardados — alterar primeiro esses campos no formulário não redireciona a palavra-passe guardada para outro lado.

Ficheiros exportados

As exportações de consultas e as exportações DBML são escritas na pasta temp do servidor com nomes aleatórios e só podem ser transferidas pelo utilizador que as criou. São eliminadas automaticamente ao fim de 24 horas.

Chaves de anfitrião SSH

Os túneis SSH e as ligações de terminal SSH verificam a chave de anfitrião do servidor em relação ao ficheiro ~/.ssh/known_hosts do utilizador do sistema operativo que executa o omnidb-server. Uma chave de anfitrião desconhecida ou alterada é recusada — o OmniDB não confia silenciosamente num anfitrião na primeira utilização. Adicione o anfitrião uma vez a partir dessa conta, por exemplo:

ssh [email protected]        # accept the key once
# or
ssh-keyscan ssh-server.example.com >> ~/.ssh/known_hosts

Exposição à rede

Não existe TLS incorporado. Mantenha o omnidb-server em 127.0.0.1 (a predefinição) atrás de um proxy inverso com terminação TLS, em vez de expor HTTP simples com -H 0.0.0.0 — consulte Implementar o omnidb-server. Enquanto estiver vinculado a loopback, o servidor só responde a pedidos dirigidos a 127.0.0.1, localhost ou [::1] com a sua própria porta, o que o protege contra ataques de DNS rebinding a partir de páginas web. Os cookies de sessão são marcados como Secure quando o pedido chega por TLS ou com X-Forwarded-Proto: https, e todos os pedidos que alteram o estado estão protegidos contra falsificação de pedidos entre sites (CSRF).