Multiple Access Keys for the Same User - amazon-web-services

I have discovered that there is a particular User that is enabled for programmatic access in my company's AWS account. I have been tasked with recreating an Access Key and Security Token for one of my colleagues, despite it already having one. I want to deactivate the original one. I feel that from a security standpoint, it is better to have only one Access Key/Token rather than multiples.
Can anyone tell me if this is a good choice to have? One of my colleagues has asked me why I would want to do that and when I told him my reasoning, I dont think he was a 100% convinced my reasoning was good. Can you please tell me if there are any advantages to having multiple access keys/secret keys to the same user? Because I can't think of any. Also, can you please provide any kind of supporting articles that would cover this?

I don't have docs for recommending a single access key per user, but AWS does recommend rotating access keys regularly. See Managing Access Keys for IAM Users, the section titled "Rotating Access Keys".
So you should, as best practice, do the following on a regular schedule (every 30, 60, 90 days, etc.)
Create a second access key for your user
Wherever you are using the first access key, replace it with the second
Wait a short time, and confirm the first access key is not being used.
After confirmation, disable or delete the first access key
The two access key system is to allow for this rotation to occur while keeping the time where an access key is disabled/deleted, but still being used to a minimum. I've been bit in other tools where you have to disable the old key when you generate a new key. Because sometimes it takes time to put the new keys in use after they're generated.
If a user needs more than one access key, then there should be a question why one needs to be, rather than multiple. There are benefits to using multiple users:
The permissions can be more granular
If a key gets leaked, there are fewer places where it needs to be replaced
You have a better audit trail of what tools are acting on your account, and when
For these reason, I recommend only having one access key "in the field".
I think, really, if someone wants to actually use 2 keys for a single user, they're just being lazy.
I create individual IAM users and roles for every tool that needs access. I never reuse them.
Update
AWS recommends rotating access keys on a regular schedule.
Source: http://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html
Further, their "howto" on the key rotation process uses both allocated access keys on an IAM user:
Source: https://aws.amazon.com/blogs/security/how-to-rotate-access-keys-for-iam-users/
Ergo, target for one access key "in use" per IAM user at any given time.

Under AWS IAM Access Keys best practices I believe these sections apply:
Use different access keys for different applications. Do this so that you can isolate the permissions and revoke the access keys for individual applications if an access key is exposed. Having separate access keys for different applications also generates distinct entries in AWS CloudTrail log files, which makes it easier for you to determine which application performed specific actions.
Rotate access keys periodically. Change access keys on a regular basis. For details, see Rotating Access Keys (AWS CLI, Tools for Windows PowerShell, and AWS API) in the IAM User Guide and How to Rotate Access Keys for IAM Users on the AWS Security Blog.
The first item clearly gives a reason to use multiple access keys with a single IAM account. I think using multiple keys would also make the second item, key rotation easier. You could create a second access key set, switch your applications over, verify that the previous set is no longer being used to access the AWS API, and then delete the old set.

Related

Seeing "Programmatic access with active access key" for old user in AWS

In the AWS User administration section, I am wanting to remove an old user from groups, however, I am seeing "Programmatic access with active access key - 15 days ago" under his Last Activity column.
Does this mean his key could be in use somewhere in our codebase? I'm not seeing any information on what this message means.
If his key is in use, is there a way to find out more information about where it is being used?
When viewing the user in the IAM console, you can view their Access Keys in the Security Credentials tab. This tab will show the Access Key ID, Created, and Last Used. You can use these details to see what the ID of the access key and what service and region the key has been used for most recently (with a few minute delay). This is also where you can disable the key without deleting it if you want to do some targeted testing to determine what may use the key.
If you have Cloudtrail enabled and setup, you can also search using the AWS Access Key attribute as #jordanm mentioned.

AWS KMS How to 100% sure that it is not stolen from others?

