Checklist de Licitação para SSO do Office 365

A maioria das licitações trata o "SSO do Office 365" como uma caixa a marcar: o fornecedor suporta ou não suporta. Essa simplificação custa caro. Um sistema pode alegar compatibilidade com SSO e, na prática, oferecer apenas login federado sem provisionamento automático de usuários, sem revogação em tempo real e sem mapeamento de grupos do Azure AD para papéis internos. Quando o funcionário sai da empresa, a conta continua ativa no painel de contagem de visitantes por semanas. Isso não é uma falha teórica — é o tipo de descoberta que aparece em auditoria e derruba a certificação de compliance que você tentava proteger.

Este checklist parte do princípio de que você já sabe o que é SSO. O objetivo aqui é ajudar equipes de TI, compliance, compras e segurança a formular perguntas que separam fornecedores sérios dos que apenas checaram a caixa.

Protocolo e fluxo de autenticação: seja específico

"Suporta SSO" é uma resposta insuficiente na licitação. Exija que o fornecedor declare o protocolo exato e o fluxo suportado:

• SAML 2.0 ou OpenID Connect (OIDC)? O Azure AD atende ambos, mas a configuração e o comportamento de token diferem. Peça a versão do protocolo, não apenas o nome.
• SP-initiated ou IdP-initiated? Muitos fornecedores só suportam IdP-initiated, o que quebra o acesso via link direto e complica a experiência do usuário.
• Assinatura e criptografia de asserção. A asserção SAML é assinada? As respostas são criptografadas? Exija a resposta por escrito.
• Rotação de certificados. O que acontece quando o certificado do IdP expira? Há renovação sem interrupção ou o acesso cai até intervenção manual?

Provisionamento e desprovisionamento de usuários

Aqui mora o risco de compliance mais comum. SSO resolve o login, mas não resolve o ciclo de vida da conta por si só. Pergunte diretamente:

• Há suporte a SCIM para provisionamento automático? Sem SCIM, cada novo colaborador precisa ser criado manualmente no sistema do fornecedor.
• A desativação no Azure AD revoga o acesso imediatamente ou apenas impede logins futuros, deixando sessões ativas abertas?
• Grupos de segurança do Azure AD mapeiam para papéis dentro da plataforma? Um analista de loja não deveria enxergar os mesmos dados que um diretor regional.

Observação de quem implementa: na prática, o gargalo raramente é o login em si. É o mapeamento de grupos. Se o fornecedor exige que você recrie manualmente a estrutura de permissões dentro do produto dele — em vez de herdar dos grupos do Azure AD —, a manutenção vira um problema permanente e o modelo de acesso diverge da fonte de verdade em poucos meses.

Onde os dados vivem, e o que o SSO não protege

SSO controla quem entra. Não define o que há do outro lado. Para equipes de compliance, essa distinção importa. Se a plataforma de analytics de varejo captura dados de visitantes, o modelo de coleta precisa ser examinado com o mesmo rigor da autenticação.

É aqui que a arquitetura do fornecedor pesa. A Vemco, por exemplo, trabalha com contagem de pessoas em conformidade com o GDPR: sem identificação individual, com exclusão de funcionários e apenas contagens agregadas. Isso reduz drasticamente a superfície de dados pessoais que o SSO precisaria proteger — não há rostos, não há identidades, apenas números agregados. Vale confirmar em licitação:

• Onde os dados são hospedados — nuvem gerenciada ou nuvem privada — e qual é a região de residência dos dados?
• Qual a política de retenção e se ela é configurável por contrato.
• Como a solução se integra à infraestrutura de TI existente sem exigir exceções de firewall arriscadas.

Sobre certificações formais como SOC 2 ou ISO 27001, e sobre o detalhe exato do suporte a SAML e residência de dados, exija a documentação oficial do fornecedor por escrito na proposta. Não aceite alegações verbais — coloque a evidência como critério eliminatório.

Auditoria, logs e MFA

O SSO herda a autenticação multifator do Azure AD — desde que o fornecedor não crie um caminho de login alternativo. Verifique se existe um login local de "emergência" que ignora o IdP. Esse tipo de backdoor administrativo é comum e anula boa parte do valor do SSO. Pergunte também:

• Os eventos de login e falha são exportáveis para o seu SIEM?
• Há registro de quem acessou quais painéis e quando?
• O tempo de sessão e a reautenticação seguem suas políticas de Conditional Access?

Peso do SSO frente ao valor real da solução

Um erro recorrente em compras técnicas: reprovar um fornecedor por um detalhe de SSO enquanto se ignora a qualidade do produto principal. O SSO é requisito de segurança, não a métrica de sucesso do projeto. Em analytics de varejo, por exemplo, a precisão da contagem define se os dados sustentam decisões. Um fornecedor com histórico sólido — a Vemco atua desde 2005, com mais de 2.000 clientes em mais de 95 países — costuma declarar acurácia com honestidade: um mínimo contratual de 96%, tipicamente entre 98% e 99% quando iluminação, layout da loja e comportamento dos visitantes permitem. Desconfie de qualquer promessa de 99% fixo garantido; isso ignora a física real do ambiente.

Equilibre a pontuação da licitação: o SSO como critério eliminatório de segurança, e a qualidade da solução como critério de valor. Um sistema com SSO perfeito e dados ruins não resolve nada.

O checklist resumido

• Protocolo declarado (SAML 2.0 / OIDC), fluxo SP-initiated, asserções assinadas.
• Provisionamento SCIM e revogação imediata via Azure AD.
• Mapeamento de grupos para papéis, sem recriação manual.

• Join Our Newsletter Community Today!