Identity and Access Management also known as IAM on Amazon Web Services. IAM is an extremely important concept. IAM is so as the name implies IAM as a permission system that regulates access to AWS resource is so really it helps you as the administrator define who can access what on an AWS account. Secondly IAM users allow you to assign broad or specific permissions to groups of users or even specific ones. Broad permission could include things like providing access to an entire AWS service such as Dynamo DB.

For cloud-based solutions for the businesses like Google, AWS, and Azure please visit:

Whereas specific permissions could include fine grain access to a particular S3 bucket to perform read and write operations. Third IAM provides a mechanism to monitor and audit access to specific resource is by enabling Cloud Trail and finally for those of that are in large organisations with existing identity technologies. IAM can easily integrate with them so that is a high-level overview of what IAM is.

For cyber security related issues of businesses please visit:

There are four key concepts that you need to be aware of when using IAM. There are users, groups, roles and policies being the official name but refer to them as permissions. Through each of these one my one. So, users refer to specific individuals 20 login and password so they can access the AWS console on their own. Although they will have a limited set of permissions that you define. Users also have secret keys and secret access keys which are used as inputs when setting up clients in your application-level code. Then there are groups which simply referred to a collection of users with a common theme. On example could be in turn students and senior developers, obviously we want intern students to have a very different set of permissions than a senior developer and third there are roles which act as a collection of policies. For example, you can define a role that has both database read and database right permissions to a specific AWS dynamo dB table. Rules have a slight nuance and that they are typically not directly tied to individual users and are meant to be assumed by anyone who needs it.

For instance, you can use rules to allow users within a different AWS account to access one of your Dynamo DB tables by creating a role with the right permissions and then granting them the ability to assume or use that role and finally there are policies which really are the bread and butter of IAM. These things define the specific low-level permissions for access resources and there are two variations to these there is either allow or deny. So, you can allow or deny permissions to resource.

For Data security related issues of businesses please visit:

Practical example what how an organisation may set up IAM. In this example, we are working with one group A, group of intern students. We have three users that we have defined Jack, Mandy and Sofie. Now Mandy and Sofie are intern students. To perform, let us give them fewer or more restrictive permissions than other users. Say we have two policies now, so we have a Dynamo DB basic right which gives us the ability to perform a put item operation on a specific table and then we have a dynamo DB basic read which gives us the query and get item permissions also on this table. So, in this example, we want to associate this group with the dynamo DB basic read permissions to give Mandy and Sofie access to this DynamoDB table and that is something that is very simple to do. In the AWS console you just go to the group section and add a policy and select this policy that has the permissions that you need. What about Jack, who is left all alone. Now John wants to access this table as well he wants to access the put item in the query and get him. So how can we do this, well we can create a Dynamo DB reader right role and with that role we can associate these two policies with it.

For general IT Support services for Businesses please visit:

Now anyone that is using this rule will have access to these resources and these specific API endpoints. So, when we go to the user section for Jack, we can grant him this time want to be rolled in doing so giving him access to this table for the quote item in the query and get item APIs. So that is a simple example of how you may set this up in an organisation. So let us move on to best practises when using IAM lot of big ones that and the first and most important bold in underlined is to use the least privilege model. So, this means to only give users the minimum set of permissions they need to perform their tasks do not go ahead and give too many permissions because it can lead to vulnerabilities, or some people accidentally delete in production database tables. So, use the least privilege model and secondly exercise caution when modifying existing policies and it is very easy to modify a policy thinking it is safe to do so and then find out one of your production applications was using that policy and suddenly lost access to a resource. So just be careful when modifying production IAM configuration.

For general support issues of home users please visit:

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.