14    Security Lifecycle Management

Implementing a security model is just the beginning. In this chapter, we’ll discuss how you can create processes and procedures to govern future changes and to promote those changes to other environments.

As mentioned throughout this book, SAP HANA is a development platform, which makes SAP HANA more than just a database. As a development platform, security administrators will discover that security-related development artifacts can be easily transported between different SAP HANA instances. In this chapter, we’ll outline the best practices and options available when using this transportation mechanism, so that you can maintain a consistent security model between SAP HANA instances. We’ll start by discussing how to maintain a consistent security model. Then, we’ll review the steps necessary to define a delivery unit containing security-related artifacts. You’ll use the delivery unit to transport security models between systems. We’ll then review the steps necessary to access the SAP HANA application lifecycle management tool. Finally, we’ll discuss additional features in SAP HANA application lifecycle management that can benefit the lifecycle management of security artifacts.

14.1    Maintaining a Consistent Security Model

Most organizations will maintain more than one instance of SAP HANA within their landscapes. Some organizations will need multiple instances to support multiple SAP application solutions, and others will need multiple instances to support lifecycle management within the same solution. Given the likelihood that an organization will have multiple unique or related instances, expecting security administrators to manually create security models for each unique environment isn’t practical. Fortunately, SAP HANA offers capabilities to easily transport repository-based content, including repository roles, between environments.

You’ll need to follow three sets of guidelines to ensure that your security models are both consistent and secure. The first practice involves lifecycle management best practices. The second governs how you make changes to the security model and conduct testing. The final practice centers on the policies and procedures required to maintain a consistent security model in each environment.

14.1.1    Best Practices

Security model lifecycle management encompasses the process, procedures, and tasks you’ll follow to ensure that your security model is secure and consistent in all environments. Because SAP HANA is also a development platform, built-in tools are available to help you manage and promote software code stored within its repository. Fortunately, many of your security artifacts, such as repository roles, are stored in this repository. To facilitate the management and promotion of the software code and security artifacts within SAP HANA, a tool called SAP HANA application lifecycle management is available as a web-based application hosted in the SAP HANA extended application services engine (XS engine). Note that, as of SAP HANA 2.0 SPS 04, the SAP HANA cockpit does not offer tools to help you manage the application lifecycle of artifacts hosted in the SAP HANA XS-based repository.

SAP HANA application lifecycle management allows you organization to both manage changes within the SAP HANA repository and promote those changes to other SAP HANA environments. In Section 14.2 and Section 14.3, we’ll discuss SAP HANA application lifecycle management in more detail, but in this section, we’ll discuss a few basic security model lifecycle management best practices. Securing an SAP HANA environment is only the first step. Once the environment is secured, you’ll need to follow strict policies and procedures to help maintain the security of the environment. Specifically, organizations should maintain multiple environments, create content in development, organize content effectively, cleanup unused content, have a rollback plan, and manage content dependencies. These best practices will help you formulate policies and procedures to facilitate security model and content lifecycle management. To further your understanding, let’s look at each of these items in more detail.

Maintaining Multiple Environments

A key dependency in the development, validation, testing, and implementation of a security model requires that organizations maintain multiple unique SAP HANA instances. Most organizations will deploy a development (DEV) environment in which they create content, security models, and other dependent content; a quality assurance (QA) environment in which they validate the promotion process and test content changes to application code; and a production (PROD) environment, which serves as the active environment in which your users work and execute business-related transactions.

The purpose of maintaining multiple environments is to identify issues with developed content or to identify issues related to configuration changes before they are implemented in production. As shown in Figure 14.1, the lifecycle management process for SAP HANA security follows a strict path from DEV to QA to PROD.

Figure 14.1    Lifecycle Management Process for SAP HANA Security

Creating Content in Development

Generating repository roles and their dependencies in a DEV environment is best. After the content is validated, this content should then be transported to a QA environment for further testing. We never recommend making security changes directly in production. Changes in production are untested and can lead to the accidental elevation of privileges or the exposure of sensitive data.

Organizing Content in Packages

SAP HANA development and security artifacts are both stored in the logical SAP HANA repository and in the package hierarchy. How you organize packages, subpackages, and their dependencies plays a key role in how you promote content to other environments. For example, let’s assume that all content, both development-related and security-related, is stored in a single package. Packages and their subordinate objects are assigned to a delivery unit within SAP HANA. (Remember that delivery units are the objects transported between environments.) If all content is organized into a single package, your organization will have no choice but to promote everything in a single delivery unit each time code is promoted to production, which can lead to the promotion of content that is incomplete and not validated. Therefore, we recommend organizing content into packages based on their relationships. Unrelated objects should be in their own independent packages and delivery units.

Cleaning Up Test and Validation Content

Development environments often become the testing ground for application code. The same can happen with security artifacts. For example, user accounts, repository roles, catalog objects, and other items can be created to test a scenario before changes to permanent objects are implemented. You should encourage this type of validation in development. However, you should also discourage the permanent proliferation of objects that won’t be promoted to QA or PROD. Such objects should be deleted from the system when they’re no longer used. Too often, these objects are mistaken for permanent objects and promoted to the QA or PROD environment. The most effective way to prevent validation content from accidental promotion is to delete the content from the system once the validation is completed.

Rollback Plans

When promoting content between environments, make sure that you always have a rollback plan. SAP HANA offers several features to help with these requirements. For example, you can restore the system from backup, restore exported catalog content, and restore individual items from the repository activation history.

Promoting Repository Role Dependencies

Repository roles often reference other repository-based objects or runtime catalog objects. These referenced objects are dependencies for a repository role. When you promote a repository role, you must ensure that all the referenced repository objects, both design-time and runtime, are included with the promotion delivery unit. If the repository role references a runtime catalog object, that object must exist in all environments. For this reason, among many others, we highly recommend using repository-based objects for both security and database development.

