Esta página se ha traducido con Cloud Translation API.

Reglas de entrada y salida

En esta página se explican las reglas de entrada y salida de los Controles de Servicio de VPC. Controles de Servicio de VPC usa reglas de entrada y salida para permitir el acceso a los recursos y clientes protegidos por perímetros de servicio.

Los bloques de reglas de entrada y de salida especifican la dirección del acceso permitido a diferentes identidades y recursos. Las reglas de entrada y salida pueden sustituir y simplificar los casos prácticos que antes requerían uno o varios puentes de perímetro.

Para saber cómo aplicar políticas de entrada y salida a tu perímetro de servicio, consulta Configurar políticas de entrada y salida.

Puedes configurar grupos de identidades e identidades de terceros y roles de gestión de identidades y accesos (vista previa) en las reglas de entrada y salida.

Para ver una lista de casos prácticos y ejemplos de intercambio de datos seguro, consulta Intercambio de datos seguro con reglas de entrada y salida.

Para ver una lista de casos de uso y ejemplos de acceso contextual, consulta el artículo Acceso contextual con reglas de entrada.

Ventajas de las reglas de entrada y salida

Las reglas de entrada y salida te permiten intercambiar datos de forma privada y eficiente dentro de las organizaciones y entre ellas mediante las APIs de servicios de Google Cloud .
Las reglas de entrada y salida te permiten conceder acceso a los Google Cloud recursos de un perímetro en función del contexto de la solicitud de la API:
1. Restringe los tipos o las identidades que se pueden usar en una red, una dirección IP o un dispositivo de origen.
2. Restringe Google Cloud las APIs y los métodos a los que se puede acceder en función de la red de origen, la dirección IP, el dispositivo y el tipo de identidad.
Minimiza el riesgo de filtración externa de datos limitando el servicio, los métodos, los proyectos, las redes VPC y las identidades exactos que se utilizan para ejecutar el intercambio de datos.Google Cloud
Concede acceso de solo lectura a conjuntos de datos e imágenes externos que no gestiones tú.
Asegúrate de que los clientes de segmentos con menos privilegios no tengan acceso a losGoogle Cloud recursos de segmentos con más privilegios, pero sí en la otra dirección.
Simplifica las configuraciones que antes requerían uno o varios puentes de perímetro.

Definición de entrada y salida

Las definiciones de entrada y salida son independientes de la operación que se invoque en el recurso. Por lo tanto, las definiciones hacen referencia a la dirección de la solicitud y no a la dirección del movimiento de datos.

Entrada: se refiere a cualquier acceso de un cliente de API desde fuera del perímetro de servicio a recursos que se encuentran dentro de un perímetro de servicio. Ejemplo:
- Un cliente de Cloud Storage fuera de un perímetro de servicio que llama a operaciones de lectura, escritura o copia de Cloud Storage en un recurso de Cloud Storage dentro del perímetro.
Salida: hace referencia a cualquier acceso que implique un cliente de API o recursos dentro del perímetro de servicio y recursos fuera de un perímetro de servicio. Ejemplos:
- Un cliente de Compute Engine dentro de un perímetro de servicio que llama a una operación de create de Compute Engine en la que el recurso de imagen está fuera del perímetro.
- Un cliente de Cloud Storage (dentro o fuera del perímetro) que llama a un comando copy en el que un segmento está dentro del perímetro y el otro, fuera.

Modelo de política

Una regla de entrada o salida consta de bloques from y to, donde:

from hace referencia a los atributos del cliente de la API.
tohace referencia a los atributos de Google Cloud servicios y recursos.

Se pueden asociar varias reglas de entrada y de salida a un perímetro de servicio. Una llamada de servicioGoogle Cloud se permite o se deniega en función de la siguiente semántica:

Se permite una solicitud de un cliente que está fuera del perímetro a un Google Cloud recurso que está dentro del perímetro si se cumplen las condiciones de la regla de entrada necesaria.
Se permite una solicitud de un cliente dentro del perímetro a un recurso Google Cloud fuera del perímetro si se cumplen las condiciones de la regla de salida necesaria.
Se permite una llamada a la API que implique un Google Cloud recurso dentro del perímetro y un Google Cloud recurso fuera del perímetro si hay una regla de entrada que cumpla el cliente (si el cliente no está dentro del perímetro) y una regla de salida que cumpla el recurso externo.

