Row Level Access Control in GridDB for Multi‑Tenant IoT Systems

by

Summary

During the implementation of a multi-tenant IoT platform using GridDB, we encountered a significant architectural bottleneck. The requirement was to enforce Row Level Access Control (RLAC) so that users could only interact with data subsets (e.g., specific device IDs or departments) within a shared container. We discovered that GridDB does not natively support fine-grained Row Level Security (RLS) at the engine level like some relational databases. This led to a critical design decision: whether to implement security at the database schema level or the application logic level.

Root Cause

The failure to anticipate this limitation stemmed from a fundamental misunderstanding of the GridDB security model. The root causes identified were:

  • Coarse-Grained Permissions: GridDB’s native ACL (Access Control List) operates at the Container level, not the row level. Once a user has read access to a container, they can theoretically query any row within it.
  • Missing Native RLS: Unlike PostgreSQL or SQL Server, there is no built-in mechanism to inject a mandatory WHERE clause based on the authenticated user’s context.
  • Implicit Trust Model: The initial design assumed the database engine would act as the Policy Enforcement Point (PEP), whereas it actually only acts as a Policy Administration Point (PAP) for container-level access.

Why This Happens in Real Systems

In high-performance distributed databases and NoSQL-style engines, there is often a direct trade-off between security granularity and throughput.

  • Performance Optimization: Implementing RLS requires the database engine to intercept every single query, evaluate a policy, and rewrite the execution plan. This adds latency to the hot path of data ingestion and retrieval.
  • Distributed Complexity: In a distributed environment, maintaining a global state of “who owns which row” across all nodes introduces significant synchronization overhead.
  • Abstraction Leaks: Engineers often assume that “Database” implies a full suite of relational security features, forgetting that specialized engines (like time-series or distributed NoSQL) optimize for scale over complex relational constraints.

Real-World Impact

The lack of a native solution forced us to choose between two suboptimal paths:

  • Architectural Complexity: Implementing a Middleware Authorization Layer added roughly 15-20ms of latency to every request.
  • Operational Overhead: Using the Container-per-Tenant pattern led to “container sprawl,” making schema migrations and global analytics nearly impossible to manage.
  • Security Risk: Relying solely on the application layer to append WHERE clauses created a risk of Broken Object Level Authorization (BOLA) if a single developer forgot to include the tenant filter in a new API endpoint.

Example or Code

To mitigate the risk of developers forgetting filters, we implemented a Repository Pattern Wrapper that injects the tenant context into every query programmatically.

class SecureGridDBRepository:
    def __init__(self, griddb_connection, user_context):
        self.db = griddb_connection
        self.tenant_id = user_context.tenant_id

    def get_device_data(self, device_id):
        # The filter is forced by the repository, not the API layer
        query = f"SELECT * FROM device_container WHERE device_id = '{device_id}' AND tenant_id = '{self.tenant_id}'"
        return self.db.query(query)

    def insert_telemetry(self, data):
        # Force injection of ownership metadata
        data['tenant_id'] = self.tenant_id
        return self.db.put("device_container", data)

How Senior Engineers Fix It

Senior engineers do not just “add a WHERE clause”; they design defense-in-depth architectures to ensure the system is secure by default.

  • Policy Enforcement Point (PEP) Abstraction: Instead of letting the application query the DB directly, we implement a Data Access Layer (DAL) or a Query Proxy. This ensures that the tenant_id is appended at the lowest possible level of the application code.
  • Hybrid Partitioning: We use a sharding strategy where highly sensitive tenants get dedicated containers (isolation), while low-risk tenants share a large, multi-tenant container (efficiency).
  • Automated Schema Auditing: Implementing CI/CD checks that scan the codebase for any raw database queries that do not pass through the Secure Repository.
  • Observability: Setting up alerts for “Cross-Tenant Access Attempts,” where the middleware catches a query attempting to access an unauthorized tenant_id.

Why Juniors Miss It

  • Feature Assumption: Juniors often assume that if a database is “enterprise-grade,” it must have every feature found in a standard RDBMS.
  • Focus on “Happy Path”: They focus on the functional requirement (“I need to fetch data”) rather than the adversarial requirement (“How can a user see someone else’s data?”).
  • Lack of Pattern Awareness: They tend to write imperative code (direct queries in controllers) rather than declarative/structured code (using repositories or interceptors), which makes security enforcement inconsistent and difficult to audit.

Leave a Comment