Um dos principais componentes que fazem parte da arquitetura do Blazon é o que conhecemos como Diretório. O diretório é um repositório de dados central, que tem como principal objetivo armazenar as informações de identidades e acessos.

A presença deste diretório, permite o armazenamento de forma centralizada de todas as informações necessárias para a correta gestão de identidade e acessos. Ele habilita o Blazon a executar todos processos necessários como revogações, revalidações de acessos e segregação de funções.

No diretório é possível encontrar todos os usuários cadastrados bem como os acessos que estes usuários possuem, o que facilita e permite o gerenciamento de acesso efetivo.

Objetos

No diretório, é possível encontramos os objetos descritos na imagem abaixo:

Usuários

O usuário, é o objeto que representa uma identidade e que é utilizado normalmente para representar uma pessoa. Este objeto possui um conjunto de atributos que são fundamentais para determinar as características deste usuário.

Recursos

Um recurso é utilizado para representar um conjunto de acessos que precisa ser gerenciado. Normalmente um recurso representa uma aplicação, como por exemplo Active Directory, Office 365, Google Workspace, ou alguma aplicação corporativa legada.

Contas

Uma conta é a representação de uma credencial, que um determinado usuário possui em um determinado recurso, por exemplo: Um usuário que possui um acesso ao Active Directory, terá este acesso mapeado por meio de uma conta. A conta permite o Blazon entender que um usuário possui de fato um acesso em uma determinada aplicação.

Direitos

Um direito representa uma permissão de acesso em uma aplicação. Esta permissão de acesso pode ser um perfil de acesso, grupo de acesso ou qualquer outra nomenclatura ou modelo que uma aplicação possa utilizar. Um direito sempre estará relacionado a um determinado recurso.

Membros de direitos

Um membro de direito indica a permissão de acesso de um determinado usuário dentro de uma aplicação, por exemplo: Um usuário do Active Directory que é membro de um grupo, será mapeado como um membro de direito no Blazon.

Papéis

Os papéis possuem a responsabilidade de permitir a concessão de acessos de uma forma agrupada e abstrata. Como abstrato, queremos dizer que um papel permite que a complexidade de um sistema seja simplificado no Blazon, por exemplo: Um grupo de acesso no Active Directory que possui uma nomenclatura muito técnica, pode ser mapeado em um papel com um nome mais relevante ao usuário final.

Além disso, um dos principais objetivos dos papéis é permitir a implementação de um modelo de acesso baseado em papéis (RBAC), pois ele permite a inclusão de diversos acessos em sua estrutura e permite a concessão destes acessos de maneira unificada para um usuário.

Membros de papéis

Um membro de papel representa a relação entre um usuário e um papel. Sempre que um usuário possui um papel, haverá um objeto denominado membro de papel.

Relações

Os objetos do diretório possuem uma relação entre si e é exatamente esta relação que permite o entendimento dos acessos existentes no diretório.

Um usuário, pode possuir zero ou mais contas em algum recurso. Dito isso, é importante notar que uma conta possui um usuário relacionado a mesma e esta relação normalmente é referenciada como proprietário. Sobre a relação entre usuários e contas, existem regras e exceções a esta relação:

• Um usuário possui zero ou mais contas;

• Uma conta pode, em alguns momentos, não possuir nenhum proprietário, o que é caracterizado como uma conta órfã;

• Um usuário só pode possuir uma conta em um determinado recurso, exceto em contas de aplicação.

Além disso, um usuário pode possuir zero ou mais papéis e esta relação é representada por meio de um objeto do tipo membro de papel.

Já a relação entre um papel, recursos e direitos, indica que um determinado papel possui acessos relacionados a ele e desta maneira, quando um membro de papel é criado ou removido, acessos podem ser concedidos ou revogados, baseados nesta relação.

Em relação a um recurso, o mesmo pode possuir zero ou mais contas e/ou direitos. E uma determinada conta pode possuir zero ou mais direitos e esta relação é determinada a partir de um objeto membro de direito.

As relações descritas aqui, são manipuladas por diversos mecanismos, seja por uma intervenção manual ou principalmente por algum processo que acontece de forma automatizada. As próximas seções da nossa documentação descrevem como os objetos do diretório podem ser manipulados.

Tipos de gerenciamento de objetos

Cada objeto do diretório possui uma forma de gerenciamento, esta forma simboliza como um determinado objeto pode ser manipulado e esse entendimento é de suma importância, pois a forma na qual um objeto é gerenciado pode afetar diversos processos.

Atualmente, as formas disponíveis para gerenciamento destes objetos pode variar para cada tipo, a tabela abaixo contém cada um dos objetos e como eles podem ser gerenciados:

• Objetos gerenciados manualmente: Os objetos gerenciados manualmente podem ser revogados e podem ser submetidos a processos de certificação;

• Objetos gerenciados por papel: Estes objetos possuem seu ciclo de vida atrelado a um papel e não podem ser revogados manualmente e também não são elegíveis para processos de certificação;

• Objetos gerenciados por política de atribuição: Os membros de papaéis gerenciados por uma política de atribuição não podem ser revogados manualmente e também não são elegíveis para processos de certificação.

As seções a seguir desta documentação, discutem de maneira detalhada cada um dos aspectos relaciondos aos objetos do diretório.

Segundo o Gartner, a disciplina de IAM pode ser definida como:

"Gestão de Identidade & Acessos é a disciplina que permite o indivíduo correto acesse o recurso correto, no tempo e pelos motivos certos."

Antes de analisarmos esta definição, é importante mencionar as diversas nomenclaturas pelas quais esta disciplina é denominada. É normal encontrarmos termos como: “Gestão de Identidade”; “Gerenciamento de Identidade”; “Gestão de Acesso”; “Identity Management”; “Identity and Access Management”; ou, “IAM”, simplesmente.

É interessante notar que esta definição aparentemente simples, toca em aspectos que podem se tornar muito complexos, se considerarmos que as organizações são dotadas de dezenas/centenas de colaboradores, parceiros de negócios, sistemas e milhares de clientes. Voltando definição, podemos destacar termos chaves nesta definição, sendo eles: Individuo; Recurso; Tempo certo; e Razão certa.

Indivíduo

Indivíduo é o sujeito central das ações, isto é, a Entidade que deseja fazer acesso a um determinado recurso. Em um contexto organizacional, este indivíduo pode ser um colaborador, um parceiro, um cliente ou, até mesmo, robôs etc. Indivíduos têm ciclos de vida em suas relações com a Organização, desde o instante em que é criado (quando é admitido, por exemplo) até sua remoção. Neste período ele pode ter promoções na carreira, bem como pode ter afastamentos por férias ou saúde, por exemplo. É fundamental que uma plataforma de Gestão de Identidade gerencie o ciclo de vida de Indivíduos, de tal modo que seus direitos de acessos reflitam o instante presente.

Recurso

A definição de Recurso, pode ser feita de forma geral como algo que um determinado Indivíduo deseja utilizar, ou seja, deseja fazer acesso. Um Recurso pode ser algo como uma Aplicação, um Conteúdo, um Servidor, um Acesso à Internet, uma Pasta ou até mesmo uma coisa (IoT), por exemplo uma catraca que dê acesso físico a organização. Assim como Indivíduos, Recursos também podem ter ciclo de vida, desde o instante em que passa a fazer parte da infraestrutura da corporação, apresentando do mesmo modo, períodos de indisponibilidade, por questões de manutenção ou de segurança.

Tempo certo

Em um mundo cada vez mais digital, mais conectado, mais móvel e que valoriza a experiência do usuário, Indivíduos precisam de acesso a Recursos de maneira mais rápida possível. Não é mais aceitável que um colaborador aguarde dias para poder acessar seu sistema principal de trabalho. Além disso, devido a cenários cada vez mais ágeis, é necessário conceder acessos a recursos corporativos de forma rápida, garantindo que a agilidade requerida não comprometa a segurança da organização. Por outro lado, há Recursos e Indivíduos que podem ter restrições de horários para seus acessos e, então, nestes casos, o acesso deve ser negado para horários indevidos.

Motivo certo

Cada indivíduo deve ter acesso aos recursos necessários e em tempo hábil, e isto deve sempre ocorrer pela razão correta. A necessidade do acesso pode se dar pelo papel que ele exerce na organização ou por alguma tarefa específica que ele vá executar durante algum período. De forma geral, nenhum indivíduo deveria ter acesso a um recurso se não houver uma razão. Isto protege a organização, mas, também, protege o indivíduo.

Segurança é um assunto transversal à estrutura organizacional das corporações, que permeia os aspectos físicos, lógicos e virtuais estruturados em três camadas: Física, de Controle e de Aplicação. Além de aspectos básicos, tais como antivírus e zonas militarizadas, a complexidade aumenta consideravelmente para atender leis, normas, padrões e políticas corporativas, tais como LGPD, ISO 27001, PCI, SOX e HIPAA, entre outros, visando a governança TI da organização.

Adicionalmente, foi feita uma análise meticulosa das fragilidades críticas de segurança em aplicativos Web, reportadas pela Fundação OWASP (Open Web Application Security Project). O projeto de cada camada, cada módulo e cada aplicação incluiu controles pró ativos de segurança, além de garantir que novos desenvolvedores continuem a proteger a manutenção e o desenvolvimento de novos módulos. Foram, portanto, utilizadas as melhores práticas de segurança de modo a atingir um alto padrão em todos os aspectos de projeto nesta disciplina.

Independentemente dos aspectos e das camadas de Segurança, há quatro propriedades que devem ser garantidas onde quer que um módulo, uma aplicação ou um sistema opere: Integridade – que garante a não alteração de dados/informações durante seu transporte; Confidencialidade – que garante que dados/informações só serão conhecidas por aqueles que portem as credenciais devidas; Disponibilidade – que garante que dados/informações estejam disponíveis quando requeridos; e Não Repúdio – que garante que um acesso feito por um colaborador não possa ser negado de tê-lo feito.

Gerência de vulnerabilidades

Considerando que vivemos em mundo altamente conectado e móvel, é impossível garantir que um ambiente é 100% seguro e, portanto, ameaças são uma constante. Isto posto, é necessário cuidar pró ativamente para que os riscos sejam monitorados, detectados, controlados e mitigados, protegendo e dando segurança ao negócio em toda a estrutura da organização.

Atuar preditiva e preventivamente é fundamental para se antecipar às ameaças e suas consequências. Gestão de Vulnerabilidades é o processo que monitora, detecta, identifica, analisa, classifica e trata eventos associados a vulnerabilidades. O saneamento de vulnerabilidades consiste na prevenção de fraquezas, controle e aplicação de correções e minimização/mitigação de efeitos colaterais na organização. A gestão de vulnerabilidades é um processo contínuo, sistemático, e que precisa monitoração pormenorizada.

Pensando em todos os aspectos descritos anteriormente, o Blazon se preocupa em garantir uma plataforma livre das vulnerabilidades abaixo (mas não se limitando apenas a elas):

• Controle de injeção;

• Exposição de dados desnecessários;

• Cross-Site Scripting (XSS);

• Cross-Site Request Forgery (XSRF);

• Gerenciamento correto de sessões Web.

Além disso, a equipe de profissionais do Blazon se preocupa em garantir um ambiente configurado seguindo as melhores práticas de mercado, evitando a exposição desnecessária de informações e impedindo ataques como escalação de privilégios.

Cifragem

Cifragem é um método de embaralhamento de dados, baseado em algoritmos de criptografia, fundamental para garantir a confidencialidade. Sistemas/Aplicações, em geral, utilizam esses métodos de duas formas: i) embaralhamento irreversível, em geral utilizado para a confidencialidade de autenticação; e ii) embaralhamento reversível, utilizado para o transporte confidencial de dados/informações.

Todas as credenciais utilizadas por colaboradores (usuários) da organização são criptografadas utilizando o algoritmo de codificação SHA-512, não sendo possível a reversão das cifragens. Na realidade, é possível a configuração de outros algoritmos de criptografia, se for um requisito da corporação.

O armazenamento de dados/informações (ii), que requerem a remoção da cifragem, tais como o nosso cofre de senha, utilizam o método de criptografia simétrica baseado no algoritmo AES (Curvas Elípticas) de 256 bits. É interessante frisar que o método de criptografia baseado em algoritmos AES oferece uma confidencialidade superior aos demais algoritmos, sendo comprovado que AES 256 bits é mais do que suficiente para as necessidades atuais de confidencialidade.

As chaves utilizadas para cifrar/decifrar são armazenadas em locais seguros e possuem um processo em camadas, que minimizam/evitam suas utilizações indevidas. Além das chaves, cada transação necessária possui um salto que aumenta o nível de dificuldade de possíveis atacantes que queiram obter acesso indevido a dados/informações contidas na plataforma.

Autenticação

A autenticação é o ato de provar uma afirmação, como a Identidade de um usuário (Username) de sistemas computacionais, onde um usuário precisa provar que ele é quem diz ser. Em contraste com a identificação, o ato de indicar a identidade de uma pessoa ou coisa, a autenticação é o processo de verificação dessa identidade. Um usuário pode provar que ele é quem diz ser de, basicamente, três modos: i) algo que o usuário sabe – em geral uma senha; ii) algo que o usuário tem – em geral um dispositivo, como um token; e iii) algo que o usuário é – em geral biometria.

