Access and permissions

Give a team the access its work requires.

Configure a Linux team to request changes to its own rules, with a separate Security team reviewing those requests. The example changes Comments on one existing Access Control rule, using accounts with no deployment-wide rule access.

1. Understand what each access setting controls

User: A person who can sign in to your installed Naradox deployment. Their current account, roles, team memberships, and grants determine their access.
Team: A named group of users. It can own firewall scopes, receive grants, or be selected to review requests. Creating a team alone gives it no firewall access.
App role: A set of administrative or deployment-wide permissions. No app role is sufficient for users who work through a grant or firewall scope, and for explicitly selected reviewers.
Firewall scope: A team-owned block in a particular connector instance, policy package, and layer. Its verified section boundaries determine the current rules covered; its settings control fields, objects, and the change workflow.
Grant: An assignment to selected users or teams. For existing-rule access, an exact-rule grant identifies one rule in its policy context and defines the permitted fields, objects, and workflow.
Reviewer selection: The users, teams, or roles explicitly chosen in a change workflow. Reviewers can inspect the relevant request and decide on it without joining the owning team or receiving general rule-edit access.

Use the access controls inside your deployment. Roles in the naradox.com customer portal govern portal tasks such as downloads and billing; they do not grant installed-product permissions.

Access is additive: a narrow scope or grant does not reduce broader rights from an app role, another grant, or another team scope. Check the account's complete access when testing a restriction.

2. Prepare the accounts and two teams

Start with an installed, licensed deployment and a configured Check Point connector; see Connect Check Point. Agree the target package, layer, pilot rule, and intended comment update with your firewall administrator.

For this manually controlled pilot, have the connector administrator confirm Enable auto-install is off under the instance's Auto-install settings in Platform > Connectors. Connector auto-install can schedule policy installation after a publication independently of the operator's manual installation permission.

An Administrator can complete this setup. In a separated administration model, an Identity manager prepares accounts and an Access governance administrator manages teams, grants, and scopes. Assigning app roles requires separate role-assignment authority. Reviewing and binding existing scope boundaries additionally requires rule-edit authority.

Open Identity & Access > Users. Prepare an active account for each Linux operator and Security reviewer. Use Add user > Invite user with configured email delivery, Local account, or your deployment's existing Entra sign-in process. See account preparation for the prerequisites.
Use No app role for the pilot operators and reviewers. Confirm that each can sign in and complete any required MFA. Check for existing grants or memberships that would give these accounts broader access.
Open Identity & Access > Teams and choose Create team. Enter Linux, select the operators under Team members, and create the team.
Create a separate Security team with the intended reviewers. Include at least one active person other than the requester. Use your existing teams if these names are already in use.

Expected result: the operator belongs to Linux and the reviewer belongs to Security. Security does not need membership of Linux. The scope and reviewer configuration below supply their respective access.

3. Choose a verified block of rules

Open the Linux team and its Firewall scopes. Prefer an existing reviewed pilot scope containing the intended rule. Confirm the connector instance, policy package, Access Control type, and layer. Use Check scope boundaries in the scope's Actions menu to inspect its live section boundaries.

If you need a new scope

Creating a scope provisions and publishes new section boundaries in Check Point. It creates a new block; it does not automatically include the pilot rule. Agree this firewall change and its placement with the firewall administrator before saving.

Choose Add scope. Under Policy target, select Instance, Policy, Policy type: Access Control, and Layer. The connector needs its configured write API key to provision the scope.
Enter the agreed Rulebase section name (creation only) and After rule number. Keep existing-rule fields at view for this preparation step.
Leave rule creation and policy installation disabled. Turn off Rule logs for this team scope and Watchlist for this team scope for this pilot. Read-only rule fields do not need object-management permissions.
Choose Save scope and wait for provisioning to finish successfully. A scope still provisioning or reporting failure is not ready for delegation.
Have the firewall administrator prepare a suitable pilot rule inside the new block through your normal reviewed firewall-change process. Rule order affects policy behavior, so choose the position deliberately. After publication, refresh and verify the scope's contents.

Scope membership follows the live rules between its verified boundaries, including reachable inline layers. Rules added inside receive the scope's permissions; rules moved outside lose that scope's access. Missing, replaced, or reversed boundaries block operations. Matching section names alone do not establish authority.

4. Limit the editable fields and separate object rights

Edit the chosen scope. In this example, Linux may update the pilot rule's Comments to record an agreed maintenance owner or reference. Configure the settings below, then select the reviewers in the next section before saving.

Confirm Scope enabled is selected and any Expires date allows the pilot to run.
Under Existing rule access, set the applicable fields to view, then set Comments to edit. Use hidden when a field should be withheld. These settings apply across the scope, so verify that its other rules may receive the same access.
Keep Allow creating rules, policy installation, Rule logs, and Watchlist disabled for this example. Updating Comments needs no object creation, editing, or deletion permission.

