Hello, and welcome to this lecture, where we will look at how the IAM service is used to help implement security across both container and abstract services.

IAM is tightly integrated with both of the shared responsibility models, and both of them require you to understand the different methods of using IAM to implement the different security controls around these services.

This lecture will not cover how to create and setup these controls. More information on how to do this can be found within our existing courses and labs, Introduction to IAM, and Advanced Roles and Groups Management Using IAM.

Regardless of the service, you must be familiar with AWS IAM. This will allow you to control who has access to which services and also under which conditions. IAM policies allow you to configure conditional access. For example, configuring access only during set time periods or from a specific IP address.

IAM enforces multiple methods of authentication and authorization against resources within your AWS environment. Detailed information on this subject can be found in our existing course entitled Understanding of AWS Authentication, Authorization, and Accounting.

So let's take a look at how IAM can help to control access to our container services, looking firstly at RDS.

An authenticated identity whether that be a user within your AWS account, a user from another account, another service, or even a federated user from your on-premise Microsoft active directory environment, the identity can access your RDS instance providing they have authorized permissions to do so. Using the correct permissions and access control, you are able to grant or restrict access on a granular level within RDS. For example, you can specify who can create an RDS database, who can access it, and who can run snapshots, et cetera, all through using IAM policies attached to the user, group, or role. As I said earlier, these permissions can even be based on specific conditions. For example, only to allow access at a specific time of day or from a specific IP address.

IAM policies are JSON formatted files. The following policy example only allows the user to create an RDS instance using the MySQL as the database engine type using the Condition parameter.

RDS permissions can only be given through IAM policies. There are no resource based policies that can be applied like it's possible within S3, such as bucket policies or S3 ACL's.

You must review who should have access to your database along with the correct level of permissions. Be as granular as possible when looking at data security across your databases. For improved management, create groups and roles, and apply permissions to these rather than individual users.

EMR also uses IAM to control access to its resources, such as the clusters and the data itself, again with policies, groups, and roles that we have already discussed. To understand the full level of access that can be granted or denied, see the EMR documentation provided by AWS.

By default, when an IAM user launches a new cluster, it is restricted to only that user. No other IAM users are ever to see the clusters; however, there is an option to make the cluster visible to all IAM users if required.

To help you manage permissions for EMR within IAM, you could always implement the AWS managed policies and assign them to users, groups, or roles. If they do not fully fit your requirements, then you can copy, edit, and customize these policies as required, which saves a lot of time and effort. And this applies to all services discussed within this lecture, and these AWS managed policies are a good source to base your permissions upon.

Looking at our abstract services, we can apply all of the same IAM security controls that we have already discussed; however, there are some differences worth noting. For example, when we look at S3, we can implement additional resource based access control methods, such as bucket policies and access controllers, which can specify permissions at an object level given granular access. When there are conflicting access permissions between IAM and resource based permissions, then access will be granted on a least privileged basis.

So, for example, the user John may have access of our IAM policy that grants access to delete objects within bucket CA-Lecture. In addition to this, there is a bucket policy attached to a bucket CA-Lecture that explicitly denies the principle John to delete objects. If John tried to delete an object within this bucket, he would be denied as access is granted based on least privileged and a denial will always take precedence over an allow.

As we are already aware, IAM allows you to create very specific permissions against different services for access. DynamoDB is no exception, and, in fact, with IAM, you can even grant access to specific rows within a DynamoDB table for specific users given a fine grained access control on the database itself.

As you can see, there isn't a huge amount of difference between how IAM is used to manage authentication, authorization, and access control to both container and abstract services. IAM is fundamental in granting users and services access to resources within AWS.

This access control centers around the following components of IAM:

• Users
• Groups
• Roles, and
• Permissions

Understanding how these interact with each other is imperative in applying an effective security policy from an access control perspective. Like I mentioned earlier, we have courses on IAM that go into these details in great detail, and I highly recommend you take these courses.

In addition to these IAM components, other services such as S3 may have their own resource level permissions, which you should invest time into understanding in order to help you add another layer of security to your data, and this may be required for specific governance controls depending on the data being used.

That brings us to the end of this lecture, and coming up next, we take a brief look at how some of the services have built-in functionality to help you secure your data. Understanding the services you're working with is just as important as understanding the security features offered by other AWS services such as IAM.

 

Lectures:

• AWS Security Best Practices
• AWS Abstract and Container Services
• AWS Encryption at rest and in transit
• Network segmentation
• Identity and Access Management
• Built-in Service Security Controls
• Summary