O processo de autenticação pode exigir alguns desses fatores (i, ii ou iii), dependendo do contexto de utilização, o que é denominado autenticação por meio de Múltiplos Fatores de Autenticação (MFA – Multi Factor Authentication), que implica na necessidade de oferecer dois ou mais fatores de autenticação. A autenticação é um processo que pode envolver:

• Múltiplos Fatores de Autenticação:

  • Username/Password;

  • Perguntas secretas;

  • Google Authenticator; e

  • Canal seguro (email/SMS/App).

• Controle de risco:

  • Solicitação de mais Fatores de Autenticação baseada em contexto:

    • Origem do acesso;

    • Horário;

    • Dispositivo conhecido.

  • Negação de acesso baseado em contexto:

    • Origem do acesso;

    • Horário;

    • Dispositivo conhecido.

• Controles contra ataques de força bruta:

  • Muitas tentativas de logins com falha do mesmo endereço IP;

  • Logins com vários nomes de usuários do mesmo endereço IP;

  • Logins para uma única conta provenientes de muitos endereços IP diferentes.

Gerenciamento de senhas

Senha é um dos fatores de autenticação mais largamente utilizados devido à facilidade de ser algo que pode ser memorizado e, portanto, não requer nenhum artefato adicional. Por outro lado, memorizar sequência longa de caracteres, principalmente se se inclui caracteres especiais, pode levar ao esquecimento frequente de senhas. Ausência de critério na criação de senha leva ao risco de se criar senhas fáceis e fracas. Nas organizações, além de ser requeridas senhas fortes, há políticas de segurança que impõem a troca sistemática de senhas, incluindo o requisito de não se repetir senhas. Todos esses requisitos implicam na necessidade de se constituir um processo que gerencie as senhas de usuários, sendo oferecidas as seguintes funcionalidades:

• Política de Complexidade de senha: maiúscula, minúscula, números, caracteres especiais, tamanho mínimo;

• Não reutilização de senhas;

• Expiração de senhas;

• Sincronismo de senhas;

• Armazenamento seguro (baseado no item ‘i’ descrito em cifragem);

• Troca de senha pelo usuário:

  • Identificação do usuário;

  • Perguntas secretas;

  • Inativação do usuário;

  • Token secreto no e-mail;

  • Nova senha baseada na Política de Complexidade.

Integrações de Sistemas

A Gestão de Identidade permeia todos os sistemas e recursos da corporação, desde sistemas pré-existentes na organização, bem como novos sistemas. Além disso, recursos físicos tais como catracas e portas podem (e deveriam) fazer parte de uma plataforma de Gestão de Identidade. Deste modo, integração de sistemas é uma das chaves para o sucesso de um projeto bem sucedido.

A arquitetura Blazon tem uma camada (Resource Adapters Layer) especialmente projetada para integrar transparentemente todos os sistemas existentes numa corporação. Visando escalabilidade e funcionamento em nuvem, esta camada foi projetada completamente desacoplada do Módulo Core Engine, permitindo que esses adaptadores (RA) operem em um mesmo ambiente ou em ambientes distintos, incluindo diferentes nuvens.

Blazon permite que esses adaptadores sejam construídos facilmente, podendo ser inclusive desenvolvidos pela equipe de TI da organização. Os seguintes aspectos de segurança são especialmente tratados:

• Integridade e Confidencialidade

  • Comunicações entre o Módulo Core Engine e cada RA é passível de utilização de HTTPS, sendo esta recomendada;

  • Eventos de provisionamento contendo informações sensíveis são criptografados, tais como:

    • Criação de contas;

    • Mudança de Senhas;

    • Atualização de contas.

• Disponibilidade

  • Toda e qualquer comunicação realizada entre o Módulo Core Engine e um RA, é feita no modelo de polling, sendo responsabilidade do RA buscar eventos relativos a provisionamento/reconciliação;

  • Caso um RA se torne indisponível, assim que ele se torne novamente disponível, os eventos em aguardo são processados;

  • Caso algum sistema (integrado) se torne indisponível para provisionamento, foram desenvolvidas políticas de resiliência, que tentam o provisionamento até que um limite máximo de tentativas especificado (configurado) seja alcançado.

Acesso à Plataforma

Todo e qualquer acesso ao Blazon pode ser disponibilizado a partir de HTTPS, sendo que todos estes acessos são registrados via log. Este requisito de acessos via HTTPS é fundamental para a confidencialidade dos acessos e, é importante frisar que, a Política de Log foi desenvolvida para garantir o Não-repúdio, que, como dito anteriormente, é uma garantia de comprovação da origem e autoria de um determinado acesso. A plataforma garante que o autor (usuário) não negue ter feito o acesso.

Controle de permissões internas

Blazon conta com um conjunto de permissões internas que permitem que apenas as funcionalidades necessárias sejam disponíveis para um usuário. Desta forma controles como Segregação de Responsabilidade, que reduzem em até 40% tentativas de fraudes, podem ser aplicados na própria plataforma, garantindo um alto nível de confiabilidade e diminuição de riscos.

Gerenciamento de sessões

Uma sessão é caracterizada pelo intervalo de tempo decorrido entre o instante em que um usuário é autenticado até o instante em que o acesso é encerrado, sendo que neste intervalo de tempo, o usuário pode requerer a execução de tarefas. Gerenciar uma sessão é então o processo de garantir que um usuário somente terá o acesso para o intervalo de tempo que lhe é outorgado e que esse usuário somente execute tarefas para as quais possui direito. Do mesmo modo, a gerência de sessão deve garantir que apenas o usuário autenticado poderá executar tarefas na sessão para a qual foi autenticado e registrar todas as atividades visando a rastreabilidade do acesso.

Sendo considerado um item extremamente relevante no controle de vulnerabilidades, há especial atenção ao gerenciamento adequado de sessões Web para evitar que ataques sejam realizados por meio de tais sessões. Dentre algumas preocupações, abaixo temos alguns dos controles realizados pela plataforma:

• Controle de timeout absoluto;

• Controle de sessão por tempo de inatividade;

• Session ID Name Fingerprinting.

Além disso, nossa equipe se preocupa na utilização/configuração de um setup que contemple a utilização de HTTPS, evitando o sequestro das sessões por meio de técnicas como Man-in-the-middle.

Logging

O projeto da plataformar inclui um completo sistema de Logging para que Analistas de Segurança possam rastrear atividades visando a gerência da segurança da informação, de infraestrutura, auditoria de segurança e governança. Em casos necessários, a plataforma permite a consolidação de loggings em um repositório central. A seguir são listados três exemplos de registros:

• Logging de alteração dos principais objetos/processos do sistema;

• Logging de acessos;

• Trilhas de auditoria e governança.

Disponibilidade

Pensando em garantir um dos pilares fundamentais na segurança da informação, o Blazon conta com uma arquitetura capaz de ser disponibilizada em alta disponibilidade. Todos os seus principais componentes podem escalar de forma horizontal, de tal forma a mitigar eventuais riscos de indisponibilidade.

Há uma versão, que pode ser contratada sob demanda, que dota a Plataforma Blazon de escalabilidade, permitindo-lhe operar a partir de diversos sites (Datacenter/Nuvem), de tal modo que se uma instância se torna indisponível, outra instância passa a responder pelas funcionalidades da plataforma.

O Recurso é um dos objetos mais importantes do Blazon, ele tem como propósito a representação de um conjunto de Contas, Direitos e Membros de direitos de uma determinada aplicação. Além disso, é no Recurso que configuramos algumas necessidades que temos para gestão de acesso de uma determinada aplicação.

Para o Blazon, um Recurso pode ser uma Aplicação Web, Sistema Desktop, Dispositivos IOT, ou qualquer outro elemento que necessite de gestão de acessos, permitindo assim a gestão de praticamente qualquer elemento computacional.

De forma simplificada, um Papel nada mais é que um conjunto de Direitos e Recursos que Usuários herdam quando atrelados a este Papel.

Um Papel pode ser utilizado para representar cargos, funções ou grupos dentro de uma determinada organização. Esta abstração é muito útil, pois pode permitir a gestão de acessos baseadas na estrutura organizacional.

O controle de acesso baseado em papéis, normalmente citado como RBAC, é uma abordagem para restringir acessos à aplicações baseado em alguma característica do usuário. Usualmente, este papéis são modelados para representar o cargo, função, departamento ou algum outro atributo relevante do usuário.

No Blazon, um Papel pode ser associado a um conjunto de um ou mais Usuários e pode servir como mecanismo para a implementação do modelo RBAC.

Um papel também auxilia na abstração da complexidade dos sistemas alvo. Por exemplo, a nomenclatura utilizada em grupos do Active Directory pode não facilitar a solicitação por um usuário, assim, um papel pode abstrair esta complexidade a partir de um nome que represente algo conhecido pelo negócio.

Membros de um papel

Quando um Papel é atribuído a um Usuário, ele passa a compor a lista de membros desse papel. A relação entre um Usuário e um Papel é denominada Membro de Papel. Um usuário pode ser membro de zero ou mais papéis.

O Direito é um objeto do Diretório que pode ser concedido a uma Conta para permitir que esta execute ações em um determinado Recurso.

Além do objeto Direito o outro objeto importante para o gerenciamento de direitos é o Membro de direito. Um membro de direito é um objeto que representa a relação entre uma conta e um direito.

Direito

No Blazon, um Direito é um termo que expressa a atribuição de um Nível de Privilégio a uma conta. Determinados Recursos podem permitir um conjunto de atividades às quais serão desempenhadas por acessos específicos.

Por exemplo, um um arquivo pode ser escrito, lido e removido. Imagine que se queira atribuir apenas a permissão de leitura a este arquivo, então, um direito deve ser responsável por expressar esta permissão.

O Blazon nos permite especificar uma granularidade fina na gestão de acessos a Recursos, por meio do uso de Direitos. Além dos acessos garantidos por credenciais a um determinado Recurso, em muitos casos, se faz necessária a gestão granular de acessos a estes recursos. Um Direito serve como mecanismo que possibilita a gestão de cada um dos acessos de uma conta a um determinado recurso.

Um Direito pode representar um grupo, papel, perfil, permissão ou qualquer outro elemento utilizado para controlar permissões de ações sobre um aplicação alvo especificado.

Membros de direito

Quando a Conta de um Usuário recebe um Direito, o proprietário dessa conta passa a compor a lista de membros desse direito. E essa relação é denominada Membro de Direito. É possível que um usuário, através de suas contas, seja membro dos mais diversos direitos de acordo com o recurso aos quais esses direitos pertençam.

Via Console Administrativo, você pode realizar várias ações sobre os Direitos como:

• Criar um direito;

• Remover um direito;

• Definir o(s) dono(s) de um direito;

• Habilitar ou desabilitar certificações;

• Habilitar ou desabilitar self-service;

• Definir atributos de um direito.

Este documento irá guiá-lo para que você possa entender os principais conceitos e funcionamentos do Blazon. Aqui, será possível encontrar definições importantes para o entendimento correto sobre o funcionamento da plataforma.

O entendimento dos conceitos apresentados neste guia são fundamentais para que você possa utilizar a plataforma da melhor maneira possível, seja em sua utilização ou até mesmo na resolução de eventuais problemas.

Uma Conta é um objeto que representa uma credencial de acesso em um determinado Recurso. Ao possuir uma Conta em um determinado Recurso, entende-se que o usuário proprietário desta Conta possui acesso a aplicação na qual este recurso está relacionado. Em muitos casos, estas contas podem possuir características distintas, como:

• Contas de usuários comuns;

• Contas de administradores;

• Contas utilizadas para integração entre aplicações;

• Contas de administração local.

Considerando que cada tipo de Conta possui característica de gestão específica, o Blazon permite a categorização e a gestão dessas contas para tratar especificidades de diversos cenários de acessos. Desta forma, podemos representar todas as necessidades especificas de gestão para cada cenário necessário. O Blazon define atualmente 4 tipos de Contas, sendo:

• Contas Regulares;

• Contas de Aplicações;

• Contas Compartilhadas;

• Contas Administrativas.

Contas Regulares

Uma Conta do tipo Regular é responsável por representar dados de credenciais e identidades em uma aplicação, um dispositivo ou qualquer recurso que necessite de gerenciamento de acesso. Cada usuário pode possuir uma única Conta Regular por Recurso. O tipo Conta Regular tem as seguintes características:

• É uma conta nominal, individual, para a qual existe uma, e apenas uma, pessoa responsável por esse tipo de conta;

• É uma conta que pode ser solicitada via Portal de Auto-Serviço;

• É uma conta que pode ser certificada;

• É uma conta que pode utilizar o cofre de senha para armazenar as credenciais do usuário;

• É uma conta que não possui um mecanismo de expiração, sendo que caso esse tipo de conta necessite de revogação, isto terá de ser feito manualmente pelo administrador, por meio do processo de certificação, por reconciliação ou por processo de importação;

• É uma conta que pode utilizar dos mecanismos de rotação de senha, fazendo uso da rotação de senha e do cofre de senha, sendo que este tipo de conta pode sofrer alteração de forma periódica sem trazer muitos transtornos ao usuário;

• É uma conta que pode ter suas credenciais do Blazon sincronizadas na aplicação, sendo assim, sempre que o usuário trocar sua senha no Blazon, a senha será atualizada na aplicação;

