oldiveoPor-que-as-soluções-de-CASB-devem-ser-a-próxima-prioridade-em-TI

Por que as soluções de CASB devem ser a próxima prioridade em TI?

No mundo onde a transformação digital vem exigindo que empresas coloquem uma parte crescente de seus dados críticos de negócio em cloud computing, não existe mais rede exclusivamente interna ou externa; a nuvem se tornou uma extensão da infraestrutura das empresas. E a segurança precisa seguir o mesmo caminho, seja para os dados, as aplicações ou os usuários.

Sabemos que dentro de uma organização, as tendências de shadow IT, BYOD e outras formas autônomas de consumo de serviços de TI devem considerar as perspectivas de risco de cada tipo de usuário. Quando a atividade do colaborador pode envolver práticas menos seguras, como expor dados sensíveis em redes sociais, o colaborador tende a contar com a sorte.

Por conta disso, a segurança da informação vem ganhando um novo aliado, chamado CASB (Cloud Access Security Brokers), uma ferramenta de software voltada para a segurança da informação do tráfego pela internet dentro do sistema na nuvem.

As soluções de CASB vem garantindo o devido controle e segurança, sem comprometer a agilidade do usuário de dispor das ferramentas que lhe forem mais úteis para geração de resultados ao negócio.

Até o final e 2018, 50% das organizações com mais de 2.500 usuários estarão com uma plataforma de CASB para controlar o uso dos produtos mantidos como SaaS (Software as a Service), afirma o Gartner. Ainda de acordo com a consultoria, em 2020, 85% das maiores empresas usarão um produto de CASB. Desta forma, a camada de segurança não precisa estar por padrão incluída no ambiente de Cloud, mas ele precisa estar pronto para ambientes que usem CASB.

Como o tema “Segurança da Informação” ganhou muita importância nos últimos tempos, notamos que independentemente do modelo de Cloud escolhido, ele tem que possuir mecanismos que protejam a autenticação para acessar o painel de gerenciamento.

É comum encontrarmos hackers descobrindo o usuário responsável pela administração das máquinas em Cloud e pedir resgate para devolver o acesso e não apagar ou danificar as máquinas virtuais que foram criadas. Tem-se assim, perdas financeiras reais. É importante ter um ambiente de contingência e um plano bem detalhado e ensaiada com simulações periódicas para recompor de forma rápida o ambiente em Cloud.

 

Um mercado em crescimento

Os aplicativos de Software-as-a-Service (SaaS), cada vez mais difundidos nas empresas, oferecem novos desafios às equipes de segurança com visibilidade e opções de controle limitadas. O CASB responde a um requerimento crítico dos CSOs, que é aplicar as políticas de monitoramento e gerenciamento de riscos por toda a gama de serviços na nuvem utilizados pela empresa.

Nos próximos anos, espera-se que o CASB seja o principal mecanismo de segurança da informação que trafega pelo sistema na nuvem. Recentemente, já é possível identificar novos produtos disponíveis conforme o grau de maturidade de cloud, seja ela pública ou privada.

Segundo dados do Gartner, em 2020, 80% dos negócios envolvendo CASB farão parte de uma plataforma que integrará firewall, secure web gateway (SWG) e web application firewall (WAF). Ainda de acordo com o levantamento, o CASB é a única garantia de segurança quando o assunto é computação em nuvem. Ao final de 2016, ao menos 25% das empresas irão adotá-lo.

 

Principais funcionalidades do CASB

Dentre os principais mecanismos utilizados pelo CASB podemos mencionar:

 

Controle de políticas de acesso: trata-se de uma ampla gama de regras que visam ser utilizadas no controle de acesso.

 

Controle de autenticação – busca verificar a identidade digital do usuário. Existem diversos modos de autenticação:

  • Token – atualmente, o mecanismo de segurança mais conhecido e utilizado no mercado, o token cria uma senha única do usuário, garantindo a integridade do acesso. Existem diversas formas de token, porém a mais relevante se apresenta no formato de software.
  • Single sign-on – o usuário utilizará o mesmo log in para todos os aplicativos e dispositivos. Com isso, os custos de TI são reduzidos, porque implicam em menos chamados no help desk em função do único usuário. Além disso, permite a redução do tempo de reentrada de senhas com a mesma identidade.
  • Criptografia – fundamental para que as informações críticas dos usuários estejam preservadas.

 

Controle de Workflow do compliance – Consiste em um painel de alertas que mostra as atividades ocorridas fora do previsto, gerando maior controle sobre como os colaboradores estão aptos a seguir o fluxo estabelecido pela organização.

 

Log – Garante que cada atividade suspeita ou com sucesso seja gravada para avaliação posterior.

 

Prevenção contra malware – O CASB também possui uma heurística capaz de identificar e eliminar os diversos aplicativos prejudiciais ao sistema da empresa, usuários mal-intencionados e links maliciosos e faz varreduras em todo o sistema na nuvem, além de manter o setor de TI da empresa ciente de possibilidades reais de ataques cibernéticos.

 

Integração com o DLP (Digital Light Processing): o DLP é uma ferramenta de segurança que, quando integrada ao CASB, aumenta o poder sobre o uso de um determinado aplicativo, ao controlar, por meio de um dispositivo óptico, o uso de um software.

 

Ação em tempo real

O CASB executa esses monitoramentos e correções de forma constante e sem interrupções, a fim de fornecer relatórios atualizados sobre a segurança das informações, aplicativos utilizados no sistema na nuvem e infrações às políticas de segurança da empresa, entre outras informações.

O empreendedor, ao acessar o CASB, poderá acompanhar e monitorar informações já existentes antes da implantação desse sistema de segurança, tendo conhecimento do tráfego das informações, possível disseminação de vírus, compras não autorizadas e identidade do usuário, além de incorporar essas informações ao seu banco de dados.

 

CASB, uma ferramenta adicional

