Corregir errores de Security Command Center

En esta página se incluye una lista de guías de referencia y técnicas para corregir errores de SCC.

Antes de empezar

Necesitas los roles de Gestión de Identidades y Accesos (IAM) adecuados para ver o editar las detecciones, así como para acceder a los recursos o modificarlos. Google Cloud Si se producen errores de permisos al acceder a Security Command Center en laGoogle Cloud consola, pide ayuda a tu administrador. Para obtener información sobre los roles, consulta Control de acceso. Para solucionar los errores de recursos, consulte la documentación de los productos afectados.

Revisar los resultados en la Google Cloud consola

Los errores de SCC son errores de configuración que impiden que Security Command Center funcione como debería. La fuente Security Command Center genera estas detecciones.

Siempre que Security Command Center esté configurado para tu organización o proyecto, generará resultados de error a medida que los detecte. Puedes ver los errores de SCC en la Google Cloud consola.

Siga este procedimiento para revisar los resultados en la consola de Google Cloud :

  1. En la Google Cloud consola, ve a la página Resultados de Security Command Center.

    Ir a Resultados

  2. Selecciona tu Google Cloud proyecto u organización.
  3. En la sección Filtros rápidos, en la subsección Nombre visible de la fuente, seleccione Security Command Center. Los resultados de la consulta de detecciones se actualizan para mostrar solo las detecciones de esta fuente.
  4. Para ver los detalles de un resultado específico, haga clic en su nombre en la columna Categoría. Se abre el panel de detalles del resultado y se muestra la pestaña Resumen.
  5. En la pestaña Resumen, consulta los detalles de la detección, incluida la información sobre lo que se ha detectado, el recurso afectado y, si está disponible, los pasos que puedes seguir para corregir la detección.
  6. Opcional: Para ver la definición JSON completa de la detección, haga clic en la pestaña JSON.

Desactivación de errores de SCC después de la corrección

Después de corregir un resultado de SCC error, Security Command Center cambia automáticamente el estado del resultado a INACTIVE durante el siguiente análisis. El tiempo que tarda Security Command Center en cambiar el estado de un hallazgo corregido a INACTIVE depende de cuándo corrijas el hallazgo y de la programación del análisis que detecte el error.

Para obtener información sobre la frecuencia de análisis de una SCC error, consulta el resumen de la detección de errores.

Corregir errores de SCC

En esta sección se incluyen instrucciones para corregir todos los errores de SCC.

API disabled

Nombre de la categoría en la API: API_DISABLED

Uno de los siguientes servicios está inhabilitado en el proyecto:

El servicio inhabilitado no puede generar resultados.

Para solucionar este problema, sigue estos pasos:

  1. Revisa el resultado para determinar qué API está inhabilitada.
  2. Habilita la API:

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

APS no resource value configs match any resources

Nombre de la categoría en la API: APS_NO_RESOURCE_VALUE_CONFIGS_MATCH_ANY_RESOURCES

Las configuraciones de valor de recursos se definen para las simulaciones de rutas de ataque, pero no coinciden con ninguna instancia de recurso de su entorno. Las simulaciones están usando el conjunto de recursos de alto valor predeterminado.

Es posible que las configuraciones de valores de recursos no coincidan con ningún recurso por los siguientes motivos, que se identifican en la descripción de la detección en la consolaGoogle Cloud :

  • Ninguna de las configuraciones de valor de recurso coincide con ninguna instancia de recurso.
  • Una o varias configuraciones de valores de recursos que especifican NONE anulan todas las demás configuraciones válidas.
  • Todas las configuraciones de valores de recursos definidos especifican el valor NONE.

Para solucionar este problema, sigue estos pasos:

  1. Ve a la página Simulación de ruta de ataque en Security Command Center Configuración:

    Ir a Ajustes

  2. Selecciona tu organización. Se abrirá la página Simulación de ruta de ataque con las configuraciones existentes.

  3. En la columna Valor del recurso de la lista Configuraciones de valor del recurso, compruebe si hay valores de None.

  4. En cualquier configuración que haya especificado None, haga lo siguiente:

    1. Haga clic en el nombre de cualquier configuración de valor de recurso para ver las especificaciones de la configuración.
    2. Si es necesario, edite las especificaciones de los atributos de recursos para reducir el número de instancias de recursos que coincidan con la configuración.
  5. Si el problema no se debe a una especificación None demasiado amplia, haz lo siguiente:

    1. Haga clic en los nombres de cada configuración que especifique un valor de HIGH, MEDIUM o LOW para ver las especificaciones de los atributos de recursos.
    2. Revise la configuración y, si es necesario, edítela para corregir el ámbito, el tipo de recurso, la etiqueta o la especificación de la etiqueta para que coincidan con los recursos previstos.
  6. Si es necesario, crea una configuración de valor de recurso.

