Proteção pensada para dados clínicos

O acesso à área autenticada exige identidade válida. Credenciais e sessões são tratadas com medidas padrão de proteção no servidor.

• Login com e-mail e senha; a senha é armazenada apenas como hash, nunca em texto puro.
• Opção de entrar com Google (OAuth), com verificação do fluxo de autorização.
• Sessões em cookie HttpOnly, com renovação controlada e encerramento no logout.
• Fluxos de verificação de e-mail e de recuperação de senha com links de uso limitado.

Dentro da clínica, cada pessoa enxerga e executa apenas o que o seu papel permite.

• Papéis definidos: Owner, Admin, Dentista, Recepcionista e Auxiliar.
• Permissões aplicadas nas ações do sistema — não apenas escondidas na interface.
• O Owner define quem entra na organização e com qual nível de acesso.
• Mudanças relevantes podem ser registradas em logs de auditoria sanitizados.

Cada clínica opera no próprio contexto. Usuários de uma organização não acessam dados de outra.

• Arquitetura multi-tenant com isolamento por organização.
• Consultas e ações autenticadas vinculam o acesso à organização da sessão.
• Arquivos clínicos ficam em armazenamento privado, com acesso temporário e controlado.
• Essa separação é um pilar estrutural do produto, não um ajuste cosmético.

Cópias de segurança do banco fazem parte da operação, com proteção em trânsito para o destino de armazenamento.

• Backups do banco gerados de forma criptografada antes do envio ao armazenamento de retenção.
• Rotina operacional com retenção diária, semanal e mensal em produção.
• Objetivos de recuperação definidos na operação para continuidade do serviço.
• Exclusões feitas na clínica seguem a política de retenção das cópias até a rotação natural.

Acompanhamos erros e eventos relevantes para manter a plataforma estável e investigar incidentes com responsabilidade.

• Observabilidade de erros em produção, com filtros para evitar envio de senha, token e dados sensíveis óbvios.
• Registros de auditoria com metadados sanitizados — sem replicar conteúdo clínico desnecessário.
• Analytics próprio da operação, sem depender de suites publicitárias de terceiros.
• Sinais operacionais usados para estabilizar o serviço e apoiar a investigação responsável de incidentes.

A aplicação roda em hospedagem gerenciada, com camadas básicas de endurecimento HTTP e segredos fora do código.

• Hospedagem e banco em provedor de infraestrutura dedicado à operação da plataforma.
• Cabeçalhos HTTP de endurecimento (por exemplo, bloqueio de iframe e política de referrer).
• Segredos e chaves de integração via variáveis de ambiente no servidor — não no cliente.
• Pagamentos de assinatura processados por prestador de cobrança; a plataforma não armazena dados de cartão.

Processos e hábitos de engenharia da fábrica 2DevsLab reduzem a superfície de risco no dia a dia do Cliniq.

• Desenvolvimento e sustentação contínua realizados pela equipe de engenharia da 2DevsLab.
• Privacidade por desenho: mínimo necessário, papéis claros de controlador (clínica) e operadora (plataforma).
• Testes contínuos de isolamento multi-tenant entre organizações e revisão rigorosa de permissões.
• Dependências e integrações limitadas estritamente ao que a operação técnica realmente precisa.
• Canal de privacidade para titulares e dúvidas sobre tratamento de dados pessoais.