Sumário

1. Introdução
2. Fundamentação Teórica
   • 2.1. O Problema da Insegurança de Senhas Corporativas
   • 2.2. Criptografia Simétrica (AES-128) e a Biblioteca Fernet
   • 2.3. Entropia e o Módulo Secrets do Python
   • 2.4. Hashing vs. Criptografia: Bcrypt
3. Engenharia de Software
   • 3.1. Requisitos Funcionais (RF)
   • 3.2. Requisitos Não Funcionais (RNF)
   • 3.3. Orientação a Objetos na Arquitetura do Sistema
   • 3.4. Caso de Uso Principal (UC-01)
4. Banco de Dados (MySQL)
   • 4.1. Modelagem e Script DDL
   • 4.2. Consultas Complexas e Relatórios de Auditoria (DML)
5. Gestão, Segurança e LGPD
   • 5.1. Backlog e Histórias de Usuário (Padrão INVEST)
   • 5.2. Conformidade com a LGPD e Privacy by Design
   • 5.3. Cronograma do Projeto
6. Diagramas de Visualização
   • 6.1. Diagrama de Casos de Uso
   • 6.2. Diagrama de Classes
   • 6.3. Diagrama de Entidade-Relacionamento (DER)

1. Introdução

A era digital trouxe consigo uma dependência inexorável de sistemas de informação para o funcionamento das organizações. Com a expansão do perímetro de segurança, impulsionada pelo trabalho remoto e pela adoção de serviços em nuvem, a gestão de credenciais tornou-se um dos pilares mais críticos da segurança da informação. O Projeto Integrador SafePass Corporate, desenvolvido como projeto acadêmico (2026), propõe uma solução robusta, escalável e academicamente rigorosa para mitigar os riscos associados à má gestão de senhas no ambiente corporativo.

O principal objetivo deste projeto é conceber e modelar um sistema de custódia e geração de senhas que aplique princípios avançados de Engenharia de Software e Banco de Dados. A arquitetura foi desenhada para garantir a confidencialidade, integridade, disponibilidade e rastreabilidade das credenciais, premissas exigidas por regulamentações vigentes como a Lei Geral de Proteção de Dados (LGPD). Este documento apresenta toda a modelagem sistêmica, especificações de requisitos, arquitetura de banco de dados e as justificativas criptográficas que embasam a solução.

2. Fundamentação Teórica

2.1. O Problema da Insegurança de Senhas Corporativas

No contexto corporativo contemporâneo, a vulnerabilidade do fator humano continua sendo o elo mais fraco da cadeia de segurança. Práticas como a reutilização de senhas entre múltiplos serviços, a adoção de senhas com baixa entropia e o armazenamento inseguro de credenciais (como em planilhas ou blocos de notas não criptografados) expõem as organizações a ataques de força bruta, credential stuffing e phishing.

As violações de dados frequentemente resultam de credenciais comprometidas, o que pode acarretar prejuízos financeiros severos, danos irreversíveis à reputação da marca e sanções legais. Nesse cenário, um gerenciador de senhas corporativo não é apenas uma ferramenta de conveniência, mas um mecanismo de controle de acesso essencial que centraliza a custódia de segredos e aplica políticas de complexidade de forma automatizada e imperceptível para o usuário final.

2.2. Criptografia Simétrica (AES-128) e a Biblioteca Fernet

Para o armazenamento do conteúdo sensível (neste caso, as senhas corporativas), o projeto emprega o padrão de criptografia simétrica AES (Advanced Encryption Standard). Especificamente, a arquitetura faz uso da especificação AES-128 em modo CBC (Cipher Block Chaining) com preenchimento (padding) PKCS7, abstraída pela biblioteca Fernet da suíte cryptography do Python.

O uso da biblioteca Fernet assegura que toda mensagem criptografada (o ciphertext) seja assinada digitalmente com um HMAC (Hash-based Message Authentication Code) utilizando SHA-256. Isso não apenas garante a confidencialidade do dado em repouso no banco de dados, mas também a sua integridade, evitando que o dado sofra qualquer tipo de manipulação ou corrupção maliciosa. A escolha do AES-128 balanceia alta performance computacional (essencial para não degradar a experiência do usuário) com um nível de segurança considerado inquebrável por métodos criptoanalíticos clássicos.

2.3. Entropia e o Módulo Secrets do Python

A geração de novas senhas pelo SafePass Corporate requer um gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG). O uso de funções randômicas padrão, como o módulo random tradicional, é inadequado para segurança devido à sua previsibilidade inerente e suscetibilidade a ataques de inferência de estado.