• É uma conta que é atrelada ao status do usuário, sendo assim, sempre que um usuário é Inativado, suas contas regulares também o serão, sendo que, há exceções que podem ser tratadas a partir do uso das regras de Inativação (chamada de um Web Service que pode conter regras para analisar se é necessária a Inativação da conta em um determinado cenário).

Contas de Aplicações

O tipo de Conta Aplicação existe para permitir acessos que normalmente são utilizados para a comunicação entre duas aplicações distintas, como ocorre em cenários de integração.

Apesar da existência de protocolos como OAuth2, que permitem integrações sem a necessidade de uma credencial regular, em muitos cenários, ainda é necessária a criação de um acesso regular para que duas aplicações possam se comunicar de forma segura.

O Blazon oferece uma forma de gestão, para que contas que são utilizadas para estes cenários possam ser gerenciadas de forma mais adequada. Abaixo são relacionadas as características de uma Conta Aplicação:

• Não é uma conta nominal, isto é, não há uma pessoa que a possa utilizar normalmente, mas, contudo, é um tipo de conta que requer um responsável por ela;

• É uma conta que pode ser solicitada via portal de auto serviço;

• É uma conta que pode ser certificada;

• É um tipo de conta cujas credenciais são obrigatoriamente salvas no cofre de senhas e ninguém sabe (ou ninguém deveria saber) o valor dessas credenciais;

• É uma conta cujas formas de revogação são: pelo administrador no console administrativo, pelo processo de certificação, ou pelo processo de importação;

• É um tipo de conta que pode utiliza mecanismos de rotação de senha, para dificultar ataques.

Como se pode depreender das características, nenhum usuário deve conhecer as credenciais de uma Conta Aplicação, nem mesmo o responsável especificado. Recomenda-se fortemente que as credenciais de uma aplicação sejam obtidas por um agente que automaticamente busca as credenciais no cofre de senhas e a fornece para aplicação, não sendo necessário seu conhecimento pelo usuário.

Todavia, levando em consideração cenários de aplicações legadas, onde o investimento, ou alguma outra característica, impeça o uso deste agente, o Blazon oferece a possibilidade de o responsável pela conta solicitar a senha desta aplicação através do cofre de senha.

A solicitação da senha é auditada e é possível ao administrador verificar se o responsável pela conta conhece suas credenciais (da aplicação). Sendo assim, as credenciais desta aplicação passam a ser de total responsabilidade de seu dono (responsável).

Contas Compartilhadas

Contas Compartilhadas, como o próprio nome sugere, são contas cujas credenciais podem ser do conhecimento de mais de um usuário. Contas Compartilhadas devem, sempre que possível, ser evitadas. Entretanto, há muitos cenários nos quais este tipo de conta ainda se faz necessário.

Por exemplo, atualmente, um uso muito comum de contas compartilhadas é o cenário de uso de contas de redes sociais (Instagram por exemplo) corporativas, no qual mais de uma pessoa responde pela rede social da organização.

Neste cenário, muitas vezes, as credenciais de acesso nessa rede social são conhecidas por várias pessoas e isto pode acarretar em grandes riscos. Imagine por exemplo, um ex- colaborador que tenha sido desligado por justa causa e que conheça essas credenciais. Ele poderia fazer mal uso deste acesso para denegrir a imagem da empresa.

No Blazon, o tipo Conta Compartilhada possui características de gestão que permitem emitir um alerta de risco, sempre que um colaborador é demitido, de tal forma que uma nova credencial seja configurada para a aplicação. Deste modo, a conta compartilhada não mais poderá ser utilizada pelas credenciais conhecidas pelo colaborador demitido e as novas credenciais são colocadas à disposição dos colaboradores remanescentes. As principais características de uma Conta Compartilhada são:

• Não é uma conta nominal, individual, pois um grupo de usuários pode ter acesso às credenciais desta conta, sendo que, todavia, ela tem um responsável;

• É um tipo de conta que pode ser solicitada via Portal de Auto-Serviço;

• É um tipo de conta que pode passar por um processo de certificação periódico;

• É um tipo de conta que cujas credenciais são armazenadas no cofre de senhas;

• É um tipo de conta que não expira de forma automática;

• É um tipo de conta que é revogada manualmente pelo administrador ou no processo de certificação;

• É um tipo de conta para a qual sempre que um dos integrantes da conta compartilhada sai do grupo, um alerta de risco para a troca de senha é gerado.

Contas Administrativas

Contas Administrativas normalmente são caracterizadas por possuir um acesso privilegiado (“root”) a aplicações. Esse tipo de conta é utilizado muitas vezes para a administração completa da aplicação e é muito comum existir pelo menos um colaborador de posse desta credencial.

Idealmente, nenhum colaborador deveria conhecer essas credenciais. Para que isto ocorra, é necessário que a gestão da Conta Administrativa seja feita por um processo que evite, e torne desnecessária, a posse de tais credenciais.

O Blazon define o tipo Conta Administrativa e permite que contas deste tipo sejam cadastradas e armazenada em um repositório. Se houver necessidade de acesso para alguma conta deste tipo, o colaborador poderá solicitar as credenciais de acesso para as intervenções devidas, por meio de um Nome (Name) que é associada univocamente a esta conta. Isto permite que uma conta administrativa seja utilizada, mas o Blazon sempre saberá quem solicitou e qual o período da sessão de uso.

Sempre que um usuário faz a solicitação destas credenciais, o Blazon audita essas informações e, quando o usuário faz o checkout das credenciais, o Blazon obrigatoriamente, automaticamente, faz a mudança da senha na aplicação. Sendo assim, é sempre possível rastrear o responsável pelo uso de uma Conta Administrativa e, se for o caso, responsabilizá-lo no caso eventual de perda destas credenciais. As principais características de uma Conta Administrativa são:

• Não é um tipo de conta nominal, individual;

• É uma conta para a qual o responsável por esse tipo de conta, basicamente, é o usuário utilizado no processo de aprovação da solicitação das credenciais;

• É um tipo de conta que não possui mecanismo de certificação;

• É um tipo de conta que não possui provisionamento de usuário para a conta;

• É um tipo de conta que utiliza o cofre de senha para armazenamento das credenciais;

• É um tipo de conta na qual sempre que o usuário solicita as credenciais, o Blazon armazena os dados dessa solicitação para auditoria;

• É um tipo de conta que sempre que o usuário faz o checkout das credenciais, o Blazon faz a troca de senha.

• Via Console Administrativo, você pode realizar várias ações sobre as contas, como:

  • Remover uma conta;

  • Revogar uma conta;

  • Inativar uma conta;

  • Ativar uma conta;

  • Certificar uma conta.

Em qual cenário cada conta deve ser utilizada?

O Blazon é uma Plataforma de Gestão de Identidade & Acessos (IAM), que permite o gerenciamento de acessos a recursos coporativos de modo simples e seguro. O Blazon permite a concessão, manutenção e revogação de acessos, controle do ciclo de vida de colaboradores e a implementação de diversos controles críticos de segurança da informação, tais como Certificações de Acessos e Segregação de funções.

Por que utilizar o Blazon?

O Blazon pode ser utilizado para resolver uma série de problemas corporativos críticos, desde questões operacionais – como a quantidade de demandas atendidas manualmente, até questões relacionadas à Gestão da Segurança da Informação – como por exemplo, política de senhas e usuários com acessos indevidos. O Blazon também vai ser muito importante se você precisa apresentar evidências, diretas e indiretas, em casos de auditorias internas e/ou externas.

Para tentar contextualizar alguns dos desafios que o Blazon pode resolver, vamos analisar alguns possíveis cenários:

• Um novo colaborador é contratado e precisa que seus acessos sejam concedidos da maneira mais ágil possível. No primeiro dia de trabalho é importante para a organização que ele consiga acessar a rede corporativa, VPN, e-mail e demais aplicações corporativas.

• Em casos de férias e/ou afastamento, como poderiam ser inativados acessos a e-mail, rede corporativa ou qualquer outro acesso crítico? O Blazon faz isto transparente e automaticamente a partir de uma integração com alguma . Assim, sempre que um colaborador entra de férias, o Blazon recebe esta informação e propaga as inativações necessárias.

• E para os casos de novos acessos, para um colaborador que já faça parte dos quadros da organização? Por exemplo, se um colaborador precisar de acessos para a aprovações de vendas, cadastro de produtos etc? Neste caso, o Blazon conta com um portal de , que permite que os próprios colaboradores solicitem seus acessos.

• E nos casos de desligamento? Aqui, é de suma importância que a revogação dos acessos do colaborador desligado seja feita da maneira mais rápida possível, imediatamente.

Qual a versão mais adequada à sua Organização?

O Blazon pode ser utilizado em ambientes On Premise ou em Nuvem. Em sua versão On Premise, há a possibilidade de ser instalado em um servidor (físico ou virtual) ou ser instalado para utilizar todo o seu potencial de escalabilidade para rodar em diversos servidores (Scalable).

Para atender nichos de negócios diversificados, desde pequenas até grandes empresas, a Plataforma Blazon permite que seus componentes sejam montados em um mesmo processo, oferecendo uma versão Single Server. Deste modo, caberá à necessidade do negócio definir qual versão da Plataforma Blazon será utilizada (Single Server ou Scalable). Ambas as versões podem ser implantadas na infraestrutura da empresa (On Premise) ou em nuvem (On Cloud).

O Blazon é uma plataforma de Gestão de Identidade projetada para oferecer os mais altos níveis de qualidade em vários aspectos fundamentais, tais como usabilidade, segurança, desempenho, dentre outros. Modelada de acordo com as melhores práticas e padrões de engenharia de software, o Blazon foi construído tendo por base conceitos modernos em termos de alta disponibilidade e escalabilidade.

Componentes

A arquitetura é composta por um conjunto de camadas, estruturadas por uma série de componentes, responsáveis por prover todas as funcionalidades requeridas por processos corporativos relacionados à Gestão de Identidades, entregando um alto valor a processos ligados a Gerência de Segurança, Auditorias e Governança corporativa em Sistemas de Informação. A seguir são listados alguns dos principais módulos da plataforma:

Core Engine

Principal módulo, é aqui que a orquestração de fluxos de trabalhos, lógicas e demais aspectos fundamentais da governança e administração de identidades corporativas são executados;

Workspace

Uma aplicação chave para produzir uma experiência de usuário superior, facilitando o acesso a sistemas e recursos corporativos e oferecendo facilidades para solicitação de acessos e reset de senha, a um clique de mouse;

Admin Console

Como o próprio nome diz, é uma console para oferecer, aos vários níveis de administração e suporte, alto nível de usabilidade na manutenção das configurações do ambiente corporativo;

Resource Adapter

Um componente especialmente projetado para a integração transparente de recursos corporativos de TI pré-existentes, permitindo alto desacoplamento de sistemas legados;

Resource Adapter Interface

Este módulo visa abstrair os detalhes (físicos e lógicos) da conectividade com os sitemas legados, permitindo que novos Resource Adapters sejam desenvolvidos e integrados transparentemente à plataforma em plena operação;

Job Manager

O modelo de processamento utilizado, para permitir alta escalalbilidade e operação em nuvem, é rico em Tarefas assíncronas, sendo a atribuição deste módulo a gerência desse universo de tarefas;

API Server

Uma interface aberta para o desenvolvimento de Add-ons (novas aplicações) que permite imensa liberdade ao departamento de TI da organização em termos de novos desenvolvimentos;

OAuth2 Authorization Server

Servidor especializado em autorizações específicas para aplicativos Web, Lapttop/Desktop, Smartphones e IoT existentes no ambiente corporativo;

SSO & MFA

Módulos especializados em oferecer uma autenticação única (para os acessos disponíveis no Workspace), com a possibilidade de requerer vários fatores de autenticação (MFA – Multifactor Authentication) dependendo do contexto de acesso aos recursos.

Resumo

Modelada para operar em nuvem, as camadas da arquitetura foram projetadas a partir de componentes bem definidos e com alto grau de desacoplamento, permitindo a instalação e operação independentes, requisito essencial de plataformas em nuvem.

Visando a experiência de usuários (QoE – Quality of Experience), a arquitetura foi projetada para garantir os tempos de respostas independentemente do volume de acessos, permitindo afirmar que todos os componentes apresentados na figura anterior podem ser escalados horizontalmente, independentemente da localização e distribuição geográfica, como se espera de uma plataforma cloud enabled.

Altamente modularizada, se houver necessidade, sob demanda, quaisquer dos componentes apresentados na figura podem ser adicionados à medida que a maturidade em governança e administração de Identidade evolua ao longo do tempo. Isto permite que uma organização planeje seus investimentos de acordo com sua maturidade e somente tenha desembolsos à medida que os componentes da plataforma sejam mandatórios em seus processos de segurança, governança e auditorias.

Modelo de processamento

Essencial para decisões de projeto, o Modelo de Processamento implica diretamente na arquitetura de um sistema. Considerando os requisitos não funcionais atuais (segurança, alta disponibilidade, escalabilidade, usabilidade, accountability) e os cenários de operação (on premise e borda/nuvem), o projeto da arquitetura considerou o seguinte:

• A arquitetura em seu todo utiliza um modelo de processamento no qual todo o trabalho necessário é divido temporal e espacialmente, visando a não sobrecarga da plataforma como um todo e, tampouco, seus módulos em particular;

