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.
Related
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.
I am looking for ways to automate the rotation of access keys (AWS credentials) for a set of users. There is a seperate process that creates the Access Keys. I need to be able to rotate the keys in an automated way. This link explains a way to do this for a specific user. How would I be able to achieve this for a list of users. Any thoughts or recommendations?
You can use AWS Config to mark the old access keys non-compliant (https://docs.aws.amazon.com/config/latest/developerguide/access-keys-rotated.html) and then use CloudWatch Events (my article how to do this) to run a Lambda function that deletes the old key, creates a new one, then send it to the user.
Access keys are generally used for programmatic access by applications. If these applications are running in, says EC2, you should use roles for EC2. This will install temporary credentials on the instance that are automatically rotated for you. The AWS CLI and SDKs know how to automatically retrieve these credentials so you don't need to add them in the application either.
Other compute solutions (Lambda, ECS/EKS) also have ways to provision roles for applications.
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.
I need to develop a solution to store both symmetric and asymmetric keys securely in AWS. These keys will be used by applications that are running on EC2s and Lambdas. The applications will need to be set up with policies that will allow the application or lambda to pull the keys out of the key store. The key store should also manage the key expiry, notifying various people when keys are going to expire. The initial key exchange is between my company and its partners meaning that we may have either a public or private key for a key pair depending upon the data transfer direction.
We have looked at KMS but from what I have seen KMS does not support asymmetric keys. I have also seen online that some people are using either S3 (protected by KMS) or parameter store to store the keys but this does not address the issue of key management.
Do you guys have any thoughts on this? or even SaaS/PaaS suggestions?
My recommendation would be to use AWS Secrets Manager for this. Secrets Manager allows you to store any type of credential/key, you can set up fine-grained cross account permissions to secrets, encryption at rest is used (via KMS), and secrets can be automatically rotated (by providing an expiration time and an AWS Lambda function owned by you to perform the rotation).
More details on the official docs:
Basic tutorial on how to use AWS Secrets Manager
Encryption at rest on Secrets Manager
Secrets rotation
Managing secrets policies
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.