Porque Multicloud ?

Em meu último post falei sobre algumas diferenças fundamentais entre ofertas de plataformas de nuvem existentes no mercado, como isso pode impactar seu negócio e como explorar os pontos fortes de cada tipo de oferta. O objetivo hoje é avançar um pouco mais, exemplificando como a adoção de uma estratégia MultiCloud pode ajudar na redução de custos, aumento de disponibilidade e resiliência, mas também expor pontos chave que devem ser levados em conta nesta jornada.

Utilizar mais de uma nuvem de forma simultânea pode trazer ambientes para um novo patamar em termos de qualidade, performance e disponibilidade. Felizmente, com o advento do Cloud, nos dias de hoje rodar aplicações em diversas nuvens é algo que está ao alcance de qualquer empresa, algo que a 8 anos atrás só era possível para corporações de grande porte.

Falhas de infraestrutura sempre vão acontecer, não é uma questão de “se” e sim de “quando” irão acontecer. A única forma de minimizar seu impacto é estar preparado para quando acontecer.

Mesmo trabalhando com aplicações preparadas para Cloud (Cloud-Ready Applications) ou nativas de Cloud (Cloud-Native Applications), que tiram proveito de todas as funcionalidades e o potencial da nuvem elas não estão imunes às falhas de infraestrutura.

Tais falhas podem afetar regiões inteiras de provedores de Cloud não são incomuns, podem gerar grande impacto pela extensão da falha (que em muitos casos tem efeito cascata, afetando diversos serviços de um mesmo provedor mesmo em regiões distintas) e o tempo de reestabelecimento desses serviços que pode demorar algumas horas.

Os benefícios de utilizar-se múltiplos provedores de Cloud simultaneamente vão além de melhorar resiliência e tolerância às falhas em camadas de hardware, software e infraestrutura. Uma estratégia MultiCloud pode reduzir a dependência de um único provedor (vendor lock-in), facilitando futuras negociações e migrações.

Mas toda essa abundância de ofertas e possibilidades deve fazer parte de uma estratégia que contemple todos os aspectos relevantes em termos de segurança, flexibilidade e controle. Pois como os sistemas estarão distribuídos em diversas nuvens, as autenticações, logs e controle de acesso, permissões, configurações e cobrança também estarão.

Isso traz uma série de novos desafios que devem ser observados com atenção:

– Gestão de Identidade/ Auditoria

– Gestão de Capacidade/Monitoração

– Gestão de Configuração

– Automação

– Billing

Cada nuvem disponibiliza seus recursos de uma forma, painéis, APIs e terminologias são bastante diferentes, podem não representar um problema no início, mas que podem se tornar um pesadelo se não forem feitos planejamento e as definições adequadas.

NO UOL Diveo, já adotamos estratégias Multicloud há alguns anos e neste tempo adquirimos experiência, desenvolvemos técnicas e ferramentas que nos permitem extrair o melhor de cada nuvem, entregando para nossos Clientes todos os benefícios.

Olimpíada Rio 2016: Oceano de Oportunidades para o Cybercrime

Devido a minha vivência em segurança da informação, sempre observo eventos com grandes aglomerações de pessoas como uma oportunidade perfeita para atacantes digitais. Desta forma, foi natural refletir e imaginar o que poderia ser feito por um atacante digital experiente na Olimpíada do Rio de Janeiro. Assim, durante um final de semana fiz um pequeno exercício.

O primeiro exercício que fiz foi identificar alguns números e avaliar a verdadeira importância do evento em questão para tentar mensurar um elemento importante chamado de motivação. Considerando que tivemos neste evento 205 países, mais de 7,5 milhões de ingressos vendidos e que a maioria das pessoas levam consigo no mínimo um celular, teremos pelo menos um vetor para ataques focado em dispositivos móveis, sejam eles pessoais ou empresariais.

E neste “oceano” de celulares nasceu o Samsung Pay, mostrando para o mundo que é possível ter uma tecnologia wireless de curto alcance focada em fazer pagamentos. A Samsung saiu na frente da Apple e do Google usando como tecnologia o NFC (Near Field Communication). Isto possibilita o registro de catões de créditos cadastrados em celulares, bastando aproximar o celular de terminais de compra para autenticar a transação. A segurança é concluída inserindo a impressão digital ou outros elementos para autenticar a transação.

O uso do NFC é algo recente, mas a segurança aplicada no gateway de pagamento ou nos elementos que o cercam é algo bem conhecido que vem evoluindo com o passar do tempo. Entretanto, existe um outro ponto muito importante que devemos considerar para uma análise macro. Veja que tivemos 28 edições dos jogos olímpicos na era moderna, onde 17 foram na Europa, 6 na América do Norte, 3 na Ásia e 2 na Oceania. Não há dúvida que um evento desta magnitude na América do Sul impulsionaria as vendas, principalmente dos patrocinadores. Assim, é natural que os ataques digitais sejam mais focados nestas empresas. Precisamos no exercício deste texto imaginar quais as preocupações que o C-Level deveria ter em mente?

Preocupações

O primeiro ponto é a infraestrutura. Ataques DDoS (Distributed Denial-Of-Service) são usados em conjunto com outras metodologias para indisponibilizar o ambiente exposto à internet. Está ficando muito comum identificarmos ataques múltiplos, representando a combinação de diversas estratégias usadas para alcançar fama, furto de dados ou enriquecimento ilícito. Algumas aplicações são muito sensíveis a latência e este modelo de ataque afeta principalmente isto. Ter uma proteção que não penalize a latência é importante.

