AWS Fundamentals: Addressing Security Risk

Hello, this is course 2 in AWS Fundamentals. It majorly focuses on security and organizations. The link for the course is, https://www.coursera.org/learn/aws-fundamentals-addressing-security-risk/home/welcome

Some of the topics have been covered in the previous blog, still I will try to explain them in brief.

Shared Responsibility Between AWS and Customer :

Security and Compliance is a shared responsibility between AWS and the customer. This shared model can help relieve customer’s operational burden as AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall.

AWS responsibility “Security of the Cloud” – AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.

Customer responsibility “Security in the Cloud” – Customer responsibility will be determined by the AWS Cloud services that a customer selects. This determines the amount of configuration work the customer must perform as part of their security responsibilities.

For abstracted services, such as Amazon S3 and Amazon DynamoDB, AWS operates the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data. Customers are responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions.

See this page on the AWS website for more details: https://aws.amazon.com/compliance/shared-responsibility-model

Q. What is Cloud Security ?

AWS provides these security services upon creation of your AWS account, but, as with any service-based model, AWS gives you the mechanisms to further secure your account and infrastructure. This means AWS readily provide services to secure your accounts, like IAM, or Identity and Access Management, and Amazon Cognito, which allows you to provision end user access to your applications. No matter how you deploy your IT infrastructure, on your own servers or on AWS Cloud, you, as an application owner, need to maintain adequate governance over the entire IT controlled environment.

There are a few practices you need to follow.

1. understand compliance objectives and requirements.
2. then you need to establish a controlled environment that meets those objectives and requirements.
3. you need to understand the validation required based on your organization’s risk tolerance.
4. you need verification of the operating effectiveness of your controlled environment.
5. Now, when you build and operate your IT environment on AWS, it is a shared responsibility model between you and AWS.
   1. AWS’s part in this shared responsibility includes providing its services on a highly secure and controlled platform, and providing a wide array of security features that you can use.
   2. User responsibility includes configuring your IT environment in a secure and controlled manner for your purposes. AWS does communicate its security and control information to customers.

Take a virtual tour and see how AWS secures it’s data centers: https://aws.amazon.com/compliance/data-center/

IAM Roles for your organization :

When you first create the account, you’ll notice that you’re using the super user or root user. This means that you can do anything and everything in your account even deleting resources that you didn’t mean to. For that fact, the first best practice is to create individual user accounts for each user and provide them with relevant access.

The principle of least privilege access and likewise means to provision the minimum needed access policies. So that users can only perform the work they need to. You can create more users via the IM console by choosing a username, password, whether you want to access it via the console or programmatically. And then you add policies that stipulate the actual resources they have access to.

For example you want to create an admin user, you attach the administrator access policy, which is a JSON document that describes it.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
       ],
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}

So after you create the user successfully, the console will show you the user name, the access key ID, the secret access key, and the password. So, you have to download these resources, because it will not be available later on the console. You can choose to download by clicking on the Download .CSV button

If we want to add another layer of protection apart from our username and password, multi-factor authentication (MFA) and it adds another verification check when you try to log in. This can and should be enabled for your root account along with each account you’re trying to protect. Essentially you’ll be prompted for a code once you’ve entered your username and password with the code coming from an application like Google Authenticator. A security key like a yubikey or even an actual token device such as a gemalto token.

Other practices I recommend are,

1. use strong passwords to secure your accounts
2. using roles and groups to assign permissions
3. monitoring using Amazon CloudWatch and AWS CloudTrail

Let’s say you have multiple IT engineers that are tasked to manage AWS accounts and resources. As an IT manager, you would need to grant AWS admin access for your engineers.

Q. How do we scale and automate AWS account creations? How do we make sure that each team and organization has the appropriate permissions to use the right AWS services and resources?

The solution is AWS Organizations. This AWS service can help you centrally govern your environment as we grow and scale. Using AWS Organizations, you can automate account creation and management, create groups of accounts to reflect business needs, govern access to AWS services resources in Region by policy,

