O controle de acesso baseado em funções (RBAC) é o modelo dominante de gerenciamento de acesso na TI corporativa. 94.7% das organizações já usaram RBAC em algum momento, e 86.6% ainda o consideram seu principal modelo de controle de acesso em 2026.1 No entanto, a maior parte do material publicado trata o RBAC como uma estrutura teórica. Nós nos concentramos no que realmente aconteceu quando organizações reais o implantaram: os problemas específicos que enfrentaram, as configurações que escolheram e os resultados que mediram.
Também abordamos onde o RBAC está atingindo seus limites, especialmente com IA agêntica, ambientes multinuvem e obrigações de conformidade mais rígidas sob as regras atualizadas da HIPAA e a Diretiva NIS2 da UE.
Exemplos reais de RBAC
1. Dresdner Bank
Um grande banco europeu com 368 funções de trabalho distintas e mais de 1.300 funções organizacionais chegou a um ponto em que seu gerenciamento de acesso havia se tornado um risco, e não um controle.
Desafio: Gerenciamento manual de privilégios de acesso
O banco reestruturou seu modelo de segurança em torno de três capacidades específicas de RBAC que antes não possuía:
Agrupamento demográfico e departamental: Antes do RBAC, os únicos eixos de classificação eram função, hierarquia e unidade organizacional. O RBAC permitiu que o banco atribuísse permissões com base em um conjunto mais amplo de atributos sem criar uma nova função para cada combinação.
Herança de funções: Essa foi a mudança mais significativa. O banco não tinha estrutura de herança, portanto títulos de cargos relacionados não carregavam relação implícita de permissão. Um gerente financeiro não podia acessar as notas contábeis mensais sem pedir ao especialista contábil que as recuperasse. Após implementar a herança hierárquica de funções, o cargo do gerente financeiro herdava automaticamente as permissões relevantes do especialista contábil. A transferência manual desapareceu completamente.
Estrutura de políticas centralizada: Substituir arquivos de permissão no nível do aplicativo por uma camada unificada de políticas RBAC deu aos administradores um único ponto de revisão para auditorias.
Por que isso importa para outras organizações: A experiência do banco não é incomum. A proliferação de permissões no nível do aplicativo é comum em organizações que cresceram sua pilha de software mais rapidamente do que seu modelo de governança de acesso.
Exemplo: Antes da implementação do RBAC, o gerente financeiro precisava pedir ao especialista contábil para editar as notas contábeis mensais. Agora o gerente financeiro acessa as notas contábeis mensais diretamente, pois o cargo herda a função de especialista contábil.2
2. Interfaith Medical Center
Organização educacional de saúde comunitária multi-site sediada nos EUA, com 50.659 funcionários e 1.459 filiais em todo o mundo.
Desafio: Manter a conformidade com a HIPAA
A HIPAA exige o estabelecimento de controles internos baseados em funções para que os funcionários protejam os dados eletrônicos de pacientes contra uso indevido.
Os administradores do Interfaith Medical Center precisavam definir manualmente a configuração do banco de dados para que apenas funcionários autorizados (codificadores médicos, gerentes de saúde) tivessem acesso aos dados dos pacientes.
Solução e resultado: Os administradores de TI usaram recursos de gerenciamento em massa para criar, remover e editar inúmeras contas do Active Directory para definir permissões específicas de usuário em uma única operação.
Gerenciamento de acesso centralizado: Os administradores garantiram que todo acesso à rede seja por meio de login exclusivo de cada funcionário e não compartilhado.
Gerenciamento automatizado de RBAC: Após a implementação do controle de acesso baseado em funções em massa, a empresa afirma que pode gerenciar com confiança 1.000+ objetos de usuário, 750+ caixas de correio e 850+ estações de trabalho com dois DBAs e cinco especialistas de help desk. 3
Muitos hospitais agora combinam RBAC com acesso limitado no tempo. O cirurgião obtém acesso elevado apenas durante a janela programada da operação; depois, as permissões são revertidas automaticamente.
Para violações da HIPAA avaliadas em ou após 28 de janeiro de 2026, os valores máximos de multa ajustados pela inflação agora são de US$ 73.011 por violação para a maioria dos níveis, com um teto anual de US$ 2.190.294 para negligência intencional não corrigida, acima dos valores citados anteriormente.4 As organizações que citam tabelas de multas antigas da HIPAA em políticas internas devem atualizá-las.
3. Western Union
Empresa americana internacional de serviços financeiros com mais de 5.000 funcionários, com sede em Denver, Colorado.
Desafios Operar um armazém de identidades centralizado: Os sistemas atuais da empresa não permitiam extrair dados de origem de inúmeros aplicativos no armazém de identidades, resultando em uma visão pouco clara dos controles de acesso dos usuários. Quando os gerentes solicitavam a correção de acesso, precisavam passar pelo sistema de tickets; no entanto, o sistema não atualizava efetivamente o perfil do usuário.
Administração demorada dos controles de acesso: O tempo gasto na administração dos controles de acesso e na reação às mudanças regulatórias era longo. Cada nova contratação exigia acesso a 7-10 aplicativos e permissões relacionadas. O acesso era fornecido manualmente e levava cerca de 20 minutos por pessoa para enviar a solicitação de acesso e receber a aprovação de primeiro nível.
A empresa esperava ver quem tem acesso a quais programas, serviços e arquivos e como avaliar se esse acesso está em conformidade com a política de segurança.
Solução e resultado: A Western Union migrou para uma plataforma de gerenciamento de identidade e acesso (IAM) com recursos de RBAC para cerca de 750 aplicativos.
Visibilidade de rede aprimorada com um armazém de identidades: A Western Union começou a coletar todos os dados de identidade baseados em funções necessários dos sistemas de RH em um único armazém de identidades, permitindo visibilidade total dos privilégios de acesso dos usuários em um ambiente centralizado com mais de 600 aplicativos.
Gerenciamento robusto de banco de dados de usuários: A empresa afirma que a solução de gerenciamento de identidades baseado em funções simplificou o procedimento de provisionamento para departamentos que contratam novos funcionários rotineiramente. O provisionamento de 50 usuários agora leva 2.5 minutos, abaixo dos 14 minutos.5
Bancos e fintechs agora tratam o RBAC como parte de um modelo de confiança zero com auditoria contínua.
4. Kubernetes na área da saúde
Habilitar o RBAC no Kubernetes e realmente aplicá-lo são duas coisas diferentes. Um relato de março de 2026 de um profissional de saúde que documentou uma auditoria real da HIPAA ilustra isso claramente.6
O que aconteceu: O cluster passou na revisão de documentação. O RBAC estava tecnicamente habilitado. Mas a auditoria encontrou:
- Três namespaces configurados incorretamente
- Uma conta de serviço com acesso cluster-admin que ninguém da equipe lembrava ter criado
- Dados de pacientes trafegando sem criptografia entre dois serviços internos
Nada foi violado. Mas as três constatações foram falhas de auditoria, e qualquer uma delas poderia ter produzido um incidente reportável.
A questão estrutural: A Regra de Segurança da HIPAA exige salvaguardas técnicas específicas, controles de acesso, trilhas de auditoria, identificação exclusiva de usuário, criptografia em trânsito e em repouso. O RBAC do Kubernetes cobre o requisito de controle de acesso, mas não faz nada quanto à criptografia ou à completude da trilha de auditoria por si só. As equipes que marcam “RBAC habilitado” em uma lista de conformidade sem mapear cada salvaguarda técnica para uma configuração específica do cluster não estão em conformidade; estão apenas documentadas.
Clusters Kubernetes em conformidade com a HIPAA mapeiam o RBAC para o padrão de mínimo necessário: usuários humanos vinculados a grupos do provedor de identidade via OIDC/SSO com MFA, ClusterRoles reservados para tarefas inevitáveis do plano de controle, RoleBindings com escopo de namespace como padrão e contas de serviço apenas para cargas de trabalho.7
5. Plataformas de nuvem: como AWS, Azure e Google Cloud estruturam o RBAC na prática
Os três principais provedores de nuvem implementam, cada um, uma variante do RBAC, mas as diferenças de arquitetura importam na prática.
AWS IAM
O AWS IAM atribui permissões por meio de políticas anexadas a identidades (usuários, grupos, funções) ou recursos. As funções são o mecanismo recomendado para acesso entre serviços e entre contas. O controle refinado está disponível por meio de condições de política: hora do dia, faixa de IP e status de MFA, o que move o AWS IAM em direção ao comportamento baseado em atributos, mantendo o RBAC como a estrutura organizacional.
Como funciona na prática: Uma função de desenvolvedor em uma conta de produção pode ter acesso somente leitura ao S3 e ao CloudWatch, com acesso de gravação restrito a uma função de implantação separada, assumida apenas durante a execução do pipeline de CI/CD. Separar a função permanente do desenvolvedor das permissões elevadas de implantação é a aplicação do menor privilégio dentro das restrições do RBAC.
Microsoft Entra ID + Azure RBAC
O RBAC do Azure é construído em torno de uma hierarquia de escopo de quatro níveis. No topo está o grupo de gerenciamento, que abrange várias assinaturas e é normalmente usado por grandes empresas para aplicar políticas entre unidades de negócios. Abaixo dele está a assinatura, o principal limite de cobrança e acesso para a maioria das organizações. Dentro de uma assinatura ficam os grupos de recursos, contêineres lógicos para recursos relacionados, como um aplicativo web, seu banco de dados e sua conta de armazenamento. Na base da hierarquia estão os recursos individuais propriamente ditos.
O Defender for Cloud da Microsoft introduziu Cloud Scopes e Unified RBAC, uma única camada agnóstica de nuvem que segmenta recursos e controla a visibilidade entre AWS, Azure e GCP simultaneamente.8 Isso substitui o padrão anterior, em que organizações que gerenciam ambientes multinuvem precisavam manter definições de funções separadas e não interoperáveis por provedor. Para equipes de segurança que executam ambientes híbridos, essa é uma mudança operacional relevante.
Google Cloud IAM
O IAM do Google Cloud é organizado em torno de uma hierarquia de recursos de quatro níveis. A organização fica no topo e mapeia para a conta do Google Workspace ou Cloud Identity de uma empresa. É o nó raiz ao qual todos os recursos pertencem em última instância. Abaixo dela estão as pastas, que agrupam projetos relacionados e são normalmente usadas para espelhar a estrutura interna: unidades de negócios, equipes ou ambientes como produção e staging. Os projetos ficam dentro das pastas e atuam como o principal limite para gerenciamento de recursos, cobrança e controle de acesso. Os recursos individuais, instâncias do Compute Engine, buckets do Cloud Storage e datasets do BigQuery ficam na base.
Os conjuntos de principais de contas de serviço permitem referenciar todas as contas de serviço em um projeto, pasta ou organização em políticas de permissão, negação e acesso, úteis para organizações que gerenciam grandes populações de contas de serviço. A autoconscessão de permissões ausentes a partir de mensagens de erro (GA em fevereiro de 27 de 2026) reduz o atrito da depuração de permissões.9
No Google Cloud Next ’26, o Google também anunciou um catálogo simplificado de funções predefinidas com funções de administrador, editor e visualizador simplificadas, um seletor de funções do IAM e a capacidade de exigir reautenticação para ações confidenciais.10
6. VLI
Provedor de logística ferroviária no Brasil. Gerencia sistema ferroviário, 100 locomotivas, mais de 6.000 vagões, com 8.000 funcionários e 1.000 contratados.
Desafio: Controles de acesso complexos na cadeia de suprimentos: A empresa teve dificuldades para atribuir acesso aos registros de movimentação de mercadorias e transações.
CISO da VLI: “Temos cerca de 9.000 funcionários que precisam usar vários sistemas para mover trens, e precisamos de um sistema governado para melhor tempo; os funcionários não podem esperar para ter acesso para descarregar o caminhão.”
Motoristas de caminhão e operadores de trem precisavam entrar continuamente nos sistemas para obter informações e transações como parte de sua rotina de carga, o que atrasava o processo e reduzia a produtividade. Apesar da presença de vastas equipes de TI e desenvolvimento, não havia mecanismo para detectar ou rastrear indivíduos privilegiados que acessavam os servidores da VLI.11
Solução e Resultado: A VLI migrou para uma plataforma centralizada de controle de acesso de usuários.
Gerenciamento rápido de acesso de usuários: A VLI alcançou capacidade para dar aos usuários certos acesso aos recursos relevantes no momento certo. Reduziu o tempo de resposta das solicitações de acesso de 5 dias para segundos.
Servidores protegidos: Protegeu os servidores removendo a exigência de informações de login autorizadas compartilhadas.
Risco reduzido de ataques de malware e ransomware: Limitou o número de usuários não administradores com acesso administrativo nos endpoints e configurou listas de aplicativos confiáveis e não confiáveis e instruções, minimizando o risco de ataques cibernéticos.
7. Nine Entertainment
Maior empresa de mídia de capital nacional da Austrália.
Desafio: Permissões de Controle de Acesso: A manutenção de soluções personalizadas tornou-se uma carga enorme para a equipe técnica, pois não conseguiram gerenciar milhares de permissões de controle de acesso.
Solução e Resultado: A Nine Entertainment criou um diretório unificado com sincronização de AD em tempo real e MFA para criar procedimentos padronizados de RBAC.12
Gerenciamento de acesso unificado: A empresa usa efetivamente mais de 200 conexões para fornecer acesso a mais de 50 aplicativos e vários sites WordPress com base em permissões personalizadas.
Controles de autenticação aprimorados: Com a implementação do software, os usuários da Nine Entertainment não precisam mais digitar códigos MFA; a autenticação ocorre sem problemas.
Exemplo: Com o gerenciamento de identidades e os recursos de RBAC, a Nine Entertainment pôde detectar usuários fazendo login de qualquer local, como o escritório em casa. Se o usuário precisar se inscrever com autenticação baseada em identidade, ele é orientado por um procedimento de inscrição de autoatendimento baseado em assistente.
8. SaaS e aplicações multi-inquilino: o problema da explosão de funções
Plataformas de suporte ao cliente, ferramentas de gerenciamento de projetos e CRMs SaaS representam um desafio distinto de RBAC.
Isso é gerenciável com quatro funções. O problema surge quando as equipes começam a acomodar exceções.
Isso é uma explosão de funções. É um modo de falha estrutural do RBAC, não um caso extremo. Acontece especificamente quando as organizações tentam codificar variações de políticas, condições, exceções e contexto em nomes de funções, em vez de em um mecanismo de políticas projetado para lidar com eles.
Como as organizações lidam com isso:
A solução prática é um modelo híbrido. O RBAC lida com as funções básicas de cargo que são estáveis e bem definidas. O ABAC (Controle de Acesso Baseado em Atributos) ou o PBAC (Controle de Acesso Baseado em Políticas) lida com as condições: horário de acesso, integridade do dispositivo, nível de classificação dos dados e localização geográfica.
9. RBAC e IA agêntica: o problema estrutural de 2026
O RBAC tradicional foi projetado para usuários humanos com identidades estáveis e padrões de acesso previsíveis. Os agentes de IA não são nem um nem outro.
Na RSAC 2026, o CEO da Oasis Security, Danny Brickman, descreveu a questão central: “Um agente é tão bom quanto o acesso que lhe é concedido. Um agente sem acesso basicamente não significa nada. Um agente com acesso total aos dados da sua empresa tem todo o valor potencial dado à organização.”13
O problema não é simplesmente que os agentes de IA precisam de funções. É que eles operam de maneira diferente dos usuários humanos de formas que quebram as premissas centrais do RBAC:
- As identidades de máquina já superam em muito as humanas na maioria dos ambientes corporativos
- Os agentes mudam de estado dinamicamente. O mesmo agente que lida com tarefas rotineiras em um momento pode precisar de acesso escalado no seguinte
- Um agente que herda todas as permissões de um usuário (comum em implantações iniciais) cria privilégios excessivos herdados em escala
- O log de auditoria mostra a identidade do agente, não a identidade do usuário de origem, quebrando a responsabilização
A IANS Research identificou as soluções do Model Context Protocol (MCP) como o padrão de integração específico em que as atuais estruturas de autenticação e autorização estão criando exposição real.14
A resposta do setor está migrando para modelos de acesso baseados em intenção e just-in-time: permissões temporárias e de escopo restrito provisionadas quando necessário e revogadas automaticamente, em vez de funções permanentes que um agente mantém continuamente.15
O que é RBAC?
O controle de acesso baseado em funções (RBAC) é um modelo para gerenciar o acesso de usuários para proteger recursos como informações, aplicações e sistemas contra acesso não autorizado.
Figura 1: Atribuições de funções do controle de acesso baseado em funções
Problemas sem RBAC
Aplicar o princípio do “menor privilégio” é difícil: Os administradores não conseguem compreender as funções e permissões dos usuários. Podem não identificar o menor grau de acesso que um funcionário precisa para realizar tarefas.
A integração leva mais tempo: As permissões de usuários recém-contratados são enviadas caso a caso por meio de formulários específicos.
Mudanças de cargo são complexas: controlar o acesso de pessoas que mudam de cargo exige solicitações de ajuste individualizadas.
Risco de acesso não autorizado: Pode envolver mau uso, causando acesso espelhado (o acesso de Bert aparecendo como o de Eva).
Demonstração de RBAC: Atribuição de funções e permissões
Considere um consultório odontológico que assina um produto SaaS para administrar e promover serviços de saúde a clientes em potencial com os seguintes módulos:
Módulo de cobrança: Coleta pagamentos de seguradoras e pacientes por serviços médicos cobertos por códigos de cobrança odontológica.
Módulo de vendas: Permite que os consultórios odontológicos categorizem leads em potencial de acordo com a probabilidade de comprar um produto/serviço.
Configuração de permissões
Os administradores do consultório odontológico usam a interface do usuário do software para atribuir acesso de permissão a várias funções de negócios.
Usando opções de arrastar e soltar, os administradores criam diferentes permissões: “visualizar”, “editar”, “criar” e “excluir”.
Permissões do módulo de cobrança (somente gerente de cobrança):
- visualizar: billing_codes
- visualizar: customer_ID
- criar: invoice
Permissões do módulo de vendas (gerente de vendas):
- visualizar: sales_database
- criar: sales_database
- editar: sales_database
- excluir: sales_database
Após definir as permissões, o administrador cria a função “gerente de vendas” e atribui essas permissões a essa função, limitando o acesso de outros funcionários ao banco de dados de vendas.
Figura 2: Avaliação das políticas de RBAC para o “sales_manager” com elementos de interface do usuário (UI)
Figura 3: Exemplo de como o arquivo data.json pode parecer para as funções “billing_manager” e “sales_manager”:
5 benefícios do RBAC
1. Acesso excessivo limitado
Com a transição para a infraestrutura em nuvem, aplicativos SaaS e logon único (SSO), indivíduos e grupos frequentemente herdam funções com acesso excessivo. O RBAC reduz esse risco definindo grupos e subgrupos para que os usuários tenham acesso apenas ao que precisam.
Exemplo: Os usuários enviam imagens para um concurso das melhores fotos de viagem. Apenas os jurados do concurso devem ver essas fotos. A política permite que qualquer entrada na posição “travel_photo_judges” examine a foto “travel_photo1997.jpg.”
Isso é feito por meio da avaliação de RBAC, que passa as informações do grupo ao mecanismo de avaliação e determina se a entrada indicada na solicitação de permissão é membro do grupo.
2. Políticas exclusivas de controle de acesso
Os sistemas RBAC fornecem políticas de controle de acesso mais granulares, adaptadas às necessidades de uma empresa, do que os sistemas de mainframe.
Exemplo: Os administradores de sistemas RBAC empregam funções para fins administrativos, restringindo o acesso à rede com base na função de um indivíduo, como “usuário convidado com permissões limitadas”.
3. Suporte no nível da aplicação
O RBAC ajuda as empresas a ter uma abordagem de acesso granular, suportando permissões no nível da aplicação.
Exemplo: O RBAC pode atribuir um conjunto de permissões em um programa de escrita que permite aos usuários ler, editar e excluir conteúdo.
4. Alocação flexível de funções
Os modelos RBAC constroem relações entre funções, permissões e usuários. Duas funções podem ser mutuamente exclusivas, permitindo que um único usuário tenha duas funções. As funções podem herdar permissões fornecidas a outras funções.
Exemplo: Quando uma permissão é definida, ela pode ser alocada a várias funções. Matt pode ter tanto funções administrativas quanto de especialista financeiro, enquanto Eva pode ter apenas a função de especialista financeiro.
5. Demonstração de conformidade
A implementação do RBAC ajuda instituições financeiras e prestadores de serviços de saúde a demonstrar conformidade com padrões técnicos e operacionais, incluindo HIPAA, PCI e PHI.
Por que usar RBAC?
O acesso não autorizado à rede representou 40% das intrusões cibernéticas de terceiros em 2023. Considerando que o acesso não autorizado é um dos principais causadores de violações de dados, estabelecer o RBAC é fundamental, especialmente para empresas com vários funcionários.
1. Segurança aprimorada
Risco minimizado de acesso não autorizado: Ao atribuir permissões com base em funções e não em indivíduos, é mais fácil garantir que os usuários tenham acesso apenas às informações e aos recursos necessários para suas funções.
Aplicar o princípio do menor privilégio: Os usuários recebem o nível mínimo de acesso necessário para realizar seus trabalhos, reduzindo o risco de violações internas de dados e exposição a informações confidenciais.
2. Gerenciamento simplificado
Facilidade de administração: Os administradores podem atribuir e gerenciar facilmente as permissões dos usuários por função, em vez de gerenciá-las individualmente.
Escalabilidade: À medida que as organizações crescem, novos usuários são rapidamente atribuídos a funções predefinidas, simplificando o processo de integração e garantindo políticas consistentes de controle de acesso.
3. Risco reduzido de erros
Controle centralizado: O gerenciamento centralizado de funções reduz o risco de erro humano na atribuição de permissões e garante que as políticas de acesso sejam aplicadas de forma consistente.
Responsabilização clara: É mais fácil com o RBAC determinar a responsabilidade e a prestação de contas pelo acesso a recursos confidenciais.
4. Aderência à conformidade
Conformidade regulatória: O RBAC ajuda as organizações a cumprir vários requisitos regulatórios, garantindo que o acesso a dados confidenciais seja controlado e documentado.
Trilhas de auditoria: A natureza baseada em funções do controle de acesso torna mais fácil rastrear e auditar quem tem acesso a quais recursos, facilitando melhor monitoramento e geração de relatórios.
Adicionar como fonte preferencialFuturo do RBAC
Em todos os setores, o RBAC mudou de:
Cargos estáticos: funções dinâmicas baseadas em tarefas
Permissões permanentes: acesso temporário e contextual
Controle apenas humano: governança de identidade humana e de IA
O RBAC não se trata mais apenas de “quem pode fazer login”. Trata-se de quem pode agir, quando e sob quais condições, com cada ação rastreável.
Leitura adicional
- As 10 principais ferramentas de microssegmentação
- Prevenção de intrusões: como funciona? e 3 métodos
- Soluções de gerenciamento de políticas de segurança de rede (NSPM)
Cite esta pesquisa
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem},
title = {{9 exemplos reais de RBAC}},
year = {2026},
month = may,
howpublished = {\url{https://aimultiple.com/rbac-examples}},
note = {AIMultiple. Acessado em 26 Maio 2026}
}Registro de alterações
3 atualizações- 2026
Expandida a seção "Exemplos Reais de RBAC" com três novos exemplos de empresas.
- 2025
Removidas as fontes baseadas em dados da seção "Por que usar RBAC?".
Adicionada uma seção de demonstração RBAC.
Links de referência
O trabalho de Cem na AIMultiple foi citado por publicações globais líderes, incluindo Business Insider, Forbes, Morning Brew e Washington Post, por empresas globais como Deloitte e HPE, ONGs como o World Economic Forum e organizações supranacionais como a European Commission. [1], [2], [3], [4], [5]
Ao longo de sua carreira, Cem atuou como consultor de tecnologia, comprador de tecnologia e empreendedor de tecnologia. Ele aconselhou empresas sobre suas decisões de tecnologia na McKinsey & Company e na Altman Solon por mais de uma década. Ele também publicou um relatório da McKinsey sobre digitalização.
Ele liderou a estratégia de tecnologia e as compras de uma operadora de telecomunicações, reportando-se ao CEO. Ele também liderou o crescimento comercial da empresa de deep tech Hypatos, que atingiu uma receita recorrente anual de 7 dígitos e uma avaliação de 9 dígitos partindo do zero em 2 anos. O trabalho de Cem na Hypatos foi coberto por publicações de tecnologia líderes como TechCrunch e Business Insider.
Cem fala regularmente em conferências internacionais de tecnologia. Ele se formou como engenheiro da computação pela Bogazici University e possui um MBA pela Columbia Business School.
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.