Termos de uso Entra: exigir aceitação com Conditional Access

O que os termos de uso Entra realmente impõem

Os termos de uso Entra apresentam um documento durante um início de sessão interativo e podem tornar a aceitação uma condição de acesso. A pergunta útil é se as pessoas previstas têm de aceitar o documento aprovado antes de chegarem à aplicação prevista. Encontrar um PDF no tenant responde apenas a parte dessa pergunta.

Comece por um requisito de negócio: quem precisa de reconhecer quais regras, para quais recursos, e quem é responsável pelo texto? Peça aos revisores de negócio e jurídicos apropriados que aprovem o documento antes de configurar a imposição. A ausência de um acordo é um sinal de configuração a investigar, não uma prova de infração regulamentar universal. Alguns tenants podem não ter um caso de uso justificado para esta funcionalidade; registe essa decisão em vez de criar um acordo vazio para eliminar um resultado.

Um piloto prático pode abranger um espaço de trabalho de parceiros cujo responsável pretende que os colaboradores externos reconheçam as suas regras de tratamento de dados. Defina explicitamente a população e a aplicação. Não pressuponha que todas as formas de partilha externa criam uma conta de convidado Entra ou passam pelo mesmo percurso de início de sessão. Use a revisão de Conditional Access para convidados e colaboração externa para delimitar essa população e as suas exclusões antes de acrescentar a aceitação do documento.

A implementação deve produzir provas para três perguntas distintas: o acordo existe, uma política que impõe o acesso exige esse acordo para a população e o recurso escolhidos, e as respostas dos utilizadores mostram que o documento esperado foi aceite ou recusado? Mantenha essas respostas separadas no registo da alteração.

Como o acordo e o Conditional Access se articulam

O guia de configuração de termos de uso da Microsoft exige licenciamento Entra ID P1 e um PDF. Indica Security Reader como função mínima para ler a configuração e Conditional Access Administrator para a criar ou modificar. Confirme a subscrição e a atribuição do administrador antes de agendar o piloto.

O acordo contém as definições do documento; um controlo de concessão do Conditional Access liga-o às decisões de acesso. A escolha de idiomas e versões também faz parte do desenho. Um acordo que existe sem a ligação à política prevista pode satisfazer uma verificação de existência e deixar o requisito de negócio por cumprir.

O recurso agreement do Graph disponibiliza um identificador, requisitos de visualização e por dispositivo, um calendário de expiração e uma duração de nova aceitação por utilizador. A sua relação file identifica o PDF predefinido; a documentação indica que files está a ser descontinuada em favor de file. A relação acceptances é uma coleção separada de respostas dos utilizadores.

Use estas distinções ao planear as provas. Mantenha o ID do acordo e a versão aprovada do PDF juntos e depois registe a política que exige esse acordo. Um nome de apresentação é conveniente para as pessoas, mas o identificador é a chave de associação mais segura para os registos de configuração e de resposta. Atribua um responsável pela manutenção do documento e das traduções, e um responsável pela política para manter o âmbito. Se um dos lados mudar, reveja o outro lado da ligação.

Deteção: verificar separadamente existência, ligação e respostas

Inventariar os acordos sem confundir uma leitura falhada com ausência

No Entra admin center, abra Entra ID > Conditional Access > Terms of use. Identifique o acordo previsto para o cenário de negócio, os idiomas dos documentos e o histórico de versões. Se a página estiver vazia, confirme que está a inspecionar o tenant correto com uma função de leitura adequada antes de registar uma ausência.

Para um inventário independente por API, a Microsoft documenta este pedido em List agreements:

GET https://graph.microsoft.com/v1.0/identityGovernance/termsOfUse/agreements
Authorization: Bearer {token}

Este é um modelo de pedido documentado, não uma consulta executada num tenant de cliente para este artigo. A página indica a permissão delegada Agreement.Read.All para contas profissionais ou escolares, com Security Reader como função suportada de menor privilégio. Indica que as permissões de aplicação não são suportadas para esta operação. Verifique o modelo de permissões atual do cliente que utiliza em vez de pressupor que um token de aplicação e um token delegado oferecem cobertura equivalente.

