Identix: plataforma de gestão de identidades e acessos

O Identix é um fornecedor de identidade alojado pelo próprio cliente. A empresa instala-o na sua infraestrutura, e uma única instalação serve muitas aplicações independentes (inquilinos), cada uma com os seus utilizadores, funções, definições de início de sessão e chaves de assinatura. Palavras-passe, chaves e dados pessoais nunca saem da infraestrutura do operador.

A identidade é a parte mais sensível de qualquer sistema em matéria de segurança: um erro neste ponto expõe todas as aplicações que dela dependem. Por isso, o projeto tinha de conciliar uma funcionalidade ampla com uma arquitetura de segurança capaz de resistir a um exame rigoroso. Foi concebido e construído, e é mantido, por um único engenheiro.

Servidor de autorização — OAuth 2.0 e OpenID Connect sobre Spring Authorization Server, com emissor e chaves de assinatura próprios para cada inquilino, rotação de tokens de atualização e revogação imediata de tokens.

• Isolamento rigoroso entre inquilinos — cada pedido fica circunscrito ao seu inquilino, e testes de arquitetura automatizados garantem o cumprimento desta regra
• Utilizadores, funções, grupos e organizações, com importação e exportação em massa e política de palavras-passe por inquilino
• Autenticação de dois fatores (TOTP) com códigos de recuperação
• Personificação auditada — um administrador pode agir em nome de um utilizador, e cada uma dessas sessões fica registada
• Webhooks assinados com HMAC para eventos do ciclo de vida dos utilizadores
• Registo de auditoria — só admite novas entradas, é separado por inquilino e oferece ao operador uma vista transversal a todos os inquilinos
• Exportação e importação da configuração dos inquilinos entre instalações

Consola de administração — React e TypeScript, em inglês e russo, adaptada do computador ao telemóvel, com um portal para programadores integrado: guias de integração e documentação interativa da API.

API pública — 237 operações, integralmente descritas em OpenAPI.

Infraestrutura — três serviços em Kubernetes com charts Helm, PostgreSQL e Redis, e três pipelines de CI/CD no GitLab que compilam, testam e implementam cada serviço. Basta a falha de um único teste para bloquear a implementação.

A arquitetura separa zonas de confiança. O servidor de autorização público não tem acesso à base de dados nem guarda chaves privadas: todos os dados e todas as assinaturas de tokens ficam num serviço interno, acessível apenas dentro do cluster. As chaves de assinatura são guardadas cifradas e só são decifradas em memória; assim, o comprometimento do nó público não expõe chaves nem dados.

A segurança fez parte do método desde o início, não foi acrescentada no fim:

• Modelo de ameaças elaborado com STRIDE: ativos protegidos, perfis de atacante, fronteiras de confiança e uma contramedida para cada ameaça
• Documentação de segurança para auditores, com os controlos mapeados para o OWASP ASVS de nível 2 e para as boas práticas do IETF relativas a OAuth 2.0 e JWT
• Auditoria de segurança concluída com êxito; todas as constatações foram corrigidas

Um engenheiro no papel de arquiteto e de orquestrador de IA, a trabalhar segundo o Specification-Driven Development. O trabalho começou com uma especificação escrita (requisitos, modelo de dados, invariantes de segurança), e cada decisão relevante ficou documentada num registo de decisão de arquitetura (ADR) antes da implementação.

Os agentes de IA geraram código, testes e documentação a partir dessa especificação; o engenheiro reviu cada alteração, respondeu pela arquitetura e pelo modelo de segurança e assumiu a responsabilidade por cada commit. A infraestrutura (manifestos de Kubernetes, charts Helm, pipelines de CI/CD) foi construída pela mesma pessoa e da mesma forma.

O desenvolvimento não foi contínuo: o projeto avançou por etapas, com pausas entre elas. Contando apenas os dias em que houve efetivamente trabalho, a plataforma exigiu 40 dias úteis.

A gestão de identidades e acessos não é um terreno óbvio para demonstrar entregas rápidas: alia um vasto conjunto de funcionalidades a requisitos de segurança intransigentes. O Identix mostra que o método também resulta aqui.

Um engenheiro. 40 dias úteis. Um servidor de autorização multi-inquilino, uma consola de administração, uma API pública com 237 operações, cerca de 1 700 testes automatizados, Kubernetes e CI/CD, e uma arquitetura de segurança sustentada por um modelo de ameaças e por uma auditoria concluída.

O fator decisivo não foi a velocidade de geração de código, mas a disciplina que a rodeia: primeiro a especificação, decisões documentadas, cada alteração revista. É isso que torna o sistema sustentável e que permitiria a outra equipa assumi-lo.