[Feat] Allow AWS SECRETS MANAGER instead of storing AES Encrypted in db

[aluferraz]

This pull request introduces a significant security enhancement by providing an option to migrate away from storing AES-encrypted sensitive data directly in our database. Instead, it allows us to leverage AWS Secrets Manager to securely store, manage, and retrieve our application's secrets.

Key Highlights of this Change:

Improved Security: Sensitive data is now protected by AWS Secrets Manager's enterprise-grade security features, including encryption at rest and in transit, strict access controls, and auditing capabilities.
Compliance Alignment: This shift enhances our alignment with various regulatory compliance standards that recommend or mandate the use of dedicated secret management solutions for sensitive data.
Simplified Key Management: No longer will we need to manage AES encryption keys within our application, reducing operational overhead and potential security risks associated with key mismanagement.
Audit Trail: Traceble log of credentials

[aluferraz]

@HenryHengZJ any thoughts on this feature ? It can be toggled using env. vars.

[HenryHengZJ]

I'd prefer to have more generic name that can be reused in future for Azure Key Vault, Okta and other else.

Perhaps: SECRET_MANAGER_PROVIDER, the value can be aws, azure, etc

Also, search for the variable STORAGE_TYPE, you can similar references and other places that we need to declare these env variables as well

[HenryHengZJ]

All other 3rd party providers should provide caching: https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/data-key-caching.html#:~:text=In%20general%2C%20use%20data%20key,NET.

For security purpose, I prefer not to cache it in the application, but rather on your key vault side