Segurança e Arquitetura
Os mecanismos e controles de segurança do Accelero — da autenticação de operadores ao motor de controle de acesso físico — sob a ótica de cyber security e arquitetura da solução.
O Accelero é uma plataforma de controle de acesso físico que administra a entrada e a saída de pessoas e veículos em catracas, portas, cancelas e elevadores. Por operar na fronteira física da segurança de uma organização, a plataforma trata segurança em profundidade: cada requisição atravessa múltiplas camadas independentes de verificação, e cada decisão de acesso é registrada de forma rastreável.
Princípios de segurança adotados
| Princípio | Como se materializa no Accelero |
|---|---|
| Defesa em camadas | Perímetro (TLS), autenticação, autorização por perfil, isolamento por empresa e o motor de regras de acesso são camadas independentes — falhar uma não expõe as demais. |
| Menor privilégio | Operadores só enxergam menus, ações e dados das empresas a que foram vinculados; dispositivos de campo só acessam os tópicos de comunicação que lhes pertencem. |
| Rastreabilidade total | Operações de cadastro, logins e cada passagem no controle de acesso geram registros persistentes, com autor, data/hora e motivo. |
| Criptografia de dados sensíveis | Senhas com hash irreversível (bcrypt), fotos cifradas em repouso e QR Codes de acesso criptografados. |
| Segurança por padrão | Prepared statements no acesso ao banco, cookies de sessão endurecidos e sanitização de uploads são o comportamento nativo, não uma opção. |
Arquitetura de segurança em camadas
Uma requisição para liberar um acesso — ou uma ação de um operador no sistema — só é atendida após passar, em sequência, por todas as camadas de controle. Cada camada tem uma responsabilidade única e pode negar a operação isoladamente.
| Camada | Papel |
|---|---|
| Perímetro | Nginx com TLS/HTTP2; comunicação com dispositivos via broker MQTT dedicado. Serviços isolados em contêineres com rede interna. |
| Autenticação | Verifica quem está fazendo a requisição — operador (sessão), integração (chave/assinatura) ou dispositivo (credencial de broker). |
| Autorização (RBAC) | Decide o que aquele operador pode fazer, com base em perfis e permissões. |
| Isolamento multiempresa | Garante que o operador só acesse dados das empresas a que pertence. |
| Motor de acesso físico | Aplica as regras de negócio de segurança física (área, horário, anti-passback, escolta, lotação, etc.). |
| Auditoria | Persiste o resultado — inclusive o motivo de uma negação — para investigação posterior. |
Autenticação e identidade
O login de operadores combina hash de senha padrão de mercado, política de complexidade e uma série de verificações contextuais que vão além de "usuário e senha".
// Senha do operador — hash irreversível com bcrypt
password_hash($senha, PASSWORD_BCRYPT, ['cost' => 10]);
password_verify($senhaDigitada, $hashArmazenado); // comparação em tempo constante
// Política de complexidade exigida
// ≥ 8 caracteres · letra maiúscula · letra minúscula · número · caractere especial
| Controle | O que faz |
|---|---|
| Hash bcrypt | Senhas nunca são armazenadas em texto; o hash é irreversível e resistente a força bruta. A criptografia acontece automaticamente ao salvar. |
| Complexidade obrigatória | Exige maiúscula, minúscula, número, caractere especial e mínimo de 8 caracteres. |
| Expiração e troca forçada | Senhas podem exigir troca no próximo login (senha nova ou vencida), com bloqueio de reutilização da senha atual. |
| Revalidação periódica | Em intervalo configurável, o operador precisa revalidar o acesso por um link com token aleatório enviado por e-mail, consumido no uso. |
| Proteção anti-força-bruta | Cada tentativa de senha incorreta impõe um atraso progressivo no servidor, tornando a adivinhação em massa inviável. |
| Restrição por dispositivo | Opcionalmente, a conta pode ser amarrada a um dispositivo específico (device lock). |
| Restrição por horário | O login pode ser limitado a dias da semana e faixas de horário permitidos. |
| Presença física | Opcionalmente, um operador só consegue logar se estiver fisicamente presente em uma área autorizada — impedindo o compartilhamento remoto de credenciais. |
Toda tentativa de login com senha incorreta gera uma ocorrência registrando o IP de origem, permitindo identificar padrões de ataque.
A plataforma já traz a base para autenticação federada via OAuth2 / Azure AD (Microsoft Entra ID), permitindo integrar o login ao provedor de identidade corporativo do cliente.
A configuração da conta de operador, perfis de acesso e o fluxo de primeiro login estão detalhados em Operadores e Primeiro Login.
Controle de sessão
Após o login, a sessão do operador é protegida contra roubo, fixação e uso concorrente indevido.
| Controle | O que faz |
|---|---|
| Regeneração de ID | O identificador da sessão é regenerado ao iniciar, mitigando ataques de fixação de sessão. |
| Cookie endurecido | Cookies de sessão com HttpOnly (inacessíveis a JavaScript), strict mode e identificador de 32 caracteres. |
| Timeout por inatividade | Sessões inativas expiram após um período configurável. |
| Sessão única por usuário | Módulo que impede que a mesma conta esteja ativa em dois lugares ao mesmo tempo — um novo login derruba o anterior. |
| Limite de sessões simultâneas | O número de operadores conectados ao mesmo tempo é controlado pela licença, com alocação de vagas por empresa. |
Autorização e perfis (RBAC)
O acesso às funções do sistema é governado por um modelo de papéis e permissões (RBAC): operadores recebem um ou mais perfis, e cada perfil concede um conjunto de permissões.
| Controle | O que faz |
|---|---|
| Perfis e permissões | Estrutura Operador → Perfil → Permissão, com resultado cacheado para desempenho. |
| Menu por permissão | Os itens de menu exibidos são filtrados pelas permissões do operador — ele não vê o que não pode acessar. |
| Verificação por ação | Cada ação sensível verifica a permissão correspondente no ponto de entrada; a falha lança uma exceção de "sem permissão". |
| Rotas protegidas | Rotas administrativas passam por um middleware que exige sessão autenticada. |
| Console de banco restrito | A ferramenta de acesso direto ao banco é liberada exclusivamente ao usuário administrador raiz; qualquer outro recebe 404. |
| Entitlement por licença | Módulos e limites de cadastro são habilitados conforme a licença (criptografada) do cliente. |
A definição de papéis e permissões é feita nas entidades Perfis e Operadores.
Isolamento multiempresa
O Accelero é multiempresa: uma mesma instalação atende várias empresas/condomínios. Os dados de cada uma ficam segregados, e um operador só acessa aquilo que pertence às empresas a que está vinculado.
Cada operador tem uma lista de empresas autorizadas. Consultas de pessoas, colaboradores, visitantes e eventos são automaticamente filtradas por essa lista — o dado de outra empresa nunca entra no resultado, mesmo que o operador tente forçar um identificador.
| Elemento | Função |
|---|---|
| Vínculo operador–empresa | Define, por operador, o conjunto de empresas visíveis. |
| Filtro em nível de consulta | As listagens aplicam a restrição de empresa diretamente na consulta ao banco. |
| Vínculo pessoa–empresa | Pessoas pertencem a empresas; o acesso do operador respeita esse vínculo. |
O cadastro e agrupamento de empresas está em Empresas.
Motor de controle de acesso físico
O coração do Accelero é um motor de regras de verificação modulares. A cada apresentação de credencial (cartão, biometria, QR, placa), a decisão de liberar ou não passa por mais de 30 regras independentes. Basta uma reprovar para o acesso ser negado — e a decisão sempre carrega o motivo.
Regras de identidade e credencial
| Regra | Verifica |
|---|---|
| Cartão / pessoa existe | A credencial está vinculada a uma pessoa cadastrada. |
| Cartão habilitado e válido | O cartão está ativo e dentro da janela de validade. |
| Pessoa habilitada | O cadastro da pessoa está ativo. |
| Categoria ativa / data de cadastro | A categoria (perfil de acesso) está válida e a inscrição, dentro do prazo. |
| Blacklist | Categorias marcadas para bloqueio permanente barram o acesso imediatamente. |
Regras de área e tempo
| Regra | Verifica |
|---|---|
| Área permitida | A pessoa tem permissão para a área de destino do dispositivo. |
| Horário de funcionamento | A área está operante no momento. |
| Faixa horária | Dia da semana, faixa de horário, feriados e janelas ad-hoc de eventos autorizam a passagem. |
| Área de origem | Fluxos direcionais exigem estar na área de origem para transitar. |
| Timeouts de reentrada | Impede reentradas em intervalo menor que o configurado. |
Regras avançadas de segurança
| Regra | Verifica |
|---|---|
| Anti-passback | Impede dupla entrada e carona (tailgating) — inclusive para veículos. |
| Escolta / acompanhante | Exige que certos perfis passem acompanhados de um escolta autorizado; valida escolta por categoria ou ad-hoc, previne autoescolta e trata escolta de veículos. |
| Dupla custódia | Áreas críticas podem exigir a presença simultânea de dois autorizados. |
| Controle de lotação | Limita a ocupação por área e por empresa dentro da área. |
| Controle de jornada | Limita o tempo máximo de permanência contínua na instalação. |
| Grants / liberações | Áreas podem exigir certificações/clearances, com lógica positiva (deve ter) e negativa (não pode ter) e validade temporal. |
| Créditos / cota | Áreas podem debitar créditos, bloqueando quando o saldo é insuficiente. |
| Câmara fria | Limita o tempo de permanência em áreas refrigeradas. |
| Estado do dispositivo | Respeita modo de bloqueio/emergência do controlador. |
| Visitante / evento | Valida status de autorização, finalização e política de reentrada de visitantes. |
Quando uma pessoa sinaliza coação (ex.: uma senha especial sob ameaça), o Accelero gera uma ocorrência de coação com pessoa, cartão e controlador envolvidos e dispara uma notificação — permitindo resposta silenciosa a uma situação de risco.
Cada recusa retorna um código de motivo específico — anti-passback, fora da faixa horária, área não permitida, lotação excedida, sem grant, controle de jornada, blacklist, entre outros — registrado para investigação.
Cada uma dessas regras tem página própria na referência: Política de Acesso, Escolta, Dupla Custódia, Controle de Jornadas, Créditos, Passes e Câmara Fria.
Proteção de dados e privacidade (LGPD)
A plataforma lida com dados pessoais e imagens. Os mecanismos abaixo protegem esses dados em repouso, em trânsito e ao longo do seu ciclo de vida.
| Controle | O que faz |
|---|---|
| Foto em repouso | As fotos das pessoas são cifradas (AES) ao gravar e decifradas apenas na leitura. |
| Foto servida com autorização | As imagens só são entregues a operadores autenticados: exigem sessão válida e passam por uma verificação de autorização no Nginx (auth request) antes de serem servidas. |
| Sanitização de upload | Toda imagem enviada é reprocessada em JPEG, removendo qualquer código malicioso embutido; arquivos ficam fora da raiz web. |
| QR Code de acesso | QR Codes de acesso e convite carregam dados criptografados com nonce aleatório — não podem ser forjados sem a chave e são validados contra a base. |
| Senha irreversível | Senhas de operador em bcrypt: mesmo com acesso ao banco, não são recuperáveis. |
| Retenção e expurgo | Rotinas automáticas removem, por tempo/inatividade, logs, eventos, relatórios, fotos e cadastros inativos — base para políticas de retenção da LGPD. |
| Remoção de biometria | Templates biométricos podem ser removidos da pessoa e dos dispositivos. |
Os aspectos de conformidade legal (direitos dos titulares, responsabilidades controlador/operador, incidentes) estão em LGPD e Segurança.
Auditoria e rastreabilidade
O Accelero mantém trilhas distintas para operações administrativas e para eventos físicos de acesso, permitindo reconstruir "quem fez o quê, quando e com qual resultado".
| Trilha | O que registra |
|---|---|
| Log de operações | Criação, alteração, exclusão, logins e ações administrativas — com autor, data/hora, objeto afetado e detalhes. |
| Log de eventos de acesso | Cada passagem física: dispositivo/porta, área, pessoa, cartão, tipo de evento e se foi online ou offline. |
| Controle de login | Registro das sessões por operador. |
| Ocorrências de segurança | Eventos sensíveis, como coação e tentativas de senha incorreta (com IP). |
| Log de aplicação | Registro operacional estruturado (formato JSON) com rotação de arquivos. |
A consulta operacional dessas trilhas está em Eventos, Livro de Ocorrências e Painel de Ocorrências.
Comunicação e integrações
A comunicação com o navegador do operador, com os dispositivos de campo e com sistemas de terceiros é autenticada e, quando trafega em redes não confiáveis, cifrada.
Dispositivos de campo (MQTT)
Os controladores de acesso conversam com o Accelero por um broker MQTT. Em produção, cada dispositivo possui credencial própria (hash no banco) e uma ACL que restringe os tópicos que ele pode publicar ou assinar — um dispositivo não consegue interferir na comunicação de outro.
API e integrações
# Autenticação da API por assinatura — o segredo nunca trafega na rede
GET /api.php
Authorization: {chave_publica}/{timestamp}/{nonce}/{assinatura}
# assinatura = hash(timestamp + nonce + segredo)
# o timestamp precisa estar dentro de uma janela curta (anti-replay)
| Canal | Autenticação |
|---|---|
| Web / operador | TLS/HTTP2 no Nginx; sessão autenticada por cookie endurecido. |
| API pública | Chave pública + segredo + nonce + timestamp assinados; o segredo nunca é transmitido. |
| Integrações externas | Middlewares de autenticação por integração (ex.: Bearer token), com comparação em tempo constante nas integrações mais recentes. |
| Dispositivos MQTT | Credencial por dispositivo + ACL de tópico; porta TLS disponível. |
| Câmeras / hardware | Autenticação nas chamadas aos equipamentos (ex.: digest auth). |
| Bot Telegram | Validação de token pela biblioteca oficial e limitador de requisições habilitado. |
A API do Accelero é de acesso restrito (mediante contrato/NDA), não pública. Consulte a equipe comercial para habilitação.
Segurança de aplicação e infraestrutura
| Controle | O que faz |
|---|---|
| Proteção contra SQL Injection | O acesso ao banco usa prepared statements com vinculação de parâmetros por padrão, separando código de dados. |
| Erros sem vazamento | Exceções são tratadas e traduzidas em mensagens genéricas ao usuário — sem expor stack trace ou detalhes internos. |
| Uploads sanitizados | Imagens são reprocessadas e armazenadas fora da raiz web, em diretório não executável. |
| Sessão endurecida | Cookies HttpOnly, strict mode e regeneração de identificador. |
| Isolamento de serviços | Arquitetura multicontêiner (aplicação, banco, cache, broker, serviços auxiliares) com rede interna segregada. |
| Console administrativo restrito | Ferramentas de baixo nível (acesso direto ao banco) limitadas ao administrador raiz. |
PHP 8.1+ com tipagem estrita, arquitetura PSR com injeção de dependência, ORM próprio sobre PDO/mysqli, e orquestração via Docker Compose (Nginx, PHP-FPM, banco MySQL/MariaDB, cache Redis/Valkey e broker Mosquitto MQTT).
Perguntas frequentes
Como as senhas dos operadores são armazenadas? Com hash bcrypt, irreversível. Nem os administradores conseguem recuperar a senha original a partir do banco de dados.
O sistema protege contra tentativas de adivinhação de senha? Sim. Cada tentativa incorreta impõe um atraso progressivo no servidor e gera uma ocorrência registrando o IP de origem.
É possível integrar o login ao Active Directory / Microsoft Entra ID? A plataforma já traz a base para autenticação federada via OAuth2/Azure AD, permitindo integrar ao provedor de identidade corporativo.
Um operador consegue ver dados de outra empresa? Não. Cada operador é vinculado a um conjunto de empresas, e as consultas são filtradas automaticamente por esse conjunto, mesmo diante de tentativas de forçar identificadores.
Por que uma passagem foi negada? Toda negação retorna um motivo específico (fora da faixa horária, anti-passback, área não permitida, lotação, sem grant, controle de jornada, blacklist, etc.), registrado na auditoria.
O que acontece em uma situação de coação? A sinalização de coação gera uma ocorrência específica e dispara notificações, permitindo resposta silenciosa a uma ameaça.
As fotos e QR Codes ficam protegidos? As fotos são cifradas em repouso e só servidas a operadores autenticados; os QR Codes de acesso são criptografados com nonce, não podendo ser forjados.
Como os dispositivos de campo são autenticados? Por credencial individual no broker MQTT, com ACL restringindo os tópicos de cada dispositivo. Um controlador não acessa a comunicação de outro.
O acesso é auditável para fins de compliance? Sim. Operações administrativas, logins e cada passagem física ficam registrados com autor, data/hora e resultado, em trilhas persistentes.
Próximos Passos
- LGPD e Segurança — Conformidade legal e retenção de dados
- Normas e Protocolos — Padrões técnicos suportados