- Newest
- Most votes
- Most comments
Your code shows AWS KMS being accessed with a static, long-term access key. Would you like to elaborate a bit on which kind of audience the credentials would be provided to?
For example, if any arbitrary internet user gained access to the access key ID and its secret key, there'd be nothing stopping them from abusing them, such as by generating arbitrarily large numbers of requests to KMS, S3, or other services in the context of the AWS account where the IAM user resides. Even if the permissions of the user are limited, requests to many services, such as S3 and KMS, are charged as API calls, even when the requests are denied, if they're made by the same AWS account or a different account that belongs to the same AWS Organization.
The reason I'm asking is mainly to ensure that the division of responsibilities between client-side and server-side code is as intended relative to what is technically possible to achieve with direct client-side access to KMS and the AWS account, before delving deeper into the specifics of how to achieve what is intended.
Hi,
You probably want to read and follow the guidance of this blog post to achieve your goal: https://aws.amazon.com/blogs/database/performing-sql-database-client-side-encryption-for-multi-region-high-availability/
Best,
Didier
Thank you. This was the approach I looked at initially and using the same approach in the code I have given above. I believe one of the approaches I can use is encrypting the sensitive columns using the technique mentioned in the link. Unencrypted ones I can still use to query the database.
Your approach to client-side encryption before sending data to the server is a valid method for enhancing data security, especially when dealing with sensitive information. However, there are a few considerations and potential improvements to your current approach:
-
Encryption granularity: Encrypting each field separately provides more flexibility but may increase overhead. Consider whether you need to encrypt all fields individually or if you can group some related fields together.
-
Key management: Your current approach uses AWS KMS for key management, which is a good practice. However, ensure that you're following best practices for key rotation and access control.
-
Performance: Client-side encryption can impact performance, especially for large datasets. Be mindful of the potential latency this might introduce to your application.
-
Data structure: If you're encrypting each field separately, you'll need to ensure your database schema can accommodate the encrypted data, which may be longer than the original plaintext.
-
Search and indexing: Encrypted data cannot be easily searched or indexed. If you need to perform operations on the data, you may need to implement additional mechanisms or consider partial encryption.
-
Encryption context: Your use of encryption context is good for adding an extra layer of security. Ensure you store this context securely as you'll need it for decryption.
An alternative approach could be to use the AWS Database Encryption SDK, which is designed specifically for database encryption scenarios. It allows for client-side encryption in multi-tenant databases by isolating each tenant with distinct encryption materials. This might be more suitable if you're dealing with a shared schema database.
Another option is to use the Amazon S3 Encryption Client, which provides a straightforward solution for client-side encryption, especially if you're storing objects rather than structured data.
Regardless of the approach, ensure you're following best practices for key management, regularly rotating keys, and securely managing access to decryption capabilities. Also, consider implementing additional security measures such as proper authentication and authorization, secure communication channels, and regular security audits.
Sources
How to use client side encryption for Postgres in a way that only the end user have access to their data? | AWS re:Post
Client-side encryption - AWS Key Management Service
Encryption in transit over external networks: AWS guidance for NYDFS and beyond | AWS Security Blog
Relevant content
- asked 3 years ago
- asked a month ago
- AWS OFFICIALUpdated 9 months ago
- AWS OFFICIALUpdated 10 months ago
- AWS OFFICIALUpdated a year ago
The application would be accessible to users over the internet, yes. But I am not sure how the Key ID and secret would be leaked, could you explain a bit more on that? I am using the https://www.npmjs.com/package/@aws-crypto/client-browser library in that above code. I have picked up the code from the docs.
The below part of your code runs on the client side, right? If so, the
accessKeyId
andsecretAccessKey
properties ofcredentials
passed togetClient
in the user's browser session contain the access key, don't they? All users would have direct access to them.To clarify my point a bit, the example you linked to says, "Create a KMS client provider with your AWS credentials." If the key belongs to the end user whose browser session runs the code, and the user knows and has legitimate access to the key anyway, there's no issue with them using it. But if the key belongs to a general IAM user created for this encryption purpose and the key is supplied to all end users running the client-side JavaScript code, that would give them access to your AWS account that they wouldn't otherwise have.