Privacidade Entra: URL do tenant e testes de convidados

O que uma declaração de privacidade Entra disponibiliza

A privacidade Entra é apresentada através de uma declaração ligada ao nível da organização: um documento que explica como a sua organização trata os dados das pessoas. Configure essa ligação juntamente com um contacto de privacidade atualizado, para que os funcionários e os convidados externos encontrem as informações que lhes são destinadas. O resultado útil é um documento legível e relevante, com um responsável contactável, em vez de um campo preenchido que ninguém testou.

O guia de configuração das informações de privacidade da Microsoft abrange tanto o contacto global de privacidade como o URL da declaração. Descreve a sua utilização para funcionários internos e convidados externos, incluindo a experiência de convite B2B. Quando nenhum dos dois é fornecido, o Learn ilustra uma mensagem em Review Permissions que indica que a organização não disponibilizou ligações para consulta. Considere essa apresentação um motivo para examinar o percurso real do convidado, sem a interpretar como uma afirmação de que os convites são bloqueados.

Decida quem é responsável pelo documento antes de alterar o tenant. Um parceiro que recebe um convite pode precisar de informações diferentes das que constam do manual interno dos funcionários. Peça aos responsáveis pela revisão de privacidade e jurídica que confirmem o âmbito e o idioma do documento. A ausência de um URL no tenant é uma observação de configuração; não estabelece uma infração jurídica universal nem determina as obrigações aplicáveis à sua organização.

Como as informações de privacidade diferem da aceitação de documentos

O recurso privacyProfile do Graph separa contactEmail de statementUrl. Ambas as propriedades são opcionais no esquema. O endereço de email identifica o contacto da declaração de privacidade, enquanto o URL aponta para a declaração da organização. Um campo opcional da API pode continuar a ser útil para os seus requisitos operacionais; o facto de ser opcional não decide se a organização precisa dessas informações.

O Learn define um URL da declaração que começa por HTTP ou HTTPS. Numa nova implementação, escolha um destino HTTPS estável e teste-o a partir das populações que o vão ler. Um documento disponível apenas após a autenticação de funcionários pode ser inadequado para um colaborador externo recém-convidado. Evite assumir que a capacidade de um administrador abrir a página prova que um convidado consegue aceder-lhe.

Publicar esta ligação disponibiliza informações. Não configura um controlo de concessão de Conditional Access que exija aceitação, não cria um registo de aceitação nem prova que alguém leu o texto. O guia de termos de uso Entra e aceitação com Conditional Access aborda esse requisito distinto: é necessário associar um acordo aprovado a uma política que o imponha quando a aceitação é a condição de acesso pretendida.

Deteção: verificar a configuração, o destino e a apresentação aos convidados

Ler o perfil da organização com acesso adequado ao Graph

Comece por confirmar o tenant que está a analisar. No Entra admin center, examine Entra ID > Overview > Properties, incluindo o contacto global de privacidade e o URL da declaração de privacidade. Conserve a hora da observação e os valores exatos, para comparar o portal com uma leitura independente da API.

A documentação de List organization da Microsoft suporta GET /organization e o parâmetro de consulta $select. Utilize este pedido para obter o perfil:

GET https://graph.microsoft.com/v1.0/organization?$select=privacyProfile
Authorization: Bearer {token}

Este é um modelo de pedido para o seu cliente autorizado, não uma consulta executada num tenant de cliente para este artigo. Examine tanto privacyProfile.contactEmail como privacyProfile.statementUrl na organização devolvida. Guarde a resposta e os erros de recolha com o registo da revisão; não substitua um resultado da API por uma captura de ecrã do portal quando estiver a investigar o comportamento da recolha.

A documentação de leitura da organização indica Organization.Read.All para acesso de aplicação e suporta essa permissão para acesso delegado com contas profissionais ou escolares. Adverte especificamente que User.Read expõe apenas id, displayName e verifiedDomains, devolvendo null nas outras propriedades. Utilize pelo menos Organization.Read.All para ler o perfil de privacidade e verifique os requisitos de função suportados para um cliente delegado. Uma resposta bem-sucedida com visibilidade insuficiente das propriedades não deve tornar-se prova de ausência.

Testar o destino independentemente da consulta Graph

Uma consulta concluída à organização e um documento de privacidade disponível são observações diferentes. Registe o URL exato devolvido e, em seguida, efetue um pedido HTTP independente para esse destino. Para uma declaração pública autorizada, um pedido de diagnóstico pode ter este formato:

curl --location --silent --show-error --output privacy-statement.html --write-out 'HTTP %{http_code}\nFinal URL %{url_effective}\n' 'https://example.org/privacy'

Substitua o exemplo pelo destino aprovado. Analise a resposta final e o corpo guardado, em vez de aceitar apenas o código de estado. Uma resposta bem-sucedida pode conter uma página inicial genérica, um formulário de início de sessão ou um documento sem relação com o tema. Verifique os redirecionamentos, a organização identificada no texto e se a página explica o tratamento de dados pretendido. Examine-a também num navegador, incluindo a navegação e a legibilidade.

Teste o acesso num contexto de funcionário e num contexto externo representativo do fluxo de convite. Se o destino exigir autenticação, determine se esse requisito é intencional e viável antes de o convidado aderir. Registe uma página indisponível, um redirecionamento inesperado, um documento desatualizado ou um idioma inadequado como um problema do destino, mesmo quando o campo do tenant está preenchido. Confirme separadamente que o contacto indicado é monitorizado e está atribuído a um responsável.

Percorrer um convite B2B representativo

Utilize um convite de teste aprovado e observe a experiência real do convidado. Verifique a organização apresentada, as informações de privacidade disponibilizadas, o destino alcançado ao seguir a ligação e o contacto mostrado. Registe o contexto do convidado e o percurso utilizado, uma vez que o regresso de um convidado existente a uma aplicação não reproduz a experiência de um novo convite.

A revisão de Conditional Access para convidados e colaboração externa ajuda a enquadrar a população externa pretendida e as suas definições de acesso. Mantenha essa revisão de acesso junto desta verificação das informações. Uma ligação de privacidade funcional não estabelece que os convites de convidados, as atribuições de políticas, o acesso às aplicações ou as definições de ciclo de vida cumprem os seus requisitos.

Observação	Provas a conservar	O que demonstra
Leitura autorizada do Graph	Contexto do tenant, resposta, hora, erros	Valores do perfil de privacidade recolhidos
Pedido independente ao destino	Estado, URL final, corpo analisado	O que o destino devolveu nesse contexto de teste
Revisão no navegador e do convite	Contexto, informações apresentadas, navegação observada	Apresentação e usabilidade no percurso testado
Responsabilidade pelo contacto e documento	Responsáveis e decisão de manutenção	Quem vai tratar das perguntas e alterações

Correção: publicar e manter um URL utilizável no tenant (Remediation)

1. Atribuir responsáveis pelo documento e pelo contacto

Identifique o responsável pela revisão da declaração e a equipa responsável por responder a questões de privacidade. Acorde os públicos de funcionários e convidados pretendidos, os idiomas e o local de publicação. Forneça ao administrador do tenant valores aprovados para introdução. Não deixe o administrador inventar o texto de privacidade apenas para eliminar um resultado da auditoria.

Utilize um endereço de contacto com um processo explícito de passagem de responsabilidade quando o pessoal muda. Decida quem verifica as mensagens recebidas e quem resolve uma ligação de documento quebrada. Registe onde o documento aprovado é mantido e como as alterações ao seu âmbito são revistas. Estas são decisões operacionais a tomar localmente, não conclusões jurídicas extraídas da definição do tenant.

2. Validar o destino antes de configurar o Entra

Publique a declaração aprovada num URL estável. Verifique se os leitores internos e externos pretendidos conseguem aceder ao conteúdo relevante e se os idiomas suportados continuam acessíveis a partir desse destino. Mantenha a página compreensível sem exigir que um convidado navegue numa biblioteca de documentos exclusiva dos funcionários.

Registe o teste do destino separadamente da alteração ao tenant. Se o sistema de publicação redirecionar a ligação, examine o destino final e assegure que os redirecionamentos futuros continuam sob o controlo do responsável pelo documento. Um URL permanente da organização é mais fácil de manter do que uma ligação associada a uma campanha temporária, a um espaço de trabalho pessoal ou a um token de partilha com prazo de validade.

3. Introduzir os valores em Properties

Siga o procedimento de Properties do Learn: inicie sessão pelo menos como Billing Administrator, navegue para Entra ID > Overview > Properties, introduza Global privacy contact e Privacy statement URL e selecione Accept, conforme documentado. Essa ação no portal guarda as informações da organização; não representa a aceitação do seu documento por um convidado.

