Detectar fraudes bancárias móveis

Em um caso típico de fraude online, o ladrão faz várias transações, levando a uma perda de milhares de dólares. É por isso que a detecção de fraudes deve acontecer quase em tempo real. Mais de 800 milhões de pessoas usam aplicativos móveis. À medida que esse número aumenta, a fraude bancária móvel também aumenta. O setor financeiro está experimentando um aumento de 100% em relação ao ano anterior em perdas causadas pelo acesso de plataformas móveis. Mas há uma atenuação. Este artigo apresenta uma solução que usa a tecnologia do Azure para prever uma transação bancária móvel fraudulenta dentro de dois segundos. A arquitetura apresentada aqui é baseada em uma solução do mundo real.

Desafios: instâncias raras de fraude e regras rígidas

A maioria das fraudes móveis ocorre quando um ataque de troca de SIM é usado para comprometer um número de celular. O número de telefone é clonado e o criminoso recebe as notificações por SMS e chamadas enviadas para o dispositivo móvel da vítima. O criminoso então obtém credenciais de entrada usando engenharia social, phishing, vishing (usando um telefone para phishing) ou um aplicativo baixado infectado. Com essas informações, o criminoso pode representar um cliente do banco, registrar-se para acesso móvel e gerar imediatamente transferências e saques de fundos.

Fraude móvel é difícil de detectar e cara para consumidores e bancos. O primeiro desafio é que é raro. Menos de 1% de todas as transações são fraudulentas, portanto, pode levar tempo para que uma equipe de gerenciamento de casos ou fraudes examine transações potencialmente fraudulentas para identificar as fraudulentas. Um segundo desafio é que muitas soluções de monitoramento de fraude dependem de mecanismos baseados em regras. Tradicionalmente, os mecanismos baseados em regras são eficazes na detecção de padrões estabelecidos de transações semelhantes a fraudes geradas a partir de endereços IP arriscados ou várias transações geradas em um breve período em uma nova conta. Mas os mecanismos baseados em regras têm uma limitação significativa: as regras não se adaptam rapidamente a tipos novos ou em evolução de ataques. Eles são restringidos das seguintes maneiras:

• A detecção não é em tempo real, portanto, a fraude é detectada depois que ocorre uma perda financeira.
• As regras são binárias e limitadas. Eles não acomodam a complexidade e as combinações de variáveis de entrada que podem ser avaliadas. Essa limitação resulta em um alto número de falsos positivos.
• As regras são codificadas na lógica de negócios. A curadoria das regras, a incorporação de novas fontes de dados ou a adição de novos padrões de fraude geralmente exigem alterações de aplicativo que afetam um processo de negócios. A propagação de alterações em um processo de negócios pode ser complicada e cara.

Os modelos de IA podem melhorar drasticamente as taxas de detecção de fraudes e os tempos de detecção. Os bancos estão usando esses modelos junto com outras abordagens para reduzir as perdas. O processo descrito aqui é baseado em três elementos:

• Um modelo de IA que atua em um conjunto derivado de características comportamentais
• Uma metodologia para aprendizado de máquina
• Um processo de avaliação de modelo que é como o usado por um gerente de fraude para avaliar um portfólio

Contexto operacional

Para o banco em que essa solução se baseia, à medida que os clientes aumentavam o uso de serviços digitais, houve um pico de fraudes em todo o canal móvel. Era hora do banco reconsiderar sua abordagem de detecção e prevenção de fraudes. Esta solução começou com perguntas que afetaram o processo de fraude e as decisões:

• Quais atividades ou transações provavelmente são fraudulentas?
• Quais contas estão comprometidas?
• Quais atividades precisam de mais investigação e gerenciamento de casos?

Para que a solução forneça valor, deve haver uma compreensão clara de como a fraude bancária móvel se torna evidente no ambiente operacional:

• Que tipos de fraude são perpetuados na plataforma?
• Como é confirmado?
• Quais são os padrões em atividades e transações fraudulentas?

As respostas a essas perguntas levaram a uma compreensão dos tipos de comportamento que podem sinalizar fraudes. Os atributos de dados foram mapeados para as mensagens, coletadas dos gateways de aplicativo móvel, correlacionadas aos comportamentos identificados. O comportamento da conta mais relevante para determinar a fraude foi então criado.

A tabela a seguir identifica tipos de comprometimento, atributos de dados que podem sinalizar fraudes e comportamentos relevantes para o banco:

* O indicador mais comum de comprometimento. Precede compromissos financeiros e não financeiros.

A dimensão comportamental é essencial para detectar fraudes móveis. Perfis baseados em comportamento podem ajudar a estabelecer padrões de comportamento típicos para uma conta. A análise pode apontar a atividade que parece estar fora da norma. Estes são alguns exemplos de tipos de comportamento que podem ser perfilados:

• Quantas contas estão associadas ao dispositivo?
• Quantos dispositivos estão associados à conta? Com que frequência eles são descartados ou adicionados?
• Com que frequência o dispositivo ou o cliente entra?
• Com que frequência o cliente altera senhas?
• Qual é o valor médio de transferência monetária ou retirada da conta?
• Com que frequência os saques são feitos da conta?

A solução usa uma abordagem baseada em:

• Engenharia de recursos para criar perfis comportamentais para clientes e contas.
• Aprendizado de máquina do Azure para criar um modelo de classificação de fraude para comportamento de conta suspeito ou inconsistente.
• Serviços do Azure para processamento de eventos em tempo real e fluxo de trabalho de ponta a ponta.

Arquitetura de alto nível

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados

Há três fluxos de trabalho nesta arquitetura:

• Um pipeline controlado por eventos ingere e processa dados de log, cria e mantém perfis de conta comportamental, incorpora um modelo de classificação de fraude e produz uma pontuação preditiva. A maioria das etapas neste pipeline começa com uma função do Azure. As funções do Azure são usadas porque são sem servidor, dimensionadas facilmente e agendadas. Essa carga de trabalho requer processar milhões de transações móveis de entrada e avaliá-las por fraude quase em tempo real.

• Um fluxo de trabalho de treinamento de modelo combina dados de fraude históricos locais e dados de log ingeridos. Essa carga de trabalho é orientada em lote e usada para treinamento e retreinamento de modelos. O Azure Data Factory orquestra as etapas de processamento, incluindo:

  • Upload de dados de fraude histórico rotulados de fontes locais.
  • Arquivo de conjuntos de recursos de dados e histórico de pontuação para todas as transações.
  • Extração de eventos e mensagens em um formato estruturado para engenharia de recursos e retreinamento e avaliação de modelos.
  • Treinamento e retreinamento de um modelo de fraude por meio do Azure Machine Learning.

• O terceiro fluxo de trabalho se integra aos processos de negócios de back-end. Você pode usar os Aplicativos Lógicos do Azure para se conectar e sincronizar com um sistema local para criar um caso de gerenciamento de fraudes, suspender o acesso à conta ou gerar um contato telefônico.

O centro dessa arquitetura é o pipeline de dados e o modelo de IA, que são discutidos com mais detalhes posteriormente neste artigo.

A solução se integra ao ambiente local do banco usando um ESB (barramento de serviço empresarial) e uma conexão de rede com desempenho.

Pipeline de dados e automação

Quando um criminoso tem acesso a uma conta bancária por meio de um aplicativo móvel, a perda financeira pode ocorrer em minutos. A detecção efetiva da atividade de fraude deve ocorrer enquanto o criminoso está interagindo com o aplicativo móvel e antes que uma transação monetária ocorra. O tempo necessário para reagir a uma transação fraudulenta influencia diretamente a quantidade de perda financeira que pode ser evitada. Quanto mais cedo a detecção ocorrer, menos a perda financeira.

Menos de dois segundos, e idealmente muito menos, é a quantidade máxima de tempo depois que uma atividade bancária móvel é encaminhada para processamento que precisa ser avaliada para fraude. Isso é o que precisa acontecer durante esses dois segundos:

• Colete um evento JSON complexo.
• Valide, autentique, analise e transforme o JSON.
• Crie recursos de conta com base nos atributos de dados.
• Envie a transação para inferência.
• Recupere a pontuação de fraude.
• Sincronizar com um sistema de gerenciamento de casos de back-end.

Os tempos de latência e resposta são críticos em uma solução de detecção de fraudes. A infraestrutura para dar suporte a ela deve ser rápida e escalonável.

Processamento de eventos

Os eventos de telemetria dos gateways de aplicativo móvel e de Internet do banco são formatados como arquivos JSON com um esquema vagamente definido. Esses eventos são transmitidos como telemetria de aplicativo para os Hubs de Eventos do Azure, onde uma função do Azure em um Ambiente de Serviço de Aplicativo dedicado orquestra o processamento.

