Contexto e Diagnóstico
Por que esses 3 controles ficaram por último — e o que cada um exige
Estado atual: CRIP 3 e CRIP 4 já estão fechados (pacotes prontos e prints capturados). Restam 3 controles sob responsabilidade da Maju TI. Os 3 têm naturezas distintas — não é trabalho repetitivo. Após esses, todos os controles do Grupo E (Responsabilidade Maju) estarão finalizados e o pacote consolidado poderá ser submetido à Netglobe para reavaliação.
~40min
CRIP 5
Matriz + política + 7 prints
Matriz + política + 7 prints
~15min
BD 3
Política + 1 print extra
Política + 1 print extra
~25min
BKP 5
Corrigir documento original
Corrigir documento original
~1h20
Total Maju
Tempo somado
Tempo somado
Boa notícia: 70% do BD 3 já está coberto pelo print Microsoft Service Assurance capturado para o CRIP 3 (menciona literalmente TDE no SQL Azure e chaves no Azure Key Vault). Reaproveitamos sem refazer.
Downloads dos Modelos
Arquivos prontos para preenchimento — clique para baixar
CRIP5_matriz_SoD.xlsx
Planilha com 6 abas: instruções, perfis Bling, usuários ativos, matriz de 13 pares de funções conflitantes, conflitos detectados, referências normativas. Preencher antes de mandar.
MJ.GER_PL_118_v2 - Politica de Controle Logico.docx
Atualização da política existente da Maju (V1.0 → V2.0). Mantém capa, header, rodapé e conteúdo original; adiciona apenas: linha V2.0 no histórico, referências ISO 27001:2022 A.5.3 + COBIT 2019, e novo capítulo "Segregação de Funções (SoD)" com os 13 pares de funções conflitantes. Acompanha a Matriz SoD anexa.
MJ.GER_PL_116 - Politica de Gestao de Chaves do BD.docx
Política formal do BD 3 — modelo SaaS-first reconhecendo que a Maju não opera banco próprio. Defesa apoiada em ISO 27001 A.5.21 (cadeia de fornecimento). Inclui inventário dos bancos em uso, gestão por plataforma (Microsoft 365 e Bling) e plano de evolução.
MJ.GER_PL_117 - Politica de Backup e Recuperacao de Dados.docx
Política formal do BKP 5 — modelo SaaS-first cobrindo Microsoft 365 (Exchange/SharePoint/OneDrive/Teams) + Bling + sincronização OneDrive em notebooks. Inclui RTO/RPO, testes de restauração trimestrais e referência NIST SP 800-111 (exigida pela Netglobe). Como não existe documento anterior na Maju, este é o V1.0 inicial.
Quatro modelos prontos para download: matriz SoD (XLSX) + 3 políticas DOCX. Importante: a
MJ.GER_PL_118_v2 é uma atualização da política existente da Maju (preserva capa/header/rodapé originais). As demais (BD 3 e BKP 5) são modelos novos no padrão visual Maju.
CRIP 5 — Segregação de Funções (SoD)
Garantir que funções conflitantes estão em pessoas diferentes
~40 min Maju
CRIP 5
~40 min
Matriz SoD + Política de Controle de Acesso + prints Entra ID / Bling
Provar que ninguém acumula funções conflitantes (cadastra fornecedor ≠ aprova pagamento, etc.)
O que a Netglobe pediu
Matriz de responsabilidades mostrando que funções críticas estão separadas + prints das roles no Microsoft Entra ID confirmando que ninguém acumula funções conflitantes.
Por que recebeu nota 0
A evidência anterior não mostrou a segregação na prática. Netglobe precisa ver matriz formal + prints técnicos do sistema. Sem isso, considerou não implementado.
Passo a passo
- PASSO 1 — Preencher a Matriz SoD (15 min): Abrir o arquivo
CRIP5_matriz_SoD.xlsx(download acima). Aba 1 (Perfis Bling): apagar perfis-exemplo que não existem, ajustar nomes reais. Aba 2 (Usuários): listar usuários ativos do Bling e M365 com perfil de cada. Aba 3 (Matriz): marcar OK / CONFLITO / N/A em cada um dos 13 pares. Aba 4 (Conflitos): se algum CONFLITO foi marcado, registrar plano de mitigação. - PASSO 2 — Capturar 4 prints do Microsoft Entra ID (10 min): Acessar
entra.microsoft.com→ Identity → Roles & admins.
(A) Lista de Roles administrativas →CRIP5_entra_roles_lista.png
(B) Global Administrator → Assignments →CRIP5_entra_global_admins.png
(C) User Administrator → Assignments →CRIP5_entra_user_admin.png
(D) Billing Administrator → Assignments →CRIP5_entra_billing_admin.png
💡 Se "Billing Administrator" estiver vazio (sem usuários atribuídos), tire o print mesmo assim mostrando "No assignments / 0 usuários". Isso é evidência positiva de segregação — significa que ninguém na Maju acumula essa função isoladamente. - PASSO 3 — Capturar 3 prints do Bling (5 min): Acessar Configurações → Usuários.
(A) Tela de Perfis de Acesso →CRIP5_bling_perfis.png— mostra os modelos/templates de permissão que o Bling oferece (Admin, Vendedor, Financeiro, Estoquista, etc.). Comprova que o sistema suporta segregação.
(B) Lista de Usuários ativos com perfis →CRIP5_bling_usuarios.png— mostra as pessoas reais que usam o Bling com o perfil de cada uma (ex.: João = Admin, Maria = Vendedora). Comprova que a Maju aplica segregação.
(C) Detalhe de 2-3 usuários representativos →CRIP5_bling_usuario_<nome>.png— entrar no perfil individual de cada usuário, mostrando as permissões concedidas.
💡 (A) e (B) são complementares, não duplicados: (A) = "que cargos o sistema oferece"; (B) = "quem ocupa cada cargo". Sem (A) o auditor questiona "existem perfis diferenciados?"; sem (B) questiona "ninguém é Admin sem precisar?". - PASSO 4 — Revisar a Política de Controle Lógico V2.0 (5 min): Baixar o arquivo
MJ.GER_PL_118_v2 - Politica de Controle Logico.docx(download acima). Este arquivo é uma atualização da política V1.0 já existente da Maju (não é documento novo) — mantém capa, header e rodapé originais, adicionando apenas: linha V2.0 no histórico, novas referências normativas (ISO 27001:2022 A.5.3 + COBIT 2019) e capítulo "Segregação de Funções (SoD)" com os 13 pares de funções conflitantes. Revisar e validar o capítulo SoD, conferir se os pares listados se aplicam à realidade da Maju. Salvar comoCRIP5_politica_controle_logico_v2.docx.
Atenção crítica — Global Administrator: deve ter entre 2 e 4 pessoas. Se tiver apenas 1, é Single Point of Failure. Se tiver mais de 5, é privilégio excessivo. Ambos os extremos a Netglobe pode questionar — se for esse o caso, ajustar antes do print.
BD 3 — Gestão de Chaves do Banco de Dados
Modelo SaaS-first — reaproveita evidência do CRIP 3
~15 min Maju
BD 3
~15 min
Política formal de gestão de chaves do banco + print do gerenciamento de chaves
A Maju não opera banco próprio — defesa via ISO 27001 A.5.21 (cadeia de fornecimento)
O que a Netglobe pediu
Documento formal de gestão de chaves do banco de dados (geração, armazenamento, rotação, expiração, descarte) + print da configuração das chaves do banco com evidência de rotação.
Estratégia adotada
A Maju opera modelo SaaS-first — sem banco próprio. Bancos estão no Bling (LWSA) e no Microsoft 365 (Exchange/SharePoint usam Azure SQL). Defesa pela ISO 27001 A.5.21 (delegação contratual a fornecedores certificados).
70% do BD 3 já está coberto pelo CRIP 3. O print Microsoft Service Assurance que o Diogo capturou diz literalmente: "Encriptação de Dados Transparente (TDE) na Base de Dados SQL do Azure" e "chave de cliente é armazenada no Azure Key Vault". Isso é exatamente o que BD 3 pede.
Passo a passo
- PASSO 1 — Baixar e revisar a Política BD 3 (10 min): Baixar o arquivo
MJ.GER_PL_116 - Politica de Gestao de Chaves do BD.docx(download na seção de modelos). Preencher os campos entre[colchetes]: data de emissão, datas de assinatura. Revisar o conteúdo — especialmente itens 6 (Modelo Operacional), 7 (Bancos em Uso) e 8 (Gestão de Chaves por Plataforma SaaS). Salvar comoBD3_politica_chaves_bd_v1.0.docxe assinar (Diogo + Fernando). - PASSO 2 — Capturar 1 print extra do Microsoft Service Assurance (5 min): Acessar
https://learn.microsoft.com/pt-br/compliance/assurance/assurance-encryption-for-microsoft-365-services. Rolar até a seção "BitLocker e Distributed Key Manager (DKM) para criptografia" ou "Gerenciamento de chaves". Capturar mostrando como Microsoft gerencia as chaves do SQL Azure. Garantir URL visível. Salvar comoBD3_microsoft_key_management.png. - PASSO 3 — Reaproveitar prints existentes (0 min): Renomear os prints que já capturamos para o CRIP 3:
→ Microsoft Service Assurance SharePoint/OneDrive (TDE + Key Vault) →BD3_microsoft_tde_keyvault.png
→ Termos Bling cláusula 4.9 (backup) →BD3_bling_backup_termos.png
→ Política LWSA Seção 10 (Segurança) →BD3_lwsa_seguranca.png - PASSO 4 — Consolidar o pacote BD 3: Reunir em uma pasta
BD3/: política assinada + 4 prints. Pasta pronta para envio à Netglobe.
BKP 5 — Revisão Periódica de Backup
Correção pontual do documento existente — não é refazer tudo
~25 min Maju
BKP 5
~25 min
Criar Política de Backup V1.0 a partir do modelo pronto
Como não existe documento anterior no SharePoint, vamos emitir uma política nova V1.0 (mais honesto que fingir histórico inexistente)
O que a Netglobe rejeitou
Data de "próxima revisão" no documento é anterior à data de aprovação — inconsistência cronológica grave. Netglobe interpretou como documento gerado por IA sem revisão humana.
Decisão (após validação com a TI Maju)
Como não existe documento anterior de Política de Backup no SharePoint da Maju, é mais honesto e defensável emitir uma política nova V1.0 com estrutura formal completa, em vez de fingir que existe um V01 prévio. O modelo pronto já inclui referência NIST SP 800-111.
Atenção crítica ao preencher as datas: a data de "Próxima revisão obrigatória" precisa ser posterior à "Data de aprovação". Recomendado: +12 meses. Esse foi exatamente o erro que causou a rejeição anterior.
Passo a passo
- PASSO 1 — Baixar e revisar a Política de Backup V1.0 (15 min): Baixar o arquivo
MJ.GER_PL_117 - Politica de Backup e Recuperacao de Dados.docx(download na seção de modelos). Preencher os campos entre[colchetes]: data de emissão, data de próxima revisão (+12 meses depois), datas de assinatura. Revisar o conteúdo — especialmente itens 7 (Escopo), 9 (Periodicidade e Retenção) e 12 (RTO/RPO) para garantir alinhamento com a operação real da Maju. Salvar comoBKP5_politica_backup_v1.0.docxe coletar assinatura (Diogo + Fernando). - PASSO 2 — (Opcional, mas recomendado) Prints de evidência (5 min):
(A) Configuração de retenção do M365 (admin.microsoft.com → Compliance → Retention) →BKP5_m365_retencao.png
(B) OneDrive com Known Folder Move ativo / versionamento →BKP5_onedrive_versionamento.png
(C) Histórico de backup recente / lixeira do SharePoint →BKP5_evidencia_backup_recente.png - PASSO 3 — Consolidar o pacote BKP 5: Reunir em uma pasta
BKP5/: política V1.0 assinada + prints opcionais. Pasta pronta para envio à Netglobe.
Fluxo Operacional Sugerido
Ordem de execução otimizada — do mais simples ao mais complexo
1
Primeiro — Mais simples
BKP 5 — Localizar e corrigir o documento de backup
Abrir o SharePoint, localizar o arquivo de Procedimento de Backup, aplicar as 4 correções (datas, versão V02, histórico de revisões, referência NIST SP 800-111) e coletar assinatura.
2
Segundo — Reaproveita CRIP 3
BD 3 — Revisar política modelo + capturar 1 print extra
Baixar a política BD 3 (modelo pronto), revisar, assinar. Capturar 1 print extra na página da Microsoft (Gerenciamento de chaves / BitLocker DKM). Reaproveitar prints do CRIP 3.
3
Terceiro — Mais trabalhoso
CRIP 5 — Preencher matriz + revisar política + capturar 7 prints
Baixar a planilha e a política (modelos prontos), preencher com dados reais, capturar 4 prints do Entra ID + 3 prints do Bling. Assinar e consolidar.
✓
Resultado final
3 pacotes prontos para envio à Netglobe
Após executar os 3 controles, a Maju terá: BKP5/ (1 doc corrigido + prints opcionais) · BD3/ (1 política + 4 prints) · CRIP5/ (1 política + 1 matriz + 7 prints). Pronto para reavaliação Netglobe.
Organização Final do Pacote
Estrutura de pastas para envio à Netglobe
Organize tudo em uma pasta única antes do envio
Estrutura recomendada para entrega à Netglobe:
📂 evidencias-3-controles/
- Criar uma pasta única chamada
evidencias-3-controles - Dentro dela, criar 3 subpastas:
CRIP5/— matriz preenchida + política assinada + 7 prints (Entra ID + Bling)BD3/— política assinada + 1 print novo + 3 prints reaproveitados do CRIP 3BKP5/— documento V02 corrigido e assinado + (opcional) 3 prints
- Renomear cada arquivo seguindo o padrão definido em cada passo (ex.:
CRIP5_entra_global_admins.png) - Compactar a pasta inteira em ZIP (clique direito → "Comprimir")
- Submeter à Netglobe via canal oficial de reavaliação
Após esses 3 controles, todos os controles sob responsabilidade da Maju TI estarão fechados. O pacote consolidado final (CRIP 3, CRIP 4, CRIP 5, BD 3, BKP 5) poderá ser submetido à Netglobe para reavaliação.