Share via

Solución de problemas de conectores de AWS S3

  • Artículo

El conector Amazon Web Services (AWS) S3 permite ingerir registros de servicio de AWS, recopilados en cubos de AWS S3, en Microsoft Sentinel. Los tipos de registros que se admiten actualmente son CloudTrail de AWS, VPC Flow Logs y GuardDuty de AWS.

En este artículo se describe cómo identificar rápidamente la causa de problemas que se producen con el conector de AWS S3 para que pueda encontrar los pasos necesarios para resolver los problemas.

Más información sobre Conexión de Microsoft Sentinel a Amazon Web Services para ingerir datos de registro del servicio AWS.

Microsoft Sentinel no recibe datos del conector de Amazon Web Services S3 ni de uno de sus tipos de datos

Los registros del conector de AWS S3 (o uno de sus tipos de datos) no son visibles en el área de trabajo de Microsoft Sentinel durante más de 30 minutos después de que se haya conectado el conector.

Antes de buscar una causa y una solución, revise estas consideraciones:

  • Pueden pasar entre 20 y 30 minutos desde que se conecta el conector hasta que los datos se ingieren en el área de trabajo.
  • El estado de conexión del conector indica que existe una regla de recopilación, no indica que se hayan ingerido datos. Si el estado del conector de Amazon Web Services S3 es verde, hay una regla de recopilación para uno de los tipos de datos, pero todavía no hay datos.

Determinar la causa del problema

En esta sección, tratamos estas causas:

  1. Las directivas de permisos del conector de AWS S3 no se establecen correctamente.
  2. Los datos no se ingieren en el cubo S3 de AWS.
  3. Amazon Simple Queue Service (SQS) en la nube de AWS no recibe notificaciones del cubo S3.
  4. Los datos no se pueden leer desde SQS/S3 en la nube de AWS. Con los registros de GuardDuty, el problema se debe a permisos KMS incorrectos.

Causa 1: Las directivas de permisos del conector de AWS S3 no se establecen correctamente

Este problema se debe a permisos incorrectos en el entorno de AWS.

Creación de directivas de permisos

Necesita directivas de permisos para implementar el conector de datos de AWS S3. Revise los permisos necesarios y establezca los permisos pertinentes.

Causa 2: Los datos pertinentes no existen en el cubo de S3

Los registros pertinentes no existen en el cubo de S3.

Solución: Busque registros y exporte registros si es necesario

  1. En AWS, abra el cubo de S3, busque la carpeta correspondiente según los registros necesarios y compruebe si hay archivos de registros dentro de la carpeta.
  2. Si los datos no existen, hay un problema con la configuración de AWS. En este caso, debe configurar un servicio de AWS para exportar registros a un cubo de S3.

Causa 3: Los datos de S3 no llegaron a SQS

Los datos no se transfirieron correctamente de S3 a SQS.

Solución: Compruebe que los datos llegaron y configure las notificaciones de eventos

  1. En AWS, abra el SQS correspondiente.
  2. En la pestaña Supervisión, debería ver el tráfico en el widget Número de mensajes enviados. Si no hay tráfico en SQS, hay un problema de configuración de AWS.
  3. Asegúrese de que la definición de notificaciones de eventos para SQS incluye los filtros de datos correctos (prefijo y sufijo).
    1. Para ver las notificaciones de eventos en el cubo de S3, seleccione la pestaña Propiedades y, después, encuentre la sección Notificaciones de eventos.
    2. Si no puede ver esta sección, créela.
    3. Asegúrese de que SQS tiene las directivas pertinentes para obtener los datos del cubo de S3. SQS debe contener esta directiva en la pestaña Directiva de acceso.

Causa 4: SQS no leyó los datos

SQS no leyó correctamente los datos S3.

