Try a Tor hidden service, configured with the low-latency/lower-privacy settings. It is slower than many of the other solutions, but very reliable and very simple.
I have worked with implementations of an online digital goods marketplace built by someone who was clever but had no notion of formal accounting, ledgers, etc. Their implementation worked, but was only just barely adequate and would have been more useful with a chart of accounts. Prototyping against an API like this would have been an informative exercise for them and probably saved a lot of time.
This depends on what you mean by "properly" and "impossible" and "professional" and "forward".
Many professional name-brand corporations use Tor daily.
The only ports opened are those you configure to have onion services. Port limiting is one of the major features of firewalls.
You don't get to control source IP ranges, but those aren't generally trustworthy on the open internet anyway.
Also, the traffic isn't "forwarded" -- hidden services shouldn't be run on a relay, actually, so you're not forwarding anybody's traffic but your own.
Also, barring the recent attacks on discovery of onion services, connecting to a tor onion service allows you stronger security guarantees and MitM defense than TCP+DNS+IP routes.
I generally have the same feeling, though https://github.com/go-gorp/gorp has worked very well for most of the database-heavy Go projects I've worked on over the last few years. It is just enough abstraction to be convenient and consistent and rarely gets in the way.
why shouldn't people have to rotate the underlying secrets?
a rogue employee who created a secret, or any engineer who had to access that secret to get their job done, is always going to be able to use that secret value, regardless of where the encrypted blob is stored.
seems like we should be making it easier to rotate secret values often and automatically.
For AWS users, KMS's GenerateDataKey is a simple way to store secrets locally in a way that reuses your IAM policies. You can also use grants and EncryptionContext to restrict the ability to decrypt secrets in a very fine-grained manner. As a bonus, all decrypts are logged in CloudTrail. The KMS docs are awful but if you're on AWS then it is worth checking out!
One common use case is in workflow systems. For example, you might "wait" for a bunch of files to exist before kicking off a job. This could be implemented as a bunch of "subjects" notifying when the files exist, and then the "observer" taking action when all of its subjects notify.
It is also used in UI frameworks to update visual representation when underlying data changes.
This page does not adequately address many of the practical questions that orgs with secrets should be asking.
Examples:
* Does it integrate with my existing infrastructure security policies?
* Does it introduce a new set of principals for me to track and manage?
* Are the configurations stored in a cleartext manner suitable for storing in version control?
* Will the audit logs integrate with my existing audit log tooling?
* Does it help or hinder continuous deployment? In other words, will my code be littered by conditionals to support non-prod jobs?
* Can my devops team run this or does it require additional staffing?
* How many layers is this adding between me and the security primitives offered by my platform (Windows AD, AWS IAM, etc)
* Is it serverless, or does it require me to run additional servers?
* How do I ensure continuity if the software is no longer actively developed?
* Can it deploy secrets to dev and test environments in the same way?
* What's the revocation story?
The answers to most of these questions for most of the tools that have made it to HN recently are not promising. For AWS the best choice seems to be using KMS directly and integrating your app with the declarative configuration tools AWS offers (IAM, CF, MFA).
Outside of AWS, Vault is the only one that I've seen which handles real-world end-to-end in a responsible way. For example, Vault is the only one that doesn't focus strictly on storing static values: Vault can integrate with services such as Postgres and SSH to dynamically provision time-limited credentials (https://vaultproject.io/docs/secrets/postgresql/index.html).
In addition to sanddancers comment, you can also do things like:
- issue ephemeral certificates (with expiration in the near future) to allow a machine to perform an action but only for a certain amount of time (for example: to fetch credentials from a source to store in memory during machine provisioning).
- use client certificates to authenticate your end-users for secure web apps.
- easily build machine-to-machine trust models that take commercial CAs out of the picture
I'm excited to see more work being done to empower small engineering teams to take advantage of certificates. Lemur looks great, though many smaller organizations may find tools like "xca" to be adequate. xca is a simple GUI for certificate management: http://xca.sourceforge.net/
The MFA Condition is a huge win, and I'm surprised Amazon hasn't built this a tool to make this easier yet.
However, I question the merit of using two separate AWS accounts. While this separation of responsibility sounds nice in theory, doesn't it introduce additional maintenance burden because you now have two accounts to administer? You can't define or manage the roles in the 2nd account without credentials to do so.