O segundo ponto está ligado na proteção direta do gateway de pagamento, da aplicação Web e dos bancos de dados usados por ela. Atualmente os ataques específicos na camada de aplicação são furtivos, assim, o atacante aprimorou sua técnica para não gerar alertas, ganhando tempo para instalar ferramentas na rede e invadir ambientes ou copiar informações dos bancos de dados. Isto é muito diferente de um ataque DDoS, que é relativamente mais fácil de detectar, pois o ecossistema da aplicação é exposto a um grande volume de acessos, superando o volume previsto de conexões por segundo. Ou seja, existe uma assinatura previamente conhecida.

O terceiro e último ponto é a imagem da empresa ou do produto. Sabemos que as campanhas de marketing ligadas principalmente a grandes eventos fornecem uma exposição muito maior de marcas ou do nome das empresas envolvidas. Assim, é necessário sempre pensar nas ações que precisam ser tomadas visando proteger o ecossistema empresarial como um todo. Isto envolve também análise de spam/phishig, redes sociais ou de sites clonados.

Sabemos que ações ligadas a proteção de marcas envolvem atividades do Departamento Financeiro, representado pelo CFO (Chief Financial Officer) e do Departamento Jurídico, guiado pelo CLO (Chief Legal Officer). Muitas vezes a retirada de um site envolve ações legais, que são custosas e bastante demoradas.

Como elemento decisivo para o negócio, podemos olhar para o tema infraestrutura. As necessidades atuais mostram que as empresas precisam direcionar o desenvolvimento das aplicações em ambientes flexíveis que forneçam de forma rápida, orquestrada e inteligente um crescimento ou uma redução de recursos computacionais (computing), de rede (network) e de armazenamento (storage). Claro que estamos falando de Cloud. A jornada para a Cloud passa basicamente por cinco fases: padronização, consolidação, virtualização, automação e orquestração. O estudo de cada fase junta-se como a análise de maturidade da aplicação dentro desta jornada, mas estes serão tema de outro artigo.

 

Denis Souza

 

Links indicados:

API FIRST

No meu último post “O que você precisa saber antes de desenvolver aplicações para a nuvem” apresentei de forma macro os 3 pilares na implantação de aplicativos em um ambiente em nuvem. Neste post o foco é aprofundar no entendimento do conceito de API (Application Programming Interface ou Interface de Programação de Aplicações) e como esse é o início da próxima revolução na tecnologia.

Uma interface de programação de aplicação (“API”) é um conjunto particular de regras (“code”) e especificações que os programas de software pode seguir para se comunicar uns com os outros. Ele serve como uma interface entre os diferentes programas de software e facilita sua interação, semelhante à maneira como a interface de usuário facilita interação entre humanos e computadores. Conceito bacana, mas enfim, o que isso muda em nosso dia a dia?

A resposta é tudo! – API são a nova quebra de paradigma que se desenha no mundo da tecnologia. IoT e Cloud só evoluíram por conta das APIs. Lembra quando se iniciou a revolução da comunicação empresarial, aquele que não possuísse um telefone para comunicar sua empresa com os seus consumidores e fornecedores estava fora do mercado, agora aquele que não conseguir fazer com que seu sistema se comunique com os demais ou quem não conseguir fazer com que sua “coisa” produto se comunique com outros, estará com certeza para trás.

Em um mundo hiperconectado é necessário termos a garantia de uma infraestrutura sólida, uma rede de comunicações evoluídas, uma cultura DevOps avançada, documentação e muito software. Para os sistemas se conversarem e que haja a evolução, você precisa ter acesso a API do seu concorrente. É preciso entender como a construção dos seus parceiros e concorrentes se comunicam e evoluir com eles.

Atualmente há muita discursão sobre desenvolvimento ágil que se preza pela velocidade de entrega do software, no alinhamento com as partes interessadas, no deply continuo etc. Toda essa discussão iniciou em um momento de destruição criativa. Para tal as APIs promove uma nova quebra de cultura nas empresas, onde será necessário um planejamento maior, talvez desenvolver algo mais demorado, mais caro, mais inteligente, mais resiliente….l

Hoje está em alta as APIs e a tecnologia é assim. Você precisa ter determinado recurso para sair na frente de sua concorrência. Amanhã, ela será commoditie. Repense na jornada de olho na indústria 4.0 e na transformação digital. Aprenda o próximo passo da tecnologia por meio de APIs e cultura DevOps.

Grande abraço.

Luiz Eduardo

A criação de uma empresa: Unindo culturas

Estávamos no final de 2010, exatamente no mês de dezembro, quando concluímos após pelo menos um ano de conversas e negociações a aquisição da Diveo.

Nove fundos, liderados pela Goldman Sachs (que detinha a maior participação da empresa), eram os donos da Diveo.Talvez isso por si só já justifique a demora na negociação, além do que se tratava de um grande deal.

Lembro que uma das críticas que o UOL S/A recebia dos analistas e investidores – nesta ocasião estávamos listados na Bovespa – era justamente de não abrirmos a estratégia em detalhes. Com essa aquisição, ficou claro nossa intenção em entrar de forma expressiva no mercado de datacenter e serviços de TI.
Com a aquisição da Diveo, de fato nos tornamos um grande player do setor, e como já havíamos inaugurado outro datacenter “da Glete” (pois localizava-se na Alameda Glete na capital paulista) em março de 2010, somávamos então 26.000m2 de área construída. Assim, administrávamos o maior parque de datacenters do Brasil e da América Latina.
Vários clientes de grande porte estavam sob nossos serviços, dos mais diversos: colocation, hosting, gateway de pagamento, EDI, quality assurance, segurança, integração de sistemas, infraestrutura de datacenter e telecomunicações!

Sim, telecomunicações, a Diveo também possuía uma rede composta, principalmente, por comunicação via Rádio de alta potência. Confesso que tentamos não incluir essa rede no deal por acreditar que telecom não era nosso foco, porém, o vendedor não queria desassociá-la e argumentava que era justamente um diferencial, pois os principais competidores não tinham sua rede e teriam que contratar de terceiros para concluir a solução.

