Alura > Cursos de DevOps > Cursos de Segurança > Conteúdos de Segurança > Primeiras aulas do curso Segurança em Cloud: governança e liderança estratégica

Segurança em Cloud: governança e liderança estratégica

Estratégia de governança em nuvem - Apresentação

Introduzindo o curso de gestão estratégica e liderança em segurança na nuvem

Olá a todos. Bem-vindos ao nosso curso de Gestão Estratégica e Liderança em Segurança na Nuvem.

Imaginem um cenário em que migramos 70% de nossos recursos informáticos para a nuvem. Há uma grande celebração, pois conseguimos reduzir os custos de CAPEX para o próximo ano. Não precisaremos comprar novos equipamentos. No entanto, com o passar do tempo, começam a surgir perguntas. Às vezes, os custos começam a aumentar, e as pessoas querem saber quem é responsável pela informação e pelas aplicações que estão na nuvem. Precisamos responder questionários para auditorias e LGPD, e surgem várias dúvidas sobre quem é responsável por cada aspecto.

Explorando o papel da inteligência artificial e liderança em segurança

Atualmente, diversas inteligências artificiais nos auxiliam em nossos projetos, com pessoas implementando várias ferramentas que utilizam IA, enquanto atacantes também usam inteligência artificial para tentar invadir nossos ambientes. Como líderes de segurança, começamos a nos perguntar o que podemos fazer para nos antecipar, nos preparar e, principalmente, orientar nossas equipes.

Estamos aqui para tratar de ferramentas, apresentar conceitos e marcos de trabalho que podemos usar no nosso dia a dia para tentar nos proteger, reduzindo nossos riscos e aumentando os ganhos da empresa de forma consciente, com estratégias que sejam sustentáveis e acertadas.

Apresentando o instrutor Danilo Regis

Meu nome é Danilo Regis. Para quem não está me vendo, sou um homem negro, com barba, uso óculos e tenho cabelo ralo. Estou vestindo uma camiseta preta e estou nos estúdios da Alura. Tenho especialização em segurança da informação, direito digital e compliance. Também sou especialista em perícia forense informática e possuo um MBA em gestão de empresas pela Fundação Getúlio Vargas. Tenho cerca de 15 anos de experiência na área de TI, em arquitetura, tanto em pequenas empresas quanto em empresas de médio e grande porte.

A ideia aqui é compartilhar um pouco do nosso dia a dia em ambientes modernos de infraestrutura multi-cloud para abordar os seguintes temas. Vamos começar discutindo algumas técnicas estratégicas de governança na nuvem. Aprenderemos a alinhar a segurança com os objetivos do negócio, removendo o estigma de que a segurança é um custo, um gasto que não se recupera. Entenderemos que existem formas de lidar com isso de maneira diferente.

Discutindo gestão de riscos e cadeia de suprimentos

Falaremos sobre a gestão de riscos e a cadeia de suprimentos (supply chain). É muito comum ouvirmos em nosso campo sobre ataques à cadeia de suprimentos, os ataques supply chain. Discutiremos isso, falaremos sobre due diligence, e como entendemos o que devemos exigir de nossos fornecedores de acordo com seu tamanho. Vamos exigir o mesmo de uma grande empresa de nuvem, como Azure, AWS, Oracle, da mesma forma que faremos com uma startup que nos presta serviços. Abordaremos esse tema.

Por fim, aprenderemos uma estratégia interessante de como podemos mover nossos OPEX para um ponto mais estratégico do estado de resultados, alinhando-o com o custo do produto e não necessariamente como um gasto.

Incorporando segurança na cultura organizacional

Aprenderemos a incorporar nosso custo de segurança no custo do produto. Discutiremos a importância da cultura de segurança. Por que isso é importante? Sem os fóruns adequados, os critérios de aceitação e de risco apropriados, a compreensão do que seria um "champion" de segurança, a compreensão do que seria uma carta de riscos, um comitê, uma análise de ameaças, um fórum de design authority, teremos muita dificuldade para incorporar a segurança, especialmente em ambientes grandes e complexos.