Solución: Compruebe que SQS lee los datos

  1. En AWS, abra el SQS correspondiente.

  2. En la pestaña de Supervisión, debería ver el tráfico en los widgets Número de mensajes eliminados y Número de mensajes recibidos.

  3. Un pico de datos no es suficiente. Espere hasta que haya suficientes datos (varios picos) y compruebe si hay problemas.

  4. Si al menos uno de los widgets está vacío, compruebe los registros de estado mediante la ejecución de esta consulta:

    SentinelHealth 
| where TimeGenerated > ago(1d)
| where SentinelResourceKind in ('AmazonWebServicesCloudTrail', 'AmazonWebServicesS3')
| where OperationName == 'Data fetch failure summary'
| mv-expand TypeOfFailureDuringHour = ExtendedProperties["FailureSummary"]
| extend StatusCode = TypeOfFailureDuringHour["StatusCode"]
| extend StatusMessage = TypeOfFailureDuringHour["StatusMessage"]
| project SentinelResourceKind, SentinelResourceName, StatusCode, StatusMessage, SentinelResourceId, TypeOfFailureDuringHour, ExtendedProperties

  5. Asegúrese de que la función de estado se ha habilitado:

    SentinelHealth 
| take 20

  6. Si la característica de mantenimiento no está habilitada, habilitela.

Los datos del conector AWS S3 (o uno de sus tipos de datos) se ven en Microsoft Sentinel con un retraso de más de 30 minutos

Este problema suele producirse cuando Microsoft no puede leer archivos en la carpeta S3. Microsoft no puede leer los archivos porque están cifrados o en el formato incorrecto. En estos casos, muchos reintentos provocarán un retraso en la ingesta.

Determinar la causa del problema

En esta sección, tratamos estas causas:

  • El cifrado de registros no está configurado correctamente
  • Las notificaciones de eventos no se definen correctamente
  • Errores de mantenimiento o estado deshabilitado

Causa 1: El cifrado de registros no está configurado correctamente

Si los registros están totalmente o parcialmente cifrados por el Servicio de administración de claves (KMS), Es posible que Microsoft Sentinel no tenga permiso para que este KMS descifre los archivos.

Solución: Comprobación del cifrado de registros

Asegúrese de que Microsoft Sentinel tiene permiso para que este KMS descifre los archivos. Revise los permisos de KMS necesarios para los registros de GuardDuty y CloudTrail.

Causa 2: Las notificaciones de eventos no están configuradas correctamente

Al configurar una notificación de eventos de Amazon S3, debe especificar a qué tipos de eventos admitidos de Amazon S3 debe enviar la notificación. Si existe un tipo de evento que no especificó en el cubo de Amazon S3, Amazon S3 no envía la notificación.

Solución: Compruebe que las notificaciones de eventos están definidas correctamente

Para comprobar que las notificaciones de eventos de S3 a SQS están definidas correctamente, compruebe que:

  • La notificación se define desde la carpeta específica que incluye los registros y no desde la carpeta principal que contiene el cubo.
  • La notificación se define con el sufijo .gz. Por ejemplo:

Causa 3: Errores de mantenimiento o estado deshabilitado

Es posible que haya errores en los registros de estado o que la característica de mantenimiento no esté habilitada.

Solución: compruebe que no hay errores en los registros de estado y habilite el estado

  1. Compruebe que no hay ningún error en los registros de estado mediante la ejecución de esta consulta:

    SentinelHealth
| where TimeGenerated between (ago(startTime)..ago(endTime))
| where SentinelResourceKind  == "AmazonWebServicesS3"
| where Status != "Success"
| distinct TimeGenerated, OperationName, SentinelResourceName, Status, Description

  2. Asegúrese de que la función de estado se ha habilitado:

    SentinelHealth 
| take 20

  3. Si la característica de mantenimiento no está habilitada, habilitela.

Pasos siguientes

En este artículo, ha aprendido a identificar rápidamente las causas y a resolver problemas comunes con el conector AWS S3.

Agradecemos cualquier comentario, sugerencias, peticiones de características, informes de errores o mejoras y adiciones. Vaya al repositorio de Microsoft Sentinel en GitHub para abrir una incidencia, crear una bifurcación o cargar una contribución.