Escolher o fornecedor certo implica em mitigar muitos riscos de segurança na nuvem. Os CASBs não devem ser vistos como um substituto para os firewalls e outros recursos de segurança existentes para proteção, mas sim como uma ferramenta adicional. Hoje, ele está se tornando essencial, ao permitir o nível mais profundo de visibilidade, investigando as ações individuais dos usuários por meio do seu uso e determinando o tipo de ameaça que a organização poderá enfrentar.

Tudo vai depender do nível de maturidade da sua empresa com relação à nuvem.

 

Com os serviços de segurança do UOLDIVEO, sua empresa pode encontrar diversos serviços que buscam a continuidade do negócio e proteção de informações dos clientes.

Os serviços vão desde DDoS Protection, um pilar para sustentar a disponibilidade dos seus serviços, e evitar perdas financeiras importantíssimas, até a proteção específica para a aplicação Web, por meio do Web Application Firewall (WAF), um produto destinado a aplicações web, protegendo-as contra ataques à sua aplicação exposta à internet, deixando seu acesso mais rápido ou auxiliando na defesa contra o furto de informações existentes nas bases de dados usada pela sua aplicação.

Não basta ter uma infraestrutura confiável ou hardwares tecnicamente reconhecidos pelo mercado, é importante considerar o apoio de uma equipe especializada em ciberataques (cyberattack). Entre em contato e consulte-nos.

 

uoldiveo-Black-Friday: como o varejo tem se preparado para suportar a alta demanda

Black Friday: como o varejo tem se preparado para suportar a alta demanda

No ano passado, a Black Friday rendeu ao varejo online R$ 1,9 bilhão de faturamento em apenas 24 horas, segundo dados apurados pela Ebit. Em um único dia foram feitos mais de 2,92 milhões de pedidos, com tíquete médio de R$ 653 por compra. Com a crise econômica dando sinais de recuperação, a expectativa é que a data mantenha sua trajetória ascendente, com desempenho ainda melhor este ano.

A boa notícia vem acompanhada de alguns alertas de precaução. Para as empresas tirarem o máximo de proveito da Black Friday é preciso preparar a estrutura de TI para encarar o pico de acessos e de demandas computacionais em um curto período de tempo. As maiores dificuldades enfrentadas pelas companhias de varejo online estão ligadas ao datacenter, uma vez que eles nem sempre são estruturados para lidar com o volume tão alto de transações simultâneas.

Para evitar surpresas de última hora, o varejo tem se preparado com meses de antecedência, justamente para conseguir realizar todos os testes e desenhar uma previsão de possíveis falhas, antes do período crítico.

 

Veja quais são os principais pontos de atenção:

 

  • Adapte sua estrutura

As empresas precisam ter consciência de que necessitam de uma infraestrutura elástica para suportar os picos de acesso em datas especiais, sobretudo na Black Friday.

O uso de servidor em nuvem pode ajudar a evitar quedas e indisponibilidades do site durante grandes demandas, mas só a cloud não resolve, porque parte dela também depende de infraestrutura. A tecnologia de suas aplicações vai dizer até que ponto você poderá usufruir da escalabilidade oferecida pela nuvem.

 

  • Realize Teste de Estresse

O Teste de Estresse consiste em checar se a plataforma na qual a loja virtual está instalada suportará o maior número de acessos e se a própria loja está preparada para lidar com um grande volume de vendas em um curto espaço de tempo, gerenciando prevenção de fraudes, emissão de notas fiscais, embalagem dos produtos vendidos e toda a operação logística.

Para isso, tenha em mão informações sobre performance, estabilidade ou funcionalidades que precisarão ser testadas.

No caso de performance e estabilidade, você submeterá o ambiente a um pico de atividade, onde o objetivo é ver o limite da infraestrutura montada. Já no caso da funcionalidade, o objetivo é saber se tudo está funcionando de acordo com o que foi especificado.

Tenha bem definido o desenho da arquitetura do ambiente, os componentes que fazem parte desta arquitetura (rede, servidores, aplicação e usuários), produtos e aplicações que serão testadas, se a carga na qual o ambiente foi montado deverá atender as demandas e, o mais importante: a quantidade estimada de usuários que vão acessar este ambiente na Black Friday.

 

  • Verifique os serviços de suporte

Cheque com a plataforma quais os serviços de suporte que os fornecedores vão praticar no dia “D”. Geralmente, quem fornece infraestrutura e datacenter cria força-tarefa com uma equipe especial que fica 24 horas à disposição, porque sabem que nesse dia tudo vai ter utilização bem superior à média. Vale a pena verificar com seus fornecedores quais são os planos para suportar o pico de atividade na Black Friday.

É importante contar com uma capacidade maior de processamento e memória do datacenter, exclusivamente para a data. O objetivo é evitar que o serviço pare ao chegar no limite, descartando os pedidos que não consiga processar. Essa condição é denominada “on demand”, criada para situações nas quais o lojista sabe que vai ter um pico de vendas.

 

  • Invista em uma análise de transação robusta

Utilize um processador de pagamentos que realize uma excelente análise de todas as transações corretamente.  Com o aumento das vendas no seu site, mais análises de transações serão necessárias e alguns serviços de análise de risco do tipo automática, feita por software, podem bloquear transações legítimas em função de inconsistências no sistema. E como nessa época o número de transações é maior, o risco de bloqueio de transação também aumenta.

É recomendável que sua empresa tenha uma equipe focada em verificar a legitimidade das transações. Talvez seja necessário repensar a forma como as transações são analisadas para que não as vendas não sejam perdidas e nem sejam vítimas de golpes.

 

  • Conheça a capacidade de seu ambiente

Por fim, tenha em mente que você precisa saber exatamente o quanto seu ambiente consegue escalar. É possível traçar estratégias de acordo com seu nível de escalabilidade, evitando picos repentinos. Uma outra possibilidade é distribuir a campanha ao longo do mês, em vez de apostar tudo em um único dia e deixar os clientes a ver navios.

 