Para atender aos rigorosos critérios de segurança, a solução utiliza o módulo secrets nativo da linguagem Python, projetado especificamente para gerenciar dados sigilosos e tokens de autenticação. A entropia das senhas geradas provém de fontes de entropia do sistema operacional (como o /dev/urandom em sistemas baseados em Unix), garantindo que cada caracter inserido na nova senha seja estatisticamente independente e impredizível. A alta entropia impede a eficácia de ataques de dicionário e reduz substancialmente a probabilidade de colisões.

2.4. Hashing vs. Criptografia: Bcrypt

É fundamental distinguir o armazenamento das credenciais do sistema (a senha mestra do usuário) do armazenamento dos segredos custodiados (as senhas de terceiros salvas pelo usuário).

• Criptografia Simétrica (Fernet/AES): Aplicada às senhas que o usuário guarda no cofre. A criptografia é uma função bidirecional; portanto, o sistema deve ser capaz de decriptar o valor para exibi-lo ao usuário legítimo mediante o fornecimento da chave correta.
• Hashing (Bcrypt): Aplicado exclusivamente à senha mestra do usuário que dá acesso ao sistema SafePass. Diferente da criptografia, o hashing é unidirecional. A utilização do algoritmo Bcrypt impõe um "fator de custo" (work factor), tornando a função intencionalmente lenta e intensiva em processamento. Esse design mitiga significativamente ataques de força bruta, pois atrasa a taxa na qual um atacante pode calcular os hashes. Ademais, o Bcrypt gera e incorpora um salt único automaticamente, anulando ataques com base em tabelas rainbow (Rainbow Tables).

3. Engenharia de Software

O desenvolvimento do SafePass Corporate foi pautado em um ciclo de vida de desenvolvimento de software (SDLC) iterativo, adotando práticas consolidadas de Engenharia de Requisitos e modelagem orientada a objetos (UML).

3.1. Requisitos Funcionais (RF)

Os Requisitos Funcionais descrevem as ações específicas que o sistema deve estar preparado para executar:

1. RF-01 | Autenticação Segura: O sistema deve permitir que os usuários se autentiquem utilizando um e-mail corporativo e uma senha mestra, cuja validação deverá ocorrer via comparação de hash Bcrypt.
2. RF-02 | Geração de Senhas de Alta Entropia: O sistema deve fornecer um módulo capaz de gerar senhas aleatórias configuráveis (comprimento, letras, números, símbolos) utilizando o módulo criptograficamente seguro secrets.
3. RF-03 | Custódia Criptografada de Segredos: O sistema deve armazenar as credenciais corporativas informadas pelo usuário, garantindo que o dado sensível seja criptografado (AES-128/Fernet) antes da persistência no banco de dados.
4. RF-04 | Desencriptação em Tempo Real: O sistema deve permitir que o usuário proprietário da credencial recupere e visualize a senha em texto plano (plaintext) em sua interface, decriptando o conteúdo sob demanda.
5. RF-05 | Auditoria de Acessos: O sistema deve registrar um log imutável de todas as ações de inserção, visualização e exclusão de credenciais, associando a ação ao ID do usuário e ao timestamp da requisição.

3.2. Requisitos Não Funcionais (RNF)

Os Requisitos Não Funcionais especificam atributos de qualidade e restrições técnicas do sistema:

1. RNF-01 | Segurança de Dados (Confidencialidade): Sob nenhuma circunstância o sistema deverá armazenar a senha mestra do usuário em texto plano ou trafegá-la sem a devida proteção de TLS/SSL.
2. RNF-02 | Desempenho e Latência: O processo de encriptação e persistência de uma credencial no banco de dados não deve exceder a latência de 500 milissegundos, garantindo fluidez na interface.
3. RNF-03 | Conformidade Legal: O projeto da arquitetura de dados e logs deve estar estritamente alinhado às diretrizes de privacidade da Lei Geral de Proteção de Dados (LGPD), permitindo a exclusão definitiva dos dados do usuário (direito ao esquecimento).

3.3. Orientação a Objetos na Arquitetura do Sistema

A arquitetura do SafePass Corporate adota os pilares da Programação Orientada a Objetos (POO) para promover coesão, baixo acoplamento e reusabilidade do código. A modelagem teórica engloba:

• Abstração: O sistema isola as complexidades da biblioteca de criptografia do resto da aplicação. Uma classe CryptoService expõe apenas os métodos encrypt() e decrypt(), ocultando do domínio as operações de padding e geração de chave.
• Encapsulamento: Os atributos críticos das classes de domínio (como a chave secreta do usuário e o hash da senha) são definidos como privados. O acesso a essas propriedades e suas mutações são restritos a métodos getters e setters controlados, assegurando que o estado do objeto não seja corrompido.
• Polimorfismo: A aplicação implementa interfaces para o registro de atividades (Auditoria). Por exemplo, a interface ILogger pode ser instanciada como DatabaseLogger ou FileLogger, permitindo que o sistema grave eventos de segurança em diferentes mídias chamando o mesmo método .log(), sem que a camada de negócios precise conhecer a implementação de destino.

