Guia de controle de segurança

Guia para 10 importantes controles de segurança na integração SP-API

Introdução

Esta publicação do blog destaca 10 importantes controles de segurança que os desenvolvedores devem abordar ao integrar-se à API do parceiro de vendas da Amazon e correlaciona esses controles à provisão aplicável da Política de proteção de dados da Amazon (DPP).

Os desenvolvedores e integradores que criam soluções para integração com a API do parceiro de vendas da Amazon (SPAPI) devem garantir que suas soluções e aplicativos estejam em conformidade com a Política de proteção de dados da Amazon. Os desenvolvedores devem manter controles tecnológicos adequados para verificar a conformidade com a Política de proteção de dados quando auditados. Os desenvolvedores podem usar as informações nesta postagem do blog para complementar e aprimorar a postura de segurança dos seus aplicativos.

Sobre a Política de proteção de dados da Amazon (DPP)

A Política de proteção de dados da Amazon (DPP) contém as categorias:

  • Requisitos gerais de segurança: Conjunto de requisitos para todos os desenvolvedores que criam aplicativos SPAPI. Esses sete requisitos incluem diretrizes de práticas recomendadas como proteção de rede, gerenciamento de acesso, política de senhas, criptografia e planos de resposta a incidentes.

  • Requisito de segurança adicional: Conjunto adicional de sete requisitos para desenvolvedores que executam operações restritas na SP-API que envolvem informação de identificação pessoal (IIP). O acesso a IIP é concedido aos desenvolvedores para fins de impostos e de envio pelo vendedor, somente em caso de necessidade. Esses sete requisitos incluem políticas sobre retenção de dados, governança, criptografia, registro e gerenciamento de vulnerabilidades.

Aplicativos bem arquitetados devem implantar controles de segurança que se enquadram em cinco categorias amplas especificadas no Pilar de segurança do AWS Well-Architected Framework. Embora o uso da AWS não seja um requisito para atingir esses controles de segurança, as cinco categorias do Pilar de segurança fornecem uma estrutura para verificar as arquiteturas de implementação da SP-API. Para referência, essas cinco categorias são:

  • Gerenciamento de identidade e acesso
  • Detecção
  • Proteção de infraestrutura
  • Proteção de dados
  • Resposta a incidentes

Se um aplicativo implantar um ou mais controles de segurança nessas cinco categorias, é provável que o aplicativo atenda aos critérios definidos na Política de proteção de dados da Amazon.

As seções a seguir analisam 10 controles de segurança principais baseados nas cinco categorias do Pilar de segurança do AWS Well Architected Framework.

Gerenciamento de senhas

Esse controle está relacionado à política de gerenciamento de acesso e gerenciamento de senhas em "Requisitos gerais de segurança". Credenciais e dados pessoais estão entre os tipos de dados mais procurados e roubados. Os agentes externos estão buscando credenciais que possam ser aproveitadas para acessar posteriormente e roubar dados de ativos como bancos de dados, servidores e armazenamento de laptop da equipe. Sem dúvida, a motivação para extrair credenciais de usuários se deve a oportunidades financeiras. Os agentes externos e internos podem aproveitar as credenciais obtidas ilegalmente e ilicitamente para expandir sua meta de acessar o sistema e obter as IIP do cliente ou dados de pagamento.

Como abordar: Os desenvolvedores devem implementar as seguintes configurações de complexidade de senha para melhorar a proteção contra Ataques de senha de força bruta:

👍

Os desenvolvedores precisam habilitar a complexidade da senha e especificar um tamanho mínimo de senha de 8 caracteres e uma combinação de letras maiúsculas, minúsculas, números e caracteres especiais. A expiração da senha deve ser definida para 90 dias. É recomendável implementar os seguintes controles de senha: Idade mínima da senha de 1 dia, número tentativas consecutivas de login inválidas devem ser definido como 4 antes do bloqueio automático da conta/nó até a liberação por um administrador ou automaticamente após 24 horas. O empo limite de inatividade da sessão/inicialização do protetor de tela deve ser definido como 5 minutos de inatividade.

