Source: https://uilson76.wordpress.com/author/uilson76/
Timestamp: 2018-07-17 05:57:42+00:00

Document:
uilson76 | InfoSec and Cloud Thoughts
Arquitetura, Processos e Governança em CyberSecurity… e um pouco de infra estrutura – all vendors allowed!
GDPR–Fundamentos que o ITPro precisa saber
20 de junho de 2018 uilson76	1 comentário
Desde 25 de maio deste ano está em vigor a norma GDPR (General Data Protection Regulation), visando melhor proteção de dados pessoais para União Européia. Neste post vamos descrever alguns fundamentos, os principais artigos e como os principais players de mercado estão agindo em relação a isso.
Pra quem segue minha fan page (https://facebook.com/usouzajr), estou postando diversos videos da equipe do Microsoft Mechanics, sobre como integrar Office 365 e demais ferramentas Microsoft (Azure) à norma.
Mas, se a norma é para União Européia, porque eu, que estou aqui no Brasil ou continente americano como um todo precisaria saber disso? Vejo dois fortes motivo para que você aprenda sobre GDPR:
1. A norma engloba qualquer empresa que, mesmo em outros continentes, tenham acordos, contratos ou qualquer tipo de envolvimento com empresas européias que envolvam o armazenamento de dados pessoais de cidadãos europeus. Se você é consultor e vai prestar algum serviço para uma empresa européia que contemple manuseamento de dados pessoais, ou se sua empresa, mesmo fora da Europa armazena dados de cidadãos europeus… ou seja, podemos concluir que norma não é uma exclusividade para europeus ou emperesas européias.
2. Como todas as outras normas que conhecemos (ISO, PCI, entre outtras), muitas começaram em um mercado restrito e hoje são padrões para o mundo todo, além do que, conversando com algumas autoridades em compliance, eles têm a certeza de que a norma GDPR vai se expandir em caráter mundial muito em breve.
Bom, então vamos falar de GDPR:
No que se baseia:
Personal Data (Dados Pessoais) – Tudo o que identifica alguém (RG, CPF, Social Security # pra quem é de US, informações médicas, etc).
Sensitive Data (Dados Sensíveis) – Uma categoria que, dentro do GDPR requer uma proteção mais forte. Trata-se de dados genéricos, biometria e qualquer tipo de dados que revele informações sobre regligião, raça ou origem étnica.
Data Privacy (Privacidade de dados) – A relação de coleta e disseminação de dados, tecnologia, expectativas públicas de privacidade e os aspectos legais e políticos ao redor do tema.
Consent (Consentimento) – Quando da concordância da pessoa em questão, informações específicas sobre ela são livremente divulgadas.
Processing (Processamento) – Qualquer operação executada com dados pessoais em que envolva coleta, armazenamento, alteração, recuperação, deleção ou destruição de dados.
O GDPR foi criado e é mantido pela União Européia em 2018, sendo a evolução de outra norma criada em 1995 – o DPD (Data Protection Directive 95/46/EC).
O DPD não contempla manipulações de dados que podem ocorrer em infras de Cloud Computing, IOT (Internet of Things) e big data, sendo que o GDPR se torna uma resposta rápida a estas tecnologias.
A norma é resultado de um trabalho de 4 anos do Parlamento da União Européia para criação de uma norma que atenda de forma eficaz a demanda por segurança para o processamento de dados pessoais.
A União Européia contabilizou em suas pesquisas mais de 1.000 brechas encontradas em armazenamentos de dados de seus cidadãos em 2016, num total de 36.6 milhões de registros vazados. Já em 2017 esse número subiu para 1.222 brechas com vazamento de mais de 172 milhões de registros – um aumento absurdo não?
Algumas normas que transitaram pela europa desde 1995 – ano de criação do DPD:
– Safe Harbor Privacy Principle – ano 2000 – Norma extinta
– Privacy Shield – Norma criada em 2016
O GDPR vem contemplando todas as anteriores de forma mais completa
– Controle: Dá à pessoa mais controle sobre como seus dados pessoais são usados, podendo revogar esta divulgação a qualquer momento.
– Confiança – Controles mais rígidos para aumentar a confiança na economia digital.
– Simplicidade – Dá ao negócio uma visão jurídica mais clara para bom seguimento das operações.
Envolve todos os setores que fazem negócios com empresas européias – seja Europa ou não. Como falei acima, se eu, como empresa, vou atuar em corporações européias em projetos qu envolvam manipulação de dados, também terei que me adequar à norma.
Outro caso é… empresas fora da União Européia que armazena dados de cidadãos europeus – também entram na norma.
A norma GDPR possui 11 capítulos com 99 artigos em cada capítulo. Todo o conteúdo pode ser lido no site da norma – https://gdpr-info.eu/
No link acima também é possível fazer o download do arquivo PDF com todos os artigos da norma nos seus 11 capítulos.
Fluxo de ação da norma:
O fluxo da GDPR tem dois atores importantes:
Data Controller – Autoridade que define por si ou em grupos os propósitos e significados para o processamento de dados pessoais. Deve assegurar a conformidade da norma, informar detalhs dos dados, exigir medidas ténicas e acordos firmados com processos.
Data Processor – Autoridade que processa dados pessoais em nome do data controller – geralmente uma empresa que presta serviços para outra que atua como data controller. Exemplo: Uma empresa seguradora que armazena seu banco de dados de clientes em um Azure SQL. Neste caso a seguradora seria o Data Controller e a Microsoft o Data Processor.
O Data Processor tem por tarefa:
. Gravar o processamento das operações
. Implementar medidas de segurança
. Informar brechas – qualquer uma que for encontrada – desde a maior até a menor
. Definir um DPO (Data Protection Officer) – Figura de liderança na segurança corporativa do Data Processor e função obrigatória para empresas que seguem a GDPR.
Abaixo uma tabela comparativa das tarefas do Data Controller e do Data Processor:
Ainda sobre a figura do DPO:
. Necessita ser um profissional independente, ou seja, sem conflito de interesses
. Deve exercer a função para um determinado Data Processor por um mínimo de 2 anos e deverá ficar no máximo 4 anos.
. Não poderá deixar o cargo sem estar religiosamente em dia com as obrigações da norma, salvo por justificativa apreciada e aprovada pelo alto comando.
Tem como tarefas:
. Informar a situação da empresa em relação a norma
. Aconselhar melhores práticas
. Registrar todas as operações garantindo o cumprimento da norma
. Estar sempre em conformidade
. Ser o ponto de contato para qualquer dúvida do process
. Cooperar com a União Européia e demais agências governamentais
Para que o Data Processor e o DPO possam exercer todas as funções citadas, existem uma série de responsabilidades que o Data Controller deverá preencher:
. Implementar medidas técnicas/organizacionais e demonstrar que está fazendo tudo da forma correta – documentar todo o processo
. Considerar a natureza, escopo, contexto e propósito da corporação
. Considerar a probabilidade e a gravidade dos riscos para os direitos das pessoas e impactos provenientes de um vazamento de dados.
. Definir e implementar a política de proteção de dados
. Definir e implementar um código de conduta demonstrando conformidade com as obrigações da norma
Multa para não conformidades:
Tenho visto alguns artigos sobre o tema em que a questão da multa para não conformidades é tratada de forma um pouco rasa, então quero aqui colocar mais detalhes sobre a multa.
Empresas que não estiverem em conformidade com os artigos 8, 15, 25 a 39, 41, 42 e 43, estão sujeitas a multa que varia de 10 milhões de Euros a 2% da receita anual.
Empresas que não estiverem em conformidade com os artigos 5, 6, 7 a 9, 12 a 22, 44 a 49, Capítulo IX e 58, estão sujeitas a multa de 20 milhões de Euros a 4% da receita anual.
Artigo 16 – dos direitos de correção – para qualquer dado cadastrado de forma errada ou imcompleta. A correção destes dados é de responsabilidade do Data Controller com tempo de resposta no mínimo de 1 mês e no máximo 2 meses – dependendo do caso.
Artigo 17 – do direito de ser esquecido. Quando da solicitação de deleção de dados de uma determinada base. De responsabilidade do Data Controller que deverá proceder a deleção de dados por solicitação do dono dos mesmos ou quando sua existência não se justifica. A deleção de dados se fundamenta no propósito, consentimento, objeção, legalidade e conformidade.
Artigo 21 – Direito do objeto – quando a legalidade do dado é de interesse público ou de interesse legítimo. O Data Controller deverá cessar o processamento com apenas duas exceções; Sob Requerimento ou sob motivos justificados.
Artigo 8 – Requerimentos especiais. Aplicado a menores de 16 anos. Neste caso, dados de menores precisam do consentimento parental.
Artigo 20 – Direito de portabilidade – quando o dono do dado requer a transferência de seus dados de um data controller para outro. Nestes casos o processo tem prazo máximo de 30 dias para ser concluído.
Artigo 33 – Tempo de notificação – em caso de riscos a direitos e liberalidades do dono do dado, uma notificação deverá ser feita a autoridade supervisora. Começa com notificações internas (Time de Segurança da Informação, Tecnologia da informação, Jurídico, áreas de suporte, direção), em seguida para partes externas (orgãos de aplicação de leis, seguradoras, perícias e relações públicas). A autoridade supervisora deverá ser informada do risco pelo data controller em até 72 após descoberta de determinada brecha de dados. Esta informação deverá conter a natureza da brecha, contato do DPO, prováveis consequências, mitigação proposta e plano de ação que poderá ser executado em fases distintas.
Artigo 83 – Também focado em medidas de notificação em caso de uma brecha de dados pessoais. Neste caso para exposição acidental ou deliberada sob risco de perda, destruição, alteração, divulgação sem autorização e acesso a dados pessoais transmitidos, armazenados ou de alguma forma processados. De igual forma ao artigo 33, o data controller tem que notificar a autoridade supervisora em até 72 após descoberta do fato, exceto se uma determinada brecha não causa risco. Caso o prazo de 72 horas seja excedido, cabe à autoridade supervisora elaborar a justificativa ao data subjetc (dono do dado). A informação deverá conter a natureza da brecha (numero de pessoas e registros), contato do DPO, consequência provável, mitigação proposta e plano de ação que poderá ser executado em fases distintas.
Medidas Tecnicas:
O artigo 32 da GDPR (dos quais resulta multa o não cumprimento), trata das medidas técnicas a serem adotadas. Estão divididas em 4 fase:
1. Criptografar dados e torna-los anônimos
2. Classificar os dados quanto a confidencialidade, integridade e diponibilidade, resiliência no processamento de sistemas e serviços, alinhados com as normas da CIS Controls.
3. Controle crítico de segurança:
. Inventários – hardware, software, etc
. Configuração segura de equipamentos
. Análise de vulnerabilidades
. Controle de privilégios administrativos
. Implementação de ferramentas de anti-virus e anti-malware
. Controle e segurança de rede – perímetro, etc.
. Pentest – Teste de penetração de forma regular
. Monitoramento
4. Backup / Restore – Definição de política e testes contínuos de restore
Demais controles:
A GDPR também requer a adoção de um Run Book (Diário de bordo de operações e processos). Neste diário de bordo devemos ter as seguintes informações:
. Informações do sistema
. Segurança e controle de acesso
. Configuração do sistema
. Monitoração e alertas
. Tarefas operacionais
. Tarefas de manutenção
. Procedimento de recuperação de falhlas
Como os principais players de mercado estão agindo na GDPR:
Veja abaixo alguns links para as principais novidades oferecidas por Microsoft e AWS no que tange a norma:
Microsoft se torna o primeiro provedor de cloud a oferecer comprometimento total com obrigações da GDPR
Cópia de dados pessoais dentro da norma GDRP para clientes do Office 365
GDPR for Office On-premisses servers
Adequando Azure Active Directory ao artigo 17 – Direito de ser esquecido
Conferindo se sua infra estrutura na AWS está em conformidade com a norma GDPR
Como a GDPR afeta usuários da AWS
AWS e a norma GDPR
Anúncio da AWS sobre a conformidade de seus serviços em 100% em relação à GDPR
Abaixo você tem um resumo da norma em uma forma mais visual:
Neste post mostrei um resumo da norma GDPR para ITPros com os principais artigos e como Microsoft e AWS (principais players de mercado em cloud) se ajustaram à ela.
Para quem quiser mais detalhes, o meu amigo, Prof. Eduardo Popovic gravou um video detalhando a norma GDPR e PCI com base neste artigo. No link abaixo você assiste à apresentação dele que ficou sensacional:
https://youtu.be/6CEMuKU2Zp4
Espero que possa ser útil e não se esqueça, estamos prestes a ter aprovada pelo governo brasileiro a lei de proteção de dados pessoais, ou seja, com este conhecimento você se adianta e, como disse no começo deste post, existe grande possibilidade da GDPR se expandir além do território da comunidade européia.
Categorias:Não categorizado
Meus apontamentos sobre a prova CLO-001–Cloud Essentials da CompTIA–Capitulo 6
2 de maio de 2018 uilson76	Deixe um comentário
Hoje chegamos no último volume desta série de posts sobre a prova CLO-001 – Cloud Essentials da CompTIA. Peço desculpas pela demora, mas, o trabalho andou tomando um tempo grande e só pude retomar hoje.
Agregado a este post você terá também o link para um webcast que entreguei sobre esta prova para o Canal vBrownBagBrasil no Youtube.
Reitero que essa série de posts foi autorizada pelo autor Yuri Diógenes.
Nenhuma imagem do livro será compartilhada aqui. Recomendo a aquisição do mesmo. Caso se interesse, me procure que posso lhe ajudar.
A quem está chegando agora, comecei no dia 12/02 essa série com a introdução onde faço algumas considerações e coloco os objetivos da prova. Além disso você pode acessar todos os volumes desta série nos links abaixo:
Meus apontamentos sobre a prova CLO-001 – Cloud Essentials da CompTIA – Introdução
Meus apontamentos sobre a prova CLO-001 – Cloud Essentials da CompTIA – Capitulo 1
Meus apontamentos sobre a prova CLO-001 – Cloud Essentials da CompTIA – Capitulo 2
Meus apontamentos sobre a prova CLO-001 – Cloud Essentials da CompTIA – Capitulo 3
Meus apontamentos sobre a prova CLO-001 – Cloud Essentials da CompTIA – Capitulo 4
Meus apontamentos sobre a prova CLO-001 – Cloud Essentials da CompTIA – Capitulo 5
Cap 06 – Riscos e consequências da computação em nuvem
Este capítulo trata dos riscos e consequências do uso da computação em nuvem. Reforça os problemas que podem ocorrer com a integração entre o ambiente empresarial e o ambiente de computação em nuvem. Discute a relação entre o conceito de flexibilidade estratégica e computação em nuvem.
Segurança, Legalidade, Conformidade e Privacidade na nuvem
Particularmente a integração da computação na nuvem com a infraestrutura existente na empresa, como no modelo de nuvem híbrida, deve considerar aspectos de segurança e acesso:
Falta de privacidade – Baixo grau de confidencialidade e deficiencia de isolamento no ambiente de nuvem – risco de acessos indevidos e/ou adultaração de dados e/ou aplicativos de consumidores.
Falhas de integridade – introdução fraudulenta de agentes de software com funções destinadas a provocar o mau funcionamento de serviço operador na nuvem
Suporte Inadequado – Falhas diversas no serviço de suporte, pessoal mal preparado, gargalos no atendimento, indisponibilidade do serviço, etc.
Baixo Desempenho – Desempenho insatisfatório dos serviços contratados, em decorrência de picos de demanda, balanceamento inadequado e/ou subdimensionamento dos recursos ou outros fatores assemelhados.
Ataques por saturação – Não detecção em tempo hábil de ataques que geram sobrecarga dos servidores ao tentar interpretar solicitações em sentido que desestabilizam o ambiente.
Dificuldades para escalar – Demora excessiva ou dificuldades para provisionar ou liberar recursos da nuvem.
Baixa interoperabilidade – Dificuldade significativa ou no limite, impossibilidade de intercambiar dados e/ou aplicativos entre provedores distintos.
Riscos de Negócio
Indisponibilidade – Interrupção temporária dos serviços em decorrência de problemas técnicos ou de outra ordem de parte do provedor.
Não continuidade – Interrupção definitiva da prestação de serviços do provedor.
Riscos estruturais
Não conformidade – Não atendimento a aspectos ditados pela legislação ou disciplinados por padrões de larga aceitação na indústria.
Licenciamento de software – Limitações impostas ao provedor por contratos de licenciamento de software inadequadamente pactuados com seus fornecedores.
Aprisionamento – Dificuldade significativa ou no limite, impossibilidade de trocar de provedor devido a particularidades do ambiente.
Má reputação – ampla repercussão de aspectos negativos envolvendo a prestação de serviços a um determinado consumidor ou a um grupo de consumidores.
Existem duas formas de licenciar software para ser utilizado na nuvem. A forma tradicional, onde o próprio provedor já licenciou o software para o uso e o BYOL (Bring Your Own License), que permite ao cliente utilizar suas próprias licenças quando da utilização na nuvem.
O BYOL trata de um contrato específico relacionado diretamente com o fornecedor.
No modelo "License Included" não é necessário adquirir licenças do fornecedor separadamente, pois o software já foi licenciado pelo provedor de nuvem. A definição de preço desta modalidade por hora inclui software, recursos de hardware subjacentes e as capacidades de gerenciamento do provedor de nuvem.
BYOL em resumo:
. Estender o valor da licença de aplicações de servidor implantando-as na nuvem ou em uma solução com parte interna (on-premisses) e outra na nuvem;
. Tirar proveito da infraestrutura de computação em nuvem e mudar a forma de adquirir serviços de infraestrutura de TI.
O livro também apresenta instruções dadas pela Microsoft para clientes que usam licenciamento por volume.
. Avalie as licenças
. Implante as licenças
. Verifique as licenças
Estas definições e instruções para cada um delas podem ser vistas no livro – pags 137, 138 e 139.
Na parte de verificação de licenças, vale ressaltar a importância da implementação de uma SGI (Sistema de Gerenciamento de identidades) – responsável pelo controle de acesso (autorização e autenticação) para cada tipo de usuário.
Este sistema reduz custo com auditoria, administração e controle de auditoria de forma centralizada.
De forma resumida, o SGI, além da autenticação, controla o acesso do usuárioi, impedindo a consulta e execução de serviços não autorizados. Todo acesso que este usuário precisa está associado a seu perfil.
Este processo também agiliza a construção de aplicações em nuvem, as tornando mais seguras e proporcionando aos desenvolvedores uma camada que garante privacidade e segurança, além de adequar nas políticas de segurança e controle de acesso estabelecido.
Na pag 139 o autor destaca tudo que é possível fazer numa gestão de SGI.
Além de tudo citado acima, a migração para a nuvem reforça a necessidade de sistemas de gerenciamento de identidade e acessos mais bem estruturados e integrados, em virtude do aumento dos riscos.
Na pag 140 o autor descreve os conceitos de Usuário, Identidade e Credencial, os quais recomendo você assimilar bem para a prova.
Os conceitos descritos pelo autor na pag 140 também é atrelado aos conceitos de Autenticação e Autorizado, também descritos na mesma pagina.
Com os conceitos de gerenciamento de identidade, se faz importante a implementação dos métodos de Federação e SSO (Single-Sign-On) com seus conceitos descritos na pag 141.
A conformidade (compliance) também é um aspect-chave da computação em nuvem com implicações de risco. Ela existe para facilitar o atendimento de padrões ditados por normas e regras.
Ao se analisar o gerenciamento de identidade e controle de acesso, o autor dá a dica de que se trata de uma tarefa que está inclusa na auditoria de conformidade.
Implicações para custos diretos e custos de alocação
O livro traz a algumas situações para pensar:
A maioria das áreas de TI não possuem um parâmetro de custos de seus serviços e nesse caso, analisar custos dos serviços on-premisses em relação ao custo dos mesmos serviços em nuvem não nos traz uma visão muito conclusiva.
Além disso, fatores como flexibilidade, agilidade e elasticidade devem contar na avaliação de uso do modelo de computação em nuvem a ser seguido. O autor relata que executivos reforçam que aplicativos que executam um alto numero de transações poderiam sofrer um impacto de performance caso fossem migrados para nuvem e dependem de uma cadeia de comunicação mais complexa envolvendo provedores de acesso, internet, redes internas, etc.
Desde o começo do livro os autores citam por diversas vezes o fato dos custos CAPEX mudarem para OPEX no modelo de computação em nuvem, sendo esta uma das principais questões a serem abordadas na apresentação do modelo aos executivos de sua empresa (diretores e gestores financeiros).
Entre os fatores que podem ser citados na questão de custo podemos colocar o fato de datacenters corporativos apresentarem uma série de custos capitais e operacionais.
No caso de serviços de nuvem, você tem a cobrança basicamente por uso ou por hora e são custos operacionais.
Estruturas on-premisses trazem custos com hardware, software, local (espaço físico, energia elétrica, água, manutenção, etc), tornando a tarefas (como sempre foi) complicada. Pode se adicionar tb o custo e tempo com suporte e gerencimamento de rede, banco de dados e storage.
Os provedores de nuvem oferecem uma gama de serviços cobrados conforme o uso, ou seja, você paga aquilo pela quantidade de recursos utilizados durante o tempo de uso.
O modelo de precificação é baseado nos aspectos abaixo:
Pay as you go – onde vc paga se usar, sem compromissos mínimos, nem contratos de longo prazo. Nesse caso não há a necessidade de um planejamento de uso de recursos de forma detalhada.
Pague pelo uso – Não há necessidade de pagar adiantado para o excesso de capacidade ou ser penalizado por problemas de falta de planejamento.
Pague menos usando mais – Para preço de transferência de armazenamento de dados, o preço é definido em camadas. Quanto mais usa, mais paga. Pague ainda menos quando for feita uma reserva, podendo investir em capacidade reservada para determinados produtos. – aqui temos um pequeno exemplo de economia em escala, citado em posts e capítulos anteriores.
Preço personalizado – para projetos de alto volume com necessidades específicas.
É importante o entedimento da precificação em computação em nuvem, sendo que existem 3 características fundamentais que determinam os preços de uso: computação, armazenamento e transferência de dados para for a da nuvem. Estes preços podem variar dependendo dos serviços que estão sendo utilizados e da forma como são adquiridos.
Flexibilidade Estratégica
Aqui o autor trata da capacidade da empresa de mudar sua estratégia de negócios sem perdas significativas, ou seja, mudar seus objetivos iniciais, caso se conclua estes não serem os mais adequados.
Caso uma estratégia de negócios já definida e implementada tenha que ser mudada, a computação em nuvem permite faze-lo sem problemas pois é possível alterar capacidade de processamento e armazenamento baseado na demanda, pois os ativos de TI em computação em nuvem são adquiridos na forma de serviços e são simplesmente devolvidos ou adquiridos.
Em resumo – a capacidade do sistema acompanha a demanda, promovendo a otimização de uso dos recursos.
E aqui encerramos esta série de posts com meus apontamentos. Espero, sinceramente, ter ajudado na compreensão dos temas envolvidos na prova e recomendo que assistam ao webcast que citei no começo deste volume. Leiam o livro, façam seus próprios apontamentos e façam a prova. Qualquer dúvida ou ajuda que precisarem, por favor, não hesitem em me procurar.
Meus apontamentos sobre a prova CLO-001–Cloud Essentials da CompTIA–Capitulo 5
3 de abril de 2018 uilson76	Deixe um comentário
Hoje vamos entrar nos apontamentos do quinto capítulo do livro “Cloud Essentials – Preparatório para a prova CLO-001”. Apontamentos estes que fiz durante meu período de estudos.
Cap 5 – Impactos e Mudanças da Computação em Nuvem no Gerenciamento de Serviços de TI
Capítulo baseado no gerenciamento de serviços de nuvem usando ITIL como parâmetro, mostrando como a computação em nuvem muda o modelo do ITIL. Neste ponto, o conhecimento prévio na biblioteca ajuda, mas, o conteúdo aqui é suficiente para fazer a prova, visto que ITIL não é o foco principal do exame e nem será abordado em sua totalidade. Reforço que a aquisição do livro vai complementar itens que aponto neste volume da série.
Visão geral do Modelo de Gerenciamento de Serviço baseado em ITIL
A ideia central do ITIL é trazer uma coleção de melhores práticas, recomendações e processos para gerenciamento de serviços de TI. O ITIL foi estabelecido nos anos 80 e é extramente usado até os dias de hj, tendo sua última versão revisada em 2011.
A biblioteca ITIL é formada foi 30 livros que documentam todo o ciclo de vida do serviço. Na última versão de 2011 foi consolidado em 26 processos distribuidos em 5 volumes.
Fornece ao provedor do serviço diretrizes na classificação e priorização dos investimentos que devem ser feitos para os serviços.
A estratégia de serviço possibilita a área de TI a ficar alinhada com o negócio principal da empresa através da delimitação dos processos:
. Gerenciamento de Estratégia
. Gerenciamento de Demanda
. Gerenciamento de Portfólio de Serviços
. Gerenciamento de Serviços
. Gerenciamento de Relacionamentos do Negócio
Implementar a estratégia de serviços em Cloud pode ser desafiador, principalmente no que tange ao Gerenciamento de Demanda, pois especificamente no modelo SaaS, os usuários da empresa podem gerar demandas diretamente com o provedor para obter mais serviços.
Se faz necessário que a área de TI reajuste o processo para deixar claro e documentado que qualquer provisionamento de serviços de nuvem para a empresa precisa primeiramente passar por ele.
O processo pode ser ajustado para algo automatizado através de um portal, pelo qual serviço possa ser requisitado, abstendo obviamente o cliente final do que ocorrem em background quando o provisionamento é realizado.
O clientes (usuários finais) deverão ser tratados como inquilinos da nuvem e passaraão a fazer uso dos recursos de forma correta.
Podemos concluir que a identidade utilizada pela empresa para fazer acesso aos serviços de nuvem oferecidos pelo provedor contratado não deve ser acessada diretamente pelo usuário final.
O principal objetivo do desenho de serviço é fornecer diretrizes no desenho de novos serviços e melhoria dos serviços existentes.
O desenho do serviço é também de suma importância para agregar os elementos que são relevantes para que o serviço possa ser entregue como prometido.
É no desenho do serviço que os 4 P´s são usados como fatores de consideração:
. Pessoas – quais papéis serão atribuídos e para quem
. Processos – quais processos serão mensurados
. Parceiros – quais são os fornecedores
. Produtos – quais são os produtos (tecnologia, serviços, ferramentas, etc) envolvidos
Processos estabelecidos para o desenho do serviço – pag 115 do livro
Processo de gerenciamento de capacidade ganha mais importância na adoção da computação em nuvem, pois vai avaliar a capacidade da área de TI em entregar a demanda corrente e futura para o negócio através de um custo efetivo.
Tem como objetivo fornecer diretrizes na tansição dos serviços desenhados para operacionalização – transição para produção.
Processos da transição de serviço – pag 116 do livro
Dica – A distribuição de software tende a sofrer uma alteração dentro dos processos de gerenciamento de mudança com a adoção da computação em nuvem.
Operação do Serviço
Fornece diretrizes para assegurar que o serviço seja entregue para os usuários da empresa da forma como foi acordada.
Processos da operação de serviço – pag 117 do livro
Se faz necessário redesenhar processos de cumprimento de serviço (Cumprimento de pedido – Request Fulfillment) tendo a experiência do usuário em mente após adoção da computação em nuvem.
Aplicando ITIL para computação em nuvem
Não existe um ITIL para nuvem. O que o exame Cloud Essentials porpõe é que alguns conceitos do mesmo podem ser aplicados a computação em nuvem para melhor gerenciamento de recursos, tendo em vista a computação em nuvem ser considerada um modelo computacional que permite ao área de TI entregar serviçosd e forma mais dinâmica.
Planejamento de Estratégia do Serviço para nuvem
Um dos processos da estragégia de serviços que pode ser aplicada a computação em nuvem é o Gerenciamento de Demandas.
Possibilita entender e antecipar as demandas do cliente, trabalhando como um gerenciamento de capacidade de forma a assegurar que o provedor de serviços tem capacidade de atender o que o consumidor está pedindo.
O resultado destas demandas deve ser analisado e a conclusão pode ser que novos serviços sejam necessários, ou seja, crescer o portfólio. Com isso fica fácil de entender que o gerenciamento de portfólio de serviços é outro processo que se aplica à computação em nuvem.
O Gerenciamento de portfólio aplicado à nuvem vai monitorar as dependências dos serviços e receber possíveis eventos acerca destes serviços. Isso é uma nova função do subcomponente chamado Modelo de Serviço, que por sua vez é definido no ITIL, como um componente responsável por ter uma descrição dos componentes necessários para o serviço que será entregue.
Como exemplo podemos citar que unidades de armazenamento estão prestes a ficar cheias, este serviço não deverá ser oferecido ao cliente, caso contrário o mesmo não será entregue. O armazenamento destas informações ficam em uma CMDB (Configuration Management Database).
O aspecto financeiro tb entra na computação em nuvem – o ROI precisa ser informado em um relatório com o máximo de assertividade, tendo também em vista a implementação do processo de Charge Back – cobrança de volta – Ex: Um departamento solicita mais processamento em um servidor que executa um sistema de sua responsabilidade. Com a liberação destes recursos o departamento receberá um cobrança posterior do depto de TI discriminando exatamente o que eles utilizaram e o quanto vai custar… (o que foi requisitado, o que foi usado e o quanto vão pagar).
Gerenciamento de relacionamento de negócio – Vai obter entradas desde pesquisa de satisfação de clientes até requisitos de serviços para então repassar ao departamento de TI, que por sua vez vai aplicar nos serviços da nuvem – processo importante para melhoria continua dos serviços.
Operação e Suporte na Computação em Nuvem
De acordo com o ITIL os dois principais propósitos do serviço de operação são o controle de incidentes e a comunicação com o cliente. É importante saber como estes incidentes serão manuseados quando o serviço é adaptado à computação em nuvem. E isso pode variar de acordo com o modelo da nuvem.
Quando fala-se em "Camada Intermediária" (*) – usar somente o serviço de suporte interno para solicitações – afim de evitar que se acione dois serviços de suporte – da visão do usuário final.
A idéia central destes serviços é evitar que clientes internos tenhanm contato direto com o provedor de serviços da nuvem e que todo gerenciamento de incidentes seja de responsabilidade interna.
Fica também como responsabilidade do serviço interno de operação e suporte:
. Documentar os serviços e saber como lidar com a abertura de incidente de cada serviço.
. Fazer a categorização de cada serviço, ou seja, à medida que o incidente for aberto é necessário entender o tipo de aplicação em uso e aonde tal aplicação está armazenada (localmente ou na nuvem).
. Entender as responsabilidades de cada serviço do ponto de vista de quem fornece.
Uma forma de manter o acompanhamento próximo dos serviços e obter dados que venham a melhorar o serviço oferecido é através de análise de desempenho com utilização de métricas.
A forma de medição de um serviço baseado em computação em nuvem varia de acordo com o fornecedor – Microsoft, AWS ou SalesForce oferecem formas variadas de monitoramento.
No caso da nuvem, a disponibilidade é o maior fator de monitoramento de serviço.
Uma forma de averiguar este valor poderia ser através da verificação do MTBF (Mean Time Between Failures) de cada componente e com isso entender o quão disponível cada serviço / componente vai ficar.
Em geral, para ambientes de alta disponibilidade, a regra é que clientes demandem de uma disponibilidade de 99.999%, também conhecida como "5 9s". Esta regra era pouco oferecia por provedores em nuvem até 2009, visto sua incapacidade no momento.
A evolução do monitoramento de disponibilidade hoje em dia já não se preocupa tanto com "o serviço estar disponivel ou não". Na realidade é preciso que o monitoramento obtenha muito mais informações:
. Qual inquilino está sendo afetado
. Qual aplicação que está em uso pelo inquilino
. Quais componentes envolvidos que podem estar impactando o desempenho
. Quem mais está sendo afetado com tal problema
Monitoramento de acordo com o modelo de nuvem
O monitoramento dos serviços também vão variar de acordo com o modelo de nuvem (IaaS, PaaS, SaaS) em uso, até mesmo porque vão existir diferentes métricas para cada tipo de modelo.
Outra variação é do ponto de vista do consumo do serviço ou do oferecimento de serviço.
Monitoramento contínuo do serviço para nuvem
Prevê o trabalho contínuo no intuíto de aperfeiçoar os serviços, aprendendo com as falhas antigas e corrigindo estas falhas. Os processos existentes são:
. Avaliação do serviço
. Avaliação do processo
. Definição das iniciativas de melhoria
. Monitoramento contínuo
E aqui finalizo os apontamentos do capítulo 5. Na próxima semana vou postar o último volume da série. Mais uma vez espero estar lhe ajudando nesta empreitada para a certificação Cloud Essentials.
Meus apontamentos sobre a prova CLO-001–Cloud Essentials da CompTIA–Capitulo 4
23 de março de 2018 uilson76	Deixe um comentário
Hoje vamos entrar nos apontamentos do quarto capítulo do livro “Cloud Essentials – Preparatório para a prova CLO-001”. Apontamentos estes que fiz durante meu período de estudos.
A quem está chegando agora, comecei no dia 12/02 essa série com a introdução onde faço algumas considerações e coloco os objetivos da prova. Além disso você pode acessar todos os volumes desta nos links abaixo:
Meus apontamentos sobre a prova CLO001 – Cloud Essentials da CompTIA – Capitulo 3
Cap 4 – Adoção da Computação na Nuvem
Como medir o sucesso da adoção da computação em nuvem?
Os objetivos da empresa em primeiro lugar
Os objetivos organizacionais da empresa, o negócio e como ele será beneficiado com a adoção da computação em nuvem é que devem vir em primeiro plano.
Os autores infatizam o importância de mapear estes objetivos com os tipos de modelos oferecidos pela computação em nuvem:
Tenha em mente: este mapeamento inicial serve para guiar a empresa no modelo de nuvem a ser adotado e não na forma com que a nuvem será adotada (Public, Private, Hybrid).
Dica dos autores: Uma das recomendações para que uma empresa possa implementar uma estratégia de IaaS com sucesso é a padronização do conjunto de máquinas virtuais que podem ser provisionadas.
Reduções de custo com SaaS:
Atualização de software – patches de segurança, atualização de versão, etc
Distribuição de software – instalação de software no cliente, remoção, etc
Servidores no Datacenter
Componentes de rede – responsabilidade do provedor
On-premisses – responsabilidade do cliente
Nuvem – responsabilidade do provedor – seja no modelo SaaS, PaaS ou IaaS
Cabe ao cliente manter os roteadores que dão acesso a internet.
As empresas que migram para a nuvem tb precisam desenvolver habilidades em diversas áreas de gerenciamento, o que inclui também o provisionamento de serviços. Nem todas usam este modelo onde é requisitado um serviço em um portal e a automação faz o provisionamento dinâmico sem requerer nenhum tipo de intervenção da área de TI.
Como TI pode ajudar:
Ajudar a entender e explicar como funciona o ciclo de vida da aplicação
Ajudar a entender os parâmetros necessários de desempenho
Auxiliar no entendimento de requisitos de qualidade do provedor
Dica para a prova – A preferência é que o provedor de nuvem use um framework baseado em Open Java para padrões SaaS ao invés de usar API´s proprietárias.
Como selecionar o provedor de acesso à nuvem?
Fatores a serem avaliados:
Reputação da empresa
Ranking deste provedor comparado a outros e um estudo detalhado dos serviços oferecidos
Tempo de recuperação contra desastre – como a empresa lida com isso, como os dados são afetados
Rever SLA que a empresa oferece para os clientes
Avaliar se o provedor de nuvem possui tecnologias compatíveis com as premissas do cliente. Fator importante para modelos de PaaS.
Se a empresa não oferece um modelo transparente de migração para o cliente, se faz necessário um investimento grande de aprendizado da equipe de desenvolvimento, o que pode retardar a migração e encarecer o custo geral.
Outras considerações quanto a escolha do provedor incluem:
Responsabilidades do provedor – Revisar o contrato modelo do provedor para entender as responsabilidades que o provedor deve entregar.
Segurança de dados – Entender a política de segurança do provedor, como os dados serão armazenados e as garantias do provedor nesse âmbito.
Recuperação contra desastre – Como o provedor vai manusear seus dados em caso de desastre no site principal onde os mesmos estão armazenados.
Modelos de adoção suportados pelo provedor – Se suporta nuvem pública apenas ou se trabalha também com híbrida e privada
Modelo de controle de identidade – Modelo de autenticação usado pelo provedor. Se é possível integrar este modelo com o existente na empresa ou se será necessário fazer ajustes e quanto isso custará. O modelo mais usado por grandes empresas inclui integração de identidade com uso de federação. É importante validar a existência dessa tecnologia e como ela é realizada.
Auditoria de dados – como o provedor lida com esse tema. Caso necessário fazer uma auditoria mais detalhada, será possível o provedor fornecer os dados? Caso o processo não seja tão transparente, verifique o que é preciso para que isso ocorra.
Manutenção de serviços – Todo provedor tem paradas programadas para manutenção. Verificar como isso pode afetar sua empresa, deixando claro esse ponto junto ao provedor
Visão futura – Ao passo que é importante saber o que o provedor oferece hoje, também é importante saber o que ele oferecerá futuramente. Qual o roadmap do provedor de serviços e o que vem por aí? Qual a estratégia do provedor para novos serviços? Algo não oferecido hoje estará disponível no futuro? Quando? Entender o que o provedor planeja para o negócio é importante, pois essa é uma parceria que tende a se pagar e trazer lucro a longo prazo, portanto, não foque somente no presente.
Flexibilidade – Muitas vezes o contrato não satisfaz as necessidades do negócio do cliente de imediato. Alguns provedores têm portifolio de serviços preestabelecidos, alguns estão abertos para negociar customizações nos termos contratuais para melhor endereçar as necessidades do negócio do cliente.
Desempenho – Este é um ponto crítico. A capacidade computacional do provedor vai satisfazer a demanda do negócio? Muitas empresas usam como estratégia um período de testes para verificar se a demanda é atingida após a migração para a nuvem. Entretanto o provedor precisar estar ciente e concordar com este período de testes.
Segurança Física – Apesar dos provedores venderem este tema como sendo os melhores. É fundamental procurar a documentação de como essa segurança é feita, quais a certificações obtidas pelo datacenter e quem são as pessoas que irão manusear os dados nas premissas do provedor.
Outro ponto importante é avaliar qua o "plano de saída" oferecido pelo provedor caso sua empresa decida por se desligar por completo dele.
Adoção para núvem e os processos para empresa
A adoção da computação em nuvem muda a forma como a empresa trabalha e acima de tudo como a empresa lida com o lucro. A mudança de CAPEX para OPEX traz o valor da nuvem e quebra o antigo paradigma de que se vc não tem acesso físico à infraestrutura então você não é o dono. (E aqui mais uma vez os conceitos de CAPEX e OPEX são citados… guardem bem!).
O fato é que você continua dono do dado independente de onde ele esteja.
Uma empresa com processos bem delimitados terá menos dificuldade de ajustar-se ao modelo de computação em nuvem tendo em vista o nível de maturidade não só dos processos, mas também dos usuários. Tentar implantar um modelo de computação em nuvem ao mesmo passo que se estabelece uma série de processos que nunca exisitiram na empresa pode ser um caminho mais árduo e dificultoso para a migração.
Durante o processo é importante estar em bom alinhamento com o jurídico e depto Legal da empresa para revisar possíveis cláusulas contratuais e entender a responsabilidade de cada parte.
Também é importante avaliar e validar processos de entrada e saída de dados, principalmente para empresas que trabalham com dados pessoais de clientes – nesse caso o processo precisa ser revisto e reavaliado.
Possíveis brechas e vazamentos de sistemas podem ocorrer, portanto, envolva o depto de Segurança da Informação no processo.
Todas as variáveis acima precisam ser incluídas no SLA que a empresa vai assinar com o provedor. Importante também se faz incluir:
Termos de proteção com exposição de dados e proteções legais/regulatórias com relação à localização física dos dados no provedor.
Este levantamento pode ser realizado durante revisão dos processos de gerenciamento de risco da empresa e como eles serão afetados com a adoção da computação em nuvem.
Tabela com tipos de risco:
Todos os elementos acima precisam estar cobertos no contrato. Além desses riscos, outros devem ser contemplados e categorizados:
Verificar se o provedor permite teste de penetração para os recursos do cliente que estão sendo executados na núvem. Alguns provedors exigem o preenchimento de um formulário especial para isso.
Verificar se o provedor permite auditoria externa para os recursos do cliente que estão sendo executados na nuvem.
O que mais saber sobre o SLA:
O maior impacto no que tange ao gerenciamento de nível de serviço na computação em nuvem é a capacidade de elasticidade, que por sua vez é um principio inerente da computação em nuvem.
Abaixo alguns exemplos de itens que devem ser considerados e estar presentes em um SLA de um contrato de computação em nuvem:
Descrição detalhada dos serviços que estão sendo cobrados
Custo descriminado dos serviços
Descrição das responsabilidades de cada parte (contratante e contratado)
Disponibilidade dos serviços contratados
Termos legais no que tange à interrupção dos serviços, incluindo valores de multas e possível ressarcimento
Detalhamento do plano de remediação (ou recuperação contra desastres) e o tempo médio que leva para remediar
Detalhamento de onde os dados ficam armazenados (localização geográfica) primariamente e também onde fica a cópia de backup
Descrição do gerenciamento de mudanças e se o mesmo vai impactar na disponibilidade ou desempenho dos serviços1
Descrição do processo de escalação de casos
Como o provedor vai lidar em casos de vazamento de dados ou caso o provedor seja atacado
Portabilidade de dados entre plataformas
Descrição detalhada do processo de saída do provedor
Dos itens mostrados acima, o último é muitas vezes esquecido e pode gerar um problema. É de suma importância que o porcesso de saída seja definido logo no começo, envolvendo cópia dos dados paras premissas do cliente e limpeza de dados no provedor.
O que muda nas premissas da empresa?
É necessário avaliar o cenário atual da empresa do ponto de vista de infraestrutura de rede, servidores, estações, licenciamento de software, treinamento de funcionários, sistema de segurança e gerenciamento de mudanças.
No livro você vai encontrar nas pag´s 94 e 95 – um estudo de caso sobre uma infraestrutura que planeja migrar para a nuvem e o autor enumera os pontos de falha do ambiente que podem comprometer a continuidade dos serviços pós migração:
Uma única conexão externa
Verificar se o firewall estará preparado para suportar a carga adiconal de entrada e saída
Conexão do firewall com com o ativo interno da rede
Revisar switches que conectam a estações e outros servidores ao roteador central
Dica: Compre o livro para ver este desenho e aprofundar mais a idéia no que estamos falando aqui.
Cuidado: Alta latência de rede e alto volume de dados armazenados podem ser fatores que causem degradação do tempo de resposta. É importante sempre ter disponível uma análise atualizada do desempenho de rede e do volume de tráfego para saber se alum tipo de ajuste precisa ser feito antes da migração para a nuvem.
Validação ou piloto – de começar após a empresa identificar qual o modelo de nuvem que vai adotar, fazendo tudo o mais próximo possível da realidade, sumarizado nas seguintes fases:
Os seguimentos da empresa que mais terão vantagens com a nuvem, quais essas vantagens obtidas pelo negócio e já criar um planejamento de adoção na fase piloto
Identificar quais aplicações serão validadas na nuvem e os usuários que irão testar no processo piloto.
Recursos de TI que serão utilizados
Recursos financeiros necessários
Dica – na fase piloto escolher aplicações mais fáceis de migrar mas que ao mesmo tempo sejam importantes para o negócio. Não é recomendado piloto com aplicações de alto impacto ou legados.
Migração de aplicações para nuvem
Neste ponto do livro, o autor mostra os passos para planejar a migração de aplicações para nuvem. Fique atento aos detalhes abaixo:
Tipos de aplicações existentes:
Fluxo básico:
Tipos de aplicação:
Baseadas em Desktop – executadas diretamente na estação do cliente usando primariamente recursos locais. Tende a serem mais rápidas por não concorrerem com outros recursos de rede e tem seus binários instalados localmente. Podem fazer proveito de API´s (Application Programming Interface).
Baseadas em Web – exeuctadas no lado do cliente independente do sistema operacional – bastando ter um navegador. Usam plataformas e aplicações distribuidas gerando melhor experiência para o usuário em termos de escalabilidade e disponibilidade.
Baseadas na Núvem – Uma aplicação baseada na núvem tira proveitos dos recursos de elasticidade e alocação de recursos em nuvem. Permite um crescimento sem comprometimento do serviço.
Fundamentos de aplicações para núvem
Um dos pontos de validação para migração de uma aplicação na nuvem é a capacidade de elasticidade. A empresa precisa considerar todo o ecossistema de nuvem para o desenvolvimento de aplicações. Em outras palavras, é esperado que exista uma melhoria no processo de desenvolvimento de aplicações agilizando a experiência de uma forma geral.
Sabendo que elasticidade é um fator importante para investimento no desenvolvimento de uma aplicação para nuvem, também deve-se levar em consideração os seguintes padrões:
Capacidade de crescimento – Não se limita apenas desenhar uma aplicação pronta para o crescimento no momento do aumento da demanda mas também ter a flexibilidade de começar pequena e à medida que for crescendo ela poder obter dinamicamente mais recursos da plataforma devido à elasticiade.
Capacidade de demanda em momentos de pico (previsíveis ou não previsíveis) – As vezes uma aplicação é desenhada para uma demanda X, porém em um dia específico ela vai chegar a uma demanda de X + 100, o que vai comprometer o desempenho. Uma aplicação baseada em nuvem não sofre este problema devido à capacidade de elasticidade e demanda dinâmica de recursos. Mesmo sendo projetada para a demanda X, ela é flexível para demanda X + 100 da plaforma e a plataforma deverá prontamente responder. Este se trata de um exemplo de demanda de pico não previsível. Podemos também usar como exemplo a demanda de pico previsível: todo final de mês é previsto o aumento da demanda na aplicação que controla a folha de pagamento dos usuários.
Capacidade de processamento periódico – algumas organizações vão ter demandas, ou seja, ter aplicações que são utilizadas durante um período de tempo e depois são "engavetadas" até a próxima oportunidade de uso. Projetos periódicos que só ocorrem uma vez por ano, ou até mesmo uma eleição que ocorre de 4 em 4 anos. O poder computacional requerido por essas aplicações durante o período em que serão usadas pode ser imenso. Entretanto, ao fim do seu uso, o que fazer com toda infra estrutura usada? Com uma aplicação baseada em nuvem, esse poderio computacional pode ser facilmente realocado para ouros projetos.
Desenvolvimento de aplicações para a nuvem
Um dos fundamentos essenciais ao se desenhar uma aplicação para nuvem é a capacidade de desenhar algo que não seja baseado no estado ou simplesmente stateful apps. Aplicações stateful são aquelas que têm suas regras embutidas na própria aplicação e mantêm o estado de conexão com o servidor de destino. Em termos de computação em nuvem, o problema deste formato é que, como o processamento é distribuído, não há nenhuma garantia de que o mesmo servidor de destino vai estar disponível para responder a chamada. O ideal é usar aplicações sem manutenção do estado (stateless apps). Neste formato as aplicações são mais eficientes e não requerem a manutenção do estado durante chamadas ao servidor de destino.
Do ponto de vista da aplicação, a empresa precisa entender que, se ela decidir seguir o modelo PaaS, terá que se adequar à plataforma de desenvovimento do provdor. As API´s (Application Programming Interface) do PaaS são proprietárias da plataforma do provedor e não necessáriamente vai portar toda sua plataforma de desenvolvimento sem requerer que o código seja reescrito. Por esse motivo existe uma tendência natural a se usar IaaS quando comparado com PaaS, a não ser que a sua empresa veja benefícios específicos na adoção do PaaS.
Caso o modelo IaaS seja o adotado para desenvolvimento de aplicações da sua empresa, certifique-se que os elementos abaixo sejam avaliados durante a escolha:
Preço e forma de pagamento – verificar as opções de pagamento para o modelo que será usado.
SLA – Verificar os detalhes de SLA para disponibilidade dos serviços que irão suportar a aplicação.
Certificação – Certifique-se e avalie as certificações do provedor, entre elas PCI DSS, SSAE e SAS – definições na pág 102 do livro.
Custo da transferência de dados – Alguns provedores cobram por upload e outros por download. É importante ficar claro como este processo é realizado, pois vai impactar o desenho da aplicação.
Suporte – Verificar o nível de suporte oferecido para as aplicações que irão residir na nuvem.
Monitoramento – Verifique qual o nível de monitoramento oferecido…se é parte do pacote ou se é necessário contratar um serviço à parte.
Dica – As tecnologias HTML, JSON e XML são comumente utilizadas em serviços WEB (Web Services) que por sua vez são inerentes ao modelo de computação em nuvem.
Enumerando desafios e riscos
A figura na pag 104 mostra os principais desafios enfrentados no processo de migração de aplicações para a nuvem – veja no livro.
Neste caso é preciso enumerar os possíveis eventos que possam ocorrer e irão afetar a migração de sua aplicação para nuvem. A tabela abaixo ajuda no processo de identificação, classificação, priorização, mitigação e monitoramento dos riscos:
Importante: Grandes empresas que movem seus dados para a nuvem não devem se esquecer que são alvos de ataques cibernéticos. Tidas como “High-Profiles”, as instituições financeiras são as que mais precisam ter cuidado neste ponto, sendo o ataque DDOS (Distributed Denial of Service) o mais crescente.
Dica do autor: É importante entender a política de saída oferecida pelo provedor. Uma opção de saída é reorganizar os dados de volta para a empresa… técnica também conhecida como “Re-host in house”.
E ficamos por aqui neste 5o. post referente ao capitulo 4.
Espero que lhe ajude em seus estudos.
Meus apontamentos sobre a prova CLO-001–Cloud Essentials da CompTIA–Capitulo 3
13 de março de 2018 uilson76	Deixe um comentário
Hoje vamos entrar nos apontamentos do terceiro capítulo do livro “Cloud Essentials – Preparatório para a prova CLO-001”. Apontamentos estes que fiz durante meu período de estudos.
Cap 3 – Perspectiva Técnica dos Tipos de Nuvem
O Foco do capítulo é estabelecer a diferença técnica entre os principais tipos de nuvem e explicar o funcionamento básico e as técnicas para realizar a implementação da nuvem.
Aqui também veremos os principais riscos da computação em nuvem e descreve o impacto da computação em nuvem nas aplicações e processos de desenvolvimento. Relembrando que a parte de riscos é muito falada no fim do livro e diversos cenários com esses riscos caem na prova.
Diferenças entre Nuvem Privada e Publica do ponto de vista técnico:
Privada: utilizada por uma única organização. Pode ser administrada por ela própria ou por terceiros e estar (ou não) em instalações próprias. O serviços afetados são de uso da própria organização. Construída para funcionar utilizando os recursos dos datacenters empresariais. Traz uma facilidade maior no que tange a segurança e arquitetura de dados, exatamente por ser privada.
Pública: Suporta arquitetura Multitenancy (multi-inquilino), na qual todos os usuários e aplicativos compartilham uma única infraestrutura e a base de códigos é mantida centralmente. As implantações individuais de aplicativos em arquitetura Multi tenant ocupam partições virtuais, em vez de pilhas físicas separadas de hardware e software. Mesmo sendo interessante, essa arquitetura pode trazer problemas para a segurança dos dados.
Multi tenant – Compartilhamento da mesma infraestrutura física e versão de aplicativos
Single tenant – Infraestrutura própria e única para o dono da nuvem privada
Guardem bem: O armazenamento de dados pessoais do cliente em um provedor de serviços é um dos riscos da computação em núvem – você verá os autores explanando sobre este tema de forma detalhada no decorrer do ultimo capitulo do livro.
De maneira geral, a nuvem privada é utilizada como alternativa à nuvem pública quando há a necessidade de níveis mais rigorosos de segurança e privacidade, ou de garantia de disponibilidade da aplicação. – se lembrarem do que compartilhei aqui nos primeiros volumes da série, alguns dados muito confidenciais podem fazer com que nem tudo da empresa seja migrado para a nuvem, tornando a opção da nuvem privada como solução ou até mesmo ficando em ambiente on-premisses.
O crescimento da adoção de nuvens privadas está sendo influenciado pelo aumento da oferta de soluções com este foco, pela rápida expansão da vitualização e pela pressão por implantações rápidas e baratas de TI.
Técnicas e métodos de distribuição de Computação em nuvem:
Rede: mesmas técnicas do que é utilizado em redes convencionais. O que muda na nuvem é que a camada de rede passa a ser uma abstração (web services) permitindo utilizar os componentes de rede de forma mais simples e ágil.
Ao se implementar aplicações em nuvem, a solução de rede utilizada deve permitir manter o controle completo sobre a configuração do endereçamento IP. Isso significa que deve ser possível continuar a usar o seus esquemas de endereçamento atuais e se conectar a rede IP já existentes.
Um outro exemplo de rede na nuvem é o uso de um dispositivo de hardware à sua escolha para estender sua rede empresarial para a núvem pública com segurança usando uma VPN – integrando a infra existente com os recursos de rede em nuvem.
Automação: (Self-Service) – é a capacidade de prover funcionalidades computacionais de maneira automática, sem que haja necessidade do usuário interagir com o provedor de serviço. Provedores têm direcionado esforços no sentido de fornecer elasticidade nos recursos de seus clientes – um dos pontos lá do começo da série em que disse que os autores reforçam bastante.
Ex: Auto Scaling da Amazon AWS – util para aplicativos que apresentam variabilidade de uso por hora, dia ou semana, escalando a capacidade do servidor virtual para cima ou para baixo de acordo com as condições que o contratante define.
Federação: A federação de identidade permite que clientes habilitados usem suas identidades existentes (usuários, por exemplo) para ter acesso seguro a API´s de determinada núvem e outros recursos usando controles provenientes do seu sistema de identidade e acesso, sem a necessidade de criar um usuário específico para cada identidade.
SSO (single sign-on) – A idéia da federação é que os funcionários façam login uma única vez em seu diretório corporativo e depois usem recursos de nuvem sem ter que fazer login novamente.
O SSO possibilita o reuso das políticas existentes de acesso a aplicativo, para controlar o acesso acesso a aplicativo SaaS. A integração do serviço de diretório com a aplicação SaaS significa que uma determinada ação não precisará da confirmação de usuário e senha.
Segundo a Microsoft, os aplicativos SaaS podem fornecer autenticação SSO pelo uso de um serviço de federação na rede do cliente que faz interface com o serviço de diretório do usuário da própria empresa do cliente. Deverá existir uma relação de confiança entre o servidor de federação do cliente e do provedor do aplicativo SaaS.
Para ter acesso ao aplicativo, o servidor de federação da empresa autentica o usuário localmente e negocia com o servidor de federação SaaS para fornecer ao usuário um token de segurança aceito pelo sistema de autenticação do provedor SaaS, que o utiliza para dar acesso ao usuário.
Padronização: Existem muitas normas para a computação em nuvem. O problema é que há uma profusão delas e muitas pessoas não sabem o que eles significam. Apensar da diversidade normas e definições, caminha-se para uma consolidação por meio de várias entidades que se destacam:
IEEE Standards Association – Institute of Electrical and Electronics Engineers
DMTF – Distributed Management Task Force
A padronização dos formatos é importante para facilitar o movimento de dados entre provedores de serviço de nuvem.
Desafios técnicos e Riscos da Computação em Nuvem:
1.Falta de interoperabilidade e aprisionamento: Quando os modelos adotados pelos fornecedores de computação em nuvem são integrados verticalmente e limitam a escolha da plataforma.
2. Incompatibilidade de aplicações: Quando aplicativos construídos para computação em nuvem são incompatíveis com os aplicativos legados.
3. Dificuldade em obedecer as normas regulatórias: Quando a regulação limita o uso da computação em nuvem para alguns ambientes. Nuvens privadas podem ser uma saída para diversas organizações.
4. Segurança inadequada: Quando em muitas situações a segurança é um gargalo para adoção da computação em nuvem.
Para os decisores envolvidos com projetos de nuvem os desafios técnicos devem ser superados naturalmente, e o foco é a conexão da TI ao negócio.
Segundo estudo da Capgemini, as decisões relativas a nuvem estão cada vez mais sendo tomados pelos gestores do negócio.
A decisão de migrar para nuvem foi tomada por gestores do negócio em 45% dos casos e por gestores de TI em 46% – Estudo da Business Cloud – The State of Play Shifts Rapidly.
O mesmo estudo aponta que em um futuro próximo as decisões sobre nuvem serão centralizadas nos gestores de negócios.
O processo de adoção da computação em nuvem apresenta benefícios e riscos e o mesmo deve ter um processo de gerenciamento de riscos associados. Existem diversas características importantes no modelo de computação em núvem e a combinação destas características fornecidas pelo modelo adotado pelos provedores pode fazer o risco variar.
Alguns cuidados que o cliente deve ter para mitigar o risco referente à aquisição de serviços de um provedor de computação em núvem sugerido pelo Gartner:
. Saber como é feito o acesso dos usuários
. Saber como o provedor obedece ás normas de regulação
. Saber onde se localizam os dados
. Saber como os dados são segregados
. Saber como os dados são recuperados
. Saber como é feito o suporte
. Ententer a viabilidade do provedor no longo prazo
Um dos riscos a ser avaliado na entrega dos serviços de TI para a computação em núvem é o risco da perda do controle dos dados internos e ele de fato existe.
Aplicativos que eventualmente continuem operando localmente, podem utilizar serviços de infraestrutura providos pela nuvem (ex: Armazenamento de dados), e funcionar utilizando serviços providos interna e externamente. Normalmente os riscos aumentam até nesses casos.
No modelo de computação em núvem (diferente do modelo de computação tradicional), teremos a alteração do modelo amparado em equipamentos para outro baseado em serviços. Usa-se nesses casos o Service Leve Agreement (SLA) como interface natural entre provedores e organizações clientes.
Dica: Riscos legais podem ocorrer caso um provedor limite suas responsabilidades na SLA com o cliente.
Os riscos que a computação em núvem pública traz devem ser minimizados nas áreas de armazenamento, desempenho, integração de dados e segurança:
Armazemanto: Os provedores oferecem suporte à autenticação de usuários para controlar o acesso aos dados. Mecanismos de acesso como ACL (Access Control List) deverão ser usados para conceder permissões seletivamente a usuários e grupos.
Uploads/Downloads deverão ser feitos por SSL usando o protocolo HTTPS ou pelos próprios métodos de autenticação que o cliente possa ter com suas bibliotecas de criptografia própria.
Dados armazenados em repouso podem ser criptografados via SSE (Server Side Encryption), fornecido por alguns provedores.
Obtenção de log´s mostrando as solicitações enviadas ao armazenamento em nuvem pode ser util para monitorar aplicativos ou para fins de auditoria.
Implementação de dispositivos locais para transferência automática de dados para uma plataforma de armazenamento em nuvem altamente disponível e durável – soluções de recuperação de desastres com o mínimo de esforço e custo com ferramentas híbridas de amazenamento.
Desempenho: O acesso de baixa latência a dados em grande escala é um desafio. As unidades de estado sólido oferecem tempos de resposta muito mais rápidos e previsíveis e já são opções oferecidas por alguns provedores de computação em nuvem.
Um cache na memória pode ajudar a melhorar o desempenho do aplicativo. O uso de um cache gerenciado na memória significa que você não precisa se preocupar com o gerenciamento, o monitoramento e a operação do cache em memória e pode se concentrar em seu aplicativo.
Para um desempenho superior considere um serviço de balanceamento de carga com escalabilidade e gerenciamento automáticos. Este serviço também deve verificar a saúde (disponibilidade) do seu aplicativo para que falhas não afetem os usuários.
Integração de dados: Como dados empresariais não estão preparados para análise, o uso de ferramentas que carregam e transformam esses dados é algo de extrema importância. No caso de provedores em nuvem esta realidade não é diferente.
O serviço de banco de dados gerenciado (oferecido por diversos provedores em nuvem), permite configurar a alta disponibilidade mais facilmente, evitando tarefas com este fim e lhe dando oportunidade de se dedicar aos recursos do próprio aplicativo e evitar altos custos.
Os provedores em nuvem oferecem recursos baseados em réplicas para melhorar os serviços de dados. As réplicas de leitura oferecem o recurso de escalabilidade horizontal além das restrições de capacidade de uma única instância de banco de dados para cargas de trabalho de bancos de dados com uso intensivo de leituras. Também é certo afirmar que o serviço de replicas em um ambiente gerenciado poupa custo e tempo nas tarefas de configuração.
Segurança: A computação em nuvem deve tratar os aspectos básicos de segurança:
Não repúdio
O aspecto chave da computação em nuvem é o gerenciamento de identidade e controle de acesso. Como se trata de ambiente disitribuído, é necessário implantar serviços de gerenciamento de segurança que funcionem de forma distribuída.
Ex: Seviços de identidade – delegando direitos administrativos, a fim de que gerentes individuais possam administrar contas dentro do seu próprio domínio.
Também usar o SSO (Single Sign On), conforme já mencionado para autenticar usuários em aplicações executadas na nuvem.
Arquitetura de aplicação e processo de desenvolvimento:
As atuais arquiteturas de software não atendem ao novo cenário dos negócios ávidos por arquiteturas flexíveis. Neste caso se faz necessário um novo modelo de arquitetura de software chamado Multitenancy ou multi-inquilino.
Multitenancy – permite que múltiplos inquilinos (empresas clientes) compartilhem os mesmos recursos físicos como um aplicativo ERP, mas permanecendo logicamente isolados.
Reforçando: Multitenancy trata da arquitetura de aplicações onde uma única instância do software roda em um servidor e vários inquilinos (tenants) a acessam.
Na arquitetura Multitenancy os inquilinos utilizam a mesma instância do servidor e não máquinas virtuais distintas. A arquitetura Multitenancy implica em ter poder para forçar aplicação de políticas, segmentação, isolamento, governança, níveis de serviço de forma diferente por perfís de usuários.
A arquitetura SaaS depende totalmente da arquitetura multitenancy – ter uma aplicação atendendo a múltiplos clientes.
OBS: Inquilinos (tenants) não são usuários individuais.
Segundo Cezar Taurion, os modelos multi-inquilo (Multitenancy) podem ser classificamos como:
Inquilino Isolado: Modelo em que cada inquilino tem seu próprio Stack de Tecnologia, não havendo o compartilhamento de recursos. Mesmo sentindo a experiência de multi-inquilino (por acessar uma aplicação oferecida a múltiplos clientes a partir do mesmo datacenter), não se trata de um modelo multi-inquilino. É similar ao modelo tradicional de hostpedagem (hosting) onde cada usuários tem seu próprio conjunto de recursos computacionais e sua própria instância da aplicação. Este modelo, por ser uma oferta SaaS, carece de agilidade e elasticidade, pois para adicionar um novo inquilino requer o provisionamento de sua própria instância de hardware e software. Também não permite economia em escala.
Multi-inquilino via hardware compartilhado (virtualização): Cada inquillino tem seu próprio stack de tecnologia, mas o hardware é alocado dinamicamente a partir de um pool de recursos, via mecanismo de virtualização. Permite elasticidade na camada de hardware. Este modelo apresenta uma limitação: pois a unidade de alocação e liberação de recursos é a máquina virtual onde a aplicação vai operar.
Multi-inquilino via container: Neste modelo várias inquilinos são executados na mesma instância de um container de aplicação (servidor de aplicação), mas cada inquilino está associado a uma instância separada do software de banco de dados. O ambiente de execução é compartilhado entre vários inquilinos, mas a plataforma de dados é a a mesma.
Multi-inquilino de stack de software compartilhado: Similar ao modelo multi-inquilino via container – compartilhando todo o stack de software. Além do container da aplicação, também uma única instância do banco de dados é compartilhada por todos os inquilinos.
“Os negócios atualmente demandam agilidade e a TI precisa prover sistemas que permitam que a empresa se reconfigure de forma rápida em função das mudanças do ambiente, o que se convenciona chamar de flexibilidade estratégica”. – Por Jinesh Varia – consultor da Amazon AWS.
A elasticidade deve ser um dos requisitos do projeto arquitetônico ou mesmo uma propriedade do sistema. – e aqui mais uma vez vemos a questão da elasticidade sendo abordada.
Algumas perguntas se fazem necessárias quando pensamos a arquitetura dos aplicativos:
Quais os componentes ou que camadas em minha arquitetura de aplicativo podem se tornar elásticas?
O que será necessário para tornar esse componente elástico?
Qual será o impacto da implementação da elasticidade na arquitetura geral do sistema?
Será que a infraestrutura está preparada para otimizar a elasticidade do aplicativo?
Você vai notar que a nuvem pode não ter a especificação exata do recurso que você tem no seu ambiente local. Deve-se compreender que a nuvem fornece recursos abstratos, e eles se tornam poderosos quando você os combina com o modelo de provisionamento on demand.
Um aspecto a ser considerado é a forma como os datacenters estão sendo construídos. Existe uma relação direta entre a arquitetura do datacenter e a arquitetura do aplicativo. A infraestrutura orientada a serviço deve suportar a arquitetura orientada a serviço do aplicativo (Services Oriented Architecture – SOA).
A arquitetura SOA utiliza o paradigma request/reply para estabelecer a comunicaçãoentre os sistemas clientes e os sistemas que implementam os serviços.
O provisionamento do datacenter sempre foi feito no limite, provisionando recursos no máximo da capacidade, para fugir das dificuldades em realizar o planejamento de capacidade (capacity planning). Este processo gera perda de eficiência e um custo muito elevado para a operação como um todo.
A modularidade foi introduzida recentemente tanto para os aspectos da construção como para os componentes da solução para melhorar estes aspectos e permitir uma infraestrutura orientada a serviços.
O modelo tradicional de datacenters provisionam servidores web com capacidade elevada para atender as demandas de pico, o que quase sempre resulta em capacidade ociosa.
Servidores de cache otimizam o uso dos servidores de banco de dados e fazem com que boa parte das requisições seja atendida em cache.
A arquitetura do datacenter deve suportar o modelo de três camadas utilizado para construção de uma aplicação:
Camada de apresentação – presentation tier – pt
Regras de negócio – business tier – bt
Camada de dados – data tier – dt
E aqui encerro esse capítulo 3 dos meus apontamentos do livro. Logo posto o capitulo 4.
Espero que estaj série o ajude em seus estudos
2 de março de 2018 uilson76	Deixe um comentário
Hoje vamos entrar nos apontamentos do segundo capítulo do livro “Cloud Essentials – Preparatório para a prova CLO-001”. Apontamentos estes que fiz durante meu período de estudos.
Cap 2 – Computação em nuvem e o Valor do negócio
Neste capítulo os autores buscam criar um entendimento de como usar a computação em nuvem para fazer e trazer valor ao negócio principal da corporação. O capítulo é mais longo e você precisa ler com muita atenção e acima disso, ter fixado bem os conceitos do capítulo 1, pois é nele que você fixa todos os conceitos, conforme falamos.
Como identificar se sua empresa precisa migrar para nuvem:
O uso da tecnologia da informação por parte das empresas é focado e justificado por três pilares de sustentação que são – Custo, Eficiência e Agilidade – guardem bem esses pilares.
Custo – a computação em núvem faz a ecomonia de escala – custo da unidade x volume de produção. – para entender o conceito de economia em escala – https://pt.wikipedia.org/wiki/Economia_de_escala
Qto maior for a produção, menor o custo por unidade.
Conforme falamos no volume 1 desta série, a computação em núvem altera o custo capital para custo variável (aquilo que falamos de CAPEX e OPEX). Um provedor pode cobrar cobrar por assinatura ou por taxas de uso (que traz custo inicial) e você deve avaliar qual delas é a melhor para sua empresa.
A computação em núvem faz uso de recursos compartilhados, onde a distribuição de custos ocorre entre todos os clientes que fazem uso dos recursos computacionais entregues a um nível tal como se fosse um servidor dedicado.
Outro ponto a ser considerado e que é citado pelos autores é que ir para núvem não significa alocar recursos em provedores externos. Um datacenter pode ser adequado a oferecer o serviço de computação em núvem, desde que siga as 5 características fundamentais de cloud computing para melhorar o negócio da empresa – vide capítulo 1 do livro.
Entretanto, na escolha de um provedor externo, a computação em núvem mostra sua vantagem logo no início de sua adoção. Ao iniciar um novo projeto, não será necessário provisão de custos para novos equipamentos de hardware. Com um contrato com algum provedor, basta solicitar a alocação de um novo recurso, pagando apenas pelo que está sendo usado. O mesmo pode ser pensado no caso de núvem privada, pois será apenas necessário que se aloque um novo recurso que será utilizado no projeto.
A aquisição destes novos recursos não se fazem necessários porque estão previstos no "Pool de Recursos" disponíveis, conforme citamos no resumo do capítulo 1 e também mais detalhado no livro.
O pool de recursos é composto por – Processamento, armazenamento e rede – guardem bem estas características.
Benefícios do modelo – Núvem Pública:
Na núvem pública, a empresa alterna os custos CAPEX (Capital) para OPEX (Operacional) – detalhes no capitulo 1
Com uso mais otimizado da infra estrutura de TI, a empresa tende a reduzir cada vez mais o CAPEX.
A redução total de custos com Hardware e Sistema Operacional pode ser encontrada no modelo SaaS, onde o provedor de serviços é totalmente responsável por estes componentes.
Eficiência - forma de agir de forma rápida e acurada, sem perder o momento ou o fio da meada de seu negócio, ou seja, buscar escalabilidade de forma eficaz.
As formas de se atingir esta escalabilidade são:
Elasticidade – como falei no volume 1 desta série, algo que será muito falado no livro!
Com estas características é possível não apenas expandir os recursos em uso por demanda, mas também diminuir o uso dos mesmos quando não forem mais necessários.
Por estarem distribuídos em Clusters (físicos ou virtuais) a escalabilidade pode ocorrer de duas formas:
Scaling up (escalar para cima) – adição de recursos (memória, disco, processador, etc) em um único nó do cluster – basicamente falando, um "upgrade" de recursos – Exemplo: Alocar mais processador e memória.
Scaling out (escalar para fora) – Adição de mais nós em um cluster.
Dica do Uilson: Guarde bem os termos citados acima não só para a prova, mas também para seu dia a dia.
As ações acima citadas (escalabilidade) permitem:
– Adição e remoção de servidores e unidades de armazenamento
– Adição e remoção de usuários para acesso aos serviços
– Segurança na computação em núvem:
– Deve ser considerada tanto para adoção de núvens públicas como privadas.
Empresas de computação em núvem investem milhões em segurança física – guardas ao redor do datacenter, identificação biométrica, etc. Dessa forma o contratante tira proveito deste fator sem gastar a mais com isso.
Monitoramento 24/7 – Em ambientes on-premisses, um dos custos mais altos é a manutenção de pessoal especializado em suporte em esquema 24/7 para atender a demanda não só que tange a segurança, mas também quanto ao suporte dos serviços. A computação em núvem faz com que todo este investimento seja do provedor.
A área de TI da empresa contratante deve manter acompanhamento do monitoramento do serviço para validar se está atendendo as necessidades – uma vez que este é feito pelo provedor.
Ao se aderir a computação em núvem a empresa deverá fazer uma análise dos custos que economizaria ao migrar seus dados para nuvem e o risco. Cada negócio precisa averiguar a pertinência do risco para o negócio ao transferir tarefas para um provedor.
Em tese, a idéia da computação em núvem não é gerar uma demissão em massa na área de TI e sim proporcionar que estes profissionais sejam alocados em tarefas mais estratégicas que permitam a TI agir como parceiro estratégico de negócios e não somento uma área de suporte.
Agilidade - Adaptar-se a alterações de mercado de forma rápida e reagir a essas alterações com fins de tirar proveito das oportunidades.
Fique atento pois será cobrado na prova as diferenças entre Computação em núvem e outsourcing:
A entrada da empresa na computação em nuvem faz com que o foco principal seja o negócio primário da organização e como reagir rapidamente as mudanças de mercado.
O mesmo conceito pode ser usado em Outsourcing, entretanto a forma de se operacionalizar os processos muda de um para o outro.
Outsourcing – contratos mais longos com duração mínima pré estabelecida e multas diante de rescisão unilateral. Em termos de escalabilidade é feito um prognóstico do que será necessáriio e, caso haja necessidade de se aumentar ou diminuir os serviços haverá uma burocracia e custos adicionais.
Computação em nuvem – Contratos mais curtos. Paga-se só pelo que se usa e é possível trocar de provedor a qualquer momento. A escalabilidade é dinâmica. É possível ajustar para mais ou para menos a qualquer momento e sem burocracia.
Cenários que também podem tirar proveito da computação em núvem:
Redução do tempo de provisionamento de serviços
Agilidade para testar soluções
OBS: Para definição completa dos itens acima procure na página 45 e começo da 46 do livro.
No que tange a validação de ambientes em teste, a computação em núvem agiliza o processo para a empresa que usa deste recurso para testar as capacidades da núvem. – considere (e muito) este ponto para questões de simulado e a própria prova.
É necessário também expor uma reflexão acerca dos riscos e possíveis impactos no negócio. Se faz necessário avaliar como seu negócio em particular vai tirar proveito deste modelo e quais os riscos em potencial.
Analisar os seguintes pontos:
Custo Real (TCO – Total Cost Ownwership) – Verificar se o modelo atual tem o TCO mais alto que o modelo de computação em núvem.
Confiabilidade – Caso a empresa esteja adotando o modelo de núvem pública é necessário avaliar a reputação do provedor e também os aspectos de segurança da núvem pública.
Legalidade – Nem toda empresa vai poder mover para a núvem pública, principalmente por fatores legais, regulamentações do tipo de negócio da empresa ou do país que a empresa opera, que não permite que alguns dados sejam localizados fora do País.
Confiabilidade e legalidade podem bloquear o ingresso da empresa na nuvem, entretanto, a análise do TCO é algo mais complexo. Durante esta análise, leve em consideração custos diretos e indiretos respondendo as perguntas abaixo:
Quanto será necessário de processamento?
Quanto será necesário de armazenamento?
Custo do licenciamento de software ao usar computação em nuvem pública?
Qual SLA que a empresa pretende ter como requisito e quanto isso vai afetar o custo do contrato?
Treinar os desenvolvedores na criação de aplicações para núvem ou contratar pessoal?
Será necessário um gasto em certificações e regulamentações que a empresa precisa ter do ponto de vista operacional?
Considerar também custos indiretos: Tais como customização de aplicações que irão para a nuvem, custo de transferência de dados e custo de validação dos softwares para verificar se os mesmos estão funcionando corretamente após terem sido movidos.
Após estes levantamentos, verificar se o ROI (Return on Investment) é favorável para a migração do seu ambiente para nuvem. Este cálculo é feito conforme abaixo:
ROI = (Benefícios – Custo de Investimento) / (Custo do investimento)8
No caso da migração de um sistema de banco de dados, avaliar o valor a ser gasto para a migração on-premisses e o valor a ser gasto para implementação desta mesma tecnologia em núvem. Levar em consideração, se o ROI compensa.
Dica do Uilson para a prova – guarde bem: O ROI é um dos passos cruciais para verificar se a migração é favorável para a empresa.
A tabela de decisão abaixo te orienta a saber qual o modelo ideal:
Os cenários acima são apenas alguns modelos para entendimento. Outros poderão surgir.
Os mesmos podem mudar de acordo com a adoção. Uma empresa que opte pela núvem privada pode decidir que existem alguns serviços de nuvem que são importantes para ela e com isso mudar para um ambiente híbrido. Não é porque a empresa começou com um modelo que não poderá mudar. Essa é uma tendência.
O ponto chave da questão de se escolher o modelo certo a ser adotado é evitar transtornos na adoção e com isso achar que a migração para núvem foi algo errado.
A tendência é que as empresas comecem adotando o modelo híbrido. Nesse modelo não é necessário uma nuvem privada no datacenter. A empresa pode manter o modelo tradicional e ter apenas uma ligação com a nuvem privada de um provedor.
Dessa forma, é correto afirmar que algumas empresas terão benefícios imediatos e outras a longo prazo.
Empresas com restrições legais ou regulatórias que exigem que os dados fiquem localizados no datacenter da empresa.
Empresas em que o custo de investimento para adequar-se ao modelo da nuvem é muito alto para a quantidade de benefícios.
Empresas localizadas em regiões onde a internet é lenta e com isso não é possível consumir de forma adequada os recursos da nuvem
Órgãos militares com alto teor de confidencialidade e certificação de operação podem não ter espaço para adoção da computação em nuvem.
E chegamos ao fim do resumo do segundo capítulo. Mais uma vez é importante associar a leitura deste e do primeiro volume como o livro para que o entendimento seja bem mais completo e para que você possa fazer os simulados oferecidos ao fim de cada capítulo.
Espero que possa lhe ser util.
22 de fevereiro de 2018 uilson76	Deixe um comentário
Hoje vamos entrar nos apontamentos do primeiro capítulo do livro “Cloud Essentials – Preparatório para a prova CLO-001”. Apontamentos estes que fiz durante meu período de estudos.
Nenhuma imagem do livro será compartilhada aqui. Recomendo a aquisição do mesmo.
A quem está chegando agora, comecei no dia 12/02 essa série com a introdução onde faço algumas considerações e coloco os objetivos da prova. Além disso todos os volumes desta série ficam listados abaixo:
Cap 1 – Características dos serviços de núvem de uma perspectiva do negócio
Este capítulo a meu ver é uma base importantíssima para domínio de todos os temos que virão no livro e também para fixar de forma eficaz todos os conceitos usados na computação em nuvem. Aqui você tem todas as definições que precisa saber para entendimento de como funciona cada tipo de serviço em nuvem.
Definições sobre computação em núvem e termos associados:
No livro, os autores trazem informações muito interessantes sobre a origem do termo "computação em núvem". O mesmo foi empregado em 2006 pelo CEO da Google Eric Schmidit.
Diversas empresas têm sua própria definição sobre o que é computação em nuvem e todas são totalmente aceitáveis, mas, a CompTIA toma como parâmetro para a prova a definição de computação em núvem do NIST (National Institute of Standards and Technology):
"Computação em núvem é um modelo que permite acesso à rede de forma onipresente. Conveniente e sob demanda a um conjunto compartilhado de recursos de computação configuráveis que podem ser rapidamente alocados e liberados com mínimo esforço de gerenciamento ou interação com o prestador de serviço."
Tomando como base a definição do NIST, temos as seguintes características que um provedor deve oferecer (é importante ter todas elas bem gravadas):
Autosserviço sob demanda – trata-se da habilidade que o provedor deve ter em prover serviços de maneira automática, sem interação do usuário .
Amplo acesso a rede – ou seja, disponibilidade total de recursos que serão acessados via internet de forma padronizada – é preciso que o uso seja aberto a todos os dispositivos (smartphones, tables, computadores, etc).
Pool de recursos – os recursos computacionais que devem ser acessados simultaneamente por vários usuários de forma dinâmica de acordo com a necessidade de cada um
Rápida elasticidade – os recursos devem ser forneceidos de forma rápida e elástica, ou seja, devem aumentar e diminuir sem demora, dando ao usuário a percepção de existência ilimitada de recursos na hora que for necessário.
Serviços mensuráveis – controle e monitoramento automático dos recursos utilizados por cada serviço oferecido.
Relembrando – as características acima são a base para qqer provedor poder funcionar…lembre-se de ter elas bem gravadas em sua mente. O entendimento do livro e dos serviços de cloud ficam mais simples.
Uma definição da Amazon reforça as características acima. Segundo a empresa, o termo "computação em núvem" significa o fornecimento de recursos de TI sob demanda por meio da internet, com pagamento conforme o uso.
Em diversas partes do livro a questão da elasticidade é abordada, pois permite transferir o risco da baixa utilização (subutilização) e da alta utilização (saturação) para uma situação de ajuste fino entre a carga de trabalho (workload) da TI e os recursos disponíveis.
A elasticidade relaciona-se com a demanda atual e a demanda futura – guarde bem isto!
Mudar a forma de financiar a TI. Grandes investimentos de capital se tornam despesas operacionais.
Realocar recursos de TI para atividades de negócio principal – menos trabalho operacional.
Procurar utilizar aplicativos que são mais simples e baratos de implementar, utilizar e ter suporte
Aumentar a escalabilidade e flexibilidade, melhorando as condições de responder às condições de mercado
Importante fixar os atores da computação em núvem sugeridos pelo NIST (não só para a prova, mas também para o dia a dia de quem trabalha em provedor ou consome serviços):
Consumidor de Nuvem (Cloud Consumer) – adquire e utiliza serviços de nuvem
Provedor de Nuvem (Cloud Provider) – responsável por disponibilizar o serviço de nuvem
Broker de Nuvem (Cloud Broker) – gerencia o uso, desempenho e entrega dos serviços de nuvem e negocia a relação entre o provedor e o consumidor de nuvem
Auditor de Nuvem (Cloud Auditor) – conduz a avaliação do serviços de nuvem com foco em privacidade, desempenho e segurança
Operadora de Nuvem (Cloud Carrier) – fornece conectividade e transporta os serviços entre o provedor e o consumidor de nuvem
Para definição completa dos termos acima (Atores da Computação em nuvem e as 5 definições de um cloud provider), leia o capítulo 1 do livro. Caso não tenha, fale comigo que posso lhe ajudar a adquirir.
Um dos pontos a fixar é o emprego da virtualização na computação em nuvem e as diferenças entre ambos. A otimização dos recursos computacionais na computação em núvem é atingida principalmente com o emprego da tecnologia de virtualização. Aqui é importante ter em mente a definição abaixo:
“Em suma, virtualização pode ser considerada a ocultação dos recursos de hardware atravésde uma camada abstrata de software”.
Diferenças entre computação em núvem e virtualização:
Virtualização – particionamento de um servidor físico em vários servidores lógicos. Pode ser vista tb como camada de abstração que é colocada entre o hardware e o software e que protege o acesso direto do software aos recursos físicos do hardware.
Computação em núvem – vai além da virtualização, pois possibilita um maior nível de abstração para o ambiente computacional. O nível de abstração propiciado pela computação em núvem permite que uma aplicação possa ser construída e colocada em operação em menos tempo do que uma aplicação que utiliza unicamente a virtualização. Além disso o nível de utilização dos recursos é otimizado com a escala da computação em núvem.
Entenda que computação em nuvem não depende de virtualização, entretanto a mesma é importante para que se tenha agilidade na prestação de serviços tais como implementação de aplicações.
Ainda sobre virtualilzação e falando da arquitetura X86 (sistemas rodam diretamente sobre o hardware – SO´s do tipo Bare-Metal – assumindo controle completo do hardware), existem 4 níveis de privilégio de acesso para operações de sistemas e acesso das aplicações ao hardware, conhecidos como Rings (anéis – 0, 1, 2 e 3).
Em infras de servidores físicos temos aplicações de usuários rodando no Ring 3 e sistema operacional no Ring 0. Em infras de servidores virtualizados o SO de uma VM passa a ser o guest, rodando no Ring 1 e o hypervisor passa a ter prioridade sobre o hardware, ficando no Ring 0.
Essas priorizações de hardware podem ser priorizadas de várias formas pelo software de virtualização (XEN, VMWare, Hyper-V).
Fixe em sua mente também as diferenças entre escalabilidade e elasticidade – a primeira trata da expansão de recursos de acordo com a demanda computacional e a segunda é mais ampla por representar o poder de dimensionar recursos computacionais, aumentando e diminuindo facilmente com o mínimo de atrito (impacto) – é o que propicia a maioria dos benefícios da nuvem.
Tipos de oraganizações que se beneficiam com a computação em núvem:
Empresas pequenas e médias se beneficiam da computação em núvem quando podem ter um sistema de informação mais flexível e pago conforme a demanda. O empresário muitas vezes não tem capital para financiar recursos de TI num modelo baseado em hardware e software (on-premisses).
Em diversas partes do livro, os autores ressaltam o benefício em questão de custos gerado pela computação em nuvem… o fato de recursos de capital (CAPEX) serem substitídos por despesas operacionais (OPEX).
CAPEX – Capital Expenditure – montante de dinheiro gasto na aquisição de bens de capital de uma determinada empresa. Vale também para custos com introdução de melhorias. (equipamentos, instalações – de forma a manter a produção de um produto ou serviço ou manter em funcionamento um negócio ou um determinado sistema).
OPEX – Operational Expenditure – custo associado à manutenção dos equipamentos e aos gastos de cosumíveis e outras despesas operacionais, necessários a produção e a manutenção em funcionamento do negócio ou sistema.
Para entender bem sobre CAPEX e OPEX leia essa post do site TIEspecialistas – https://www.tiespecialistas.com.br/2013/06/diferencas-entre-capex-e-opex/
Diferentes tipos de serviços em núvem:
Outra definição que você precisa ter fixa (para sempre) em sua mente são os tipos serviços de nuvem… é fundamental para decidir por qual delas vai seguir sua implementação:
IaaS – Infrastructure as a Service – onde o usuário controle suas máquinas virtuais sendo o provedor responsável por toda infra estrutura física
PaaS – Platform as a Service – Para desenvolvedores de aplicativos que serão disponibilizados e executados na nuvem
SaaS – Software as a Service – Aplicativos usados por uma grande quantidade de usuários que passam a ser hospedados na nuvem como alternativa ao processamento local.
As definições completas dos termos acima você encontra no próprio livro – recomendo que você leia toda a definição de cada um desses termos.
Padronização de acesso e comunicação entre aplicações:
Neste ponto, é importante que você entenda as diferencas entre as bases de acesso e comunicação entre apps – Web Browsers e Web Services
Web Browsers – suportam as ofertas de SaaS e parte da oferta de PaaS. – acessam paginas web usando como padrão protocolos de internet – http e https.
Web Services – entram na composição da oferta de IaaS e parte da oferta de PaaS. Integra sistemas e faz a comunicação entre plataformas e aplicações diferentes. Como cada app tem sua própria linguagem, os web services usam arquivos XML como meio de estabelecer a comunicação entre as pontas.
Formas de se implementar núvem – de acordo com o NIST:
Aqui os autores tratam os tipos de nuvem existentes:
Núvem privada – Infraestrutura de computação em núvem operada e quase sempre gerenciada pela própria empresa cliente. O serviços são oferecidos para serem utilizados pela própria organização, não estando publicamente disponivel para uso geral. De acordo com o Gartner Group, uma nuvem privada é definida por privacidade, não por propriedade, localização ou responsabilidade de gestão.
Núvem pública – é disponibilizada publicamente através do modelo pague-por-uso. São oferecidas por organizações públicas ou por grandes grupos industriais que possuem grande capacidade de processamento e armazenamento.
Núvem híbrida – composição de duas ou mais núvens (privada, pública ou comunitária) que continuam a ser entidades únicas, porém conectadas através de tecnologias proprietárias ou padronizadas que propiciam a portabilidade de dados e aplicações. A núvem híbrida impõe uma coordenação adicional a ser realizada para uso das núvens privadas e públicas com impactos na governança.
Núvem comunitária – infraestrutura compartilhada por diversas organizações e suporta uma comunidade que possui interesses comuns. A núvem comunitária pode ser administrada pelas organizações que fazem parte da comunidade ou por terceiros e pode existir tanto fora quanto dentro das organizações.
Ofertas de núvem pública:
Dentre as várias opções:
Microsoft Azure – começou como Windows Azure em 2010 no modelo PaaS – hoje opera modelos IaaS e PaaS. Azure Virtual Machines são o web services mais populares da plataforma.
Amazon – começou com o Amazon Web Services em 2006 com foco em IaaS – lançou o modelo de armazenamento S3 (Amazon Simple Storage Service), mas, vem migrando para ofertas baseadas em PaaS. É um conjunto de web services que constituem uma plataforma de computação em núvem. Os web services mais populares são o Amazon EC2 (Processamento) Amazon S3 (Armazenamento).
A núvem híbrida trata da extensão do datacenter empresarial para atingir e se integrar a núvem pública, oferecendo o melhor do dois mundos de forma que seja possível usufruir de recursos externos quando forem justificáveis ao negócio.
A núvem privada pode ser desenvolvida utilizando seu próprio datacenter. O ganho com essa mudança seria o de ter mais agilidade e gerenciar recursos de maneira mais efetiva.
Exemplos de fornecedores de núvem privada:
VMWare com vCloud Suite – toda ela com recursos próprios e todas as funcionalidades de computação em núvem.
NASA com sua própria núvem chamda Nebula que fornece capacidades de IaaS, PaaS e SaaS baseada em um projeto próprio (Open-Source) chamado Eucalyptus que duplica API´s fornecidas pela Amazon Web Services EC2 (Processamento).
O Gartner apresenta 5 realidades para núvem privada:
Núvem privada não é virtualização
Núvem privada não significa só redução de custos
Núvem privada não é, necessariamente, instalada localmente
Núvem privada não é apenas IaaS
Núvem privada não será sempre privada
E por aqui encerro o primeiro capítulo. É de suma importância que vc leia o livro, pois além do exposto aqui, você encontra diversos exemplos de infra estruturas de nuvem em provedores específicos (Azure, AWS, etc) citados pelos autores e uma gama de exemplos de serviços como o EC3 da AWS por exemplo que vão ajudar na fixação de cada conceito apresentado aqui… reitero que, caso queira adquirir o livro, me procure que posso lhe ajudar.
Espero que tenham gostado desse resumo da série de 6 capitulos que irei compartilhar com os meus apontamentos e considerações sobre o livro e a prova. Todo esse conteúdo é útil não só para a prova, mas também para seu dia a dia… e lhe garanto, me ajudou muito.
Até o capítulo 2!
Compre o livro pela SF Editorial
Cybrary – Treinamentos completos gratuítos
PCI – Payment Card Industry
Pesquisa de posts Selecionar o mês junho 2018 (1) maio 2018 (1) abril 2018 (1) março 2018 (3) fevereiro 2018 (2) novembro 2017 (1) agosto 2017 (2) julho 2017 (1) junho 2017 (2) maio 2017 (1) abril 2017 (3) março 2017 (2) dezembro 2016 (2) novembro 2016 (2) julho 2016 (1) junho 2016 (1) abril 2016 (1) fevereiro 2016 (1) janeiro 2016 (1) dezembro 2015 (1) novembro 2015 (2) setembro 2015 (2) julho 2015 (1) junho 2015 (2) maio 2015 (1) abril 2015 (1) março 2015 (2) fevereiro 2015 (1) janeiro 2015 (1) dezembro 2014 (1) novembro 2014 (1) outubro 2014 (1) setembro 2014 (2) agosto 2014 (2) julho 2014 (3) maio 2014 (1) abril 2014 (2) março 2014 (2) fevereiro 2014 (3) janeiro 2014 (1) dezembro 2013 (1) novembro 2013 (3) outubro 2013 (3) setembro 2013 (2) agosto 2013 (4) julho 2013 (2) junho 2013 (4) maio 2013 (1) abril 2013 (3) março 2013 (1) fevereiro 2013 (2) janeiro 2013 (3) dezembro 2012 (3) novembro 2012 (1) outubro 2012 (4) setembro 2012 (2) agosto 2012 (1) julho 2012 (3) junho 2012 (4) maio 2012 (5) abril 2012 (3) março 2012 (3) fevereiro 2012 (3) janeiro 2012 (4) dezembro 2011 (2) novembro 2011 (3) outubro 2011 (4) setembro 2011 (2) agosto 2011 (3) julho 2011 (2) junho 2011 (4) maio 2011 (4) abril 2011 (2) março 2011 (5) fevereiro 2011 (4) janeiro 2011 (2) dezembro 2010 (6) novembro 2010 (7) outubro 2010 (7) setembro 2010 (7) agosto 2010 (5) julho 2010 (10) junho 2010 (9) maio 2010 (4) abril 2010 (5) março 2010 (3) fevereiro 2010 (4) janeiro 2010 (5) dezembro 2009 (3) novembro 2009 (2) outubro 2009 (5) setembro 2009 (4) agosto 2009 (3) julho 2009 (3)
Follow InfoSec and Cloud Thoughts on WordPress.com

References: Artigo 16

Artigo 17

Artigo 21

Artigo 8

Artigo 20

Artigo 33

Artigo 83
 artigo 33
 artigo 32
 artigo 17