Oracle Database Vault: introdução a Realm

RESUMO

Objetivo deste artigo é explorar uma outra feature do Oracle Database Vault, o Realm. Veremos como é possível impedir o acesso de super users a determinado objeto, role ou mesmo a schemas inteiros.

 

INTRODUÇÃO

Este é o terceiro de uma série de artigos introdutórios a Oracle Database Vault (ODV). Vimos como configurar, as principais mudanças nas atividades do DBA e a segregação de funções em [1]. Vimos também como funcionam Factor, Rule, Ruleset e Command Rule em [2] e como podemos combiná-los para proteger um objeto, um schema ou mesmo o DB inteiro contra determinada instrução SQL.

Usaremos novamente um DB na versão 12.1.0.2 com o ODV habilitado com as configurações defaults, acrescentando apenas com as mudanças realizadas nos artigos anteriores, mas elas não necessárias. Teremos o C##DONO que possui a role DV_OWNER e o C##CONTAS com a DV_ACCTMGR.

O componente que trataremos neste artigo será o Realm (Domínio) e tentaremos ilustrar sua funcionalidade com alguns exemplos. Ele atua como um nível de proteção “mais forte” que os conhecidos privilégios de sistemas/objetos. O escopo pode ser específico a nível de determinado objeto ou amplo como tipos de objeto ou schemas.

 

CENÁRIO PARA TESTE

Para preparar nossos testes, vamos começar com a criação de users e roles que serão necessários. Contextualizando também o cenário inicial, vemos que é possível com o SYS consultar todos os objetos do schema HR mesmo com o ODV habilitado.

 

Vamos criar um user USER_CONSULTA_HR que possuirá permissão de leitura em HR.EMPLOYEES e HR.DEPARTMENTS.

 

Criaremos também uma Role que utilizaremos no último exemplo:

 

REALM

O Realm é como uma zona de proteção em que você pode colocar roles, objetos ou mesmo schemas inteiros. Com ele, é possível blindar os dados contra usuários com privilégios de sistema (como SELECT ANY TABLE, por exemplo). E isso inclui, especialmente, proteção contra o DBA [3].

Adicionar o schema HR dentro de um Realm, por exemplo, provocará erros de falta de privilégios caso seus objetos sejam acessados por um DBA ou alguém que possua SELECT ANY TABLE.

Os atributos de um Realm são:

– Name

– Description

– Enable

– Autid Option

– Type

Os dois primeiros são triviais, olhemos então para o Enable. Mas este também é trivial! Sim, só gostaríamos de chamar a atenção de como devemos utilizá-lo aplicando a API disponibilizada. Os valores aceitos para Enable são estes abaixo:

– DBMS_MACUTL.G_YES (default)

– DBMS_MACUTL.G_NO

 

Podemos também definir quando auditaremos os acessos. As opções são simplesmente não auditar, auditar falhas, auditar sucessos ou ambos.

Audit_options:

– DBMS_MACUTL.G_REALM_AUDIT_OFF (default)

– DBMS_MACUTL.G_REALM_AUDIT_FAIL

– DBMS_MACUTL.G_REALM_AUDIT_SUCCESS

– DBMS_MACUTL.G_REALM_AUDIT_FAIL + DBMS_MACUTL.G_REALM_AUDIT_SUCCESS

Quanto ao tipo, a discussão é interessante e tentaremos mostrar em detalhes através de exemplos. Há dois tipos: o REGULAR (0) e o MANDATORY (1).

A diferença entre começa no fato de que o REGULAR protege apenas os objetos contra users com “privilégios de sistema” (SELECT ANY TABLE). Porém, isso não impede de usuários que tenham privilégio de objetos de realizar a consulta (grant de SELECT/READ explícito nos objetos do HR ou via ROLE).

Já o Realm MANDATORY é um pouco mais restritivo. Nem mesmo os usuários com privilégio de objeto poderão consultá-los. Neste caso, é necessário conceder “privilégio no Realm” ao usuário que pretende fazer o acesso. Vale frisar que esta discussão inclui o owner dos objetos protegidos. Ou seja, se protegermos o HR com um Realm MANDATORY, ele perde a permissão de consultar os próprios objetos. Interessante, não?

 

Vejamos como funciona primeiramente os Realms do tipo REGULAR.

 

Aqui temos um Realm, entretanto, ele ainda não protege nada. Precisamos dizer quais são os objetos que ele deve englobar. Podemos especificar owner, nome do objeto ou mesmo seu tipo e caso precise generalizar, pode ser utilizado o “wildcard”: ‘%’. Vamos começar adicionando a tabela HR.EMPLOYEES abaixo dele.

 