• Todas as requisições são tratadas de forma assíncrona, permitindo que os módulos sejam desacoplados (podendo inclusive ser instalados em sites completamente distintos) e, deste modo, reduz-se ao máximo timeouts e notificações de exceções;

• Este modelo de processamento evita que um grande volume de trabalho sobrecarregue e interrompa o funcionamento da plataforma, e é essencial para escalabilidade horizontal.

Gerenciamento de sessão

Uma sessão é caracterizada pelo intervalo de tempo decorrido entre o instante em que um usuário é autenticado até o instante em que o acesso é encerrado, sendo que neste intervalo de tempo, o usuário pode requerer a execução de tarefas. Gerenciar uma sessão é então o processo de garantir que um usuário somente terá o acesso para o intervalo de tempo que lhe é outorgado e que esse usuário somente execute tarefas para as quais possui direito. Do mesmo modo, a gerência de sessão deve garantir que apenas o usuário autenticado poderá executar tarefas na sessão para a qual foi autenticado e registrar todas as atividades visando a rastreabilidade do acesso. Os seguintes componentes listados abaixo possuem manutenção de estado para sessão web:

• Admin console;

• Password Reset;

• Workspace;

• OTP Management; e

• Web SSO.

Existem várias abordagens para a manutenção deste estado. A manutenção deste estado foi projetada para ser feita localmente, por meio de memória local, ou descentralizada por meio de configuração, utilizando Memcached, Redis ou uma base de dados relacional.

Resource Adapters

A Gestão de Identidade permeia todos os sistemas e recursos da corporação, desde sistemas pré-existentes na organização, bem como novos sistemas. Além disso, recursos físicos tais como catracas e portas podem (e deveriam) fazer parte de uma plataforma de Gestão de Identidade. Deste modo, integração de sistemas é uma das chaves para o sucesso de um projeto bem sucedido.

A arquitetura tem uma camada (Resource Adapters Layer) especialmente projetada para integrar transparentemente todos os sistemas existentes numa corporação. Visando escalabilidade e funcionamento em nuvem, esta camada foi projetada completamente desacoplada do Core Engine da plataforma, permitindo que esses adaptadores (RA) rodem em um mesmo ambiente ou em ambientes distintos, incluindo diferentes nuvens. Esses adaptadores podem ser construídos facilmente, inclusive desenvolvidos pela equipe de TI da organização, a partir de um template de RA. A Blazon Technologies oferece a capacidade de Add-on, com a finalidade de dar o máximo de independência aos clientes. A arquitetura foi projetada com as seguintes abordagens:

• Comunicações entre a plataforma e aplicações/sistemas se dão por meio de componentes do tipo Resource Adapter;

• Resource Adapters se comunicam com o módulo Core Engine por meio de comunicação assíncrona utilizando um Modelo de Pulling;

• Aplicações indisponíveis não interferem no funcionamento e na garantia dos processos de provisionamento/reconciliação da plataforma;

• Aspectos de segurança nas comunicações entre o módulo Core Engine e RAs são garantidos por meio de HTTPS e OAUTH2.

Escalabilidade

Escalabilidade é essencial quando se olha para os requisitos de alta disponibilidade e experiência de usuários (tempo de resposta). A arquitetura foi projetada para suportar escalabilidade horizontal, na qual instâncias podem ser invocadas em diferentes sites, transparentemente à operação, e passam a responder automaticamente por requisições. Esta capacidade resolve questões ligadas a alta disponibilidade, balanceamento de carga e tempo de resposta a solicitações de usuários. Os seguintes aspectos merecem ser ressaltados:

• Com exceção do módulo Job Manager, todos os demais componentes da arquitetura são passíveis de ser escalados horizontalmente fácil e transparentemente;

• Componentes que requerem Gerenciamento de Sessão Web precisam de garantir o correto uso da sessão e, para isto, pode-se delegar a sessão para algum componente, como já descrito ou pode-se também utilizar de mecanismos como Sticky Session.

Um usuário é um objeto que possui 3 principais elementos, sendo eles: ciclo de vida, atributos e acessos.

O ciclo de vida descreve os seus possíveis estados, os atributos descrevem as características destes usuários, tais como nome, nome de usuário, cargo e departamento. Já os acessos são de fato as credenciais e permissões que o mesmo possui em aplicações.

Atributos

Os atributos descrevem de maneira geral as características de um determinado usuário. Estes atributos podem ser sincronizados por uma ou alterados diretamente no Blazon.

O Blazon possui um conjunto de atributos padrão para um usuário e você pode configurar campos adicionais para armazenar características específicas dos seus usuários. Para alterar as configurações dos atributos do usuário, acesse o .

Ciclo de vida

Todo usuário possui um ciclo de vida, um ciclo de vida nada mais é que a representação de um usuário em determinado momento. No Blazon, o ciclo de vida é composto por usuários nos estados: ATIVOS, INATIVOS, REVOGADOS e REMOVIDOS. O usuário pode atingir cada um destes estados quando uma determinada ação é executada diretamente no Blazon, ou por meio de um evento de uma .

Acessos

A gestão de identidade tem como principio a gestão de acessos desta terminada identidade. Sendo assim, os acessos nada mais são do que os recursos que um determinado usuário possui acesso e o Blazon permite a concessão e revogação dos mesmos.

Um acesso pode ser concedido por meio do , ou por meio de .

Durante o ciclo de vida de um usuário, o mesmo pode estar em quatro possíveis estados: ATIVO, INATIVO, REVOGADO e REMOVIDO.

Cada um destes estados pode ser alcançado a partir de uma das quatro possibilidades:

• Manualmente: as ações manuais podem ocorrer a partir do Admin console e/ou a partir do Workspace. Um usuário pode ser criado, ativado, inativado, revogado e removido manualmente;

• Importação: o usuário pode ser criado, ativado, inativado, revogado e removido por meio de um processo de importação;

• Reconciliação: Os processos de reconciliação permitem a criação, ativação, inativação e revogação de um usuário;

• Automático: Existem processos automáticos que podem revogar usuários automaticamente quando os mesmos estão inativos por um determinado tempo.

Neste diagrama, é possível verificar as transições de estados possíveis para um usuário, bem como as formas possíveis de executar estas transições.

Um usuário removido não pode ter seu estado alterado e é importante citar que após alcançar o estado de removido, o mesmo será excluído definitivamente do diretório após um período.

As possíveis transições, apresentadas no diagrama, podem ser resumidos como:

As seções a seguir detalham as ações que ocorrem quando a transição entre os estados de um usuário acontece.

Um usuário pode ser removido nas seguintes situações:

• Manualmente, por meio do Admin console;

• Por meio de uma importação;

• De form automática, após a revogação de um usuário.

O usuário pode ser removido de duas formas, sendo (i) uma remoção apenas no diretório local ou (ii) uma remoção devida a uma ação Revogação.

O que acontece após a revogação de um usuário?

Sempre que um usuário é removido, seu campo status é modicado para Removido e as seguintes ações são executadas:

• As contas regulares do usuário são removidas;

• Suas contas temporárias são removidas;

• Seus papéis são removidos;

• Caso o usuário seja responsável por algum recurso, direito, papel, conta de aplicação ou organização, é criado um evento de mudança de proprietário.

• Caso o usuário possua check-in para alguma conta administrativa, será executado o check-out para a referida conta.

• Caso o usuário seja administrador de alguma conta de aplicação, é gerada uma entrada para mudança de administrador (ou continuidade) desta conta.

• Caso o usuário seja membro de alguma conta compartilhada, é gerada uma entrada para remoção do usuário como membro desta conta;

Após a remoção de todos os objetos relacionados ao usuário removido, o mesmo é removido permanentemente do diretório.

Um usuário pode ser ativado nas seguintes situações:

• Manualmente, por meio do Admin console;

• Manualmente, via Workspace, pelo usuário responsável;

• Por meio de uma importação;

• Por algum evento de reconciliação.

O que acontece após a ativação de um usuário?

Sempre que um usuário é ativado, seu campo status é modicado para Ativo e as seguintes ações são executadas:

• As contas regulares do usuário são submetidas a reativação;

• Caso haja eventos de mudança de proprietário relacionados a este usuário, estes eventos são cancelados.

Um usuário pode ser revogado nas seguintes situações:

• Manualmente, por meio do Admin console;

• Manualmente, via Workspace, pelo usuário responsável;

• Por meio de uma importação;

• Por algum evento de reconciliação;

• Por meio de um processo de revalidação de usuário.

O que acontece após a revogação de um usuário?

Sempre que um usuário é inativado, seu campo status é modicado para Inativo e as seguintes ações são executadas:

• As contas regulares do usuário são revogadas;

• Suas contas temporárias são revogadas;

• Seus papéis são revogados e, consequentemente, todos as contas por ele gerenciadas também são revogadas;

• Caso o usuário seja responsável por algum recurso, direito, papel, conta de aplicação ou organização, é criado um evento de mudança de proprietário.

• Caso o usuário possua check-in para alguma conta administrativa, será executado o check-out para a referida conta.

• Caso o usuário seja administrador de alguma conta de aplicação, é gerada uma entrada para mudança de administrador (ou continuidade) desta conta.

• Caso o usuário seja membro de alguma conta compartilhada, é gerada uma entrada para remoção do usuário como membro desta conta;

• Após a revogação de todos os acessos do usuário, este usuário é transitado para um estado de REMOVIDO, e o mesmo é excluído permanentemente do diretório.

Um Resource Adapter é um componente que permite que qualquer aplicação se comunique com o Blazon. Os Resource Adapters são utilizados para o envio e recebimento de eventos nos processos de reconciliação e provisionamento. O Core Engine ao invés de se conectar diretamente a uma aplicação, se comunica com um Resource Adapter, que por sua vez tem como um dos seus principais objetivos o envio de mensagens conhecidas para uma aplicação.

Cada Resource Adapter deve ser desenvolvido especialmente para cada tipo de aplicação que ele integra. Depois de especificado, desenvolvido, testado e implantado, ele precisa ser configurado na plataforma para que ele possa ser utilizado.

Funcionalidades

Um Resource Adapter possui um conjunto de funcionalidades que permitem que o Blazon forneça todas as características necessárias para o funcionamento de um processo de gestão de identidade. As principais funcionalidades de um Resource Adapter são:

• Fazer o pulling de eventos de provisionamento contidos no Core Engine;

• Transformar cada evento de provisionamento em um comando reconhecido pela aplicação na qual ele se integra;

• Garantir a resiliência do processo de provisionamento a partir do uso de novas tentativas de provisionamento caso seja necessário;

• Enviar o conjunto de credenciais para o Cofre de Senhas do usuário após o provisionamento de uma determinada conta;

• Buscar dados em uma determinada aplicação e criar os eventos de reconciliação pertinentes no Core Engine;

• Auxiliar no processo de Password Management.

Principais características

Algumas da principais características chaves de um Resource Adapter:

• Oferecer mecanismos de resiliência para as integrações entre o Blazon e as aplicações;

• Ser um mecanismo de fácil desenvolvimento e manutenção;

• Não comprometer a funcionalidade do Core Engine;

• Executar em ambientes distintos do Core Engine.

A manutenção de um papel, para a adição e remoção de recursos e direitos, é realizada no Admin console. Toda manutenção gera uma entrada de alteração do Papel e esta alteração pode ser submetida a aprovações e validações de conflitos, conforme descrito na imagem abaixo:

O fluxo para alteração de um papel, que pode ser visto na imagem acima, permite que a alteração de um papel possua um registro de alteração detalhado, e diminui a chance de alteração de um papel de forma indevida, uma vez que é possível obter a aprovação das pessoas/equipes responsáveis. A listagem abaixo detalha este fluxo:

1. Um item é adicionado/removido de um papel, a partir do Admin console;

2. Assim que um item é adicionado ou removido de um papel, uma entrada de alteração de papel é criada e a mesma é submetida a uma política de aprovação, que verifica a necessidade de aprovação pelo responsável do papel.

   1. Caso a alteração seja negada, a entrada de alteração é finalizada e o papel não sofre alteração;

   2. Caso a alteração seja aprovada, a entrada é enviada a etapa 3 do fluxo de alteração do papel.

3. No passo 3, os itens que estão sendo adicionados são verificados na matrix de conflito de segregação de funções e caso um conflito seja encontrado e haja uma política configurada, a modificação é submetida para aprovação do responsável;

4. No quarto passo, a entrada é submetida a uma política de proprietário de acesso e caso haja uma política que de match, a entrada é submetida para aprovação;

5. No quinto e último passo, é verificada a existência de conflito entre os novos itens e os itens já existentes em um papel e caso algum seja encontrado a entrada de alteração é submetida para aprovação.

Após a execução de todo o fluxo e as aprovações necessárias, as modificações solicitadas são aplicadas no papel.

O que acontece após a finalização do fluxo de aprovações?

Após a finalização de todo o fluxo de aprovação, o Blazon executa a adição ou remoção do recurso/direito no papel alterado. A adição e/ou remoção de itens em um papel dispara uma série de ações que são descritas nos tópicos abaixo.

Adição de recursos

Assim que um recurso é adicionado a um papel, temos:

• Os usuários deste Papel herdam o acesso ao Recurso recém adicionado;

