# 5 – Control the access to workload infrastructure
<a name="design-principle-5"></a>

 **How do you protect the infrastructure of the analytics workload?** Analytics environments change based on the evolving requirements of data processing and data distribution. Ensuring the environment is accessible with the least permissions necessary is essential in delivering a secure platform. Automate the auditing of environment changes and generate alerts in case of abnormal environment access. 


|   **ID**   |   **Priority**   |   **Best practice**   | 
| --- | --- | --- | 
|  ☐ BP 5.1   |  Required  |  Prevent unintended access to the infrastructure.  | 
|  ☐ BP 5.2   |  Required  |  Implement least privilege policies for source and downstream systems.  | 
|  ☐ BP 5.3   |  Required  |  Monitor the infrastructure changes and the user activities against the infrastructure.  | 
|  ☐ BP 5.4   |  Required  |  Secure the audit logs that record every data or resource access in analytics infrastructure.  | 

# Best practice 5.1 – Prevent unintended access to the infrastructure
<a name="best-practice-5.1---prevent-unintended-access-to-the-infrastructure."></a>

 Grant least privilege access to infrastructure to help prevent inadvertent or unintended access to the infrastructure. For example, make sure that anonymous users are not allowed to access to the systems, and that the systems are deployed into isolated network spaces. Network boundaries isolate analytics resources and restrict network access. Network access control lists (NACLs) act as a firewall for controlling traffic in and out. To reduce the risk of inadvertent access, define the network boundaries of the analytics systems and only allow intended access. 