3.4. Caso de Uso Principal (UC-01)

Identificador: UC-01
Nome: Armazenar Nova Credencial Corporativa
Ator Principal: Usuário Corporativo Autenticado
Pré-condição: O usuário deve estar logado no sistema com uma sessão ativa.

Fluxo Principal:

1. O usuário acessa a funcionalidade "Nova Credencial".
2. O sistema apresenta o formulário solicitando Título, URL/Sistema, Nome de Usuário e Senha.
3. O usuário preenche os dados (opcionalmente utilizando o RF-02 para gerar a senha) e confirma a submissão.
4. O sistema intercepta o dado, instancia a classe de criptografia e aplica a cifra Fernet (AES-128) na senha em texto plano.
5. O sistema envia a instrução INSERT para o Banco de Dados com os metadados e o conteúdo já cifrado.
6. O sistema registra o evento no Log de Auditoria.
7. O sistema retorna uma mensagem de sucesso para a interface do usuário.

Fluxo de Exceção 1 (Falha na Persistência): Se, no passo 5, o banco de dados retornar um erro (ex: timeout ou violação de chave), o sistema aborta a transação (rollback), não grava o Log de Auditoria associado a essa inserção e exibe a mensagem: "Erro ao comunicar com o servidor de banco de dados. Tente novamente."

4. Banco de Dados (MySQL)

O sistema de gerenciamento de banco de dados relacional escolhido para o projeto é o MySQL. A modelagem foi concebida para estar na 3ª Forma Normal (3FN), mitigando anomalias de atualização e redundâncias.

4.1. Modelagem e Script DDL

O script de Data Definition Language (DDL) evidencia a criação de tabelas cruciais, definindo chaves primárias (PK), chaves estrangeiras (FK) com integridade referencial, e a correta tipagem para armazenar conteúdo binário encriptado.

-- Criação do Banco de Dados
CREATE DATABASE IF NOT EXISTS db_safepass_corporate
CHARACTER SET utf8mb4 
COLLATE utf8mb4_unicode_ci;

USE db_safepass_corporate;

-- Tabela de Usuários (Colaboradores)
CREATE TABLE IF NOT EXISTS tbl_usuarios (
    id_usuario INT AUTO_INCREMENT PRIMARY KEY,
    nome_completo VARCHAR(100) NOT NULL,
    email_corporativo VARCHAR(150) NOT NULL UNIQUE,
    senha_hash VARCHAR(255) NOT NULL COMMENT 'Armazena o hash Bcrypt',
    data_criacao DATETIME DEFAULT CURRENT_TIMESTAMP,
    status ENUM('ATIVO', 'INATIVO') DEFAULT 'ATIVO'
);

-- Tabela de Credenciais (Cofre de Senhas)
CREATE TABLE IF NOT EXISTS tbl_credenciais (
    id_credencial INT AUTO_INCREMENT PRIMARY KEY,
    id_usuario INT NOT NULL,
    titulo_servico VARCHAR(100) NOT NULL,
    url_sistema VARCHAR(255),
    nome_usuario_acesso VARCHAR(100) NOT NULL,
    senha_criptografada VARBINARY(500) NOT NULL COMMENT 'Senha cifrada com AES-128 (Fernet)',
    data_registro DATETIME DEFAULT CURRENT_TIMESTAMP,
    data_atualizacao DATETIME ON UPDATE CURRENT_TIMESTAMP,
    FOREIGN KEY (id_usuario) REFERENCES tbl_usuarios(id_usuario) 
        ON DELETE CASCADE 
        ON UPDATE CASCADE
);

-- Tabela de Logs de Auditoria
CREATE TABLE IF NOT EXISTS tbl_auditoria_logs (
    id_log INT AUTO_INCREMENT PRIMARY KEY,
    id_usuario INT NOT NULL,
    acao_realizada VARCHAR(50) NOT NULL,
    descricao_evento TEXT,
    endereco_ip VARCHAR(45) NOT NULL,
    data_evento DATETIME DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (id_usuario) REFERENCES tbl_usuarios(id_usuario)
);

4.2. Consultas Complexas e Relatórios de Auditoria (DML)

Para atender a demandas rigorosas de Compliance e governança corporativa, os DBAs do projeto desenvolveram rotinas de Data Manipulation Language (DML) avançadas. A consulta abaixo gera um relatório analítico para auditores, listando os usuários mais ativos na plataforma nos últimos 6 meses, agregando dados de quantitativo de credenciais armazenadas e eventos críticos gerados.

