Ph3i Technology - Software House de Segurança e Desempenho

Introdução: o que a ISO 27001 é e o que ela não é

A ISO 27001 costuma assustar quem está no dia a dia da TI. Para muitos, ela parece um conjunto infinito de regras, siglas e documentos que só fazem sentido para consultor e auditor. Mas, na prática, a norma fala sobre algo bem concreto: como organizar a segurança da informação de forma estruturada, baseada em risco e em melhoria contínua.

O problema é quando a ISO 27001 é tratada apenas como um projeto de papelada. Aí surge um abismo entre "o que está escrito" e "o que realmente acontece" em servidores, aplicações, pipelines, bancos de dados, redes e acessos.

Este guia é voltado para times de TI que querem entender onde eles entram na ISO 27001 e como transformar controles e requisitos em decisões práticas de arquitetura, acesso, logs, backup e desenvolvimento.

A ideia não é substituir o trabalho do pessoal de governança ou do consultor. A ideia é mostrar como TI pode parar de ser "quem sofre com as demandas" e virar parte ativa da solução.

Mapeando o escopo de TI dentro do Sistema de Gestão de Segurança da Informação

A ISO 27001 fala de um Sistema de Gestão de Segurança da Informação (SGSI). Em outras palavras, um conjunto de políticas, processos, papéis, controles e evidências que a empresa usa para proteger as informações.

Antes de falar de servidor, cloud ou código, é essencial responder:

Quais sistemas estão dentro do escopo do SGSI?
Quais ambientes (prod, homolog, dev) fazem parte desse escopo?
Que tipos de informação esses sistemas tratam (dados pessoais, financeiros, propriedade intelectual)?
Quais equipes de TI estão diretamente envolvidas (infra, dev, suporte, segurança, DevOps)?

Esse recorte é importante porque:

Nem tudo na empresa está no escopo da certificação, mas tudo o que está no escopo precisa ser levado a sério.
TI precisa saber em quais sistemas a auditoria vai olhar com lupa: acessos, mudanças, logs, backup, incidentes, etc.

Uma boa prática é manter um inventário vivo de ativos de TI no escopo:

Aplicações (nome, responsável técnico, tecnologias).
Bancos de dados (tipo, localização, dados sensíveis armazenados).
Infraestrutura (cloud, on prem, VMs, containers).
Contas e serviços gerenciados (IAM, e-mail, ferramentas de monitoramento, repositórios de código).

Esse inventário é o mapa que conecta a teoria da ISO com a realidade da TI.

Controles de acesso: usuários, privilégios, MFA e segregação de funções

Boa parte da ISO 27001 fala, de forma direta ou indireta, sobre quem pode fazer o quê. Para TI, isso se traduz em:

Como os usuários são criados, alterados e removidos.
Como os perfis de acesso são definidos.
Como acessos privilegiados são controlados e monitorados.

Alguns pontos-chave para TI colocar em prática:

1. Processos claros de entrada e saída

Quando alguém entra na empresa, quais acessos recebe e com base em quê?
Quando alguém muda de função, quem revisa e ajusta os acessos?
Quando alguém sai, existe um fluxo que garante revogação total em prazo definido?

Ter fluxos automatizados (via IAM, integração com AD/IdP, etc.) ajuda, mas mesmo em ambientes menores dá para registrar e seguir um passo a passo simples.

2. Princípio do menor privilégio

Usuários e sistemas com acesso "admin geral" são riscos óbvios. O papel da TI é:

Criar perfis (roles) com escopos bem definidos.
Evitar contas compartilhadas.
Reservar acessos elevados para situações específicas, com rastreamento.

3. MFA onde faz mais diferença

Nem sempre dá para colocar MFA em tudo, mas não ter MFA em acessos críticos (ex.: painel de cloud, VPN, sistemas internos sensíveis) é um risco desnecessário.

TI pode propor uma priorização:

Primeiro: acessos administrativos (cloud, banco, firewalls, repositórios de código).
Depois: sistemas de negócio sensíveis (dados pessoais, financeiros, operação crítica).
Depois: demais sistemas, de forma gradual.