## Suggestion 5.1.1 – Ensure that resources in the infrastructure have boundaries
<a name="suggestion-5.1.1-ensure-that-resources-in-the-infrastructure-have-boundaries."></a>

 Use infrastructure boundaries for services such as databases. Place services in their own VPC private subnets that are configured to allow connections only to needed analytics systems. 

 Use [AWS Identity and Access Management (IAM) Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) for all AWS accounts that are centrally managed through [AWS Organizations.](https://aws.amazon.com/organizations/) This allows security teams and administrators to uncover unintended access to resources from outside their AWS organization within minutes. 

 You can proactively address whether any resource policies across any of your accounts violate your security and governance practices by allowing unintended access. 

# Best practice 5.2 – Implement least privilege policies for source and downstream systems
<a name="best-practice-5.2---implement-least-privilege-policies-for-source-and-downstream-systems."></a>

 The principle of least privilege works by giving only enough access for systems to do the job. Set an expiry on temporary permissions to ensure that re-authentication occurs periodically. The system actions on the data should determine the permission and granting permissions to other systems should not be permitted. 

## Suggestion 5.2.1 – Ensure that permissions are least for the action performed by user/system
<a name="suggestion-5.2.1---ensure-that-permissions-are-least-for-the-action-performed-by-usersystem."></a>

 Identify the minimum privileges that each user or system requires, and only allow the permissions that they need. For example, if a downstream system requests to read an Amazon Redshift table from an analytics workload, only give the read permission for the table using Amazon Redshift user privilege controls. 

 For more details, refer to the following information: 
+  AWS Security Blog: [Techniques for writing least privilege IAM policies](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/) 
+  Amazon Redshift Database Developer Guide: [Managing database security](https://docs.aws.amazon.com/redshift/latest/dg/r_Database_objects.html) 
+  AWS Security Blog: [IAM Access Analyzer makes it easier to implement least privilege permissions by](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/) [generating IAM policies based on access activity](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/) 

## Suggestion 5.2.2 – Implement the two-person rule to prevent accidental or malicious actions
<a name="suggestion-5.2.2---implement-the-two-person-rule-to-prevent-accidental-or-malicious-actions."></a>

 Even if you have implemented the least privilege policies, someone must have critical permissions for the business, such as the ability to delete datasets from analytics workloads. 

 The two-person rule is a safety mechanism that requires the presence of two authorized personnel to perform tasks that are considered important. It has its origins in military protocol, but the IT security space has also widely adopted the practice. 

 By implementing the two-person rule, you can have additional prevention of accidental or malicious actions of the people who have critical permissions. 

# Best practice 5.3 – Monitor the infrastructure changes and the user activities against the infrastructure
<a name="best-practice-5.3---monitor-the-infrastructure-changes-and-the-user-activities-against-the-infrastructure."></a>

 As the infrastructure changes over time, you should monitor what has been changed by whom. This is to ensure that such changes are deliberate and the infrastructure is still protected. 

## Suggestion 5.3.1 – Monitor the infrastructure changes
<a name="suggestion-5.3.1-monitor-the-infrastructure-changes."></a>

 You want to know every infrastructure change and want to know that such changes are deliberate. Monitor the infrastructure changes using available methods on your team. For example, you can implement an operation procedure to review the infrastructure configurations every quarter of the year. Or, you can use AWS services that assist you to monitor the infrastructure changes with less effort. 

 For more details, refer to the following documentation: 
+  AWS Config Developer Guide: [What Is AWS Config?](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 
+  Amazon Inspector User Guide: [What is Amazon Inspector?](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) 
+  Amazon GuardDuty User Guide: [Amazon S3 protection in Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/s3_detection.html) 

## Suggestion 5.3.2 – Monitor the user activities against the infrastructure
<a name="suggestion-5.3.2---monitor-the-user-activities-against-the-infrastructure."></a>

 You want to know who is changing the infrastructure and when, so that you can see that any given infrastructure change is performed by an authorized person or system. To do so, as examples, you can implement an operation procedure to review the AWS CloudTrail audit logs every quarter of the year. Or you can implement near real time trend analysis using AWS services such as Amazon CloudWatch Logs Insights. 

 For more details, refer to the following information: 
+  AWS CloudTrail User Guide: [Monitoring CloudTrail Log Files with Amazon CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html) 
+  AWS Management and Governance Blog: [Analyzing AWS CloudTrail in Amazon CloudWatch](https://aws.amazon.com/blogs/mt/analyzing-cloudtrail-in-cloudwatch/) 

# Best practice 5.4 – Secure the audit logs that record every data or resource access in analytics infrastructure
<a name="best-practice-5.4---secure-the-audit-logs-that-record-every-data-or-resource-access-in-analytics-infrastructure."></a>

 Logs are an audit trail of events and should be stored in an immutable format for compliance purposes. These logs provide proof of actions and help in identifying misuse. The logs provide a baseline for analysis or for an audit when initiating an investigation. By using a fault-tolerant storage for these logs, it is possible to recover them even when there is a failure in the auditing systems. Access permissions to these logs must be restricted to privileged users. Also log audit log access to help in identifying unintended access to audit data. 

## Suggestion 5.4.1 – Ensure that auditing is active in analytics services and are delivered to fault-tolerant persistent storage
<a name="suggestion-5.4.1---ensure-that-auditing-is-active-in-analytics-services-and-are-delivered-to-fault-tolerant-persistent-storage."></a>

 Review the available audit log features of your analytics solutions, and configure the solutions to store the audit logs to fault-tolerant persistent storage. This helps ensure that you have complete audit logs for security and compliance purposes. 

 For more details, refer to the following information: 
+  AWS Management and Governance Blog: [AWS CloudTrail Best Practices](https://aws.amazon.com/blogs/mt/aws-cloudtrail-best-practices/) 
+  Amazon Redshift Cluster Management Guide: [Database audit logging](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing.html) 
+  Amazon OpenSearch Service (successor to Amazon OpenSearch Service) Developer Guide: [Monitoring](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/audit-logs.html) [audit logs in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/audit-logs.html) 
+  AWS Technical Guide – Build a Secure Enterprise Machine Learning Platform on AWS: [Audit trail](https://docs.aws.amazon.com/whitepapers/latest/build-secure-enterprise-ml-platform/audit-trail-management.html) [management](https://docs.aws.amazon.com/whitepapers/latest/build-secure-enterprise-ml-platform/audit-trail-management.html) 
+  AWS Big Data Blog: [Build, secure, and manage data lakes with AWS Lake Formation](https://aws.amazon.com/blogs/big-data/building-securing-and-managing-data-lakes-with-aws-lake-formation/)