Ejemplos de solicitudes de API permitidas por reglas de entrada

Un cliente de Cloud Storage fuera del perímetro descarga objetos de un segmento de Cloud Storage situado dentro del perímetro en la máquina local (por ejemplo, mediante el comando gcloud storage cp).
Un cliente de BigQuery fuera del perímetro que usa un trabajo de BigQuery en un proyecto dentro del perímetro para consultar un conjunto de datos de BigQuery dentro del perímetro (por ejemplo, con el comando bq query).
Una máquina virtual de Compute Engine en una red de VPC que está fuera del perímetro escribe en un bucket de Cloud Storage que está dentro del perímetro.

Ejemplos de solicitudes de API permitidas por reglas de salida

Un cliente de Cloud Storage dentro del perímetro que copia objetos entre un segmento de Cloud Storage fuera del perímetro y un segmento dentro del perímetro (por ejemplo, mediante el comando gcloud storage cp).

Un cliente de BigQuery dentro del perímetro que usa un trabajo de BigQuery en un proyecto fuera del perímetro para consultar un conjunto de datos de BigQuery dentro del perímetro (por ejemplo, con el comando bq query).

Ejemplos de solicitudes de API permitidas por una combinación de reglas de entrada y salida

Un cliente de Cloud Storage que está fuera del perímetro copia objetos entre un segmento de Cloud Storage que está fuera del perímetro y un segmento que está dentro del perímetro (por ejemplo, mediante el comando gcloud storage cp).
Un cliente de BigQuery fuera del perímetro que usa un trabajo de BigQuery en un proyecto fuera del perímetro para consultar un conjunto de datos de BigQuery dentro del perímetro (por ejemplo, mediante el comando bq query).
Un cliente de Compute Engine que está fuera del perímetro crea un disco de Compute Engine que también está fuera del perímetro mediante una clave de Cloud KMS que está dentro del perímetro.

En los ejemplos de BigQuery y Compute Engine, una regla de entrada no es suficiente, ya que el trabajo de BigQuery o el disco de Compute Engine están fuera del perímetro. Se necesita una regla de salida para permitir una solicitud de API que implique un recurso Google Cloud dentro del perímetro (el conjunto de datos de BigQuery o la clave de Cloud KMS) y un recurso fuera del perímetro (el trabajo de BigQuery o el disco de Compute Engine).

Solicitudes a APIs que implican varios perímetros de servicio

Cuando los recursos a los que se accede o el cliente de la API pertenecen a perímetros de servicio diferentes, las políticas de todos los perímetros implicados deben permitir la solicitud de la API. Por ejemplo, supongamos que tienes un cliente y un segmento de Cloud Storage a dentro de un perímetro de servicio A y un segmento b dentro de un perímetro de servicio B. En este ejemplo, para que el cliente de Cloud Storage copie objetos del segmento a al segmento b y del segmento b al segmento a, se necesitan las siguientes reglas de entrada y salida:

una regla de salida en el perímetro A para permitir el acceso al segmento de Cloud Storage b ,
una regla de salida en el perímetro B para permitir el acceso al segmento de Cloud Storage a,
una regla de entrada en el perímetro B para permitir el acceso al cliente de Cloud Storage que está fuera del perímetro B.

Referencia de reglas de entrada

Las reglas de entrada se pueden configurar con la Google Cloud consola, un archivo JSON o un archivo YAML. En el siguiente ejemplo se usa el formato .yaml:

- ingressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - PRINCIPAL_IDENTIFIER
    sources:
    - resource: RESOURCE
      *OR*
    - accessLevel: ACCESS_LEVEL
  ingressTo:
    operations:
    - serviceName: SERVICE
      methodSelectors:
      - method: METHOD
      *OR*
      - permission: PERMISSION
    *OR*
    roles:
    - ROLE_NAME
    resources:
    - projects/PROJECT
  title: TITLE