Os desenvolvedores que executam o AWS Directory Services podem definir as configurações de complexidade de senha usando o Gerenciamento de senha para usuários do IAM. Os administradores do Microsoft Active Directory podem habilitar a Complexidade da senha nas políticas de grupo. Além disso, a Autenticação multifator (MFA) é um controle técnico de segurança necessário que pode oferecer resiliência contra ataques de senha de força bruta. Por fim, certifiquese de aplicar o conceito de Privilégio mínimo para contas de usuários e serviços.

Gerenciamento de vulnerabilidades

Esse controle está relacionado à política de gerenciamento de vulnerabilidades em "Requisitos adicionais de segurança" especificados na Política de proteção de dados da Amazon. Quando um agente mal intencionado consegue obter acesso a um sistema de computação, muitas vezes por meio de credenciais roubadas ou ataque da força bruta, um software malware pode ser instalado. Softwares que podem ser instalados ilicitamente incluem Ransomware, Remote Access Trojan (RAT), e Keystroke Logging. No caso do software RAT e Keystroke Logging, um agente remoto pode capturar nomes de usuário, senhas e informações de pagamento remotamente sem o conhecimento do usuário no sistema comprometido.
No caso do software de RAT e Keystroke Logging, um agente remoto pode capturar nomes de usuário, senhas e informações de pagamento remotamente sem o conhecimento do usuário no sistema comprometido.

Como abordar: Os desenvolvedores podem contratar uma empresa terceirizada especializada em verificação de vulnerabilidades e testes de penetração para realizar avaliações. Como alternativa, os desenvolvedores podem executar o Kali Linux, o Nessus e o Burp Suite para realizar os seus próprios testes. Integradores podem consultar a lista de ferramentas de vulnerabilidades na OWASP. Testes em relação à infraestrutura externa e interna são necessários, como servidores web front-end e servidores de banco de dados internos. Observe que os desenvolvedores precisam executar testes de vulnerabilidade pelo menos a cada 180 dias.

👍

Os desenvolvedores devem criar e manter um plano e/ou um runbook para detectar e corrigir vulnerabilidades. Os desenvolvedores devem proteger o hardware físico que contém IIP contra vulnerabilidades técnicas executando varreduras de vulnerabilidade e corrigindo adequadamente. Os desenvolvedores devem realizar varreduras de vulnerabilidade ou penetração pelo menos a cada 180 dias e verificar se há vulnerabilidades de código antes de cada lançamento. Além disso, os desenvolvedores devem controlar as alterações no hardware de armazenamento testando, verificando alterações, aprovando as alterações e restringindo o acesso a quem pode executar essas ações.

Criptografia e armazenamento

Esse controle está relacionado à política de criptografia em repouso em "Requisitos adicionais de segurança" especificados na Política de proteção de dados da Amazon. O conceito básico é que uma vez que os desenvolvedores entendam a sensibilidade dos dados com os quais estão trabalhando, o nível adequado de criptografia pode ser aplicado sempre que for pertinente.

Como abordar: Os desenvolvedores devem realizar um inventário dos diversos mecanismos de armazenamento de dados, como bancos de dados, armazenamentos de objetos como o Amazon Simple Storage Service (S3) e armazenamentos de arquivos que armazenam dados de informações de identificação pessoal (IIP). Todos os mecanismos de armazenamento que mantêm ou armazenam dados de IIP devem criptografar os dados em repouso com o padrão de práticas recomendadas do setor, conforme especificado na DPP. Por exemplo, as máquinas virtuais do Amazon EC2 com volumes do Amazon EBS podem ser criptografadas. Bancos de dados gerenciados e discos de laptop de funcionários também exigem criptografia de disco para proteger os dados em repouso. As políticas de laptop dos funcionários podem ser aplicadas e mantidas usando ferramentas para segurança de endpoint. Qualquer chave de criptografia usada precisa ser alternada pelo menos uma vez por ano e armazenada com segurança.
Os desenvolvedores devem criptografar todas as IIP inativas (por exemplo, quando os dados são persistidos) usando padrões de práticas recomendadas do setor (por exemplo, usando AES-128, AES256 ou RSA com tamanho de chave de 2048 bits ou superior). Os materiais criptográficos (por exemplo, chaves de criptografia/descriptografia) e recursos criptográficos (por exemplo, daemons que implementam módulos confiáveis de plataforma virtual e que fornecem APIs de criptografia/descriptografia) usados para criptografia de IIP inativa devem estar acessíveis somente aos processos e serviços dos desenvolvedores.