4. Segregação de funções

Em alguns contextos, a mesma pessoa não deveria poder criar, aprovar e executar certas ações. Isso se aplica, por exemplo, a:

Movimentações financeiras.
Aprovação de mudanças em produção.
Liberação de acessos administrativos.

TI ajuda a implementar essa segregação, configurando permissões e fluxos de aprovação em sistemas e ferramentas.

Controles de registro e logs: o que registrar, onde e por quanto tempo

Sem registro confiável, não há como provar nada em uma auditoria, nem entender um incidente de segurança. Logs são uma parte central da ISO 27001 na prática.

Algumas decisões que o time de TI precisa tomar:

Que eventos registrar

Autenticação: logins bem-sucedidos, falhas de login, reset de senha.
Autorização: alterações de permissão, inclusão em grupos de acesso, uso de funções administrativas.
Operações críticas: exclusões, alterações sensíveis, exportação de grandes volumes de dados.
Eventos técnicos: erros de aplicação, falhas de integração, indisponibilidade de serviços.

Onde armazenar logs

Preferencialmente em um repositório centralizado, com controle de acesso e trilha de auditoria.
Separar logs de aplicação, infraestrutura e segurança pode ajudar na análise, desde que haja forma de correlação.

Por quanto tempo manter

O tempo de retenção precisa equilibrar requisitos legais, LGPD, auditoria e custo.
Em geral, tempos como 6, 12 ou 24 meses são comuns, dependendo do contexto.

Cuidados com dados pessoais nos logs

Não registrar senhas, tokens, números completos de documento, dados sensíveis.
Quando necessário registrar algo identificável, avaliar mascaramento ou pseudonimização.

TI não precisa escrever um livro sobre logs, mas precisa deixar claro:

O que é registrado.
Onde fica.
Quem pode acessar.
Por quanto tempo.

Isso vale ouro na auditoria.

Backups e continuidade: RPO, RTO e testes de restauração

ISO 27001 não se resume a "ter backup". O foco é capacidade real de recuperar e manter o negócio funcionando.

Do ponto de vista de TI, três conceitos precisam estar muito claros:

RPO (Recovery Point Objective): quanto de dado a empresa aceita perder em um incidente (ex.: até 15 minutos, 1 hora, 24 horas).
RTO (Recovery Time Objective): quanto tempo o sistema pode ficar fora do ar até voltar a operar.
Testes de restauração: evidências de que o backup realmente funciona.

Desenhando a rotina de backup

O que entra na rotina: bancos de dados, buckets de arquivos, configurações, infraestrutura como código, etc.
Frequência: diária, horária, contínua, baseada em snapshots.
Local: outra zona de disponibilidade, outra região, storage imutável.

Realizando testes de restauração

Auditor não quer só ouvir "temos backup". Ele quer ver evidência de restauração:

Procedimento claro (passo a passo).
Registro de quando o teste foi feito, por quem e com qual resultado.
Ajustes realizados após o teste (melhorias, correções, automatizações).

TI é protagonista aqui. Sem o time técnico, essa parte da ISO não sai do discurso.

Segurança em desenvolvimento: repositórios, pipelines, revisões de código

Para empresas que desenvolvem software, uma parte importante da ISO 27001 cai diretamente no colo do time de dev e DevOps.

Pontos essenciais:

Repositórios de código

Acesso controlado (nada de repositório aberto sem necessidade).
Duplo fator de autenticação para contas de desenvolvedores.
Política clara de branches, revisão e aprovação.

Pipelines (CI/CD)

Automatização de build, testes e deploy, com permissões bem definidas.
Gate de aprovação para deploy em ambientes sensíveis (ex.: produção).
Registro dos deploys realizados (quem aprovou, o que mudou, quando).

Gestão de secrets

Nunca subir senhas, tokens e chaves no Git.
Uso de secret managers, variáveis de ambiente seguras e automações para injeção em runtime.
Rotação periódica de secrets sensíveis.

Revisão de código com olhar para segurança

