Network Config Management backups question

michaelhd — Thu, 15 Jan 2026 23:53:10 GMT

We are starting a centralized config backups project, using a configuration management product called Unimus. They list Check Point appliances under their supported products list. The product works based on a discovery process using credentials and it sucks the configs off of the devices using sftp/ssh/scp.

I do not have any experience configuring "outside-in" backups like this. Anyone have any tips or documentation regarding this type of config? Specifically, what level of access to give to the "backup user" account?

https://wiki.unimus.net/pages/viewpage.action?pageId=10092755

https://unimus.net

Thank you,

Michael

Re: Network Config Management backups question

the_rock — Fri, 16 Jan 2026 00:12:40 GMT

I dont see Check Point listed in the first link you provided. If this is supported, I would give it full permissions.

Sorry, my bad...I thought it was alphabetically listed, did not notice they had Cisco listed before Check Point.

Re: Network Config Management backups question

emmap — Fri, 16 Jan 2026 00:35:45 GMT

If their product runs a Gaia backup then I imagine their login will need to be a full bash login, but if they're just scraping the clish config out then it probably just needs a read only clish login. From a very quick poke around their wiki there it seems like it's more of a clish config thing than a full backup thing, so I guess keep that in mind if you do any config changes that aren't in clish.

Re: Network Config Management backups question

the_rock — Fri, 16 Jan 2026 00:37:36 GMT

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:

If you only need Gaia OS config text, you can usually give a restricted Gaia RBA role. [sc1.checkpoint.com], [sc1.checkpoint.com]
If you need management DB exports, you’re typically in Expert mode tooling territory and permissions expand (often to full admin-level features). (At minimum, some tooling explicitly requires Expert mode). [sc1.checkpoint.com], [sc1.checkpoint.com]

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:

Plain Text

add rba role <RoleName> domain-type System readonly-features <...> readwrite-features <...>

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:

configuration (only if your backup method requires show configuration) [support.ch...kpoint.com], [support.ch...kpoint.com]
optionally version or asset if discovery/driver needs those (you’ll confirm via Unimus debug logs) [wiki.unimus.net]

⚠️ 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)

Use a dedicated account (never shared admin). Gaia explicitly supports granular RBA roles per user. [support.ch...kpoint.com], [sc1.checkpoint.com]
CLI-only access for the Unimus account unless there’s a real need for Portal. [sc1.checkpoint.com], [sc1.checkpoint.com]
Do not grant Expert Mode (expert) to the backup user. [support.ch...kpoint.com], [sc1.checkpoint.com]
If SCP is used, source-restrict it in policy and prefer a dedicated SCP user. [sc1.checkpoint.com]
Remember that configuration / backup are considered “power features” in Gaia—treat credentials like privileged secrets. [support.ch...kpoint.com], [support.ch...kpoint.com]

Re: Network Config Management backups question

Vincent_Bacher — Fri, 16 Jan 2026 07:23:41 GMT

If you have test devices or a lab of some kind, the easiest way to find out is to just test it! 🙂

Downloads | Unimus by NetCore j.s.a.

Re: Network Config Management backups question

michaelhd — Mon, 26 Jan 2026 19:50:44 GMT

Thanks all. Much appreciated.

Re: Network Config Management backups question

the_rock — Mon, 26 Jan 2026 20:22:06 GMT

Glad we can help.

topic Re: Network Config Management backups question in Firewall and Security Management

Network Config Management backups question

Re: Network Config Management backups question

Re: Network Config Management backups question

Re: Network Config Management backups question

1) Decide what you’re backing up (Gaia OS config vs. “real” Check Point policy/database)

2) Understand Check Point Gaia permissions (RBA) and what’s “sensitive”

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

B. Restrict access mechanisms to CLI only

C. Avoid Expert Mode

4) If you really do need SCP/SFTP: use a separate, file-transfer-only account (and lock it down)

5) How to verify least privilege (don’t guess—observe)

6) Quick checklist (security hardening for “outside-in” backups)

Re: Network Config Management backups question

Re: Network Config Management backups question

Re: Network Config Management backups question