Segurança de acesso para corte em camadas Ipiranga salão de beleza feminino São Paulo: controle de dados

Imagine a seguinte situação: é sexta-feira à tarde no Ipiranga, o salão está lotado para corte em camadas e a recepcionista precisa puxar o histórico de coloração de uma cliente frequente. O sistema trava, ela pede a senha do gerente “só para ver rapidinho” e, sem querer, exporta a lista completa de clientes com telefones e CPFs para um grupo de WhatsApp. Em minutos, dados sensíveis de centenas de mulheres estão expostos. Cenários como este não são ficção — são falhas reais de controle de acesso que colocam salões de beleza em risco jurídico (LGPD) e reputacional.

A segurança de acesso em bancos MySQL para salões não é um luxo de grandes corporações; é requisito básico para qualquer negócio que guarde nome, telefone, CPF, histórico de serviços, preferências de produtos e dados de pagamento. O artigo mostra como estruturar roles, privilégios, criptografia, auditoria e backup de forma prática, sem jargão excessivo, para que donos e gestores de salões em São Paulo — do Ipiranga a Perdizes — possam dormir tranquilos sabendo que os dados das clientes estão protegidos.

Mapeamento de roles e princípio do menor privilégio

O primeiro passo é listar quem acessa o banco e para quê. Em um salão típico existem pelo menos cinco perfis: recepcionista (agenda, cadastro básico), cabeleireiro (próprios agendamentos, ficha técnica do cabelo), gerente (relatórios de faturamento, estoque, equipe), dono (visão completa, decisões estratégicas) e suporte/desenvolvedor (manutenção, deploy). Cada perfil deve ter um usuário de banco dedicado — nada de “usuario_salao” compartilhado.

Com o mapeamento em mãos, aplique GRANT cirúrgico. Exemplo: GRANT SELECT, INSERT, UPDATE ON salao.agendamentos TO 'cabeleireiro_joao'@'%'; e GRANT SELECT ON salao.ficha_tecnica TO 'cabeleireiro_joao'@'%';. O cabeleireiro não recebe acesso a pagamentos, clientes.cpf, clientes.historico_saude nem a DROP TABLE. O gerente recebe SELECT em vendas_resumo e estoque, mas não INSERT/UPDATE em clientes. O dono recebe tudo, mas sua conta deve ser usada apenas para auditoria, não no dia a dia.

Dica prática: crie views que exponham apenas colunas permitidas (ex.: v_agendamentos_cabeleireiro sem CPF/telefone) e dê GRANT SELECT na view, não na tabela base. Isso evita vazamento acidental via SELECT *.

Autenticação forte, TLS e gestão de credenciais

Senhas fracas são a porta de entrada mais comum. Exija política de complexidade (mínimo 12 caracteres, maiúscula, minúscula, número, símbolo) e rotação a cada 90 dias via validate_password plugin. Melhor ainda: integre o MySQL a um provedor de identidade (LDAP, Azure AD, Okta) usando authentication_ldap_sasl para ter MFA e revogação centralizada.

No my.cnf, defina require_secure_transport=ON para forçar TLS em todas as conexões. Gere certificados válidos (Let’s Encrypt ou CA interna) e configure ssl_ca, ssl_cert, ssl_key. No cliente, exija --ssl-mode=VERIFY_CA. Isso impede sniffing de credenciais e dados em redes Wi-Fi do salão.

Armazene segredos da aplicação (string de conexão, chaves de API) em cofre (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) — nunca em .env versionado no Git. Rotacione chaves de criptografia de backup (GPG) a cada 180 dias.

Criptografia em repouso e proteção de colunas sensíveis

O MySQL 8.0+ oferece Tablespace Encryption (TDE) via InnoDB: innodb_encrypt_tables=ON e innodb_encrypt_online_alter_logs=ON. Ative para tabelas clientes, pagamentos, ficha_tecnica, auditoria. Para colunas ultra-sensíveis (CPF, cartão, alergias), adicione criptografia em nível de aplicação (AES-256-GCM) antes de gravar — assim, mesmo um SELECT * de um DBA mal-intencionado retorna ciphertext.

