BLOG

ABAC não RBAC: Bem-vindo ao mundo (IoT) da segurança contextual

Miniatura de Lori MacVittie
Lori MacVittie
Publicado em 07 de setembro de 2015

Há muito mais atributos que podem ser obtidos de uma solicitação de inscrição aparentemente simples do que pode parecer à primeira vista. Há, é claro, o endereço IP. A partir do qual se pode determinar a localização de alguém. Isso é geolocalização e é uma prática bastante comum hoje em dia obter esse pedaço de dados. Mas disso também se pode inferir alguns outros atributos, como “dentro de uma propriedade corporativa”. Também é possível usar uma mineração de dados um pouco mais avançada e determinar se o local é ou não típico do usuário que tenta acessar o aplicativo.

E isso é apenas de um endereço IP. Os parâmetros do sistema operacional e do dispositivo são facilmente obtidos examinando os cabeçalhos na solicitação HTTP enviada para acessar o aplicativo. Quando se trata de um navegador da web, uma impressão digital ainda mais específica pode ser realizada e, posteriormente, comparada com comunicações anteriores para determinar se “Jim” é realmente o mesmo “Jim” ao qual você permitiu acesso no passado.

Todas essas informações; as variáveis extraídas e inferidas, compõem o que o setor de controladores de entrega de aplicativos (ADC) chama de “contexto” há muitos anos. Esse contexto é o que informa as decisões de segurança, permite a inovação na entrega e auxilia na aplicação de técnicas de aceleração que melhoram a experiência do aplicativo.

Portanto, não foi surpresa ler este artigo declarando a morte do RBAC e a introdução do ABAC (Controle de Acesso Baseado em Atributos).  É baseado no contexto, apenas descrito com uma sigla muito mais legal, que soa um pouco melhor (e parece algo muito mais formal).  O foco do artigo (vá em frente e leia, estarei aqui quando você voltar...) é realmente eliminar a função como meio primário de autorização e substituição por atributos, e fala mais de um mecanismo de controle de acesso interno ou de empresa para empresa, mas o conceito é amplamente aplicável. Ele é amplamente utilizado em soluções antifraude , por exemplo, nos setores bancário e financeiro. Você provavelmente já interagiu com um deles no passado quando efetuou login para fazer operações bancárias ou verificar suas ações e, durante o processo, o aplicativo começa a incomodá-lo com uma de suas perguntas de segurança — porque você está efetuando login de um local que não é o seu habitual, ou usando um novo dispositivo ou um navegador diferente.

 

 

bloco de estatísticas iot

Considerando que uma porcentagem significativa de comprometimentos nos últimos 15 anos foi atribuída a problemas de acesso a aplicativos (principalmente credenciais roubadas), resultando em milhões de dólares em fraudes e perda de informações pessoais, esses tipos de técnicas são cada vez mais importantes para proteger dados corporativos e de consumidores. De acordo com o Relatório de Fraude de Identidade de 2014 da Javelin Strategy & Research: Violações de dados de cartão e hábitos inadequados de senhas do consumidor alimentam tendências preocupantes de fraude. 61% das violações em geral são resultado de credenciais roubadas. 

E agora, dado o número crescente de “coisas” que se comunicarão com aplicativos em todo o mundo, a necessidade de fornecer às “coisas” acesso aos aplicativos é existencial.

E isso tradicionalmente significa alguma forma de credencial. Credenciais que podem ser roubadas e (ab)utilizadas para causar estragos em sistemas internos, redes e dados.

Agora, não há nenhuma organização que eu conheça que esteja considerando seriamente atribuir todas as “coisas” que eles podem precisar para permitir o acesso a uma função. A escala necessária para atingir isso é possível, mas não prática. Além disso, atribuir identidades individuais a cada “coisa” parece um desafio intransponível; matematicamente um limite* que nunca pode ser alcançado. Mas o fato é que essas coisas (e seus proprietários) precisarão de acesso aos aplicativos, pelo menos alguns dos quais podem estar no seu data center. Aplicativos que o ativam, controlam e relatam sobre ele.

É importante considerar isso antes da implantação. Antes da disponibilidade geral. Antes que milhões de consumidores tenham sua “coisa” tentando acessar esses aplicativos.

Pense em como você fornecerá acesso seguro agora, antes que isso se torne um problema. Crie uma solução baseada no contexto – em atributos – antes que ela exija atualizações de firmware ou software para milhões de dispositivos.

O fornecedor de uma interface de rede (ethernet, bluetooth, etc.) pode ser identificado pelos endereços MAC . Essa é uma informação altamente pertinente ao solucionar problemas em uma rede local, especialmente se o engenheiro ou operador puder identificá-la prontamente em uma captura de pacotes. Haverá oportunidades com “coisas” que oferecem o mesmo tipo de identificação baseada em atributos que podem auxiliar no design e implementação de um sistema ABAC. Não endereços MAC, que não persistem fora do domínio local, mas outros atributos de identificação de dispositivos que podem ser incorporados na troca de comunicação e usados pelos gatekeepers de acesso para determinar a legitimidade.

E dada a quantidade de coisas que você terá que identificar se estiver jogando no jogo da IoT, você vai querer projetar e implementar uma.

Então, se você está mergulhando na IoT (e os dados do nosso próximo relatório State of Application Delivery 2016 dizem que muitos de vocês estão), então não é muito cedo para começar a considerar como você vai gerenciar o acesso com segurança. Chame isso de contexto, chame isso de ABAC, chame isso de outra coisa. Mas não importa como você o chame, não chame algo que você esqueceu de considerar – e agir.

*Ok, eu admito. Minha especialização na graduação foi, de fato, em matemática. Lá. Eu disse isso.