AWS for SAP

Audit your SAP systems with AWS Config – Part II

Introduction

In part I we discussed how to use managed AWS Config rules to automatically audit and assess the of your SAP landscape. We provided a solution to ensure your EC2 instances are configured per SAP best practices. At present, AWS offers more than 160 such managed rules in its North Virginia Region.

Along with the infrastructure, customers must also keep their applications compliant. This is where AWS Config Custom Rules comes into the picture. Custom rules will allow us to define our own configuration checks in addition to those covered in the managed rules. A custom rule in AWS Config essentially runs the AWS Lambda function against a list of AWS resources.

One classic example of application configuration is system parameters such as parameters for operating systems, databases, and several applications like SAP S/4HANA, SAP NetWeaver, and SAP ECC. In this blog post, we will audit one of the SAP application parameters in SAP S/4HANA. We will create one such custom rule to ensure the SAP parameter is set to the right value on our EC2 instances running the S/4HANA application. This solution can be extended to evaluate any other parameter (or a group of parameters) as required.

 

Solution Overview: AWS Custom Configuration Rules

Let us first discuss the parameter being audited in this blog. SAP S/4HANA users connect to the ABAP application with their own user IDs. Apart from these normal users, SAP provides several standard superusers. SAP* is one such standard user. This user is not susceptible to authority checks and has all authorizations. As a best practice, SAP recommends deactivating this user in all the SAP systems. Parameter login/no_automatic_user_sapstar does this job of activating and deactivating SAP* user. To deactivate, set this parameter to value 1. Apart from S/4HANA, this parameter is applicable to all SAP applications based on ABAP Platform 1909 and even older versions of the ABAP platform such as SAP Netweaver AS (Application Server) for ABAP platform.

In our solution, we will build a Lambda function that will access the existing bastion host and this bastion host will talk to the SAP instances in a private subnet to collect the required parameter value. This value is evaluated with AWS Config to be either compliant or non-compliant.

Solution Diagram - AWS Config custom rule calls a Lambda function that will access the existing bastion host and this bastion host will talk to the SAP instances in a private subnets across multiple availability zones to collect the required parameter value. This value is evaluated with AWS Config to be either compliant or non-compliant. Based on the evaluations, AWS Config dashboard will be updated.

 

Steps

Now, let us look at the custom rule creation steps.

AWS Lambda function

  • Before we create the custom rule, we will create Lambda function. In AWS Management Console, in Services, search for Lambda.

Navigate to AWS Lambda from AWS Console

 

  • In AWS Lambda, go to Functions and choose Create function.

AWS Lambda: Create function

 

  • Select Use a blueprint.

AWS Lambda: Blueprint selection screen

 

  • In the Filter, type keyword config and press enter. You will get 2 Blueprints. Select config-rule-change-triggered and choose Configure.

AWS Lambda: Blueprint to create AWS Config Custom Rule

 

  • Enter Function name e.g. sapparam-config-sapstar. Note down this name, as it will be required later during the configuration step.

Creating AWS Lambda Function

 

  • Under Execution role, choose Create a new role from AWS policy templates and enter role name e.g. sapparam-config-sapstar. Note down this name, as it will be required later during the configuration step.

Assigning IAM Role to the Function

 

  • Choose Create function at the bottom.

Create Function

 

  • Now function is successfully created. Note down the ARN. Please note that the code in the blueprint is to check if the resource is an EC2 instance with desired instance type. The logic must be modified according to our requirements. For example, searching a specific parameter in the profile file and comparing its value with the desired value.

ARN for the Lambda Function

 

  • To edit the code, under Configuration section, replace the index.js in Function Code subsection with your JavaScript and Save. In this Blueprint, function evaluateChangeNotificationCompliance evaluates the compliance status of your Instance. You may also need to add any additional modules, if they are referenced by the Java Script.

index.js for the Lambda Function

 

  • Creating secret in AWS Secrets Manager, to store SSH Key Pair – To connect to the EC2 instances, we need EC2 instance key pair. We will securely store it in plaintext format as a secret, which will be used in the Lambda Function.

ARN of the stored Secret

 

  • We also need to update the IAM Role assigned to the Lambda function, so that it can retrieve the secret. For this, we create a Policy secret_sap_private_key and attach it to our role.

IAM Policy for Lambda Function to access secrets

 

  • You can retrieve the value from this secret using a sample code.

 

const aws = require('aws-sdk');

const config = new aws.ConfigService();

var privateKeyStr = '';

// Retrieve the private key from AWS Secrets Manager
async function getPrivateKey() {

const region = "eu-west-1";
const secretName = "sapapp.pem";

// Create a AWS Secrets Manager client
var client = new aws.SecretsManager({
    region: region
});

 return new Promise((resolve,reject)=>{
  
 client.getSecretValue({SecretId: secretName}, function(err, data) {
    
    if (err) {
            reject(err);
    }
    else {
        // Decrypts secret using the associated KMS CMK.
        // Depending on whether the secret is a string or binary, one of these fields will be populated.
        if ('SecretString' in data) {
            resolve(data.SecretString);
        } else {
            let buff = new Buffer(data.SecretBinary, 'base64');
            resolve(buff.toString('ascii'));
        } 
    }
    });
 });
}

 

 

  • To securely connect to the SAP Application server via Bastion Host, add environment variable to the Lambda Function and use node-ssh-forward module.