O diagrama a seguir ilustra as interações fundamentais para uma função do Azure nessa infraestrutura:

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados

1. Ingerir a carga de evento JSON bruto dos Hubs de Eventos e autenticar usando um certificado SSL recuperado do Azure Key Vault.
2. Coordene a desserialização, a análise, o armazenamento e o registro em log de mensagens JSON brutas no Azure Data Lake e no histórico de transações financeiras do usuário no banco de dados SQL do Azure.
3. Atualize e recupere perfis de conta de usuário e dispositivo do Banco de Dados SQL e do Data Lake.
4. Chame um ponto de extremidade do Azure Machine Learning para executar um modelo preditivo e obter uma pontuação de fraude. Persista o resultado da inferência em um data lake para análise operacional.
5. Conecte o Power BI ao Data Lake por meio do Azure Synapse Analytics para um painel de análise operacional em tempo real.
6. Poste os resultados pontuados como um evento para um sistema local para mais atividades de investigação e gerenciamento de fraudes.

Pré-processamento de dados e transformação JSON

No cenário real em que essa solução se baseia, o pré-processamento dos dados foi uma etapa integral na formatação dos dados para o desenvolvimento e o treinamento dos modelos de machine learning. Houve anos de eventos históricos de mobile e internet banking, incluindo dados de transação da telemetria do gateway de aplicativo no formato JSON. Havia centenas de milhares de arquivos que continham vários eventos que precisavam ser desserializados, mesclados e limpos para treinar o modelo de machine learning.

Cada gateway de aplicativo produz telemetria da interação de um usuário, capturando informações como o sistema operacional, metadados de dispositivo móvel, dados da conta e solicitações e respostas de transação. Houve variação entre arquivos JSON e atributos, e os tipos de dados eram diferentes e inconsistentes. Outra complicação com os arquivos JSON foi que atributos e tipos de dados podem mudar inesperadamente à medida que as atualizações do aplicativo eram enviadas por push para os gateways e os recursos eram removidos, modificados ou adicionados. Os desafios de transformação de dados com os esquemas incluem o seguinte:

• Um arquivo JSON pode incluir uma ou mais interações de telefone celular. Cada interação precisa ser extraída como uma mensagem separada.
• Os campos podem ser nomeados ou representados de forma diferente.
• Caracteres como novas linhas ou retornos de carro são inseridos inconsistentemente nas mensagens.
• Atributos como endereços de email podem estar ausentes ou parcialmente formatados.
• Pode haver propriedades e valores complexos e aninhados.

Um pool do Spark é usado como parte do caminho frio para processar arquivos JSON históricos e para desserializar, nivelar e extrair atributos de dispositivo e transação. Cada arquivo JSON é validado e analisado e os atributos de transação são extraídos e persistidos em um data lake e particionados com base na data da transação.

Esses atributos são usados posteriormente para criar recursos para o classificador de fraude. O poder dessa solução depende da capacidade dos dados JSON serem padronizados, unidos e agregados com dados históricos para criar perfis de comportamento.

Processamento e apresentação de dados quase em tempo real com o Banco de Dados SQL

Nesta solução, os eventos são produzidos de várias fontes, incluindo registros de autenticação, informações do cliente e dados demográficos, registros de transações e dados de log e atividade de dispositivos móveis. O Banco de Dados SQL é usado para executar análise de dados em tempo real, pré-processamento e apresentação porque o SQL é familiar para muitos desenvolvedores.

A funcionalidade HTAP é necessária para recuperar o histórico de comportamento da conta de usuário para um determinado dispositivo nos sete dias anteriores para calcular recursos quase em tempo real com baixa latência. No Banco de Dados SQL, esses recursos HTAP (transação híbrida/processamento analítico) são usados:

• As tabelas com otimização de memória armazenam perfis de conta. As tabelas com otimização de memória têm vantagens em relação às tabelas SQL tradicionais porque são criadas e acessadas na memória principal. A latência e a sobrecarga do acesso ao disco são evitadas. O requisito para essa solução é processar 300 mensagens JSON/segundo. As tabelas com otimização de memória fornecem esse nível de taxa de transferência.
• As tabelas com otimização de memória são acessadas com mais eficiência de procedimentos armazenados compilados nativamente. Ao contrário dos procedimentos armazenados interpretados, os procedimentos armazenados compilados nativamente são compilados quando são criados pela primeira vez.
• Uma tabela temporal é uma tabela que mantém automaticamente o histórico de alterações. Quando uma linha é adicionada ou atualizada, ela é gravada em versão e gravada na tabela de histórico. Nesta solução, os perfis de conta são armazenados em uma tabela temporal que tem uma política de retenção de sete dias, portanto, as linhas são removidas automaticamente após o período de retenção.