Não se esqueça: este é um trabalho constante que envolve ações estruturadas que devem ser programadas ao longo de 12 meses. Caso contrário, fica a lacuna que pode ser ocupada pelo concorrente, que se preparou antes de você. Nós podemos ajudar a sua empresa a fazer isso. Consulte-nos!

 

Alexis Rockenbach

 

Ambiente de DR: sua empresa está realmente preparada?

Como a maioria dos profissionais de TI sabem, ambiente de contingência ou ambiente de DR (Disaster Recovery) é a infraestrutura que entrará em uso caso um problema grave ocorra por causa de incêndios, enchentes, quedas de energia, erro humano ou caso um malware/ransonware prejudique os servidores ou um datacenter. O ambiente de DR  permitirá que a empresa se mantenha em funcionamento enquanto o problema no ambiente produtivo está sendo solucionado.

Entendido o que é um ambiente de DR, precisamos ter em mente que não é consenso entre muitos gestores se devemos usar ou não usar um ambiente de DR, já que na maior parte do tempo ele não será usado. Mas esta não é a pergunta correta a ser feita. Eles deveriam estar se perguntando “qual será o prejuízo que a minha empresa terá se tivermos uma parada inesperada em algum sistema crítico para o negócio?

A palavra prejuízo neste texto nos leva a refletir sobre diversos aspectos. Dentre eles podemos citar danos à imagem, impacto na reputação do ambiente, perda de clientes, penalidades para o fechamento de contratos, riscos de ciberataques, ausência de treinamento para uma recuperação rápida e muitos outros pesadelos que tiram o sono de qualquer diretor financeiro.

De acordo com a empresa BackBox, especializada em backup e recuperações, 50% de todos os negócios já tiveram algum desastre ruim o bastante para interromper alguma aplicação, sendo 18,5 horas a média para o tempo de inatividade de uma aplicação (downtime). A mesma empresa afirma que pequenos negócios podem enfrentar perdas de US$ 8.000,00 por hora, enquanto empresas médias sofrem perdas entre US$74,000 a US$90,000 por hora. Já empresas de grande porte podem ter perdas que variam de US$700,000 a até US$800,000 por hora que a aplicação crítica ficou sem funcionar.

O estudo da BackBox aponta que cerca de 81% das paralizações duram pelo menos um dia e apenas 35% das pequenas empresas possuem planos de recuperação contra desastres. É impressionante observar que 75% das empresas pesquisadas informaram que seus planos contra paradas inesperadas (desastres) são inadequados. Comecei a me questionar quais passos estariam sendo desenhados de maneira errada?

Insatisfeito com os números, decidi examinar o que revelava o relatório “The State Of Disaster Recovery Preparedness 2017”, feito com a participação da Forrester Research e  o Disaster Recovery Journal. O relatório mostra diversos estudos, envolvendo estratégias para Continuidade de Negócio (BC-Business Continuity) e Recuperação de Desastres (DR-Disaster Recovery). O relatório entrevistou 73 tomadores de decisão, mostrando que:

Note que 45% (34%+11%) dos entrevistados não estão contentes com suas estratégias e sentem-se inseguros. Se realmente uma falha em seus sistemas críticos ocorrer estará em risco não só o impacto nos negócios, mas a reputação e a carreira de todos os responsáveis.

A mesma pesquisa revela que diversos motivos foram revelados para a criação de um ambiente para DR dentre eles podemos citar: competitividade e necessidade de permanecer online, motivos legais, custos das próprias empresas paradas, elevação de riscos naturais ou riscos causados pelo homem, elevação da disponibilidade de uma aplicação crítica, responsabilidade legal, ambiente de DR identificado como prioridade máxima pela diretoria.

Independente do motivo, desenvolver uma estratégia para a contratação de um ambiente de contingência é inevitável para qualquer empresa. Mas se a justificativa for custos, basta olharmos os valores que serão gastos com os prejuízos de uma parada inesperada em um ambiente crítico. Claramente estes custos são superiores do que os custos da grande maioria dos ambientes de contingência. É esta conta que os responsáveis pelo negócio de uma instituição devem fazer, sendo o papel dos gerentes de infraestrutura primordial para que esta visão seja considerada pela diretoria.

Ok, vamos assumir que a contratação do ambiente de DR é prioritária e foi aprovada pela diretoria, é importante destacar que frequentemente um ambiente de Backup é confundido com um ambiente de DR e isto pode trazer sérias complicações.

Pode-se dizer que Backup é a cópia de dados em um disco, fita ou em um ambiente de Cloud e o retorno desta informação em caso de necessidade pode ser muito longo e o tempo cíclico para elaborar a atualização dos dados tende a ser muito longo. Outro ponto importante é o baixo uso de automação, além de grande carga de horas da equipe de TI para guiar a recuperação do ambiente produtivo. Resumindo: muito suor e elevada possibilidade para grandes perdas financeiras.

Se imaginarmos os conceitos ligados a um ambiente de DR, veremos que o tempo entre replicações ou atualização das informações é chamado de RPO (Recovery Point Objective) e que o tempo para recuperar as informações e ativar o ambiente ou recuperar a aplicação prejudicada é chamado de RTO (Recovery Time Objective). Nem sempre isto é compreendido pelas empresas e o resultado é um projeto incompleto ou confuso. Importante destacar que:

 

“Não existem melhores práticas para serem usadas, tudo vai depender do negócio de cada empresa.”

 

Em um ambiente envolvendo o conceito de Disaster Recovery (DR) veremos que é indispensável a presença de mecanismos para a automação, estejam eles ligados a replicação de informações ou estejam eles ligados a orquestração para que as máquinas e bancos de dados sejam ligados na ordem correta.  Resumindo: temos aqui baixíssimo suor usando ferramentas para obter mínimas perdas financeiras.

Com isto em mente, muitas empresas acreditam que é suficiente, mas isto é um grande engano. É necessário ter uma equipe bem treinada, sendo apoiada por um bom run book. Um run book é um documento com a sequência de procedimentos e rotinas que devem ser seguidas por cada equipe envolvida no ambiente de DR.

