Bloqueio com beco sem saida

Nossa assinatura fde1c8c1-1268-48f0-a4fa-3c26dfac17bb recebeu duas atribuições de negação aplicadas pela própria plataforma, e agora toda operação de escrita falha com DenyAssignmentAuthorizationFailed. Leitura continua funcionando.

[UnusualActivity] Full Deny assignment on tenant at root added

[UNUSUALACTIVITY] FULL DENY ASSIGNMENT ON escopo: assinatura

As duas estão como isSystemProtected: true, então não consigo remover.

Confirmei o impacto com quatro testes: gravar etiqueta, validar implantação, criar grupo de recursos e excluir — todos negados. O diagnóstico automático da assinatura devolve "Completed diagnostics, no issues detected", ou seja, não é cobrança nem status de assinatura.

Por que não consigo abrir o chamado

É aqui que preciso de ajuda.

O assistente do portal me joga em artigos de FAQ e nunca oferece o botão de criar solicitação, independente da categoria que eu escolha.

O 0800 761 7454 é atendimento automático sem opção que leve a uma pessoa — só manda voltar ao site.

O 0800 761 0100 responde "o número chamado está desligado ou fora da área de cobertura".

E quando tento comprar um plano de suporte para abrir como caso técnico, o portal devolve "Ocorreu um erro. Tente novamente mais tarde" — o que faz sentido, porque contratar plano é operação de escrita, e escrita está bloqueada.

Ficou um círculo: preciso de plano pago para abrir chamado técnico, e não consigo comprar o plano porque a assinatura está travada.

O que provavelmente disparou a detecção

Somos uma empresa em processo de credenciamento junto à SUSEP, e nas últimas 72 horas fizemos um trabalho concentrado de hardening de segurança: ativação de oito planos do Defender for Cloud, trilhas de auditoria em doze aplicações web e sete cofres de chaves, retenção de registros elevada para 365 dias, bloqueio de acesso por chave compartilhada em sete contas de armazenamento, criação de grupos de segurança de rede e etiquetagem de 138 recursos para governança de custo.

Foram diversas operações administrativas em poucas horas — todas legítimas, todas pelo proprietário da assinatura, de um único endereço IP, executadas via Azure CLI. Entendo perfeitamente por que esse padrão parece conta comprometida.

Revisei o log de atividades das 72 horas completas: não há operação de origem desconhecida, não há tentativa de acesso por outro usuário, e não há operação destrutiva sem explicação. As únicas falhas registradas são posteriores à trava, e são meus próprios comandos de configuração sendo barrados.

Estando em um beco sem saída no Azure, abrimos 3 chamados no Office365 e fomos prontamente atendidos. Todos tentaram nos auxiliar, mas informaram que não há comunicabilidade entre produtos.

Então, após quase 48 horas sem acesso, um atendente conseguiu redirecionar nosso problema para a Azure.. O chamado chegou à Azure mas até hoje consta como OPEN, e o pior é que, com o bloqueio, sequer consigo clicar no chamado.

O pior é que o mecanismo automático aplica um bloqueio dessa magnitude e sequer recebemos qualquer contato da Azure. Simplesmente chutam o usuário para fora e sequer o notificam. Se fosse um ataque real, além de ser atacado, o cliente estaria derrubado do sistema sem ter o que fazer. Restando apenas sua preocupação sobre o que ocorreu.

O pior é que até mesmo esse canal, não tem uma opção de filho para preencher com algo relacionado. Estamos COMPLETAMENTE ABANDONADOS!

Já se vão 4 dias sem resposta e sem solução pela Azure. Estamos considerando cancelar nossa assinatura e migrar para outra nuvem mais responsável.

Que o chamado roteado para o time de Account Review / Security Review, ou que me indiquem um canal que funcione enquanto a escrita está bloqueada.

Isso está travando a preparação do nosso ambiente de produção, que tem prazo regulatório.