Como Implementamos o Controle de Acesso na Plataforma Sber
Descubra como a Sber desenvolveu um sistema robusto de gerenciamento de acesso (SUD) para sua Plataforma de Cibersegurança (PKB), lidando com uma vasta gama de dados e serviços. O artigo detalha a arquitetura, os desafios e as soluções implementadas para garantir a segurança e a eficiência.
MundiX News·08 de julho de 2026·10 min de leitura·👁 1 views
Nossa equipe está desenvolvendo um serviço de gerenciamento de acesso (SUD) em uma das maiores plataformas da Sber – a Plataforma de Cibersegurança (PKB). Esta plataforma processa todos os dados do Banco relacionados à cibersegurança e abriga inúmeros produtos e serviços voltados para o combate à fraude interna e externa, proteção de infraestrutura, monitoramento e análise de diversas ameaças. Para um entendimento mais aprofundado sobre a PKB, consulte o artigo "Plataforma Analítica de Cibersegurança. Experiência Sber" na Kibraia da Sber. Lá, você também encontrará informações sobre como nosso serviço se integra à plataforma.
Neste artigo, apresentarei uma visão geral da arquitetura do serviço, suas tarefas, o que já alcançamos, o que ainda precisamos fazer e os motivos por trás disso. Nosso serviço opera em um ambiente heterogêneo complexo, que inclui não apenas software desenvolvido internamente, mas também produtos open source como Apache Flink e MLFlow para funcionalidades diversas, e Apache Hadoop, Ozone e Clickhouse para gerenciamento de dados. O SUD deve atender a vários requisitos cruciais:
Integração com o ecossistema bancário: Deve se alinhar com o cenário geral do banco, respeitando os requisitos regulatórios de diversos níveis.
Usabilidade e Inovação: Proporcionar um gerenciamento de acesso conveniente na plataforma, introduzindo novidades que sejam úteis para todos os consumidores, inclusive nos produtos open source utilizados.
Centralização: Unificar a autenticação, autorização, atribuição e controle de acessos na plataforma.
Reutilização: Ser adaptável para uso em outras plataformas e sistemas automatizados.
As operações do SUD podem ser categorizadas em áreas específicas do domínio "Gerenciamento de Acesso e Identificação": modelo de acesso, gerenciamento do modelo de acesso a recursos, atribuição de acessos a usuários, identificação e autenticação, autorização, e controle, auditoria e relatórios. A "Modelo de Acesso" é destacada como um item separado, pois constitui a base para todas as customizações e processos de gerenciamento de acesso.
O SUD realiza a identificação e autenticação de usuários integralmente através de mecanismos bancários globais, sem armazenar quaisquer fatores de autenticação dos usuários. No entanto, o modelo de acesso é um pouco mais complexo. A principal ferramenta para gerenciar o acesso de usuários no banco é a "função" (role), que não é decomposta. Inicialmente, nosso serviço também utilizava apenas o conceito de "função". Vamos analisar como isso funcionava.
Na ilustração, as áreas em cores e números indicam as funcionalidades em que o serviço de gerenciamento de acesso da PKB operava inicialmente. Cada equipe de serviço da PKB define sua própria modelagem de acesso baseada em funções, a protege durante os testes de aceitação de cada release e envia as funções para o SUD (1a). Todas as funções de todos os serviços são agregadas e, mediante solicitação, repassadas ao serviço bancário global de gerenciamento de contas de usuário, que chamaremos de userIDM (1b), utilizando o protocolo SCIM. No userIDM, uma função pode ser atribuída a um usuário mediante solicitação aprovada (2a). Essas informações são sincronizadas com o serviço bancário global de autenticação e transmitidas via protocolo SCIM para o SUD (2b), que armazena a associação usuário-função em seu banco de dados. O usuário interage com os serviços da PKB através de um gateway de autenticação baseado no Platform V IAM Proxy. Para isso, o usuário deve se autenticar utilizando o protocolo OpenID Connect, com o auxílio do serviço bancário global de autenticação (3a–3d). Após a autenticação, a sessão do usuário é enriquecida com um ID token no formato JWT, que é então recebido pelo serviço da PKB invocado pelo usuário. Em seguida, o serviço consulta o SUD via REST API, solicitando as funções do usuário, cujo identificador foi obtido no ID token. Com base nas funções recebidas, o serviço implementa o controle de acesso do usuário, determinando se o acesso a uma determinada seção do serviço é permitido ou não.
Modelo de Acesso
Dado que o banco utiliza um modelo baseado em funções, somos obrigados a empregar funções, mas com a capacidade de expandi-las significativamente. Um dos padrões mais conhecidos que descreve o uso de modelos baseados em funções para controle de acesso é o ANSI INCITS 359-2012 "Role Based Access Control". Adotamos o componente "Core RBAC" (Modelo de Referência RBAC) e expandimos as funções para incluir o uso de privilégios dentro delas (nossas denominações diferem ligeiramente do padrão, mas a essência permanece a mesma). Uma função pode conter múltiplos privilégios, e um privilégio é um acesso nomeado a um recurso, descrito pela associação de um nome de recurso a um conjunto de permissões de acesso a ele. Essa decomposição de funções permite que o SUD armazene, essencialmente, políticas de controle de acesso e ofereça uma visão mais completa dos acessos dos usuários aos recursos dos serviços da plataforma.
Outras definições do padrão, como a hierarquia de funções (Hierarchical RBAC), ainda não são utilizadas, ou dependemos de processos bancários globais que controlam, inclusive, a separação estática de funções (Static Separation of Duties). Cada serviço da PKB mantém seu próprio modelo de funções dentro do SUD, com os espaços de serviço completamente isolados uns dos outros. No entanto, como os serviços na plataforma interagem entre si, para simplificar a obtenção de acessos dentro da plataforma, expandimos nosso modelo de funções para incluir "privilégios publicados". Estes, criados em um serviço da PKB, podem ser utilizados nas funções de outro serviço. Qualquer modelo de funções existe independentemente dos recursos reais, pois o SUD, por exemplo, não sabe quais recursos reais uma privilégio com o recurso "*" concede acesso, que geralmente é interpretado como acesso a todos os recursos. Por isso, introduzimos no SUD o conceito de "recurso físico". Recursos físicos são informações sobre os recursos reais existentes em um serviço da PKB, como um banco de dados, uma tabela ou até mesmo uma coluna de tabela. Essa informação é frequentemente chamada de modelo físico. Consequentemente, nosso modelo de funções se torna mais rico em informações, e o chamamos de modelo de acesso, em vez de modelo de funções. Graficamente, ele pode ser representado da seguinte forma:
No entanto, este modelo de acesso permanece estático; na maioria dos casos, quando um novo recurso físico é introduzido, o usuário não obtém acesso automático a ele. É necessário solicitar, obtendo uma nova função. O problema da velocidade na concessão de acessos se torna particularmente evidente com o uso massivo de aprendizado de máquina e agentes de IA. Para mitigar isso, estamos atualmente explorando os conceitos de Controle de Acesso Baseado em Relacionamentos (Relationship-based Access Control – ReBAC) e Controle de Acesso Baseado em Atributos (Attribute-based Access Control – ABAC).
Gerenciamento do Modelo de Acesso a Recursos
Conceitualmente, o Serviço de Gerenciamento de Acesso (SUD) é responsável por gerenciar todos os modelos de acesso na plataforma. Para isso, dispomos de dois canais de modificação de modelos: a API REST de gerenciamento do SUD e solicitações através da interface gráfica do SUD. A API de gerenciamento possui métodos específicos para criar ou modificar permissões, recursos, privilégios e funções, além de publicar privilégios. Para diferentes usos, existem métodos para atualização completa, parcial ou incremental das entidades (adição sem modificação ou exclusão). O serviço utiliza a API do SUD ao introduzir uma nova versão do modelo de acesso no processo de desenvolvimento em produção, com customizações no próprio serviço. O novo modelo de acesso é testado em diversos ambientes e aprovado pelas unidades interessadas antes de ser implementado. Contudo, alguns serviços da PKB precisam modificar o modelo de acesso sem novos releases, por exemplo, ao alterar os acessos dos usuários aos dados. Nesses casos, é possível utilizar solicitações de modificação do modelo de acesso, onde funcionários designados podem editar o modelo na mesma interface do SUD e, após obter todas as aprovações necessárias, aplicá-lo automaticamente ao ambiente de produção. Uma solicitação desse tipo no SUD pode ter a seguinte aparência:
A solicitação pode ser formulada com base no conhecimento dos recursos físicos do serviço. Nesse cenário, após selecionar o recurso físico e as permissões de acesso a ele, a solicitação gera automaticamente os recursos e privilégios que serão incluídos na função especificada.
Atualmente, o SUD oferece várias maneiras de obter informações sobre recursos físicos:
Via API: Qualquer serviço da PKB pode enviar seu modelo físico para o SUD, incluindo atributos ou relacionamentos, como identificadores de proprietários de recursos.
Importação de outros serviços da PKB: Informações sobre recursos físicos podem ser importadas de outros serviços da PKB, como o serviço de gerenciamento de metadados.
Importação dos próprios serviços: Informações sobre recursos físicos podem ser importadas diretamente dos serviços, como dados sobre bancos de dados e tabelas Hive do Metastore, ou diretórios HDFS.
Interface Gráfica do SUD: Planejamos introduzir informações sobre recursos físicos através da interface gráfica do SUD.
O atributo principal dos recursos físicos atualmente é a informação do proprietário, mas já calculamos outros atributos, como a categoria de confidencialidade das informações no Hadoop. Para isso, o SUD acessa o serviço Hive, lê pequenas amostras de dados das tabelas e determina o nível de confidencialidade usando um serviço interno da PKB baseado em algoritmos e inteligência artificial. Esses atributos podem ser utilizados futuramente na aplicação dos princípios ReBAC e ABAC nos modelos de acesso.
O SUD gerencia modelos de acesso não apenas para os serviços desenvolvidos na PKB, mas também para produtos open source utilizados na PKB. Por exemplo, ele é integrado ao Apache Ranger e ao freeIPA. O modelo de acesso aos serviços do Apache Hadoop é gerenciado no SUD; após a execução de uma solicitação de modificação do modelo, ele é automaticamente ou manualmente convertido em uma política de acesso do Apache Ranger e repassado a ele, sendo então distribuído para todos os nós de serviço Hadoop necessários. Outra opção é o uso da interface LDAP no SUD para transferir permissões de acesso para produtos como Grafana ou Platform V Search.
Atribuição de Acessos a Usuários
As funções de usuário no SUD são divididas em duas classes: básica e aplicada. As funções básicas são atribuídas através do serviço bancário global de gerenciamento de contas de usuário (IDM) e transmitidas para o SUD via protocolo SCIM. As funções aplicadas não concedem nenhum acesso sem as funções básicas; o usuário pode solicitá-las em seu portal pessoal ("Meu Perfil") no SUD. Somente após a aprovação do proprietário do serviço e, se necessário, dos proprietários dos recursos aos quais a função concede acesso, o usuário receberá a função aplicada solicitada.
Estamos em processo de desenvolvimento desta funcionalidade, planejando adicionar visibilidade para solicitação de funções aplicadas com base em departamentos, bem como a separação estática de funções. Nosso objetivo é automatizar ao máximo a concessão de acesso aos usuários, utilizando relacionamentos (como o de proprietário de recurso) e atributos.
Identificação e Autenticação
Após as etapas de formação e atribuição de acessos, passamos para o processo de login do usuário nos serviços da PKB utilizando o Serviço de Gerenciamento de Acesso. Primeiramente, é necessário identificar e autenticar as requisições de entrada no gateway de autenticação, que faz parte do Serviço de Gerenciamento de Acesso. Como mencionado anteriormente, o gateway é construído sobre o Platform V IAM Proxy. Para cada serviço da PKB, uma ramificação separada é criada no IAM Proxy, sob a qual opera sua interface gráfica. O usuário pode ser autenticado de diversas maneiras, dependendo, inclusive, do nível de confidencialidade dos dados processados no serviço da PKB. Por exemplo, para muitos serviços, utilizamos autenticação de dois fatores via aplicativo móvel com confirmação de login por senha de uso único ou resposta a uma notificação push.
Atualmente, não temos planos de expandir a funcionalidade nesta área, pois acreditamos que a solução atual atende a todas as necessidades da PKB. Nosso foco aqui é em alta disponibilidade, balanceamento, controle de tráfego e aspectos similares.
Autorização
Autorização (ou o ato de conceder acesso) é a atribuição de direitos de acesso a um sujeito, bem como a concessão de acesso de acordo com as regras de gerenciamento de acesso estabelecidas (GOST R 58833-2020 Proteção da Informação. Identificação e Autenticação. Disposições Gerais. Item 3.50).
Como já dito, o próprio produto autoriza o usuário com base nas informações recebidas do SUD via REST API. Como não encontramos padrões estabelecidos para esse tipo de API no momento de seu projeto, criamos nosso próprio formato. As chamadas da API de autorização são projetadas para que o serviço possa fazer diferentes tipos de requisições. Por exemplo: "Este usuário tem tal permissão para tal recurso?". Nesse caso, o SUD atua como um PDP (Policy Decision Point), fornecendo uma resposta sobre a possibilidade de acesso.
Requisição:
GET /user/access/resource/is?system_id=mms&user_id=1102787&resource_name=resource1&permission_id=READ
Resposta:
{
"has_permission": true
}
Ou outra pergunta: "Quais funções este usuário possui?". Nesse caso, o SUD atua mais como um PIP (Policy Information Point), que compila uma política de acesso aplicável a este usuário, e o próprio serviço atua como PDP: ele calcula se o usuário tem acesso ao recurso.
Independentemente de onde o acesso é calculado (PDP), a decisão de acesso é aplicada pelo próprio serviço da PKB, atuando como um PEP (Policy Enforcement Point).
No caso de um serviço open source de produto, como Grafana ou Platform V Search, utilizamos a API LDAP do SUD para autorização. Através dela, determinamos os privilégios dos usuários – na notação LDAP, eles são chamados de grupos aos quais o usuário pertence (neste caso, o SUD atua como PIP). Em seguida, com base nesses grupos, a política local do serviço determina as possibilidades de acesso do usuário a uma determinada funcionalidade (o produto executa as funções de PDP e PEP).
Existem serviços open source na plataforma que não possuem capacidade nativa de controle de acesso de usuários, como Apache Flink ou MLFlow. A autorização de acesso de usuários a esses serviços ocorre no gateway de autorização, construído sobre o Apache KNOX. Ele obtém os privilégios do usuário, correspondentes aos seus grupos no LDAP do SUD, e verifica a possibilidade de acesso do usuário aos serviços atrás do gateway usando um plugin Ranger, que armazena e atualiza a política de acesso recebida do Apache Ranger. Nesse cenário, o núcleo do SUD executa as funções de PIP, e o gateway de autorização baseado em KNOX atua como PDP e PEP.
Atualmente, a arquitetura do Serviço de Gerenciamento de Acesso se apresenta da seguinte forma:
No entanto, esta não é a arquitetura final. Como mencionado anteriormente, aprimoraremos o serviço para incorporar os conceitos de ReBAC e ABAC, o que deve alterar a arquitetura, pois o principal desafio a ser superado é a performance. Nesse caso, será necessário calcular os acessos a cada requisição com base em novos valores de atributos ou relacionamentos de entidades de acesso modificados. Portanto, distribuiremos o cache, pré-calcularemos políticas de acesso e assim por diante, o que, esperamos, trará soluções interessantes que compartilharei com vocês futuramente.
Em suma, ao longo de vários anos de desenvolvimento, o SUD evoluiu de um serviço que agregava funções de usuários para uma plataforma completa de gerenciamento de acesso. Ela integra modelos de acesso de outros serviços, oferece diversas opções de modificação, garante autorização centralizada, integra-se com soluções corporativas e open source, adapta-se a novos desafios tornando-se um subsistema de acesso para agentes de IA, e gradualmente se transforma em um ponto único de controle de acesso na PKB.
🛡️⚡
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
Nossa equipe está desenvolvendo um serviço de gerenciamento de acesso (SUD) em uma das maiores plataformas da Sber – a Plataforma de Cibersegurança (PKB). Esta plataforma processa todos os dados do Banco relacionados à cibersegurança e abriga inúmeros produtos e serviços voltados para o combate à fraude interna e externa, proteção de infraestrutura, monitoramento e análise de diversas ameaças. Para um entendimento mais aprofundado sobre a PKB, consulte o artigo "Plataforma Analítica de Cibersegurança. Experiência Sber" na Kibraia da Sber. Lá, você também encontrará informações sobre como nosso serviço se integra à plataforma.
Neste artigo, apresentarei uma visão geral da arquitetura do serviço, suas tarefas, o que já alcançamos, o que ainda precisamos fazer e os motivos por trás disso. Nosso serviço opera em um ambiente heterogêneo complexo, que inclui não apenas software desenvolvido internamente, mas também produtos open source como Apache Flink e MLFlow para funcionalidades diversas, e Apache Hadoop, Ozone e Clickhouse para gerenciamento de dados. O SUD deve atender a vários requisitos cruciais:
Integração com o ecossistema bancário: Deve se alinhar com o cenário geral do banco, respeitando os requisitos regulatórios de diversos níveis.
Usabilidade e Inovação: Proporcionar um gerenciamento de acesso conveniente na plataforma, introduzindo novidades que sejam úteis para todos os consumidores, inclusive nos produtos open source utilizados.
Centralização: Unificar a autenticação, autorização, atribuição e controle de acessos na plataforma.
Reutilização: Ser adaptável para uso em outras plataformas e sistemas automatizados.
As operações do SUD podem ser categorizadas em áreas específicas do domínio "Gerenciamento de Acesso e Identificação": modelo de acesso, gerenciamento do modelo de acesso a recursos, atribuição de acessos a usuários, identificação e autenticação, autorização, e controle, auditoria e relatórios. A "Modelo de Acesso" é destacada como um item separado, pois constitui a base para todas as customizações e processos de gerenciamento de acesso.
O SUD realiza a identificação e autenticação de usuários integralmente através de mecanismos bancários globais, sem armazenar quaisquer fatores de autenticação dos usuários. No entanto, o modelo de acesso é um pouco mais complexo. A principal ferramenta para gerenciar o acesso de usuários no banco é a "função" (role), que não é decomposta. Inicialmente, nosso serviço também utilizava apenas o conceito de "função". Vamos analisar como isso funcionava.
Na ilustração, as áreas em cores e números indicam as funcionalidades em que o serviço de gerenciamento de acesso da PKB operava inicialmente. Cada equipe de serviço da PKB define sua própria modelagem de acesso baseada em funções, a protege durante os testes de aceitação de cada release e envia as funções para o SUD (1a). Todas as funções de todos os serviços são agregadas e, mediante solicitação, repassadas ao serviço bancário global de gerenciamento de contas de usuário, que chamaremos de userIDM (1b), utilizando o protocolo SCIM. No userIDM, uma função pode ser atribuída a um usuário mediante solicitação aprovada (2a). Essas informações são sincronizadas com o serviço bancário global de autenticação e transmitidas via protocolo SCIM para o SUD (2b), que armazena a associação usuário-função em seu banco de dados. O usuário interage com os serviços da PKB através de um gateway de autenticação baseado no Platform V IAM Proxy. Para isso, o usuário deve se autenticar utilizando o protocolo OpenID Connect, com o auxílio do serviço bancário global de autenticação (3a–3d). Após a autenticação, a sessão do usuário é enriquecida com um ID token no formato JWT, que é então recebido pelo serviço da PKB invocado pelo usuário. Em seguida, o serviço consulta o SUD via REST API, solicitando as funções do usuário, cujo identificador foi obtido no ID token. Com base nas funções recebidas, o serviço implementa o controle de acesso do usuário, determinando se o acesso a uma determinada seção do serviço é permitido ou não.
Modelo de Acesso
Dado que o banco utiliza um modelo baseado em funções, somos obrigados a empregar funções, mas com a capacidade de expandi-las significativamente. Um dos padrões mais conhecidos que descreve o uso de modelos baseados em funções para controle de acesso é o ANSI INCITS 359-2012 "Role Based Access Control". Adotamos o componente "Core RBAC" (Modelo de Referência RBAC) e expandimos as funções para incluir o uso de privilégios dentro delas (nossas denominações diferem ligeiramente do padrão, mas a essência permanece a mesma). Uma função pode conter múltiplos privilégios, e um privilégio é um acesso nomeado a um recurso, descrito pela associação de um nome de recurso a um conjunto de permissões de acesso a ele. Essa decomposição de funções permite que o SUD armazene, essencialmente, políticas de controle de acesso e ofereça uma visão mais completa dos acessos dos usuários aos recursos dos serviços da plataforma.
Outras definições do padrão, como a hierarquia de funções (Hierarchical RBAC), ainda não são utilizadas, ou dependemos de processos bancários globais que controlam, inclusive, a separação estática de funções (Static Separation of Duties). Cada serviço da PKB mantém seu próprio modelo de funções dentro do SUD, com os espaços de serviço completamente isolados uns dos outros. No entanto, como os serviços na plataforma interagem entre si, para simplificar a obtenção de acessos dentro da plataforma, expandimos nosso modelo de funções para incluir "privilégios publicados". Estes, criados em um serviço da PKB, podem ser utilizados nas funções de outro serviço. Qualquer modelo de funções existe independentemente dos recursos reais, pois o SUD, por exemplo, não sabe quais recursos reais uma privilégio com o recurso "*" concede acesso, que geralmente é interpretado como acesso a todos os recursos. Por isso, introduzimos no SUD o conceito de "recurso físico". Recursos físicos são informações sobre os recursos reais existentes em um serviço da PKB, como um banco de dados, uma tabela ou até mesmo uma coluna de tabela. Essa informação é frequentemente chamada de modelo físico. Consequentemente, nosso modelo de funções se torna mais rico em informações, e o chamamos de modelo de acesso, em vez de modelo de funções. Graficamente, ele pode ser representado da seguinte forma:
No entanto, este modelo de acesso permanece estático; na maioria dos casos, quando um novo recurso físico é introduzido, o usuário não obtém acesso automático a ele. É necessário solicitar, obtendo uma nova função. O problema da velocidade na concessão de acessos se torna particularmente evidente com o uso massivo de aprendizado de máquina e agentes de IA. Para mitigar isso, estamos atualmente explorando os conceitos de Controle de Acesso Baseado em Relacionamentos (Relationship-based Access Control – ReBAC) e Controle de Acesso Baseado em Atributos (Attribute-based Access Control – ABAC).
Gerenciamento do Modelo de Acesso a Recursos
Conceitualmente, o Serviço de Gerenciamento de Acesso (SUD) é responsável por gerenciar todos os modelos de acesso na plataforma. Para isso, dispomos de dois canais de modificação de modelos: a API REST de gerenciamento do SUD e solicitações através da interface gráfica do SUD. A API de gerenciamento possui métodos específicos para criar ou modificar permissões, recursos, privilégios e funções, além de publicar privilégios. Para diferentes usos, existem métodos para atualização completa, parcial ou incremental das entidades (adição sem modificação ou exclusão). O serviço utiliza a API do SUD ao introduzir uma nova versão do modelo de acesso no processo de desenvolvimento em produção, com customizações no próprio serviço. O novo modelo de acesso é testado em diversos ambientes e aprovado pelas unidades interessadas antes de ser implementado. Contudo, alguns serviços da PKB precisam modificar o modelo de acesso sem novos releases, por exemplo, ao alterar os acessos dos usuários aos dados. Nesses casos, é possível utilizar solicitações de modificação do modelo de acesso, onde funcionários designados podem editar o modelo na mesma interface do SUD e, após obter todas as aprovações necessárias, aplicá-lo automaticamente ao ambiente de produção. Uma solicitação desse tipo no SUD pode ter a seguinte aparência:
A solicitação pode ser formulada com base no conhecimento dos recursos físicos do serviço. Nesse cenário, após selecionar o recurso físico e as permissões de acesso a ele, a solicitação gera automaticamente os recursos e privilégios que serão incluídos na função especificada.
Atualmente, o SUD oferece várias maneiras de obter informações sobre recursos físicos:
Via API: Qualquer serviço da PKB pode enviar seu modelo físico para o SUD, incluindo atributos ou relacionamentos, como identificadores de proprietários de recursos.
Importação de outros serviços da PKB: Informações sobre recursos físicos podem ser importadas de outros serviços da PKB, como o serviço de gerenciamento de metadados.
Importação dos próprios serviços: Informações sobre recursos físicos podem ser importadas diretamente dos serviços, como dados sobre bancos de dados e tabelas Hive do Metastore, ou diretórios HDFS.
Interface Gráfica do SUD: Planejamos introduzir informações sobre recursos físicos através da interface gráfica do SUD.
O atributo principal dos recursos físicos atualmente é a informação do proprietário, mas já calculamos outros atributos, como a categoria de confidencialidade das informações no Hadoop. Para isso, o SUD acessa o serviço Hive, lê pequenas amostras de dados das tabelas e determina o nível de confidencialidade usando um serviço interno da PKB baseado em algoritmos e inteligência artificial. Esses atributos podem ser utilizados futuramente na aplicação dos princípios ReBAC e ABAC nos modelos de acesso.
O SUD gerencia modelos de acesso não apenas para os serviços desenvolvidos na PKB, mas também para produtos open source utilizados na PKB. Por exemplo, ele é integrado ao Apache Ranger e ao freeIPA. O modelo de acesso aos serviços do Apache Hadoop é gerenciado no SUD; após a execução de uma solicitação de modificação do modelo, ele é automaticamente ou manualmente convertido em uma política de acesso do Apache Ranger e repassado a ele, sendo então distribuído para todos os nós de serviço Hadoop necessários. Outra opção é o uso da interface LDAP no SUD para transferir permissões de acesso para produtos como Grafana ou Platform V Search.
Atribuição de Acessos a Usuários
As funções de usuário no SUD são divididas em duas classes: básica e aplicada. As funções básicas são atribuídas através do serviço bancário global de gerenciamento de contas de usuário (IDM) e transmitidas para o SUD via protocolo SCIM. As funções aplicadas não concedem nenhum acesso sem as funções básicas; o usuário pode solicitá-las em seu portal pessoal ("Meu Perfil") no SUD. Somente após a aprovação do proprietário do serviço e, se necessário, dos proprietários dos recursos aos quais a função concede acesso, o usuário receberá a função aplicada solicitada.
Estamos em processo de desenvolvimento desta funcionalidade, planejando adicionar visibilidade para solicitação de funções aplicadas com base em departamentos, bem como a separação estática de funções. Nosso objetivo é automatizar ao máximo a concessão de acesso aos usuários, utilizando relacionamentos (como o de proprietário de recurso) e atributos.
Identificação e Autenticação
Após as etapas de formação e atribuição de acessos, passamos para o processo de login do usuário nos serviços da PKB utilizando o Serviço de Gerenciamento de Acesso. Primeiramente, é necessário identificar e autenticar as requisições de entrada no gateway de autenticação, que faz parte do Serviço de Gerenciamento de Acesso. Como mencionado anteriormente, o gateway é construído sobre o Platform V IAM Proxy. Para cada serviço da PKB, uma ramificação separada é criada no IAM Proxy, sob a qual opera sua interface gráfica. O usuário pode ser autenticado de diversas maneiras, dependendo, inclusive, do nível de confidencialidade dos dados processados no serviço da PKB. Por exemplo, para muitos serviços, utilizamos autenticação de dois fatores via aplicativo móvel com confirmação de login por senha de uso único ou resposta a uma notificação push.
Atualmente, não temos planos de expandir a funcionalidade nesta área, pois acreditamos que a solução atual atende a todas as necessidades da PKB. Nosso foco aqui é em alta disponibilidade, balanceamento, controle de tráfego e aspectos similares.
Autorização
Autorização (ou o ato de conceder acesso) é a atribuição de direitos de acesso a um sujeito, bem como a concessão de acesso de acordo com as regras de gerenciamento de acesso estabelecidas (GOST R 58833-2020 Proteção da Informação. Identificação e Autenticação. Disposições Gerais. Item 3.50).
Como já dito, o próprio produto autoriza o usuário com base nas informações recebidas do SUD via REST API. Como não encontramos padrões estabelecidos para esse tipo de API no momento de seu projeto, criamos nosso próprio formato. As chamadas da API de autorização são projetadas para que o serviço possa fazer diferentes tipos de requisições. Por exemplo: "Este usuário tem tal permissão para tal recurso?". Nesse caso, o SUD atua como um PDP (Policy Decision Point), fornecendo uma resposta sobre a possibilidade de acesso.
Requisição:
GET /user/access/resource/is?system_id=mms&user_id=1102787&resource_name=resource1&permission_id=READ
Resposta:
{
"has_permission": true
}
Ou outra pergunta: "Quais funções este usuário possui?". Nesse caso, o SUD atua mais como um PIP (Policy Information Point), que compila uma política de acesso aplicável a este usuário, e o próprio serviço atua como PDP: ele calcula se o usuário tem acesso ao recurso.
Independentemente de onde o acesso é calculado (PDP), a decisão de acesso é aplicada pelo próprio serviço da PKB, atuando como um PEP (Policy Enforcement Point).
No caso de um serviço open source de produto, como Grafana ou Platform V Search, utilizamos a API LDAP do SUD para autorização. Através dela, determinamos os privilégios dos usuários – na notação LDAP, eles são chamados de grupos aos quais o usuário pertence (neste caso, o SUD atua como PIP). Em seguida, com base nesses grupos, a política local do serviço determina as possibilidades de acesso do usuário a uma determinada funcionalidade (o produto executa as funções de PDP e PEP).
Existem serviços open source na plataforma que não possuem capacidade nativa de controle de acesso de usuários, como Apache Flink ou MLFlow. A autorização de acesso de usuários a esses serviços ocorre no gateway de autorização, construído sobre o Apache KNOX. Ele obtém os privilégios do usuário, correspondentes aos seus grupos no LDAP do SUD, e verifica a possibilidade de acesso do usuário aos serviços atrás do gateway usando um plugin Ranger, que armazena e atualiza a política de acesso recebida do Apache Ranger. Nesse cenário, o núcleo do SUD executa as funções de PIP, e o gateway de autorização baseado em KNOX atua como PDP e PEP.
Atualmente, a arquitetura do Serviço de Gerenciamento de Acesso se apresenta da seguinte forma:
No entanto, esta não é a arquitetura final. Como mencionado anteriormente, aprimoraremos o serviço para incorporar os conceitos de ReBAC e ABAC, o que deve alterar a arquitetura, pois o principal desafio a ser superado é a performance. Nesse caso, será necessário calcular os acessos a cada requisição com base em novos valores de atributos ou relacionamentos de entidades de acesso modificados. Portanto, distribuiremos o cache, pré-calcularemos políticas de acesso e assim por diante, o que, esperamos, trará soluções interessantes que compartilharei com vocês futuramente.
Em suma, ao longo de vários anos de desenvolvimento, o SUD evoluiu de um serviço que agregava funções de usuários para uma plataforma completa de gerenciamento de acesso. Ela integra modelos de acesso de outros serviços, oferece diversas opções de modificação, garante autorização centralizada, integra-se com soluções corporativas e open source, adapta-se a novos desafios tornando-se um subsistema de acesso para agentes de IA, e gradualmente se transforma em um ponto único de controle de acesso na PKB.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