Para finalizar, vamos imaginar um ambiente produtivo virtualizado que necessita ser protegido com a presença de uma estrutura de DR operando em um Data Center remoto. Quais as atividades recomendadas para a construção deste ambiente?

  • Primeiro deve-se mapear todas as aplicações realmente críticas para o negócio, juntamente com o impacto caso estas aplicações parem inesperadamente o seu funcionamento;
  • Depois é importante analisar se as aplicações identificadas estão devidamente configuradas, sem a configuração excessiva de disco, processamento ou memória RAM;
  • Com a validação do size correto das aplicações, é necessário analisar o impacto financeiro. Quanto tempo o negócio aceita ficar com suas principais aplicações sem atividade? O resultado desta análise é a definição do RPO e RTO;
  • Definidos o RTO e RPO, basta criar o run book;
  • O quinto ponto é o mais importante, estando ele centrado em pessoas. Sendo necessário:

I. Nomear uma equipe multidisciplinar para a elaboração das atividades quando for decretado o uso do ambiente de DR. Importante considerar não só membros da equipe técnica, mas também membros da diretoria ou da equipe jurídica. Deve-se nomear uma pessoa que será a representação da empresa para elaborar comunicados aos jornalistas e a mídia eletrônica, reduzindo as perdas na imagem da instituição;

II. Capacitar e treinar a equipe para elaborar simulações validando as atividades contidas com testes de DR. O resultado dos testes deve gerar um relatório com todos os pontos de melhoria;

III. Com os resultados das simulações, a equipe deve elaborar testes de DR duas vezes no ano. O resultado dos testes deve gerar um relatório apontando as evidências de cada atividade feita proporcionando auxílio ao processo de auditoria ou aos investidores da empresa;

Tenha em mente que as atividades “a” e “b” possuem o objetivo de reduzir custos do ambiente de DR. Este ambiente deve impactar minimamente a equipe envolvida, sem abrir mão de transparência, simplicidade operacional e deve-se ter suporte de uma equipe externa devidamente capacitada sempre que necessário.

 

Denis Souza

 

Links Recomendados:

 

4 fatores importantes sobre nuvem e continuidade de negócios que você precisa saber agora mesmo

Os departamentos de TI estão sob constante pressão para disponibilizar novas tecnologias que permitam que a empresa mantenha dados críticos, aplicações, processos seguros e em funcionamento 24 x 7.

Some a isto ofertas de nuvem que permitem que a empresa terceirize parte da responsabilidade pela gestão e garantia de segurança e confiabilidade e temos o ambiente perfeito para a continuidade de negócios e recuperação de desastres ser deixada para segundo plano frente aos desafios do dia-a-dia de gerenciamento de TI.

Ao utilizar serviços baseados na nuvem é fácil perder de vista os principais riscos de continuidade de negócios e por isso listamos aqui 4 pontos importantes que você deveria ter em mente enquanto utiliza cloud computing para sua empresa.

 

1. Continuidade de negócios é mais que recuperação de desastres

A indústria é permeada com termos como “continuidade de negócios” e “recuperação de desastres”, o que pode torná-lo confuso para os líderes empresariais. Mesmo o termo “recuperação de desastres” leva a maioria dos profissionais de TI para o caminho errado.

Soluções de DR são normalmente utilizadas para “cenários de desastres” e “desastres” relacionados a causas naturais não são a causa mais comum de interrupção de TI.

Falhas de software, hardware e erro humano são as principais categorias responsáveis ​​por algum tipo de interrupção no negócio.

As empresas precisam de parar de pensar apenas em desastres e começar a considerar maneiras de evitar interrupções.

 

2. As nuvens nem sempre incluem alta disponibilidade e / ou garantia de continuidade de negócios

A todo momento o serviço de nuvem é entregue a partir de um Data Center.

Se esse Data Center tiver problemas, o fornecedor de nuvem pode mover suas cargas de trabalho rapidamente para um novo Data Center?

Sempre verifique como a empresa lida com isto para poder decidir como se preparar para isto.

Muitas vezes os players de nuvem pública disponibilizam maneiras de garantir a continuidade de negócios utilizando replicação de dados em Data Centers localizados em regiões distintas.

Fique atento: este recurso não é padrão na oferta de nuvem e precisa ser configurado individualmente na maioria dos casos.

 

3. A localização dos servidores garante mais do que latência

A nuvem não é um lugar mágico – onde seus arquivos são armazenados fisicamente realmente importa.

A localização dos servidores da nuvem pode afetar a velocidade de acesso e preços, mas é um erro pensar em localização apenas por este prisma.

Quando falamos em continuidade de negócios, localização em região diferente da principal e eventualmente o uso de fornecedores distintos realmente é algo a ser considerado.

 

4. Backup nem sempre é parte da oferta padrão

Fornecedores de nuvem nem sempre oferecem backup de dados armazenados dentro das métricas necessárias para o negócio de sua empresa.

Alguns fornecedores sequer oferecem backup dos dados como parte padrão de sua oferta.

Por padrão assuma que o fornecedor não oferece garantias e verifique com o mesmo como ele lida com backup, antes de definir um plano para isto.

 

Continuidade de negócios é um tema importante para você?

Se você quiser discutir os cenários de continuidade de negócios, com garantia de alta disponibilidade, segurança e conectividade integradas às ofertas em nuvem, entre em contato conosco pelo telefone (11) 3092 6161 ou pelo nosso formulário de contato.

 

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

 

Ataques DDoS atingem novo patamar, qual será o futuro?

Sempre me questionei a respeito do que aconteceria se um ataque digital fosse feito usando centenas de milhares de dispositivos móveis ao redor do mundo, e me deparei no passado perdendo o sono diversas vezes com algo desta magnitude. Infelizmente hoje podemos dizer que algo similar aconteceu recentemente no mês de setembro e outubro deste ano. Neste cenário, é fácil dizer que não foi surpresa o ataque ter acontecido, mas foi realmente uma surpresa a forma como foi feito.