- ingressFrom: - (Obligatorio) Inicia el bloque from, que muestra las fuentes e identidades permitidas fuera del perímetro.
identityType:: (se debe usar este atributo o el atributo identities) este atributo define los tipos de identidades que se pueden usar desde el sources especificado (origen de la red). Valores aceptables: ANY_IDENTITY, ANY_USER_ACCOUNT y ANY_SERVICE_ACCOUNT. ANY_IDENTITY permite solicitudes de todas las identidades, incluidas las solicitudes sin autenticar. ANY_USER_ACCOUNT permite a todos los usuarios humanos y ANY_SERVICE_ACCOUNT permite a todas las cuentas de servicio, pero ni ANY_USER_ACCOUNT ni ANY_SERVICE_ACCOUNT permiten solicitudes sin autenticar.

Este atributo no restringe las identidades en función de la organización. Por ejemplo, ANY_SERVICE_ACCOUNT permite una cuenta de servicio de cualquier organización.
identities: - (Se debe usar este atributo o el atributo identityType) Este atributo inicia una lista de cuentas de servicio, cuentas de usuario, grupos de Google o identidades de terceros que pueden acceder a los recursos del perímetro.
PRINCIPAL_IDENTIFIER: especifica una cuenta de usuario, una cuenta de servicio, un grupo de Google o una identidad de terceros a los que quieras dar acceso a los recursos del perímetro. Controles de Servicio de VPC solo admite las siguientes identidades de los identificadores de principales de la API IAM v1:
- En el caso de las cuentas de usuario y las cuentas de servicio, usa los formatos user:USER_EMAIL_ADDRESS y serviceAccount:SA_EMAIL_ADDRESS, respectivamente.
- Para otras identidades, use los formatos especificados en Grupos de identidades admitidos.
Para obtener más información sobre estas identidades, consulta Identificadores principales de las políticas de permiso.
sources: (Obligatorio) Este atributo hace referencia a una lista de orígenes de red. Cada valor de la lista es un nivel de acceso o un Google Cloud proyecto. Si asigna el valor "*" al atributo accessLevel, la política de entrada permite el acceso desde cualquier origen de red. Si asignas a este atributo el valor de un Google Cloud proyecto, la política de entrada permite el acceso desde una red VPC que pertenece al proyecto.

Este valor podría eliminarse cuando se elimine de forma permanente el proyecto asociado. Sin embargo, la eliminación de este valor no provoca ningún error. Comprueba siempre si este valor existe cuando tengas algún problema.
- resource:: (use este atributo o el atributo accessLevel) Especifica un proyecto o una red de VPC de fuera del perímetro al que quiere dar acceso. Para especificar un proyecto, usa el siguiente formato: projects/PROJECT_NUMBER. Para especificar una red de VPC, usa el siguiente formato: //compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME.
- accessLevel:: se debe usar este atributo o el atributo resource. Especifica el nivel de acceso desde fuera del perímetro al que se da acceso. Si asigna el valor "*" al atributo accessLevel, la política de entrada permite el acceso desde cualquier origen de red.
ingressTo: - (Obligatorio) Inicia el bloque to, que muestra las operaciones de servicio permitidas en los recursos Google Cloud especificados del perímetro.
operations:: (se debe usar este atributo o el atributo roles) marca el inicio de la lista de servicios y acciones o métodos accesibles a los que puede acceder un cliente que cumpla las condiciones del bloque from.
- serviceName: - (Obligatorio) Este campo puede ser un nombre de servicio válido o tener el valor "*" para permitir el acceso a todos los servicios. Por ejemplo, bigquery.googleapis.com es un serviceName válido. Para ver una lista de los servicios disponibles, consulta Productos compatibles.
methodSelectors:: (obligatorio si serviceName no es "*") El inicio de una lista de métodos a los que puede acceder un cliente que cumpla las condiciones del bloque from. Para ver una lista de los métodos y permisos que se pueden restringir en los servicios, consulta Restricciones de métodos de servicio admitidas.

Para ver una lista de los métodos de servicio que no puede controlar Controles de Servicio de VPC, consulta Excepciones de métodos de servicio.
- method: - (Se debe usar este atributo o el atributo permission) Este campo puede ser un método de servicio válido o se puede definir como "*" para permitir el acceso a todos los métodos del servicio especificado.
- permission: - (Este atributo o el atributo method se deben usar) Este campo debe ser un permiso de servicio válido. El acceso a los recursos que se encuentran dentro del perímetro se permite para las operaciones que requieren el permiso.