Essa abordagem também oferece estes benefícios:

• Acesso a dados arquivados para análise operacional, retreinamento de modelo de machine learning e validação de fraude
• Arquivamento simplificado de dados para armazenamento de longo prazo
• Escalabilidade por meio de dados de fragmentação e o uso de um banco de dados elástico

Gerenciamento de esquema de eventos

A automação do gerenciamento de esquemas é outro desafio que precisava ser resolvido para essa solução. JSON é um formato de arquivo flexível e portátil, em parte porque um esquema não é armazenado com os dados. Quando os arquivos JSON precisam ser analisados, desserializados e processados, um esquema que representa a estrutura do JSON deve ser codificado em algum lugar para validar as propriedades de dados e os tipos de dados. Se o esquema não for sincronizado com a mensagem JSON de entrada, a validação JSON falhará e os dados não serão extraídos.

O desafio vem quando a estrutura de mensagens JSON é alterada devido à nova funcionalidade do aplicativo. Em sua solução original, o banco para o qual essa solução foi criada implantou vários gateways de aplicativo, cada um com sua própria interface do usuário, funcionalidade, telemetria e estrutura de mensagens JSON. Quando o esquema estava fora de sincronia com os dados JSON de entrada, as inconsistências criaram atrasos de perda e processamento de dados para detecção de fraudes.

O banco não tinha um esquema formal definido para esses eventos, e as flutuações constantes na estrutura dos arquivos JSON criaram dívida técnica em cada iteração da solução. Essa solução resolve esse problema estabelecendo um esquema para esses eventos e usando o Registro de Esquema do Azure. O Registro de Esquema do Azure fornece um repositório central de esquemas para eventos e flexibilidade para produtores e aplicativos de consumidor trocarem dados sem a necessidade de gerenciar e compartilhar o esquema. A estrutura de governança simples que ele apresenta para esquemas reutilizáveis e a relação que define entre esquemas por meio dos constructos de agrupamento (grupos de esquemas) pode eliminar dívidas técnicas significativas, impor conformidade e fornecer compatibilidade com versões anteriores em esquemas de alteração.

Engenharia de recursos para machine learning

Os recursos fornecem uma maneira de criar o perfil do comportamento da conta agregando atividades em diferentes escalas de tempo. Eles são criados a partir de dados nos logs de aplicativos que representam o comportamento transacional, não transacional e do dispositivo. O comportamento transacional inclui atividades de transação monetária, como pagamentos e saques. O comportamento não transacional inclui ações do usuário, como tentativas de entrada e alterações de senha. O comportamento do dispositivo inclui atividades que envolvem um dispositivo móvel, como adicionar ou remover um dispositivo. Os recursos são usados para representar o comportamento da conta atual e anterior, incluindo:

• Novas tentativas de registro de usuário de um dispositivo específico.
• Tentativas de entrada bem-sucedidas e malsucedidas.
• Solicitações para adicionar beneficiários ou beneficiários de terceiros.
• Solicitações para aumentar os limites de conta ou cartão de crédito.
• Alterações de senha.

Uma tabela de perfil de conta contém atributos das transações JSON, como a ID da mensagem, o tipo de transação, o valor do pagamento, o dia da semana e a hora do dia. As atividades são agregadas em vários períodos de tempo, como uma hora, um dia e sete dias, e armazenadas como um histórico de comportamento para cada conta. Cada linha na tabela representa uma única conta. Estes são alguns dos recursos:

Depois que os recursos da conta são calculados e o perfil é atualizado, uma função do Azure chama o modelo de machine learning para pontuação por meio de uma API REST para responder a essa pergunta: Qual é a probabilidade de essa conta estar em um estado de fraude, com base no comportamento que vimos?

AutoML

O AutoML é usado na solução porque é rápido e fácil de usar. O AutoML pode ser um ponto de partida útil para descoberta e aprendizado rápidos, pois não requer conhecimento especializado ou configuração. Ele automatiza as tarefas iterativas e demoradas do desenvolvimento de modelos de machine learning. Cientistas de dados, analistas e desenvolvedores podem usá-lo para criar modelos de machine learning com alta escalabilidade, eficiência e produtividade, mantendo a qualidade do modelo.