Preocupado com este cenário, venho acompanhando o crescimento do número de dispositivos conectados à internet, sejam eles celulares, tablets, câmeras, roteadores wireless ou diversos outros tipos de equipamentos, há mais de 3 anos e facilmente ver-se que existe um crescimento surpreendentemente a cada ano. Segundo o Juniper Research, uma empresa especializada na elaboração de pesquisas, em 2020 teremos mais 38,5 bilhões de dispositivos conectados em todo o mundo. Considerando que todos nós certamente pensamos em segurança em um dispositivo antes de conectá-lo a internet, imagine o tamanho do estrago que teremos quando 38,5 bilhões de dispositivos estiverem enviando e recebendo informações em diversos cantos do mundo? Só no Brasil, segundo um estudo realizado pela Fundação Getúlio Vargas, existem mais usuários de smatphones do que de notebooks e tablets, adivinhe o novo resultado desta pesquisa quando tivermos mais opções a um preço menor para compra.

Olhando de forma ampla, podemos dizer que as opções para este post são muitas. Poderia eu aqui falar do crescimento espantoso de malwares bancários para dispositivos móveis, já que um recente levantamento da Kaspersky Lab, uma importante referência para pesquisas envolvendo o tema segurança, detectou mais de 77.000 trojans bancários, sendo 98% projetados para o sistema operacional Android, mas não vou! Poderia também discutir neste post a ameaça que expos mais de 100 milhões de usuários do WhatsApp, mas também não vou abordar isto hoje! Então, pelo amor de Deus, que tema você vai falar Denis?

Vamos detalhar o ataque digital que ocorreu em 21 de outubro nos servidores da Dynamic Network Services, conhecida como Web Dyn. Primeiramente é importante saber que a Dyn conduz o acesso a sites como Twitter, Netflix, Spotify ou CNN através dos seus servidores de DNS (Domain Name System) e ao receber este ataque, mais de 1,2 mil sites ficaram inacessíveis. Entenda que quando navegamos pela internet, precisamos dos servidores de DNS para apontar onde estão os sites desejados e sem eles nenhum ambiente Web pode ser alcançado.

As análises iniciais da própria Dyn apontam que o ataque superou 50 vezes a volumetria de seu acesso normal, recebendo uma volumetria maior que 1.2Tbps com origem em localidades como Ásia, América do Sul, Europa e US. Observe que a complexidade deste ataque poderia prejudicar qualquer site isoladamente, seja em grande ou pequena escala de impacto, mas acredito que neste caso certamente foi feito um estudo detalhado envolvendo a relação fragilidades vs impacto. Não tenho dúvida que a Dyn tinha diversas proteções, poderia ter sido bem pior se não tivesse, mas nada poderia preparar para o que aconteceu. O objetivo final de quem fez o ataque era afetar o máximo de empresas possível e isto segue o padrão do novo atacante digital, que é capaz de elaborar atividades focadas sempre em maior poder de devastação.

Entretanto, como podemos classificar ou identificar este ataque? Primeiro ponto, o alvo foi a infraestrutura da Dyn, impedindo que seu principal negócio fosse acessado. O volume de requisições recebido foi muito superior ao planejado. O segundo ponto que devemos analisar baseia-se em no fato de que o acesso à internet e a consulta a dispositivos como firewalls, roteadores e switchs recebeu tantas conexões que saturou, prejudicando seu funcionamento. Provavelmente foi até o momento o ataque mais complexo e sofisticado deste tipo já feito. Com isto podemos concluir que é o comportamento devastador de um ataque chamado Distributed Denial of Service/Ataque de Negação de Serviço (DDoS).

O primeiro ponto importante do ataque a Dyn é que o atacante estava se preparando há algum tempo, fazendo uso de maneira inteligente e coordenada do código público pertencente ao malware mirai, que afeta ambientes com o sistema operacional Linux e transforma-os em ambientes controlados remotamente.  Em linhas gerais podemos dizer que o atacante digital se aproveitou do conceito que guia a Internet of things/Internet das Coisas (IoT) e infectou diversos dispositivos ligados a internet, principalmente câmeras e dispositivos caseiros de armazenamento usando seus acessos conhecidos. Um ambiente infectado pelo Mirai vasculha continuamente a internet procurando por dispositivos não contaminados usando uma tabela com nomes comuns de usuários e senhas padronizados por fabricantes.

Note que nenhum ataque complexo buscando por falhas em programas foi feito e para remover o controle do Mirai basta remover o cabo de rede, reiniciar o dispositivo e mudar a senha do usuário administrador no dispositivo. Veja que as bases para um ataque desta magnitude estão na fragilidade humana, que novamente não seguiu regras simples baseadas na modificação de um usuário e senha.

Quem estuda segurança da informação identifica estes traços na técnica chamada de engenharia social. Tal técnica está presente na séria de ficção Mr. Robot, que em pouco tempo se tornou a primeira produção original do USA a ser indicada na categoria Melhor Série Dramática concorrendo a um Emmy, um dos maiores prêmios da TV. Mr Robot é uma série criada por Sam Esmail, Steve Golin (True Detective) e Chad Hamilton, sendo produzida pela Universal Cable Productions e encontra-se na segunda temporada, sendo exibida aqui no Brasil pelo canal Space.  A história acompanha a vida de Elliot (Rami Malek, de The Pacific), um jovem programador que sofre de uma desordem que o torna antissocial. As atividades de Elliot chamam a atenção de Mr. Robot (Christian Slater, de Mind Games), um misterioso anarquista que o convida a fazer parte de uma organização que atua na ilegalidade com o objetivo de derrubar as corporações americanas.

Retornando ao tema do nosso post, quero concluir dizendo que infelizmente tenho visto minhas previsões se concretizarem e a tendência é que encontremos pesadelos mais frequentes nas mesas de CSO, Gerentes de TI e diversos membros do board de corporações. Segurança é algo que não podemos descartar, precisamos ter sempre em mente que ataques como o sofrido pela Dyn estão e estarão cada dia mais presentes, necessitando do apoio de empresas de Data Centers, provedores de acesso internet e diversos especialistas que saibam quais são os caminhos para proteger contra quaisquer ataques digitais.

 