Além disso, a maioria dos clientes de telecom também eram clientes de hosting ou colocation, o que foi confirmado após o due diligence. Hoje esse rede atende por volta de mil clientes.
A Diveo possuía uma carteira muito rica de clientes que mantivemos e ampliamos os serviços até hoje. No mundo financeiro, hospedamos a maior bolsa de valores da América Latina e mais de 140 instituições financeiras, nacionais e internacionais.

Também juntaram-se mais clientes da área de varejo e e-commerce. Podemos afirmar que prestamos serviços atualmente mais de 70% de todo e-commerce brasileiro, o que nos dá muito orgulho e também enorme responsabilidade.
Agora que já tínhamos um portfólio bastante consistente e uma carteira robusta de clientes, chegou a hora de criarmos um brand para essa nova companhia. Estávamos até então, usando dois brands: UOL Host para o serviços de webhosting e UOL Host Corporativo para identificar os serviços customizados para empresas.

A equipe de marketing, sempre muito criativa, apresentou algumas dezenas de nomes. Mas, nos guiamos pela intuição e lógica, onde poderíamos aproveitar toda a presença e história construída pela Diveo desde o ano 2.000 no mercado corporativo e a modernidade e vanguarda associada a marca UOL. Além disso, alguém comentou que ao preservarmos os nomes de empresas adquiridas, contávamos a história de uma forma simples e direta. Assim, decidimos pelo nome UOL Diveo, e em nossos cartões até pouco tempo, mantínhamos uma discreta assinatura da DHC.

Começamos a partir daí uma nova etapa da Companhia, somado ao difícil desafio de juntar a cultura de várias empresas adquiridas até então, e a nova cultura a ser criada a do UOLDIVEO!

Multicloud x Nuvem Híbrida – Entenda as diferenças

No universo de TI, especialmente em Cloud Computing, constantemente nos deparamos com novas tecnologias, tendências e também novos termos e definições. Há muita confusão no mercado e algumas vezes é difícil entender as diferenças entre definições e termos que parecem ser a mesma coisa, mas não são.

Ao comparar Multicloud com nuvem híbrida, as diferenças podem parecer insignificantes, e muitos profissionais, incluindo aqueles que sabem o que estão falando, usam os termos de forma ambígua, gerando ainda mais confusão e incerteza.

Para assegurar que sua equipe está recebendo a solução de nuvem que melhor se adapte às suas necessidades, é importante compreender que enquanto uma solução de nuvem híbrida pode envolver uma estratégia Multicloud (e vice-versa), os dois termos significam coisas muito diferentes.

Parece complicado? Mas não é. Vamos começar com as definições para ajudar a compreender as diferenças.

O que Multicloud significa?

Multicloud é literalmente o que diz a palavra, ou seja, envolve o uso de múltiplos serviços em nuvem, mas não é só isso.

Multicloud é a combinação de tecnologia, proximidade com o negócio do cliente e pessoas.

Com o incremento da adoção de nuvem, as empresas buscam maneiras inovadoras para alavancar a tecnologia e começamos então a perceber que diferentes nuvens são mais adequadas para diferentes necessidades.

Nos últimos anos, empresas com características tipicamente digitais estão modificando os mercados tradicionais, proporcionando novas experiências aos clientes.

Ao mesmo tempo, organizações convivem com o desafio de manter sistemas e processos legados ao mesmo tempo em que são desafiadas a transformação digital buscando inovação e agilidade. Para isso é importante ter em mente que diferentes aplicações têm diferentes requisitos de nuvem e algumas aplicações não funcionam adequadamente em ambiente de nuvem. E aí que a abordagem Multicloud se faz efetiva, permitindo que empresas utilizem nuvens com tecnologias e características diferentes.

Muitas dessas empresas já entenderam que as nuvens não são iguais e utilizam várias soluções de nuvem para maximizar os benefícios que poderiam obter com a tecnologia. Outras adotam uma solução Multicloud para minimizar sua dependência de um fornecedor específico e garantir que não está presa a um contrato único.

Uma estratégia Multicloud pode contar com soluções de Nuvens  Públicas, privadas ou híbridas, dependendo dos requisitos de cada organização. Basicamente, as empresas que utilizam Multicloud podem estar usando nuvem híbrida em muitos casos, mas Multicloud não significa a utilização de nuvem híbrida obrigatoriamente.

Esclarecendo, Nuvem híbrida refere-se ao serviço orquestrado com base em políticas de provisionamento, utilização e gestão através de uma mistura de serviços em nuvem internos e externos. Em uma Nuvem Híbrida, pode-se utilizar uma Private Cloud para atender a requisitos específicos, controle e maior segurança juntamente com uma Nuvem Pública para escala sob demada. Outras soluções híbridas ainda podem utilizar servidores dedicados para workloads ainda mais específicos. O grande brilho do híbrido é a diversidade de opções para escolher.

Nuvem Híbrida ainda se parece com Multicloud para você ?

Tenha em mente que uma solução Multicloud é aquela em que diferentes nuvens, de diferentes fornecedores, são utilizadas para tarefas separadas enquanto nuvem híbrida se parece mais com a criação de uma solução que contém mais de uma opção de nuvem.

No quesito tecnologia, podemos dizer que em nuvem híbrida, as cargas de trabalho utilizam dois tipos de infraestrutura de hospedagem diferentes, enquanto em Multicloud você está usando várias nuvens.

Apesar disto, o que é preciso ter em mente é que Multicloud não se trata apenas de tecnologia. Como citado acima, Multicloud é a combinação de tecnologia, proximidade com o negócio do cliente e pessoas.

