O blog da AWS

Definindo uma estratégia de múltiplas contas na AWS para bancos digitais

Por Paulo Aragão, Senior Solutions Architect, AWS
Por Matheus Arrais, Partner Solutions Architect, AWS

 

O mercado bancário global vem passando por transformações significativas nos anos recentes. Clientes  desejam, cada vez mais, uma experiência conectada, totalmente digital e personalizada, diferente da maioria dos serviços bancários existentes atualmente. Enquanto a constante evolução das expectativas de clientes e os avanços tecnológicos são os principais impulsionadores do crescimento de bancos digitais, o apoio regulatório tem fornecido um ambiente que propicia esta jornada. Isso pode ser observado através de uma série de regulações publicadas nos últimos anos, como Sistema de Pagamento Instantâneo (SPI/PIX),  através da introdução do Open Banking e outras iniciativas como Open Insurance, culminando em um agrupamento genérico de Open Finance, assim como o Sandbox Regulatório e também a LGPD (Lei Geral de Proteção de Dados Pessoais).

O mercado de bancos digitais continua a atrair um grupo diverso de participantes da indústria, desde bancos incumbentes construindo uma nova experiência digital, como por exemplo Banco Itaú, BTG Pactual Digital e Banco Inter, até bancos emergentes que desafiam este modelo tradicional, como Nubank, Banco Midway e C6Bank. Segundo levantamento feito pela empresa Cantarino Brasileiro, existem 40 bancos digitais no Brasil. Você pode aprender mais sobre como construir seu banco digital na AWS através do site AWS Digital Banking, assim como melhores práticas e arquiteturas de referência no AWS Well-Architected Framework FSI Lens.

Como próposito deste blog post, iremos focar em bancos digitais que estão buscando construir sua fundação desde o início de forma segura, resiliente e que sigam as conformidades do mercado, porém que seja ágil e escalável. Entretanto, muitos dos conceitos discutidos neste blog post também são aplicáveis a outros tipos de bancos digitais, como extensões digitais de bancos que possuem presença física.

 

Por que criar uma estratégia de múltiplas contas na AWS?

Muitas instituições de serviços financeiros possuem o desafio de ter times com processos de negócio diferentes que necessitam isolar suas cargas de trabalho e têm diferentes requerimentos para os controles de segurança e rede. Com uma conta AWS, empresas podem atingir o mais alto nível de isolamento de suas cargas de trabalho. O uso de múltiplas contas AWS se torna fundamental para atingir os requerimentos de negócio, governança, segurança e operação.

Alguns dos benefícios de criar uma estratégia de múltiplas contas na AWS são:

  • Inovação rápida seguindo diversos requerimentos – Você pode alocar contas AWS para diferentes times, projetos e produtos dentro da sua empresa, garantindo que cada um deles possa inovar rapidamente ao mesmo tempo que seguem seus requerimentos de segurança, sem impactar outros. Clientes AWS podem criar novas contas segregadas de seus ambientes produtivos, desenvolver novos produtos, testá-los seguindo as regulamentações e, caso aprovados, integrar este ambiente a seus sistemas produtivos.
  • Faturamento simplificado – Usando múltiplas contas AWS você simplifica como aloca os custos relacionados à nuvem, ajudando a identificar qual produto ou serviço é responsável pelos gastos na AWS. Com isso, novas iniciativas ou produtos existentes que estão migrando para a nuvem, podem ter um resumo de conta segregado para que seja possível isolar os custos, possibilitando estratégias de showback ou de chargeback dentro da empresa.
  • Controles de segurança flexíveis – Você pode usar múltiplas contas AWS para isolar as cargas de trabalho ou aplicações que tenham requisitos de segurança específicos ou precisam estar em conformidade com certificações como PCI-DSS, SOX e outras. O uso de múltiplas contas pode, inclusive, ajudar na conformidade com a LGPD, através de data lakes com dados anonimizados em contas isoladas onde usuários de negócio podem consumí-los de forma independente e com a governança adequada, evitando exposição desnecessária ao risco de vazamentos.
  • Adaptação fácil aos processos de negócio – Você pode organizar as múltiplas contas AWS de forma que melhor reflita as diferentes necessidades dos processos de sua empresa, que possivelmente terão diferentes requerimentos regulatórios, orçamentários, e operacionais. Como, por exemplo, ter uma conta que atenda às aplicações que fazem conexão com o Sistema de Pagamentos Brasileiro (SPB) e o Sistema de Pagamentos Instantâneos (SPI), que precisam seguir a LGPD, assinar digitalmente mensagens, entre outras normas, e uma outra conta para sistemas que envolvam pagamentos com cartão de crédito que precisam seguir conformidades como PCI-DSS. Dessa forma, você consegue reduzir o impacto deste esforço, agilizando a adequação do seu ambiente e permitindo um custo operacional reduzido.