Los cambios se aplicarán en la próxima simulación de ruta de ataque.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

APS resource value assignment limit exceeded

Nombre de la categoría en la API: APS_RESOURCE_VALUE_ASSIGNMENT_LIMIT_EXCEEDED

En la última simulación de ruta de ataque, el número de instancias de recursos de alto valor, según se ha identificado en las configuraciones de valor de los recursos, ha superado el límite de 1000 instancias de recursos en un conjunto de recursos de alto valor. Por lo tanto, Security Command Center ha excluido del conjunto de recursos de alto valor el número de instancias que excedía el límite.

Para solucionar este problema, puedes probar las siguientes acciones:

  • Usa etiquetas o etiquetas para reducir el número de coincidencias de un tipo de recurso concreto o dentro de un ámbito específico. Las etiquetas deben aplicarse a las instancias de recursos para que se puedan asociar a una configuración de valor de recurso.
  • Crea una configuración de valor de recurso que asigne un valor de recurso de NONE a un subconjunto de los recursos especificados en otra configuración.

    Si especificas el valor NONE, se anulará cualquier otra configuración y se excluirán las instancias de recursos de tu conjunto de recursos de alto valor.

  • Reduce la especificación del atributo de recurso de ámbito en la configuración del valor del recurso.

  • Elimina las configuraciones de valores de recursos que asignan el valor LOW.

Para obtener instrucciones sobre cómo crear, editar o eliminar una configuración de valor de recurso, consulta Definir y gestionar tu conjunto de recursos de alto valor.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

CIEM service account missing permissions

Nombre de la categoría en la API: CIEM_SERVICE_ACCOUNT_MISSING_PERMISSIONS

La cuenta de servicio que usa el servicio CIEM no tiene permisos. CIEM no puede generar una o varias categorías de detecciones.

Para solucionar este problema, restaura los roles de gestión de identidades y accesos necesarios en la cuenta de servicio de CIEM:

  1. En la consola, ve a la página Gestión de identidades y accesos. Google Cloud

    Ir a IAM

  2. Selecciona la cuenta de servicio de CIEM de tu organización. El identificador de la cuenta de servicio es una dirección de correo con el siguiente formato:

    service-org-ORGANIZATION_ID@gcp-sa-ciem.iam.gserviceaccount.com
    

    Sustituye ORGANIZATION_ID por el ID numérico de tu organización.

    Si no ves la cuenta de servicio en la lista, haz clic en CONCEDER ACCESO en la parte superior de la página e introduce la cuenta de servicio como nuevo principal.

  3. Asigna el rol Agente de servicio de CIEM (roles/ciem.serviceAgent) a la cuenta de servicio. Si usas roles personalizados, asegúrate de que incluyan los siguientes permisos:

    • cloudasset.assets.exportResource
    • cloudasset.assets.exportIamPolicy
  4. Haz clic en Guardar.

CIEM AWS CloudTrail configuration error

Nombre de la categoría en la API: AWS_CLOUDTRAIL_CONFIGURATION_ERROR

No se están enviando todos o algunos de los resultados de CIEM de AWS a Security Command Center. El feed de AWS CloudTrail ha fallado y no puede obtener datos correctamente debido a un error de configuración.

Este resultado puede deberse a tres motivos:

  • Falta el feed de AWS CloudTrail

    Para solucionar este problema, cree y configure un feed en la consola de Security Operations para ingerir registros de AWS CloudTrail. Asigna los valores CIEM y TRUE al par clave-valor Etiqueta de ingestión.

    Para obtener instrucciones sobre cómo crear un feed, consulta Crear el feed en la documentación de Google SecOps.

  • Errores en la configuración del feed

    Asegúrate de que has configurado el feed correctamente.

    Para configurar un feed, consulta el artículo Configurar un feed en Google Security Operations para ingerir registros de AWS de la documentación de Google SecOps.

  • Configuración de AWS CloudTrail incompleta

    Para solucionar este problema, configure el segmento de S3 en su configuración de AWS CloudTrail para registrar tanto eventos de datos como eventos de gestión de todas las cuentas de AWS en las que quiera usar CIEM.

    Para configurar CloudTrail, consulta el artículo Configurar AWS CloudTrail (u otro servicio) de la documentación de Google SecOps.

