Pós-Análise de Casos de Uso: Projetando Autorização Contínua para UI e API (Parte 1)
Descubra como o "pós-análise de casos de uso" pode revolucionar o design de autorização contínua para interfaces de usuário (UI) e APIs, focando na transição de modelos RBAC para ABAC e na implementação dos princípios Zero Trust.
MundiX News·03 de junho de 2026·8 min de leitura·👁 6 views
Atualmente, todo profissional de TI precisa dominar os fundamentos de segurança, e ignorar essa exigência não é mais uma opção. Ela se torna parte integrante de uma das principais tarefas do analista de sistemas: o projeto de interfaces. Demonstraremos, através de um exemplo, como novos requisitos de controle de acesso podem se tornar um sério problema arquitetônico em sua aplicação, solucionável com uma pequena ideia e artefatos de análise de sistemas.
A TI em segurança surgiu com as primeiras máquinas de computação industriais. Para se aprofundar na evolução das ACLs (Access Control Lists) para a segurança em sistemas distribuídos modernos, focando nas funções de identificação, autenticação e autorização, você pode consultar o canal do Telegram de Nikita "postanaliz". Aqui, nos concentraremos nos conceitos mais atuais: o modelo de autorização baseada em atributos (ABAC) e a filosofia de segurança Zero Trust.
Existem muitos artigos e vídeos sobre controle de acesso baseado em atributos, então, para relembrar, no momento de decidir sobre o acesso de um usuário, é necessário avaliar condições baseadas em atributos do sujeito, objeto e ambiente. O artigo apresentará exemplos de condições reais de controle de atributos, então não se preocupe se sentir que "nada" no tema – isso não impedirá a sua compreensão.
Por outro lado, o segundo "animal" pode não ser tão amplamente conhecido. A paradigma Zero Trust surgiu em 2010 e, sem ela, o já enorme número de vítimas de cibercrime hoje poderia ser várias vezes maior. A base da paradigma é a abordagem "Não confie em ninguém" e ela segue três princípios simples:
Verificação explícita de cada solicitação.
Princípio do menor privilégio.
Presunção de violação.
O primeiro princípio gera o conceito de verificação contínua – o uso de nossas funcionalidades de segurança para literalmente cada ação do usuário. O segundo princípio afirma que não se deve conceder ao usuário mais direitos do que ele precisa para trabalhar dentro de sua função de negócios, e isso requer um sistema de acesso flexível. E, finalmente, o terceiro princípio afirma que um invasor pode já estar dentro do seu sistema e precisa ser detectado antes que ocorra um dano crítico.
A quantidade de princípios utilizados pode variar dependendo da confidencialidade dos dados e da criticidade do sistema. Aqui, nos aprofundaremos na autorização contínua e a analisaremos no nível das interfaces do sistema – a principal área de responsabilidade dos analistas.
Contexto da Tarefa – Задачи (Tarefas)
Nosso holding de TI possui uma linha de produtos muito interessante, a IT4IT, ou, em termos simples, uma plataforma para desenvolvimento de software – Сфера (Esfera). Um dos produtos mais proeminentes nela é o sistema de gerenciamento de projetos (ou, popularmente, um rastreador de tarefas) – Сфера.Задачи (Esfera.Tarefas). Um dia, os desenvolvedores precisaram tirar do backlog e implementar um sistema de papéis flexível, que era solicitado por todos os consumidores. Foi a nós que coube a honra de ajudar essa equipe de produto com a análise de requisitos e a implementação da funcionalidade.
No contexto desta história, examinaremos como alcançar as condições para implementar os dois primeiros princípios do Zero Trust através da transição de um modelo de acesso rígido para um flexível. Falaremos detalhadamente sobre as dificuldades de construir uma autorização contínua ABAC para UI e API, e também sobre como a "pós-análise de casos de uso" nos ajudou com isso.
Antigo Modelo de Autorização
Um rastreador de tarefas é necessário, antes de tudo, para gerenciar tarefas de diferentes equipes, e para isso, ele possuía um modelo de papéis com duas funções de negócios principais:
Líder de equipe: responsável pela criação e arquivamento de tarefas, além de gerenciar o acesso ao espaço de trabalho da equipe.
Membro da equipe: pode gerenciar quaisquer tarefas nesse espaço.
À primeira vista, o modelo de acesso é RBAC, mas há uma dependência da equipe, e um membro podia editar desde que a tarefa não estivesse fechada. Essas restrições estão destacadas em laranja. Essencialmente, isso já é um ABAC simplificado: existem condições baseadas na verificação de atributos do sujeito (papel e equipe) e do objeto (equipe e status).
Não apenas os desenvolvedores, em sentido amplo, precisam de acesso aos dados das tarefas da equipe, mas também várias partes interessadas. No entanto, seus cenários de uso são limitados principalmente à visualização, e a edição está associada apenas a atributos específicos, sobre os quais falaremos mais adiante. E para dar a eles acesso, a única função mais ou menos adequada utilizada era a de "Membro da equipe". Este era o principal problema: um nível de acesso idêntico era concedido tanto a membros reais da equipe quanto a partes interessadas, o que violava claramente o segundo princípio do Zero Trust. Além disso, o modelo de papéis estava codificado e qualquer alteração exigia não a manipulação de configurações, mas um novo release.
Agora, vamos olhar a autorização em tal sistema, usando o exemplo de abrir um quadro Kanban (veja as figuras abaixo):
O usuário inicia a aplicação web, que primeiro solicita seu papel. Com base na resposta, o frontend decide quais elementos da interface mostrar e quais ocultar.
Ao solicitar dados para exibir a lista de tarefas, o backend filtra a resposta com base nas equipes às quais o usuário tem acesso.
Quando o usuário seleciona uma tarefa, é necessário exibir seu cartão detalhado. O frontend, com base nos papéis do sujeito e no status da tarefa, decide exibir o cartão em modo de leitura ou edição.
Ao alterar uma tarefa, a aplicação solicita ao backend a disponibilidade de tal operação.
É visível a autorização contínua: nenhuma ação do usuário ficou sem verificação. Essa abordagem pode ser classificada como lógica paralela, onde o frontend e o backend autorizam as ações do usuário de forma independente.
Modelo de Autorização Desejado
Como deveria ser o modelo de papéis ideal em nosso sistema de gerenciamento de projetos? Idealmente, para cada parte interessada, seria necessário criar um papel com um conjunto específico de permissões. Exemplos de regras de acesso necessárias:
Observe que agora as condições de acesso são definidas não para o objeto da tarefa, mas para seus atributos. Por exemplo, é necessário verificar o acesso não à edição da tarefa, mas à alteração de suas informações principais: status, comentários e muitos outros atributos individuais. Dados confidenciais que requerem atenção especial também são destacados.
No novo esquema, a tarefa, dependendo de seu estado, entra no contexto da parte interessada (relacionada a finanças, segurança da informação, etc.), e o acesso a ela por outros membros da equipe deve mudar. Além disso, pode-se permitir leitura, edição completa ou edição de apenas atributos específicos.
Aqui, exemplos interessantes e complexos de uso de ABAC já são claramente visíveis: existem regras separadas para os atributos da tarefa. Como alcançar isso do ponto de vista da autorização contínua?
Interface do Usuário e Autorização
O ABAC completo trouxe dificuldades. Foi necessária uma transição da verificação de papéis para a verificação de permissões, da autorização de ações com a tarefa para a autorização de operações com seus atributos individuais, tudo isso levando em conta o contexto da tarefa.
Foi necessário entender quais mudanças ocorreriam no frontend e no backend. Mas comparar tabelas e desenhar diagramas de sequência para cada caso parecia desproporcionalmente demorado. Nós, como Colombo, decidimos zarpar pelos mares da incerteza, onde nossas únicas bússolas eram os casos de uso!
Papel do Frontend e Backend no Antigo Modelo de Autorização
Extraímos os passos dos principais cenários de uso – criação, edição e arquivamento de uma tarefa – como um mapa de "caminhos do usuário". Tudo começa com a visualização de dados – obtemos uma lista de tarefas. Em seguida, o usuário cria uma tarefa: ele seleciona a equipe apropriada, preenche os atributos necessários e a salva. Ou o usuário pode encontrar uma tarefa e selecioná-la para visualização: aqui ele poderá editar atributos ou arquivar a tarefa, se ela estiver concluída.
A representação tabular e em quadros é responsável pela exibição e seleção de tarefas, e o trabalho detalhado com cada tarefa – edição, arquivamento – é realizado na representação em cartão.
Agora, adicionamos a condição de autorização a cada passo e determinamos qual é a zona de responsabilidade – frontend ou backend – destacando-as com suas próprias cores. A leitura de dados é uma clara responsabilidade do backend, os dados são filtrados de acordo com o nível de acesso. Mas a renderização de controles, a seleção da equipe e a exibição do cartão da tarefa em modo de leitura e edição, dependendo das permissões do usuário, já é trabalho do frontend. E, claro, salvar as alterações é uma tarefa do backend: ele verifica os direitos de acesso à operação sobre uma tarefa específica.
Papel do Frontend e Backend no Modelo de Autorização Desejado
Agora faremos as mesmas manipulações com a nova versão. Ao contrário da antiga, surgiram cenários de visualização e edição de atributos confidenciais. As principais mudanças afetaram o trabalho com o cartão da tarefa. Agora, parte dos atributos pode ser ocultada para leitura, dependendo das permissões do usuário. Por exemplo, a tarefa entrou no contexto de uma parte interessada e parte dos atributos se torna inacessível para membros comuns.
Mas e se esses atributos participaram da definição das condições de acesso? O frontend não poderá calcular as condições e atender aos requisitos corretos de autorização. Também não temos uma compreensão clara do número de papéis com possíveis condições para atributos. Estas são zonas de incerteza, vamos destacá-las em vermelho. É óbvio que o frontend terá dificuldade em manter a lógica sozinho nessas zonas. Por que não transferir isso para o backend? E ele conseguirá lidar com isso?
Como a autorização pode ser organizada neste caso: ao iniciar a aplicação web, o frontend envia uma solicitação para obter não os papéis do usuário, mas a configuração de visualização para ele. A resposta já leva em conta todas as suas permissões. Em seguida, o frontend solicita a lista de tarefas. E aqui há uma diferença: após o backend formar a lista de tarefas disponíveis, é necessário limpar adicionalmente os dados de cada tarefa para atributos inacessíveis para leitura. Quando o usuário seleciona uma tarefa, o frontend solicita novamente a configuração, mas desta vez, para o cartão da tarefa. Todos os atributos da tarefa são solicitados separadamente com filtragem subsequente, e ao alterar, o backend verifica o acesso não à tarefa, mas ao atributo.
Agora toda a lógica de autorização está destacada em vermelho. O frontend se torna mais simples, mas mais flexível para qualquer cenário. Essa abordagem pode ser chamada de orientada ao backend.
Pós-Análise de Casos de Uso para o Projeto de Autorização de Interface do Usuário
O que fizemos:
Agrupamos os casos de uso e criamos um diagrama de caminhos do usuário.
Visualizamos a autorização contínua, adicionando ao diagrama as condições de acesso para a execução da ação.
Definimos as zonas de responsabilidade pela autorização, experimentamos "leitura e salvamento de dados – backend, processo – frontend", avaliamos os riscos na zona de responsabilidade do frontend.
Comparamos as abordagens Parallel FE-BE e BE-driven.
Se houver riscos, é melhor usar BE-driven, ou até mesmo uma abordagem híbrida: uma das opções é aplicada dependendo de diferentes cenários ou telas.
Assim, realizamos a "pós-análise de casos de uso" para determinar a abordagem de autorização. Agora, mais detalhes sobre os riscos.
Identificação de Riscos na Zona do Frontend
Como detectar riscos de que o frontend pode não lidar com alguma condição? Se a autorização for por papéis ou permissões, não há problemas, mas se forem necessárias regras de acesso, olhamos para as condições. Requer cálculos complexos, funções? – esta é uma zona problemática. Mas regras simples também podem ser um problema para o frontend se ele não tiver dados suficientes para verificar, por exemplo, o backend não retornou atributos ocultos para leitura. Um indicador adicional é o número de atributos: se for indefinido e puder aumentar, é melhor escolher o backend.
Design de Autorização Contínua de Interface do Usuário
Na abordagem paralela, durante o projeto da interface do usuário, pode-se focar uma vez em obter acessos via API, e os requisitos para novas funcionalidades devem conter imediatamente a descrição das permissões necessárias (papéis, autorizações).
Na abordagem orientada ao backend, em cada elemento da interface, é preciso prever um comportamento diferente dependendo das configurações recebidas e, consequentemente, desenvolver uma API especial para obtê-las. Para novas funcionalidades, os requisitos vinculam as configurações às regras de acesso, e a API deve retornar não apenas os dados dos recursos em si, mas também informações sobre as ações disponíveis para o usuário com eles – integração direta no método de leitura ou um endpoint separado apenas para obter as ações disponíveis para o usuário com os objetos.
Com isso, a primeira parte termina, e na próxima falaremos sobre API.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Atualmente, todo profissional de TI precisa dominar os fundamentos de segurança, e ignorar essa exigência não é mais uma opção. Ela se torna parte integrante de uma das principais tarefas do analista de sistemas: o projeto de interfaces. Demonstraremos, através de um exemplo, como novos requisitos de controle de acesso podem se tornar um sério problema arquitetônico em sua aplicação, solucionável com uma pequena ideia e artefatos de análise de sistemas.
A TI em segurança surgiu com as primeiras máquinas de computação industriais. Para se aprofundar na evolução das ACLs (Access Control Lists) para a segurança em sistemas distribuídos modernos, focando nas funções de identificação, autenticação e autorização, você pode consultar o canal do Telegram de Nikita "postanaliz". Aqui, nos concentraremos nos conceitos mais atuais: o modelo de autorização baseada em atributos (ABAC) e a filosofia de segurança Zero Trust.
Existem muitos artigos e vídeos sobre controle de acesso baseado em atributos, então, para relembrar, no momento de decidir sobre o acesso de um usuário, é necessário avaliar condições baseadas em atributos do sujeito, objeto e ambiente. O artigo apresentará exemplos de condições reais de controle de atributos, então não se preocupe se sentir que "nada" no tema – isso não impedirá a sua compreensão.
Por outro lado, o segundo "animal" pode não ser tão amplamente conhecido. A paradigma Zero Trust surgiu em 2010 e, sem ela, o já enorme número de vítimas de cibercrime hoje poderia ser várias vezes maior. A base da paradigma é a abordagem "Não confie em ninguém" e ela segue três princípios simples:
Verificação explícita de cada solicitação.
Princípio do menor privilégio.
Presunção de violação.
O primeiro princípio gera o conceito de verificação contínua – o uso de nossas funcionalidades de segurança para literalmente cada ação do usuário. O segundo princípio afirma que não se deve conceder ao usuário mais direitos do que ele precisa para trabalhar dentro de sua função de negócios, e isso requer um sistema de acesso flexível. E, finalmente, o terceiro princípio afirma que um invasor pode já estar dentro do seu sistema e precisa ser detectado antes que ocorra um dano crítico.
A quantidade de princípios utilizados pode variar dependendo da confidencialidade dos dados e da criticidade do sistema. Aqui, nos aprofundaremos na autorização contínua e a analisaremos no nível das interfaces do sistema – a principal área de responsabilidade dos analistas.
Contexto da Tarefa – Задачи (Tarefas)
Nosso holding de TI possui uma linha de produtos muito interessante, a IT4IT, ou, em termos simples, uma plataforma para desenvolvimento de software – Сфера (Esfera). Um dos produtos mais proeminentes nela é o sistema de gerenciamento de projetos (ou, popularmente, um rastreador de tarefas) – Сфера.Задачи (Esfera.Tarefas). Um dia, os desenvolvedores precisaram tirar do backlog e implementar um sistema de papéis flexível, que era solicitado por todos os consumidores. Foi a nós que coube a honra de ajudar essa equipe de produto com a análise de requisitos e a implementação da funcionalidade.
No contexto desta história, examinaremos como alcançar as condições para implementar os dois primeiros princípios do Zero Trust através da transição de um modelo de acesso rígido para um flexível. Falaremos detalhadamente sobre as dificuldades de construir uma autorização contínua ABAC para UI e API, e também sobre como a "pós-análise de casos de uso" nos ajudou com isso.
Antigo Modelo de Autorização
Um rastreador de tarefas é necessário, antes de tudo, para gerenciar tarefas de diferentes equipes, e para isso, ele possuía um modelo de papéis com duas funções de negócios principais:
Líder de equipe: responsável pela criação e arquivamento de tarefas, além de gerenciar o acesso ao espaço de trabalho da equipe.
Membro da equipe: pode gerenciar quaisquer tarefas nesse espaço.
À primeira vista, o modelo de acesso é RBAC, mas há uma dependência da equipe, e um membro podia editar desde que a tarefa não estivesse fechada. Essas restrições estão destacadas em laranja. Essencialmente, isso já é um ABAC simplificado: existem condições baseadas na verificação de atributos do sujeito (papel e equipe) e do objeto (equipe e status).
Não apenas os desenvolvedores, em sentido amplo, precisam de acesso aos dados das tarefas da equipe, mas também várias partes interessadas. No entanto, seus cenários de uso são limitados principalmente à visualização, e a edição está associada apenas a atributos específicos, sobre os quais falaremos mais adiante. E para dar a eles acesso, a única função mais ou menos adequada utilizada era a de "Membro da equipe". Este era o principal problema: um nível de acesso idêntico era concedido tanto a membros reais da equipe quanto a partes interessadas, o que violava claramente o segundo princípio do Zero Trust. Além disso, o modelo de papéis estava codificado e qualquer alteração exigia não a manipulação de configurações, mas um novo release.
Agora, vamos olhar a autorização em tal sistema, usando o exemplo de abrir um quadro Kanban (veja as figuras abaixo):
O usuário inicia a aplicação web, que primeiro solicita seu papel. Com base na resposta, o frontend decide quais elementos da interface mostrar e quais ocultar.
Ao solicitar dados para exibir a lista de tarefas, o backend filtra a resposta com base nas equipes às quais o usuário tem acesso.
Quando o usuário seleciona uma tarefa, é necessário exibir seu cartão detalhado. O frontend, com base nos papéis do sujeito e no status da tarefa, decide exibir o cartão em modo de leitura ou edição.
Ao alterar uma tarefa, a aplicação solicita ao backend a disponibilidade de tal operação.
É visível a autorização contínua: nenhuma ação do usuário ficou sem verificação. Essa abordagem pode ser classificada como lógica paralela, onde o frontend e o backend autorizam as ações do usuário de forma independente.
Modelo de Autorização Desejado
Como deveria ser o modelo de papéis ideal em nosso sistema de gerenciamento de projetos? Idealmente, para cada parte interessada, seria necessário criar um papel com um conjunto específico de permissões. Exemplos de regras de acesso necessárias:
Observe que agora as condições de acesso são definidas não para o objeto da tarefa, mas para seus atributos. Por exemplo, é necessário verificar o acesso não à edição da tarefa, mas à alteração de suas informações principais: status, comentários e muitos outros atributos individuais. Dados confidenciais que requerem atenção especial também são destacados.
No novo esquema, a tarefa, dependendo de seu estado, entra no contexto da parte interessada (relacionada a finanças, segurança da informação, etc.), e o acesso a ela por outros membros da equipe deve mudar. Além disso, pode-se permitir leitura, edição completa ou edição de apenas atributos específicos.
Aqui, exemplos interessantes e complexos de uso de ABAC já são claramente visíveis: existem regras separadas para os atributos da tarefa. Como alcançar isso do ponto de vista da autorização contínua?
Interface do Usuário e Autorização
O ABAC completo trouxe dificuldades. Foi necessária uma transição da verificação de papéis para a verificação de permissões, da autorização de ações com a tarefa para a autorização de operações com seus atributos individuais, tudo isso levando em conta o contexto da tarefa.
Foi necessário entender quais mudanças ocorreriam no frontend e no backend. Mas comparar tabelas e desenhar diagramas de sequência para cada caso parecia desproporcionalmente demorado. Nós, como Colombo, decidimos zarpar pelos mares da incerteza, onde nossas únicas bússolas eram os casos de uso!
Papel do Frontend e Backend no Antigo Modelo de Autorização
Extraímos os passos dos principais cenários de uso – criação, edição e arquivamento de uma tarefa – como um mapa de "caminhos do usuário". Tudo começa com a visualização de dados – obtemos uma lista de tarefas. Em seguida, o usuário cria uma tarefa: ele seleciona a equipe apropriada, preenche os atributos necessários e a salva. Ou o usuário pode encontrar uma tarefa e selecioná-la para visualização: aqui ele poderá editar atributos ou arquivar a tarefa, se ela estiver concluída.
A representação tabular e em quadros é responsável pela exibição e seleção de tarefas, e o trabalho detalhado com cada tarefa – edição, arquivamento – é realizado na representação em cartão.
Agora, adicionamos a condição de autorização a cada passo e determinamos qual é a zona de responsabilidade – frontend ou backend – destacando-as com suas próprias cores. A leitura de dados é uma clara responsabilidade do backend, os dados são filtrados de acordo com o nível de acesso. Mas a renderização de controles, a seleção da equipe e a exibição do cartão da tarefa em modo de leitura e edição, dependendo das permissões do usuário, já é trabalho do frontend. E, claro, salvar as alterações é uma tarefa do backend: ele verifica os direitos de acesso à operação sobre uma tarefa específica.
Papel do Frontend e Backend no Modelo de Autorização Desejado
Agora faremos as mesmas manipulações com a nova versão. Ao contrário da antiga, surgiram cenários de visualização e edição de atributos confidenciais. As principais mudanças afetaram o trabalho com o cartão da tarefa. Agora, parte dos atributos pode ser ocultada para leitura, dependendo das permissões do usuário. Por exemplo, a tarefa entrou no contexto de uma parte interessada e parte dos atributos se torna inacessível para membros comuns.
Mas e se esses atributos participaram da definição das condições de acesso? O frontend não poderá calcular as condições e atender aos requisitos corretos de autorização. Também não temos uma compreensão clara do número de papéis com possíveis condições para atributos. Estas são zonas de incerteza, vamos destacá-las em vermelho. É óbvio que o frontend terá dificuldade em manter a lógica sozinho nessas zonas. Por que não transferir isso para o backend? E ele conseguirá lidar com isso?
Como a autorização pode ser organizada neste caso: ao iniciar a aplicação web, o frontend envia uma solicitação para obter não os papéis do usuário, mas a configuração de visualização para ele. A resposta já leva em conta todas as suas permissões. Em seguida, o frontend solicita a lista de tarefas. E aqui há uma diferença: após o backend formar a lista de tarefas disponíveis, é necessário limpar adicionalmente os dados de cada tarefa para atributos inacessíveis para leitura. Quando o usuário seleciona uma tarefa, o frontend solicita novamente a configuração, mas desta vez, para o cartão da tarefa. Todos os atributos da tarefa são solicitados separadamente com filtragem subsequente, e ao alterar, o backend verifica o acesso não à tarefa, mas ao atributo.
Agora toda a lógica de autorização está destacada em vermelho. O frontend se torna mais simples, mas mais flexível para qualquer cenário. Essa abordagem pode ser chamada de orientada ao backend.
Pós-Análise de Casos de Uso para o Projeto de Autorização de Interface do Usuário
O que fizemos:
Agrupamos os casos de uso e criamos um diagrama de caminhos do usuário.
Visualizamos a autorização contínua, adicionando ao diagrama as condições de acesso para a execução da ação.
Definimos as zonas de responsabilidade pela autorização, experimentamos "leitura e salvamento de dados – backend, processo – frontend", avaliamos os riscos na zona de responsabilidade do frontend.
Comparamos as abordagens Parallel FE-BE e BE-driven.
Se houver riscos, é melhor usar BE-driven, ou até mesmo uma abordagem híbrida: uma das opções é aplicada dependendo de diferentes cenários ou telas.
Assim, realizamos a "pós-análise de casos de uso" para determinar a abordagem de autorização. Agora, mais detalhes sobre os riscos.
Identificação de Riscos na Zona do Frontend
Como detectar riscos de que o frontend pode não lidar com alguma condição? Se a autorização for por papéis ou permissões, não há problemas, mas se forem necessárias regras de acesso, olhamos para as condições. Requer cálculos complexos, funções? – esta é uma zona problemática. Mas regras simples também podem ser um problema para o frontend se ele não tiver dados suficientes para verificar, por exemplo, o backend não retornou atributos ocultos para leitura. Um indicador adicional é o número de atributos: se for indefinido e puder aumentar, é melhor escolher o backend.
Design de Autorização Contínua de Interface do Usuário
Na abordagem paralela, durante o projeto da interface do usuário, pode-se focar uma vez em obter acessos via API, e os requisitos para novas funcionalidades devem conter imediatamente a descrição das permissões necessárias (papéis, autorizações).
Na abordagem orientada ao backend, em cada elemento da interface, é preciso prever um comportamento diferente dependendo das configurações recebidas e, consequentemente, desenvolver uma API especial para obtê-las. Para novas funcionalidades, os requisitos vinculam as configurações às regras de acesso, e a API deve retornar não apenas os dados dos recursos em si, mas também informações sobre as ações disponíveis para o usuário com eles – integração direta no método de leitura ou um endpoint separado apenas para obter as ações disponíveis para o usuário com os objetos.
Com isso, a primeira parte termina, e na próxima falaremos sobre API.
📤 Compartilhar & Baixar
📩 Newsletter MundiX
Receba novidades de cibersegurança + um checklist de pentest grátis. Sem spam.
Ao assinar você concorda em receber e-mails. Cancele quando quiser.