Denis Souza

 

Links indicados:

Kaspersky Lab detecta mais de 77 mil trojans bancários em dispositivos móveis

27ª Pesquisa Anual do Uso de TI, 2016 – Estudo da Fundação Getúlio Vargas

Quantidade de objetos conectados no mundo alcançará 38,5 bilhões em 2020

Dyn Analysis Summary Of Friday October 21 Attack

 

Por onde anda o seu dinheiro? – O início da investigação

Quem de nós nunca se referiu à pessoal escassez econômica ou mesmo viu alguém referir-se ao triste desprovimento monetário, com aquele gesto universal onde o sujeito puxa para fora, e expõe seu límpido e inócuo bolso, em prova à total falta de notas ou moedas.

fsf

Porém, em tempos modernos, onde a circulação de cédulas bancárias ou moedas têm sido cada vez mais sufocadas pelos usuais e funcionais evolutivos métodos de “escambo” (chegaremos lá), tal gestual expressão ainda é comum. Mas vamos falar num sentido mais amplo, onde a dúvida maior sobre o paradeiro do seu dinheiro, realmente ainda é um mistério para muitos.

Desmistificando o dinheiro …

… mas antes, não temos como fugir da história, afinal a moeda, como hoje a conhecemos, é o resultado de uma longa evolução.

Há muitos e muitos séculos atrás ele não existia, mas, como sempre existiu a necessidade de comprar, as pessoas da época tiveram que dar um jeitinho e resolver o problema.

A primeira solução foi fazer trocas, então, como por exemplo se uma pessoa tinha colhido muitas frutas, mas precisava de peixe, e partia à procura de quem estivesse interessado nas frutas, mas também tivesse pescado em excesso, por exemplo. (*Daí o uso do sistema de comércio, chamado também de escambo). *Atualmente ainda encontramos pessoas que se utilizam dessa prática, inclusive há sessões específicas nos classificados ou dos jornais para anúncios de trocas, mas é claro que em escala muito menor do que antigamente. Outra situação identificada apenas pelos pais dos pequeninos, é o caso, por exemplo, da criança que troca com o coleguinha um brinquedo caro por outro de menor valor, qual deseja muito, sem preocupar-se com o valor diretamente relacionado.

dgsgrs

Contudo, embora de certa forma esse sistema suprisse as necessidades de sobrevivência, muitas vezes era difícil ter a noção do real valor da mercadoria a ser trocada. Assim, cada civilização arrumou uma forma de dar valor às mercadorias baseado em elementos que tinham algum significado. Aceitas por todos, assumiram a função de moeda, elementos dos mais variados como troca: gado, sal (que deu origem na Roma antiga ao nosso bendito salario), bambu etc.

sgerhgdf

Avançando rapidamente alguns séculos para seguirmos a velocidade que o nosso tempo exige, passamos da moeda-mercadoria, para a moeda metálica (ouro, prata e cobre), moeda-papel, cheques, … (proposital o não menção dos ‘modernos’ meios atrelados ao sistema bancário, afinal, esse exigiria alguns extensos tópicos adicionais)

Enfim, o que antes exigia-se do palpável elemento monetário, onde a expressão do bolso vazio, fazia muito mais sentido e que expressava literalmente a realidade, agora está sendo amplamente substituído pela praticidade do que o sistema bancário, tecnologicamente munido da praticidade do avanço que a internet (incluamos toda a tecnologia imputada nela) e necessidade de mobilidade têm trazido.

Isso responde inicialmente à pergunta: “Por onde anda seu dinheiro? ”

Proporcional ao consumo do meio escolhido, ele está em geral, de modo superficial, navegando e ‘voando’ pela rede mundial… sendo processados pelas administradoras de cartões, de passagem por algum smartphone, smartwatch, carteiras eletrônicas, instituições financeiras ou outro meio que surge ou é utilizado à cada novo momento ou boom inovador. (Esse artigo apenas abre a oportunidade de aprofundarmo-nos no tema)

O que antes era ficção nos tempos dos Jetsons, hoje é um presente passageiro, onde avançamos rapidamente para ser passado.

Então, fará cada vez menos sentido a gestual exposição do pano vazio de nossos bolsos físicos, sendo substituídos por indicativos azuis, verdes ou vermelhos, apontando positivo ou negativo de nossas contas, aplicativos ou instituições que que as fintechs estão cada vez mais em velocidades estrondosas, nos apresentando e dando continuidade ao estímulo que a criatividade humana  e encontrar novas formas de intermediar as trocas de aquisição de bens e serviços.

Abraços e até o próximo post.

Rodrigo Godoi

 

 

Indisponibilidade de aplicações: Qual é o prejuízo para a sua empresa?

Passei alguns anos da minha carreira construindo projetos em ambiente de Data Center requisitados por diversas empresas de setores industriais distintos e muitas vezes percebi que o tema indisponibilidade e seus efeitos para o negócio como um todo não eram abordados com o aprofundamento necessário ou eram esquecidos ao se “espremer” por redução de custos. Lembro que em muitas reuniões tive que revelar este tema e perceber que era tratado com certa surpresa.

Se observarmos o relatório publicado pela Veeam (2016 Veeam Availability Report) feito com 1.140 tomadores de decisão de TI de 24 países, veremos claramente que as necessidades da corporação estão bem distantes de serem atendidas, e que as empresas de uma forma mais macro, precisam fazer da disponibilidade uma prioridade estratégica ou estarão arriscando a perda de até 16 milhões de dólares por ano em receita. Para ficar mais claro, vamos comparar os dados de 2014 com as informações obtidas em 2016:

  • O tempo de inatividade anual não planejado foi elevado:
    • 1,4 a 1,9 hora para aplicações essenciais.
    • 4 a 5,8 horas para aplicações não essenciais.
    • O número médio de eventos aumentou (de 13 para 15 eventos).
  • O custo médio anual do tempo de inatividade para uma organização pode chegar até US$ 16 milhões (US$ 6 milhões a mais que 2014).

