Part 1 How CloudGuard Controller R82.10 Builds Dyn... - Check Point CheckMates

Part 1 How CloudGuard Controller R82.10 Builds Dynamic Security Context

Part 1: How CloudGuard Controller R82.10 Builds Dynamic Security Context

Executive Summary

Cloud environments do not become insecure only because a firewall fails to inspect traffic. They also become insecure when the context used by the firewall no longer represents the infrastructure it is protecting.

In AWS, Azure, GCP, Kubernetes, and private cloud environments, IP addresses, virtual machines, load balancers, tags, subnets, and security groups can change faster than a traditional change-management process can update firewall objects.

The CloudGuard Controller addresses this problem by running as a component of the Check Point Security Management Server, polling supported data-center APIs, evaluating imported objects and Data Center Query Objects, and sending updated object membership to Security Gateways.

This does not mean that the Controller automatically writes the security policy. The rulebase remains under administrative control. What changes dynamically is the set of IP addresses and attributes represented by the objects already used in that rulebase.

This distinction is fundamental:

> CloudGuard Controller does not automate security intent. It automates the translation of dynamic infrastructure context into enforceable gateway object membership.

This first part focuses on the Controller architecture, polling behavior, dynamic objects, query logic, and tag governance.

The technical baseline used for this article is the R82.10 CloudGuard Controller Administration Guide, published on June 23, 2026.

The Real Cloud Security Problem: Context Becomes Stale

A static firewall object works well when an application server has a long-lived IP address.

Cloud infrastructure rarely operates that way.

A production application can be affected by:

\* Virtual-machine replacement

\* Autoscaling events

\* Load-balancer backend changes

\* Kubernetes pod and service changes

\* Subnet redesign

\* Migration between accounts or subscriptions

\* Changes to cloud tags

\* Instance creation through Terraform or another CI/CD pipeline

\* Disaster-recovery activation in another region

A rule based only on manually maintained IP addresses can become inaccurate immediately after one of these events.

Consider a traditional policy:

Source: 10.10.20.15

Destination: Shared-Database

Service: TCP/5432

Action: Accept

When the workload is replaced and receives `10.10.20.84`, the firewall does not inherently know that the new IP belongs to the same application role.

A cloud-aware policy can instead reference infrastructure context:

environment = production

application = payments

role = backend

The security intent remains stable while the infrastructure membership changes.

That is the operational problem the CloudGuard Controller is designed to solve.

First, Separate the Components

One reason CloudGuard architecture is frequently misunderstood is that several Check Point cloud-security components are discussed under the same portfolio name.

They have different responsibilities.

The current CME documentation describes CME as a service that runs on a Security Management Server or Multi-Domain Security Management Server and continuously monitors supported Cloud Firewall deployments.

Its role includes cloud-native integration and automatic provisioning of autoscaling gateway solutions.

CloudGuard CNAPP, by contrast, is documented as a SaaS platform for unified cloud-native security across applications, workloads, networks, posture, and compliance.

It is managed through the Check Point cloud service rather than through the CloudGuard Controller process on the Security Management Server.

This article is about the CloudGuard Controller, not the entire CloudGuard portfolio.

What the CloudGuard Controller Actually Is

The CloudGuard Controller is a component of the Check Point Security Management Server.

It establishes a trusted relationship with a supported data center, uses the vendor API to poll the environment, learns changes to relevant objects and attributes, and sends applicable updates to Security Gateways.

According to the R82.10 documentation, the Controller can learn changes involving resources such as:

\* Subnets

\* Security groups

\* Virtual machines

\* IP addresses

\* Tags

\* Provider-specific cloud objects

The exact objects and properties available depend on the data-center connector.

AWS, Azure, GCP, Kubernetes, OCI, VMware, Nutanix, Proxmox, and other integrations do not expose identical object models.

Logical Architecture

The Controller is therefore part of the management and context-distribution plane.

It is not deployed inline in the traffic path.

Near Real Time Does Not Mean Instantaneous