O que é melhor?

Não se trata de melhor ou pior e sim diferente. Empresas que utilizam Multicloud também podem utilizar soluções de Nuvem Híbrida, mas entenda que a principal vantagem de uma abordagem Multicloud é permitir que empresas utilizem nuvens com tecnologias e características diferentes de diferentes fornecedores.

Há diversas maneiras de utilizar Multicloud e nuvem híbrida em sua estratégia de TI.

Nós do UOLDIVEO acreditamos numa estratégia Multicloud próxima ao seu negócio, com uma equipe altamente especializada em serviços de gestão de múltiplas núvens, oferecendo vantagens de nosso acordo de parceria em alto volume com os principais players de Cloud Computing, possibilitando liberdade de escolha e ganho de escala .

Você está preparado para os novos desafios da TI Bimodal?

Precisamos repensar no modelo de gestão tradicional porque não atende mais as necessidades e a velocidade que os negócios precisam.

O novo modelo é desafiador, imprevisível, clama por inovação e rapidez na entrega e claro, não podemos esquecer da excelência.

A TI tradicional, que visa estabilidade e segurança precisa coexistir com o modelo digital que exige agilidade e flexibilidade, agregando valor ao negócio seja ele de qual segmento for.

Neste cenário surge TI Bimodal, mas você sabe do que se trata?

Leia Mais

Você está atento a estes problemas de segurança?

Dicas para monitorar e garantir a segurança virtual da sua empresa:

Segurança da informação já deixou há muito tempo de ser modismo para ser necessidade em qualquer tamanho de empresa. A presença da internet flexibiliza, amplia e concebe um universo de oportunidades para qualquer estratégia de negócio, mas também interliga uma variável relativamente nova chamada de atacante digital.

Na década de 90, era muito comum encontrarmos o atante digital dentro das organizações. Vivíamos momentos com a presença de viroses limitadas a contaminação de disquetes como o vírus ping-pong. Bons momentos, onde era possível fazer uma pausa no texto digitado e observar o símbolo de uma pequena bola sendo arremessada contra os cantos da tela.

Vivemos momentos onde os ataques são altamente sofisticados com estratégias customizadas para cada empresa alvo, orientada por campanhas de e-mails, ataques usando criptografia SSL, furtos de informações pela camada Web ou indisponibilizar a infraestrutura de maneira parcial ou total. Vamos neste texto analisar alguns desafios ligados a Segurança da Informação e identificar como empresas como o UOLDIVEO podem ajudá-lo a resolver cada um destes desafios para que você tenha diferenciais significativos para a sua empresa.

Fraude nos e-mails estão mais agressivas e frequentes

O primeiro elemento que gostaria de abordar é muito comum em qualquer organização. São os e-mails recebidos e identificados como Spams e Phishing. Este último pode ser encontrado em uma versão mais devastadora chamada de Spear Phishing.

Precisamos ter em mente que enquanto o Spam foca-se em um e-mail visando promover a venda de um produto, seja ele legal ou não, o phishing tem o objetivo direcionar a vítima para um site que vai furtar informações pessoais, cartões de crédito, informações bancárias e qualquer coisa que o atacante considere importante. O Spear Phishing estuda todas as características do destinatário do e-mail, indo desde o departamento trabalhado, nomes dos seus superiores e gostos pessoais. Tudo é customizado em um e-mail que ilude o destinatário a instalar um programa em seu computador ou a fazer algo que seja benéfico para o atacante.

Grande parte dos e-mails acompanham campanhas publicitárias e direcionam para sites clonados causando danos financeiros a marca de uma empresa, forçando o envolvimento do departamento jurídico com ações de clientes que foram enganados pelos atacantes ou ainda forçando o investimento em estratégias para refazer a credibilidade de uma marca no mercado. O site clonado pode estar presente nas redes sociais, em blogs ou em ambientes de cloud pública dentro ou fora do Brasil. O processo de desativação deste site pode ser muito complexo e custoso. É necessário o monitoramento de e-mails, redes sociais ou mídias sociais 24 horas por dia por especialistas que tenham experiência neste modelo de operação. Como definir um plano que realmente funcione contra estes ataques?

Ataques criptografados se destacam nas previsões do Gartner

Segundo o Gartner, o tráfego criptografado cresce 20% ao ano e 80% das empresas não inspecionam seus tráfegos Web. Existem centenas de justificativas para esta ausência de inspeção, mas podemos dizer que a principal é a sobrecarga em processamento que gera nos hardwares de firewalls ou equipamentos de IPS (Intrusion Prevention Systems), por exemplo.  Infelizmente percebe-se que o uso de ataques envolvendo criptografia se elevam a cada ano, seja para a comunicação de malware ou para ataques a servidores Web. O resultado final é sempre a perda financeira, seja por dano diretos ou indiretos à imagem, perda de vendas devido a sites invadidos ou furto de informações pertencentes a clientes. Ter a informação furtada é sem dúvida um grande problema, mas tê-la divulgada é um problema maior ainda. É importante ter um plano de ação que inclua o corpo diretor e a equipe de operação envolvida e treinada.

Note que um erro muito comum é ter um plano de ação de segurança de várias páginas e não ter a equipe treinada para responder a um evento guiado por um ataque digital. Mais importante do que comunicar é como comunicar um incidente de segurança. Ter uma assessoria de imprensa que não está preparada ou que não tem o apoio para responder tecnicamente aos questionamentos é pior do que não comunicar.

Uma estratégia usada com sucesso por empresas internacionais é minimizar o aparecimento na mídia e limitar a uma única reunião para apresentar esclarecimentos aos investidores e a imprensa. Outro ponto importante aderente a qualquer empresa é testar periodicamente o plano de resposta a incidentes de segurança.