A partir de agora, usuários com privilégios de sistema não conseguirão mais ver os dados desta tabela. Veja o que ocorre com o SYS:

 

Porém, aqui ainda é possível o acesso de users que possuam privilégios do objeto, como é o caso do USER_CONSULTA_HR:

 

Antes de avançar, vamos ver como estão as configurações e aproveitaremos para conhecer as views com os metadados de Realms:

 

Até aqui nenhum segredo, falamos de todos estes atributos. Vejamos como está nosso ambiente.

 

Note que tivemos um outro efeito com esta proteção: não é mais possível conceder permissão de leitura nesta tabela. Resolveremos este ponto adiante.

 

Explorando um pouco mais o conceito de Realm, vamos falar do tipo que é mais restritivo, o MANDATORY. Como citado acima, ele impede quem tenha privilégios de sistema, privilégios de objetos e até mesmo o owner de fazer consultas em objetos protegidos.

Para ilustrar, vamos alterar o tipo do Realm PROTECT_HR para MANDATORY e, com isso, esperamos que o USER_CONSULTA_HR perca o acesso de leitura, visto que será necessário um privilégio a mais para conseguir “chegar” aos dados [4].

 

Consultando novamente, vemos que temos um Realm MANDATORY:

 

Vamos testar o acesso de USER_CONSULTA_HR aos dados protegidos (EMPLOYEES) e não protegidos (DEPARTMENTS).

 

Veja o que ocorreu com o HR:

 

O próprio owner perdeu acesso a seus dados. É nesse sentido que afirmamos que o MANDATORY é mais restritivo. Segundo a documentação, com sua utilização é necessária autorização explícita ao Realm. Ou seja, para acessar os dados, além dos devidos privilégios de objeto, será necessária autorização no Realm.

O que seria esta autorização no Realm? São dois os tipos de permissão: Participante (DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT) ou Owner (DBMS_MACUTL.G_REALM_AUTH_OWNER). A principal diferença no tipo de autorização é que o tipo PARTICIPANT não permite a concessão de privilégios sobre os objetos protegidos. Para isso, é necessário a autorização do tipo OWNER.

Autorizando o USER_CONSULTA_HR como PARTICIPANT, resolverá o problema da falta de privilégio. Veja:

 

Precisamos também aumentar nossa query (removemos alguns campos para simplificar) que verifica a configuração atual, adicionando outra view:

 

E agora podemos ver que USER_CONSULTA_HR é PARTICIPANT do Realm PROTECT_HR. Será que isso resolve o problema de falta privilégio? Resolvido.

 

Para ilustrar a diferença, vamos conceder o mesmo nível de privilégio para o HR e em seguida vamos resolver um outro ponto citado acima.

 

O problema citado foi o user HR não conseguir conceder privilégio de leitura em uma tabela protegida, embora consiga agora acessar a tabela.

 

Para que seja possível, precisamos alterar o tipo de privilégio do HR para OWNER do Realm.

 

Agora temos:

 

Isto resolve nosso problema, confira:

 

