Security planning
Review the following topics for information about how BMC Database Automation provides security and for recommendations on deploying securely:
Security overview
Security within the BMC Database Automation product is comprised of robust authentication mechanisms, flexible and granular Role Based Access Controls (RBAC), and comprehensive monitoring. This makes BMC Database Automation well suited for complex enterprise organizations, such as financial institutions or service providers, where portions of the database infrastructure are managed by different teams that must operate autonomously due to regulatory separation of duty policies.
BMC Database Automation is handled at multiple tiers:
- Using the management GUI, users can access the web interface based on the product's RBAC mechanisms.
- At a transport level, all of the communications between the management server and the agents are encrypted using SSL, with both server and client certificates being presented. This means that a malicious party cannot masquerade as an agent nor a manager, and that all of the communications are secured against third-party discovery or injections.
- Application-level security is provided by encryption and digital signatures of all of the workflow libraries on the management server (these libraries are what interpret, for example, how to run the Oracle installer), with the keys embedded in the management server code and the agent. This prevents a malicious party from gaining privileged access to the management server and modifying the instructions the management server sends to the agents.
All of the commands that are run are centrally logged and audited on the management server. For any job that is run, a user with the correct privileges can bring up a log file with the commands, arguments, outputs, and associated log files. For information about this and other security-based administrative tasks that can be managed and configured in BMC Database Automation, see Performing-security-administration-tasks.
Security assessment FAQs
Question | Response |
---|---|
Does product development follow a Security Development Lifecycle (SDL) Process? | No. The BMC Database Automation product does not follow a formal SDL process. However, many aspects of the SDL process are done during our development lifecycle and are documented as follows. |
Do you conduct security reviews? If so, what? | Yes. Security-related product testing is done as part of each release. In addition, the BMC AppSec team performs penetration and other security tests on our product prior to each release. |
Do you use any tools to test for vulnerabilities? | Yes. Although most of of the testing is done manually, the BMC AppSec team also uses Burp Suite(Pro), a web proxy tool. |
Can you provide the results of these vulnerability reviews performed? | Yes. We can provide the report from the BMC AppSec team upon request. |
Have you closed on vulnerabilities found for the subject application using these application security reviews? | Yes. All High/Severe issues are required to be closed before releasing the software as part of our Quality Certification (QCert) checkpoint; low/medium issues are reviewed and assessed on a case-by-case basis. |
Are you committed to perform regular security reviews of the application and resolving vulnerabilities identified? | Yes, BMC is committed to resolve all Common Vulnerability Scoring System (CVSS) High and Critical vulnerabilities found in our code and remediate any found in 3rd party components we include and ship with our product. BMC's AppSec team performs regular penetration tests during the product's release lifecycle. See www.bmc.com/security for BMC's disclosure and alert details. BMC and the BMC Database Automation product are committed to monitor, find, and resolve security-related product issues both during our release process and after releases are available to customers. For the BMC Network Automation Product:
|
Is the product FIPS-140 compliant? | No. |
What type of encryption is used for storing sensitive data? | Communication between the management server and the agents are encrypted using SSL, with both server and client certificates being presented. This means that a malicious party cannot masquerade as an agent nor a BMC Database Automation manager, and that all of the communications are secured against third-party discovery or injections. |
What kind of encryption is used when the database is not fully encrypted, for example, when using Oracle? | Application-level security is provided by encryption and digital signatures of all of the workflow libraries on the management server (these libraries are what understand, for example, how to run the Oracle installer), with the keys embedded in the management server code and the agent. This prevents a malicious party from gaining privileged access to the management server and modifying the instructions the management server sends to the agents. Users can be centrally authenticated against LDAP or AD, so when a user leaves the company, simply disabling their user in AD will prevent them from logging in to the GUI. |
Role Based Access Control (RBAC)
RBAC, separate from the database server OS-level permissions, enable users to control access to execute commands in BMC Database Automation against servers where they do not have OS-level access. RBAC provides a mechanism for restricting user access and defining segregation of duties based on the concept of roles, groups, and capabilities, where BMC Database Automation users are members of groups and groups are assigned roles (which contains one or more capabilities). For more information about managing RBAC, see Managing-the-RBAC-access-controls.
Roles
A role is a collection of capabilities and is granted to groups. Fine-grained permissions in BMC Database Automation are managed by using capabilities which are activities and tasks that can be performed by using BMC Database Automation.
To create a role, see Creating-roles.
Capabilities
Capabilities are the built-in, permanent permissions that are associated with every task that can be performed in BMC Database Automation. They can be broken down into the following types:
- Global. Global capabilities are system-wide tasks that are not connected to domains. For a global capability to be enabled for a role, the role must belong to a group that has grants on the root domain (Grid). Most of the user administration capabilities are global capabilities.
- Domain. Domain capabilities are connected to domains. They are grouped into tabs that are seen when you manage the capabilities for a role.
To locate specific capabilities, perform any of the following actions:
- Select an option from the Type list to filter the table by capability type (Global or Domain).
- Select an option from the Category list to filter the table by a specific category displayed in corresponding tabs in the GUI, such as USER or Db2.
- Type a character string in one or more of the boxes to filter the list of capabilities (for example, typing us in the Description field displays all capabilities with User in the description.
- Click any column heading to sort this table or change sort direction.
Groups
A group consists of one or more users. Each group has roles assigned and is granted access to domains. A user can be a member of more than one group. Groups can be granted different roles in different domains or the same role in different domains. When more than one role is granted to the same group on the same domain, the result is cumulative capabilities.
To create a group, see Creating-groups.
Users
BMC Database Automation user accounts include the full name, user name, password and the groups in which a user is a member. Users must be members of a group to be granted permissions. The group membership for a user determines their assigned roles and granted domains. A user can be a member of more than one group.
To create a user, see Creating-users.
Security implementation examples
Typical enterprise level implementations of BDA include the setup of Roles and Groups that segregate the activities of engineering and operational DBAs. For example, engineering DBAs might only be allowed to create and test patch packages on non-production servers that are published to operational DBAs. As a result, the operational DBAs would only be able to apply or roll back patch packages to production servers but not modify those packages.
Another common example is for non-DBAs (such as DBA Managers) to be granted access to BMC Database Automation only to view DBA activity, check OS and database versions and physical CPU counts, or to run reports without the ability to initiate any other intrusive database-related activities (such as patching or provisioning).
Using calculated RBAC strategies enables Security Managers to operate under a secure and granular system access system that ultimately provides their security teams to operate according to pre-existing policies. Managers can start a RBAC security model with tight controls and then gradually transition the model to less stringent requirements by gradually loosening the permissions.
For example, they might start a model whereby all Oracle DBAs can see all Oracle servers for activities such as provisioning and patching, but not be able to view any Actions that have already been created. Over time, those Actions might be published to certain groups, users, and databases, according to specifications enforced by security teams and management.
Authentication
BMC Database Automation includes its own credential store internally by default. However, in a large enterprise implementation, it is very common to want to authenticate off of a central authentication mechanism.
BMC Database Automation provides the ability to authenticate off of LDAP or Active Directory, and to configure authentication settings including password expiration time and grace period, password complexity requirements, and password lockout policy. For more information, see Configuring-authentication.
Data security
All of the communications between the management server and the agents are encrypted using SSL, with both server and client certificates being presented. This means that a malicious party cannot masquerade as an agent nor a BDA manager, and that all of the communications are secured against third-party discovery or injections. All of the workflow libraries on the management server require digital signatures and are encrypted with the keys embedded in the management server code and the agent. This prevents a malicious party from gaining privileged access to the management server and modifying the instructions the management server sends to the agents.
Additional security considerations
The following sections detail additional measures you can take to ensure the security of your BMC Database Automation implementation.
Scanning for malicious files
It is possible to inadvertently upload malicious files to BMC Database Automation. Because of this risk, BMC strongly recommends that you scan upload directories for malicious files using anti-virus software before uploading any files to BMC Database Automation.
Disabling the Autocomplete browser feature
Browsers implement the Autocomplete feature that keeps track of information that has been recently and repetitively submitted, such as web addresses, information in forms (user name and passwords), and search queries. Enabling Autocomplete by default prevents the web browser from specifically caching the login_password fields. To disable the web browser Autocomplete feature, open the /app/clarity/dmanager/etc/d2500_config file on the Manager with a text editor and set prevent_password_auto_complete to true.
Related topic