14.1.2    Testing Security Model Changes

One purpose of security model lifecycle management is to facilitate the testing and validation of changes. Special attention should be given to testing practices, given the amount of risk introduced when testing isn’t emphasized. To ensure that your organization approaches testing properly, let’s explore a few best practices you should follow. Your organization should track changes, validate code, socialize with their peers, test content in an environment identical to production, and define test plans based on the type of change. Let’s look at each of these items in more detail.

Tracking Changes

Tracking security model changes in an external software application is very important for lifecycle management, compliance, and auditing purposes. Such systems should contain information pertaining to the purpose of the change and the specifics of the change itself. Retaining this information is helpful if your organization has multiple individuals implementing changes so that everyone has access to information about a change in case contradictions or overlaps are introduced. More importantly, this information is often useful for communicating the intent of changes for future internal and external security administrators.

Validating the Security Model in Development

Security model developers and administrators should validate their own changes before those changes are promoted. Organizations often overlook the importance of emphasizing validation within their security model lifecycle management process. We highly recommend that your organization requires security model developers validate their own work using test cases specific to their changes. Adding this extra requirement to the process further reduces the likelihood of security vulnerabilities and inaccurate changes. In addition, frequently promoting content from DEV to QA because of development-related defects isn’t efficient. Establishing a process and procedure that includes developer validation will help reduce the frequency of content promotions.

Discussing Security Changes with Other Administrators

Security model changes should be discussed with the broader SAP HANA administration team. This line of communication can be created using meetings, emails, or other forms of communication. Granting everyone access to open dialog about the change is important. In most situations, socializing about changes can help identify unexpected issues, mitigating contingencies related to the change.

Testing Security Changes in an Identical Environment

As mentioned earlier, security administrators and developers should validate their work before promoting changes to a QA environment. However, once the content is transported to QA, these changes should be thoroughly tested. To make these tests more useful, the QA environment should be a mirror of the PROD environment. You don’t need exactly the same data in the QA environment, but you should ensure that the content, metadata, and configurations are similar, if not exact. If you use sound testing processes, using a near-identical environment will help mitigate potential issues in production.

Defining Test Plans Based on Change Types

When testing content in QA, make sure that you execute different levels of testing. A series of standard tests should always be executed. However, you should also devise a test specific to the most recent change. For example, if the change was to a repository role that grants access to a new SAP HANA information view, testing should include a procedure to test access to this new information view.

14.1.3    Keeping Repository Roles in Sync

In most cases, you’ll identify several repository roles that can exist in all environments within the organization. With some exceptions, these roles are predominantly related to administration-level access. In addition, repository roles used by SAP HANA instances within the same solution might host the same security content. For example, if you have DEV, QA, and PROD SAP HANA instances each operating an equivalent SAP S/4HANA application server, you should strive to have the same repository roles in each environment. In short, you might have some repository roles that exist in all SAP HANA instances and some that only exist in instances hosted in the same solution.

One way to ensure that administrators have the same level of access in each environment is by using the same administrative repository roles in each environment. For example, all SAP HANA instances can have the same base security administration role. We aren’t suggesting that all repository roles exist the same in all environments, but base-level administrative repository roles can be the same in each environment. For SAP HANA instances that share the same solution, you should assume that nonadministrative repository roles will be the same in each solution-based instance.

Therefore, you’ll need to devise a procedure that ensures that repository roles remain consistent throughout the SAP HANA landscape. The most effective way to accomplish consistency is via a process in which changes are tracked and monitored until those changes are moved into production. For example, an incident management system can track a process from beginning to end. Such systems often provide alerts and reports for incomplete incidents. Similar solutions might work as well. In addition to using a tracking system, you can also follow a few guidelines to help keep content in harmony. Specifically, you can transport and test changes quickly, eliminate changes in production, design roles that work in multiple environments, document repository roles, schedule changes, and audit the environment often. Let’s look at each of these items in more detail.

Transporting and Testing Quickly

One way to ensure that content remains in sync is to expedite the transportation process and subsequent testing. The longer content remains untested and untransported, the more likely your organization will experience inconsistency issues.

Eliminating Manual Changes in Production

When organizations make changes to repository roles directly in production, they run the risk of those changes being overwritten by subsequent transports. When this happens, those earlier changes might be lost forever. You should eliminate the need to make changes in production by using transports and by predominantly using repository-based content for development objects and security objects. Using transports ensures that the same content is implemented in each target instance. Repository-based objects all can be transported between systems, which helps keep them consistent.

Designing Repository Roles That Work in Other Environments

You’ll need to design your repository roles so that they work in multiple environments. Design a base set of repository roles that are universally applicable. You should also consider that users aren’t automatically granted access to new repository roles; these roles must be manually assigned to users or other roles. Therefore, having the same repository roles in each environment is fine, even though the same user might have different roles granted to it in each environment.

Documenting Repository Roles

Each repository role should have its configuration documented in an external master source location. Ideally, all security model changes would be updated in the documentation and in the SAP HANA instances during each change incident. This documentation can be used during periodic audits of the system or to determine inconsistencies among SAP HANA instances.

Scheduling Changes

Your organization should schedule changes to occur on a weekly basis. Set aside time each week to address transporting content and testing changes. If no changes are needed, these events can be skipped until the next week. Maintaining a consistent schedule helps keep instances in harmony.

Auditing Security Often

Using resources external to the group that normally manages the lifecycle process, routine audits of the security model should be conducted. Such audits will help to ensure consistency within the SAP HANA landscape.

With these key principles in mind, let’s now look at how you can use SAP HANA’s built-in tools to manage the transportation of development and security artifacts between systems.