I am proposing to use AWS KMS to encrypt my database. However by boss challenge me that what if the someone in Amazon staff has access to steal my KMS and decrypt my database.
The information inside the database is very important and cannot take any risk other people can decrypt it.
Is there other solution to solve this issue? to make sure no one can steal the Key?
Should we use some on-prem HSM to store the key instead ?
As the FAQ points out, AWS KMS is designed such that
no one, including AWS employees, can retrieve your plaintext KMS keys from the service.
If you read further down, it also provides links to various articles detailing the specification and design of the KMS. And as you can see from the volumes of these articles, the full scope of design consideration and how it complies with FIPS certification is beyond the scope of this answer.
However, as an example, refer to the cryptographic details tech paper for some ideas of how it works. There are 2 areas mentioned where keys are present:
In the KMS Keys Repository
In the HSM modules
KMS Keys Repository
The repository serves as durable storage for the keys. Keys are, of course, stored encrypted. The article further explains that the key repository leverages on IAM roles.
Only under AWS IAM roles and accounts administered by each customer can customer KMS keys be created, deleted, or used to encrypt, decrypt, sign, or verify data.
This is the same way authentication and authorization to any other AWS services are managed. Hence, this is one way to prevent AWS employees from gaining access to the keys. How IAM works and how it is secured is once again beyond the scope of this answer.
HSM Modules
Unlike the KMS keys repository, the HSM Modules will have access to the plain text keys. However, the plain text keys are only loaded in-memory for the duration that they are used. They are not durably stored in the HSM modules.
These keys are made available only on the HSMs and only in memory for the necessary time needed to process your cryptographic request.
Hence, employees with access to these modules would be able to theoretically gain access to these keys. To mitigate this risk, if you go to the design goals section, the article further explains the modules use quorum-based access controls.
Multiple Amazon employees with role-specific access to quorum-based access controls are required to perform administrative actions on the HSMs.
That is, no single employee will have administrative access to these modules. Multiple employees are always required. Once again, how AWS assigns which roles to which employees at which management level is beyond the scope of this answer.
As the question requested, these are just some of the considerations of how the service is secured against AWS employees. For an organization to make a decision on whether to use AWS, usually it should be based on a comprehensive set of security policies and an audit whether AWS complies to these requirements.
EDIT
Since you mentioned also how to convince stakeholders, this is usually a business question rather than a technical one.
I would refer them to AWS compliance for evidence that AWS goes through rigorous 3rd party audits. Would then point out the security of a system is only as strong as the weakest link. That is, using AWS does not mean we automatically have AWS security. We have to ensure our software, our people, and our processes are secure against exploits. So unless we are sure we have better security profile than AWS (with all their compliance and audits), our focus and worry should be more on securing our resources.

Can I make EC2 instance visible to all users in an organisation?

I have an organization and I want one user to create the EC2 and all other to be able to access it. Is that possible?
Short answer: yes.
Long answer:
Depending on how you grouped your "organization", implementation methods vary.
For example, if you defined it outside AWS, you can share the SSH key inside a shared, controlled space for your organization (like a Github repo). This isn't recommended for obvious security reasons. If you like the SSH route, it may be worth looking into setting up AWS Secrets Manager to create "rotating keys" such that previously shared keys won't grant malicious users access.
You could also look into setting up AWS Session Manager which ties into your IAM roles/policies and therefore allows you to do your access management within AWS.
There are many other methods in setting up user management, but these are the ones I see most frequent.

AWS Access Key Rotation

I am planning to rotate AWS keys.
My question is, will program throws an exception if we use expried AWS Keys?. If yes, what is the exception it is going to throw.
I didnt find any api to check the expired AWS Key.
Can someone pls help.
IAM Users can have two active Access Keys.
Therefore, the normal rotation process is:
Add a new Access Key
Update all software to use the new Access Key (this can take several days)
Revoke the old Access Key
Access Keys do not "expire". They are simply deleted. Trying to make a call on a deleted set of access keys will result in an error that the credentials are not found.
See: How to Rotate Access Keys for IAM Users | AWS Security Blog

AWS Access keys vs keyPairs

I am very new to AWS and while getting familiarized with key concepts, I came across two distinct set of keys to which I think we could do with either without needing the other.
So the two keys that I want to talk about are
AWS Access Keys and AWS Key Pairs. From my understanding Acceskey and secret key are like user name and password which I can use to call CLI and API etc. while Key pair is used for Ssh-ing to my EC2s but what I am still failing to understand is that why did AWS have to create two similar concepts. Why didn't they just keep one pair of keys and have users use them for all the operations?
The use of public-private keypairs is standard in the IT industry, especially with Linux-based computers. Anyone who uses Linux in a corporate environment would likely be using keypairs.
Access Keys and Secret Keys are the AWS equivalent of a username and password, but for API calls. This is necessary to authenticate to AWS to prove that you are permitted to make the API call.
So, AWS did not "create two similar concepts". One is an industry standard for logging into a computer, the other is used to authenticate to AWS.
It is created to distinguish two types of users,
Access keys are for users who have create and own instance.
Key pairs are for those who are users of ec2 instance.
Owner can create multiple key pairs for granting access for users (one for each)
Users don't need to share access keys of owner as they don't need to create resources thus maintaining separation of concern.