👍

Os desenvolvedores devem criptografar todas as IIP inativas (por exemplo, quando os dados são persistidos) usando padrões de práticas recomendadas do setor (por exemplo, usando AES-128, AES256 ou RSA com tamanho de chave de 2048 bits ou superior). Os materiais criptográficos (por exemplo, chaves de criptografia/descriptografia) e recursos criptográficos (por exemplo, daemons que implementam módulos confiáveis de plataforma virtual e que fornecem APIs de criptografia/descriptografia) usados para criptografia de IIP inativa devem estar acessíveis somente aos processos e serviços dos desenvolvedores.

Controles de mídia removível

Esse controle está relacionado à política de gerenciamento de ativos em "Requisitos adicionais de segurança" especificados na Política de proteção de dados da Amazon. Os dispositivos USB podem armazenar uma grande quantidade de dados e a segurança nesses dispositivos USB pode ser relaxada ou inexistente. Dispositivos USB podem ser roubados ou extraviados e perdidos. O papel impresso com IIP pode ser extraviado. Por fim, os dados de IIP armazenados em aplicativos de nuvem pública e não seguros podem cair nas mãos de pessoas mal-intencionadas.

Como abordar: Os desenvolvedores devem implementar controles que proíbam o armazenamento de dados de IIP em dispositivos de mídia removíveis e sistemas de armazenamento públicos não seguros. Você pode alcançar essa abordagem desativando ou bloqueando portas USB e restringindo o acesso da organização para armazenar IIP em sistemas de arquivos públicos. Além disso, os desenvolvedores podem evitar imprimir materiais com IIP e configurar mecanismos de disposição seguros, como caixas de trituração para documentos impressos.

👍

Os desenvolvedores não devem armazenar IIP em mídia removível (por exemplo, USB) ou aplicativos de nuvem pública não protegidos (por exemplo, links públicos disponibilizados pelo Google Drive). Os desenvolvedores devem descartar com segurança quaisquer documentos impressos que contenham IIP.

Criptografia de dados em repouso

Esse controle está relacionado ao controle de segurança de criptografia em repouso em "Requisitos adicionais de segurança" especificados na Política de proteção de dados da Amazon. Usando um documento de classificação de dados, os desenvolvedores podem prosseguir com o conhecimento para identificar quais sistemas e volumes devem ser criptografados em repouso. Por exemplo, as máquinas virtuais do Amazon EC2 que armazenam dados de IIP devem ter volumes do EBS criptografados para proteger dados confidenciais. Bancos de dados gerenciados e discos de laptop de funcionários também exigem criptografia de disco para proteger os dados em repouso.

Como abordar: Usando o conhecimento organizado em um documento de classificação de dados, os desenvolvedores devem habilitar a criptografia de disco para proteger os dados quando aplicável, incluindo laptops, servidores, bancos de dados e armazenamento de backup. Além de criptografar dados, todas as chaves da API do vendedor devem ser mantidas seguras e criptografadas. As chaves de API não devem ser expostas em e-mails ou permanecer na documentação em texto simples.

👍

Os desenvolvedores devem criptografar todas as IIP inativas (por exemplo, quando os dados são persistidos) usando padrões de práticas recomendadas do setor (por exemplo, usando AES-128, AES256 ou RSA com tamanho de chave de 2048 bits ou superior). Os materiais criptográficos (por exemplo, chaves de criptografia/descriptografia) e recursos criptográficos (por exemplo, daemons que implementam módulos confiáveis de plataforma virtual e que fornecem APIs de criptografia/descriptografia) usados para criptografia de IIP inativa devem estar acessíveis somente aos processos e serviços do desenvolvedor.