Também falaremos sobre o BISO, nosso par do CISO, que terá um enfoque mais centrado no negócio. Cada um, dentro de uma estrutura complexa, tem suas próprias preocupações. Certamente, a preocupação de um CISO, dos analistas de segurança, é garantir que nossos ativos e produtos estejam extremamente seguros. O BISO entra como contraponto com a ideia de que o negócio precisa ponderar e, muitas vezes, até aceitar determinados riscos, por exemplo, para reduzir certa fricção e diminuir o time to market. Mas é necessário que alguém possa dialogar entre as partes, que alguém possa deixar claro, em uma planilha, em uma tabela, em um infográfico, o que estamos, de fato, trocando. Porque sem argumentos claros para o negócio, muitas vezes não saberão como lidar com esse risco. O aspecto técnico, às vezes, é um problema para quem não está acostumado à área de segurança.

Abordando inteligência artificial e frameworks na segurança na nuvem

Também trataremos da Inteligência Artificial na liderança de Segurança na Nuvem. Aprenderemos sobre frameworks. Entenderemos como o NIST está abordando a Inteligência Artificial, por exemplo. Grandes referências como Gartner estão tratando desse tema. Quais são as referências que podemos usar para fundamentar nosso trabalho, inclusive para elaborar um plano de trabalho que nos permita manejar todo esse conjunto de ferramentas que está surgindo no contexto da IA.

Explorando o conceito de Zero Trust e suas implicações

Falaremos também sobre Zero Trust, não a partir de aspectos muito técnicos, pois esse seria o foco dos analistas. Mas, o que a gestão precisa saber sobre Zero Trust? Vamos fazer uma estratégia Big Bang? Tentaremos resolver todos os problemas da empresa? Quais problemas atacaremos primeiro? Quais problemas deixaremos para depois? E como fundamentaremos nossas decisões para que chegue o investimento?

Discutindo privacidade, compliance e direito digital na nuvem

Por último, falaremos um pouco sobre Privacidade, Compliance e Direito Digital no ambiente cloud. Porque no modelo de responsabilidade compartilhada, é necessário entender que parte de nossas decisões pode ser impactada por determinados produtos que contratamos. Existe uma diferença legal quando contratamos uma infraestrutura, quando contratamos um produto, quando contratamos um serviço, uma solução, um SaaS. E aí falaremos de cada um desses aspectos.

Concluindo com o público-alvo do curso

A ideia aqui é dialogar principalmente com profissionais de nível sênior que estão migrando para a área de gestão, ou profissionais da área de gestão que estão entrando na área de segurança, para entender quais são os critérios e para onde devemos olhar durante nosso trabalho. Esperamos que aproveitem todo o nosso conteúdo, e nos vemos a seguir em nossa primeira aula.

Estratégia de governança em nuvem - Segurança como estratégia de negócio

Introduzindo a aula de estratégia e governança em nuvem

Olá, pessoal. Vamos começar com a nossa primeira aula de Estratégia e Governança em Nuvem. Trabalharemos em quatro blocos: o conceito da segurança alinhada com o negócio, frameworks e modelos de governança em cloud (nuvem), indicadores e dashboards (painéis) para executivos, e, por fim, teremos um entendimento prático da elaboração de um roadmap (plano de ação) de maturidade.

Explorando a segurança como estratégia de negócio

Começando com a segurança como estratégia de negócio, a ideia é entendermos que existem duas abordagens possíveis: uma tradicional e uma nova habilitadora. A segurança sempre foi vista dentro da indústria como um custo, uma camada; até hoje, muitas vezes, é tratada de forma displicente, com o entendimento de que primeiro deve existir um business case (caso de negócio), primeiro devem ser implementados requisitos funcionais, soluções de negócio, ferramentas, plataformas, e então deve ser aplicada uma camada de segurança. Nesse sentido, a segurança passa a ser vista como um custo porque dá a entender que tudo funcionaria normalmente se ela não existisse. Essa abordagem tradicional é limitante e leva a equipe de segurança para um cenário muito difícil de trabalhar.