Com os ataques se tornando mais complexos e mais frequentes, torna-se necessário criar uma cultura de segurança mais transparente, preparando e concebendo as aplicações de maneira diferenciada, juntamente com os elementos que a protegem. Ver-se que elementos de uso simples e de baixo custo não usados por muitas empresas. Um exemplo disto é o certificado SSL. Apesar dos benefícios da criptografia em sites Web serem claros e muito vantajosos, possibilitando não só a elevação da confiança dos usuários, mas também elevando a prioridade nas listas de pesquisa do Google, vê-se que poucas empresas fazem usos desta vantagem, deixando um farto oceano de oportunidades para os atacantes digitais. Os certificados digitais podem e devem ser usados por qualquer tipo de aplicação Web.

Bom lembrarmos que segundo o HIPAA (Health Insurance Portability and Accountability Act), PCI Security Standards Council e PII Laws (Personally Identifiable Information), deve-se manter criptografadas todas as informações referentes a dados pessoais, elementos financeiros e informações envolvendo empresas de saúde. Não obedecer a estas indicações pode acarretar em implicações graves.

Novamente devemos nos perguntar o que fazer? Que estratégia devemos seguir para elevar a proteção?

Cloud são seguras, mas você está usando-as corretamente?

Muitas vezes imagina-se que um ambiente de Cloud é inseguro e que projetos usando plataformas de virtualização dentro das empresas formam ambientes de segurança superiores. Primeiramente é importante o entendimento que existem tipos distintos de Cloud, e estes tipos são aderentes ao grau de maturidade da aplicação analisada. Saber se uma Cloud pública em OpenStack, AWS, Microsoft Azure, Google ou ainda uma Cloud Privada é mais adequada a maturidade da sua aplicação é um elemento de sobrevivência indispensável para qualquer empresa.

Observe que não é uma questão de saber qual é a Cloud mais barata para o portal Web da campanha do mês de novembro, mas saber onde a aplicação vai ter uma melhor performance ou onde vai apresentar melhores requisitos de segurança para o projeto proposto. Observe as Clouds Públicas, o uso de controles em seu ambiente são elementos mais rígidos do que muitos projetos dentro das corporações. Este fator é certamente influenciado pelo compartilhamento físico dos servidores. Note que o nível de segurança é muito maior do que os usados tradicionalmente e que a invasão de um cliente por outro é praticamente impossível.

Outra visão importante aborda a relação Compliance e Ambiente em Cloud. Devemos entender que mesmo contratando um provedor em nuvem que possui uma certificação em segurança, isto não faz com que a aplicação de uma empresa hospedada e exposta para a internet esteja segura ou seja resistente a qualquer tipo de ataque digital. A proteção contra este modelo de atacante é um projeto adicional que faz uso de diferentes camadas de defesa, indo desde do desenvolvimento do código-fonte, passando pelo projeto de camadas de defesa e terminando com a escalabilidade e flexibilidade do ambiente usado.

Os ataques direcionados a aplicações em nuvem não são diferentes dos ataques direcionados para os ambientes fora dela. A abordagem buscando por erros humanos continua a mesma, a busca por falhas na aplicação ou no modelo de acesso ao ambiente de gestão continua a mesma. O questionamento também continua o mesmo: o que pode ser feito para elevar a proteção do negócio?

Quais lições podem ser aprendidas?

Os ataques digitais não vão reduzir de intensidade. A realidade mostra que teremos volumetrias bem superiores e muito mais agressivas a tudo que vemos hoje. Olhando somente para os dispositivos móveis, encontraremos previsões indicando que 70% da população mundial estará fazendo uso de algum tipo de dispositivo móvel conectado à internet em 2020 e isto representa 5,5 bilhões de pessoas. Só para o Brasil estima-se que terá mais de 182,1 milhões de usuários móveis e nem aprofundamos as análises envolvendo IoT (Internet das Coisas).

O segredo é como estaremos preparados para estes ataques. Ter um comitê de segurança multidisciplinar é importante, mesmo para as pequenas empresas. Treinar a equipe técnica, juntamente com este comitê vai ser inevitável para responder de maneira clara e objetiva a um atacante digital.

Outro ponto importante é que não podemos construir toda defesa eletrônica em uma tecnologia apenas ou em um processo de gestão que não opera 24×7. Ter o apoio de uma equipe experiente é questão de sobrevivência. Um exemplo claro deste tema é representado pelos ataques DDoS (Distributed Denial of Service), que hoje atinge valores superiores a 500Gbps de pico. Tenha em mente que a defesa contra um ataque DDoS não se faz só, sendo necessária a presença intensa do provedor de acesso bloqueando e identificando o atacante internacional e nacional.

Para concluir, tenha em mente que a defesa digital é uma equação que precisa ser equalizada entre três variáveis importantes representadas por processos, pessoas e tecnologia, independente se lidamos com um ambiente em Cloud ou não.

 

Denis Souza

 

Boas Práticas com Docker

No post sobre DevOps foram citadas inúmeras ferramentas que facilitam e permitem cultivar uma cultura DevOps. Minha escolha para iniciar esta jornada foi o Docker. Em vez de convencer que o Docker é bom ou explicar como instalar e subir o primeiro container, vou focar em questões da nossa experiência com o Docker. Questões simples mas importantes acabam passando desapercebidas e geram problemas em produção.

Se você está iniciando em Docker, recomendo começar pela documentação oficial, que melhorou bastante nos últimos tempos. Se você ainda está em dúvida para onde as coisas caminham, dê uma olhada neste gráfico. Containers já são uma realidade.

Entendendo Problemas de Consistência