Cuando una solicitud a un recurso requiere varios permisos, debe especificar todos los permisos necesarios en la misma operación para que funcione la regla de entrada. Por ejemplo, si una solicitud a un recurso de BigQuery requiere los permisos bigquery.jobs.create y bigquery.tables.create, debe especificar ambos permisos en la misma operación. Además, si especificas los permisos varias veces para el mismo recurso mediante laGoogle Cloud consola, los permisos no se crearán en la misma operación. Para evitar este problema, especifique todos los permisos del recurso a la vez.
roles:: (se debe usar este atributo o el atributo operations) este atributo hace referencia a una lista de roles de gestión de identidades y accesos que define el ámbito de acceso de los servicios especificados en la regla.
ROLE_NAME: especifica un solo rol o una combinación de roles que incluyan todos los permisos necesarios para acceder a los servicios. Para especificar un rol, usa los formatos de nombre de rol que se mencionan en Componentes de los roles, excepto el siguiente: projects/PROJECT_ID/roles/IDENTIFIER.

Para obtener información sobre los servicios y roles admitidos, consulta el artículo Productos admitidos.
resources: - (Obligatorio) Este atributo especifica la lista de recursos del perímetro de servicio a los que puede acceder el cliente que se encuentra fuera del perímetro.Google Cloud Este campo se puede definir como "*" para permitir el acceso de entrada a cualquier recurso Google Cloud dentro del perímetro.
title: - (Opcional) Este atributo especifica el título de la regla de entrada. El título debe ser único dentro del perímetro y no puede superar los 100 caracteres. En la política de acceso, la longitud combinada de todos los títulos de las reglas no debe superar los 240.000 caracteres.

Para crear una regla de entrada funcional, debe especificar los siguientes atributos:

sources. Debes especificar un accessLevel o un resource (Google Cloud proyecto o red de VPC) o definir el atributo accessLevel en "*".

Atributo identityType o identities
Atributo resources
Atributo serviceName

Cuando hayas terminado de configurar el archivo de política de entrada, consulta Actualizar políticas de entrada y salida para obtener instrucciones sobre cómo aplicar el archivo de política de entrada a tu perímetro de servicio.

Si configuras varias reglas de entrada en un perímetro de servicio, Controles de Servicio de VPC permite una solicitud si cumple las condiciones de alguna de las reglas de entrada.

Referencia de reglas de salida

Las reglas de salida se pueden configurar mediante la Google Cloud consola, un archivo JSON o un archivo YAML. En el siguiente ejemplo se usa el formato .yaml:

- egressTo:
    operations:
    - serviceName: SERVICE_NAME
      methodSelectors:
      - method: METHOD
      *OR*
      - permission: PERMISSION
    *OR*
    roles:
    - ROLE_NAME
    resources:
    - projects/PROJECT
    *OR*
    externalResources:
    - EXTERNAL_RESOURCE_PATH
  egressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - PRINCIPAL_IDENTIFIER
    sources:
    - resource: RESOURCE
      *OR*
    - accessLevel: ACCESS_LEVEL
    sourceRestriction: RESTRICTION_STATUS
  title: TITLE

- egressTo: - (Obligatorio) Inicia el bloque to, que enumera las operaciones de servicio permitidas en los recursos de Google Cloud de los proyectos especificados que están fuera del perímetro.
operations:: (se debe usar este atributo o el atributo roles) marca el inicio de la lista de servicios y acciones o métodos accesibles a los que puede acceder un cliente que cumpla las condiciones del bloque from.
- serviceName: - (Obligatorio) Este campo puede ser un nombre de servicio válido o tener el valor "*" para permitir el acceso a todos los servicios. Para ver una lista de los servicios disponibles, consulta Productos admitidos.
methodSelectors:: (obligatorio si serviceName no es "*") El inicio de una lista de métodos a los que puede acceder un cliente que cumpla las condiciones del bloque from. Para ver una lista de los métodos y permisos que se pueden restringir en los servicios, consulta Restricciones de métodos de servicio admitidas.

Para ver una lista de los métodos de servicio que no puede controlar Controles de Servicio de VPC, consulta Excepciones de métodos de servicio.
- method:: (se debe usar este atributo o el atributo permission). Este campo puede ser un método de servicio válido o se puede definir como "*" para permitir el acceso a todos los métodos del servicio especificado.
- permission:: (se debe usar este atributo o el atributo method). Este campo debe ser un permiso de servicio válido. Se permite el acceso a los recursos especificados fuera del perímetro para las operaciones que requieran el permiso.