Recomendações adicionais podem ser encontradas no whitepaper Organizando seu ambiente AWS, o qual compartilha orientações sobre como arquitetar um ambiente com múltiplas contas. Vamos utilizar essas orientações do whitepaper e aplicá-las para definir a estratégia de múltiplas contas de um banco digital. Você também pode revisar alguns conceitos e terminologias do AWS Organizations incluindo Organizações, Raiz (root), Conta, Unidade Organizacional (UO), que são fundamentais para a compreensão deste blog post.

 

Configurando um ambiente de múltiplas contas para um banco digital

Uma Unidade Organizacional (UO) é um container de contas em uma conta raiz (root). Uma UO também pode conter outras UOs, permitindo que você crie uma estrutura hierárquica. Vamos considerar agora quais são UOs que recomendamos para você criar para um banco digital. Uma UO deve ser baseada em uma função e propósito de controle comum, ao invés de se espelhar nas estruturas da sua empresa. A AWS recomenda que você inicie com as UOs Segurança e Infraestrutura. A maioria das empresas tem equipes centralizadas que fornecem serviços para toda a organização. Para isso, a AWS recomenda a criação de um conjunto de UOs fundamentais para essas funções específicas. O diagrama a seguir mostra a estrutura de UO recomendada para um banco digital.

 

 

Nós adicionamos duas UOs para cargas de trabalhos uma chamada Banking Applications e outra chamada Data & Analytics, juntamente com as UOs Infraestrutura, Segurança, Deployments, Sandbox, Policy Staging e Suspended UOs, que são as recomendadas no whitepaper Organizing Your AWS Environment Using Multiples Accounts.

  • UO Banking Application: essa UO é útil para rodar aplicações bancárias. Ela terá as contas que hospedam as cargas de trabalhos como core bancários, pagamentos, on-boarding, decisão de crédito e regulações. Essa UO pode futuramente ser divida em Retail UO (para unidade de negócio de varejo) e UO Corporativa (para Corporate Banking) baseada nos interesses de negócio do banco. Isso é útil quando você quer isolar uma carga de trabalho de uma unidade de negócio e aplicar diferentes politicas. Nós iremos cobrir sobre estrutura de contas com mais detalhes na próxima seção.
  • UO Data & Analytics: muitos clientes separam uma UO para analytics. Uma UO com esse proposito provê segurança, governança e controle de custo em funções analíticas. Ela terá contas com cargas de trabalhos para analise de dados e machine learning. Nós iremos cobrir sobre estrutura de contas com mais detalhes na próxima seção.

Estrutura de contas na AWS para bancos digitais

Após ter estabelecidos uma estrutura de UO, vamos olhar sobre contas AWS que farão parte de cada UO. O diagrama a seguir mostra as contas AWS recomendadas fundamentais requeridas para configurar em um banco digital. No entanto, isso pode variar com base nas ofertas de produtos fornecidas pelo banco digital.

 

 

Nas próximas seções, nós iremos cobrir contas AWS abaixo da UO de Banking Applications e Data & Analytics. Para contas AWS abaixo de outras UOs, você pode usar a referência do whitepaper Organizing Your AWS Environments Using Multiples Accounts.

Contas AWS abaixo da UO Banking Applications:

Vejamos as camadas funcionais de alto nível de um banco digital que nos ajudam a chegar às contas da AWS exigidas por uma UO de Banking Applications. Será semelhante ao diagrama a seguir (para simplificar, omitimos serviços horizontais, como rede, segurança, DevOps, outras camadas de infraestrutura e gerenciamento).

 

 