O AutoML pode executar as seguintes tarefas em um processo de aprendizado de máquina:

• Dividir dados em conjuntos de dados de treinamento e validação
• Otimizar o treinamento com base em uma métrica escolhida
• Executar validação cruzada
• Gerar recursos.
• Acrescentar valores ausentes
• Executar codificação one-hot e vários dimensionadores

Desequilíbrio nos dados

A classificação de fraudes é desafiadora devido ao grave desequilíbrio de classe. Em um conjunto de dados de fraude, há muito mais transações não fraudulentas do que transações fraudulentas. Normalmente, menos de 1% de um conjunto de dados contém transações fraudulentas. Se não for resolvido, esse desequilíbrio poderá causar um problema de credibilidade no modelo, pois todas as transações podem acabar classificadas como não fraudulentas. O modelo pode perder completamente todas as transações fraudulentas e ainda alcançar uma taxa de precisão de 99%.

O AutoML pode ajudar a redistribuir dados e criar um melhor equilíbrio entre transações fraudulentas e não fraudulentas:

• O AutoML dá suporte à adição de uma coluna de pesos como entrada, fazendo com que as linhas nos dados sejam ponderadas para cima ou para baixo, o que pode tornar uma classe menos importante. Os algoritmos usados pelo AutoML detectam desequilíbrio quando o número de amostras na classe minoritária é igual ou menor que 20% do número de amostras na classe majoritária. Posteriormente, o AutoML executa o experimento com dados subamplados para verificar se o uso de pesos de classe resolve esse problema e melhora o desempenho. Se ele determinar que o desempenho é melhor por causa do experimento, o remédio é aplicado.
• Você pode usar uma métrica de medição de desempenho que lida melhor com dados desequilibrado. Por exemplo, se o modelo precisar ser sensível a falsos negativos, use recall. Quando o modelo precisar ser sensível a falsos positivos, use precision. Você também pode usar uma pontuação F1. Essa pontuação é a média harmônica entre precision e recall, portanto, não é afetada por um alto número de verdadeiros positivos ou verdadeiros negativos. Talvez seja necessário calcular algumas métricas manualmente durante a fase de teste.

Como alternativa, para aumentar o número de transações classificadas como fraudulentas, você pode usar manualmente uma técnica chamada Técnica de Sobrecarga De Minoria Sintética (SMOTE). SMOTE é uma técnica estatística que usa bootstrapping e k-nearest neighbor (KNN) para produzir instâncias da classe minoritária.

Treinamento do modelo

Para treinamento de modelo, o SDK do Python espera dados em um formato de dataframe pandas ou como um conjunto de dados tabular do Azure Machine Learning. O valor que você deseja prever precisa estar no conjunto de dados. Você passa a coluna y como um parâmetro ao criar o trabalho de treinamento.

Aqui está um exemplo de código, com comentários:

data = https://automlsamplenotebookdata.blob.core.windows.net/automl-sample-notebook-data/creditcard.csv
dataset = Dataset.Tabular.from_delimited_files(data)
training_data, validation_data = dataset.random_split(percentage=0.7)
label_column_name = "Class"

automl_settings = {
    "n_cross_validations": 3, # Number of cross validation splits.
    "primary_metric": "average_precision_score_weighted", # This is the metric that you want to optimize.
    "experiment_timeout_hours": 0.25, # Percentage of an hour you want this to run.
    "verbosity": logging.INFO, # Logging info level, debug, info, warning, error, critical.
    "enable_stack_ensemble": False, # VotingEnsembled is enabled by default.
}

automl_config = AutoMLConfig(
    task="classification",
    debug_log="automl_errors.log",
    training_data=training_data,
    label_column_name=label_column_name,
    **automl_settings,
)

local_run = experiment.submit(automl_config, show_output=True)

No código:

1. Carregue o conjunto de dados em um conjunto de dados tabular do Azure Machine Learning ou no dataframe pandas.
2. Divida o conjunto de dados em 70% de treinamento e 30% de validação.
3. Crie uma variável para a coluna que você deseja prever.
4. Comece a criar os parâmetros AutoML.
5. Configurar AutoMLConfig.
   1. task é o tipo de aprendizado de máquina que você deseja fazer: classification ou regression. Nesse caso, use classification.
   2. debug_log é o local onde as informações de depuração são gravadas.
   3. training_data é o dataframe ou objeto tabular no qual os dados de treinamento são carregados.
   4. label_column_name é a coluna que você deseja prever.
