Enhancing NetWorker Security: A theoretical architecture

It’s fair to say that no one backup product can be all things to all people. More generally, it’s fair to say that no product can be all things to all people.

Security has had a somewhat interesting past in NetWorker; much of the attention to security for a lot of the time has been to with (a) defining administrators, (b) ensuring clients are who they say they are and (c) providing access controls for directed recoveries.

There’s a bunch of areas though that have remained somewhat lacking in NetWorker for security. Not 100% lacking, just not complete. For instance, user accounts that are accessed for the purposes of module backup and recovery frequently need higher levels of authority than standard users. Equally so, some sites want their <X> admins to be able to control as much as possible of the <X> backups, but not to be able to have any administrator privileges over the <Y> backups. I’d like to propose an idea that, if implemented, would both improve security and make NetWorker more flexible.

The change would be to allow the definition of administrator zones. An “administrator zone” would be a subset of a datazone. It would consist of:

1. User groups:
   • A nominated “administrator” user group.
   • A nominated “user” user group.
   • Any other number of nominated groups with intermediate privileges.
2. A collection of the following:
   • Clients
   • Groups
   • Pools
   • Devices
   • Schedules
   • Policies
   • Directives
   • etc

These obviously would still be accessible in the global datazone for anyone who is a datazone administrator. Conceptually, this would look like the following:

The first thing this should point out to you is that administrator zones could, if desired, overlap. For instance, in the above diagram we have:

1. Minor overlap between Windows and Unix admin zones (e.g., they might both have administrative rights over tape libraries).
2. Overlap between Unix and Oracle admin zones.
3. Overlap between Windows and Oracle admin zones.
4. Overlap between Windows and Exchange admin zones.
5. Overlap between Windows and MSSQL admin zones.

Notably though, the DMZ Admin zone indicates that you can have some zones that have no overlap/commonality with other zones.

There’d need to be a few rules established in order to make this work. These would be:

1. Only the global datazone can support “<x>@*” user or group definitions in a user group.
2. If there is overlap between two zones, then the user will inherit the rights of the highest authority they belong to. I.e., if a user is editing a shared feature between the Windows and Unix admin zones, and is declared an admin in the Unix zone, but only an end-user in the Windows zone, then the user will edit that shared feature with the rights of an admin.
3. Similarly to the above, if there’s overlap between privileges at the global datazone level and a local administrator zone, the highest privileges will “win” for the local resource.
4. Resources can only be created and deleted by someone with data zone administrator privileges.
5. Updates for resources that are shared between multiple administrator zones need to be “approved” by an administrator from each administrator zone that overlaps or a datazone administrator.

Would this be perfect? Not entirely – for instance, it would still require a datazone administrator to create the resources that are then allocated to an administrator zone for control. However, this would prevent a situation occurring where an unprivileged user with “create” options could go ahead and create resources they wouldn’t have authority over. Equally, in an environment that permits overlapping zones, it’s not appropriate for someone from one administrator zone to delete a resource shared by multiple administrator zones. Thus, for safety’s sake, administrator zones should only concern themselves with updating existing resources.

How would the approval process work for edits of resources that are shared by overlapping zones? To start with, the resource that has been updated would continue to function “as is”, and a “copy” would be created (think of it as a temporary resource), with a notification used to trigger a message to the datazone administrators and the other, overlapping administrators. Once the appropriate approval has been done (e.g., an “edit” process in the temporary resource), then the original resource would be overwritten with the temporary resource, and the temporary resource removed.

So what sort of extra resources would we need to establish this? Well, we’ve already got user groups, which is a starting point. The next step is to define an “admin zone” resource, which has fields for:

1. Administrator user group.
2. Standard user group.
3. “Other” user groups.
4. Clients
5. Groups
6. Pools
7. Schedules
8. Policies
9. Directives
10. Probes
11. Lockboxes
12. Notifications
13. Labels
14. Staging Policies
15. Devices
16. Autochangers
17. etc.

In fact, pretty much every resource except for the server resource itself, and licenses, should be eligible for inclusion into a localised admin group. In it’s most basic, you might expect to see the following:

nsradmin> print type: NSR admin zone; name: Oracle
               type: NSR admin zone;
               name: Oracle;
     administrators: Oracle Admins;
              users: Oracle All Users;
  other user groups: ;
            clients: delphi, pythia;
             groups: Daily Oracle FS, Monthly Oracle FS,
                     Daily Oracle DB, Monthly Oracle DB;
              pools: ;
          schedules: Daily Oracle, Monthly Oracle;
           policies: Oracle Daily, Oracle Monthly;
         directives: pythia exclude oracle, delphi exclude oracle;
...etc...

To date, NetWorker’s administration focus has been far more global. If you’re an administrator, you can do anything to any resource. If you’re a user, you can’t do much with any resource. If you’ve been given a subset of privileges, you can use those privileges against all resources touched by those privileges.

An architecture that worked along these lines would allow for much more flexibility in terms of partial administrative privileges in NetWorker – zones of resources and local administrators for those resources would allow for more granular control of configuration and backup functionality, while still keeping NetWorker configuration maintained at the central server.