A camada de Core Products hospedará todos os produtos principais, como Core banking e será abstraída usando microsserviços personalizados, que, por sua vez, serão consumidos pelas APIs hospedadas em Experience APIs. A camada Experience tem o propósito de ser uma API para interface do usuário usando canais digitais e aplicações de engajamento com o cliente. As mudanças no ciclo de vida do cliente e do core banking irão emitir eventos para o Event Hub e para os assinantes desses eventos, que por sua vez orquestrarão as ações necessárias.

A seção a seguir cobre cada uma dessas camadas em detalhes e inclui recomendações de como você pode executar essas camadas em múltiplas contas. A seguir estão as contas recomendadas abaixo da UO de Banking Applications e a segregação de contas baseada na propriedade e nos diferentes requisitos de segurança de cada carga de trabalho.

  1. Conta para Core Products: um banco digital tem vários produtos principais implantados como Core Banking, Decisão de Crédito, Sistema de Pagamentos, Gerenciamento de Cartão, Sistemas de Risco e Conformidade, Contabilidade, Tesouraria, etc. Alguns bancos digitais desejam construir alguns desses recursos sozinhos e outros confiam Fornecedores de Software Independentes (ISV). A escolha é motivada pela cultura organizacional, pelo conjunto de habilidades e recursos disponíveis e pela rapidez com que o banco deseja lançar seus produtos e serviços para o mercado. Dependendo do software, o cliente terá a opção de implantar soluções ISV em sua conta da AWS ou usar uma versão SaaS para reduzir os esforços de gerenciamento e operação. Consulte a lista de parceiros com a competência AWS Financial Services para encontrar um parceiro AWS que possa ajudá-lo a acelerar o fornecimento de recursos essenciais. Para aumentar a segurança e o isolamento, recomendamos que você tenha contas AWS separadas para os sistemas principais. O número de contas de que você precisa dependerá da quantidade de produtos principais desenvolvidos. Por exemplo, certos produtos de core bancário disponíveis no mercado vem com módulos de core banking, pagamentos, gestão de patrimônio e tesouraria, enquanto outros provedores simplesmente fornecem módulos de core banking e pagamentos.
  2. Conta de microsserviços: essa conta hospedará os microsserviços para criar uma camada de abstração e agregação sobre os produtos principais do banco que serão expostos à uma camada de API (Experience). Ela terá integrações com os produtos principais em vários protocolos e modelos de dados. Terá microsserviços para recuperar informações da conta, perfil do cliente, configuração de instruções de pagamento, etc. Os serviços da AWS como Amazon API Gateway, AWS Fargate, Amazon Elastic Kubernetes Service (Amazon EKS) e Amazon Elastic Container Service podem ser usados para a construção de contêineres dos microsserviços com banco de dados como Amazon DynamoDB e Amazon Relational Database Service (Amazon RDS)
  3. Conta para Gerenciamento de API: os microsserviços principais serão expostos aos consumidores finais usando Experience APIs. Essas APIs são construídas para fins específicos que orquestram várias chamadas de microsserviços com base em requisitos de dispositivos móveis, web e outros canais. Essa camada também terá os recursos de gerenciamento de API, como limitação de taxa, throttling e proteção de segurança como serviços de firewall de aplicativo web e proteção de negação de serviços distribuída (DDoS). As APIs podem ser expostas usando o Amazon API Gateway com AWS Web Application Firewall (AWS WAF) para fornecer proteção contra ataques de aplicação, como DDoS, SQL Injection, Cross Site Scripting (XSS) entre outros. O AWS Shield fornece proteção DDoS contra todos os ataque de infraestrutura conhecidos (camadas 3 e 4), protegendo os aplicativos em execução na AWS. O AWS AppSync pode ser usado para construir APIs com GraphQL, que é um padrão comum para implantar APIs de camada de experiência agregando dados de vários microsserviços e centrais de domínio subjacentes.
  4. Conta de aplicativo de canal digital: um banco digital pode ter vários canais para fornecer a experiência bancária, por exemplo, aplicativo da web e móvel para seus clientes e parceiros. Esses aplicativos fornecem a origem do cliente/parceiro e a jornada de onboarding. Alguns dos serviços que a AWS oferece neste espaço são AWS Amplify para criar rapidamente aplicativos móveis e da web, Amazon Step Functions para criar fluxos de trabalho, Amazon Simple Storage Service (Amazon S3) e Amazon Elastic Compute Cloud (Amazon EC2) para hospedar qualquer software de terceiros.
  5. Conta de engajamento com o cliente: na ausência de agências físicas, o engajamento com cliente é a chave para um banco digital. A conta de Engajamento do Cliente terá funcionalidades em torno do fornecimento de suporte de centro de contato omnichannel por voz e chat, produtos de marketing e fidelidade, software de Gerenciamento de Relacionamento com o Cliente (CRM) e software de gerenciamento de campanha. Alguns dos serviços que a AWS oferece neste espaço são Amazon Connect, Amazon Pinpoint e Amazon Lex.
  6. Conta para Gerenciamento de Eventos: as arquiteturas orientadas a eventos ajudam os bancos digitais a crescer e também oferecem recursos de processamento quase em tempo real. Quaisquer eventos no sistema de transação central devem ser emitidos e capturados nesta conta para que os assinantes do evento possam orquestrar as ações necessárias, como enviar uma notificação de transação a um cliente ou executar verificações contra lavagem de dinheiro. Alguns dos serviços que a AWS oferece neste espaço são Amazon Managed Streaming para Apache Kafka (Amazon MSK), Amazon Kinesis e Amazon Simple Notification Service (Amazon SNS).
  7. Conta de Open Banking: esta conta hospedará as APIs necessárias para atender aos requisitos regulatórios de um país e se integrar às contas de microsserviços para buscar as informações necessárias. Essa conta também hospeda gerenciamento de consentimento, sandbox e portais de desenvolvedor para parceiros que consomem APIs de open banking.
  8. Conta para Depósito de Dados: um depósito de dados é uma conta segura que manterá dados como backups de dados, snapshots, modelos do AWS CloudFormation e imagens de máquina da Amazon (AMI) em um local seguro dentro da região primária da AWS. Os dados serão criptografados em repouso usando serviços como AWS Key Management Service (AWS KMS) e em trânsito usando TLS. No caso improvável de qualquer perda de dados na conta principal, essa conta é usada para recuperar os dados e backups do banco. O privilégio mínimo é concedido aos membros da equipe de segurança do banco digital para acessar esta conta. Para detalhes sobre sobre a concessão de privilégios mínimos, acesse aqui.