Não é só ver se "funciona". Em features críticas, avaliar:
- Validação de entrada.
- Tratamento de erros.
- Exposição de dados.
- Consultas a banco (SQL injection).
- Autorização correta antes de executar ações.

Mesmo sem ferramentas sofisticadas, uma prática consistente de revisão já reduz muito o risco.

Relacionando controles a evidências técnicas que TI consegue entregar

A ISO 27001 traz uma série de controles (especialmente no Anexo A). Na prática, auditor vai perguntar:

"Como esse controle está implementado?"
"Pode me mostrar evidências?"

O segredo é evitar que o controle fique só na política escrita. TI consegue transformar isso em evidência técnica, como por exemplo:

Controle de acessos → prints/configs de IAM, grupos, perfis, políticas.
Logs e monitoramento → telas de ferramentas de observabilidade, exemplos de registros.
Backup e restauração → registros de jobs concluídos e relatórios de testes de restore.
Segurança em desenvolvimento → prints de pipelines, histórico de merge requests com aprovação, configurações de secret manager.

Uma boa prática é manter um mapa de controles x evidências x responsáveis. Assim TI sabe:

Quando fizer uma mudança, quais evidências precisam ser atualizadas.
Em auditoria, onde buscar rapidamente as telas e relatórios necessários.

Como TI e segurança podem trabalhar juntos no dia a dia

Em muitas empresas, existe uma separação entre "time de segurança" e "time de TI". Na ISO 27001, se esses times trabalharem isolados, o SGSI tende a virar burocracia.

O ideal é criar uma rotina em que TI e segurança:

Planejam juntos mudanças relevantes em sistemas críticos.
Definem em conjunto impactos em riscos e controles.
Avaliam incidentes e quase-incidentes para melhorar processos.
Mantêm um backlog de melhorias de segurança, priorizado por risco.

Na prática, isso pode ser feito com:

Reuniões periódicas rápidas (ex.: quinzenais) para revisar riscos, mudanças e incidentes.
Registro de decisões e pendências em uma ferramenta simples (board Kanban, por exemplo).
Envolvimento de segurança na definição de novos projetos desde o início.

Assim TI deixa de ser "área que recebe demanda da norma" e passa a ser criadora de soluções seguras.

Checklist resumido para times de TI baseado nos principais anexos

Para fechar, um checklist rápido para TI se localizar na prática da ISO 27001. Use como ponto de partida, adaptando à realidade da empresa.

Acessos e identidade

[ ] Existem processos documentados para entrada, mudança e saída de usuários?
[ ] Perfis de acesso seguem o princípio do menor privilégio?
[ ] MFA está habilitado nos acessos mais críticos?

Logs e monitoramento

[ ] Eventos de autenticação, autorização e operações críticas são registrados?
[ ] Os logs estão centralizados e com acesso controlado?
[ ] Existe período de retenção definido?
[ ] Há algum nível de monitoramento e alertas sobre falhas e eventos suspeitos?

Backups e continuidade

[ ] RPO e RTO dos sistemas críticos estão definidos e conhecidos?
[ ] Existe rotina de backup implementada e monitorada?
[ ] Testes de restauração são feitos periodicamente e registrados?

Desenvolvimento e mudanças

[ ] Repositórios de código têm controle de acesso e MFA?
[ ] Pipelines de CI/CD são registrados e possuem aprovações claras?
[ ] Secrets são gerenciados em cofre seguro e não vão para o código?
[ ] Revisões de código consideram segurança, especialmente em áreas críticas?

Evidências e auditoria

[ ] Existe um mapa ligando controles a evidências técnicas?
[ ] TI sabe onde buscar evidências atualizadas de acessos, logs, backup, mudanças?
[ ] Incidentes e melhorias são registrados e usados para evoluir o SGSI?

Se esse checklist começar a ser respondido com "sim" de forma consistente, é sinal de que TI não está apenas cumprindo tabela na ISO 27001. Está ajudando a construir um ambiente realmente mais seguro e previsível.

ISO 27001 na prática para times de TI