In the past, a common refrain from companies was that they were hesitant to move to the cloud because they believed the cloud was not secure. A big part of this pushback was that companies didn’t understand the cloud or its capabilities. It is possible to have security vulnerabilities even if you use cloud infrastructure. However, as we will see in this chapter, AWS provides a comprehensive catalog of services enabling you to create highly secure sites and applications.
When creating applications and implementing workflows, it is imperative to consider security from the start of your design and not as an afterthought. First, you will understand why security is essential in any system – not just in the cloud. Next, you will learn how AWS, in general, and IAM, in particular, can help us design and build robust and secure cloud applications. Also, as you will see in this chapter, AWS provides a veritable cornucopia of other security services. In this chapter, we will cover the following topics:
By the end of this chapter, you will have learned about how to secure your AWS cloud environment and the AWS services available to make your environment secure. AWS offers a plethora of security services to assist with these requirements. In this chapter, we will review these services in detail.
Many organizations face challenges in maintaining and managing the security of their on-premises infrastructure. In an on-premises environment, it can be challenging to know what resources and data are out there at any given time, where they are moving, and who is utilizing/accessing them. Accurate, real-time asset inventory requires expensive and complex tooling, making it inaccessible for most organizations. This lack of visibility in their on-premises environment hinders their ability to ensure adequate security and compliance of infrastructure and data. With AWS, you can see all your infrastructure and application resources in one place and maintain servers, storage, and database inventory records and access patterns.
AWS enhances your capacity to adhere to key security and compliance standards, such as data locality, protection, and confidentiality, through its extensive services and features. Boasting the largest network of security partners and solutions, the capabilities of AWS can be further extended through familiar security technology and consulting providers. AWS is compliant with major security standards and certifications, such as PCI-DSS, HIPAA/HITECH, FedRAMP, SEC Rule 17a-4, the EU Data Protection Directive, and FISMA, thereby enabling organizations to meet compliance requirements globally.
Another common problem is the reliance on manual processes for remediation. This may involve the manual copying of access information from one tool to another or the manual application of security patches. Automating key security tasks has been challenging due to the lack of interoperability between third-party and custom-made tools. These manual processes result in inconsistent execution and longer wait times to address all systems, and often negatively impact the customer experience. Automation aims to solve these issues by programmatically managing security tasks, such as checking if access to an application server is exposed to the internet or ensuring that an S3 bucket is not left public unintentionally.
As with any computer system, ensuring that it’s secure and that only authorized users access the system is paramount. Security should be incorporated at the beginning of your application design and not as an afterthought. AWS provides a broad set of security offerings that can ensure your application is secure and that your application data is safe. Notice that we used the word assist. Just because you are using AWS does not mean that your applications will be instantly secure.
A quick example of how easy it is to expose your data: There is nothing barring you from creating a bucket in AWS that is both unencrypted and public. You may get some warnings asking you if you are certain that you want to proceed, but AWS won’t disallow it. You could then put a client file in that bucket that may contain emails, passwords, names, addresses, and so on. This combination would immediately make this data accessible to anyone in the world with an internet connection (including any threat actors).
Even though you may not have published the URL for the bucket, please don’t assume it is secure. Threat actors know these mistakes happen sometimes. They constantly send requests to random AWS S3 buckets, trying to guess if they were created unsecured and exposed. And occasionally, they get lucky and hit pay dirt.
In the following section, we will learn more about what security AWS provides without involving the user and what services and tools AWS provides to its users to keep their systems secure.
AWS uses the shared responsibility model, which means that AWS and its users are responsible for keeping applications secure. However, the lines of responsibility are pretty clear. AWS is solely responsible for some aspects (for example, physical data center security), and users are solely responsible for other aspects (for example, making sure that Amazon S3 buckets that will contain sensitive information are private, accessible to only authorized users, and encrypted). This model enables AWS to reduce the burden of securing some components needed to create applications while enabling users to customize the applications to suit their clients’ needs and budgets.
Depending on the service chosen, some responsibilities may fall on AWS or the user. For example, if you use Amazon RDS to stand up an instance of MySQL, the patching of the database and the underlying operating system would be performed by AWS.
Suppose you instead decide to install MySQL directly into an Amazon EC2 instance. In that case, you will still be able to use the MySQL functionality. But in this case, the responsibility to patch the operating system and the database would fall on you.
One quick note: If your use case requires you to deploy MySQL manually into an EC2 instance, there is another option rather than deploying it yourself and risking the database not being deployed properly and securely. It is better to work with an AWS Consulting Partner. AWS has a list of trusted Consulting Partners that they recommend, and that can assist AWS customers. AWS ranks these partners by the level of service that they can provide. They have changed the ranking names in the past, but as of December 2022, the rankings are as follows:
Where Premier Partner is at the highest level. The current list of Consulting Partners can be found here: https://partners.amazonaws.com/ .
Leverage the power of AWS by incorporating security technology and consulting services from reputable and trusted providers. AWS has handpicked these providers to ensure they have extensive experience in securing every aspect of cloud adoption, from initial migration to ongoing management. The AWS Partner Network (APN) is a worldwide program of technology and Consulting Partners, many of whom specialize in delivering security solutions tailored to your specific needs and use cases. APN partner solutions promote automation, agility, and scalable growth with your workloads. You can easily access, purchase, implement, and manage these cloud-optimized software solutions, including SaaS products, within minutes on AWS Marketplace. You can find AWS security partners here: https://aws.amazon.com/security/partner-solutions/ .
Deciding whether to use managed services versus deploying applications yourself is an important decision. Both approaches have advantages and disadvantages and the decision to use one method or another will be dictated by your business needs. For example, using Amazon RDS will require less maintenance since AWS performs the patching. Still, your organization may require you to own complete control of what changes happen to the software (perhaps because of regulatory reasons), in which case, using the approach to install MySQL on your own would make more sense. Now AWS provides Amazon RDS Custom, with which you can manage the underlying operating system and database settings as per your need while taking advantage of the scale that comes with RDS.
One common refrain heard to distinguish which components are the responsibility of AWS and which are the responsibility of the customer is as follows: • AWS is responsible for the security OF the cloud. • The AWS customer is responsible for security IN the cloud.
The following diagram illustrates the separation of duties:
One common refrain heard to distinguish which components are the responsibility of AWS and which are the responsibility of the customer is as follows:
The following diagram illustrates the separation of duties:
The preceding figure shows in broad strokes how the responsibilities are broken down. For exam- ple, it clearly shows that the responsibility of AWS is for infrastructure elements such as regions, edge locations, and Availability Zones. This includes the physical security of the data centers. You may have passed an AWS data center and not noticed; AWS data centers are always unmarked buildings. On the other hand, customer data is the customer’s responsibility. When it comes to customer data, the encryption of the data is also the customer’s responsibility.
These areas of responsibility can be fuzzy depending on how a certain functionality is implemented. We see in the chart that databases fall under the purview of AWS, but as we saw previously, the customer can install a database, in which case they would be responsible for its management. Similarly, the chart in Figure shows the customer’s responsibility for operating systems, the network, and firewall configuration. But the shared responsibility model varies depending on the services provided to you by AWS.
The following diagram shows various levels of security responsibilities shared by AWS:
As shown in the diagram above, in some cases, for example, when using AWS S3, the management of most items is the responsibility of AWS. For EC2, AWS only handles infrastructure security while RDS security is managed at the platform level. For DynamoDB, you just need to manage data and its access while everything else in the layer up until network traffic and server encryption is managed by AWS.
Another way to understand how security in AWS works is by using the analogy of locks and doors. AWS provides you with the doors and the locks to secure your applications and data, but you can still leave the door open and not secure the lock, leaving the contents of your home exposed to the world.
For example, Amazon RDS is a managed service. AWS does much of the heavy lifting to make a database secure. However, you can still publish the credentials to access your Amazon RDS instance on GitHub and let anyone who views these credentials access your database. Overall, with AWS, you own your data and applications, and under the shared responsibility model, it becomes your responsibility to secure them by using various security services provided by AWS, from access management to encryption.
AWS has a broad range of security services available to fulfill every protection need of their customers. AWS is built to support the creation of secure, high-performing, resilient, and efficient infrastructure for your applications. The following AWS security services and solutions are designed to provide critical benefits that are crucial in helping you attain the best security posture for your organization:
As shown in the above table, AWS divides security services into the following pillars:
Identity and access management: Establish, enforce, and monitor user access to AWS services, actions, and resources.
Detective controls: Obtain the necessary visibility to identify potential issues before they affect your business, enhance your security posture, and minimize the risk to your environment.
Infrastructure protection: Minimize the surface area to manage and enhance the privacy, control, and security of your overall infrastructure on AWS.
Data protection: A collection of services that automate and simplify various data protection and security tasks, such as key management and storage, and credential management.
Incident response: During a security incident, containing the event and restoring to a secure state are critical steps in a response plan. AWS offers tools to automate parts of this best practice.
Compliance: Provide audit traces and artifacts in order to meet compliance requirements.
Let’s look into individual services belonging to these security pillars.
Identity and access management is the most fundamental security posture for any organization, and AWS provides the following services in this category:
Let’s look into each of the above services in detail.
Perhaps the most fundamental and important service in AWS is Identity and Access Management (IAM), which can secure every single other software service offered by AWS. AWS IAM offers precise access control across all AWS services. This level of control allows you to define who can access specific services and resources and under what conditions. By creating IAM policies, you can manage access permissions for your users or applications to ensure minimal privilege access. IAM is a complimentary service provided by AWS at no extra cost. More specifically, AWS IAM can be used to do the following:
Here are a few use cases for AWS IAM:
Suppose you have a company that uses AWS to host its applications. You can use IAM to create a group for your developers, granting them access to EC2 instances, S3 buckets, and DynamoDB tables, while only allowing them read-only access to your billing information. You can also use IAM to set up MFA for the root account and individual IAM users to add an extra layer of security.
To understand AWS IAM, we must first understand how authentication and identity management work. Users, groups, roles, permissions, and policies are fundamental concepts that need to be fully understood to grasp how resources are secured using AWS IAM. The purpose of using IAM is to regulate the authentication and authorization of individuals who wish to utilize resources. This is achieved by establishing precise permissions through IAM, thereby determining who has access to what. IAM consistently implements these permissions for every request made. By default, all requests are denied (except for the root user, which is allowed by default) unless an explicit “allow” is specified. An explicit “deny” overrides any allows.
In the following sections, you will learn AWS IAM terms.
An IAM user is an IAM principal you create in AWS to represent the person or application that uses it to interact with AWS. An IAM principal is a user, group, or service that is authenticated and authorized to access resources in an AWS account. An IAM principal can be an AWS account root user, an IAM user, an IAM role, or a federated user.
An AWS user comprises a username and associated credentials. Take, for instance, a user named John. Upon creating an IAM user account for John, you’ll need to establish a password for that user. You have the option to assign IAM user-specific permissions, such as the ability to start a particular Amazon EC2 instance.
An IAM user is an individual that needs to access, interact with, and potentially modify data and AWS resources. Users can interact through one of three ways:
Other than the root user, no implicit permissions or credentials are given when a new user is set up. That new user cannot access any resources until permission is explicitly assigned.
The IAM service in AWS enables you to securely control access to AWS resources and the actions that can be performed on those resources. You can use IAM to create and manage IAM principals, as well as to assign permissions to these principals to allow or deny access to AWS resources. For example, you can use IAM to create an IAM user for a person in your organization, and then grant that user permissions to access specific AWS resources or perform certain actions. Overall, using IAM helps you to securely and effectively manage access to your AWS resources, and helps you to enforce the principle of least privilege by granting only the necessary permissions to IAM principals.
An IAM user group is an assembly of IAM users. By organizing IAM users into groups, you can efficiently manage their permissions as a collective. As an illustration, consider a user group named Dev, to which you have assigned the typical permissions required for developers. Any IAM user belonging to this group will automatically inherit the permissions assigned to the Dev user group.
When a new member joins your organization and requires developer privileges, you can grant the necessary permissions by adding them to the relevant user group.
On the other hand, if an individual changes their role within your organization, you can simply transfer them from their current user group to the appropriate new user group, rather than modifying their individual permissions. The following diagram shows IAM users assigned to different user groups:
The above diagram shows three user groups, Admins, Developers, and Test, and IAM users assigned to those groups with the same credentials set. Putting users into groups facilitates permission management and gives system administrators a more efficient way to administer permissions. Users that have similar profiles are grouped. They could be grouped based on similar characteristics and on having similar needs, such as the following:
Then, permissions for users that belong to one group can be managed all at once through the group. It is recommended to put all users in one group that need the same access level. Often organizations use Active Directory to group employees, and in that case, you can map IAM groups to your Active Directory groups. If you have been around technology for a while, the idea of users and groups should not be new. However, IAM roles may require a little more explanation. Let’s continue discussing them in the next section.
An IAM role is a way to grant permission to access AWS resources to users or processes that do not have their own AWS credentials. The major difference is that, unlike users, IAM roles have no long-term credentials (i.e., passwords or access keys).
As shown in the diagram below, you can use an IAM role to allow a user to access an S3 bucket. For that, first, you need to create an IAM role that has the necessary permissions to access the S3 bucket. This can be done through the AWS Management Console or using the AWS CLI. For example, you might create a role that has the AmazonS3FullAccess policy attached to it. Next, create a user and associate the IAM role with the user. The user can then access the S3 bucket using the AWS Management Console or the AWS SDKs by assuming the IAM role. This will allow the user to use the permissions of the IAM role to access the S3 bucket, without the need for the user to have their own AWS credentials.
In IAM, a role is an object definition configuring a set of permissions assigned to that role. The role can be assigned to other entities, such as a user. A role is not directly connected to a person or a service. Instead, the role can be assumed by an entity that is given the role. Role credentials are always only temporary and rotated on a schedule defined by the AWS Session Token Service (STS). It is best practice to use roles whenever possible instead of granting permissions directly to a user or group.
STS allows you to request short-lived, restricted credentials for both AWS IAM users and federated users. This service is frequently utilized to grant temporary access to resources for trusted users, such as by granting them an IAM role that has a more limited set of permissions compared to their standard IAM user or federated user permissions.
STS enables you to grant trusted users temporary permissions to resources without having to share long-term AWS access keys. For example, you can use STS to grant temporary access to an IAM role that allows users to perform specific tasks in your AWS account, such as creating and managing Amazon EC2 instances or uploading objects to Amazon S3. STS can also be used to provide federated users with temporary credentials to access resources in the AWS cloud.
You can use STS to grant temporary credentials in several ways:
AssumeRole : This operation enables you to grant a trusted user temporary access to an IAM role.
GetFederationToken : This operation enables you to grant a trusted user temporary access to AWS resources that you specify in the permissions policy associated with the token.
GetSessionToken : This operation enables you to obtain temporary credentials for an IAM user or for a federated user.
Using STS helps you to secure your AWS resources and provides flexibility for granting temporary access to your resources. In Python, the user can use the boto3 library to assume the IAM role and then access the S3 bucket like this:
import boto3
# Assume the IAM role
sts_client = boto3.client('sts')
assumed_role_object = sts_client.assume_role(
RoleArn='arn:aws:iam::123456789012:role/my-iam-role',
RoleSessionName='my_session'
)
# Use the temporary credentials provided by the assume_role method to access S3
s3_client = boto3.client('s3', aws_access_key_id = assumed_role_
object['Credentials']['AccessKeyId',aws_secret_access_key = assumed_role_object['Credentials']['SecretAccessKey'],
aws_session_token = assumed_role_object['Credentials']['SessionToken'])
# List the objects in the S3 bucket
objects = s3_client.list_objects(Bucket='my-s3-bucket')
print(objects)Furthermore, roles enable you to grant multi-account access to users, services, and applications. Assigning a role to users not part of your organization is possible. Obviously, this has to be done judiciously and with flexibility as required.
IAM roles carry out a fundamental task in the security access landscape. By assigning permissions to a role instead of directly to a user or group, roles facilitate and simplify system administration and allow these permissions to only be given temporarily.
Access control in AWS is achieved through the creation and attachment of policies to IAM identities (such as users, groups, or roles) or AWS resources. These policies, which are objects in AWS, define the permissions of the associated identity or resource when they are attached. When an IAM principal, such as a user or role, makes a request, AWS evaluates the relevant policies to determine whether the request should be granted or denied. The majority of these policies are stored in AWS in the form of JSON documents.
A policy is a named document with a set of rules that specify what actions can be performed. Each policy laid out in the document gives a set of permissions. These policies can then be assigned to the IAM principals covered previously—users, groups, and roles. The syntax for AWS policy documents comes in two flavors:
The following is the syntax for defining policy and permissions:
Version: 2012-10-17
Statement:
- Effect: Allow
Action:
- ec2:DescribeInstances
Resource: "*"The above policy allows the ec2:DescribeInstances action to be performed on all resources. The Version field specifies the version of the policy language being used. The Statement field is a list of individual statements that together make up the policy.
Each statement consists of an Effect field (either Allow or Deny ), an Action field that lists the actions that are allowed or denied by the Effect field, and a Resource field that specifies the resources that the actions apply to. IAM policies can be attached to IAM users, groups, and roles to grant permissions to perform various actions on AWS resources.
Policies can be defined in the two following ways:
• Managed policies: When policies are defined as managed policies, they are created as standalone policies, and therefore they can be attached to multiple entities. Out of the box, AWS provides a set of predefined managed policies that can be used in many use cases. Managed policies can be combined to deliver additional access to roles, users, or groups. Finally, AWS users can define and customize their own managed policies.
• Inline policies: Inline policies are created within the definition of an IAM entity and can only be assigned to the entity to which they are attached. They do not have their own Amazon Resource Name (ARN). Since inline policies are related to a specific entity, they are not reusable. An ARN is an identifier used to uniquely identify AWS resources. It is a string that consists of several different parts, including the service, region, and resource identifier. Here is an example of an AWS ARN: arn:aws:s3:::my_bucket/example.jpg . In this example, arn:aws:s3 indicates that the resource is an S3 bucket, my_bucket is the name of the bucket, and example.jpg is the name of a file stored in the bucket.
It is best practice to use managed policies whenever possible and use inline policies only when there is a good reason to do so.
Permissions are lists of actions that can be taken on AWS resources. When a user or group is created, initially, they have no permissions. One or more policies can be attached to the new user or group to enable access to resources.
When creating policies, it is a good idea to abide by the principle of least privilege. In simple terms, this means that entities should be given a high enough level of access to perform assigned tasks but nothing more. For example, suppose an Amazon EC2 instance is created, and we know that only five users with five different IPs will access it. In that case, we should use allowlist for those IPs and only give them access instead of opening the Amazon EC2 instance to the whole world. Here is an example IAM policy that allows an EC2 instance to perform certain actions on S3 and EC2 resources, but only from a specific IP address range:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket", "s3:GetObject"],
"Resource": ["arn:aws:s3:::my-s3-bucket"],
"Condition": {
"IpAddress": {
"aws:SourceIp": "10.0.0.0/16"
}
}
},
{
"Effect": "Allow",
"Action": ["ec2:StartInstances", "ec2:StopInstances"],
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "10.0.1.1/16"
}
}
}
]
}This policy allows the EC2 instance to list the contents of the my-s3-bucket S3 bucket and retrieve objects from it, as well as to start and stop other EC2 instances, but only if the request originates from an IP address in the range 10.0.1.1/16 . You can attach this policy to an IAM role and then associate the role with an EC2 instance to apply the permissions to the instance.
Note: This is just one example of how IAM policies can be used to allowlist EC2 IP addresses. There are many other ways to write IAM policies and you should carefully consider the specific needs of your use case when writing your own policies. AWS provides a policy simulator. This policy simulator can test new policies you may create and ensure they have the correct syntax. You can learn more here: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html .
Permissions can be assigned to AWS users, groups, and roles via policies. These permissions can be given with policies in one of two ways:
Identity-based policies are attached to an AWS identity and grant permissions to the identity. AWS identities include IAM users, IAM roles, and AWS service accounts. Identity-based policies can be used to grant permissions to IAM users or roles in your AWS account or to grant permissions to other AWS accounts.
Resource-based policies are attached to a resource, such as an Amazon S3 bucket or an Amazon SNS topic, and grant permissions for the resource. These permissions can be used by any AWS identity that has access to the resource.
Both types of policies use the same syntax and structure, and you can use them together to finetune access to your resources. It is important to choose the right type of policy for your use case and to design your policies carefully to ensure that they provide the right level of access to your resources. Now, let’s learn about how to manage multiple AWS accounts using AWS Organizations.
AWS Organizations is a service that can be used to manage multiple AWS accounts in a consolidated manner. It provides a centralized location where you can see all your organization’s bills and manage all your AWS accounts from one place. This central location makes it much easier to establish, manage, and enforce your organization’s security policies. This central control ensures that security administrators and auditors can perform their jobs more efficiently and confidently.
These are the most important and relevant concepts when working with the AWS Organizations service:
The following figure illustrates how these components interact with each other:
As you can see in the diagram above, Policy 1 is associated with Organizational Unit (OU) 1 and with AWS Account B. Policy 1 is also applied to all children of OU 1 (OU 3, AWS Account C, and AWS Account D).
Since Policy 1 is associated with AWS Account B directly, it overrides Policy 2, which is associated with OU 2 and all its children except for AWS Account B. Policy 3 is associated with OU 4 and all its children (AWS Accounts E, F, and G).
The following diagram shows an AWS organizational structure created in the AWS console:
As you can see in the preceding diagram, two OUs are under the root account, and each unit has its sub-unit and AWS accounts.
The following are the key benefits of AWS Organizations:
Without AWS Organization’s SCP, all these policies would have to be repeated individually for each account. Every time there was a change to a policy, it would have to be changed individually in each account. This old approach had a high likelihood of policies that were supposed to be identical getting out of sync. You can learn more about AWS Organizations by visiting the AWS page here: https://aws.amazon.com/organizations/ .
Managing multiple accounts could be complicated. If you’d like to start your AWS environment using a simple UI and built-in best practices it’s better to use AWS Control Tower. When you assign permission to a user or resource, you want to see the policy evaluation and how it will work. You can refer to details on IAM policy evaluation here: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html .
Hopefully, the concepts of users, groups, roles, permissions, and policies are clearer now. IAM is far from the only security service that AWS offers. AWS IAM is a vast topic that warrants a book in itself. You can find more detail about AWS IAM here: https://aws.amazon.com/iam/ . Let’s learn about the next service in the IAM category: AWS Directory Service.
Microsoft Active Directory has been a popular choice for user and role management for decades, which, in computer years, is a long time. Given this popularity, AWS offers a fully managed implementation of Microsoft Active Directory. AWS Directory Service for Microsoft AD, also known as AWS Managed Microsoft Active Directory, allows AWS services that require directory services to integrate with Microsoft Active Directory.
AWS Managed Microsoft AD uses the actual Microsoft AD. It does not need to stay in sync because it does not copy the contents of existing ADs to the cloud. For this reason, the standard Microsoft AD administration tools can be used, and you can leverage the built-in AD capabilities, such as group policies and single sign-on. Using AWS Managed Microsoft AD, you can integrate Amazon EC2 and Amazon RDS for SQL Server instances with Microsoft AD. You can learn more about AWS Directory Service here: https://aws.amazon.com/directoryservice/ . Let’s learn about how AWS offers support for single sign-ons.
Being able to sign on to multiple enterprise applications using a user’s network login ID has been a pervasive way to manage application access for a while now. AWS IAM Identity Center has replaced AWS Single Sign-On, and offers a secure way to establish and link workforce identities, as well as to centrally manage their access across AWS accounts and applications. With AWS IAM Identity Center, SSO can be implemented without too much effort, and it can also be centrally managed, even in a multi-account AWS environment. It can be used to manage user access and permissions for multiple AWS accounts in one central place by leveraging AWS Organizations. IAM Identity Center can be used to configure and maintain all account permissions automatically. It does not need additional configuration for each account. User permissions can be assigned using roles. The following are the benefits of IAM Identity Center:
You can use the following simple steps to set up application access through single sign-on:
To manage user identities, IAM Identity Center provides an identity store or can connect with an existing identity store. Some of the supported identity stores are the following:
Any activity that occurs when using IAM Identity Center will be recorded using AWS CloudTrail. You can find more details about configuring SSO using AWS IAM Identity Center here: https://aws.amazon.com/iam/identity-center/ . You have now learned how to manage access for mul-tiple users.
If you have a simple AWS setup with a few servers and only one AWS account, then you don’t need AWS Control Tower. But if you are part of an environment with hundreds or thousands of resources and multiple AWS accounts and teams, then you will want to learn about and leverage AWS Control Tower. AWS Control Tower simplifies a multi-account environment’s administration, governance, and security setup.
Control Tower helps you quickly set up and govern multi-account environments securely. It automatically applies management features from existing AWS services, such as Organizations, AWS Config, and IAM Identity Center, and implements default account structure and governance policies based on AWS best practices from thousands of customers.
You can continue to use native features from Organizations, such as tag or backup policies, and integrated AWS services. AWS Control Tower enables you to set up company-wide policies and apply them across multiple AWS accounts. Without AWS Control Tower, you would have to apply the individual files to each account, opening up the possibility of having inconsistencies in your accounts. You can learn more about AWS Control Tower by visiting the AWS page here: https://aws.amazon.com/controltower/ . Now let’s learn how to manage multiple resources across organizational units using AWS Resource Access Manager.
The AWS Resource Access Manager (RAM) service allows you to share AWS resources with other AWS accounts or within your own organization. RAM allows you to share resources such as Amazon EC2 instances, Amazon RDS database instances, and Amazon Virtual Private Clouds (Amazon VPCs) with other AWS accounts or within your organization.
You can use RAM to manage resource sharing by creating resource shares, which are collections of resources that you want to share with specific AWS accounts or within your organization. You can specify the accounts or organizational units (OUs) that you want to share the resources with, and set permissions to control how the resources can be accessed.
RAM is useful for scenarios where you want to share resources with other teams or organizations, or when you want to centralize the management of resource sharing within your organization. It helps you to simplify resource sharing, reduce the complexity of resource management, and maintain control over the resources that you share. Here are the steps you can follow to use AWS RAM:
Note that you can only share resources that support sharing, and some resources have additional sharing requirements. For example, you can’t share an EC2 instance unless it’s in a VPC. You can learn more about AWS RAM by visiting the AWS page here: https://aws.amazon.com/ram/ .
As of now, you have learned that managing users’ security is the responsibility of your organization, but what if you are developing a web or mobile app open to the world? In those scenarios, you must manage millions of users, secure their credentials, and provide the required access. Amazon Cognito fulfills these needs. Let’s learn more about it.
Amazon Cognito enables developers to add user sign-in, sign-up, and access control to their web and mobile apps. It provides granular APIs and SDKs to manage end-user authentication, and authorization workflows that can be customized using out-of-the-box integration with AWS Lambda.
Cognito is fully managed with a built-in hosted UI and provides out-of-the-box support for open standards authentication protocols such as OAuth 2.
You can easily integrate your app to authenticate users using federation with Facebook or login with Amazon, Google, and custom OpenID Connect or SAML providers. It provides a serverless fully managed directory to store and securely manage user information using MFA authentication through SMS and email. Amazon Cognito offers authentication, authorization, and user management services for web and mobile applications. Here are some of the security features of Amazon Cognito:
You can learn more about Amazon Cognito by visiting the AWS page here: https://aws.amazon.com/cognito/ .
In this section about the security services in AWS’s IAM pillar you learned about managing user security in AWS. As AWS security is a vast topic that would require multiple books to cover in detail, in the upcoming section, you will learn a bit about each AWS service belonging to different security pillars with resources to learn more. Let’s learn about the next security pillar, which helps you detect and control security threats.
Security is more about preventive gestures than reactive as any security incident can cause significant damage to organizations, so it’s better to detect and fix incidents before a security leak can cause damage. AWS provides an array of services to help you to monitor, detect, and mitigate security threats. The following is a summary of services to apply proactive security control:
The following are common security audit services:
AWS Config: AWS Config enables you to assess, track, and evaluate the configurations of your AWS resources. With AWS Config, you can monitor the changes to your resources and assess their compliance with internal policies and regulatory standards. Additionally, you can use AWS Config to conduct security analysis and improve the visibility of your resource configurations, making it easier to identify potential security risks and respond to any incidents. Overall, AWS Config provides a centralized and automated way to manage the configuration of your AWS resources, ensuring that they remain compliant and secure over time. You can learn more about Config by visiting the AWS page here: https://aws. amazon.com/config/ .
AWS CloudTrail: AWS CloudTrail provides a record of all API calls made to your AWS account. This service enables you to monitor and audit your AWS resource activity, including changes to your resources and the actions of your users and applications. With AWS CloudTrail, you can gain greater visibility of your resource usage and security posture, as well as quickly identify and respond to any suspicious or unauthorized activity. AWS CloudTrail supports multiple platforms, including the AWS Management Console, AWS CLI, and AWS SDKs, making it easy to track and manage your AWS resource activity from a variety of sources. You can learn more about CloudTrail by visiting the AWS page here: https://aws.amazon.com/cloudtrail/ .
Amazon VPC Flow Logs: VPC Flow Logs enables you to capture information about the IP traffic going to and from network interfaces in your VPC. This service allows you to track the traffic flow and troubleshoot network connectivity issues, as well as improve the security of your network by identifying any potential network threats or unauthorized access. You can learn more about Flow Logs by visiting the AWS page here: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html .
Amazon CloudWatch: CloudWatch is a monitoring service that enables you to monitor your AWS resources and applications in real time. With CloudWatch, you can monitor metrics, logs, and events generated by your resources and applications, and set alarms to be notified of any issues. This service provides a centralized and automated way to monitor your environment, making it easier to detect and resolve issues, improve the performance of your resources, and ensure the availability of your applications. CloudWatch supports a variety of resources and services, including Amazon EC2 instances, Amazon RDS databases, AWS Lambda functions, and many more. You can also use CloudWatch to monitor custom metrics, such as the number of requests made to an application, the response time of a database, or the disk usage of an EC2 instance. You can learn more about CloudWatch by visiting the AWS page here: https://aws.amazon.com/cloudwatch/ .
Let’s learn about security control services in detail.