A proposta moderna é transformar aquela restrição em uma força. Novos negócios podem ser consolidados porque existe segurança; o negócio pode continuar com um lucro previsível porque existe segurança. O que o conselho, os investidores mais querem é estabilidade e crescimento; eles não gostam de surpresas. Quando uma empresa está suscetível a determinados riscos, é muito difícil que investidores coloquem seu dinheiro nela, pois ela pode colapsar a qualquer momento. Quando transformamos nossa segurança em algo habilitador, é possível, por exemplo, fechar grandes negócios, estabelecer contratos com empresas de grande porte, empresas multinacionais, e obter certas certificações, como a ISO 27.000, SOC 2, entre outras. A segurança nos habilita a fazer mais conexões.

Integrando segurança e negócios no contexto moderno

No contexto moderno, nenhuma empresa é uma ilha. Todos precisamos estar sempre nos integrando, seja a outras empresas, seja a órgãos do governo, órgãos reguladores, Receita Federal, Anvisa, Ministério da Agricultura. O investimento que fazemos no contexto de segurança pode ser revertido. Ele pode, inclusive, reduzir o time to market (tempo de lançamento no mercado). Imaginem que, dentro da área de segurança, tenhamos habilitado soluções de acesso, autenticação e autorização. Se tivermos uma ferramenta pronta, podemos reduzir o time to market. Parte do nosso trabalho é justamente pesquisa e desenvolvimento, provas de conceito. Colocamos homologados na prateleira aceleradores que trarão ao negócio, por exemplo, maior visibilidade.

Vamos aprender que é possível fazer uma correspondência direta entre um determinado valor investido em segurança e os custos do produto. Dentro do nosso contexto de segurança, existe a ideia de que GRC (Governança, Riscos e Compliance) está totalmente alinhado com o que precisamos ter como alicerce, como base. Ao chegar em um determinado contexto, dentro de uma área ou empresa, podemos nos basear para fazer um assessment (avaliação), para realizar um levantamento. Na literatura, temos um framework chamado COSO, que nos indica cinco pilares que precisamos avaliar um por um, e todos eles fazem parte do nosso contexto de gestão de cybersecurity (cibersegurança).

Discutindo governança e cultura organizacional

Começaremos falando de governança e cultura. Governança é o entendimento de que sabemos o que existe e qual é o estado atual. Existe uma métrica famosa, o CMMI (Capability Maturity Model Indicator), que nos ajuda a entender nosso grau de maturidade perante determinados elementos. Dentro da nossa governança, sabemos o que existe? Isso é bom. E o que existe? Está governado? É reprodutível? Está gerenciado? Está otimizado? Quando tivermos cada um dos elementos que governamos com uma determinada métrica de maturidade e governança, teremos um controle maior e entenderemos onde precisamos fazer maiores investimentos e tomar mais precauções.

A cultura faz parte disso, pois sem uma cultura adequada de cibersegurança, muitas vezes, determinadas áreas estarão extremamente confortáveis, acreditando que existe um profissional ou uma área dentro da empresa cuidando de tudo relacionado à segurança. Isso, naturalmente, é falho, pois segurança é um dever de todos e deve estar presente em diversas camadas, inclusive nas ferramentas de segurança, mas não só nelas.

Avaliando apetite de risco e performance

Os objetivos estratégicos nos levarão ao conceito de apetite de risco, ou seja, o quanto estamos dispostos a aceitar e conviver com determinados riscos, porque às vezes vale a pena. Um exemplo clássico são os supermercados de autoatendimento. Quando retiramos a figura de um operador de caixa e pedimos que um cliente passe suas próprias compras e pague, entendemos que, em algum momento, determinadas mercadorias podem ser furtadas. Isso é um problema, mas por que seguir com a solução sabendo que há falhas? Porque compensa. Compensa porque deixaremos de pagar a um profissional para estar na caixa. Está bem se tivermos alguns furtos durante a operação, pois sai mais barato assumir o custo dessa perda do que contratar novos profissionais.

Entender que existem estratégias para lidar com os riscos é importante, e determinados riscos devem ser assumidos, sim. Por exemplo, para reduzir a fricção em um determinado percurso ou, principalmente, para ajustar a fricção ao risco. A performance nos colocará números. É muito difícil melhorar o que não podemos medir.

Comunicando performance e revisando controles