• Caso o usuário já possua uma conta no Recurso em questão, esta conta passa a ser gerenciada por este Papel;

• Caso o usuário ainda não possua a conta no recurso adicionado a mesma é criada no diretório e um evento de provisionamento é criado, caso aplicável.

Remoção de recursos

Quando um Recurso é removido de um Papel, temos:

• As contas pertinentes ao recurso e ao papel em questão são revogados do Usuário;

Adição de direitos

Assim que um direito é adicionado a um papel, temos:

• Os usuários deste papel herdam o direito de acesso especificado;

• Caso o usuário já possua o direito especificado, esta conta passa a ser gerenciada por este Papel;

• Caso o usuário ainda não possua o direito adicionado o mesmo é criado no diretório e um evento de provisionamento é criado, caso aplicável.

Remoção de direitos

Quando um direito é removido de um papel, temos:

• Os membros de direitos pertinentes gerenciados pelo papel são revogados do usuário;

Sempre que um novo Usuário é criado ele é inserido no diretório do Blazon. Porém, é importante o entendimento de alguns aspectos desta criação:

• Todo usuário é criado por padrão com o status ATIVO;

• Quando um usuário é criado, antes de ser inserido no diretório do Blazon, um nome de usuário é determinado a partir de uma política de nome de usuário.

Como um usuário pode ser criado?

• Um novo usuário pode ser criado diretamente no ;

• Ele pode ser solicitado via ;

• Pode ser importado a partir do ;

• Ou ele ainda pode ser criado a partir de um evento de reconciliação de uma .

O que pode impedir a criação de um novo usuário?

• De acordo com as configurações de seus atributos, seus atributos obrigatórios devem ser preenchidos, caso contrário o usuário não será criado;

• Se um nome de usuário disponível não for encontrado.

O que acontece após a criação de um novo usuário?

Após a inserção do usuário no diretório, uma série de processos são iniciados e este usuário passa a ser monitorado de acordo com todas as políticas definidas no Blazon. Alguns exemplo do que pode ocorrer:

• O usuário pode receber uma notificação de criação, de acordo com as configurações definidas no ;

• Uma política de atribuição pode dar match, e o usuário poderá ser inserido em um papel e herdar os acessos nele definido;

• A validação de campos como organização, responsáveis e outros são monitorados para garantir que estão de acordo com o configurado.

Um usuário pode ser inativado nas seguintes situações:

• Manualmente, por meio do Admin console;

• Manualmente, via Workspace, pelo usuário responsável;

• Por meio de uma importação;

• Por algum evento de reconciliação.

O que acontece após a inativação de um usuário?

Sempre que um usuário é inativado, seu campo status é modicado para Inativo e as seguintes ações são executadas:

• As contas regulares do usuário são submetidas a inativação;

• Caso o usuário seja responsável por algum recurso, direito, papel, conta de aplicação ou organização, é criado um evento de mudança de proprietário.

• Caso o usuário possua check-in para alguma conta administrativa, será executado o check-out para a referida conta.

• Caso o usuário seja administrador de alguma conta de aplicação, é gerada uma entrada para mudança de administrador (ou continuidade) desta conta.

• Caso o usuário seja membro de alguma conta compartilhada, é gerada uma entrada para remoção ou para continuidade do usuário como membro desta conta.

Quando um usuário permanece inativado por um longo período de tempo, pode ser interessante revogá-lo de maneira automática. Você pode definir esta configuração seguindo .

Para a Reconciliação de usuários, as regras de associação dos dados reconciliados com as informações presentes no BLAZON podem ser configuradas utilizando-se diferentes combinações de atributos que um usuário possui, como por exemplo username, primeiro nome, último nome, e-mail, status entre outros. Cada condição será validada de acordo com o operador e o valor escolhidos para o atributo em questão.

É importante ressaltar que o valor a ser comparado numa condição pode ser fixo, variável de acordo com os dados da reconciliação, representado pelo nome do campo entre chaves e colchetes (exemplo: {[username]}), ou ainda uma concatenação de ambas, partes fixas e variáveis (exemplos: Sistema {[nomeDoSistema]}, {[firstName]}.{[lastName]}).

O perfil de reconciliação seleciona qual ação será tomada pelo BLAZON, de acordo com a situação especificada pelas regras de associação. Para reconciliações de usuários, estão disponíveis as ações de criação, atualização, remoção e resolução manual de conflitos. É possível mapear uma ação para cada uma das situações que uma reconciliação de usuário pode encontrar, quais sejam:

1. Conflito de entrada: esta situação ocorre quando o BLAZON encontra mais de um usuário que se encaixa nas regras de associação especificadas;

2. Entrada encontrada: esta situação (esperada) ocorre quando o BLAZON encontra somente um usuário que se encaixa nas regras de associação especificadas; ou

3. Entrada não encontrada: esta situação ocorre quando o BLAZON não encontra um usuário que se encaixe nas regras de associação especificadas.

No que tange o mapeamento de atributos, é possível definir quais atributos do usuário deverão ser criados ou alterados – a depender da ação a ser tomada pelo BLAZON – e, além disso, se essa criação ou atualização dos dados do usuário deverá ser feita integral ou parcialmente através da opção de reconciliação incremental.

O mapeamento dos atributos segue o mesmo princípio utilizado na declaração de valores das regras de associação, ou seja, os atributos podem ser mapeados estaticamente, dinamicamente através da representação do nome do campo entre chaves e colchetes, de forma mista – quando há a utilização de mais de um modo de mapeamento – ou ainda utilizando BeanShell2 [28], que retornará o valor a ser atribuído ao campo desejado.

Para Reconciliação de Membership Entitlement, as regras de associação são distribuídas em duas partes: (i) regras que avaliam os dados reconciliados relativos aos atributos da conta e (ii) as regras que avaliam os dados relativos ao Entitlement do recurso configurado

no perfil. Cada condição será validada de acordo com o operador e o valor escolhidos para o atributo em questão. Da mesma forma que em um perfil de reconciliação de usuários, o valor a ser comparado numa condição pode ser fixo, variável ou misto.

O comportamento do perfil trata de qual ação será tomada pelo BLAZON, de acordo com a situação encontrada, dadas as regras de associação especificadas. Para reconciliações de Membership Entitlement, estão disponíveis as ações de concessão do Entitlement, revogação do Entitlement, resolução automática e manual de conflitos. É possível mapear uma ação para cada uma das situações que uma Reconciliação de Membership Entitlement pode encontrar:

1. Conta e Entitlement não encontrados: esta situação ocorre quando o BLAZON não encontra nem a conta e nem o Entitlement reconciliados de acordo com as regras de associação especificadas;

2. Conta encontrada e Entitlement não encontrado: esta situação ocorre quando o BLAZON encontra somente a conta e não encontra o Entitlement reconciliado de acordo com as regras de associação especificadas;

3. Conta não encontrada e Entitlement encontrado: esta situação ocorre quando o BLAZON não encontra a conta, mas encontra o Entitlement reconciliado de acordo com as regras de associação especificadas;

4. Conflito de entrada ou conflito de proprietário: esta situação ocorre quando o BLAZON encontra mais de uma conta ou mais de um Entitlement de acordo com as regras de associação especificadas;

5. Entrada encontrada: esta situação ocorre quando a relação de Membership Entitlement já existe entre a conta e o Entitlement reconciliado no diretório do BLAZON; ou

6. Entrada não encontrada: esta situação ocorre quando a conta e o Entitlement reconciliados foram encontrados, mas ainda não existe a relação de Membership Entitlement no diretório do BLAZON.

Não há mapeamento de atributos em uma reconciliação de Membership Entitlement.

Um dos principais mecanismos e responsabilidades relacionados aos processos de gestão de identidade e acessos, é garantir o sincronismo entre uma fonte autoritativa de dados e aplicações.

Este sincronismo visa garantir que acessos solicitados sejam de fato criados nas aplicações e que acessos não mais necessários sejam de fato revogados. Além disso, esse sincronismo permite o monitoramento de aplicações para que os acessos ali presentes, realmente devam existir.

Para a garantia deste sincronismo, o Blazon conta com três componentes principais, sendo eles: um módulo de provisionamento, responsável pelo envio de informações que são criadas e/ou alteradas no Blazon; um módulo de reconciliação, responsável por monitorar aplicações alvo e garantir que os dados ali presentes sejam válidos; por último, o resource adapter, que é o componente responsável por executar os eventos de provisionamento e reconciliação.

Provisionamento

Para que os dados presentes no diretório do Blazon sejam sincronizados com aplicações externas, é utilizado um mecanismo conhecido como provisionamento. O provisionamento tem como principal objetivo sincronizar os dados que são alterados no Blazon com as aplicações externas, exemplo: quanod um usuário solicita um novo acesso e o mesmo é aprovado e inserido no diretório, um evento de provisionamento é criado para que este acesso seja de fato criado na aplicação.

Reconciliação

A reconciliação é o processo inverso do provisionamento, ele visa garantir que as informações em uma determinada aplicação sejam conhecidas e gerenciadas pelo Blazon. Exemplo: um usuário que existe em uma fonte autoritativa, deve ser criado no diretório do Blazon, ou um acesso criado de forma indevida deve ser descoberto e ações cabíveis devem ser disparadas pelo Blazon.

Resource adapters

O Resource adapter é o componente principal para a garantira do sincronismo entre o Blazon e as aplicações gerenciadas pelo Blazon. Ele é responsável por manipular os eventos de provisionamento e reconciliação e sua função é se comunicar com uma aplicação, por meio de protocolos específicos como por exemplo LDAP, SOAP ou até mesmo RESTful APIs.

Sincronismo entre o Blazon e aplicações alvo

A partir dos componentes descritos anteriormente, o Blazon é capaz de enviar e receber informações de aplicações alvos e garantir que apenas os acessos necessários estejam de fato ativos.

A imagem a seguir ilustra de forma resumida a relação entre estes componentes:

Sempre que um novo objeto é inserido no diretório do Blazon é iniciado um processo para verificar a necessidade de sincronismo entre este novo objeto e a aplicação alvo. De acordo com as configurações de provisionamento, um evento é criado e o resource adapter é responsável por realizar o pooling deste evento e enviá-lo da maneira adequada para a aplicação alvo.

No caminho inverso, o resource adapter é responsável por monitorar uma aplicação alvo, descobrir alterações e enviá-las ao Blazon para que ele verifique as ações que devem ser aplicadas a este evento. Basicamente todos os objetos do diretório podem ser reconciliados, exceto recursos, papéis e membros de papéis.

As seções a seguir discutem de forma detalhada o funcionamento de cada um do três componentes introduzidos aqui.

As requisições da categoria Usuários, permite que façamos a manipulação de todo o ciclo de vida do mesmo, que vai da sua criação até a sua remoção. Além disso, é possível solicitar o bloqueio e desbloqueio de login, além de solicitar o reset de senha de um usuário.

O provisionamento automático é um tipo de provisionamento que garante que os eventos de provisionamento que acontecem no Blazon, sejam refletidos de forma automática nas aplicações. O processo de provisionamento automático conta com uma série de funcionalidades para garantir que o provisionamento seja executado com sucesso.

Arquitetura

O provisionamento automático conta basicamente com 4 componentes para sua execução:

• O Core Engine é responsável pela gestão e configurações do processo de provisionamento;

• O Resource Adapter Interface é o componente que realiza a integração entre o Core Engine e os Resource Adapters;

• O Resource Adapter é responsável pela integração com as aplicações;

• A Aplicação é o elemento que deseja-se gerenciar.

Entendendo o fluxo de provisionamento

O processo de provisionamento consta basicamente de 4 passos, descritos abaixo:

1. Um evento de provisionamento automático é criado (Clique aqui e veja quando um evento de provisionamento é criado.)

2. O Resource Adapter realiza o pulling do evento criado

   1. O Resource Adapter armazena o evento em sua base de dados locais

3. O Resource Adapter envia o comando de provisionamento adequado para a aplicação

   1. O Resource Adapter salva o status de sucesso do provisionamento

4. O Resource Adapter notifica o Blazon que o provisionamento foi executado.

Gerenciamento de falhas

Os passos descritos anteriormente partem do pressuposto que o provisionamento ocorreu com sucesso, porém em várias ocasiões isto pode não acontecer. Por exemplo: a aplicação pode estar indisponível, os dados enviados pelo Resource Adapter podem ser inválidos, os dados de conexão podem estar incorretos e etc.

A arquitetura dos Resource Adapters e do Blazon possuem um conjunto de funcionalidades que garantam a resiliência do processo de provisionamento.

Tentativas de provisionamento

O Resource Adapter possui um conjunto de configurações que permitem que em casos de falha entre o Resource Adapter e a aplicação, o próprio Resource Adapter faça novamente outras tentativas de provisionamento. Nestas configurações é possível configurar por exemplo por quanto tempo essas tentativas devem ser feitas e quantas tentativas devem ser realizadas antes que o Resource Adapter envie um evento de falha para o Blazon.

Erro no provisionamento

Quando o Resource Adapter não consegue realizar o provisionamento, o mesmo deve informar ao Core Engine que o evento de provisionamento não teve sucesso. Ao reportar, o Core Engine coloca a entrada de provisionamento em no status de WAITING_FAILOVER_RESOLVING, e a engine de provisionamento encaminha a entrada para o processo de provisionamento manual, de acordo com as configurações definidas.