1. automate account creation and management
2. create groups of accounts to reflect business needs
3. govern access to AWS services resources region by policies
4. set up single payment method for all AWS accounts
5. share resources across accounts

Q. How does AWS Organizations work ?

Firstly, you will choose an AWS account as a master account. Then, you create an organization in this master account. Note that when you use Organizations to create a new account, an IAM role will be created so that the master account can switch roles to access your member account. Then, you can either create an organization unit called OU, or accounts, called member accounts, under organization.

Some of the practices for AWS Organizations :

1. plan ahead for the structure of your organization, to have a structural flow
2. keep the master account free of any operational AWS resources, as master account is to monitor
3. use AWS CloudTrail to monitor resources
4. Apply Least Privilege practice, to reduce the cost and security break
5. Assign policies to Organizational Units, for specific tasks
6. test new and modified policies, if you want to update
7. use the APIs and AWS Cloud Formation, to get your work done from Command line interface (CLI)

More information on AWS Organizations can be found at:

1. https://aws.amazon.com/organizations/
2. https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

Identity and Access Services :

There are three use cases when you need to provide access,

1.When the user accesses an AWS account and resources :

An example of this use case is when you enable single sign-on on your AWS accounts to let a developer log in to an AWS account using credentials from your corporate identity to create and run an AWS Lambda function.

2.To allow your applications to access AWS services, you need to be able to validate the identity and permissions of your application’s resources :

A containerized application runs on Elastic Kubernetes Service needs to do an API call to query a table in AWS No SQL database DynamoDB. You will need to securely validate API calls and manage permissions for actions that your app is allowed to perform on DynamoDB tables using short-term credentials called IAM roles.

3.To allow end users to access the application :

Your application would need to manage user sign up and sign in, and you also need to enable multi-factor authentication when users sign in.

let’s dive into 4 services related to the 3 use cases.

1.AWS Organizations : a service to help you create and manage multiple AWS accounts.

2.AWS identity and Access management (IAM) : a service in which, you can create and manage AWS users in groups and use permissions to allow and deny the access to it resources. It does a lot of things,

1. manage IAM user and to access
2. manage IAM roles and their permissions
3. manage federated users and their permissions.

3.AWS Single sign-On : a Cloud service that make it easy to centrally manage SSO access to multiple AWS accounts and business application. It help you manage SSO access and user permission across all your AWS account in AWS organization

4.Amazon Cloud Directory : a service with Cloud directory, you can create a directory for a variety of used cases such as organizational charge, course catalogs, and divine registry. Traditional directory solution such as Held-up based directory limit due to a single hierarchy Cloud directory offer you the flexibility to create directories within hierarchies that span multiple dimensions

AWS managed Directory :

A best practice is to logically separate your infrastructure users and end-users. This means that, you can manage them independently and avoid overlap of process’s.

For example, if you had all your users irrespective of type in one identity store and that store had a disruption, you would not be able to effectively shut off access to specific users to debug without some work-around.

Amazon Cognito itself provides an identity store called Cognito User Pools. This would store all your users so that registration, authentication, and even password resets are handled by the user pool. Now say a user had logged into your application, and wants to upload to an S3 bucket, they require access to that bucket. This is where Cognito identity pools come in and allow authorized access to AWS resources, With Cognito, you can do that with the identity pool which means linking your Cognito user pool, would say in Open-ID connect provider, or even login with Facebook, or Google.

AWS managed Microsoft Active Directory :

This is useful if you want to reuse an existing on-premises Microsoft Active Directory without caching any information in the cloud. This means that, you can use your existing corporate credentials to log into AWS applications like Amazon workspace and even manage AWS resources like S3.

The two ways you can use it is to join your existing directory to the AWS one:

1. Active Directory with your identity store and therefore not have to recreate all your users from scratch.
2. You can even use single-sign-on or SSO, to ride a seamless integration between different services. SSO means that, a user would login once and then be able to access two different applications without having to log into each one individually.