The CloudGuard Controller documentation states that the Controller regularly polls connected environments.

This is a polling-based synchronization model, not a guarantee that every cloud event will be reflected on the gateway at the exact instant it occurs.

The default R82.10 configuration includes:

global.scannerInterval=30

autoUpdateIntervalInSeconds=30

enforcementUpdateIntervalTime=10

These values represent different stages of Controller processing:

\* `global.scannerInterval` controls the default delay between successful data-center scans when a connector-specific value does not override it.

\* `autoUpdateIntervalInSeconds` controls how frequently Management pulls imported object-property changes from the Controller.

\* `enforcementUpdateIntervalTime` controls the delay between gateway update cycles.

These defaults must not be added together and interpreted as a deterministic enforcement SLA.

Actual propagation time also depends on:

\* Cloud-provider API response time

\* Number of connected data centers

\* Number of discovered assets

\* Number of affected gateways

\* Controller and Management Server load

\* Retry behavior

\* Connectivity between Management and gateways

\* Connector-specific settings

The correct architectural description is therefore:

> CloudGuard Controller provides periodic, near-real-time synchronization of cloud context—not instantaneous event-driven enforcement.

The Rulebase Is Controlled; Object Membership Is Dynamic

A frequent misunderstanding is that CloudGuard Controller automatically rewrites the security policy.

That is not the normal operating model.

The administrator must still:

1. Configure the Data Center Server.

2. Create or import the applicable Data Center Object, or create a Data Center Query Object.

3. Place the object in the applicable rule.

4. Publish the management session.

5. Install the policy on the Security Gateway.

After this initial policy installation, changes in the IP membership represented by the object can be updated dynamically.

Security intent: Administratively controlled

Rulebase structure: Administratively controlled

Services and actions: Administratively controlled

Object membership: Dynamically updated

Cloud asset lifecycle: Controlled by the cloud platform

For example, the following rule does not need to be rewritten every time a matching virtual machine is replaced:

Source:

DCQ-PRD-PAYMENTS-BACKEND

Destination:

DCQ-PRD-SHARED-DATABASES

Service:

PostgreSQL

Action:

Accept

Track:

Log

The rule remains fixed.

The Controller updates which IP addresses currently belong to the source and destination query objects.

However, a change to the rule itself still requires normal publishing and policy installation.

There is also an important exception: when a Data Center Query uses All Data Centers and a new Data Center Server is later added, the documentation requires policy installation on gateways whose policy contains that query.

Imported Data Center Objects Versus Data Center Query Objects

Both object types can represent dynamic infrastructure, but they solve different policy-design problems.

Data Center Query Objects are supported on Security Gateway versions R81 and higher.

They can be created before or after the associated Data Center Servers and can operate across multiple data centers.

The R82.10 guide also explicitly states that Data Center Objects and Data Center Query Objects can be used in:

\* Access Control rules

\* Threat Prevention rules

\* HTTPS Inspection rules

Only regular Data Center Objects—not Data Center Queries—can be used in the Original Source and Original Destination columns of NAT rules.

How Data Center Query Logic Works

A Data Center Query can evaluate attributes such as:

\* Type in Data Center

\* Name in Data Center

\* IP address

\* Customer Tag

The logic model is:

Values inside one query rule = OR

Separate query rules = AND

The documentation uses a semicolon to separate OR values inside a query rule.

Conceptually:

Query Rule 1:

Type = Instance ; Load Balancer

AND

Query Rule 2:

Customer Tag = server_type=prod_app ; server_type=prod_db

This query represents:

(Type = Instance OR Type = Load Balancer)

AND

(Tag = server_type=prod_app OR Tag = server_type=prod_db)

All matching object IP addresses are then updated on the applicable Security Gateway.

Practical Multi-Cloud Example

Assume an organization uses AWS and Azure for the same payment platform.

The cloud team applies this taxonomy:

environment = production

application = payments

role = backend

owner = digital-banking

A possible Data Center Query design is:

Object name:

DCQ-PRD-PAYMENTS-BACKEND

Data Centers:

AWS-PRODUCTION

AZURE-PRODUCTION

Query Rule 1:

Type in Data Center = Instance ; Virtual Machine

Query Rule 2:

Customer Tag = environment=production

Query Rule 3:

Customer Tag = application=payments

Query Rule 4:

Customer Tag = role=backend

The exact Type values must be selected from the values exposed by each configured connector.

Object types are provider-specific, so an administrator should not assume that AWS, Azure, GCP, and Kubernetes use identical names.

Before using the query in production:

1. Publish the query.

2. Reopen the Query Rules section.

3. Use the preview function.

4. Verify every returned asset.

5. Add the query to the rulebase.

6. Install policy.

7. Test creation, replacement, removal, and retagging of a controlled workload.

A query that technically works but returns unintended assets is still a security-policy failure.

Tags Become Part of the Security Boundary

Once tags influence firewall membership, tags are no longer merely inventory metadata.

They become an authorization input.

For example, consider this rule:

Source:

application=payments

environment=production

Destination:

database-tier

Service:

PostgreSQL

Action:

Accept

A cloud administrator who can change an arbitrary workload to:

application=payments

environment=production

may indirectly cause that workload to match the firewall rule.

The Azure integration documentation explicitly warns that users who can change Azure resource tags can change their access permissions when those tags are used by security policy.

Required Governance Controls

Organizations using tag-based enforcement should implement:

\* Cloud IAM restrictions on who can create and modify security-relevant tags

\* Separate administrative permissions for descriptive and security-sensitive tags

\* Mandatory tag schemas

\* Controlled values instead of free-form values

\* Infrastructure as Code for production tagging

\* Pull-request or pipeline approval for security-relevant changes

\* Cloud audit logging for tag modifications

\* Alerts for unauthorized or unexpected tag changes

\* Periodic reconciliation between CMDB, cloud inventory, and firewall query membership

A useful classification is:

Descriptive tags:

cost-center

business-owner

project-name

Operational tags:

backup-policy

patch-group

monitoring-profile

Security-sensitive tags:

environment

application

security-zone

data-classification

exposure

access-role

Security-sensitive tags should be protected with the same seriousness as firewall-object changes.

Check Point also recommends avoiding sensitive information such as employee names or email addresses in cloud tags, virtual-machine names, and related objects.

Important Tag-Matching Nuance in the R82.10 Documentation

The R82.10 Data Center Query section states that tag evaluation is case-insensitive and gives `KEY=VALUE` and `key=value` as matching examples.

However, the limitations section separately states that, for Azure, the CloudGuard Controller can treat tag keys and values with different case as separate entries in SmartConsole.

Because these two statements create an implementation ambiguity, the secure operational approach is:

1. Enforce a single tag-casing standard.

2. Avoid relying on case normalization.

3. Validate query results with the preview function.

4. Test the behavior against the installed R82.10 CloudGuard Controller self-updatable package.

5. Consult Check Point Support before designing policies that depend on case equivalence.

For example, do not allow all of the following in the same organization:

environment=production

Environment=Production

ENVIRONMENT=PRODUCTION

environment=Production

Select one canonical format:

environment=production

Conclusion

CloudGuard Controller enables security policies to reference dynamic cloud context instead of relying exclusively on static IP addresses.

However, the architecture only works safely when several principles are respected:

\* The Controller, CME, CNAPP, and Cloud Firewall gateways must be treated as separate components.

\* Synchronization must be described as polling-based and near real time.

\* The rulebase remains administratively controlled.

\* Imported objects and Query Objects have different capabilities and limitations.

\* Query logic must be tested before production use.

\* Tags that influence policy must be governed as security-sensitive authorization inputs.

In Part 2, we will examine how this context reaches Security Gateways, including Identity Awareness, Identity Web API, PDP/PEP Identity Sharing, TTL expiration, monitoring, troubleshooting, known limitations, implementation phases, and operational metrics.