Designing secure workloads is essential to protect your data and systems and to be able to respond to security threats in a timely and successful manner. When you design a new solution on Amazon Web Services (AWS), security is the first topic you want to focus on. Whether the application that you design is a public application or for internal use only, it is paramount to establish a trustworthy, secure foundation on AWS for your application to run in a safe environment.
In this chapter, you will learn how to control access to resources across multiple AWS accounts in your organization when building a new solution. You will look at applying security and compliance controls and go through the measures and the AWS services to leverage for the following topics:
The first security aspect to consider for your application is the credentials and the associated permissions that are necessary both for the application components to do their jobs and for the end users to be able to interact with the application.
The complete set of features available on AWS for identity and access management (IAM) was already discussed in Chapter 1, Determining an Authentication and Access Control Strategy for Complex Organizations, but here a quick recap of the major concepts for this chapter’s discussion. If, at any moment, you feel you need more information to fully understand this part, please refer to Chapter 1, Determining an Authentication and Access Control Strategy for Complex Organizations.
When designing your application on AWS, you will leverage one or more AWS services to fulfill its mission. Accessing those services requires permissions, thus you must provide the necessary credentials for your application to work. IAM provides two types of entities— users and roles—for this purpose. IAM users are allowed access to AWS resources either through the AWS Management Console (by providing a username and password) and/or programmatically (using an access key and a secret access key) from the command- line interface (CLI) or one of the AWS software development kits (SDKs). IAM users are given permissions either by being directly assigned IAM policies or by being assigned to an IAM user group. IAM roles are like IAM users in the sense that they also provide access to AWS resources and define what the end user or application assuming that role can do on AWS. There are two major differences, though. The first one is that a role is not associated with a single individual or application, but it can be assumed by multiple entities (users or roles). The second major difference is that IAM roles provide temporary credentials as opposed to IAM users’ long-lived credentials.
As much as possible, it is good practice to use temporary credentials, which means preferring IAM roles to IAM users. Temporary credentials take a thorn out of your side since you don’t need to store those credentials for more than the duration of the session for which they are valid. On the other hand, if you need to use long-lived credentials, you also need to secure their storage, which requires particular care, can be tricky, and inevitably increases your security risk exposure.
What can temporary credentials be used for, then? Well, they can be used for pretty much everything on AWS. IAM roles can be used for end users, applications, and AWS services themselves. There are a few exceptions where you need to rely on IAM users and long-lived credentials.
One such notable exception is, for instance, if you need to create Amazon Simple Email Service (SES) Simple Mail Transfer Protocol (SMTP) credentials for sending emails via SMTP—this can only be achieved by an IAM user (at least, at the time of writing this).
IAM roles are the standard mechanism through which AWS services call each other’s application programming interfaces (APIs). Whenever one service—for example, Amazon Elastic Compute Cloud (EC2)—needs to call another service’s APIs—for example, Amazon Simple Storage Service (S3)—then the caller service must assume a service role that gives them enough permissions to invoke the called service’s APIs they want to use. It is also recommended to use IAM roles to invoke any AWS service APIs when calling them from your own application.
Last but not least, if your application needs to authenticate end users before granting them access, in many cases you will be interested in leveraging identity federation, relying on a third-party identity provider (IdP). This is true whether we are talking of a public-facing application or an internal application. In the former case, you will rely on an external IdP such as Apple, Facebook, Google, or Amazon. In the latter case, you will want to rely on a pre-existing corporate IdP, such as Microsoft Active Directory (MS AD), not only to avoid impacting your admin’s identity management process but also to avoid duplicating identities. There can, of course, be exceptions if you wish to start from a blank slate, free of ties with any pre-existing corporate environment.
The next section dives a little bit more into service roles and end user identity federation.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