É sempre importante destacar que o preço de uma indisponibilidade para um ambiente de produção pode ser mais impactante do que se pode imaginar. Observe a figura seguinte:

 

blog56546

 

Veja que mais da metade dos entrevistados (68%) revela que a confiança na organização pode ser afetada e 62% afirma que a confiança na marca pode sofrer danos. Os dados revelam que foram notadas quedas nos preços das ações, juntamente com a presença de processos judiciais. São dados que precisam e devem ser levados em consideração.

Imaginemos este acontecimento em empresas que operam com bolsa de valores ou com compras pela internet. É inaceitável imaginar que os consumidores de hoje aceitariam esperar 1 minuto para um site retornar ao funcionamento com o objetivo de concluir a sua compra. Questionar suas instituições se estão à altura deste desafio é uma tarefa que todos os líderes de negócio deveriam fazer.

Outro ponto importante para ser avaliado está centrado na causa do e nos efeitos do temido downtime (quedas funcionais) de uma aplicação. Quase metade dos entrevistados (48%) reportaram que suas organizações tiveram repetitivas experiências com quedas causadas pelo uso de upgrades na aplicação ou problemas gerados por correções feitas no sistema operacional. Aqui vale o questionamento: onde estão os ambientes para homologação e onde estão as metodologias para aplicação das correções em ambientes com cluster balanceados por cargas de trabalho?

Observe que a presença de um balanceamento de cargas é um importante aliado para corrigir um grupo de aplicações que apresentou algum tipo de problema. Outro elemento importantíssimo é o teste de backup. Somente 41% dos entrevistados afirmaram que usam seus backups como parte dos testes de recuperação e ainda assim, este backup possui uma recuperação em dias relativamente pequena. No Brasil, a média foi de 11 dias de dados recuperados por mês, na Alemanha 12 dias e na Itália 14.

Para concluir, é importante termos em mente que o desenho de qualquer projeto, seja ele físico ou virtual, deve considerar a sobrevivência da aplicação mesmo em condições de falhas. Claro que o desafio é sempre alinhar custos com perdas financeiras causadas pela ausência funcional da aplicação. Acredito que os números apresentados pela Veeam mostram que existe um longo caminho a ser trilhado, mas que existe solução se pensarmos estrategicamente com cuidado.

 

Denis Souza

 

Links indicados:

https://go.veeam.com/2016-availability-report-latam-br.html

http://convergecom.com.br/tiinside/home/internet/19/02/2016/indisponibilidade-de-aplicacoes-gera-prejuizo-de-us-16-milhoes-por-ano-as-empresas/

http://computerworld.com.br/brasileiras-perdem-us-18-milhoes-com-indisponibilidade-de-aplicacoes

6 mitos inacreditáveis sobre segurança em nuvem

Toda semana dedico um bom tempo a entender quais são os principais problemas e oportunidades que a área de TI das empresas enfrenta no dia a dia e em uma das pesquisas encontrei um artigo da Forbes que colocava segurança como uma das principais preocupações de CIOs para 2016.
Descobri ao mesmo tempo que este é um dos fatores que tem desestimulado a adoção rápida de cloud computing por algumas empresas.

Segurança em cloud? Como assim?

Conversei com diversos especialistas em cloud e segurança, e em nenhum momento consegui chegar à conclusão de que a tecnologia aplicada à maioria das nuvens era determinante para tornar a computação em nuvem mais vulnerável que um ambiente tradicional de TI.

Então, por que tanta insegurança com a segurança?

insegurança
sensação ou sentimento de não estar protegido, seguro.

Um dos motivos é comportamental. O fato da tecnologia de nuvem ser nova pode causar um comportamento mais conservador, fazendo com que alguns profissionais prefiram aguardar testes e casos de sucesso de outras companhias para tomar sua decisão – mesmo isto implicando em agir de forma mais lenta e reativa com relação ao mercado.

O outro motivo é basear-se em informações incorretas. A verdade é que alguns pontos que tenho observado sobre esta insegurança são na verdade fruto de mitos propagados constantemente pela internet e que apenas reforçam uma informação imprecisa, impedindo que profissionais de TI tomem decisão com base em fatos.

Há ainda uma parcela das decisões de adoção de nuvem que estão de fato baseadas em características muito específicas e incomuns que fazem com que a segurança seja um impeditivo.

Chegou a hora de separar verdade de ficção e acabar com alguns mitos sobre segurança na nuvem (IaaS)!

MITO 1: NUVENS PÚBLICAS NÃO SÃO SEGURAS.

O ambiente de nuvem pública pode ser ainda mais seguro do que um ambiente on-premisses ou mesmo um Data Center. O fato é que nenhuma nuvem é igual a outra e por isso o importante é que as empresas tenham critérios claros de controle e visibilidade desejados.

Por se tratar de um ambiente compartilhado, na maioria das vezes os controles aplicados à nuvem são mais rígidos do que em ambientes on-premisses.
Diversas regras de segurança são aplicadas na camada física da infraestrutura, além de existir isolamento lógico entre todos os clientes, fazendo com que os ambientes estejam blindados contra acessos não autorizados.

Um exemplo disso é que o UOLDIVEO, para reduzir os riscos de clientes e do próprio UOL, atualiza constantemente suas tecnologias, regras de firewalls, planos de mitigação de vulnerabilidades para todos componentes de infraestrutura baseado na detecção de tentativas de ataques, além de segmentação de rede e aplicação de patchs de segurança.

MITO 2: SEGURANÇA EM NUVEM É UM NOVO DESAFIO.

A verdade é que a segurança na nuvem não é uma preocupação nova.
A computação em nuvem tem mudado muita coisa no mundo da infraestrutura, mas a maioria das preocupações de segurança, como proteger a infraestrutura e os dados sensíveis, são preocupações antigas.
Requisitos de segurança e de governança são os mesmos independentemente de componentes físicos, virtuais ou de nuvem. Na nuvem, a maneira pela qual as mudanças na infraestrutura acontecem tornam controle e visibilidade ainda mais importantes.