Cuando una solicitud a un recurso requiere varios permisos, debe especificar todos los permisos necesarios en la misma operación para que la regla de salida funcione. Por ejemplo, si una solicitud a un recurso de BigQuery requiere los permisos bigquery.jobs.create y bigquery.tables.create, debe especificar ambos permisos en la misma operación. Además, si especificas los permisos varias veces para el mismo recurso mediante laGoogle Cloud consola, los permisos no se crearán en la misma operación. Para evitar este problema, especifique todos los permisos del recurso a la vez.
roles:: (se debe usar este atributo o el atributo operations) este atributo hace referencia a una lista de roles de gestión de identidades y accesos que define el ámbito de acceso de los servicios especificados en la regla.
ROLE_NAME: especifica un solo rol o una combinación de roles que incluyan todos los permisos necesarios para acceder a los servicios. Para especificar un rol, usa los formatos de nombre de rol que se mencionan en Componentes de los roles, excepto el siguiente: projects/PROJECT_ID/roles/IDENTIFIER.

Para obtener información sobre los servicios y roles admitidos, consulta el artículo Productos admitidos.
resources:: este atributo es una lista de Google Cloud recursos especificados por sus proyectos a los que pueden acceder los clientes que se encuentran dentro de un perímetro. Puede definir este campo como "*" para permitir el acceso de salida a cualquier recursoGoogle Cloud .
externalResources:: este atributo solo se usa para especificar recursos de BigQuery Omni. Este atributo es una lista de recursos externos compatibles con BigQuery Omni a los que pueden acceder los clientes que se encuentren dentro de un perímetro. Solo puede especificar recursos de Amazon S3 o Azure Blob Storage. En Amazon S3, el formato admitido es s3://BUCKET_NAME. En el caso de Azure Storage, el formato admitido es azure://myaccount.blob.core.windows.net/CONTAINER_NAME.
egressFrom: - (Obligatorio) Inicia el bloque from que enumera las fuentes e identidades permitidas dentro del perímetro.
identityType:: (se debe usar este atributo o el atributo identities). Este atributo define los tipos de identidades que se pueden usar para acceder a los recursos especificados fuera del perímetro. Valores aceptables: ANY_IDENTITY, ANY_USER_ACCOUNT y ANY_SERVICE_ACCOUNT. ANY_IDENTITY permite solicitudes de todas las identidades, incluidas las solicitudes sin autenticar. ANY_USER_ACCOUNT permite a todos los usuarios humanos y ANY_SERVICE_ACCOUNT permite a todas las cuentas de servicio, pero ni ANY_USER_ACCOUNT ni ANY_SERVICE_ACCOUNT permiten solicitudes sin autenticar.

Este atributo no restringe las identidades en función de la organización. Por ejemplo, ANY_SERVICE_ACCOUNT permite una cuenta de servicio de cualquier organización.
identities:: (se debe usar este atributo o el atributo identityType). Este atributo inicia una lista de cuentas de servicio, cuentas de usuario, grupos de Google o identidades de terceros que pueden acceder a los recursos especificados fuera del perímetro.
PRINCIPAL_IDENTIFIER: especifica una cuenta de usuario, una cuenta de servicio, un grupo de Google o una identidad de terceros que pueda acceder a los recursos especificados fuera del perímetro. Controles de Servicio de VPC solo admite las siguientes identidades de los identificadores de principales de la API IAM v1:
- En el caso de las cuentas de usuario y las cuentas de servicio, usa los formatos user:USER_EMAIL_ADDRESS y serviceAccount:SA_EMAIL_ADDRESS, respectivamente.
- Para otras identidades, use los formatos especificados en Grupos de identidades admitidos.
Para obtener más información sobre estas identidades, consulta Identificadores principales de las políticas de permiso.
sources:: este atributo especifica una lista de orígenes de red. El valor del atributo puede ser una lista de proyectos o niveles de acceso. Para aplicar restricciones de acceso basadas en el sources especificado, asigna el valor SOURCE_RESTRICTION_ENABLED al atributo sourceRestriction.

