O controle de acesso baseado em funções (RBAC) é o model dominante de gerenciamento de acesso na TI empresarial. 94,7% das organizações já usaram RBAC em algum momento, e 86,6% ainda o consideram seu principal model de controle de acesso em 2026.1 No entanto, a maior parte do material publicado trata o RBAC como um framework teórico. Nós nos concentramos no que realmente aconteceu quando organizações reais o implementaram: 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 se tornara um passivo em vez de um controle.
Desafio: Gerenciamento Manual de Privilégios de Acesso
O banco reestruturou seu model de segurança em torno de três capacidades específicas do 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 consequente. O banco não tinha estrutura de herança, portanto cargos relacionados não carregavam relação implícita de permissão. Um gerente financeiro não podia acessar notas contábeis mensais sem pedir ao especialista contábil para recuperá-las. Após implementar a herança hierárquica de funções, o cargo do gerente financeiro herdou automaticamente as permissões relevantes do especialista contábil. A transferência manual desapareceu completamente.
Estrutura centralizada de políticas: 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 fizeram sua pilha de software crescer mais rápido do que seu model de governança de acesso.
Exemplo: Antes da implementação do RBAC, o gerente financeiro tinha que 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
O Interfaith Medical Center é um hospital comunitário de ensino com vários locais no Central Brooklyn, Nova York, com 287 leitos, 16 clínicas ambulatoriais e mais de 1.000 funcionários.
Desafio: Manter a Conformidade com a HIPAA
A HIPAA exige a definição de controles internos baseados em funções para os funcionários, a fim de proteger os dados eletrônicos de pacientes contra uso inadequado.
Os administradores do Interfaith Medical Center precisavam configurar manualmente o banco de dados para que somente 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 várias contas do Active Directory a fim de definir permissões específicas de usuário em uma única operação.
Gerenciamento de acesso centralizado: Os administradores garantiram que todo acesso à rede fosse feito por meio de login exclusivo do 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 com prazo determinado. O cirurgião recebe 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 das penalidades ajustados pela inflação agora são de $73,011 por violação para a maioria das categorias, com um teto anual de $2.190.294 para negligência intencional não corrigida, acima dos valores citados anteriormente.4 As organizações que citam tabelas de multas mais antigas da HIPAA em políticas internas devem atualizá-las.
3. Western Union
Empresa americana internacional de serviços financeiros com 5.000+ funcionários, com sede em Denver, Colorado.
Desafios Operar um identity warehouse centralizado: Os sistemas atuais da empresa não permitiam extrair dados de origem de vários aplicativos no identity warehouse, resultando em uma visão pouco clara dos controles de acesso dos usuários. Quando os gerentes solicitavam 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 administrando controles de acesso e reagindo a mudanças regulatórias era longo. Cada nova contratação exigia acesso a 7-10 aplicativos e permissões relacionadas. O acesso era concedido manualmente e levava ~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 ~750 aplicativos.
Visibilidade de rede aprimorada com um identity warehouse: 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 identity warehouse, permitindo total visibilidade dos privilégios de acesso dos usuários em um ambiente centralizado com 750+ aplicativos.
Gerenciamento robusto do banco de dados de usuários: A empresa afirma que a solução de gerenciamento de identidade baseado em funções simplificou o procedimento de provisionamento para departamentos que contratam novos funcionários com frequência. O provisionamento de 50 usuários agora leva 2.5 minutos, abaixo das 14 horas.5
Bancos e empresas de fintech agora tratam o RBAC como parte de um model de confiança zero com auditoria contínua.
4. Kubernetes na 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 documentando uma auditoria real da HIPAA ilustra isso claramente.6
O que aconteceu: O cluster passou na revisão documental. O RBAC estava tecnicamente habilitado. Mas a auditoria encontrou:
- Três namespaces configurados incorretamente
- Uma service account 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 gerado 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ários, criptografia em trânsito e em repouso. O RBAC do Kubernetes cobre o requisito de controle de acesso, mas não faz nada sozinho em relação à criptografia ou à completude da trilha de auditoria. 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 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 service accounts 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, como horário do dia, faixa de IP e status de MFA, o que move o AWS IAM para um 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 somente 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 privilégio mínimo dentro das restrições do RBAC.
Microsoft Entra ID + Azure RBAC
Azure RBAC é 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 em unidades de negócios. Abaixo está a assinatura, o principal limite de cobrança e acesso para a maioria das organizações. Dentro de uma assinatura estão 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 em si.
Microsoft’s Defender for Cloud introduziu Cloud Scopes e Unified RBAC, uma única camada agnóstica de nuvem que segmenta recursos e controla a visibilidade simultaneamente entre AWS, Azure e GCP.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
Google Cloud IAM é organizado em torno de uma hierarquia de recursos de quatro níveis. A organização fica no topo e corresponde à conta do Google Workspace ou Cloud Identity de uma empresa. É o nó raiz ao qual todos os recursos pertencem em última instância. Abaixo estão as pastas, que agrupam projetos relacionados e normalmente são 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 service accounts permitem referenciar todas as service accounts em um projeto, pasta ou organização em políticas de allow, deny e access, úteis para organizações que gerenciam grandes populações de service accounts. A autoconcessão de permissões ausentes a partir de mensagens de erro (GA em 27 de fevereiro 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 simplificadas de administrador, editor e visualizador, 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 o 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 tinha dificuldades para atribuir acesso aos registros de movimentação de mercadorias e transações.
CISO da VLI: “Temos ~9.000 funcionários que precisam usar vários sistemas para movimentar trens e precisamos de um sistema governado para melhor timing; os funcionários não podem esperar para ter acesso para descarregar o caminhão.”
Motoristas de caminhão e operadores de trem tinham que 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 grandes 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 a capacidade de 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
A maior empresa de mídia de capital doméstico da Austrália.
Desafio: Permissões de Controle de Acesso: Manter soluções personalizadas tornou-se uma carga enorme para a equipe técnica, pois não conseguiam gerenciar milhares de permissões de controle de acesso.
Solução e resultado: A Nine Entertainment criou um diretório unificado com sincronização em tempo real do AD e MFA para construir procedimentos padronizados de RBAC.12
Gerenciamento de acesso unificado: A empresa usa efetivamente 200+ conexões para fornecer acesso a 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 inserir códigos MFA; a autenticação ocorre sem atritos.
Exemplo: Com os recursos de gerenciamento de identidade e RBAC, a Nine Entertainment pôde detectar usuários fazendo login de qualquer local, como o home office. 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 Aplicativos 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.
Isto é 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ítica, 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 model híbrido. O RBAC trata das 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) trata das condições: horário do 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 nenhum dos dois.
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 forma diferente dos usuários humanos de maneiras que quebram as premissas centrais do RBAC:
- Identidades de máquina já superam em muito as humanas na maioria dos ambientes empresariais
- Os agentes mudam de estado dinamicamente. O mesmo agente que lida com tarefas rotineiras em um momento pode precisar de acesso elevado no momento seguinte
- Um agente que herda as permissões totais de um usuário (comum em implantações iniciais) cria excesso de privilégios 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 models 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 model para gerenciar o acesso de usuários a fim de proteger recursos como informações, aplicativos 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 “privilégio mínimo” é difícil: Os administradores não conseguem compreender as funções e permissões dos usuários. Talvez não identifiquem 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 uso indevido, causando acesso espelhado (o acesso de Bert aparecendo como o de Eva).
Demonstração de RBAC: Atribuindo 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 potenciais com os seguintes módulos:
Módulo de faturamento: Coleta pagamentos de seguradoras e pacientes por serviços médicos cobertos por códigos de faturamento odontológico.
Módulo de vendas: Permite que os consultórios odontológicos categorizem leads potenciais de acordo com a probabilidade de comprar um produto/serviço.
Configurando 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 permissões diferentes: “visualizar”, “editar”, “criar” e “excluir”.
Permissões do módulo de faturamento (somente gerente de faturamento):
- 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: Avaliando 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 de 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. Somente os jurados do concurso devem ver essas fotos. A política permite que qualquer entrada no cargo “travel_photo_judges” examine a foto “travel_photo1997.jpg”.
Isso é realizado por meio da avaliação do RBAC, que passa informações do grupo para o mecanismo de avaliação e determina se a entrada indicada na solicitação de permissão é membro do grupo.
2. Políticas de Controle de Acesso Exclusivas
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 do indivíduo, como “usuário convidado com permissões limitadas”.
3. Suporte no Nível de Aplicativo
O RBAC ajuda as empresas a ter uma abordagem de acesso granular ao dar suporte a permissões no nível do aplicativo.
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 models de RBAC constroem relacionamentos entre funções, permissões e usuários. Duas funções podem ser definidas como mutuamente exclusivas, de modo que o mesmo usuário não possa ter ambas (por exemplo, um usuário que cria pagamentos não pode também aprová-los). Isso impõe a separação de funções.
Exemplo: Quando uma permissão é definida, ela pode ser alocada a várias funções. Matt pode ter tanto a função administrativa quanto a de especialista financeiro, enquanto Eva pode ter apenas a função de especialista financeiro.
5. Demonstrando Conformidade
Implementar o 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 o 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 impulsionadores das 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 privilégio mínimo: 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. Aderir à 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 facilita rastrear e auditar quem tem acesso a quais recursos, permitindo melhor monitoramento e geração de relatórios.
Adicionar como fonte preferencialFuturo do RBAC
Em todos os setores, o RBAC deixou de ter:
Cargos estáticos: funções dinâmicas e baseadas em tarefas
Permissões permanentes: acesso temporário e contextual
Controle somente 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
- Top 10 Ferramentas de Microssegmentação
- Prevenção de Intrusões: Como funciona? & 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
4 atualizaçõesAdicionadas seções sobre RBAC do Kubernetes na saúde, RBAC dos provedores AWS, Azure e Google Cloud, e IA agêntica.
Expandida a seção "Exemplos Reais de RBAC" com três novos exemplos de empresas.
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.