Guía para abordar los controles de seguridad clave en la integración de la SP-API

Este documento técnico destaca diez controles de seguridad clave que los desarrolladores deben abordar al integrarse con la API de Selling Partner y correlaciona estos controles con la disposición de la Política de protección de datos (DPP) de Amazon aplicable.

Los desarrolladores e integradores que crean soluciones para integrarse con Amazon Selling Partner API (SP-API) deben asegurarse de que sus soluciones y aplicaciones cumplan con la Política de protección de datos (DPP) . Los desarrolladores deben mantener controles de tecnología adecuados para verificar el cumplimiento de la Política de protección de datos cuando se auditan. Los desarrolladores pueden usar la información de este documento técnico para complementar y mejorar la postura de seguridad de sus aplicaciones.

Sobre la Política de Protección de Datos (DPP)

Sobre la Política de Protección de Datos (DPP)

La Política de Protección de Datos (DPP) contiene dos categorías relacionadas con los requisitos de seguridad:

• Requisito general de seguridad: requisitos para todos los desarrolladores que crean aplicaciones SP-API. Estos requisitos incluyen pautas de mejores prácticas, como protección de red, gestión de acceso, política de contraseñas, cifrado y planes de respuesta a incidentes.
• Requisito de seguridad adicional: requisitos adicionales para los desarrolladores que realizan operaciones restringidas en SP-API que involucran información de identificación personal (PII). El acceso a la PII se otorga a los desarrolladores para impuestos seleccionados y fines de envío gestionados por el seller, solo de manera obligatoria. Estos requisitos incluyen políticas sobre retención de datos, gobierno, cifrado, registro y gestión de vulnerabilidades.

Las aplicaciones bien diseñadas deben implementar controles de seguridad que se clasifiquen en cinco amplias categorías especificadas en el pilar de seguridad del marco de buena arquitectura de AWS . Si bien no es necesario que utilice Amazon Web Services (AWS) para lograr estos controles de seguridad, las cinco categorías de pilares de seguridad brindan un marco para verificar las arquitecturas de implementación de SP-API. Como referencia, estas cinco categorías son

• Gestión de identidad y acceso
• Detección
• Protección de infraestructura
• Protección de Datos
• Respuesta al incidente

Si una aplicación implementa uno o más controles de seguridad en estas cinco categorías, es probable que la aplicación cumpla con los criterios definidos en la Política de protección de datos.

Las siguientes secciones analizan diez controles de seguridad clave basados en las cinco categorías del Pilar de seguridad del marco de buena arquitectura de AWS.

1. Gestión de Credenciales

e relaciona con la política de administración de credenciales en "Requisitos generales de seguridad". Las credenciales y los datos personales se encuentran entre los tipos de datos robados más buscados. Los actores externos que obtienen credenciales pueden usarlas más adelante para acceder y robar datos de activos como bases de datos, servidores y almacenamiento de computadoras portátiles del personal. Según el reporte de investigaciones de violación de datos de Verizon de 2021 , la motivación para extraer las credenciales de los usuarios se debe, con mucho, a las oportunidades financieras. Los actores externos e internos pueden utilizar las credenciales obtenidas de forma ilegal e ilícita para ampliar su objetivo de acceder al sistema y obtener información de identificación personal o de pago del cliente. Una forma de acceder a las credenciales es a través de ataques de contraseña de fuerza bruta . Con este tipo de ataque, las combinaciones de contraseñas se intentan varias veces hasta que se encuentra una coincidencia de contraseña exitosa.

Los desarrolladores deben implementar la siguiente configuración de complejidad de contraseña para mejorar la protección contra los ataques de contraseña de fuerza bruta :

Los desarrolladores deben establecer requisitos mínimos de contraseña para el personal y los sistemas con acceso a la Información. Los requisitos de la contraseña deben tener un mínimo de doce (12) caracteres, no incluir ninguna parte del nombre del usuario, combinación de letras mayúsculas, minúsculas, números y caracteres especiales, incluidos los requisitos mínimos para cada uno. Los desarrolladores deben establecer una antigüedad mínima de la contraseña de 1 día y una caducidad máxima de la contraseña de 365 días para todos los usuarios. Los desarrolladores deben asegurarse de que se requiera la autenticación multifactor (MFA) para todas las cuentas de usuario. El desarrollador debe asegurarse de que las claves API proporcionadas por Amazon estén encriptadas y solo los empleados requeridos tengan acceso a ellas.