Todas as contas devem seguir as melhores práticas de segurança da AWS. A mesma estrutura de conta pode ser seguida para ambientes de desenvolvimento e teste abaixo da UO de Banking Application. Você pode ter vários ambientes de teste, como de User Acceptance Testing (UAT) e outro para os testes de integração do sistema.

Contas AWS abaixo da UO de Data & Analytics:

Os bancos digitais estão inovando e oferecendo ofertas personalizadas aos clientes, procurando oportunidades de vendas cruzadas e fornecendo melhores serviços ao cliente. Para alcançar tudo isso, os bancos digitais exigem uma plataforma de análise segura, flexível e escalável.

Uma arquitetura de várias contas para UO de dados e análises é um tópico abrangente com uma série de variações e poderia ser um blog dedicado em si. Uma arquitetura de várias contas para um ambiente de dados oferece suporte a uma arquitetura de Lake House, fornecendo dados em escala, o melhor preço-desempenho, acesso contínuo aos dados para resolver os desafios de negócios e governança unificada. Recomendamos três contas para começar, mas que podem ser estendidas à medida que o ambiente aumenta.

  1. Conta de ingestão de dados: uma conta intermediária que permite a ingestão de dados de uma variedade de fontes na conta de armazenamento Lake House (data-lake-house-storage-account). Essa conta oferece a capacidade de se conectar a fontes de dados internas e externas por meio de uma variedade de protocolos. Por exemplo, dados de diferentes LOBs, aplicativos ERP, aplicativos de CRM e aplicativos da web e móveis serão entregues à conta de armazenamento da Lake House por meio desta conta. Essa conta aproveitará os serviços da AWS, como Amazon Simple Storage Service (Amazon S3), Amazon Kinesis, Amazon Managed Streaming para Apache Kafka, AWS Database Migration Service e AWS DataSync.
  2. Conta de armazenamento de dados do Lake House: essa conta fornece componentes duráveis, escaláveis e econômicos para armazenar e gerenciar grandes quantidades de dados. Em uma arquitetura Lake House, o data lake, o data warehouse e outros armazenamentos construídos para fins específicos se integram nativamente para fornecer uma camada de armazenamento integrada e econômica que oferece suporte a dados não estruturados, bem como altamente estruturados e modelados. A camada de armazenamento pode armazenar dados em diferentes estados de prontidão para consumo, incluindo estado bruto (raw), em conformidade com a confiabilidade (trusted-conformed), enriquecido (enriched) e modelado (modelled). Essa conta também terá os componentes da camada de processamento para transformar os dados em um estado consumível por meio de validação, limpeza, normalização, transformação e enriquecimento de dados. Essa conta aproveitará os serviços da AWS como Amazon S3, Amazon Redshift e Amazon OpenSearch para armazenamento; Amazon Elastic Map Reduce(Amazon EMR) e AWS Glue para processamento e catálogo de dados; e AWS Lake Formation para governança.
  3. Conta de consumo de dados: esta conta fornece componentes escaláveis e de alto desempenho, que usam interfaces unificadas da Lake House para acessar todos os dados armazenados na conta de armazenamento da Lake House e todos os metadados armazenados no catálogo da Lake House. Essa conta será acessada pelas equipes de cientistas e analistas de dados. Pode haver várias contas de consumidor com base nos controles de uso e segurança. Pode haver um para aprendizado de máquina e outro para análises padrão. Esta conta aproveitará os serviços da AWS, como Amazon Sagemaker Studio, AWS Glue DataBrew, Amazon QuickSight e Amazon Athena.