view reveals a field without allowing edits; edit allows permitted changes subject to the workflow. Approval does not override field restrictions.

When you later allow object-reference changes

Editable fields such as Source, Destination, and Service also need an object boundary. Under Object permissions, use Selected Check Point objects and Browse to choose the exact existing objects the team may use. An empty selection does not authorize arbitrary existing objects. All Check Point objects makes supported objects available except explicit exclusions; switching modes clears draft selections and exclusions.

Allow creating objects, Allow editing objects, and Allow deleting objects are separate capabilities. Selecting an existing destination in a rule does not require permission to change that object's definition. Keep these capabilities disabled unless their wider impact is part of the agreed task. Follow Manage Check Point objects when extending the pilot to object selection or lifecycle management.

5. Require an independent Security review

Review any existing approval requirements first. Reuse the intended Security requirement when present, and retain additional reviews required by your organization. For a dedicated pilot scope, configure one Security requirement as follows; any other saved requirements must also be satisfied.

In the same scope editor, open Change workflow and choose Edit flow: Approval.
Use the intended requirement, or choose Add approval requirement when it is missing. Set Required approvals to 1 for this pilot's Security review.
Set Identity type to Teams, then select Security under Approval by, using search or Browse.
Review the field access and reviewer requirement together, then choose Save. Resolve any validation error before testing the operator account.

Every active current member of the selected Security team is eligible to review, except the requester. This example has no self-approval exception. Can approve own request is available only for an individually selected user and should remain off when independent review is required.

A single requirement combines its selected identities into one reviewer pool. If you later need one approval from Security and one from another team, create two separate requirements. All requirements must be met, and each person can fill only one required approval across the request.

Selected reviewers do not need Global change supervisor. That role provides broad request visibility and rejection authority; approval still requires explicit selection in the applicable workflow. Direct (no approval) queues permitted changes without a review requirement, so leave this pilot on Approval.

6. Check access from each participant's account

Test with the limited accounts rather than the administrator account. Separate browser profiles help keep the operator and reviewer sessions distinct.

Linux operator: open Workspace > Team rules and select the Linux scope. The intended rule and visible fields should appear. Comments should be editable, while fields set to view remain read-only.
Scope boundary: rules outside the block should not become available through this scope. If the account sees broader access, check its other team memberships, grants, and app role.
Separate capabilities: the pilot account should have no scope permission to create rules, change object definitions, or install policy.
Security reviewer: once Linux submits a request, the reviewer can open it in Changes, inspect its context and proposal, and approve or reject. Reviewer selection alone does not make Linux's scope available as an editable team scope.

Continue with Request and approve a change to submit the comment update and verify the applied result. Request participation does not grant access to the technical Jobs workspace. Policy installation remains a separate authorized action.

When to use an exact-rule grant

Choose a grant when a person or team needs an existing rule without taking responsibility for a whole section block. Under Identity & Access > Grants, an access administrator selects the exact rule in its connector, package, policy-type, and layer context, then assigns the intended users or teams. Configure field access, selected objects, and reviewers for that grant.

The recipient opens Workspace > Granted rules. A new neighboring rule does not become part of an exact-rule grant, and the grant does not allow creating rules. Follow the single-rule pilot for this alternative.

Deployment-wide Rulebase access is a different choice. Its app role supplies write authority, and approval-mode users need explicit reviewers under Users > Edit user > Access > Rulebase change workflow. Configure the grant or scope workflow when the work is delegated through that source.

Maintain access and resolve common problems

The operator cannot see the scope or rule: Check active team membership, Scope enabled, expiry, provisioning, and the selected connector/package/layer. Check the live section boundaries and confirm that the rule is published inside them. An exact grant appears under Granted rules instead.
The rule is visible, but the change is unavailable: Check the field's edit level and the selected objects. Existing-rule editing does not enable rule creation or object management. For a stale rule, pending request, or edit-lock problem, follow workflow troubleshooting.
A reviewer cannot approve, or the workflow cannot be saved: Check the explicit reviewer selection, active accounts, current team membership, and required approval count. Count different eligible people across all requirements, excluding the requester unless deliberately allowed. An administrator role alone does not satisfy a reviewer requirement.
The scope boundaries need attention: Use Check scope boundaries in the scope's Actions menu under the team's Firewall scopes. An administrator with access-management and rule-edit authority can review and bind the intended exact sections when required. Retry a failed verification with Check again; do not recreate sections just to match their names.

Review team membership, expiry, object choices, and reviewer availability whenever responsibilities change. Team reviewer targets follow current membership, so adding a member also makes that person eligible in workflows selecting the team. Changes to access or workflow can retire outstanding requests and require fresh submission. A running or unresolved change can block an affected access removal until an authorized operator finishes or reconciles execution.

If the issue remains, collect the affected account, scope or grant, policy context, and visible error without credentials or sensitive rule content. See what to include in a support request.