6. Execute o trabalho de machine learning.

Avaliação de modelos

Um bom modelo produz resultados realistas e acionáveis. Esse é um dos desafios com um modelo de detecção de fraudes. A maioria dos modelos de detecção de fraude produz uma decisão binária para determinar se uma transação é fraudulenta. A decisão é baseada em dois fatores:

• Uma pontuação de probabilidade entre 0 e 100 retornada pelo algoritmo de classificação
• Um limite de probabilidade estabelecido pela empresa. Acima do limite é considerado fraudulento, e abaixo do limite é considerado não fraudulento.

A probabilidade é uma métrica padrão para qualquer modelo de classificação. Mas normalmente é insuficiente em um cenário de fraude para decisões sobre se bloquear uma conta para evitar novas perdas.

Nesta solução, as métricas no nível da conta são criadas e fatoradas na decisão de se a empresa deve agir para bloquear uma conta. As métricas de nível de conta são definidas com base nessas métricas padrão do setor:

Essas métricas são pontos de dados valiosos para um gerenciador de fraudes. O gerente os usa para obter uma imagem mais completa do risco da conta e decidir sobre a correção.

Operacionalização e retreinamento do modelo

Modelos preditivos precisam ser atualizados periodicamente. Com o tempo e à medida que dados novos e diferentes se tornam disponíveis, um modelo preditivo precisa ser treinado novamente. Isso é especialmente verdadeiro para modelos de detecção de fraudes nos quais novos padrões de atividade criminosa são frequentes. Também se torna necessário quando a telemetria dos logs de aplicativos móveis é alterada devido a modificações enviadas por push para o gateway de aplicativo. Para fornecer o retreinamento nesta solução, todas as transações enviadas para análise e as métricas de avaliação de modelo correspondentes são registradas em log. Ao longo do tempo, o desempenho do modelo é monitorado. Quando parece degradar, um fluxo de trabalho de retreinamento é disparado. Vários serviços do Azure são usados no fluxo de trabalho de retreinamento:

• Você pode usar o Azure Synapse Analytics ou o Azure Data Lake para armazenar dados históricos do cliente. Você pode usar esses serviços para armazenar transações fraudulentas conhecidas carregadas de fontes locais e dados arquivados do serviço Web do Azure Machine Learning, incluindo transações, previsões e métricas de avaliação de modelo. Os dados necessários para o retreinamento são armazenados neste armazenamento de dados.

• Você pode usar pipelines do Data Factory ou do Azure Synapse para orquestrar o fluxo de dados e o processo de retreinamento, incluindo:

  • A extração de dados históricos e arquivos de log de sistemas locais.
  • O processo de desserialização JSON.
  • Lógica de pré-processamento de dados.

  Para obter informações detalhadas, consulte Retreinar e atualizar modelos do Azure Machine Learning com o Azure Data Factory.

• Você pode usar implantações azul-verde no Azure Machine Learning. Para obter informações sobre como implantar um novo modelo com tempo de inatividade mínimo, consulte a Distribuição segura para pontos de extremidade online.

Componentes

• O Azure Functions fornece funções de código sem servidor controladas por eventos e uma experiência de desenvolvimento de ponta a ponta.
• Os Hubs de Eventos são um serviço de ingestão de dados em tempo real totalmente gerenciado. Você pode usá-lo para transmitir milhões de eventos por segundo de qualquer fonte.
• O Key Vault criptografa chaves criptográficas e outros segredos usados por aplicativos e serviços de nuvem.
• O Azure Machine Learning é um serviço de nível empresarial para o ciclo de vida de aprendizado de máquina de ponta a ponta.
• O AutoML é um processo para automatizar as tarefas iterativas e demoradas do desenvolvimento do modelo de machine learning.
• O Banco de Dados SQL do Azure é um serviço de banco de dados relacional sempre atualizado e totalmente gerenciado criado para a nuvem.
• O Azure Synapse Analytics é um serviço de análise ilimitado que reúne integração de dados, armazenamento de dados corporativos e análise de Big Data.

Considerações técnicas

Para selecionar os componentes de tecnologia certos para uma infraestrutura baseada em nuvem em operação contínua para detecção de fraudes, você precisa entender os requisitos atuais e, às vezes, vagos. As opções de tecnologia para essa solução baseiam-se em considerações que podem ajudá-lo a tomar decisões semelhantes.