A mesma estrutura de conta pode ser seguida para ambientes de desenvolvimento e teste para esta UO.

Como a AWS pode ajuda-lo a implantar esta estratégia?

Criar e gerenciar uma estratégia de múltiplas contas requer segurança, governança, e controles de custos além da automação adequada que possa orquestrar esse ambiente. AWS Control Tower fornece a maneira mais fácil para configurar e governar um ambiente seguro, de múltiplas contas, que chamamos de landing zone. O AWS Control Tower cria a sua landing zone usando o AWS Organizations, trazendo a gerência e governança contínua assim como implementa as melhores práticas baseadas no trabalho da AWS com milhares de clientes que migraram para a nuvem. Ao implementar o AWS Control Tower você pode estender a governança para contas novas ou existentes, e ganhar visibilidade da conformidade de seus recursos rapidamente. Você pode implantar você mesmo, através de nossa extensa gama de parceiros, ou através do time de AWS Professional Services.

Conclusão

Neste blog post nós cobrimos os benefícios de criar uma estratégia de múltiplas contas para um banco digital e os fatores mais importantes que bancos digitais deveriam olhar ao definir sua estrutura de contas. É importante configurar a sua landing zone pensando nos tipos de cargas de trabalho que você vai querer operar na nuvem para que seja facilmente escalável para atender requerimentos futuros. Nós estamos ajudando os bancos digitais ao redor do mundo a rodar na AWS e você pode nos procurar se precisar de ajuda. Para mais informações sobre como rodar aplicações financeiras na AWS, você pode olhar os seguintes posts focados em instituições financeiras no Brasil:

Além destes, os seguintes blogs e whitepapers podem ser de seu interesse:

Este blog post foi baseado no conteúdo original deste artigo e adaptado para a realidade local do Brasil.

 

Sobre os autores

Paulo Aragão é um Arquiteto de Soluções Sênior que trabalha há mais de 20 anos com clientes Enterprise. Ampla experiência em Computação de Alta Performance (HPC), atualmente dedica seus dias a ajudar clientes a inovarem através do uso de serviços de IA e ML na nuvem AWS. Apaixonado por música e mergulho, gosta de ler livros, jogar World of Warcraft, New World e cozinhar para os amigos.

 

 

 

 

Matheus Arrais é um Arquiteto de Soluções para parceiros cujo foco é a estratégia de múltiplas contas e serviços de gerenciamento e governança. Ele trabalha em estreita colaboração com parceiros para ajudar a oferecer a melhor solução para seus clientes. Fora do trabalho, Matheus tem uma paixão por ler, tocar bateria e viajar