GKE service account missing permissions

Nombre de la categoría en la API: GKE_SERVICE_ACCOUNT_MISSING_PERMISSIONS

Container Threat Detection no puede generar detecciones en un clúster de Google Kubernetes Engine porque faltan permisos en la cuenta de servicio predeterminada de GKE del clúster. De esta forma, se evita que Container Threat Detection se habilite correctamente en el clúster.

Para solucionar este problema, restaura la cuenta de servicio predeterminada de GKE y confirma que tiene el rol Agente de servicio de Kubernetes Engine (roles/container.serviceAgent).

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

KTD blocked by admission controller

Nombre de la categoría en la API: KTD_BLOCKED_BY_ADMISSION_CONTROLLER

No se puede habilitar Container Threat Detection en un clúster porque un controlador de admisión de terceros impide el despliegue del objeto DaemonSet de Kubernetes necesario.

Para solucionar este problema, asegúrese de que los controladores de admisión que se ejecutan en el clúster permitan que Container Threat Detection cree los objetos de Kubernetes necesarios.

Comprobar el controlador de admisión

Comprueba si el controlador de admisión de tu clúster está denegando la implementación del objeto DaemonSet de detección de amenazas de contenedores.

  1. En la descripción del hallazgo, en los detalles del hallazgo de la Google Cloud consola, revisa el mensaje de error incluido de Kubernetes. El mensaje de error de Kubernetes debe ser similar al siguiente:

    generic::failed_precondition: incompatible admission webhook:
    admission webhook "example.webhook.sh" denied the request:
    [example-constraint] you must provide labels: {"example-required-label"}.
    
  2. En los registros de auditoría de Cloud de actividad de administración del proyecto que contiene tu clúster, busca el mensaje de error que se muestra en el campo Descripción de los detalles del hallazgo.

  3. Si tu controlador de admisión funciona, pero deniega la implementación del objeto DaemonSet de Container Threat Detection, configura tu controlador de admisión para que permita que el agente de servicio de Container Threat Detection gestione objetos en el espacio de nombres kube-system.

    El agente de servicio de Container Threat Detection debe poder gestionar objetos de Kubernetes específicos.

Para obtener más información sobre cómo usar los controladores de admisión con Container Threat Detection, consulta PodSecurityPolicy y controladores de admisión.

Confirmar la corrección

Una vez que hayas corregido el error, Security Command Center intentará habilitar automáticamente Container Threat Detection. Una vez que haya transcurrido el tiempo necesario para que se habilite, puedes comprobar si Detección de amenazas de contenedores está activo siguiendo estos pasos:

  1. Ve a la página Cargas de trabajo de Kubernetes Engine en la consola.

    Ir a cargas de trabajo de Kubernetes

  2. Si es necesario, selecciona Mostrar cargas de trabajo del sistema.

  3. En la página Cargas de trabajo, filtra las cargas de trabajo por el nombre del clúster.

  4. Busca la carga de trabajo container-watcher. Si aparece container-watcher y su estado es OK, significa que Container Threat Detection está activo.

KTD image pull failure

Nombre de la categoría en la API: KTD_IMAGE_PULL_FAILURE

No se puede habilitar Detección de amenazas de contenedores en el clúster porque no se puede extraer (descargar) una imagen de contenedor necesaria de gcr.io, el host de imágenes de Container Registry.

La extracción o descarga de una imagen de contenedor puede fallar por varios motivos.

Comprueba lo siguiente:

  • Asegúrate de que la red de VPC, el DNS o la configuración del cortafuegos no bloqueen el acceso de la red del clúster al host de la imagen gcr.io.
  • Si el clúster es privado, asegúrate de que la opción Acceso privado de Google esté habilitada para permitir el acceso al host de la imagen gcr.io.
  • Si los ajustes de red y el Acceso privado de Google no son la causa del error, consulta la documentación para solucionar problemas de GKE sobre los errores ImagePullBackOff y ErrImagePull.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

KTD service account missing permissions

Nombre de la categoría en la API: KTD_SERVICE_ACCOUNT_MISSING_PERMISSIONS

La cuenta de servicio de Container Threat Detection identificada en los detalles de la detección de la consola Google Cloud no tiene los permisos necesarios. No se están enviando todos los resultados de Container Threat Detection a Security Command Center, o bien no se está enviando ninguno.