Conjuntos de habilidades

Considere os conjuntos de habilidades de tecnologia atuais das equipes que projetam, implementam e mantêm a solução. As tecnologias de nuvem e IA expandem as opções disponíveis para implementar uma solução. Por exemplo, se sua equipe tiver habilidades básicas de ciência de dados, o Azure Machine Learning será uma boa opção para criação e ponto de extremidade de modelo. A decisão de usar os Hubs de Eventos é outro exemplo. Os Hubs de Eventos são um serviço gerenciado que é fácil de configurar e manter. Há vantagens técnicas em usar uma alternativa como Kafka, mas fazer isso pode exigir treinamento.

Ambiente operacional híbrido

A implantação dessa solução abrange um ambiente local e o ambiente do Azure. Serviços, redes, aplicativos e comunicação precisam funcionar efetivamente em ambas as infraestruturas para dar suporte à carga de trabalho. As decisões de tecnologia incluem:

• Como os ambientes são integrados?
• Quais são os requisitos de conectividade de rede entre o datacenter do Azure e a infraestrutura local? O Azure ExpressRoute é usado porque fornece linhas duplas, redundância e failover. A VPN site a site não fornece a segurança ou o QoS (Qualidade de Serviço) necessário para a carga de trabalho.
• Como as pontuações de detecção de fraudes se integram aos sistemas de back-end? As respostas de pontuação devem se integrar aos fluxos de trabalho de fraude de back-end para automatizar a verificação de transações com clientes ou outras atividades de gerenciamento de casos. Você pode usar o Azure Functions ou os Aplicativos Lógicos para integrar os serviços do Azure a sistemas locais.

Segurança

Hospedar uma solução na nuvem cria novas responsabilidades de segurança. Na nuvem, a segurança é uma responsabilidade compartilhada entre um fornecedor de nuvem e um locatário do cliente. As responsabilidades de carga de trabalho variam dependendo se a carga de trabalho é um serviço SaaS, PaaS ou IaaS. Para obter mais informações, consulte Responsabilidade compartilhada na nuvem.

Se você estiver se movendo em direção a uma abordagem de Confiança Zero ou trabalhando para aplicar requisitos de conformidade regulatória, proteger uma solução de ponta a ponta requer um planejamento e consideração cuidadosos. Para design e implantação, recomendamos que você adote princípios de segurança consistentes com uma abordagem de Confiança Zero. Adotar princípios como verificar explicitamente, usar acesso de privilégios mínimos e assumir que a violação fortalece a segurança da carga de trabalho.

Verificação explícita é o processo de examinar e avaliar vários aspectos de uma solicitação de acesso. Aqui estão alguns dos princípios:

• Use uma plataforma de identidade forte como o Microsoft Entra ID.
• Entenda o modelo de segurança para cada serviço de nuvem e como os dados e o acesso são protegidos.
• Quando possível, use entidades de serviço e identidade gerenciada para controlar o acesso aos serviços de nuvem.
• Armazene chaves, segredos, certificados e artefatos de aplicativo, como cadeias de caracteres de banco de dados, URLs de ponto de extremidade REST e chaves de API no Key Vault.

Usar acesso de privilégio mínimo ajuda a garantir que as permissões sejam concedidas apenas para atender às necessidades comerciais específicas de um ambiente apropriado para um cliente apropriado. Aqui estão alguns dos princípios:

• Compartimentalize cargas de trabalho limitando o acesso que um componente ou recurso tem por meio de atribuições de função ou acesso à rede.
• Não permite o acesso público a pontos de extremidade e serviços. Use pontos de extremidade privados para ajudar a proteger seus serviços, a menos que seu serviço exija acesso público.
• Use regras de firewall para ajudar a proteger pontos de extremidade de serviço ou isolar cargas de trabalho usando redes virtuais.

Pressupor a violação é uma estratégia para orientar as decisões de design e implantação. A estratégia é assumir que uma solução foi comprometida. É uma abordagem para criar resiliência em uma carga de trabalho planejando a detecção, a resposta e a correção de uma ameaça à segurança. Para decisões de design e implantação, isso implica que:

• Os componentes da carga de trabalho são isolados e segmentados para que um comprometimento de um componente minimize o impacto em componentes upstream ou downstream.
• A telemetria é capturada e analisada proativamente para identificar anomalias e possíveis ameaças.
• A automação está em vigor para detectar, responder e corrigir uma ameaça.

