Walkthrough: Restricting permissions for a Compliance officer
This topic walks you through the process of setting up a Compliance officer, who is in charge of performing compliance analyses, and limiting permissions so that this user cannot perform other types of actions in BMC BladeLogic Server Automation (BSA). Although this process is not essential for compliance analysis, BMC always recommends that you grant users the minimum set of permissions needed to perform actions. If you do not set up a Compliance officer with a limited set of permissions, a superuser such as the BLAdmins role must perform compliance analysis.
This topic includes the following sections:
Introduction
This topic is intended for system administrators who manage data center authorizations. The goal of this topic is to grant the minimum set of permissions to the role and user who performs compliance analysis.
What are roles and users?
BSA manages data center access through a system of role-based access controls (RBAC). Each role defines a set of permissions. Typically roles correspond to jobs performed in an organization, such as QA testers or application developers. A user can be assigned to one or more roles, but a user can only assume one role at a time.
What does this walkthrough show?
This walkthrough shows how to:
- Create an authorization profile, which is a collection of authorizations to perform certain tasks — in this case to perform compliance analysis.
- Create a role for a Compliance officer.
- Create a Compliance user who is assigned to the Compliance officer role and thus is granted the permissions available to the Compliance officer.
What do I need to do before I get started?
For this walkthrough, you need to log in as the RBAC administrator for BSA (typically RBACAdmin or a user with equivalent permissions)
How to restrict permissions for a Compliance officer
Step | Example screen | |
---|---|---|
1 | Create an authorization profile for compliance analysis. An authorization profile is a collection of all authorizations needed to perform all compliance analysis tasks.
| |
2 | Still logged on as the RBAC administrator, create a role for Compliance management. Assign the authorization profile you just created to the role.
| |
3 | Still logged on as the RBAC administrator, create a Compliance user. Assign this user to the role you just created.
| |
4 | Grant the new role (that you created in step 2) permissions to read various global configuration files, global extended objects, and server objects that your component templates will test for compliance. (For example, many rules in the Compliance Content component templates check the compliance of global configuration files and global extended objects.)
|
Wrapping it up
Congratulations. You have set up a role for Compliance officers and created a Compliance user.
Where to go from here
Now that you have restricted access to the Compliance officer, you can continue to the next tasks in preparation for performing compliance analyses.
- If you want to use out-of-the-box compliance content to check for compliance with regulatory standards and best-practice policies, continue with the task described in Walkthrough: Loading compliance content.
- To prepare your own component templates for compliance analysis, see Walkthrough: Creating a compliance template.
Comments
Sandeep Das, I modified the list of minimum authorizations based on your comment. Let me know if this looks OK. Thanks for the great feedback!
A Compliance Officer will need ConfigFile.Read permission to open any Red Hat CIS template. (E.g. CIS - Red Hat Enterprise Linux 6).
The CIS component templates are part of the product and the permissions listed here should allow a user to work with BMC provided templates.
Can you please test whether the permissions listed on this page will allow a Compliance Officer to work with all the component templates that are shipped with BMC Compliance Content Installer?
BMC recommends to not use BLAdmin role for everyday tasks but I've found way too many instances of permissions for specialized roles not being documented properly.
Hi, Sandeep. I added ConfigFile.Read with a parenthetical remark to indicate that it's commonly needed when using Compliance Content templates. I added a similar parenthetical remark to a couple of other bullets, as well. As always, thanks for the great feedback!
Thanks Yechezkel.
Hi Sandeep,
I made more changes on the page. I modified the list in step 1 some more. More importantly, we identified a gap in the procedure here and I added another task (step 4) for granting the role read permissions on objects in the Configuration Object Dictionary.
Thanks!
Thanks Yechezkel. It looks like only the Windows Configuration Objects have the Everyone > ConfigFile.Read permission by default. Configuration Objects for other OS do not have this permission and updating them one by one is tedious as there are over 100 objects. It is possible to update the permissions in bulk and the steps here should mention that. Set filters to "Configuration Objects" and "All Operating Systems". Select all objects, right click and select Update Permissions.
Repeat for Extended Objects and Server Objects. Although, ideally all objects should have the Everyone.Read permission by default just like the Windows configuration objects. Is it possible to get the development team to update the default permissions and remove the need for the post install configuration?
And you've added ConfigFile.Read, ExtendedObjects.Read and ConfigurationObjectClass.Read permissions to the actual objects. Yet, the permission list for the compliance officer role has ConfigFile.*, ExtendedObjects.* and ConfigurationObjectClass.* permissions. The role should only have the minimum permissions required to perform the job.
Hi Sandeep,
To address the three points in your last comment:
Thanks so much for all the feedback!
Regards,
Yechezkel