Uma requisição do tipo Revoga usuário, permite a inserção de novos usuários no diretório do Blazon.

Como criar uma requisição?

• A partir do Admin console;

• A partir do Workspace.

É possível a criação em lotes desta requisição?

Sim, você pode criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

Para reconciliação de direitos, as regras de associação dos dados reconciliados com as informações presentes no BLAZON podem ser configuradas utilizando-se combinações de atributos que o Entitlement do recurso possui configurado no perfil. Cada condição será validada de acordo com o operador e o valor escolhidos para o atributo em questão. Da mesma forma que em um perfil de reconciliação de usuários, o valor a ser comparado numa condição pode ser fixo, variável ou misto.

O comportamento do perfil trata de qual ação será tomada pelo BLAZON de acordo com a situação encontrada dadas as regras de associação especificadas.

Para reconciliações de Entitlements, estão disponíveis as ações de criação, atualização, remoção e resolução manual de conflitos. É possível mapear uma ação para cada uma das situações que uma reconciliação possa encontrar:

1. Conflito de entrada: esta situação ocorre quando o BLAZON encontra mais de um Entitlement que se encaixa nas regras de associação especificadas;

2. Entrada encontrada: esta situação ocorre quando o BLAZON encontra somente um Entitlement que se encaixa nas regras de associação especificadas; ou

3. Entrada não encontrada: esta situação ocorre quando o BLAZON não encontra um Entitlement que se encaixe nas regras de associação especificadas.

Na parte de mapeamento de atributos, é possível definir quais atributos do Entitlement deverão ser criados ou alterados – dependendo da ação a ser tomada pelo BLAZON – e, ainda, se essa criação ou atualização dos dados do Entitlement deverá ser feita integral ou parcialmente através da opção de reconciliação incremental. O mapeamento dos atributos pode ser feito de forma estática, dinâmica, mista ou através da utilização de BeanShell, como descritos no perfil de reconciliação de usuário.

Uma requisição do tipo Reset de senha, permite a inserção de novos usuários no diretório do Blazon.

Como criar uma requisição?

• A partir do Admin console.

É possível a criação em lotes desta requisição?

Sim, você pode criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

Para Reconciliação de contas, as regras de associação são distribuídas em duas partes: (i) regras que avaliam os dados reconciliados relativos aos atributos da conta e (ii) as regras que avaliam os dados relativos ao proprietário da conta. Cada condição será validada de acordo com o operador e o valor escolhidos para o atributo em questão. Da mesma forma que em um perfil de reconciliação de usuários, o valor a ser comparado numa condição pode ser fixo, variável ou misto.

Como uma conta é uma entidade cuja existência extrapola os limites de gestão do BLAZON, além das ações de criação, atualização, remoção e resolução manual de conflito

da conta, somente dentro do gerenciador de acessos, são disponibilizadas também as ações de criação, atualização, revogação e resolução automatizada de conflito da conta do sistema ao qual a conta pertence, gerando entradas de provisionamento automáticas ou manuais quando necessárias. É possível mapear uma ação para cada uma das situações que uma reconciliação de conta pode encontrar:

1. Conta e proprietário não encontrados: esta situação ocorre quando nem a conta e nem o proprietário da conta são encontrados no BLAZON, de acordo com as regras de associação especificadas;

2. Conta encontrada e proprietário não encontrado: esta situação ocorre quando a conta existe no BLAZON, mas o proprietário da conta não foi encontrado, de acordo com as regras de associação especificadas;

3. Conta não encontrada e proprietário encontrado: esta situação ocorre quando o proprietário existe no BLAZON mas a conta não é encontrada, de acordo com as regras de associação especificadas;

4. Conflito de entrada ou conflito de proprietário: esta situação ocorre quando mais de uma conta ou mais de um usuário são encontrados no BLAZON de acordo com as regras de associação especificadas;

5. Entrada encontrada: esta situação ocorre quando ambos – a conta e o proprietário – são encontrados e a conta já está mapeada como pertencente ao proprietário encontrado de acordo com as regras de associação especificadas; ou

6. Entrada não encontrada: esta situação ocorre quando ambos – a conta e o proprietário – são encontrados, porém a conta está associada a um proprietário diferente daquele encontrado de acordo com as regras de associação especificadas.

Os atributos passíveis de criação ou atualização em um perfil de Reconciliação de Conta são os atributos da conta, de acordo com a ação a ser tomada pelo BLAZON. Também é possível que a criação ou atualização dos dados da conta sejam feitos de forma integral ou parcial através da opção de reconciliação incremental. O mapeamento dos atributos pode ser feito de forma estática, dinâmica, mista ou através da utilização de BeanShell, como descritos no perfil de reconciliação de usuário.

Sempre que uma intervenção manual precisa ser realizada nos objetos Usuário, Conta, Membro de direito ou Membro de papel, uma nova requisição é criada.

As requisições são responsáveis, por exemplo, por permitir que usuários solicitem novos acessos. Além disso, no Admin console, é possível fazer uma requisição para ações tais como Revogação de contas, Ativação e Desativação de usuários.

Para cada tipo de ação necessária, o Blazon possui uma requisição que permite sua execução, o tópico a seguir descreve de forma geral cada um dos tipos de requisições existentes no Blazon.

Tipos de Requisição

O Blazon conta atualmente com 20 tipos de requisições, dividas em 4 categorias, descritas na tabela abaixo:

Fluxo de uma nova requisição

A execução de uma nova requisição passa por um ciclo de vida que é composto por até 5 etapas. Cada uma destas etapas é responsável por alguma ação e a depender do tipo de requisição, a execução de algumas destas etapas podem não ser necessárias. A imagem a seguir detalha esteas 5 etapas:

A seções a seguir detalham o funcionamento de cada uma das requisições apresentadas aqui.

O provisionamento é o processo que permite que os acessos gerenciados pelo Blazon possam ser concedidos nas aplicações necessárias. Todo e qualquer acesso concedido pelo Blazon deve ser criado nas aplicações, e o processo de provisionamento é o mecanismo responsável por isto.

Eventos de provisionamento

O Blazon conta atualmente com onze tipos de eventos de provisionamento. Estes eventos permitem a cobertura de todo o ciclo de vida de acessos.

Cada um destes eventos podem ser configurados permitindo o correto provisionamento. No Blazon, o provisionamento pode ser executado de duas maneiras, sendo elas: Automática ou Manual.

Provisionamento automático

Apesar de importante, nem todos os eventos de provisionamento citados anteriormente podem ser possíveis de automação, ou até mesmo alguma aplicação específica pode não possuir essa capacidade, nestes casos, podemos trabalhar o provisionamento de forma manual.

Provisionamento manual

Resumo

• Provisionamento é o mecanismo que permite a concessão/revogação de acessos nas aplicações necessárias;

• O Blazon possui onze tipos diferentes de provisionamento (Criação de contas; Atualização de contas; Inativação de contas; Ativação de contas; Revogação de contas; Troca de senha; Concessão de direitos; Revogação de direitos; Criação de direitos; Atualização de direitos; Remoção de direitos.);

• O provisionamento pode ser feito de forma automática ou manual;

• Um mesmo recurso pode ter eventos provisionados de forma manual e automática;

Uma requisição do tipo Novo usuário, permite a inserção de novos usuários no diretório do Blazon.

Como criar uma requisição?

• A partir do Admin console;

• A partir do Workspace.

É possível a criação em lotes desta requisição?

Sim, você pode criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

Uma requisição do tipo Nova conta, permite a concessão de novas contas a usuários do Blazon.

Como criar uma requisição?

• A partir do Admin console, por meio de importação;

• A partir do Workspace.

É possível a criação em lotes desta requisição?

Sim, você pode criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

O que acontece se o provisionamento falha?

Caso o item requisitado não seja provisionado, o Blazon realiza a remoção da conta solicitada, mantendo assim o diretório integro.

Reconciliação é um dos aspectos mais importantes, críticos e complexos em uma Plataforma de Gestão de Identidade. Reconciliação tem a ver com a consistência espacial e temporal de informações, que podem ter diversas naturezas numa plataforma de Gestão de Identidade. Consistência espacial é uma propriedade requerida quando uma informação é replicada em dois ou mais lugares. De modo sucinto, consistência espacial é a propriedade que garante que todas as cópias são consistentes entre si, isto é, as cópias são iguais à informação original. Consistência temporal é a propriedade requerida quando as cópias, incluindo a informação original, variam ao longo do tempo. Resumidamente, a consistência temporal é a propriedade que garante a consistência espacial independentemente do tempo transcorrido.

Consistências, espacial e temporal, são um dos dificultadores no projeto da escalabilidade de sistemas distribuídos. Lembrando que não apenas a fonte original pode mudar, as réplicas também podem variar (e variam) ao longo do tempo. Ou seja, há que se garantir que as cópias se mantêm consistentes em relação à informação original, mas eventuais alterações nas cópias têm de ser conciliadas (e atualizadas, portanto) com reflexo na informação original.

Por exemplo, quando um novo colaborador é admitido na corporação, o backoffice fará o cadastro deste novo colaborador na Folha de Pagamentos. Observe que os demais sistemas, tais como Active Directory (AD ou LDAP) – que entre outras coisas garante o acesso à rede corporativa, email, VPN, por exemplo, precisam das informações deste novo funcionário para prover seus acessos. A arquitetura da plataforma tem um RA (Resource Adapter) especialmente preparado para buscar este evento (da inserção de um novo colaborador) na Folha de Pagamentos e cadastrar este novo colaborador nos sistemas mencionados.

Ocorre que este colaborador obtém uma Identidade que tem um ciclo de vida dentro da corporação. Por exemplo, anualmente há o direito a férias, período em que colaboradores não devem (ou não deveriam) acessar os recursos da empresa. Cabe à gestão de identidades gerir estes eventos e conciliá-los nos sistemas corporativos aos quais o colaborador tem direitos de acesso. Quando colaboradores são desligados da empresa, seus acessos devem (ou deveriam) ser removidos dos sistemas aos quais têm acessos. Estes são apenas dois exemplos para tornar mais concreto este tópico.

Por que é crítico? Porque qualquer falha nas conciliações pode implicar em, pelo menos, dois problemas: 1) falha de acesso, na qual o colaborador não consegue acessar sistemas necessários a suas tarefas; 2) auditoria, pois inconsistências nos acessos (por exemplo, um acesso que deveria ter sido removido) são penalizáveis dependendo das regulações aplicáveis à corporação. Por que é complexo? Corporações podem ter dezenas de sistemas e centenas ou milhares de colaboradores (e prestadores de serviços) e a correlação de eventos pode ser explosiva, podendo facilmente atingir milhões de eventos. Isto torna humanamente impossível, inviabilizando processos manuais.

Imagine que durante uma reconciliação, o sistema endereçado esteja fora do ar ou com sobrecarga de processamento e esteja com um tempo de resposta excessivamente longo. Poderia ocorrer de reconciliar em alguns sistemas, mas não nesses. Por este motivo, a plataforma foi projetada para trabalhar nesses (e muitos outros cenários problemáticos) garantindo que as reconciliações sejam efetivamente feitas, mesmo que tenha de esperar e fazer ao longo do tempo (quando o sistema endereçado voltar a operar). Em último caso, último mesmo, poderá ser feita uma notificação (que poderá inclusive ser a abertura de um ticket se houver um RA para o TTM – Trouble Ticket Management) para os administradores responsáveis pelos sistemas faltosos.

Além dos eventos, digamos naturais (como a remoção de um cadastro que foi “esquecido” no desligamento de um colaborador), há aqueles advindos de brechas na segurança. Administradores têm (mas não deveriam ter) acessos irrestritos a sistemas corporativos tais como bases de dados, LDAP etc e podem ser tentados (e nada mais tentador que um colaborador amigo precisando de um “acessozinho extra”) a fazer alterações (e até inserções) nesses sistemas. Imagine por exemplo, que um usuário seja inserido no LDAP da empresa, ele passa automaticamente a acessar a rede corporativa.

Observe, então, que o termo Reconciliação, tem um semântica de conciliar muitas vezes, isto é, garantir as consistências reiterada e repetidamente ao longo do tempo. Garantir que todos as possibilidades mencionadas nos exemplos dados, sejam sanadas a cada ciclo. Esses ciclos são configuráveis em termos de periodicidade, de eventos e, até, manualmente, isto é, o Gestor de Identidade pode a qualquer momento solicitar uma reconciliação. Lembrando que a reconciliação é orientada por políticas corporativas, normativas, regulatórias, de segurança etc.

Como as informações a serem reconciliadas são de diversas naturezas, podendo inclusive pertencer a repositórios diferentes, fazer todas ao mesmo tempo, além de dispendioso (custo de processamento), pode ser desnecessário, uma vez que as políticas aplicáveis às diversas naturezas de informações da Gestão de Identidade, podem variar bastante no tempo e na amplitude. Por este motivo, a Plataforma Blazon distribuiu este tópico em diversas Reconciliações, sendo: Reconciliação de Usuários, Reconciliação de Contas, Reconciliação de Direitos e Reconciliação de Membros de Direitos.