Para solucionar este problema, sigue estos pasos:

  1. Asigna el rol Agente de servicio de Container Threat Detection (roles/containerthreatdetection.serviceAgent) a la cuenta de servicio. Para obtener más información, consulta el artículo Asignar un solo rol.

    Si quieres usar un rol personalizado, asegúrate de que tenga los permisos del rol Agente de servicio de Container Threat Detection.

  2. Asegúrate de que no haya políticas de denegación de gestión de identidades y accesos que impidan que la cuenta de servicio use alguno de los permisos del rol Agente de servicio de Detección de amenazas de contenedores. Si hay una política de denegación que bloquea el acceso, añade la cuenta de servicio como principal de excepción en la política de denegación.

Para obtener más información sobre la cuenta de servicio de Detección de amenazas de contenedores, el rol y los permisos que requiere, consulta Permisos de gestión de identidades y accesos necesarios.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

Misconfigured Cloud Logging Export

Nombre de la categoría en la API: MISCONFIGURED_CLOUD_LOGGING_EXPORT

El proyecto configurado para la exportación continua a Cloud Logging no está disponible. Por lo tanto, Security Command Center no puede enviar resultados a Logging.

Para solucionar este problema, haz una de las siguientes acciones:

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

VPC Service Controls Restriction

Nombre de la categoría en la API: VPC_SC_RESTRICTION

Security Health Analytics no puede generar determinados resultados de un proyecto porque este está protegido por un perímetro de servicio. Debe conceder acceso entrante a la cuenta de servicio de Security Command Center al perímetro de servicio.

El identificador de la cuenta de servicio es una dirección de correo electrónico con el siguiente formato:

service-RESOURCE_KEYWORD-RESOURCE_ID@security-center-api.iam.gserviceaccount.com

Haz los cambios siguientes:

  • RESOURCE_KEYWORD: la palabra clave org o project, en función del recurso al que pertenezca la cuenta de servicio
  • RESOURCE_ID: una de las siguientes opciones:

    • El ID de la organización si la cuenta de servicio es propiedad de la organización
    • El número de proyecto si la cuenta de servicio es propiedad de un proyecto

Si tienes cuentas de servicio a nivel de organización y de proyecto, aplica la corrección a ambas.

Para solucionar este problema, sigue estos pasos.

Paso 1: Determina qué perímetro de servicio está bloqueando Security Health Analytics

  1. Obtén el ID único de Controles de Servicio de VPC y el ID de proyecto asociado a la detección:

    1. Para ver los detalles de la detección, haz clic en el nombre de su categoría.
    2. En el campo Descripción, copia el ID único de Controles de Servicio de VPC. Por ejemplo, 5e4GI409D6BTWfOp_6C-uSwmTpOQWcmW82sfZW9VIdRhGO5pXyCJPQ.
    3. En el campo Ruta del recurso, copia el ID del proyecto.
  2. Obtén el ID de la política de acceso y el nombre del perímetro de servicio:

    1. En la Google Cloud consola, ve a la página Explorador de registros.

      Ir a Explorador de registros

    2. En la barra de herramientas, selecciona el proyecto asociado a la detección.

    3. En el cuadro de búsqueda, introduce el ID único del error.

      Buscar por UID de error

      Si el error no aparece en los resultados de la consulta, amplía la cronología en el histograma y vuelve a ejecutar la consulta.

    4. Haz clic en el error que aparece.

    5. Haz clic en Mostrar campos anidados.

    6. Copia el valor del campo servicePerimeterName. El valor tiene el siguiente formato:

      accessPolicies/ACCESS_POLICY/servicePerimeters/SERVICE_PERIMETER
      

      En este ejemplo, el nombre de recurso completo del perímetro de servicio es accessPolicies/540107806624/servicePerimeters/vpc_sc_misconfigured.

      • ACCESS_POLICY es el ID de la política de acceso (por ejemplo, 540107806624).
      • SERVICE_PERIMETER es el nombre del perímetro de servicio, por ejemplo, vpc_sc_misconfigured.

        Nombre completo del recurso del perímetro de servicio

    7. Para obtener el nombre visible que corresponde al ID de la política de acceso, usa la CLI de gcloud.

      Si no puedes hacer consultas a nivel de organización, pide a tu administrador que siga este paso.

      gcloud access-context-manager policies list \
          --organization ORGANIZATION_ID
      

      Sustituye ORGANIZATION_ID por el ID numérico de tu organización.

      Obtendrás un resultado similar al siguiente:

      NAME          ORGANIZATION  SCOPES                 TITLE           ETAG
      540107806624  549441802605                         default policy  2a9a7e30cbc14371
      352948212018  549441802605  projects/393598488212  another_policy  d7b47a9ecebd4659
      

      El nombre visible es el título que corresponde al ID de la política de acceso. Anota el nombre visible de la política de acceso y el nombre del perímetro de servicio. Los necesitarás en la siguiente sección.