Cómo abordar: los desarrolladores que ejecutan AWS Directory Service pueden establecer configuraciones de complejidad de contraseña mediante la administración de contraseñas para usuarios de IAM. Los administradores de Microsoft Active Directory pueden habilitar la complejidad de la contraseña en las políticas de grupo . La autenticación multifactor (MFA) es un control de seguridad técnico requerido que puede ofrecer resiliencia contra los ataques de contraseña de fuerza bruta. Finalmente, asegúrese de aplicar el concepto de privilegio mínimo para las cuentas de usuario y de servicio.

2. Gestión de vulnerabilidades

se relaciona con la política de gestión de vulnerabilidades en "Requisitos de seguridad adicionales" especificados en la Política de protección de datos de Amazon. Cuando un mal actor logra obtener acceso a un sistema informático, a menudo a través de credenciales robadas o ataques de fuerza bruta, el mal actor también puede instalar software malicioso. El software que se puede instalar de forma ilícita incluye ransomware, troyano de acceso remoto (RAT) y registro de pulsaciones de teclas. En el caso de RAT y software de registro de pulsaciones de teclas, un actor remoto puede capturar nombres de usuario, contraseñas e información de pago de forma remota sin el conocimiento del usuario en el sistema comprometido.

Cómo abordar: los desarrolladores pueden realizar sus propias pruebas ejecutando Kali Linux , Nessus y Burp Suite o contratar a una empresa externa especializada en análisis de vulnerabilidades y pruebas de penetración para realizar evaluaciones. Las pruebas contra la infraestructura externa e interna son necesarias, como servidores web front-end y servidores de bases de datos internas. Puede encontrar una lista de herramientas de exploración de vulnerabilidades de aplicaciones web en OWASP.org . Tenga en cuenta que los desarrolladores deben ejecutar pruebas de vulnerabilidad al menos cada 180 días. Antes de ejecutar pruebas de vulnerabilidad en los servicios de AWS, consulte la guía de pruebas de penetración para obtener una lista de las pruebas y consideraciones permitidas.

Los desarrolladores deben crear y mantener un plan y/o runbook para detectar y remediar las vulnerabilidades. Los desarrolladores deben proteger el hardware físico que contiene PII de las vulnerabilidades técnicas mediante la realización de análisis de vulnerabilidades y la reparación adecuada. Los desarrolladores deben realizar escaneos de vulnerabilidades al menos cada 180 días, pruebas de penetración al menos cada 365 días y escanear el código en busca de vulnerabilidades antes de cada lanzamiento. Además, los desarrolladores deben controlar los cambios en el hardware de almacenamiento probando, verificando los cambios, aprobando los cambios y restringiendo el acceso a quienes pueden realizar esas acciones. El desarrollador debe tener procedimientos y planes apropiados para restaurar la disponibilidad y el acceso a la PII de manera oportuna en caso de un incidente físico o técnico.

3. Gestión de activos

Este control se relaciona con la política de gestión de activos en "Requisitos de seguridad adicionales" especificados en la Política de protección de datos de Amazon. Los dispositivos extraíbles pueden almacenar una gran cantidad de datos y la seguridad en esos dispositivos extraíbles puede ser relajada o inexistente. Los dispositivos extraíbles pueden ser robados o extraviados y perdidos. El papel impreso con información PII se puede extraviar. Los datos PII almacenados en aplicaciones de nube pública y no seguras pueden caer en manos de malos actores.

Cómo abordar: los desarrolladores deben realizar un inventario de los diversos mecanismos de almacenamiento de datos, como bases de datos, almacenes de objetos como Amazon Simple Storage Service (Amazon S3) y almacenes de archivos que almacenan datos de información de identificación personal (PII). Todos los mecanismos de almacenamiento que retienen o almacenan datos de PII deben cifrar los datos en reposo con el estándar de mejores prácticas de la industria como se especifica en el DPP. Por ejemplo, las máquinas virtuales de Amazon EC2 con volúmenes de Amazon Elastic Block Store (Amazon EBS) se pueden cifrar. Las bases de datos administradas y los discos de las computadoras portátiles de los empleados también requieren el cifrado del disco para proteger los datos en reposo. Las políticas de portátiles de los empleados se pueden aplicar y mantener utilizando herramientas para la seguridad de los terminales. Cualquier clave de cifrado utilizada debe rotarse al menos una vez al año y almacenarse de forma segura.