Considerando que as possibilidades de reconciliações são muitas, como se pode depreender do parágrafo anterior, a Plataforma Blazon, para facilitar a Gestão de Identidade, criou a possibilidade da criação de perfis de reconciliação. Cada perfil pode ter um nome que represente a necessidade específica, por exemplo Auditoria de Contas, sendo que o administrador poderá criar vários perfis, um para cada finalidade.

A solicitação de criação, alteração ou revogação de contas, pode se dar por meio das requisições descritas nas seções a seguir.

Uma requisição do tipo Atualiza usuário, permite a inserção de novos usuários no diretório do Blazon.

Como criar uma requisição?

• A partir do Admin console.

É possível a criação em lotes desta requisição?

Sim, você pode criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

A automatização integral de atividades é o sonho de toda corporação, porém existem empecilhos técnicos, econômicos e até políticos para tais implementações. Além disso, muitas atividades realizadas para a Gestão de Identidades são Tarefas realizadas manualmente. Deste modo, apesar do desejo de automatização total, nem todas as atividades são passíveis ou compensam ser automatizadas. O Blazon conta com cinco tipos de tarefas, sendo elas:

Tarefa de Aprovação

Permite que aprovadores aprovem ou reprovem a solicitação de um determinado pedido de acesso, sendo que Tarefas de Aprovação podem ser dos seguintes tipos:

• Aprovações para novas Contas;

• Aprovações para novos Direitos;

• Aprovações para novos Papéis; ou

• Solicitação de credenciais de Contas Administrativas.

Tarefas de Certificação

Permite que aprovadores revoguem ou mantenham um determinado acesso (Direito), sendo que, as Tarefas de Certificação podem ser dos tipos:

• Contas;

• Entitlements; ou

• Roles.

Tarefas de provisionamento

• Tarefa de Provisionamento

Tarefas de segregação de responsabilidades

• Tarefa de Segregação de Responsabilidade

Tarefas de alteração de direitos de um papel

• Tarefa de Alteração em Direitos de um Papel

Todas as Tarefas podem ser resolvidas de forma simples a partir do Workspace. Para configurações das Tarefas, o Blazon disponibiliza quatro componentes principais: Definições, Políticas de Escalação, Filas e Calendários.

Uma requisição do tipo Revoga conta, permite a revogação de uma conta existente no diretório do Blazon.

Como criar uma requisição?

• A partir do Admin console;

• A partir do Admin console por meio de importação;

• A partir do Workspace.

É possível a criação em lotes desta requisição?

Sim, você pode criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

O que acontece se o provisionamento falha?

Caso o item requisitado não seja provisionado, o Blazon realiza o rollback da conta alterada, mantendo assim o diretório integro.

Uma requisição do tipo Bloqueia usuário, permite a inserção de novos usuários no diretório do Blazon.

Como criar uma requisição?

• A partir do Admin console.

É possível a criação em lotes desta requisição?

Não, não é possível criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

O Gerenciamento de Senhas é algo fundamental quando lidamos com identidades e acessos. Esta é uma das funcionalidades centrais quando falamos de Governança de Identidades e o Blazon fornece um conjunto de funcionalidades que nos permite o gerenciamento de senhas de maneira adequada.

Para uma completa experiência, o Blazon conta com uma arquitetura com os componentes que podem ser visualizados na imagem abaixo:

Políticas de senhas

As políticas de senhas permitem a configuração de complexidade e ciclo de vida da senha de uma identidade. Em uma política de senha, podemos definir:

• Complexidade;

• Histórico de senhas;

• Expiração.

Cada uma destas configurações permitem um controle adequado das senhas utilizadas pelos usuários no Blazon.

Políticas de troca de senhas

• Opções de fator;

• Notificações;

• Tempo mínimo até a próxima troca de senha.

As opções das políticas de troca de senhas permitem um controle adequado de autenticação do usuário para sua troca de senha.

Dicionário

Mesmo com a configuração de complexidade de uma política de senha, é importante utilizarmos uma lista de senhas que não devem ser utilizadas. Mesmo senhas que seguem a complexidade configurada podem ser consideradas fracas e um dicionário de senhas pode ser utilizado para minimizar o risco de utilização de senhas fracas.

Cofre de senhas

O Blazon armazena as senhas provisionadas em um cofre de senhas, o que elimina a necessidade de envio de credenciais por meio de algum canal de comunicação. Além disso, o usuário ainda pode fazer o armazenamento de credenciais pessoais, o que de forma natural aumenta a segurança de uma organização.

Sincronismo de senhas

Após a troca de senha, o Blazon permite que as senhas de um determinado usuário seja sincronizada com suas aplicações corporativas. Desta forma, sempre que o usuário troca sua senha no Blazon, a mesma será modificada em suas aplicações.

Console de troca de senha

O Console de troca de senha é uma aplicação Web que permite que o usuário se autentique por meio de algum fator de autenticação e forneça uma nova senha.

As próximas sessões discutem os passos necessários para as configurações de toda a estrutura de gerenciamento de senhas.

A Certificação é um processo de revalidação sistemática de acessos (contas, membros de direitos e membros de papéis) e tem como principal objetivo garantir que apenas os acessos necessários estejam ativos dentro da organização.

Um processo de Certificação pode detectar que determinados acessos não são mais necessários ou até mesmo são indevidos e pode, então revogá-los, diminuindo assim a exposição da organização à riscos desnecessários.

Quais os tipos tipos de problema a Certificação resolve?

A Certificação deve ser utilizada como um controle que impede que acessos indevidos estejam ativos em uma organização. Sendo assim, processos de Certificação analisam vários tipos de contextos para garantir apenas os acessos necessários. Os contextos normalmente considerados são:

• De maneira periódica, é necessário validar se os acessos que um usuário possui ainda são necessários, principalmente os acessos mais críticos;

• Sempre que um usuário tem algum atributo crítico alterado, é importante a revalidação de seus acessos. Ex.: quando um colaborador muda de cargo ou departamento;

• De forma controlada, alguns acessos podem ser selecionados e enviados para revalidação, para garantimos a revogação de acessos indevidos e até mesmo para monitorar a qualidade do processo de certificação.

Um processo de Certificação pode validar uma série de outros contextos, além dos descritos acima. O importante é o entendimento de que um processo de Certificação tem como objetivo auxiliar para que apenas os acessos necessários estejam ativos dentro de uma organização.

O que pode ser certificado?

O Blazon permite a certificação de todos os objetos do diretório que representam um acesso em uma aplicação alvo, de forma direta ou indireta, sendo assim podemos certificar: contas, membros de direitos e membros de papel.

Apesar da possibilidade de certificação dos objetos citados acima, é importante notar algumas características que podem impedir que um determinado acesso seja certificado. Sendo assim, você deve levar em consideração as características abaixo para verificar se um objeto pode ou não ser certificado.

Caso você tenha alguma dúvida sobre o tipo de gerenciamento dos objetos do diretório, sugerimos a leitura do tópico relacionado a esta informação.

Tipos de certificação

Um processo de Certificação pode ter diversas características, como comentado anteriormente, para o cumprimento destes e diversos outros cenários, o Blazon oferece três tipos de certificações, sendo:

1. por Políticas de Certificação;

2. por Campanhas de Certificação; e

3. por Micro-Certificações.

Políticas de Certificação

As Políticas de Certificação são tipos de certificações que têm por princípio validar automaticamente os acessos que se encaixem nas regras especificadas em uma determinada política.

O Blazon possui dois tipos de Políticas de Certificação, sendo elas :

• Políticas periódicas;

• Políticas baseada em Mudanças de atributos.

Políticas periódicas

As políticas de Certificação periódicas permitem que se configure o período (por exemplo, mensalmente, semestralmente, anualmente) no qual determinados acessos devem ser revalidados. Sempre que um determinado acesso atinge o tempo máximo de Certificação, o mesmo é enviado para aprovação e caso não seja aprovado, o mesmo pode ser inativado/revogado.

Políticas baseadas em Mudança de Atributos

As políticas baseadas em Mudança de Atributo permitem que se especifique atributos, nos quais, caso seja verificada alteração, a revalidação será aplicada. Sendo assim, sempre que um determinado usuário tem um atributo determinado alterado, os seus acessos são enviados para revalidação.

Campanhas

As campanhas oferecem uma capacidade de revalidação de acessos em lotes, isto é, apenas os acessos especificados na campanha serão passíveis de revalidação. Além disso, as campanhas podem ter uma data de início e fim, para o controle de sua execução.

As campanhas de Certificação são uma maneira adequada para a execução de um processo de revalidação de acessos mais controlado. Diferente das políticas que executam continuamente e de forma automática, as campanhas são criadas e gerenciadas pelo próprio administrador, o que permite a seleção de acessos específicos a serem revalidados.

Micro-Certificações

Nos momentos onde apenas um acesso específico precisa ser revalidado, a Micro-Certificação permite que o administrador, com poucos cliques, selecione um acesso para revalidação.

A Micro-Certificações é uma funcionalidade oferecida pelo Blazon para facilitar a operação de administradores, caso sejam solicitadas revalidações de acessos muito bem determinadas e que não sejam necessárias a criação de uma campanha pra isso.

Uma requisição do tipo Ativa conta, permite a ativação de uma conta existente no diretório do Blazon.

Como criar uma requisição?

• A partir do Admin console;

• A partir do Admin console por meio de importação;

• A partir do Workspace.

É possível a criação em lotes desta requisição?

Sim, você pode criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

O que acontece se o provisionamento falha?

Caso o item requisitado não seja provisionado, o Blazon realiza o rollback da conta alterada, mantendo assim o diretório integro.

Uma requisição do tipo Inativa usuário, permite a inserção de novos usuários no diretório do Blazon.

Como criar uma requisição?

• A partir do Admin console;

• A partir do Workspace.

É possível a criação em lotes desta requisição?

Sim, você pode criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

Uma requisição do tipo Ativa usuário, permite a inserção de novos usuários no diretório do Blazon.

Como criar uma requisição?

• A partir do Admin console;

• A partir do Workspace.

É possível a criação em lotes desta requisição?

Sim, você pode criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

Uma requisição do tipo Inativa conta, permite a inativação de uma conta existente no diretório do Blazon.

Como criar uma requisição?

• A partir do Admin console;

• A partir do Admin console por meio de importação;

• A partir do Workspace.

É possível a criação em lotes desta requisição?

Sim, você pode criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

O que acontece se o provisionamento falha?

Caso o item requisitado não seja provisionado, o Blazon realiza o rollback da conta alterada, mantendo assim o diretório integro.

Uma requisição do tipo Desbloqueia usuário, permite a inserção de novos usuários no diretório do Blazon.

Como criar uma requisição?

• A partir do Admin console;

É possível a criação em lotes desta requisição?

Não, não é possível criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

Uma requisição do tipo Atualiza conta, permite a atualização de atributos de uma conta existente no diretório do Blazon.

Como criar uma requisição?

• A partir do Admin console;

• A partir do Admin console por meio de importação.

É possível a criação em lotes desta requisição?

Sim, você pode criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

O que acontece se o provisionamento falha?

Caso o item requisitado não seja provisionado, o Blazon realiza o rollback dos atributos da conta alterada, mantendo assim o diretório integro.

A Segregação de Funções, consiste na separação das responsabilidades de autorização, aprovação, execução, controle e contabilização. Para evitar conflitos de interesses, e diminuir riscos de fraudes, é necessário repartir responsabilidades entre colaboradores para que não exerçam tarefas incompatíveis, tais como execução e fiscalização de uma mesma atividade.

SoD é uma disciplina cujo escopo abarca diversas áreas da corporação passando por finanças, controladoria, vendas, controle de qualidade, entre outras. Deste modo, a Gestão de Identidade desempenha um papel importante no controle de acesso aos sistemas que dão suporte à gestão dessas diferentes áreas.

De acordo com o Gartner Group, controles eficazes de Segregação de Responsabilidades podem reduzir o risco de fraude interna em até 60% por meio da detecção precoce de falhas de processos internos em sistemas de negócios importantes. A Plataforma Blazon possui funcionalidades que garantem que acessos conflitantes não sejam concedidos, a menos que sejam explicitamente autorizados por analistas de Gestão de Identidade.

Como a Plataforma Blazon garante a segregação de funções?

A Plataforma Blazon provê políticas de SoD que contêm regras para a de possíveis conflitos. É importante frisar que a organização precisa ter o levantamento de todos os possíveis conflitos, de tal forma que a configuração de Políticas de SoD expressem todos esses casos de possíveis conflitos. As Políticas de SoD são executadas em dois momentos:

1. Requisição de um novo acesso: durante a requisição de um novo acesso, as Políticas de SoD configuradas são aplicadas ao novo acesso e, em caso de conflito, um workflow pode ser executado para aprovação (ou não) do novo acesso;

2. Sistematicamente: a Plataforma Blazon aplica as Políticas de SoD constantemente para a detecção de conflitos e, quando um conflito é detectado, um workflow pode ser invocado para aprovação (ou não) do acesso.

De forma geral, a Plataforma Blazon foi projetada para atuar como um mecanismo que garante que acessos conflitantes, previamente mapeados e especificado em políticas, não sejam concedidos.

A autenticação tem como objetivo garantir que uma pessoa, ou até mesmo um sistema, é quem ele diz ser. Em um ambiente digital, a autenticação é a maneira na qual um sistema computacional utiliza alguma técnica para verificar a autenticidade de quem deseja utilizar tal sistema.

