Many MFT server deployments are being managed by multiple administrators. But because these admins usually have different tasks and responsibilities, there's been a growing clamor for greater granularity when delegating admin privileges. That granularity has finally arrived.
Why you need more flexibility in delegating administrative privileges
Having more flexibility over what access rights and privileges are granted to your administrators will help you apply the principle of least privilege. That is, assigning admins only the privileges they need to carry out their specific administrative duties. This principle is a vital element in governance, information security and regulatory compliance.
Laws and regulations like SOX, HIPAA, and PCI DSS, all contain provisions requiring restrictions on administrative privileges. Granting unlimited admin capabilities to individuals can pose a huge risk. Doing so would increase the impact of a misconfiguration or even a data breach due to either an innocent oversight or a deliberate action.
Let me give you a couple of examples.
If an administrator accidentally misconfigures a setting that somehow prevents users from connecting to your server, that little mistake can result in some serious company-wide downtime. But if that admin only had control over users from say a particular geographic region, then users in other regions wouldn't be affected.
In the same manner, if an admin with malicious intentions creates a trigger that would automatically divert sensitive data to a remote server, his actions will have limited impact if his access rights and privileges are also limited.
Limiting privileges of admin accounts also mitigates risk in the event any of these accounts' login credentials fall into the wrong hands.
In previous versions, we provided JSCAPE MFT Server administrators the ability to create domain administrators and assign certain tasks to them. Those domain admins had fewer capabilities than full-fledged admins and only had jurisdiction over their respective domains.
However, as it turned out, many of our customers wanted even greater granularity. That's why, starting JSCAPE MFT Server version 9.3, we introduced what we call Administrative Roles and Administrative Tags. Let's talk about Administrative Roles first.
When you create an admin account in 9.3, you'll be given the option to assign a Role to that account. Administrative Roles are a way for you to restrict administrative access to areas in your managed file transfer server using domain, module and tagged data as criteria.
For example, you may wish to create an administrative role that allows an administrator to only see Triggers for a specific domain. Another example might be an administrative role that limits the Users that an administrator can see to those tagged users within a specific geographic region. Administrative roles may be managed from the Roles tab in the administrative user interface.
Each Role comes with two sets of permissions: Global Permissions and Domain Permissions. You can set these permissions when you create or edit a Role by clicking either the Add or Edit buttons shown in the screenshot above.
Domain permissions refer to those permissions that only apply to a specific domain, while Global Permissions are those that aren't domain-specific.
Global Permissions apply mostly to settings found in Server > Settings and Server > Key Manager. So this is where you set permissions to settings for the Manager Service, Datastore, JDBC Drivers, Web Service, Email Service, and Key Manager, to mention a few.
For most of these settings, you'll be able to grant either Read only permissions or allow also Write permissions. So, for example, you can choose whether to allow the admin to only read the settings in the Manager Service screen, or to also grant the admin the ability to change (write) those settings.
If you don't choose either a Read or Write for a Global Permission, then JSCAPE MFT Server will simply deny access to all settings associated with that particular Global Permission. All Global Permissions have this setting (i.e., no access) by default.
Domain permissions define those functions that an administrative user can perform for one or more domains. These permissions must be explicitly defined (i.e. if a role is not assigned permissions for a domain then administrative users assigned to that role will not be able to access that domain).
To grant a Role permissions to a domain, you simply add that domain to the Role.
Once you've added a domain to a Role, you can then set specific Permissions for that domain.
Basically, you can set permissions for all modules in a domain. So, for example, you can set permissions for the Services, Reports, AS2 Messages, DLP, Connections, Triggers, Accounts, and Trading Partners modules.
Again, you can choose between a Read or Write permission, wherein Write means you can both view the settings AND edit them. Like the Global Permissions, the Domain Permissions don't have any permission settings selected by default. That means, if you don't choose either a Read or Write permission for a particular module, then the admin assigned to the Role in question would be denied access to that particular module. Or if you don't assign a permission to any module at all, then the admin assigned to the Role in question won't be able to do anything in that domain!
For more information on creating and managing Administrative Roles, read this part of the online documentation.
Administrative Roles alone already provide extensive flebility in managing administrative privileges. But our developers didn't stop there. In our next post, we'll talk about Administrative Tags, which adds even greater granularity in managing admin privileges. Stay tuned for that.
In the meantime, you might want to try the latest version of JSCAPE MFT Server, which already supports Administrative Roles and Administrative Tags. JSCAPE MFT Server comes with a FREE, fully-functional evaluation edition, which you can download right now.