Paso 2: Crea una regla de entrada que conceda acceso al proyecto

Para acceder a esta sección, debes tener acceso a nivel de organización a los Controles de Servicio de VPC. Si no tienes acceso a nivel de organización, pide a tu administrador que siga estos pasos.

En los pasos siguientes, creará una regla de entrada en el perímetro de servicio que ha identificado en el paso 1.

Para conceder a una cuenta de servicio acceso entrante a un perímetro de servicio, sigue estos pasos.

  1. Ve a Controles de Servicio de VPC.

    Ir a Controles de Servicio de VPC

  2. En la barra de herramientas, selecciona tu Google Cloud organización.

  3. En la lista desplegable, selecciona la política de acceso que contenga el perímetro de servicio al que quieras conceder acceso.

    Lista de políticas de acceso

    Los perímetros de servicio asociados a la política de acceso aparecen en la lista.

  4. Haga clic en el nombre del perímetro de servicio.

  5. Haz clic en Editar perímetro.

  6. En el menú de navegación, haz clic en Ingress Policy (Política de entrada).

  7. Haz clic en Añadir regla.

  8. Configura la regla de la siguiente manera:

    Atributos FROM del cliente de API

    1. En Fuente, selecciona Todas las fuentes.
    2. En Identidad, selecciona Identidades seleccionadas.
    3. En el campo Añadir usuario o cuenta de servicio, haga clic en Seleccionar.
    4. Introduce la dirección de correo de la cuenta de servicio. Si tienes cuentas de servicio a nivel de organización y a nivel de proyecto, añade ambas.
    5. Haz clic en Guardar.

    Atributos TO de los servicios o recursos

    1. En Proyecto, selecciona Todos los proyectos o el proyecto especificado en la detección.

    2. En Servicios, selecciona Todos los servicios o servicios específicos en los que se produzcan infracciones de los Controles de Servicio de VPC.

    Si un perímetro de servicio restringe el acceso a un servicio obligatorio, Security Health Analytics no podrá generar resultados para ese servicio.

  9. En el menú de navegación, haz clic en Guardar.

Para obtener más información, consulta el artículo sobre cómo configurar políticas de entrada y salida.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

Security Command Center service account missing permissions

Nombre de la categoría en la API: SCC_SERVICE_ACCOUNT_MISSING_PERMISSIONS

Al agente de servicio de Security Command Center le faltan los permisos necesarios para funcionar correctamente.

El identificador de la cuenta de servicio es una dirección de correo electrónico con el siguiente formato:

service-RESOURCE_KEYWORD-RESOURCE_ID@security-center-api.iam.gserviceaccount.com

Haz los cambios siguientes:

  • RESOURCE_KEYWORD: la palabra clave org o project, en función del recurso al que pertenezca la cuenta de servicio
  • RESOURCE_ID: una de las siguientes opciones:

    • El ID de la organización si la cuenta de servicio es propiedad de la organización
    • El número de proyecto si la cuenta de servicio es propiedad de un proyecto

Si tienes cuentas de servicio a nivel de organización y de proyecto, aplica la corrección a ambas.

Para solucionar este problema, sigue estos pasos:

  1. Asigna el rol Agente de servicio de Security Center (roles/securitycenter.serviceAgent) a la cuenta de servicio.

    Para obtener más información, consulta el artículo Asignar un solo rol.

    También puedes usar un rol personalizado. En ese caso, asegúrate de que tenga los permisos del rol Agente de servicio de Security Center.

  2. Asegúrate de que no haya políticas de denegación de gestión de identidades y accesos que impidan que la cuenta de servicio use alguno de los permisos de los roles necesarios. Si hay una política de denegación que bloquea el acceso, añade la cuenta de servicio como principal de excepción en la política de denegación.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

Siguientes pasos

Consulta información sobre los errores de Security Command Center.