Atualmente, existem uma série de abordagens que tentam aumentar o nível de confiabilidade de um processo de autenticação, bem como melhorar o nível de experiência do usuário. Historicamente, utiliza-se mecanismos tradicionais como usuário e senha, mas hoje contamos também com técnicas como One time password, que nada mais é que uma espécie de senha gerada sob demanda e que pode ser utilizada uma única vez. Além disso, existem técnicas mais sofisticadas como reconhecimento facial, que é muito comum em dispositivos de smartphone.

O Blazon conta com um conjunto robusto de funcionalidades relacionadas a autenticação e podemos implementar um processo de autenticação segura, por meio da utilização de usuário, senha, One time password e contexto, que permite habilitar passos adicionais para garantir que um usuário realmente é quem ele diz ser.

Estas funcionalidades podem ser utilizadas para autenticar o usuário na própria plataforma e também para a implementação de um processo de autenticação centralizado, a partir de técnicas de Single Sign On.

Recursos e funcionalidades de autenticação

Conheça as principais funções de autenticação do Blazon:

As políticas de certificação, apresentadas na seção anterior, abrangem uma parte significa dos acessos que devem ser certificados. Porém, nem sempre queremos automatizar este processo, ou ainda, durante um determinado período, por algum motivo, desejamos selecionar um conjunto de acessos e submetê-los a aprovação.

As campanhas de certificação permitem que um conjunto qualquer de acessos sejam selecionados e submetidos para revalidação. Estas campanhas permitem a seleção dos acessos desejados e permite também uma janela temporal, que específica quanto tempo essa certificação deve durar.

Durante o processo de certificação, você pode acompanhar o andamento da certificação, a partir do Admin console e tomar algumas decisões, como cancelar a campanha, finalizá-la ou até mesmo notificar os responsáveis que existem acessos aguardando revalidação.

Diferente das políticas de certificação, as campanhas nos permite um maior controle e autonomia daquilo que será certificado.

Como uma campanha é criada?

Uma campanha de certificação pode ser criada a partir do Admin console. Você vai precisar informar:

• Um CSV com os acessos a serem revalidados (você pode extrair estas informações dos relatórios da própria plataforma);

• Você deverá informar o início e o fim da sua campanha;

• E você também irá informar se os acessos não revalidados ao final da campanha, devem ser mantidos ou revogados.

Quando utilizar uma campanha?

Não há nenhuma razão específica para optar pelo uso de campanhas, mas sempre que houver a necessidade de revalidação de um conjunto de diferentes tipos de acessos, e esta revalidação deve acontecer de forma imediata e de forma controlada, indicamos o uso das campanhas.

As políticas e campanhas de certificação são ferramentas muito poderosas e que provavelmente irão atender suas necessidades de certificação na maior parte do tempo. Porém, existem cenários onde um acesso bem específico precisa ser revalidado.

Este acesso talvez não seja elegido por uma política e ao mesmo tempo, criar uma campanha para revalidar este acesso, talvez seja um processo mais oneroso, apesar de possível.

Assim, as micro certificações nada mais são que uma funcionalidade que visa facilitar a certificação de acessos, por meio de uma seleção simples no Admin console.

Assim como no caso das campanhas, é possível adicionar uma data de início e fim e indicar se o acesso deve ou não ser revogado quando a data limite for alcançada.

Como uma micro certificação é criada?

Estando no Admin console, basta selecionar o acesso necessário, selecionar a opção certificar e preencher os dados solicitados durante o processo.

Quando utilizar uma micro certificação?

Sempre que você precisar certificar um conjunto mínimo de acessos e que a criação de uma campanha seja mais complicada que isso.

Uma requisição do tipo Checkin de conta administrativa, permite a obtenção das credenciais de uma conta administrativa, adicionando estas credenciais no cofre de senhas do usuário beneficiário da requisição.

Como criar uma requisição?

• A partir do Workspace.

É possível a criação em lotes desta requisição?

Não, não é possível criar requisições deste tipo a partir de uma nova importação.

Quais as etapas são executadas?

Outros objetos relacionadas a esta requisição

Ao executar uma requisição, uma série de outros objetos podem ser criados:

O monitoramento dos objetos do diretório nos permite garantir que apenas os acessos necessários estejam de fato ativos. As políticas de certificação, baseada em algumas características, monitoram os objetos do diretório e de acordo com suas definições, inicia um processo de certificação para os objetos necessários.

As políticas de certificação são um mecanismo para automatizar o processo de certificação, uma vez identificada/mapeada uma característica específica que se deseja revalidar, você pode criar uma política para monitorar estes objetos. O Blazon possui dois tipos de políticas: Periódicas e Baseada em Mudanças de Atributos do Usuário.

As políticas periódicas garantem que um acesso seja revalidado não podem ser revogados manualmente e também não são elegíveis para processos de certificação após um período, independente se houve algum tipo de mudança para o proprietário daquele acesso ou não. Já as políticas baseadas em mudanças de atributos, são utilizadas para a captura de mudança de um usuário e inicio da revalidação dos seus acessos.

Políticas periódicas

As políticas periódicas, monitoram o diretório do Blazon, em busca de contas, membros de direitos ou membros de papéis que estão a um determinado período sem serem revalidados.

Uma política é definida com informações de periodicidade, onde neste caso indicamos de quanto em quanto tempo um determinado objeto deve ser revalidado. Além disso, a política determina quais os tipos de objetos devem ser considerados, bem como alguns filtros como: criticidade do acesso, acessos de um recurso, direito ou papel em específico.

Quando utilizá-las?

As políticas periódicas são indicadas para acessos críticos, que independente de alguma mudança, devam ser revalidados. Porém não há limitação em relação ao seu uso, podendo ser utilizadas em qualquer cenário que envolva periodicidade.

Políticas baseadas em mudança de atributos do usuário

As políticas baseadas em mudanças de atributos, determinam que quando um usuário sofre alteração em algum atributo monitorado, ele poderá ter os seus acessos submetidos a revalidação.

Quando utilizá-las?

As políticas baseadas em mudanças de atributos do usuário, devem ser utilizadas principalmente para o monitoramento de acessos que podem ser revogados quando há algum tipo de mudança. Um exemplo clássico para este tipo de política, é a revalidação de acessos baseado em cargo, sempre que um determinado usuário muda de cargo dentro da organização, seus acessos são submetidos para revalidação.

As conexões remotas tem como objetivo disponibilizar funcionalidades que permitam o acesso remoto à aplicações e servidores. Estas funcionalidades são fundamentais na implementação dos controles relacionados ao e visam garantir um maior nível de segurança à acessos em servidores e aplicações que sejam considerados críticos.

Ao utilizar estas funcionalidades, você pode por exemplo acessar um servidor sem a necessidade de acesso às credenciais. Além disso, é possível monitorar e gravar o que o usuário está executando.

O processo atual de autenticação do Blazon é baseado em uma política de autenticação. Essa política tem como objetivo, determinar como um usuário irá se autenticar. Nela é possível determinar, por exemplo, se o usuário irá se autenticar apenas fornecendo seu nome de usuário e senha, ou se terá também que informar um token , sendo possível a implementação de um processo de autenticação baseado em múltiplos fatores de autenticação ().

Métodos de autenticação

O Blazon conta com um conjunto de fatores que podem ser utilizados durante um processo de autenticação.

Cada um destes fatores pode ser utilizado de maneira complementar, a partir das definições que são configuradas em uma política de autenticação.

Contextos de autenticação

Os fatores descritos na seção anterior podem ser utilizados de acordo com o contexto de autenticação do usuário. Por exemplo, um token OTP pode ser solicitado se o usuário está se autenticando a partir de uma rede desconhecida ou em um horário fora do estipulado.

Todas estas definições de contexto são definidas em uma política de autenticação, que é utilizada durante o processo de autenticação de um usuário.

Próximos passos

Para determinar como o seu processo de autenticação no Blazon irá acontecer, acesse o Guia do administrador. Nessa documentação você encontra o passo-a-passo necessário para determinar o funcionamento de autenticação dos seus usuários.

O Blazon utiliza em sua arquitetura um componente amplamente utilizado na indústria conhecido como . O Apache Guacamole é um gateway que permite o acesso remoto a partir dos protocolos , e e um modelo denominado clientless, que utiliza tecnologia 100% WEB e elimina a necessidade de elementos intermediários.

A integração entre Blazon e Apache Guacamole acontece de maneira totalmente integrada e todos os benefícios que o Blazon possuem são estendidos às funcionalidades disponíveis no Apache Guacamole.

O usuário pode realizar o acesso a servidores remotos a partir do em uma conexão HTTPS, onde o mesmo pode selecionar e conectar em suas conexões disponíveis. Estas conexões podem ser solicitadas a partir do próprio Workspace e podem também ser submetidas a processos de aprovação, assim como qualquer outro acesso que é gerenciado pelo Blazon.

Assim que o usuário inicia uma conexão, o Blazon se conecta a um proxy Guacamole, que poder configurado diretamente no Admin console, e este proxy é responsável pela conexão com os servidores remotos a partir do protocolo mais adequado.

Para que seja possível a integração entre Blazon e Apache Guacamole, você deve instalar e configurar um proxy guacd, e adicioná-lo ao Blazon, por meio do Admin console e após isso, você poderá configurar conexões e permitir que as mesmas sejam utilizadas a partir do Workspace.

Serviços disponíveis

Além do processo de conectividade, o Blazon permite que o acesso seja feito utilizando credenciais que estão armazenadas em seu Cofre de senhas e também permite o monitoramento e gravação das conexões que estão em andamento.

Você pode ainda configurar uma série de serviços que podem ser utilizados durante a utilização de uma conexão remota.

Cofre de senhas

O usuário poderá fornecer manualmente as credenciais para o estabelecimento de uma conexão remota. Porém, o Blazon poderá gerenciar e injetar de maneira automática as senhas para uma conexão, evitando assim a necessidade de exposição destas credenciais.

Rotacionamento de senhas

Após a utilização de uma determinada credencial, é possível a rotação da mesma, diminuindo o risco de vazamento.

Gravação de sessões

As sessões estabelecidas podem ser gravadas em vídeo e acessadas posteriormente.

Auditoria de sessões

Todas as sessões são registradas e é possível identificar a credencial que foi utilizada, o usuário que a utilizou, informações do dispositivo remoto (endereço IP, navegar e etc).

As aplicações do ecossistema do Blazon são autenticadas de maneira centralizada a partir de Single Sign On. Sendo assim, o Admin console, Workspace e o Gerenciador de Sessões remotas, delegam sua autenticação para o Autenticador da plataforma.

Além disso, o Blazon é capaz de receber as delegações de autenticação de sistemas corporativos por meio do protocolo SAML. Sendo assim, toda aplicação Web que possui suporte, pode delegar o seu processo de autenticação para o Blazon usando o protocolo SAML. Existem diversos benefícios na utilização de Single Sign On, sendo alguns:

• Usabilidade: o usuário elimina a necessidade de memorizar diversas senhas e a necessidade de autenticação em cada sistema corporativo;

• Diminuição de chamados no Service Desk: sem a necessidade de utilização de várias senhas, a chance de acionamento no Service Desk para auxílio na recuperação de uma credencial é diminuída;

• Segurança: com um processo de autenticação centralizado, é mais simples implementar processos mais elaborados e implementar políticas de senhas mais efetivas, com rotações e complexidade mais adequadas.

Os benefícios de implementação de Single Sign On não se limitam aos citados acima, mas eles são tópicos relevantes em um ambiente corporativo.

Arquitetura

O processo de autenticação é baseado em um fluxo de HTTP Redirect e protocolo SAML. Sempre que um usuário acessa uma das aplicações, o Blazon verifica se há sessão ativa e caso não haja ele redireciona o usuário para o Autenticador, que é a aplicação responsável por gerenciar o processo de autenticação de usuários.

A imagem acima simboliza o processo de autenticação das aplicações do Blazon e o mesmo é descrito abaixo:

1. O usuário acessa uma das aplicações do Blazon (Admin console, Workspace, Conexões remotas);

2. A aplicação, não possuindo uma sessão válida, redireciona o usuário para o Autenticador via HTTP Redirect contendo uma SAML Request.

3. O usuário acessa o Autenticador e caso ainda não esteja autenticado, é enviado ao passo 4 para se autenticar. Caso já tenha uma sessão ativa (já tenha se autenticado anteriormente), é enviado diretamente ao passo 5;

4. No passo 4, o usuário irá de fato se autenticar. Ele deverá informar seu nome de usuário, e credenciais, que pode ser sua senha e/ou token OTP;

5. No passo 5, após autenticado, o usuário é redirecionado de volta à aplicação de origem por meio de um HTTP Redirect e SAML Response, informando que o usuário foi autenticado;

6. O usuário acessa a aplicação;

7. O usuário é apresentado com a interface da aplicação e pode realizar as atividades necessárias.

Apesar de um processo relativamente complexo, todos estes passos acontecem de forma transparente ao usuário.

Além das próprias aplicações do Blazon, você pode ainda delegar a autenticação de outras aplicações corporativas que possuem suporte a SAML. O processo funciona de forma similar ao que foi descrito para as próprias aplicações do Blazon.

Próximos passos