Com todo o hype em torno de containers, é natural que existam sentimentos do tipo “precisamos usar Docker porque todo mundo está usando” ou “vamos usar Docker porque é legal”. Docker, como qualquer ferramenta, tem seus principais valores. E no caso, posso resumir o valor do Docker em uma palavra: consistência. É importante entender o que isso significa para implantar a ferramenta de forma adequada em seu ciclo produtivo.

Pré-Puppet (ou Chef, Ansible…)

Vamos supor que você precisa subir uma aplicação nova. Máquina provisionada, SO instalado, você loga na máquina e:

  • Atualiza o sistema operacional.
  • Instala os pacotes da sua aplicação (apt, yum, zip (!!) etc).
  • Edita os arquivos de configuração.
  • Coloca o serviço no boot.
  • Reboot.

Este fluxo representa a maioria dos casos, e é um bom exemplo.

Agora solicitaram subir mais máquinas idênticas… será tedioso.

Mecanizando o Processo

De posse de ferramentas de gestão de configuração, você escreve o código que mecaniza todo o processo. Maravilha! Máquinas novas provisionadas para produção em segundos!

Porém, saem novas versões da aplicação o tempo todo, problemas aparecem em produção e a únia solução é “formatar” a máquina…

Gerenciando Alterações

Vamos entender onde o problema ocorre. Você recebe a máquina M1, apenas com o SO (BareMetal):

M1 > BareMetal

Então, aplica a sua automação, v1, em cima:

M1 > BareMetal > v1

E leva a máquina para produção, na versão v1. Mas claro, vem a v2 da automação, e você aplica:

M1 > BareMetal > v1 > v2

Agora você adiciona uma nova máquina M2, para suportar a v3:

M1 > BareMetal > v1 > v2 > v3

M2 > BareMetal > v3

E de repente, a M1 funciona, mas a M2 não! Claramente, M1 foi submetida a um fluxo (v1 > v2 > v3) totalmente diferente da M2 (v3), e fatalmente o estado real e final da M2 não é o mesmo da M1, mesmo que ambas foram submetidas à mesma receita v3. Uma causa comum por exemplo, é que a v2 instala uma dependência, que a v3 não pede.

Para resolver o problema, só começando do zero.

Entregando Com Consistência

Achado o bug, criamos uma v4, e entregamos em uma máquina M3:

M3 > v4

Isso funciona porque o fluxo é mais consistente. Pra fechar a questão, matamos as máquinas M1 e M2, e provisionamos as máquinas M4 e M5, no mesmo fluxo da M3:

M4 > v4

M5 > v4

Maravilha! Um mês depois, você provisiona a M6, para suportar a carga crescente:

M6 > v4

E novamente, problemas! Como pode? M4 e M5 foram submetidas ao mesmo fluxo do M6! Fatalmente é algum fator externo, como por exemplo updates do SO que estão na receita. Alguma versão mais nova de dependência que está presente somente na M6 está gerando problemas.

“Que maravilha!”, você pensa. Agora vamos à estaca zero para versionar TODOS os pacotes do sistema operacional, repositórios, etc…. não vai ter fim.

Containers Para a Salvação!

Bem, é exatamente todo esse stress que containers evitam. Fazendo uma analogia, containers são como um snapshot de uma VM em um estado confiável. Este snapshot pode ser utilizado para instanciar quantas VMs forem preciso, de forma confiável. Na terminologia do Docker, os snapshots se chamam imagens e as VMs containers:

Dockerfile > Image > Containers

Uma vez com a imagem pronta, você pode instanciar quantos containers forem precisos, onde for preciso, rapidamente e com confiança!

Além do Ambiente de Produção

 

Um container é algo tão leve e rápido, que consegue ser utilizado na máquina do desenvolvedor e também no servidor em produção, com fidelidade altíssima entre os ambientes. Além disso, o Docker Registry resolve o problema de se compartilhar imagens. Imaginem que eu como desenvolvedor preciso fazer o QA do meu sistema, que tem dependência de um sistema terceiro. Eu posso simplesmente utilizar a imagem do container de produção deste sistema! Nada mais de “o QA está fora”, ou “o orçamento para máquinas de QA está alto”.

 

Docker traz assertividade, confiabilidade e redução de custos, levando para o início do ciclo de desenvolvimento a mesma tecnologia e performance que existem no ambiente de produção.

Pontos de Atenção Com Docker

Criar um Dockerfile e subir o primeiro container é quase trivial. Entretanto,alguns pontos importantes, triviais de se implementar, muitas vezes são esquecidos. Em especial, no Docker Hub, há imagens prontas para praticamente qualquer coisa. Entretanto, a maturidade e qualidade delas varia grotescamente. Olhe as imagens e valide se os Dockerfiles seguem bons princípios. Somente então as utilize.

 

Alguns dos pontos levantados aqui são parte do http://12factor.net/, vale a leitura complementar.

Não Executar Como root

Um dos anti-patterns mais comuns com o Docker é executar os processos do container como root. Há uma certa argumentação válida de que a kernel já garante isolamento entre containers, mesmo eles sendo executados como root. Vou dar crédito para isso. Porém, há uma série de abusos que podem ser feitos dentro do container, como sobrescrever binários, arquivos de configuração etc… Pense assim: para quê rodar como root? O único caso que consigo pensar é executar um container privilegiado, que por si só é algo tão fora do padrão, que pode ser até considerado um anti-pattern.

Logs Fora do Container

Apesar de não haver nada proibindo você de gravar logs dentro do container, isso fatalmente irá te causar problemas. Na próxima atualização, quando for entregue um novo container, TODO o conteúdo dos logs antigos será perdido. As opções são:

  • Mapear o diretório de logs para um volume que será persistente, e anexado a novas versões do container.
  • Enviar os logs para outra ferramenta externa (ex: Elastic Search, Splunk).
  • Enviar logs para o STDOUT / STDERR.