Los desarrolladores deben mantener una configuración estándar de referencia para el sistema de información y mantener un inventario de software y activos físicos (por ejemplo, computadoras y dispositivos móviles) con acceso a PII y actualización trimestral. Los activos físicos que almacenan, procesan o manejan PII deben cumplir con todos los requisitos establecidos en esta política. Los desarrolladores no deben almacenar PII en medios extraíbles, dispositivos personales o aplicaciones de nube pública no seguras (por ejemplo, enlaces públicos disponibles a través de Google Drive) a menos que esté encriptada con claves de al menos AES-128 o RSA-2048 o superior. Los desarrolladores deben desechar de manera segura cualquier documento impreso que contenga PII. El desarrollador debe implementar controles de prevención de pérdida de datos (DLP) para monitorear y detectar el movimiento no autorizado de datos.

4. Cifrado de datos en reposo

Este control se relaciona con el control de seguridad de Cifrado en reposo en "Requisitos de seguridad adicionales" especificados en la Política de protección de datos de Amazon. El documento técnico de clasificación de datos proporciona a los desarrolladores una guía para identificar qué sistemas y volúmenes deben cifrarse en reposo. Por ejemplo, las máquinas virtuales de Amazon EC2 que almacenan datos PII deben tener volúmenes de Amazon EBS cifrados para proteger los datos confidenciales. Las bases de datos administradas y los discos de las computadoras portátiles de los empleados también requieren el cifrado del disco para proteger los datos en reposo.

Cómo abordar: los desarrolladores deben crear su propio documento de clasificación de datos para identificar los datos que requieren cifrado de disco para proteger la información, incluidas las unidades de dispositivos finales, servidores, bases de datos y almacenamiento de respaldo. Además de cifrar los datos, todas las claves SP-API deben mantenerse seguras y cifradas. Las claves API no deben exponerse en correos electrónicos ni permanecer en la documentación en texto sin formato.

Los desarrolladores deben cifrar toda la PII en reposo utilizando al menos AES-128 o RSA con un tamaño de clave de 2048 bits o superior. Los materiales criptográficos (por ejemplo, claves de cifrado/descifrado) y las capacidades criptográficas (por ejemplo, demonios que implementan Módulos virtuales de plataforma segura y proporcionan API de cifrado/descifrado) utilizados para el cifrado de PII en reposo solo deben ser accesibles para los procesos y servicios del desarrollador.

5. Procesos de retención de datos

Este control se relaciona con la política de retención de datos en "Requisitos de seguridad adicionales" especificados en la Política de protección de datos de Amazon. Los desarrolladores pueden retener los datos de PII encriptados con fines legales y fiscales. Una vez que los datos de PII ya no sean necesarios para cumplir con los requisitos legales, los datos de PII deben borrarse. Muchos desarrolladores luchan por cumplir con esta política porque a menudo almacenan la información PII completa en lugar de la información que no es PII que realmente requiere su caso de uso, como los totales de los pedidos, el código postal de 5 dígitos utilizado para el cálculo de impuestos, etc.

Cómo abordar: los desarrolladores pueden eliminar los datos relacionados con la PII, como el nombre del cliente, la identificación, la dirección, etc., de la memoria caché activa, o si la ley exige el acceso a estos datos más allá de los 30 días, los desarrolladores pueden archivar los datos relacionados con la PII en forma cifrada. almacenamiento.

Los desarrolladores conservarán la PII por no más de 30 días después de la entrega del pedido y solo con el propósito de (i) cumplir con los pedidos, (ii) calcular y remitir impuestos, (iii) generar facturas de impuestos y otros documentos requeridos, y (iv) cumplir con los requisitos legales, incluidos los requisitos fiscales o reglamentarios. Los desarrolladores pueden conservar los datos durante más de 30 días después de la entrega del pedido solo si así lo exige la ley y solo con el fin de cumplir con esa ley. Según las secciones 1.5 ("Cifrado en tránsito") y 2.4 ("Cifrado en reposo") en ningún momento se debe transmitir o almacenar la PII sin protección.

6. Controles antimalware

Este control se relaciona con la política de Protección de la red en los "Requisitos generales de seguridad" especificados en la Política de protección de datos de Amazon. El malware generalmente lo instala un actor externo. El malware enviado por correo electrónico es el segundo método más común de envío de software malicioso a un sistema de destino. Por ejemplo, se puede instalar malware cuando los usuarios visitan un sitio web comprometido. Las computadoras y los usuarios del sistema que no ejecutan un antivirus actualizado pueden crear vulnerabilidades en la red del sistema.