A ideia de performance é apresentar determinados números de forma compreensível para quem não é da área de cibersegurança. Quando apresentamos para um responsável de negócio, como um PO ou um Value Stream Owner, precisamos traduzir as informações. Não podemos simplesmente apresentar um CVE ou o risco de um cluster cair. Precisamos representar isso em uma linguagem que o negócio entenda. Por exemplo, dizer que o tempo médio de atendimento dentro da empresa aumentará de cinco minutos para uma hora é algo que será compreendido.

Dentro desse cenário, há a necessidade de revisões constantes. Precisamos escrever muito, especialmente na área de segurança, onde é necessário redigir normativos, avaliações, relatórios e pareceres de segurança. Isso se aplica aos nossos controles. Em um ambiente cloud, teremos diversos recursos, mas é importante entender que, mesmo em um ambiente altamente seguro, podem ocorrer falhas. Isso é especialmente verdade quando recorremos a soluções como IaaS, onde depositamos nossa confiança nos profissionais que cuidam da infraestrutura ou das plataformas.

Gerindo comunicação e transparência em segurança

Revisar é extremamente importante. Quando tratamos de comunicação, é essencial entender que prestaremos contas o tempo todo. Um gestor de cibersegurança tomará várias medidas de segurança, mas passará muito tempo fazendo relatórios. Comunicaremos riscos em cenários mais sérios, como vazamentos de dados, e teremos que informar clientes e a mídia, além de gerir a comunicação interna para evitar que informações incorretas sejam divulgadas.

A gestão da informação, alinhada à devida transparência e preparo para incidentes, é fundamental para a gestão de riscos e compliance. Isso já está no radar há muito tempo. Desde 2002, o OSSEG (Open Compliance and Ethics Group) começou a falar sobre GRC, e o primeiro artigo saiu em 2007. Hoje, temos como referência o Redbook, que aborda de forma sucinta os três pilares: governança, gestão de riscos e compliance, controles regulatórios, ética e obrigações legais.

Implementando governança adaptativa

Esses três pilares são muitas vezes vistos como limitadores dentro da empresa, mas cabe a nós, gestores da área de segurança, trabalhar cada um deles para mudar essa percepção. A principal estratégia para isso é a governança adaptativa. Funciona entendendo que dentro da nossa organização teremos soluções que mudam de acordo com seu ritmo e importância para o negócio. A camada mais interna, chamada de core, deve ter uma governança mais rígida, pois seu ritmo de mudança precisa ser lento e extremamente governado. Em uma estrutura bancária, por exemplo, estamos falando do core de processamento de transações.

Precisamos de aceleradores, como camadas de APIs e ferramentas comerciais, para facilitar o desenvolvimento e publicação de aplicações. Na camada mais externa, temos a camada de experimentação, que precisa de liberdade para agir e criar produtos rapidamente. Isso é importante para testar novas tecnologias e fornecer dados para parceiros criarem soluções. Cada camada precisa de uma governança de segurança diferente. Quando erramos na camada core, é um problema enorme, mas a área de experimentação deve ter liberdade para errar com segurança.

Concluindo o primeiro bloco da aula

Dentro da área de governança, ao chegarmos em uma empresa, precisamos entender o que é core, o que é tangencial, o que é mais ou menos importante. Devemos classificar cada um para trabalhar de forma adaptativa, sem frear o time-to-market ou o negócio, mas sim auxiliá-los. Seremos rígidos com o core, moderados com os aceleradores e flexíveis com a camada de experimentação.

Assim, chegamos ao final do nosso primeiro bloco. Nos vemos a seguir no segundo bloco da nossa aula de hoje.

Estratégia de governança em nuvem - Frameworks e modelos de governança

Introduzindo frameworks e modelos de governança em ambientes cloud

Vamos tratar agora alguns frameworks e modelos de governança em ambientes cloud. Começaremos com o TOGAF, o framework de arquitetura empresarial do Open Group. Ele divide nosso contexto em quatro pilares: estratégia, negócios, aplicação e tecnologia. Cada um deles está interconectado, onde o que está na parte inferior sustenta o que está na parte superior. Uma estratégia de negócio é realizada por meio de capacidades de negócio, serviços oferecidos dentro do nosso negócio, que, por sua vez, têm aplicações diretamente vinculadas e que sustentam nossa capacidade de negócio.