Controles de Servicio de VPC evalúa los atributos accessLevel y resource del atributo sources como una condición OR.
- resource:: (use este atributo o el atributo accessLevel) especifique uno o varios recursos del perímetro de servicio a los que quiera permitir acceder a datos fuera del perímetro.Google Cloud Este atributo solo admite proyectos. Para especificar un proyecto, usa el siguiente formato: projects/PROJECT_NUMBER.

No puede usar "*" en este atributo para permitir todos los recursos. Google Cloud
- accessLevel:: (usa este atributo o el atributo resource) especifica uno o varios niveles de acceso que permitan a los recursos que se encuentran dentro del perímetro acceder a recursos que estén fuera de él. Asegúrate de que estos niveles de acceso pertenezcan a la misma política de acceso que el perímetro. Si asignas el valor "*" al atributo accessLevel, la política de salida permite el acceso desde cualquier origen de red.
sourceRestriction:: obligatorio si usa el atributo sources. Este atributo le permite aplicar restricciones de acceso en función del sources especificado. Para aplicar estas restricciones de acceso, asigna el valor SOURCE_RESTRICTION_ENABLED al atributo sourceRestriction.

Para inhabilitar estas restricciones de acceso, asigna el valor SOURCE_RESTRICTION_DISABLED al atributo sourceRestriction.

Si no asigna ningún valor al atributo sourceRestriction, Controles de Servicio de VPC ignora el atributo sources y no aplica ninguna restricción de acceso.
title:: (opcional) este atributo especifica el título de la regla de salida. El título debe ser único dentro del perímetro y no puede superar los 100 caracteres. En la política de acceso, la longitud combinada de todos los títulos de las reglas no debe superar los 240.000 caracteres.

Cuando hayas terminado de configurar el archivo de política de salida, consulta el artículo Actualizar políticas de entrada y salida para obtener instrucciones sobre cómo aplicar el archivo de política de salida a tu perímetro de servicio.

Si configura varias reglas de salida en un perímetro de servicio, Controles de Servicio de VPC permite una solicitud si cumple las condiciones de alguna de las reglas de salida.

Usar el modo de prueba de funcionamiento para probar las políticas de entrada y salida

Si no quieres conceder acceso a todos los métodos de un servicio, a veces puede ser difícil determinar la lista precisa de métodos que se deben permitir. Esto puede ocurrir porque un método determinado de un servicio puede provocar que se invoque otro método en un servicio independiente. Google Cloud Por ejemplo, BigQuery carga una tabla de un segmento de Cloud Storage para ejecutar una consulta.

Para determinar el conjunto correcto de métodos que se deben permitir, puedes usar el modo de ejecución de prueba de Controles de Servicio de VPC. Para ello, primero habilita un perímetro en modo de prueba sin políticas de entrada ni de salida y recoge la lista de métodos invocados del registro de auditoría. A continuación, añade progresivamente estos métodos a las políticas de entrada y salida en el modo de prueba hasta que se hayan resuelto todas las infracciones. En ese momento, la configuración se puede cambiar del modo de prueba al modo obligatorio.

Funciones no compatibles

Actualmente, no se admiten las siguientes funciones en las reglas de entrada y salida:

Identificar Google Cloud recursos por etiquetas en lugar de por proyectos.
No todos los servicios admiten reglas de entrada y salida por método. Consulta las restricciones de métodos de servicio admitidas.
No se pueden usar los tipos de identidad ANY_SERVICE_ACCOUNT y ANY_USER_ACCOUNT para permitir las siguientes operaciones:
- Todas las operaciones de Container Registry.
- Todas las operaciones del servicio notebooks.googleapis.com.
- Operaciones de Cloud Storage mediante URLs firmadas.
- Con Cloud Run Functions, puedes desplegar una función de Cloud Functions desde la máquina local.
- Exporta registros de un receptor de Cloud Logging a un recurso de Cloud Storage.
- Todas las operaciones de la interfaz de usuario web de Apache Airflow en Cloud Composer.

Limitaciones

Para obtener información sobre los límites de entrada y salida, consulta Cuotas y límites.

Siguientes pasos

Completa este codelab para saber cómo solucionar las infracciones de entrada y salida.
Consulta cómo configurar y ver el panel de control de infracciones.