Processos de destruição e retenção de dados

Esse controle está relacionado à política de retenção de dados em "Requisitos adicionais de segurança" especificados na Política de proteção de dados da Amazon. Os desenvolvedores podem reter os dados de IIP criptografados para fins legais e fiscais. Quando os dados de IIP não forem mais necessários para cumprir os requisitos legais, os dados de IIP devem ser apagados.

Como abordar: Os desenvolvedores podem limpar os dados relacionados às IIP, como nome/ID/endereço do cliente e assim por diante, do cache ativo ou do armazenamento criptografado de arquivamento se a acessibilidade for exigida além de 30 dias por lei. Muitos desenvolvedores lutam para cumprir essa política porque muitas vezes armazenam as informações completas de IIP em vez das informações que não são IIP e são realmente exigidas por seu caso de uso, como totais de pedidos, código postal de 5 dígitos usado para cálculo de impostos e assim por diante.

👍

Os desenvolvedores manterão a IIP somente enquanto for necessário para fins de entrega de pedidos (não mais de 30 dias após o envio do pedido), ou para calcular/remeter impostos. Se um desenvolvedor for obrigado por lei a reter cópias de arquivo de IIP para fins fiscais ou regulamentares semelhantes, as IIP devem ser armazenadas como um backup criptografado “frio” ou offline, por exemplo, não disponível para uso imediato ou interativo.

Controles antimalware

Esse controle está relacionado à política de proteção de rede em "Requisitos gerais de segurança" especificados na Política de proteção de dados da Amazon. O malware geralmente é instalado por um agente externo. O malware enviado por email é o segundo método mais comum de entrega de software malicioso a um sistema de destino. Por exemplo, o malware pode ser instalado quando os usuários estão visitando um site comprometido. Se o computador ou o sistema que os usuários estiverem usando não executar um antivírus atualizado, o sistema pode ficar vulnerável.

Como abordar: os desenvolvedores devem aplicar a segmentação de rede em infraestruturas de rede na nuvem e no local. Por exemplo, use regras de filtragem de firewall para segmentar sub-redes e redes em ambientes na nuvem e no local. Os desenvolvedores devem implantar e manter antivírus atualizado em servidores e endpoints. Instale firewalls de rede e aplicativos para proteger servidores web externos. Adote e mantenha uma estrutura de ciclo de vida de desenvolvimento de software (SDLC) para que testes de segurança seja implementado e integrado desde a fase inicial do projeto. Implante um sistema de gerenciamento de segurança e gerenciamento de informações e uma solução contra ameaças persistentes avançadas, quando aplicável.

👍

Os desenvolvedores devem implementar controles de proteção de rede (por exemplo, subrede/grupos de segurança da AWS VPC, firewalls de rede) para negar acesso a endereços IP não autorizados, e o acesso público deve ser restrito somente a usuários aprovados. Os desenvolvedores devem implementar um software antivírus e antimalware nos dispositivos do usuário final. Os desenvolvedores devem restringir o acesso público somente a usuários aprovados.

Procedimentos de gerenciamento de incidente

Esse controle está relacionado à política do Plano de Resposta a Incidentes em "Requisitos Gerais de Segurança" especificados na Política de proteção de dados da Amazon. Os planos de gerenciamento de incidentes e respostas (plano de IR) incluem uma metodologia e uma estrutura que ajudam as organizações a identificar e implementar procedimentos proativos e reativos para proteger a API dos Serviços da Amazon. As fases de um plano de gerenciamento e incidente que os desenvolvedores devem considerar incluem as seções Preparação, Identificação, Contenção, Erradicação, Recuperação e Lições aprendidas.

Como abordar: Os desenvolvedores devem notificar a Amazon dentro de 24 horas após um incidente em [email protected]. O Plano de Resposta a Incidentes (IR) deve ser aprovado por um gerente sênior. Revise o plano de RI pelo menos a cada 6 meses.

👍

Os desenvolvedores devem criar e manter um plano e/ou runbook para detectar e lidar com incidentes de segurança.