O conceito de overlap (superposição) surge quando um determinado negócio, com uma determinada capacidade, é sustentado por duas ou mais aplicações que fazem o mesmo. Por exemplo, quando temos duas ferramentas para gerenciar documentos. Isso requer uma governança duplicada, e os esforços devem ser duplicados. Chamamos isso de overlap de aplicações. O ideal é que sempre tenhamos uma única ferramenta sustentando uma determinada capacidade de negócio. Naturalmente, isso não exclui a possibilidade de estarmos sempre avaliando novas ferramentas ou estudando determinados recursos que existem em certas alternativas do mercado. A ideia aqui é conceitual: não devemos desperdiçar recursos nem duplicar projetos porque temos duas ou mais ferramentas sustentando as mesmas capacidades de negócio. A tecnologia está presente para sustentar essas aplicações.

Conectando elementos e reduzindo fricção

Um arquiteto deve ser capaz de conectar todos esses elementos. Se um determinado cluster falhar, ou se um pilar de segurança for comprometido, de que estamos falando? Qual capacidade do negócio é afetada? Atendimento ao cliente, realização de transações, programação de processos pelo cliente? Qual o impacto disso em nossa estratégia? Vamos deixar de crescer este ano como havíamos previsto? Portanto, o TOGAF é o primeiro framework que abordamos. Dentro deste contexto de quatro pilares, temos interconexões. Chamaremos de habilitadores tudo aquilo que contribui para essas interconexões e que acelera nossas entregas.

Estamos falando de redução de fricção. Fricção é o grau de dificuldade para que algo ocorra. Por exemplo, um processo de onboarding. Quanto tempo leva para um parceiro consumir nossas APIs após o fechamento de um contrato? É necessário preencher uma série de formulários? Passar por uma junta de segurança? Realizar algum processo muito burocrático? Ou há um self-service no marketplace? Reduzir a fricção é, muitas vezes, acelerar o time to market. A ideia é que devemos sempre evoluir nossos habilitadores.

Exemplos de habilitadores e segurança na borda

Alguns exemplos de habilitadores incluem IAM, nossos modelos de identidade. Hoje, temos sistemas de gestão de identidades na cloud, como o Identity e o Azure Identity. É importante que tenhamos habilitadores como SSO (single sign-on), plataformas às quais nos conectamos uma vez e que permitem acessar diversas ferramentas, podendo integrar-se até mesmo em ambientes complexos. Assim, meu sistema de recursos humanos, meu sistema de faturamento e meu sistema operacional podem utilizar meu IAM por meio de um SSO. É importante ter isso habilitado, assim como aceleradores para CIAM, nosso Customer IAM, B2B, B2C, B2B2C. Isso ocorre quando temos ferramentas que funcionam com protocolos padrão do mercado, como SAML, OAuth 2.0 e OpenID Connect.

É importante que tenhamos habilitadores de segurança na borda. Falamos de firewalls de aplicações web, soluções Edge, como Kamae, Asion, Cloudflare e vários outros. Falamos de motores de avaliação de risco. Tudo isso, disponível na prateleira para uso, acelera nossas entregas. Também falamos de habilitadores de automação e biometria. Processos automatizados reduzem nossos erros. Dentro de uma plataforma IAM na cloud, podemos ter automações e fluxos de trabalho para onboarding e offboarding de funcionários, que revogam todos os acessos desse usuário de forma segura e instantânea.

Utilizando biometria e processos organizacionais

Ferramentas de biometria incluem biometria facial, biometria da palma da mão e verificações de liveness, para saber se o que está diante da câmera não é uma fotografia. Análises dinâmicas para detectar tentativas de burlar essa identidade. Integrações com bureaus. A ideia é que os motores antifraude trabalhem com elementos que conhecem. Por exemplo, uma pessoa mudou a senha pela manhã e, no final da tarde, tenta esvaziar sua conta corrente. Conhecemos ambas as informações. Sabemos que a senha foi alterada e, muitas vezes, que o celular ou dispositivo não é o que costuma usar, e tomaremos uma decisão. Um bureau é um local onde podemos consultar para coletar mais informações. Exemplos de bureaus: temos a Serasa, por exemplo. Alguns trabalham com biometria, como iProove e Único. Temos diversas formas de coletar dados biométricos e consultar bureaus para verificar se a pessoa é quem diz ser. Existem até consultas governamentais que podemos verificar para confirmar se a pessoa é realmente quem afirma ser.

