O que autorização faz?
Torne cada decisão de acesso afetada explícita, aplique-a no limite real e prove tanto o comportamento permitido quanto o negado. Trabalhe dentro do fluxo solicitado; carregar esta habilidade não inicia uma auditoria de toda a aplicação. Use a identidade, política e proprietários de domínio existentes antes de introduzir um novo framework.
Definir a política
Leia as decisões de produto aceitas e os chamadores reais. Registre uma pequena matriz de política para o fluxo alterado: principal, operação, recurso, relacionamento/escopo/estado aplicável, campos de entrada/saída permitidos e resultado. Use funções, atributos, propriedade ou capacidades de acordo com a necessidade real; uma função sozinha pode não estabelecer acesso a um registro específico. Preserve permissões intencionalmente diferentes de leitura, escrita, exportação, compartilhamento e administração.
Separe a autenticação de identidade da permissão para agir. Obtenha identidade e concessões do contexto de sessão, token ou serviço confiável. IDs de solicitação, seletores de inquilino (tenant), campos de função e estado da interface selecionam ou descrevem uma solicitação; eles não conferem autoridade. O acesso anônimo/público pode ser explicitamente permitido ou com escopo de capacidade. Identidade ou escopo ausente não deve silenciosamente se tornar uma concessão global/de sistema. Mantenha operadores privilegiados e impersonificação explícitos e atribuíveis.
Padrão de acesso não correspondente para recusa e use a menor autoridade que satisfaça a política aceita. Uma permissão de negócios não decidida é uma questão de produto, não um convite para inventar um padrão permissivo. Continue o trabalho independente enquanto essa escolha não for resolvida. Mantenha uma demonstração deliberadamente local e não compartilhada distinta de um serviço que expõe dados protegidos reais.
Encontrar todos os caminhos de acesso afetados
Siga o recurso afetado através de seus pontos de entrada e proprietários reais. Inclua APIs web/mobile relevantes, carregadores renderizados no servidor, ações, importações, operações em lote, jobs e integrações. Inspecione pesquisa/contagem/exportação, arquivos, caches e assinaturas quando eles expõem os mesmos fatos protegidos. Leia Superfícies de acesso para esses caminhos ou para capacidades, delegação e revogação; selecione as seções aplicáveis.
Nomeie o proprietário da política e os pontos de aplicação. Centralize o significado da regra enquanto a aplica onde quer que dados ou efeitos cruzem limites de confiança. Uma verificação de login de middleware, proteção de interface, UUID ou leitura bem-sucedida anterior é insuficiente por si só. Uma política de framework, política de banco de dados ou proprietário com escopo pode funcionar; verifique sua configuração real e credenciais de tempo de execução em vez de assumir que cobre rotas de bypass.
Aplicar a decisão
Para leituras, restrinja a população de recursos autorizados antes que os resultados saiam do limite confiável e restrinja os campos retornados. Aplique política equivalente a objetos relacionados e representações alternativas. Use a política de divulgação do produto para recursos ausentes versus proibidos; erros, contagens e props serializadas também podem revelar fatos protegidos.
Para mutações, valide a ação, o alvo e os relacionamentos resultantes, incluindo chaves estrangeiras fornecidas pelo usuário e campos protegidos. Use campos de entrada permitidos em vez de vincular uma solicitação inteira a uma entidade durável. Onde um intercalamento alcançável pode invalidar a autoridade, aplique escopo, associação ou estado no efeito usando o guarda atômico ou serialização apropriada do armazenamento. Filhos acoplados e efeitos colaterais seguem a mesma admissão. Mantenha um proprietário completo existente; não adicione outro escritor de negócios meramente para inserir verificações de autorização.
Defina quando as concessões são avaliadas e quando uma alteração entra em vigor. Acesso atual, atribuição histórica imutável e uma obrigação durável previamente aceita são contratos diferentes. Replays, entrega atrasada e jobs delegados precisam de uma autoridade/tempo de vida explícito; nem alegações de usuário obsoletas nem uma identidade de sistema genérica respondem a essa pergunta. Aplique revogação e recuperação de acordo com esse contrato sem cancelar silenciosamente obrigações válidas ou ampliar seu público.
Provar o limite
Derive um pequeno conjunto de testes discriminatórios da matriz de política. Através do proprietário real e do limite montado relevante, mostre um ator válido completando a operação e recusas significativas: outro proprietário no mesmo inquilino (tenant), outro inquilino, uma função mais fraca, capacidade anônima/malformada ou concessão alterada quando aplicável. Use registros de destino reais e iscas explícitas; afirme campos protegidos, efeitos duráveis inalterados e registros não relacionados. Selecione casos relevantes em vez de ensaiar toda combinação teórica.
Uma política simulada retornando verdadeiro ou falso não prova nem sua decisão nem a restrição de consulta/escrita. Teste predicados reais ou políticas de armazenamento com autoridade de tempo de execução realista. Para reivindicações de acesso de interface, verifique uma solicitação direta independentemente da visibilidade do botão. Não investigue identidades de outras pessoas ou dados compartilhados/ao vivo; use fixtures autorizadas isoladas. Separe descobertas estáticas, verificações propostas, testes executados e lacunas de política de implantação.
Entregue a política, fontes autoritativas, caminhos afetados, aplicação e prova, mais escolhas de produto não resolvidas ou configuração externa. Uma verificação aprovada é limitada a esses caminhos; o procedimento não certifica a segurança geral da aplicação.