Este último é a boa prática com Docker, utilize se possível. É trivial configurar o Docker Engine para que os logs de TODOS os containers sejam redirecionados para algum local externo. Cuidado com esta configuração e garanta que os logs estão sendo devidamente rotacionados, e os antigos apagados.

Volumes de Dados

Pelo mesmo motivo dos logs, dados importantes persistidos pela aplicação devem sair do container (ex: /var/lib/mysql). Caso contrário serão perdidos quando o container for destruído.

 

Este ponto é melhor compreendido se olharmos para uma arquitetura completa:

Web Tier > App Tier > BD

Apenas a camada de BD persiste dados, logo deve ser a única elegível para utilizar volume de dados (sujeito a backup). Pense nas demais camadas como “imutáveis”: os containers nela devem poder ser destruídos sem qualquer tipo de prejuízo, a qualquer momento. Isso facilita bastante a administração e acaba sendo um requisito importante se você está pensando em qualquer tipo de auto-scaling.

Configurações Através de Variáveis de Ambiente

Outro anti-pattern comum é colocar um grande volume de configurações no container, em arquivos. Não há nada de errado nisso, mas você tem dois pontos a considerar:

  • O que muda do container de produção para o de QA?
  • A mesma imagem pode ser utilizada para criar containers em ambientes distintos (eg: Apache como proxy para 2 sistemas)?

O que for identificado como necessário para que a mesma imagem atenda mais de um cenário deve ser informado via variáveis de ambiente na criação do container (ver –env)! O seu ENTRYPOINT deve ser responsável por interpretar estas variáveis e fazer os ajustes necessários. Uma opção comum é colocar no ENTRYPOINT um shell script que lê as variáveis de ambiente (tipicamente usuário e senha), gera o arquivo de configuração adequado e depois executa o processo do container.

 

Permitir “reciclar” a mesma imagem em mais de um cenário tem sempre que estar em mente. Minimamente produção e QA acabarão existindo. Tome cuidado para não abusar deste modelo. Uma coisa é colocar os certificados HTTPS em variável (um pattern que já vi algumas vezes) e outra é colocar TODO o httpd.conf do Apache em uma variável de ambiente. Ambos funcionam, mas claramente há um pouco de bom senso nisso. A regra do dia a dia é: se é algo que muda entre cada ambiente, vai para variável de ambiente, caso contrário vai para o container diretamente.

Operating System updates

Já pensou o como corrigir o próximo bug nojento do OpenSSL em todos os seus containers em produção? A resposta é simples: não se corrige. Pense em containers como algo imutável. Se você precisa atualizar algo, inclua no seu Dockerfile um comando pra atualizar o SO e o que mais for necessário e entregue a nova versão do container. Tecnicamente é possível entrar em um container e atualizar o SO, mas faz pouco sentido pois viola o princípio da imutabilidade.

Nomes das Tags

Uma consequência de atualizar o SO diretamente do Dockerfile (ex: apt-get upgrade) é que um mesmo Dockerfile, utilizado para criar imagens em dois momentos distintos, gera duas imagens distintas. Isso ocorre devido a dependências externas na criação do container, que mudam com o tempo (ex: versão do OpenSSL). Uma opção seria controlar também a versão dos pacotes no repositório do SO porém uma solução mais simples, seria adotar um padrão para a tag de cada imagem:

[git tag]_[data]

Ex:

V1.0.10_2016-07-07_18-36

Apesar de um pouco extenso, o node permitirá melhor gestão. Ex: você só precisa atualizar o SO do container, mas a versão da aplicação é a mesma. Sem problemas. Fica claro pelo nome que é a mesma versão da aplicação, mas dependências externas são diferentes.

 

Utilizar a tag “latest”, além da tag específica, também é uma prática comum para indicar qual a versão de produção.

Pacotes de SO / Prateleira

Se você vai executar uma aplicação que não foi feita para ser executada em container, tenha os seguintes pontos em mente:

  • Os scripts de start / stop do SO não foram feitos para serem executados em container.
    • Eles irão fazer fork() do daemon, e você verá uma morte prematura do container.
    • Você deve invocar o binário do daemon diretamente no ENTRYPOINT do container.
  • Rotação e purga de logs geralmente funcionam via cron, porém não há cron no container.
    • Tente redirecionar os logs do daemon para stdout / stderr.
    • Se não por possível, a alternativa é usar um entrypoint que suba o cron no container, e depois execute o daemon.

Um Processo por Container

Esse é um mantra comum na comunidade Docker, mas é bastante mal compreendido. Pense em um Apache MPM, que abre diversos processos para atender requisições. Ele viola o princípio do Docker? Bem… não. Uma melhor formulação do mantra seria “uma aplicação por container”. Exemplo: se você tem um Apache e um Jetty para subir, coloque cada um em seu container. Este artigo explora o cenário de mais de um processo por container.

Tecnicamente, você pode rodar o init em um container, e “subir o SO do zero”. Nada te impede disso. Porém isso vai contra a mentalidade de containers serem leves, auto-contidos e descartáveis. Um SO completo sobe uma variedade de serviços que sua aplicação no container não precisa… inclusive o próprio init.

Conclusão

Não pense em Docker / containers como uma opção, mas sim como algo inevitável. Quanto antes você estiver nesta onda, melhor. Mas compreenda bem a mentalidade por trás e use a ferramenta certa, da maneira certa, para o problema certo. Não somente “siga o hype” cegamente.

Inovação: Reinventando a organização

Peter Thiel começa seu livro Zero to One com a seguinte citação: “Cada momento nos negócios acontece uma só vez”.
Agora, pense nisso por alguns instantes.