Processos e certificações são importantes. É essencial que ambos existam. Que os processos estejam definidos. Como é feito o onboarding de um novo funcionário? Como é feita a desvinculação, uma mudança de área, uma promoção? O acesso se acumula? Um gerente é um superfuncionário que pode fazer tudo o que um vendedor faz? Não deveria ser assim. O gerente de uma loja não deveria ter a capacidade de vender da mesma forma que um vendedor. São funções distintas. E quando são objeto de um processo organizacional, como uma promoção ou avanço de carreira, devem estar alinhados com segurança, e para isso existem os processos.

Estabelecendo comitês e certificações

Comitês e grupos de trabalho. Dentro da empresa, devem existir fóruns, grupos de especialistas multidisciplinares que avaliam determinados riscos dentro da companhia e ajudam a ponderar o que está sendo colocado na balança. A própria existência de grupos assim já é considerada um habilitador.

Certificações são resultados de auditorias realizadas por empresas acreditadas, por exemplo, para nos conceder a certificação ISO 27001, SOC 2. E isso é importante? Sim. Mas a certificação não substitui nenhum dos outros elementos, nem processos definidos, nem os comitês e grupos de trabalho.

Por que muitas vezes a auditoria toma uma amostra, selecionando algum elemento que está presente, frequentemente dentro de um contexto reduzido que não representa a empresa em sua totalidade.

Frameworks de referência

O NIST é, sem dúvida, uma das referências internacionais. O NIST-CSF 2.0 é ainda mais importante para nosso contexto de liderança, pois aborda governança. Até as versões anteriores, a quem era direcionado? Aos analistas, ao público mais técnico. A partir do 2.0, temos a presença de governança. O SP-879 também aborda a gestão. E o 800-210 se alinha precisamente com a nuvem. Ele é atualizado e traz novos elementos porque nosso cenário mudou. Algumas coisas mudaram e o NIST se atualizou para acompanhar essas mudanças.

A CSA, Cloud Security Alliance, é quem publica o CCM. E o CCM traz algo chamado CAIQ. Falando em nosso idioma, CAIQ é o Consensus Assessment Initiative Questionnaire (questionário de avaliação). Às vezes, quando fechamos projetos com empresas internacionais, recebemos um e-mail solicitando nosso CAIQ. O que é nosso CAIQ? O CAIQ é um questionário. É público e pode ser obtido no site do CCM. No site "cloudsecurityalliance.org", temos a opção de Download CCM and CAIQ. Este questionário trará diversas perguntas. Desde nosso processo de auditoria, nosso processo de criptografia, governança, recursos humanos, segurança, IAM, cadeia de suprimentos, avaliação de ameaças. São diversas perguntas que farão um diagnóstico de nossa empresa.

Explorando o CCM e outros frameworks

Voltando então à nossa apresentação, o CCM aborda três pilares principais: segurança de dados, gestão de identidades e segurança de aplicações e interfaces. Quando falamos de dados, falamos de DFD, de fluxo de dados. Fluxos que devem estar mapeados e ser conhecidos. E quando falamos de dados pessoais, estes devem estar conectados à base legal correspondente. Esse dado pessoal está presente por quê? Cumprimento de contrato, consentimento, obrigação legal. Dentro da área de cybersecurity, estamos diretamente conectados com a área de conformidade ou compliance. E o CCM nos ajuda nisso, além de vários outros pilares, como vimos em seu site.

Alguns outros frameworks que devemos conhecer e aprofundar conforme a necessidade são o Well-Architected. É um framework nascido na AWS e que tem sua versão também na Azure. São boas práticas de onboarding. Como manejar da melhor maneira possível dentro de um ambiente cloud. Por quê? Existem muitos riscos. Sim, há ferramentas para segurança, mas muitas vezes dependem de profissionais altamente qualificados, profissionais certificados para operar essa cloud. E para a direção é importante conhecer o Well Framework. Por quê? É uma forma de entender o caminho que vamos percorrer. Desde um lift-and-shift, subir as coisas tal como estão. Sair de um ambiente on-premises, migrar tudo em máquinas virtuais para a Azure e pensar que já estamos modernizados. Não, é um primeiro passo. O Well Framework orienta nossa trajetória para, de fato, alcançar a maturidade com tudo o que a cloud oferece e também chamando a atenção sobre a relação custo-benefício e o entendimento de FinOps.