Revisão de acesso

Esse controle está relacionado à política de gerenciamento de acesso em "Requisitos gerais de segurança" especificados na Política de proteção de dados da Amazon. A expectativa da política de Revisão de acesso é estabelecer um processo de revisão periódica para garantir o conceito de Privilégio Mínimo. Revise as contas de usuário e serviço que não são mais necessárias e exclua contas inativas.

Como abordar: Os desenvolvedores devem desenvolver uma documentação da política de gerenciamento de senhas. Inclua neste documento o conceito de privilégio mínimo e avaliação de contas de usuário inativas e contas de serviço que devem ser desativadas e excluídas. O processo de revisão de acesso deve ocorrer pelo menos trimestralmente.

👍

Os desenvolvedores devem implementar mecanismos de linha de base para garantir que, em todos os momentos, apenas as contas de usuário necessárias acessem as Informações da Amazon. Os desenvolvedores devem revisar a lista de pessoas e serviços com acesso às informações da Amazon regularmente (pelo menos a cada trimestre) e remover contas que não precisam mais de acesso.

Identificação de possíveis incidentes

Esse controle está relacionado à política de registro e monitoramento em "Requisitos gerais de segurança" especificados na Política de proteção de dados da Amazon. Os usuários que forem fisgados em ataques de phishing raramente conseguem perceber que estão com o sistema comprometido. Os ataques podem ser lançados contra servidores web na forma de negação de serviço distribuída (DDoS) contra a rede e os aplicativos. Os funcionários podem ter sistemas comprometidos por malware. Portanto, os sistemas de monitoramento são essenciais para detectar e notificar usuários comprometidos por meio de engenharia social ou outros métodos.

Como abordar: Implante um sistema de monitoramento e detecção para todos os ativos de dados aplicáveis, como um sistema SIEM ou um sistema de Intrusão e Prevenção. O requisito é manter os registros de segurança retidos por pelo menos 90 dias.

👍

Os desenvolvedores devem reunir registros para detectar eventos relacionados à segurança que afetam os seus aplicativos e sistemas, incluindo sucesso ou falha do evento, data e hora, tentativas de acesso, alterações de dados e erros do sistema. Os desenvolvedores devem implementar esse mecanismo de registro de log em todos os canais (por exemplo, APIs de serviço, APIs de camada de armazenamento, painéis administrativos) que fornecem acesso às Informações da Amazon. Todos os logs devem ter controles de acesso para evitar qualquer acesso autorizado e adulteração ao longo de sua vida útil. Os registros não devem conter IIP, a menos que as IIP sejam necessárias para atender aos requisitos legais, incluindo requisitos fiscais ou regulamentares. Os registros devem ser mantidos por pelo menos 90 dias para referência no caso de um incidente de segurança. Os desenvolvedores devem criar mecanismos para monitorar os logs e todas as atividades do sistema para acionar alarmes investigativos de ações suspeitas (por exemplo, várias chamadas não autorizadas, volume de recuperação de dados, taxa de solicitação inesperadas e acesso a registros de dados da versão Canary). Os desenvolvedores devem implementar alarmes de monitoramento para detectar se as Informações são extraídas de seus limites protegidos. Os desenvolvedores devem investigar quando os alarmes de monitoramento são acionados e isso deve ser documentado no plano de resposta a incidentes do desenvolvedor.

Conclusão

Esta postagem do blog descreveu os principais controles de segurança nas implementações da API do Parceiro Vendedor e exemplos de ferramentas que podem ser consideradas ao aplicar a Política de proteção de dados da Amazon.

A Política de proteção de dados da Amazon estabelece os requisitos que os desenvolvedores precisam implementar para proteger os dados de IIP do cliente. A lista de questões analisadas acima não é limitada. Os desenvolvedores podem encontrar a Política de proteção de dados da Amazon neste link.

Sobre os autores:

Ronaldo N é arquiteto de soluções especializado em SIEM, nuvem e segurança de data center.
Anuj R é líder global na função de arquitetura de soluções da API do parceiro de vendas.