Governance , while often used in the context of ‘cost governance’ , can actually apply to either of the following.

• Automation Governance – Resource Provisioning Automation, Account Automation, Policy Automation
• Budget Enforcement and Cost Compliance Governance on AWS, Azure, GCP
• Security Compliance for AWS, Google Cloud and Azure
• Base Enablement – Tagging of assets on GCP, Azure and AWS. Centralized Logging of events and across multiple accounts and subscriptions.  This is probably the FIRST thing you should tackle when it comes to ensuring compliance for any of the other three categories (Security, Automation or Cost)

Automation – Includes Policy Automation, Account Automation, Identity Federation

Resource Provisioning

• AWS Service Catalog automate  – network architecture baselining. They replace manual processes, and facilitate the use of pre-defined, standardized system deployment templates.
• AWS Landing Zones and
• AWS Quick Starts

Account Automation

• Services such as AWS Organizations, AWS CloudFormation –  AWS account provisioning
• AWS Landing Zones

Policy Automation

• AWS guidance to achieve governance at scale automates the application of company policies, deploying accounts with standard specifications to ensure consistency across AWS accounts and resources. The policy engine is flexible to accommodate and enforce different types of security polices such as AWS Identity and Access Management (IAM), AWS CloudFormation, or custom scripts.

Identity Federation

•  AWS governance solutions employ AWS Single Sign-On (SSO) through federated identity integration with external authentication providers such as OpenID, or Active Directory to centralize AWS account management and simplify user access to AWS accounts. When SSO is used in conjunction with AWS CloudTrail, user activity can be tracked across multiple AWS accounts.

Budget Enforcement

Enforcement of budget constraints is a key component of governance at scale. Each layer of the company defines spending limits within accounts and projects, monitors account spending in near real-time, and triggers warning notifications or enforcement actions. Automated actions include:

• Restricting the use of AWS resources to those that cost less than a specified price.
• Throttle new resource provisioning.
• Shut down, terminate, or de-provision AWS resources after archiving configurations and data for future use.

Security Compliance

• AWS services or Amazon Virtual Private Cloud (Amazon VPC) baseline configurations can be provisioned using standardized AWS configurations or AWS CloudFormation templates
• These templates align with the company’s security and compliance requirements and have been evaluated and approved by company’s risk decision makers.
• Well implemented security automation is responsive to security incidents. This includes processes to respond to policy violations by revoking IAM user access, preventing new resource allocation, terminating resources, or isolating existing cloud resources for forensic analysis.
•  Automation can be accomplished by collecting and storing AWS logging data into centralized data lakes and performing analytics, or basing responses on the output of other analytics tools.
• At each level of the hierarchy the company can specify which AWS Services, features, and resources are approved for use on a per department, per user, or per project basis. This ensures self-service requests can’t provision unapproved items, as illustrated in the following diagram.

Base Enablement – Tagging and Logging

As discussed in the opening paragraph, this is the first step in getting any of the other pieces even close to working.

• Centralized logging – There’s a good deal of options – including cloud native options (e.g. centralized S3 bucket logging in AWS) as well as third party open source solutions such as the ELK stack.
• Tagging Strategy and Enforcement on AWS, Azure and Google Cloud – This is such a key area that, if done right, it can help answer the toughest questions around your cloud environment.

Summary

People use the word Governance very loosely, both for on premises as well as cloud environments. In cloud environments, your first concern should be getting base enablement – which involves a comprehensive asset tagging strategy as well as a centralized logging mechanism. Once your environment has this base enablement, some of the other governance can be put in place – using custom policies for security governance, cloud native (Security Hub, Google Command Center, Azure Policy Management…), for automatic checking of resource compliance.

Need assistance with your GCP, Azure or AWS compliance efforts or security audits?   

The post Governance in AWS, Azure, GCP appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

(Also read, KMS based data encryption on AWS and Google Cloud)

CloudTrail logs, CloudWatch log groups, GuardDuty logs, Inspector logs, VPC Flow Logs, Trusted Advisor logs – are just some AWS native services that provide you insight into security events on your AWS account.

Each of these services requires a role with it’s own IAM policies, either custom or managed – for access. This is why a majority of AWS admins take a shortcut. They create a role (or a user) and assign a Full Administrator policy to users that need read only access to these logs.

 That’s the key point — this is meant to be a read only user (or role), and granting full admin is overkill, apart from being a security risk.