Aqui no Blog, já conversamos com você sobre transformação digital e como isso deve mudar o comportamento das organizações. Tudo aquilo que era considerado o estado da arte tende a ficar obsoleto rapidamente.
Não estamos falando simplesmente de uma transformação de TI, mas sim de uma transformação cultural. A maneira como a organização passa a gerar valor para seus clientes está intimamente ligada em como ela compreende seu ecossistema e consegue antecipar tendências.

Tecnologia é uma arte. A arte de prover soluções para problemas de qualquer natureza.
Gosto de pensar desta forma e trazer para presente, onde as organizações já pensam TI em suas mais váriadas formas: sustentação, algumas vezes o próprio negócio ou o impulso que vai reinventar a própria Organização. Quem sabe até o Mercado!

Naturalmente vamos falar mais e mais de convergência e automação de todas as camadas, de como as empresas vão ver seus dados como um recurso a ser explorado para obter insights, inovação, gerar novas oportunidades e também o lucro. Tudo isso sustentado por um modelo de inteligência e detecção de ameaças ou mesmo tendências, que só vão acelerando na medida que novos padrões são desenvolvidos.

E neste espaço já apresentamos algumas ferramentas e métodos que entre outras ganhos vão promover uma adequada gestão do conhecimento, afinal, somente com conhecimento que se consegue identificar se os processos e tecnologias estão alinhados com os objetivos da organização, ou se estão terrivelmente longe (assunto para outro post).
Então ser digital também é ter um olhar tecnológico e crítico para as estratégias de negócio.

E como estimular este potencial? Pessoas, cultura e ambiente.

Sua estratégia de transformação passa pelas pessoas. São elas que vão apoiar sua decisão de tecnologia, promovendo o engajamento necessário para este processo de transformação. Em outras palavras, a gestão destas mudança e comunicação adequada vai te ajudar a reduzir riscos nos processos que afetam os negócios e tecnologia.
Comunique seus objetivos de forma clara, estimule o time a pensar diferente.
Entenda que toda organização é única. É um sistema complexo, mas que vai se adaptar ao que você promover internamente. Mova as peças chaves. Quebre o paradigma de que apenas manter os sistemas funcionando é o único papel da TI.

Agregue, promova. Coloque os talentos para interagir.

Desenvolva a cultura de colaboração. Estimule a cocriação e a exploração de métodos e outros mercados.
Relembrando como iniciamos, “Cada momento nos negócios acontece uma só vez”. Tenha em mente que agir no momento certo, é o que define o futuro da maioria das organizações. E isso será crucial para qualquer time de TI.

Causa Raiz – da Inexistência à solução

Quando falamos em tecnologia todos sabem que por mais preparado, moderno e controlado que seja o ambiente, em algum momento este pode sofrer uma interrupção, seja ela de pequeno impacto a indisponibilidade de grande proporção, e que após a recuperação do ambiente teremos o famoso e temido “RCA” (Root Cause Analysis).

Apesar deste fato ser conhecido e as empresas cada vez darem maior importância a análise de causa raiz, muitos casos a metodologia não é seguida e/ou implementada com sucesso.

Afinal de constas porque o RCA não funciona?

Este post propõe-se a expor experiências de como melhorar a análise de causa RAIZ para ser solução, e não um novo problema. Vamos debater o tema e passar experiências como:

  • Metodologia de investigação (Processo)
  • Como aplicar a metodologia (Técnico)

Todos já ouviram falar de “Sherlock Holmes”,  este trecho abaixo tive a oportunidade de conhecer em pesquisas de análise de Causa Raiz e vou usar como “CASE”, vou comentar cada item e falarmos das regras básicas para o sucesso. Nesta ficção temos o maior exemplo de método cientifico de análise e solução de problemas, veja o que ela nos ensina:

Sherlock Holmes tinha paixão pelo conhecimento exato e preciso, ou seja, os dados devem ser coletados para provar a hipótese antes de determinar a causa raiz em uma análise.

Regra número 1: Nada deve ser concluído sem “FATO”. Devemos sempre provar a análise.

Sherlock Holmes acreditava que investigando vários crimes (1000) teria informação suficiente para solucionar o 1001º crime. Examine dados de eventos similares pois estes ajudarão a aprimorar o processo de análise.

Regra número 2: A experiência de vários casos ajuda o próximo. Tenha um sistema de base de conhecimento, seja ele qual for.

Sherlock Holmes acreditava que o mundo está repleto de coisas óbvias que ninguém, por qualquer motivo, observa.– Isto implica em não aceitar a primeira explicação, sem atentar para todos os detalhes.

Regra número 3: Aqui está um item que sempre devemos levar para o time, podemos resolver muitos casos com o obvio. Mas nunca devemos esquecer que a riqueza da informação leva a certeza.

Algumas frases do nosso professor “Sherlock Holmes”:

 “É um erro capital teorizar antes de se ter os dados. Insensivelmente, começa-se a distorcer os fatos para adaptá-los às teorias, em vez de fazer com que as teorias se adaptem aos fatos.”

  “Dados! Dados! Preciso de dados! Não posso fazer tijolos sem barro!”

  “Jamais arrisco um palpite. Isso é um hábito chocante… fatal para a capacidade de raciocinar logicamente.”

Regra número 4: Nunca arriscar palpite ou teorizar

Após as regras estarem definidas precisamos definir as fases da análise, cada empresa ou profissional pode ajustar conforme a necessidade, mas vou colocar aqui as que podemos chamar de “obrigatórias”, que atendem inclusive processos de certificação.

  1. Definir o problema
  2. Identificar as possíveis falhas
  3. Verificar a real causa
  4. Propor a solução
  5. Implantação e acompanhamento dos resultados

Bom pessoal, para não ficar um blog maçante vou parar por aqui e nos vemos a semana que vem onde vamos falar de, como definir o problema, identificação das falhas e real causa. Não perca.