Trate um erro de autorização, uma recolha interrompida ou uma resposta ilegível como uma observação por resolver. Só um inventário bem-sucedido e completo sustenta a conclusão de que não foram devolvidos acordos. Preserve o contexto do tenant, a hora da recolha e quaisquer erros juntamente com o resultado.

Inspecionar a política que deve exigir o acordo

Abra a política Conditional Access relevante e inspecione o seu estado, os utilizadores ou grupos incluídos, as exclusões, os recursos de destino e os controlos de concessão. Confirme que o acordo previsto está selecionado em Grant access, fornecendo o requisito Require terms of use. Verifique a combinação dos controlos de concessão para que a decisão de acesso planeada exija efetivamente a aceitação.

Um nome de política que menciona termos de uso não é prova suficiente. A configuração Report-only é útil para rever o impacto, mas o teste de imposição tem de usar uma política piloto ativada. Siga um utilizador de teste previsto pelas atribuições e exclusões e depois efetue o início de sessão no recurso. Se o inventário de acordos tiver entradas, mas nenhuma política prevista as selecionar, registe a lacuna de ligação separadamente da ausência de acordos.

Rever as provas de aceitação da versão prevista

O portal disponibiliza respostas aceites e recusadas e o histórico de versões. Para provas por API, List acceptances documenta:

GET https://graph.microsoft.com/v1.0/identityGovernance/termsOfUse/agreements/{agreementsId}/acceptances
Authorization: Bearer {token}

Os objetos devolvidos são registos agreementAcceptance, habitualmente designados como aceitações de acordos. A referência do recurso descreve agreementId, agreementFileId, userId, state, recordedDateTime e expirationDateTime. Os estados de resposta documentados são accepted e declined. Correlacione o utilizador, o acordo e o ficheiro em vez de tratar qualquer aceitação histórica como prova do documento atual.

Para este endpoint limitado a um acordo, a operação de listagem documenta a permissão delegada AgreementAcceptance.Read e a permissão superior AgreementAcceptance.Read.All, com Security Reader como função suportada de menor privilégio. Indica que as permissões de aplicação não são suportadas. Trate as exportações de aceitação como dados de utilizadores, limite o acesso aos revisores que precisam dele e siga as regras de retenção da sua organização. A finalidade da exportação é fundamentar o piloto, não criar uma cópia irrestrita da atividade dos utilizadores.

Correção: implementar um acordo aprovado através de um piloto delimitado (Remediation)

1. Aprovar o texto e definir o requisito de aceitação

Registe o responsável pelo recurso, o responsável pelo documento, os utilizadores previstos, os idiomas necessários, as exceções e o comportamento esperado da nova aceitação. Decida se uma versão atualizada exige uma nova resposta. Dê à equipa de suporte um contacto para perguntas sobre os termos e outro contacto para problemas de início de sessão. Faça-o antes de carregar o PDF para que uma alteração de autenticação não se transforme num exercício improvisado de redação de regras.

2. Criar o acordo e verificar a sua apresentação

Use Conditional Access > Terms of use > New terms. Carregue o PDF finalizado, escolha o idioma e o título apresentado aos utilizadores, e configure Require users to expand the terms of use quando a experiência aprovada exigir a abertura do documento antes da aceitação. Adicione as variantes linguísticas aprovadas e reveja o que um utilizador previsto vê. Registe o ID do acordo e o PDF carregado para cada idioma.

Decida as opções de expiração e por dispositivo a partir do caso de uso, em vez de as ativar automaticamente. Em particular, o Learn exclui os utilizadores B2B do suporte de termos de uso por dispositivo. Num piloto para utilizadores externos, mantenha o requisito normal do acordo distinto dessa opção por dispositivo e valide o percurso de colaboração real.

3. Ligar o acordo ao controlo de concessão Conditional Access previsto