Cómo abordar: los desarrolladores deben aplicar la segmentación de red en infraestructuras de red locales y en la nube. Por ejemplo, use reglas de filtrado de firewall para segmentar subredes y redes tanto en entornos locales como en la nube. Los desarrolladores deben implementar y mantener un antivirus actualizado en servidores y puntos finales e instalar firewalls de red y aplicaciones para proteger los servidores web externos. Adopte y mantenga un marco de ciclo de vida de desarrollo de software (SDLC) para la integración de pruebas de seguridad y prácticas eficientes de administración de software en el proyecto. Implemente un sistema de administración de seguridad e información y una solución contra amenazas persistentes avanzadas cuando corresponda.

Los desarrolladores deben implementar controles de protección de red, incluidos cortafuegos de red y listas de control de acceso a la red para denegar el acceso a direcciones IP no autorizadas. Los desarrolladores deben implementar software de segmentación de red, antivirus y antimalware en los dispositivos de los usuarios finales. Los desarrolladores deben restringir el acceso público solo a los usuarios aprobados y realizar capacitación en protección de datos y seguridad de TI para todos los que tengan acceso al sistema.

7. Procedimientos de gestión de incidentes

Este control se relaciona con la política del Plan de respuesta a incidentes en los "Requisitos generales de seguridad" especificados en la Política de protección de datos de Amazon. Los planes de respuesta a incidentes (IR) incluyen una metodología y un marco que ayuda a las organizaciones a identificar e implementar procedimientos proactivos y reactivos para proteger la API de Amazon Services. Las fases de un plan de gestión e incidentes que los desarrolladores deben considerar incluyen secciones de preparación, identificación, contención, erradicación, recuperación y lecciones aprendidas.

Cómo abordar: los desarrolladores deben mantener un plan de respuesta a incidentes actualizado y asegurarse de que haya un proceso para notificar a Amazon dentro de las 24 horas de un incidente en [email protected] . El plan de respuesta a incidentes (IR) debe ser aprobado por un gerente senior y revisado al menos cada 6 meses.

Los desarrolladores deben tener un proceso de gestión y evaluación de riesgos que sea revisado anualmente por la alta gerencia del desarrollador, que incluye, entre otros, la evaluación de amenazas y vulnerabilidades potenciales, así como la probabilidad y el impacto para rastrear los riesgos conocidos. Los desarrolladores deben crear y mantener un plan y/o runbook para detectar y manejar incidentes de seguridad. Dichos planes deben identificar las funciones y responsabilidades de respuesta a incidentes, definir los tipos de incidentes que pueden afectar a Amazon, definir los procedimientos de respuesta a incidentes para los tipos de incidentes definidos y definir una ruta y procedimientos de escalamiento para escalar los incidentes de seguridad a Amazon.

8. Revisión de acceso

Este control se relaciona con la política de Gestión de acceso en los "Requisitos generales de seguridad" especificados en la Política de protección de datos de Amazon. La expectativa de la política de revisión de acceso es establecer un proceso de revisión periódica para garantizar que el concepto de revisión de cuentas de usuario y servicio ya no sea necesario y eliminar cuentas inactivas.

Cómo abordar: los desarrolladores deben crear documentación de política de administración de contraseñas. Esta documentación de política de administración de contraseñas debe establecer el requisito de privilegio mínimo para el acceso a la cuenta y proporcionar directivas sobre la revisión de permisos para cuentas de usuario y de servicio, incluso cuándo estas cuentas deben deshabilitarse y eliminarse. El proceso de revisión de acceso dentro de la política debe ocurrir al menos trimestralmente.

Los desarrolladores deben establecer un proceso de registro de acceso de usuario formal para asignar derechos de acceso para todos los tipos de usuarios y servicios asegurándose de que se asigne una identificación única a cada persona con acceso a la información por computadora. Los desarrolladores no deben crear ni utilizar credenciales de inicio de sesión o cuentas de usuario genéricas, compartidas o predeterminadas y evitar que las cuentas de usuario se compartan. Los desarrolladores deben implementar mecanismos de referencia para garantizar que, en todo momento, solo las cuentas de usuario requeridas accedan a la Información. Los desarrolladores deben restringir que los empleados y contratistas almacenen información en dispositivos personales. Los desarrolladores mantendrán y harán cumplir el "bloqueo de la cuenta" mediante la detección de patrones de uso anómalos y los intentos de inicio de sesión, y deshabilitando las cuentas con acceso a la Información. Los desarrolladores deben revisar la lista de personas y servicios con acceso a la Información al menos trimestralmente. Los desarrolladores deben asegurarse de que el acceso se deshabilite y/o elimine dentro de las 24 horas para los empleados despedidos.