So — what’s the alternative?

An Auditor Role would be cool

Wouldn’t it be cool if you could encapsulate all the required IAM policies into a single policy?  And simply create a user (or a role) with that attached policy?

This post describes such a Security Auditor role in AWS, with the following attributes.

1. A READ ONLY (auditor) role that is able to access logs and events to investigate potential security breaches or potential malicious activity.
2. The role should have privileges to read and view ANYTHING and EVERYTHING related to security, monitoring and troubleshooting within an AWS environment.
3. This should include GuardDuty logs, CloudTrail logs, CloudWatch events, Inspector logs and more.
4. Optionally, it should also continuously check for compliance vioilations (security related compliance violations – such as open Security Groups, Public IPs etc.)

Built in Security policies in AWS IAM ?

Believe it or not, AWS has already thought through the majority of this security audit use case. They have a policy specifically designed to perform this read only auditing role. However, as this post will describe, you may still need an additional policy or two (depending on how comprehensive an auditor role you are defining is).

To that end, the policies that I recommend for a full security auditor role in AWS include:

• SecurityAudit– MUST have policy, contains all the read only permissions for cloudtrail, cloudwatch, vpc flow logs, inspector logs and more.
• AWSSecurityHubFullAccess(as opposed to AWSSecurityHubReadOnlyAccess— Wait, didn’t you say you should avoid FullAccess? This was meant to be a read only role. You are right – but the SecurityHub full access isn’t the same as Admin Full Access. In addition, what it buys you, is the ability to automatically check for any compliance violations (See the AWS managed policy AWSSecurityHubFullAccess section below).

Why we need this AWS managed policy –  AWSSecurityHubFullAccess ?

 When you enable Security Hub, it’s assigned a service-linked role named:

AWSServiceRoleForSecurityHub

This service-linked role includes a trust policy that Security Hub requires to do the following:

1. Detect and aggregate findings from Amazon GuardDuty, Amazon Inspector, and Amazon Macie
2. Configure the requisite AWS Config infrastructure to run supported standards (in this release, CIS AWS Foundations) compliance checks.

This is why I recommend this policy for all auditor roles. The SecurityAudit policy by itself does not allow the running of supported CIS benchmarks.

What about Cross Region Security Logs and Cross Account Logs?

The SecurityAuditor role (A role with the SecurityAudit AWS policy attached), provides access to cloudwatch logs, regardless of the region in which they were created. The same applies for all other security related logs, including VPC flow logs, Inspector Logs and GuardDuty logs.

For accessing logs across AWS accounts, you have 2 options:

1. Either create the same role in each account and provide cross account ‘assume role’ access to appropriate users in each account.
2. A better solution is to use a centralized logging solution in your AWS account. This would channel all logs from all different accounts to a centralized logging account (typically to an S3 resource).

Are there any Permissions Boundaries for this role?

No permission boundaries are required for this role, since it is designed as a read only role.

Other Public Clouds? Azure and Google Cloud Security Auditor Roles

In GCP, the equivalent is the IAM Security Reviewer role (roles/iam.securityReviewer).

In Azure, the closest is the Security Reader Role.

The following table displays roles and allowed actions in Azure Security Center (source Azure docs).

TABLE 1

Role	Edit security policy	Apply security recommendations for a resource (including with ‘Quick Fix!’)	Dismiss alerts and recommendations	View alerts and recommendations
Subscription Owner
Subscription Contributor	—
Resource Group Owner	—		—
Resource Group Contributor	—		—
Reader	—	—	—
Security Administrator		—
Security Reader	—	—	—

Summary

 Auditing all security related events and logs across an AWS account means auditing multiple logs. Each of these logs can be streamed to a variety of destinations. This makes it challenging to assign IAM policies for accessing each service’s log, especially since it could be going to an S3 bucket today and to an event streaming service tomorrow.

 This post details creating a SINGLE role that provides READ ONLY access across all these logs – regardless of their source (GuardDuty, VPC Flow Logs, Inspector, Trusted Advisor Logs) or their destination.

Looking for a consultant to assist with a Cloud Security Review on AWS, Azure or Google Cloud?

For an initial security consultation on AWS, Azure or GCP, pick a time here. For a general consultation, Set up a time here .

The post Security Audits of AWS Accounts – Roles, Policies and equivalents on GCP and Azure appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.