Senhas de acesso ao sistema nunca vão ao banco em texto claro. Use bcrypt (cost 12+) ou argon2id via biblioteca da aplicação (PHP password_hash, Node argon2, Python passlib). O banco guarda apenas o hash.

Auditoria e trilha de acesso (audit log)

Compliance exige saber quem fez o quê e quando. No MySQL Enterprise, ative audit_log_format=JSON e audit_log_policy=ALL para capturar conexões, queries, tabelas afetadas e linhas alteradas. No Community, crie triggers em tabelas críticas:

CREATE TRIGGER trg_clientes_audit_upd
AFTER UPDATE ON clientes
FOR EACH ROW
INSERT INTO auditoria_log (tabela, operacao, usuario, timestamp, antes, depois)
VALUES ('clientes', 'UPDATE', CURRENT_USER(), NOW(),
  JSON_OBJECT('cpf', OLD.cpf, 'telefone', OLD.telefone),
  JSON_OBJECT('cpf', NEW.cpf, 'telefone', NEW.telefone));

Armazene logs em tabela auditoria_log com ENGINE=InnoDB, índices em usuario, timestamp, tabela. Retenção mínima de 12 meses. Acesso restrito: GRANT SELECT ON salao.auditoria_log TO 'seguranca'@'%';. Configure alertas para: múltiplas falhas de login, SELECT * FROM clientes fora do horário comercial, DROP/TRUNCATE em qualquer tabela.

Backup seguro, testado e fora do servidor

Backup no mesmo disco do banco não é backup — é cópia local. Automatize com script cron (02:00) que executa:

1. mysqldump --single-transaction --routines --triggers --events --hex-blob salao | gpg --encrypt --recipient backup@salao.com > /tmp/salao_$(date +%F).sql.gpg
2. aws s3 cp /tmp/salao_$(date +%F).sql.gpg s3://bucket-backup-salao/diario/ --storage-class STANDARD_IA
3. Limpeza local: find /tmp -name 'salao_*.sql.gpg' -mtime +2 -delete

Mantenha três camadas: diário (7 dias), semanal (4 semanas), mensal (12 meses) com lifecycle policy no S3/Wasabi/Google Cloud. Teste de restauração mensal obrigatório — agende no calendário, restaure em instância isolada, valide contagem de linhas e integridade referencial. Documente o RTO/RPO aceito pelo dono (ex.: RPO 24h, RTO 4h).

Offboarding rápido e revisão contínua

Quando um cabeleireiro sai, o acesso deve cair em minutos, não dias. Tenha playbook versionado:

1. REVOKE ALL PRIVILEGES ON salao.* FROM 'cabeleireiro_saida'@'%'; DROP USER 'cabeleireiro_saida'@'%';
2. Revogar credencial no IdP (LDAP/SSO) — isso derruba sessões ativas.
3. Rotacionar APP_DB_PASSWORD no cofre de segredos e fazer rolling restart da aplicação.
4. Revisar SHOW GRANTS para contas residuais (% hosts órfãos, usuários de testes).

Agende revisão trimestral de privilégios: exporte SELECT USER, Host FROM mysql.user; e SHOW GRANTS FOR 'user'@'host'; para planilha, valide com RH. Remova o que não faz sentido. Monitore performance_schema.host_cache e audit_log para acessos anômalos (horários, IPs, volume de linhas lidas).

Conclusão prática

Proteger dados de clientes em um salão de beleza não exige orçamento de enterprise — exige disciplina: roles bem definidas, privilégios mínimos, TLS obrigatório, criptografia nas colunas certas, auditoria ativa, backup testado fora do servidor e offboarding em minutos. Comece hoje mapeando quem acessa o quê; o resto é implementação incremental. E se você precisa de um parceiro que entenda tanto de MySQL quanto da rotina de um salão de cabeleireiro em Perdizes, a consultoria especializada acelera o processo e evita multas.

Para aprofundar em arquitetura segura, veja boas práticas em arquitetura de banco de dados para otimizar sistemas MySQL. Para diagnosticar queries lentas que expõem dados desnecessários, consulte diagnóstico slow queries MySQL. E para entender como backups bem feitos sustentam a performance, leia como geradores de backup asseguram a performance de bancos de dados críticos.

Checklist prático

Perguntas frequentes