Se o processo de alteração aprovado utilizar antes o Graph, Update organization documenta PATCH /organization/{id} com Organization.ReadWrite.All para acesso delegado com contas profissionais ou escolares e acesso de aplicação. Utilize o ID da organização verificado e examine os requisitos de função delegada antes de escrever. Envie os valores de perfil pretendidos sem alterar propriedades da organização que não estão relacionadas:

PATCH https://graph.microsoft.com/v1.0/organization/{organization-id}
Authorization: Bearer {token}
Content-Type: application/json

{
  "privacyProfile": {
    "contactEmail": "[email protected]",
    "statementUrl": "https://example.org/privacy"
  }
}

O exemplo é um padrão de pedido documentado com valores de exemplo, não uma alteração executada no tenant. Mantenha as permissões de escrita separadas do cliente de revisão apenas de leitura. Uma resposta de atualização bem-sucedida é um ponto de partida para a verificação, não a prova final de que as pessoas conseguem utilizar o documento.

4. Voltar a ler o perfil e repetir o teste do convidado

Repita o GET da organização com a seleção de propriedades e compare ambas as propriedades com os valores aprovados. Volte a verificar o destino de forma independente e repita depois a revisão do convite representativo. Conserve as falhas e as observações bem-sucedidas. Se o perfil for diferente, investigue o contexto do tenant e o resultado da atualização antes de repetir uma escrita.

Se as informações estiverem configuradas, mas o percurso do convidado testado não as apresentar como esperado, conserve as provas da API e a apresentação observada como factos separados. Investigue esse percurso em vez de substituir repetidamente um URL correto. Evite adicionar um requisito de termos de uso como correção improvisada para informações de privacidade em falta; a aceitação precisa do seu próprio objetivo e âmbito aprovados.

5. Manter os idiomas, as ligações e a responsabilidade

Reveja a declaração quando houver alterações no tratamento de dados, no alojamento do documento, nas populações de convidados ou na responsabilidade pelo contacto. Atualize as traduções juntamente com o documento de origem aprovado. Após uma migração de alojamento, repita as verificações HTTP e no navegador, mesmo que o URL do tenant permaneça inalterado. Depois de uma passagem de responsabilidade pelo contacto, verifique se o endereço continua a chegar à equipa responsável.

Mantenha juntos os valores aprovados, a releitura do Graph, as verificações do destino, as observações dos convidados e as decisões dos responsáveis. Isto permite distinguir desvios de configuração de uma falha de publicação ou de uma alteração na experiência de convite. Defina uma periodicidade de revisão adequada à sua organização, em vez de tratar a primeira gravação bem-sucedida como prova permanente.

Como o EtcSec deteta esta situação

O detetor AZ_NO_PRIVACY_STATEMENT do etc-collector lê AzurePrivacyStatementProbed e AzurePrivacyStatementURL. A sua implementação de Detect() tem três ramos:

Estado recolhido	Resultado real do detetor	Interpretação
`AzurePrivacyStatementProbed` é false	Resultado Info, Count 1	Não determinável: esta auditoria não consultou o perfil; examine `audit.warnings` e os pré-requisitos de recolha.
Consultado e `AzurePrivacyStatementURL != ""`	`nil`, sem resultado	A cadeia de caracteres recolhida não está vazia.
Consultado e o URL está vazio	Resultado Low, Count 1	A recolha concluída não forneceu um URL da declaração.

Count 1 é a contagem do resultado, não uma contagem de convidados afetados. Não consultado não significa ausente, e o ramo Info não é um veredito de conformidade. Resolva as falhas de recolha antes de tirar uma conclusão sobre a configuração.

O provider efetua GET /organization?$select=privacyProfile, lê o statementUrl da primeira organização e devolve uma cadeia vazia sem erro quando a lista de organizações está vazia ou o perfil está ausente. Os erros de pedido e de descodificação são devolvidos separadamente. Um inventário inesperadamente vazio merece, por isso, investigação em conjunto com as permissões e o contexto do tenant.

Nem o provider nem este detetor removem espaços da cadeia: os espaços em branco são considerados não vazios e passam na comparação. Nenhum dos dois efetua um pedido ao URL da declaração, verifica o contacto ou analisa o conteúdo ou os idiomas do documento. O provider não recolhe contactEmail para esta verificação. Um URL não vazio pode eliminar este resultado enquanto o destino está indisponível ou inadequado. Associe este resultado limitado de configuração aos testes independentes do destino e do convite descritos acima e conserve a decisão do responsável pelo documento sobre a sua adequação.