-- Relatório Avançado de Auditoria Semestral
SELECT 
    U.nome_completo AS 'Colaborador',
    U.email_corporativo AS 'E-mail',
    COUNT(DISTINCT C.id_credencial) AS 'Total de Credenciais no Cofre',
    COUNT(DISTINCT A.id_log) AS 'Total de Eventos de Auditoria',
    MAX(A.data_evento) AS 'Última Atividade Registrada'
FROM 
    tbl_usuarios U
INNER JOIN 
    tbl_credenciais C ON U.id_usuario = C.id_usuario
INNER JOIN 
    tbl_auditoria_logs A ON U.id_usuario = A.id_usuario
WHERE 
    A.data_evento >= DATE_SUB(CURRENT_DATE(), INTERVAL 6 MONTH)
    AND U.status = 'ATIVO'
GROUP BY 
    U.id_usuario, U.nome_completo, U.email_corporativo
HAVING 
    COUNT(DISTINCT A.id_log) > 10
ORDER BY 
    'Total de Eventos de Auditoria' DESC;

Justificativa Técnica: A query utiliza INNER JOIN para cruzar tabelas fortemente tipadas. O GROUP BY condensa a informação no nível do colaborador, enquanto a função de agregação DATE_SUB dinamicamente retroage 6 meses. O uso da cláusula HAVING atua como um filtro pós-agregação, exibindo apenas usuários com volume significativo de ações, essencial para identificar padrões anômalos de acesso.

5. Gestão, Segurança e LGPD

5.1. Backlog e Histórias de Usuário (Padrão INVEST)

O desenvolvimento segue uma mentalidade Ágil (Scrum). O Backlog do Produto foi construído garantindo que os itens de trabalho sigam a heurística INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable).

História de Usuário 01 - Geração de Senhas

Como um funcionário de infraestrutura,
Eu quero um gerador automático de senhas que utilize caracteres especiais e alta entropia,
Para que eu não precise pensar em combinações complexas que atendam às exigências do Active Directory da empresa.
Critérios de Aceite: O gerador deve possuir opções em interface para definir o tamanho (8 a 64 caracteres); deve incluir por padrão A-Z, a-z, 0-9 e símbolos; o tempo de geração não pode ultrapassar 100ms.

História de Usuário 02 - Log de Auditoria

Como um Auditor de Segurança (DPO),
Eu quero visualizar um painel administrativo com todos os acessos de decriptação das senhas,
Para que a empresa possa rastrear acessos indevidos em caso de vazamento de informações.
Critérios de Aceite: O registro deve ocorrer via trigger no banco ou serviço centralizado no back-end; o log deve capturar o ID do usuário, a data e a ação específica (Visualização de Credencial XYZ); o dado de log deve ser somente leitura (append-only).

5.2. Conformidade com a LGPD e Privacy by Design

A arquitetura do SafePass Corporate foi concebida sob a óptica do Privacy by Design (Privacidade desde a Concepção). Em total alinhamento à Lei Geral de Proteção de Dados Pessoais (Lei nº 13.709/2018):

• Minimização de Dados (Art. 6º, III): O sistema coleta estritamente o necessário para sua finalidade (Nome e E-mail corporativo). Nenhum dado pessoal sensível adicional é requisitado.
• Segurança (Art. 6º, VIII): A utilização de criptografia AES-128 e Hashing Bcrypt demonstra o emprego de medidas técnicas adequadas para proteger os dados contra acessos não autorizados.
• Direitos do Titular (Art. 18): A estrutura em cascata (ON DELETE CASCADE) na modelagem de banco de dados assegura que, mediante o desligamento do colaborador ou revogação de consentimento, a exclusão do registro na tbl_usuarios erradicará automaticamente todas as suas credenciais no cofre e vínculos lógicos no banco de dados, atendendo ao direito à eliminação dos dados.

5.3. Cronograma do Projeto

A execução do Projeto Integrador foi estruturada em um ciclo intenso de 6 semanas:

6. Diagramas de Visualização

A representação visual da arquitetura foi elaborada utilizando a linguagem de marcação estruturada Mermaid, permitindo integração nativa de documentação como código.

6.1. Diagrama de Casos de Uso

Este diagrama evidencia as principais interações do Ator (Usuário Corporativo) com as fronteiras do sistema SafePass.

Versão em SVG (Diagrama de Casos de Uso):

6.2. Diagrama de Classes

O diagrama de classes reflete o nível de abstração orientado a objetos, focando no desacoplamento entre os domínios de negócio e os serviços criptográficos.

6.3. Diagrama de Entidade-Relacionamento (DER)

O DER lógico abaixo detalha os artefatos de dados hospedados no MySQL, consolidando as relações estruturadas no script DDL da Seção 4.1.

Fim da Documentação do Projeto Integrador (2026). Este documento foi estruturado visando o rigor técnico, profundidade em arquitetura de software e aderência às melhores práticas de segurança da informação no cenário corporativo.