FWIW, I ran the exact question you had through fully licensed MS Copilot AI and below is what it came up with...
Hi Michael — great question, and you’re right to think about least-privilege up front.
A key first point (because it influences permissions): Unimus primarily backs devices up by logging in (SSH/Telnet) and running the vendor-appropriate “show/export config” CLI commands, using the credentials discovered during its discovery phase.
So in many environments, Unimus does not actually need SCP/SFTP to pull configs (unless you build a custom flow that generates a file and then transfers it, or you’re using a product/driver that works that way). Unimus also supports overriding the built‑in driver behavior with Custom Backup Flows, and you can enable debug logging to see exactly which commands it runs during backup. [wiki.unimus.net] [wiki.unimus.net]
Below is a practical way to think about permissions for Check Point Gaia appliances.
1) Decide what you’re backing up (Gaia OS config vs. “real” Check Point policy/database)
Unimus will happily collect device configuration text, which for Gaia commonly means the Gaia OS configuration (interfaces, routing, etc.).
However, for Security Management Servers, the “important backup” is often the management database/policy export (e.g., migrate tools), which is a different workflow from “show configuration.” Check Point’s own upgrade/backup guidance distinguishes these (e.g., migrate exports for Management Server, snapshots/backups for gateways). [wiki.unimus.net] [sc1.checkpoint.com]
Why this matters:
2) Understand Check Point Gaia permissions (RBA) and what’s “sensitive”
Gaia has a Role Based Administration (RBA) system with predefined roles:
- adminRole = full read/write access to all features
- monitorRole = read-only access to all features [sc1.checkpoint.com]
Check Point also explicitly calls out “power features” that effectively elevate privileges (even if assigned read-only). These include:
- Display Configuration (
configuration) – show/save/load Gaia OS configuration
- Backup (
backup) – create/restore backups
- Expert Mode (
expert), cron, etc. [support.ch...kpoint.com]
There’s even a documented warning that adding some of these features to a role can present as “equivalent to adminRole” (cosmetic warning, but still a strong hint to treat these as high-impact). [support.ch...kpoint.com], [support.ch...kpoint.com]
Bottom line: if Unimus’ Check Point driver uses show configuration, you will likely need the configuration feature, which Check Point considers sensitive. [support.ch...kpoint.com], [support.ch...kpoint.com]
3) Recommended approach: a dedicated “Unimus backup” user with a tight RBA role (CLI-only)
A. Create a custom RBA role with only what Unimus needs
Check Point’s Gaia documentation shows the syntax pattern for roles like:
Example from Check Point docs:
add rba role NewRole domain-type System readonly-features vpn,ospf,rba readwrite-features snmp [sc1.checkpoint.com]
For Unimus, start with CLI-only + read-only, and include only the minimum features required for config retrieval, typically:
⚠️ Note: assigning configuration is powerful in Gaia’s model. Treat this account as privileged and protect it accordingly. [support.ch...kpoint.com], [support.ch...kpoint.com]
B. Restrict access mechanisms to CLI only
Gaia roles can restrict which access mechanisms a user can use (Gaia Portal vs Gaia Clish).
So make the Unimus user CLI-only unless you have a specific reason for Web UI access. [sc1.checkpoint.com], [sc1.checkpoint.com]
C. Avoid Expert Mode
Expert mode exists because clish is intentionally restrictive; Check Point notes clish is a restrictive shell and Expert mode provides broader low-level command access.
Check Point also recommends that to block Expert mode, don’t include “power features” like expert in the role. [sc1.checkpoint.com] [support.ch...kpoint.com]
4) If you really do need SCP/SFTP: use a separate, file-transfer-only account (and lock it down)
If your design is “generate a file on the appliance, then pull it via SCP/SFTP,” Check Point’s guidance for SCP connectivity includes:
- The connecting user’s default shell must be
/bin/bash for SCP clients in their documented approach [sc1.checkpoint.com]
- On gateways/clusters, the Access Control policy must allow the SCP connection, and you should limit sources to known internal hosts [sc1.checkpoint.com]
- They recommend a dedicated SCP user with permissions only to its home directory [sc1.checkpoint.com]
There’s also a community best-practice pattern to create a dedicated “scpuser” instead of changing the admin shell (example uses /usr/bin/scponly for tighter file transfer posture). [community....kpoint.com]
✅ Best practice here is two accounts:
- Unimus CLI backup user (RBA-limited, no file transfer requirement)
- SCP-only user (home-dir only, source-restricted, used only if you must pull files)
This separation prevents your config-backup process from also becoming a general-purpose file transfer foothold.
5) How to verify least privilege (don’t guess—observe)
Because Unimus’ exact behavior can vary by driver/version and by what it discovers, the fastest way to nail permissions is:
- Enable Unimus device output logging / debug, run discovery+backup once, and inspect what commands it tried. [wiki.unimus.net]
- Add only the missing Gaia “features” to the role until backup succeeds.
- Keep a record of the final role feature list as your standard.
This avoids over-granting permissions “just in case.”
6) Quick checklist (security hardening for “outside-in” backups)