9. Identificación de Incidentes Potenciales

Este control se relaciona con la política de registro y monitoreo en los "Requisitos generales de seguridad" especificados en la Política de protección de datos de Amazon. Los usuarios que han sido objeto de ataques de phishing rara vez pueden darse cuenta de que tienen un sistema comprometido. Se pueden lanzar ataques contra servidores web en forma de denegación de servicio distribuido (DDoS) contra la red y las aplicaciones. Los empleados pueden tener sistemas comprometidos por malware. Por lo tanto, los sistemas de monitoreo son fundamentales para detectar y notificar a los usuarios comprometidos a través de la ingeniería social u otros métodos.

Cómo abordar: implementar un sistema de monitoreo y detección para todos los activos de datos aplicables, como un sistema SIEM o un sistema de detección y prevención de intrusiones . El requisito es conservar los registros de seguridad durante al menos 90 días.

Los desarrolladores deben recopilar registros para detectar eventos relacionados con la seguridad en sus aplicaciones y sistemas, incluido el éxito o el fracaso del evento, la fecha y la hora, los intentos de acceso, los cambios de datos y los errores del sistema. Los desarrolladores deben implementar este mecanismo de registro en todos los canales (por ejemplo, API de servicio, API de capa de almacenamiento, paneles administrativos) que brindan acceso a la información. Los desarrolladores deben revisar los registros en tiempo real (por ejemplo, la herramienta SIEM) o cada dos semanas. Todos los registros deben tener controles de acceso para evitar cualquier acceso no autorizado y manipulación a lo largo de su ciclo de vida. Los registros no deben contener PII a menos que la PII sea necesaria para cumplir con los requisitos legales, incluidos los impuestos o los requisitos reglamentarios. A menos que la ley aplicable exija lo contrario, los registros deben conservarse durante al menos 90 días como referencia en el caso de un Incidente de seguridad. Los desarrolladores deben crear mecanismos para monitorear los registros y todas las actividades del sistema para activar alarmas de investigación sobre acciones sospechosas (por ejemplo, múltiples llamadas no autorizadas, tasa de solicitudes inesperadas y volumen de recuperación de datos, y acceso a registros de datos controlados). Los desarrolladores deben implementar alarmas y procesos de monitoreo para detectar si la información se extrae o se puede encontrar más allá de sus límites protegidos. Los desarrolladores deben realizar una investigación cuando se activan las alarmas de monitoreo, y esto debe documentarse en el Plan de respuesta a incidentes del desarrollador.

Conclusión

Este documento técnico describió los controles de seguridad clave en las implementaciones de API de Selling Partner y ejemplos de herramientas que se pueden considerar al aplicar la Política de protección de datos.

La Política de protección de datos de Amazon establece los requisitos que los desarrolladores deben implementar para proteger los datos de PII de los clientes. La lista de cuestiones analizadas anteriormente no es exhaustiva. Para obtener más información, consulte la Política de protección de datos de Amazon .

Revisiones de documentos

Avisos

Los sellers y desarrolladores de Amazon son responsables de realizar su propia evaluación independiente de la información de este documento. Este documento: (a) es solo para fines informativos, (b) representa las prácticas actuales, que están sujetas a cambios sin previo aviso, y (c) no crea ningún compromiso ni garantía por parte de Amazon.com Services LLC (Amazon) y sus affiliates, suppliers, or licensors. Los productos o servicios de Amazon Marketplace Web Services (Amazon MWS) y Amazon Selling Partner API (Amazon SP-API) se proporcionan "tal cual" sin garantías, representaciones o condiciones de ningún tipo, ya sean expresas o implícitas. Las responsabilidades y obligaciones de Amazon con respecto a Amazon MWS y SP-API están controladas por los acuerdos MWS y SP-API de Amazon (incluido el Acuerdo de desarrollador de API de selling partner de Amazon o el Acuerdo de licencia de API de selling partner de Amazon), y este documento no es parte de, ni modifica ningún acuerdo entre Amazon y ninguna de las partes.

© 2022 Amazon.com Services LLC o sus afiliados. Reservados todos los derechos.