Environment variable for Lambda Function


const SSHConnection = require('node-ssh-forward').SSHConnection;
    const sshConnection = new SSHConnection({
        endHost: configurationItem.configuration.privateDnsName,
        bastionHost: process.env.BASTION_HOSTNAME,
        username: 'ec2-user',
        privateKey: privateKeyStr 
    });
    
    await sshConnection.forward({
        fromPort: 9000,
        toPort: 80, // 80
    });

 

 

  • Increase Timeout value to sufficient threshold. The Lambda function gets executed in about 10 seconds. With buffer, we can place 1 minute as the timeout.

Adjusting Timeout for Lambda Function

 

  • Secure communication between the Lambda function and the EC2 instances – attach policy to the IAM Role assigned to the Lambda function, to allow the ENI creation.

IAM Policy for Lambda Function to access Elastic Network Interface

 

  • Associate your Lambda function with VPC, to keep communication secured. Also update the Security group with the ENI attached to the Lambda Function. In this case, SSH port 22 needs to be opened for the communication.

Security Group for Lambda Function

 

AWS Config Custom Rule

  • Now, we are ready to create the custom rule. Go to Services and search for config.

Navigating to AWS Config in AWS Console

 

  • Navigate to Rules.

AWS Config – Navigation screen

 

  • On next screen, choose Add Rule.

AWS Config – Add rule

 

  • On next screen, choose Add custom rule.

AWS Config – Add custom rule

 

  • Enter the Name e.g. sapparam-config-sapstar, relevant Description and AWS Lambda function ARN.

AWS Config: Add custom rule – Name and Description

 

  • Under Trigger section, choose both the Trigger types. In Scope of changes, select Resources and EC2: Instance. In Frequency, select required duration.

AWS Config Parameters section where triggers are selected

 

  • Under Rule parameters section, enter Key as login/no_automatic_user_sapstar and Value as number 1. Leave rest of the section as it is and Save.

AWS Config Rule parameters section with Key and Value

 

  • Now you will find that the rule has detected and evaluated your instance and reported the status.

AWS Config Rule detecting resource compliance status - This image shows an EC2 instance in complaint status

 

  • Compliance Timeline – You can see the compliance history of the EC2 instance on the Compliance Timeline.

Compliance Timeline example - This example shows EC2 instance as non-compliant from 18th September 2020 and back in compliant status from 21st September 2020

 

Cost Scenario

For Cost calculations, we will assume –

  • 50 EC2 instances
  • US East 1 (North Virginia) Region
  • 10 distinct rules
  • Each Rule running on each instance, once a day

AWS Config Configuration Items:

Number of Configuration Items Recorded Estimated Cost (Month)
10,000 10,000 * .003 = $30.00

Note: A configuration item represents a point-in-time view of the various attributes of a supported AWS resource that exists in your account. The components of a configuration item include metadata, attributes, relationships, current configuration, and related events. AWS Config creates a configuration item whenever it detects a change to a resource type that it is recording. For example, if AWS Config is recording Amazon S3 buckets, AWS Config creates a configuration item whenever a bucket is created, updated, or deleted. Additional details are available on the AWS Config Concepts page.

AWS Config Rules:

SAP Instances (I) Rules (R) Evaluations (E) Estimated Cost
50 10 I*R*30 Days E*.001
50*10*30 = 15,000 15,000*.001 = $15.00

AWS Lambda:

Whenever a custom rule is executed, Lambda Function associated with it will be invoked.

SAP Instances (I) Function Calls per Day (R) Memory Allocated per Call (M) Estimated Duration per call (D) Evaluations (E) Estimated Cost
50 10 128 MB 22000 ms I*R*30*D*0.001*M/1024*0.0000166667 USD $0.69

AWS Secrets Manager:

We are storing 1 secret in our AWS Secrets Manager, which will be called once per execution.

Secrets stored (S) API Calls per month (C) Evaluations (E) Estimated Cost
1 15000 (0.40*S) + (0.05*ROUNDUP(C/10,000)) $0.50

Amazon S3:

In addition, Amazon S3 Bucket will be used to store the Configuration and Compliance History related to the AWS Config Service and its Configuration Items.

S3 Standard Storage(S) GB/month PUT Requests (P) GET Requests (G) Evaluations (E) Estimated Cost
1 15000 15000 (0.023*S) + (P*0.000005) + (G*0.0000004) $0.11

Cost Summary:

Based on above assumptions, total Monthly Cost with above Resources comes to an estimated $46.30. Refer to the following pricing details for each of the services discussed above as AWS periodically optimizes the costs:

 

Conclusion

We saw how AWS Config Custom Rules keep an SAP Profile Parameter in check. Similarly, we can keep track of all critical parameters in our landscape, using these custom rules. In this way, AWS Config can become a central location to monitor compliance of the entire Enterprise System Landscape. This service will help you in securely managing and governing the Application along with the Infrastructure. As mentioned in of the series, you can also enable email notifications using Amazon EventBridge and Amazon Simple Notification Service to notify you when your resource is flagged as non-compliant. Use these AWS services as building blocks to construct your goal.

 

What next?

If you are interested in further integration cases and scenarios for your SAP on AWS Landscape, please contact us at sap-on-aws@amazon.com for any questions or visit aws.com/sap to learn more.