Aqui estão algumas diretrizes a serem consideradas:

• Criptografar dados inativos e em trânsito.
• Habilite a auditoria para serviços.
• Capture e centralize logs de auditoria e telemetria em um único workspace de log para facilitar a análise e a correlação.
• Permitir que o Microsoft Defender para Nuvem examine configurações potencialmente vulneráveis e forneça um aviso antecipado sobre possíveis problemas de segurança.

A rede é um dos fatores de segurança mais importantes. Por padrão, os pontos de extremidade do workspace do Azure Synapse são pontos de extremidade públicos. Isso significa que eles podem ser acessados de qualquer rede pública, portanto, é altamente recomendável desabilitar o acesso público ao workspace. Considere implantar o Azure Synapse com o recurso de Rede Virtual Gerenciada habilitado para adicionar uma camada de isolamento entre seu workspace e outros serviços do Azure. Para obter mais informações sobre a Rede Virtual Gerenciada e outros fatores de segurança, consulte o white paper de segurança do Azure Synapse Analytics: segurança de rede.

Baixe um Arquivo Visio dessa arquitetura.

As diretrizes de segurança específicas para cada componente da solução na solução bancária são incluídas na tabela a seguir. Para obter um bom ponto de partida, examine o Azure Security Benchmark, que inclui linhas de base de segurança para cada um dos serviços individuais do Azure. As recomendações de linha de base de segurança podem ajudá-lo a selecionar as configurações de segurança para cada serviço.

Para obter mais informações, consulte Zero Trust Guidance Center.

Escalabilidade

A solução precisa executar os horários de pico de ponta a ponta. Um fluxo de trabalho de streaming para lidar com milhões de eventos que chegam continuamente exige alta taxa de transferência. Planeje criar um sistema de teste que simule o volume e a simultaneidade para garantir que os componentes de tecnologia sejam configurados e ajustados para atender às latências necessárias. O teste de escalabilidade é especialmente importante para esses componentes:

• Ingestão de dados para lidar com fluxos de dados simultâneos. Nessa arquitetura, os Hubs de Eventos são usados porque várias instâncias dela podem ser implantadas e atribuídas a diferentes grupos de consumidores. Uma abordagem de expansão é uma opção melhor porque o dimensionamento pode causar bloqueio. Uma abordagem de expansão também é uma melhor opção se você planeja expandir a detecção de fraudes do mobile banking para incluir um canal de internet banking.
• Uma estrutura para gerenciar e agendar o fluxo do processo. O Azure Functions é usado para orquestrar o fluxo de trabalho. Para melhorar a taxa de transferência, as mensagens são enviadas em lote em micro lotes e processadas por meio de uma única função do Azure em vez de processar uma mensagem por chamada de função.
• Um processo de dados de baixa latência para lidar com análise, pré-processamento, agregações e armazenamento. Na solução do mundo real na qual este artigo se baseia, os recursos de funções SQL otimizadas para memória atendem aos requisitos de escalabilidade e simultaneidade.
• Pontuação de modelo para lidar com solicitações simultâneas. Com os serviços Web do Azure Machine Learning, você tem duas opções para dimensionamento:
  • Selecione uma camada da Web de produção para dar suporte à carga de trabalho de simultaneidade da API.
  • Adicione vários pontos de extremidade a um serviço Web se precisar dar suporte a mais de 200 solicitações simultâneas.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

• Kate Baroni | Engenheiro de cliente principal
• Michael Hlobil | Gerente de Engenharia de Cliente Principal
• Cedric Labuschagne | Gerente de Programas Técnicos
• Frank Garofalo | Engenheiro de cliente principal
• Shep Sheppard | Engenheiro de Serviços Sênior

Outro colaborador:

• Mick Alberts | Escritor técnico

Próximas etapas

• Um pipeline de Big Data rápido, sem servidor e alimentado por uma única função do Azure
• Considerando o Azure Functions para um cenário de streaming de dados sem servidor
• Considerações de rede para o Ambiente do Serviço de Aplicativo
• Hubs de Eventos
• Key Vault
• Azure Machine Learning

Recursos relacionados

• Design de arquitetura de IA
• Comparar produtos e tecnologias de machine learning da Microsoft
• Diretrizes de desempenho e escala para Hubs de Eventos com Azure Functions
• Monitorar Azure Functions e Hubs de Eventos
• O que são os pipelines do Azure Machine Learning?