MITO 3: COMPLIANCE É O MESMO QUE SEGURANÇA.

Muitas empresas acreditam que se o provedor de nuvem é certificado, seus sistemas são seguros e invulneráveis à ataques.
Na verdade, o certificado não garante a segurança. Apenas confirma que o que estava definido, foi cumprido no momento da auditoria.
Muitas vezes, os padrões de conformidade às políticas e procedimentos dependem de pessoas ao invés de sistemas automatizados e por isso podem ocorrer falhas entre auditorias. Acreditar que ter certificação é o mesmo que ter segurança – e vice-versa – coloca a empresa em risco.

MITO 4: CLIENTES DE UMA MESMA NUVEM PODE ATACAR UNS AOS OUTROS.

Em uma nuvem pública como VMware vCloud Air, OpenStack, AWS ou Microsoft Azure, os clientes compartilham recursos de computação, armazenamento e recursos de rede.
Como os recursos físicos são compartilhados, muitas empresas se preocupam que sejam atacadas por outros clientes que utilizam o mesmo serviço. Na verdade, existem diversas questões que garantem a proteção entre clientes.

Invadir a camada de virtualização, por exemplo, não é simples. Há poucos relatos deste tipo no mundo e casos deste tipo ocorreram elevando o nível de permissão de um usuário existente, dentro do painel de gestão.

Para evitar isto, é possível isolar a camada de gerenciamento, colocando-a em uma rede separada e ainda que estejam na mesma rede, é possível fazer o isolamento da VLAN.

MITO 5: INVASÕES VIA INTERNET SÃO MAIS AMEAÇADORAS NA NUVEM DO QUE EM UM DATA CENTER.

Ameaças vindas da Internet são reais, mas não são mais ameaçadoras na nuvem do que para qualquer outro ambiente.
Alguns dos principais problemas de segurança em nuvem incluem violações de dados, invasão de conta, APIs inseguras e negação de serviço (DDoS). Estas preocupações não são novas quando falamos em serviços conectados à Internet.
Uma variedade de proteções pode ser utilizada contra esses ataques, que vão desde firewalls, varredura de vulnerabilidades e criptografia para prevenção de intrusão de rede, até credenciais inteligentes.

MITO 6: VOCÊ NÃO PODE CONTROLAR ONDE SEUS DADOS RESIDEM NA NUVEM.

A localização dos dados é uma preocupação importante e muitos países têm leis que não permitem a exportação de dados pessoais ou o seu armazenamento em outro país.
Quando a residência de dados é uma preocupação, especialmente para informações pessoais como informações de saúde, impostos e financeiras, a escolha do provedor de nuvem deve basear-se onde o service provider mantém seus Data Centers em nuvem.
Empresas que fornecem serviços em vários continentes devem, pelo menos, escolher um provedor de serviços que possa satisfazer essas necessidades com Data Centers aderentes à política de cada país.

 

Gostou deste post? Aproveite e baixe gratuitamente nosso whitepaper “Nuvem híbrida: deixe as preocupações com segurança no passado” e saiba mais sobre segurança em nuvem.

Dica: Este whitepaper acima pode ser ainda mais interessante se sua empresa utiliza ambiente virtualizado em tecnologia VMWare.

Alerta: Novo malware se espalha agressivamente pela internet

A internet recebeu mais um convidado indesejado e provavelmente vai fazer muito mais que simples barulho. Estamos falando de um malware que usa o código do conhecido BARTALEX. Já é possível identificar uma elevação muito acentuada de e-mails contendo-o, principalmente para usuários do Office 365.

O BARTALEX explora os recursos de macros e já é conhecido desde abril de 2015. Inicialmente era disseminado por SPAMs usando URLs que exibiam uma página pedindo para o usuário habilitar macros em um documento Microsoft Word. Se esta atividade fosse feita, um download do malwareTSPY_DYRE.YUYCC era feito para monitoramento de atividades bancárias.

O novo malware deposita o BARTALEX no campo de formulário de um arquivo do tipo “dotm” para evadir a detecção de macros. O mesmo apresenta alto grau deobfuscação (técnica usada para evitar que seu código seja visto e seu funcionamento entendido), além de utilizar codificação RC4 para proteger e dificultar sua detecção. O código do BARTALEX foi modificado para fazer o download do Ransomware Cerber. Indicações da Check Point (equipe Threatcloud Incident Response) apontam que o CERBER está sendo distribuído via Botnet Dridex.

Importante destacar que até hoje de manhã, nenhuma das principais engines de antivírus do mercado conseguiam detectar este malware.

Acredito que este não será o primeiro, nem o último ataque deste tipo. Se analisarmos os ataques via macro, veremos que existe um crescimento com o passar dos anos. Possivelmente encontraremos muitos Ransomware como o RANSOM_LOCKY.A ou como o CERBER e ainda diversos outros meios destrutivos usando macros.

O dia 23 de junho de 2016 pode ser uma data importante para as empresas em todo o mundo. Devemos observar de perto a evolução para o ciclo de contaminação do BARTALEX e do CERBER. Aliado a isto devemos evitar que funcionários ativem macros para documentos não assinados por suas empresas e fazer uso de mecanismos que monitorem o tráfego Web ou o fluxo de Correio Eletrônico para identificar comportamentos comuns nos ataques de ransomware.

Entre em contato agora com o UOLDIVEO e entenda como podemos ajudar sua empresa a solucionar este e outros problemas de segurança.

http://uoldiveo.com.br/contato/
comercial@uoldiveo.com

 

Denis Souza

 

Referências:

  • Check Point Threatcloud Incident Response (Time de Resposta à Incidentes), Check Point ThreatCloud e Threat Intelligence (Nuvem Colaborativa de Segurança).
  • Trend Micro Blog.