Using Amazon Web Services IAM
IAM (Identity and Access Management) from Amazon Web Services is a tool to create users, groups, roles and permissions. This is a 10 minute video on how to use IAM (Identity and Access Management) services to provision users and groups within the Amazon Web Services infrastructure. IAM is a blunt instrument, and in general does not do as much as Active Directory or LDAP. It is also limited to the Amazon infrastructure as well unless you use IAM to provision simple user accounts from within a Software as a Service application.
There are some downsides to IAM that makes this a difficult item to use, and while Amazon is adding new capability all the time, it is important to note that IAM does not log individual user actions on their services. For example, IAM does not log that a hypothetical user “aphillips” started instance DSA-9999999-a at 10:30AM and terminated the instance at 12:30PM. It also does not log API calls or REST calls that are made. However, if using as S3 bucket with logging enabled you will see the REST call there, or accesses made to that bucket by ID date and time if you have enabled logging on the S3 bucket. This at least gives some level of logging for actions taken by users who are accessing pre-existing objects. For environments though that need a high level of logging specific user actions, then IAM is not going to be of help. While this is a requested feature from Amazon, there is no estimated time of delivery for the ability to log specific actions like starting up new services.
Another downside to IAM is that most of the work when adding large numbers of users should be done at the command line and programmatically. This does not alleviate the need to go back and verify that each account was done, but like many access management systems it can be time consuming depending on the size of the company and the number of users and groups that need to be made. IAM can also lead to overly complex security policies that could tend to limit users when they should not be limited. While it is easy to move users around various groups, if there is a large number of users to move to new groups if a company reorgs, it is not simply enough to rename the IAM container for a group. It is important to make sure that those changes are propagated to programs that require the security key and group permissions, as well as making sure that users are not impacted by changes within the companies changing structure.
The other downside to this is key management, if a company is not ready for key management, or has no easy way of storing keys securely then security credentials can become burdensome to the manual haphazard process that will be involved. When working with the programmatic aspects of coding for the API’s, key management, access to keys, and how programs access keys is very important. While it is possible to store keys in LDAP and Active Directory, some personnel will need to have their keys on their computers if they are using services in the Amazon Cloud programmatically. Key management requires a high level of security to ensure that the keys are not lost, or are otherwise not compromised.
Keys stored on laptops or on compromised computers can defeat any security that is put in place if using a key based login without a password. If a key is compromised, then the hacker or malicious user will have the same permissions as the person whose key was compromised. In the event of spear fishing, stolen laptops, or confiscated laptops it is important that keys on computers are stored encrypted, and that if the computer is reported lost or stolen that the user account keys are changed as soon as possible. Companies who do not have a key management solution should invest in a solution that will work for everyone across the enterprise that needs to access the back end services of Amazon Web Services.
(Cross-posted @ Managing Intellectual Property & IT Security)