Compreendendo modelos na cloud e responsabilidades

O que mais precisamos na estante? Conhecimento de Gartner, que junto com TOGAF traz muitas boas referências. CMMI é algo do mercado, não necessariamente de segurança, mas ajuda a entender que existe um ponto onde temos um contexto desconhecido, que é nosso nível zero, nosso nível básico. Não conhecemos nada do que temos aqui. Avançamos para um nível conhecido, isso já é algo. Do desconhecido ao conhecido, vamos avançando. E depois avançamos para um nível gerenciado. Já conheço, já está gerenciado, e vou avançar para o otimizado. A ideia é que algo tenha uma maturidade que pode ser péssima ou altamente otimizada.

Também existem frameworks mais técnicos, como por exemplo Dora Metrics, que aparece no livro Accelerate. A ideia é olhar a saúde de nossas aplicações, nosso tempo de entrega, quanto tempo levamos para recuperar uma aplicação e aqui há exemplos aos quais podemos recorrer.

Falando de modelos na cloud, temos três modelos básicos: infraestrutura como serviço, plataforma como serviço, às vezes em alguns lugares veremos produto como serviço, mas o mais adequado é plataforma como serviço e SaaS, que é o software como serviço. O grau de responsabilidade do cliente varia entre eles. Quando falamos de infraestrutura, o cliente tem muita responsabilidade, deve cuidar da infraestrutura como se estivesse on-premises, como se fosse local. Em plataforma como serviço, temos já uma maior facilidade, não precisamos nos preocupar tanto com a infraestrutura em si e quando falamos de uma solução como serviço, estamos mais tranquilos em relação à infraestrutura e plataforma. Em todos eles, algo em comum: dados e identidade sempre são responsabilidade do contratante.

Finalizando com a separação de responsabilidades

Aqui temos a separação de responsabilidades entre o fornecedor e o cliente, conforme o modelo. Em infraestrutura como serviço, devemos entender que a parte física está bem cuidada, mas todo o resto, aplicação de patches de segurança, instalação de OAuth, tudo corre por conta do cliente. Assim, a responsabilidade do cliente inclui sistema operacional, middleware, e nesse contexto podemos dizer que são nossos aceleradores, por exemplo, mensageria, nosso RabbitMQ, nosso Kafka, ou outros, nosso API Gateway, tudo o que está ao redor de nossas soluções. E conforme avançamos de modelo, alguns itens que eram responsabilidade do cliente passam para o fornecedor. Por exemplo, em plataforma como serviço, movemos para o lado do fornecedor o sistema operacional, os middleware e os runtimes. E ao cliente resta o quê? Aplicação, dados, identidade e acesso, configurações de segurança. Aqui se enquadra, por exemplo, um SGBD, um sistema de gestão de bases de dados. Receberemos uma base de dados, mas teremos que gerir o quê? Seus usuários, seus acessos, os papéis, porque é uma plataforma, é uma plataforma que contratamos, está disponível, mas devemos cuidá-la para garantir que a segurança seja adequada.

Por último, temos o software como serviço, onde transferimos as aplicações para o fornecedor. Do lado do fornecedor ficam as aplicações geridas. Por exemplo, quando falamos de Office 365 na cloud ou Google Docs. Todos os softwares como serviço: nós os acessamos, os usamos e já estão providos. Não sabemos em que cluster estão rodando, nem mesmo onde estão. E o que devemos cuidar: novamente, dados, identidade, configurações de uso, permissões de usuário.

Com isso, chegamos ao final de nosso segundo bloco e nos veremos a seguir para o terceiro.

Sobre o curso Segurança em Cloud: governança e liderança estratégica

O curso Segurança em Cloud: governança e liderança estratégica possui 505 minutos de vídeos, em um total de 66 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda Segurança acessando integralmente esse e outros cursos, comece hoje!

Conheça os Planos para Empresas