Faltou ainda falar de um outro atributo da “autorização” a nível de Realm, os Rulesets. Deseja permitir o acesso apenas se determinadas condições forem verificadas? A partir de determinado host? Apenas em certos horários? Este é o ponto chave para atingir este objetivo. Falamos de Rulesets em [http://www.oracle.com/technetwork/pt/articles/idm/rule-ruleset-command-rule-vault-3038750-ptb.html] e citamos que elas poderiam ser utilizadas aqui.

Aumentando a especificidade do nosso exemplo, aproveitarei para incluir um questionamento que nosso time recebeu da equipe de Sec. Como fazer para que a concessão de privilégios tenha prazo de validade? Com os pontos que já discutimos nos artigos anteriores, temos condições de resolver este ponto.

Faremos agora com que o Realm só permita acesso do USER_CONSULTA_HR aos dados até um horário determinado: 10h 35min do dia 18/06/2016. É uma forma não depender de uma ação manual para removê-lo no futuro. Vale enfatizar que o Ruleset está vinculado com a autorização e, portanto, pode afetar apenas determinado user.

Vamos criar uma Rule e um Ruleset e associá-los.

 

Precisamos também alterar a autorização dada ao USER_CONSULTA_HR para que seja também validado o Ruleset:

 

Verificando a configuração, temos:

 

E finalmente, só admirar o resultado:

 

Último ponto que discutiremos nesta introdução a Realms, será como proteger também as Roles. No começo do artigo criamos uma role ROLE_READ_SCOTT. Vamos conceder privilégio de leitura em uma tabela do SCOTT e em seguida criar um Realm para proteger a Role. Depois, tentaremos conceder outro privilégio.

 

Grant concedido com sucesso. Agora a criação do Realm e incluindo a Role na proteção.

 

Analisando o resultado:

 

E agora que a Role está protegida, podemos conceder privilégio de leitura na SCOTT.DEPT?

 

A forma de “resolver” a violação é fazer com que o SCOTT tenha autorização de OWNER no Realm.

 

E o resultado:

Desta forma, vimos que podemos evitar que privilégios sejam adicionados ou removidos de determinada Role se a protegermos com Realm. Somente quem for autorizado como OWNER do Realm poderá fazer o Grant/Revoke.

 

CONCLUSÃO

Neste artigo exploramos uma outra feature poderosa do Oracle Database Vault. Este é o componente responsável por impedir o acesso de usuários privilegiados aos dados sensíveis. Vimos os diferentes tipos de Realms e que podemos escolher quando auditaremos os acessos (ou tentativas). Falamos também o quão específico ou genéricos podemos ser quando o assunto é proteger os dados.

Há ainda pontos a serem explorados nós próximos artigos como autorização para datapump e patches, auditoria, roles, schedulers, etc. Faremos na medida do possível.

 

REFERÊNCIA

[1] http://www.oracle.com/technetwork/pt/articles/idm/seguranca-oracle-database-vault-2999070-ptb.html

[2] http://www.oracle.com/technetwork/pt/articles/idm/rule-ruleset-command-rule-vault-3038750-ptb.html

[3] https://docs.oracle.com/database/121/DVADM/cfrealms.htm#DVADM70144

[4] https://docs.oracle.com/database/121/DVADM/cfrealms.htm#DVADM71156

 

Entenda de forma simples e fácil o que é “Big Data”

Olá,

Hoje vou falar um pouco mais sobre “Big Data” e mostrar para você a quantidade de dados que geramos para que entenda de forma simples e fácil o que é “Big Data”

Você nem imagina, mas geramos atualmente um volume absurdo de dados e dos mais variados.

(mais…)

Big Data / Machine Learning: Rise of the Machines

Olá pessoal. Como estão as coisas por aí?

Hoje o post vai ser diferente. Vamos falar um pouco de Futurismo ou Futurologia, e ao mesmo tempo perceber que essa realidade não está tão distante assim.
Vocês já têm acompanhado aqui pelo Blog, que cobrimos temas diversos, mas sempre com algo em comum: novas tecnologias ou novas formas de se fazer negócios, ou simplesmente como implementar novas habilidades nas organizações.

Eu também me sinto bem à vontade para dizer que, a esta altura, vocês já perceberam que parte do nosso papel no Marketing de Produtos aqui no UOLDIVEO, é pensar como será o mundo de amanhã, e como a tecnologia vai impactar a sua, a minha, as nossas vidas.

 

*** Alerta de spoiler ***

 

Digo isso pois vocês já acompanharam em um post ou outro, nosso time comentando sobre automações, como melhorar a performance de equipes e sistemas, falamos também de Big Data…

 

Então, agora que estamos contextualizados, vamos ao ponto: vocês já ouviram falar do projeto Serenata de Amor? Não? Google it! Não vou entrar nos detalhes do crowdfunding, depois vocês entram lá, ou acessam o GitHub do projeto e dão uma olhada. Mas eu vou deixar alguns termos relevantes por aqui: Bancos de Dados, informação, Data Science, Machine Learning, Inteligência Artificial e por aí vai…
Entenderam onde quero chegar?

As organizações, independente da sua natureza, produzem verdadeiras montanhas de dados. Você já sabe disso. E também sabe que o futuro destas mesmas organizações vai estar alicerçado aí. Já não é novidade para você que, na mesma medida que nossas vidas migram para a internet, ou digital, acessamos ou produzimos um universo de dados e informações.

Você já deve ter escutado por aí que nos últimos 10 anos foram gerados mais dados do que toda a história da humanidade.
É algo impressionante, considerando a nossa pequena parcela na existência. Mas isso já é suficiente para que você considere o valor que o ativo informação tem no mercado. Ela virou moeda (e certamente a mais poderosa), e é necessário que os mercados e negócios sejam capazes de interpreta-la de forma favorável.

Extrair informações e conhecimento dos dados é um fator importante, mas a capacidade de tomar decisões é o fator de sucesso. Big Data, Data Science? Sim, você já sabe a resposta. Agora pense em uma Inteligência Artificial que será capaz de relacionar e aprender sobre o seu negócio de uma forma robotizada. Você conhece bem a vantagem disso. Toda organização que em algum momento adotou sistemas de apoio a decisão, sabe o valor da informação e sabe a importância de ter esta mesma informação de uma forma cada vez mais ágil.

Agora, pense em tudo o que estamos falando aqui. Pense no que você já fez hoje, usando redes sociais, plataformas de comunicação, ou as aplicações corporativas. Que imagem vem a sua mente? Montanhas e montanhas de dados. Veja o potencial que existe em sistemas de apoio capazes de tratar estas montanhas de dados e que conseguem desdobrar isso em padrões, que geram informações ou simplesmente servem de retroalimentação para este mesmo sistema.

Exato, estou falando de Machine Learning.

O valor de você, por exemplo, lidar com um projeto ou com uma demanda de negócio, ou mesmo elaborando um novo produto ou serviço usando as mais diversas variáveis é algo intangível. Já pensou em analisar informações com variáveis que vão da complexidade, prazo, orçamento e conectando a isso a pessoa responsável, seu tempo de dedicação, experiência, processos envolvidos. Some isso a mais variáveis, como cliente, segmento, seu histórico e perfil de compra, utilização, fidelização. Já pensou em relacionar isso com posicionamento e aceitação de mercados, e até se os treinamentos e materiais de apoio são suficientes? Você precisa analisar esta informação em quantas dimensões?

Qual seria o impacto no seu negócio se, analisando padrões, você conseguisse saber qual o ROI de uma iniciativa qualquer, ainda no período de descoberta desta oportunidade? Estamos falando de prever o futuro?
A meu ver, este futuro está mais próximo do que imaginamos. E fica a pergunta: você está preparado?
Até a próxima!

1 Abraço!
Fabiano

BIG DATA – inovando e agilizando a sua empresa

Olá pessoALL, todos nós temos conhecimento de algum projeto de sucesso usando a tecnologia “BIG DATA” e ao mesmo tempo percebi que ainda existem muitas dúvidas sobre o esforço para implantar “BIG DATA” nas organizações.

Ter um “BIG DATA” não é algo distante das nossas possibilidades.

Correlacionar diversos tipos de dados que antes era muito complicado, hoje tornou-se muito mais simples com as novas tecnologias disponíveis no mercado, as quais muitas vezes não tem custo de licença para seu uso.

Então quer dizer que os CEOs devem pensar seriamente em ter “BIG DATA” na empresa? SIM!

Nos próximos 10 anos teremos uma economia da informação cada vez mais estabelecida e a moeda de valor serão os dados, ou seja, quem tiver a inicitativa de buscar oportunidades com estas informações vai ter uma enorme vantagem competitiva.

Na prática as empresas vão monetizar o “BIG DATA” como um produto e já temos vários exemplos desta nova realidade acontecendo, imaginem em 2026!

Mas não precisamos esperar 2026 para ver o que vai acontecer. O PagSeguro que é um caso de sucesso aqui do UOL utilizando “BIG DATA” para melhorar a eficiência operacional e consequentemente a satisfação dos nossos clientes.

Outro exemplo é a inovação e agilidade promovida por nossa área de operações, com a gestão de capacidade preditiva (analytics), através da tecnologia “BIG DATA”, que além de oferecer uma análise especializada aos nossos clientes também atende as normas da ISO20000.

Ainda há outras iniciativas, como mapear todo o conhecimento tácito e explicito da empresa usando todo o potencial de correlacionar diversas fontes de dados usando “BIG DATA”. E isso é só o começo!

Todas estas mudanças estão ocorrendo muito rapidamente e é importante saber que “BIG DATA” não é algo abstrato. É concreto e tem características que são: volume, variedade, velocidade, veracidade e principalmente valor ao negócio.

Como falei acima, é fácil começar um projeto de “BIG DATA”, mas alguns pontos são fundamentais para determinar o sucesso ou fracasso desta iniciativa.

8 pontos fundamentais para sua iniciativa de BIG DATA ser consistente:

1) “BIG DATA” é uma mudança de “mindset” e se você tratar este novo conceito apenas como uma questão tecnológica é quase certo que vai fracassar;

2) Implantar “BIG DATA” exige uma mudança cultural da organização porque envolve uma tecnologia totalmente nova que manipula dados não relacionais (volume), de diversas fontes (variedade) e serão armazenados em um banco de dados não relacional para buscar padrões criando um leque de oportunidades (velocidade e veracidade) e muitos deles são estratégicos para a empresa (valor);

4) Estruture o “BIG DATA” com objetivos claros;

5) Divida o projeto em etapas;

6) Atenda às 5 características (volume, variedade, velocidade, veracidade e valor);

7) Não se esqueça da política de governança das informações;

8) Ao final de cada etapa, faça um “brainstorm” sobre o que você aprendeu com “BIG DATA”. Isso faz toda a diferença.

 

E agora está se sentindo mais preparado para inovar e agilizar a sua operação com “BIG DATA”?

E se precisar de ajuda conte conosco!