A política de exemplo da Microsoft seleciona os termos criados em Access controls > Grant > Grant access, começa em Report-only e passa para On depois de rever o impacto. O exemplo destina-se a Microsoft Admin Portals; adapte a atribuição de recursos ao seu cenário aprovado em vez de copiar esse destino para um piloto de espaço de trabalho sem relação com ele.

Comece pelo grupo piloto e pelo recurso previstos. Preserve o acesso de recuperação de emergência e documente as exclusões. O Learn também avisa que as contas de serviço não conseguem satisfazer este requisito de aceitação interativa; identifique essas dependências antes de ativar a imposição. Reveja primeiro o impacto em Report-only e depois ative o piloto para os testes interativos. Uma revisão de impacto e um teste de aceitação imposta respondem a perguntas diferentes, pelo que deve conservar ambos.

4. Testar a aceitação, a recusa e o percurso de recuperação excluído

Use identidades de teste que representem a população prevista. No percurso de aceitação, entre no recurso de destino pela sua via normal de início de sessão, verifique o PDF e o idioma apresentados, expanda o documento se necessário, aceite-o e verifique o acesso ao recurso. No percurso de recusa, use uma identidade sem aceitação anterior e verifique se a recusa impede o acesso. Mantenha estes resultados como resultados de teste esperados até os observar e registar.

Verifique os registos de aceitação com o utilizador de teste e o ID do ficheiro. Confirme também que a conta de recuperação planeada continua fora da política piloto. Se um utilizador previsto não receber nenhum pedido, investigue a aceitação existente, o estado da sessão, as atribuições, as exclusões e o recurso selecionado na política. Não conclua de imediato que o acordo está avariado ou que o utilizador está corretamente abrangido.

5. Manter as versões e testar quando ocorre a nova aceitação

Reveja Edit terms, atualize o PDF do idioma relevante e tome uma decisão explícita sobre Require reaccept. Preserve as provas anteriores antes de alterar o documento e depois verifique o registo de resposta relativo ao novo ficheiro. Trate os PDFs localizados como versões geridas da mesma mensagem aprovada; uma revisão do documento inglês deve desencadear a revisão das outras variantes linguísticas.

Require reaccept não interrompe instantaneamente uma sessão ativa. O Learn indica que as sessões existentes têm de expirar antes de o novo requisito de aceitação ser apresentado. Planeie a verificação em torno do próximo início de sessão relevante ou da próxima avaliação da sessão e registe esse contexto com o pedido observado. O guia de controlos de sessão e frequência de início de sessão explica por que razão uma política de acesso e o momento em que a sessão é avaliada devem ser considerados em conjunto. Não prometa um prazo imediato de nova aceitação para todo o tenant apenas porque um PDF foi atualizado.

6. Registar as provas e passar a manutenção

Conserve a referência do texto aprovado, os identificadores do acordo e da política, o âmbito, as exclusões, as versões dos PDFs e os resultados observados do piloto no registo da alteração. Registe as falhas e os percursos por resolver, bem como os sucessos. Expanda a política apenas depois de os responsáveis aceitarem as provas e as implicações para o suporte. Organize uma revisão quando o documento, a população da aplicação ou o modelo de colaboração mudar; o inventário de acordos, por si só, não revela desvios nessas relações.

Como o EtcSec deteta esta situação

O detetor AZ_NO_TERMS_OF_USE do etc-collector lê AzureTermsOfUseProbed e AzureTermsOfUseCount. A sua implementação Detect() tem três ramos:

Count 1 é a contagem do resultado; não é uma contagem de utilizadores que não aceitaram. O ramo não sondado não é um resultado de ausência nem um veredicto de conformidade. Uma recolha falhada deve permanecer visível até poder ser investigada.

Esta verificação estabelece apenas a existência de acordos. Não valida a ligação a Conditional Access, o estado ativado da política, a seleção de destinatários, as exceções, a qualidade do PDF, a cobertura de idiomas ou as aceitações dos utilizadores. Criar um acordo não utilizado pode eliminar este resultado específico sem impor o requisito de negócio. Combine o resultado do collector com a inspeção da política e as provas de aceitação acima, e conserve uma decisão explícita de adequação quando os termos de uso forem desnecessários para o tenant.