Reglas de seguridad para operaciones de canalización

Reglas de seguridad para operaciones de canalización

Las reglas de operaciones de canalización te permiten igualar las funciones de filtrado del motor de reglas existente. Si bien las operaciones de Pipeline ofrecen un amplio conjunto de funciones, el motor de reglas se limita a reconocer filtros simples para garantizar la satisfacción y la seguridad de las consultas.

Requisitos de edición y modo

Este documento se aplica a la edición Enterprise de Firestore en modo nativo.

Expresiones de filtro admitidas

Para que una búsqueda esté restringida por tus reglas, debe usar operadores de comparación estándar con constantes. El motor de reglas reconoce los siguientes tipos de filtros:

• Igualdad y desigualdad: eq y neq
• Comparaciones: gt, gte, lt y lte
• Membresía: in y arrayContains

Estos son algunos ejemplos:

• where(eq("foo", 2))
• where(lt("foo", 2))
• documents("/user/1", "/user/2").where(...)

Nota: No se reconocen las expresiones complejas, como las operaciones aritméticas dentro de un filtro (por ejemplo, where(eq("foo" * 2, 10))) o las funciones de cadena como strContains, para restringir las consultas.

Propiedades de las solicitudes

Puedes seguir usando el objeto request para validar la autenticación y el contexto de la consulta, aunque algunas propiedades disponibles en las consultas estándar no se admiten en las canalizaciones.

Propiedades admitidas

El nuevo motor sigue admitiendo las siguientes propiedades:

• request.auth: Accede a los datos del UID y el token del usuario.
• request.method: Identifica la operación (por ejemplo, get o list).
• request.path: Es la ruta de acceso del recurso.
• request.time: Es la marca de tiempo del servidor de la solicitud.

Propiedades no admitidas

Las propiedades de request.query, como limit, offset y orderBy, no son compatibles con las verificaciones de reglas de Pipelines debido a la complejidad de determinar estos valores en consultas de varias etapas.

Control y permisos de etapas de canalizaciones

Existen diferentes etapas de la canalización que se asignan a operaciones específicas y detalladas en las reglas de seguridad:

• Permisos de allow list: Se activan en las etapas collection(), collectionGroup() y database().
• Permisos de allow get: Se activan en la etapa documents(), que se trata de manera similar a una operación por lotes de get.
• Permisos de allow create: Se activan en las etapas insert() y upsert() cuando se crean documentos nuevos.
• Permisos de allow update: Se activan en las etapas update() y upsert() cuando se actualizan documentos existentes.
• Permisos de allow delete: Se activan en las etapas delete().
• Permisos de allow write: Se aplican a todas las operaciones de DML (insert(), update(), upsert() y delete()).
• Etapas de modificación de campos: Las reglas solo operan en los datos almacenados y no en los valores derivados. Si una canalización incluye etapas que modifican campos (por ejemplo, AddFields, ReplaceWith o Select), el motor de reglas deja de aplicar restricciones de filtro después de que se encuentra esa etapa.
• Etapa de literales: La etapa literals() no lee datos de la base de datos, pero puede generar costos. Para evitar abusos, debe combinarse con otra etapa (como collection()) que se pueda verificar con reglas.

Etapas del lenguaje de manipulación de datos (DML) y reglas de seguridad

Cuando se ejecutan etapas de lenguaje de manipulación de datos (DML) (insert(), update(), upsert() y delete()), las reglas de seguridad evalúan los permisos de manera diferente que para las consultas de lectura:

• Evaluación de reglas por documento: A diferencia de las canalizaciones de lectura, que requieren expresiones de filtro por adelantado para restringir la consulta en el momento de la planificación, las operaciones de DML evalúan las reglas de seguridad en función de cada mutación de documento individual.
• Variables de regla:
  • request.resource: Contiene los datos del documento propuestos para las operaciones insert(), update() y upsert().
  • resource: Contiene los datos actuales del documento almacenados en la base de datos antes de la modificación (disponible para update(), delete() y upsert() de documentos existentes).

Límites del sistema y comportamiento de ejecución con DML

Cuando ejecutes operaciones de DML con reglas de seguridad, ten en cuenta los siguientes límites del sistema y comportamientos de ejecución:

El límite de veinte búsquedas en get() y exists()

Las reglas de seguridad de Firebase permiten un máximo de 20 búsquedas de documentos (get() o exists()) en una solicitud completa.

Cuando una canalización de DML se ejecuta fuera de una transacción explícita, los documentos se procesan en lotes. Debido a que cada lote se ejecuta en su propia transacción y los documentos se pueden modificar de forma simultánea entre lotes, las reglas de seguridad y las búsquedas de documentos se vuelven a evaluar para cada lote de escritura.

Incluso si tus reglas de seguridad se evalúan en función de un solo documento estático, por ejemplo, para verificar si un usuario es administrador:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /posts/{postId} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.isAdmin == true;
    }
  }
}

Cada lote de escritura de documentos realiza una búsqueda. Como resultado, después de escribir todos los documentos posibles, se alcanza el límite de 20 búsquedas para la solicitud y la canalización falla con un error PERMISSION_DENIED. Además, cada búsqueda realizada por lote de escritura genera su propia facturación de lectura.

Sugerencia: Para evitar alcanzar el límite de 20 búsquedas en operaciones de DML masivas, usa reclamaciones personalizadas en tokens de Firebase Authentication (por ejemplo, request.auth.token.isAdmin == true) en lugar de búsquedas de get() o exists(). Las reclamaciones personalizadas se validan en la memoria directamente desde el token de autenticación, lo que evita por completo las lecturas de documentos y los límites de búsqueda.

Éxito parcial y PERMISSION_DENIED

Cuando se ejecutan fuera de una transacción, las operaciones de DML confirman las escrituras en lotes secuenciales. Si un lote falla, ya sea porque un documento no cumple con una condición de regla o porque se supera el límite de 20 búsquedas, la canalización se detiene y devuelve un error PERMISSION_DENIED.

Sin embargo, los lotes que ya se confirmaron no se revierten. La base de datos permanece en un estado de actualización parcial. Debido a que el cliente recibe un error sin una lista de documentos modificados, debes consultar tus datos para inspeccionar qué escrituras se realizaron correctamente.

Sugerencia: Si tu carga de trabajo requiere una ejecución de todo o nada, ejecuta la canalización de DML dentro de una transacción de usuario explícita (por ejemplo, con runTransaction y transaction.execute(pipeline)). En una transacción, todas las operaciones se confirman juntas o se revierten por completo en caso de error. Ten en cuenta que las transacciones están sujetas a los límites de transacciones de la edición Enterprise de Firestore.

Diagnostica fallas de reglas con los Registros de auditoría de Cloud

Por motivos de seguridad, los errores PERMISSION_DENIED que se muestran al cliente no divulgan qué condición de la regla de seguridad falló ni si se alcanzó el límite de 20 búsquedas.

Para diagnosticar fallas en la evaluación de reglas, los administradores de proyectos pueden inspeccionar los Registros de auditoría de Cloud en la consola de Google Cloud (en Firestore > Monitoring o en el Explorador de registros) para ver entradas detalladas de EvaluationError.