I agree with Corion's comments.
I would lean more towards using a tokenisation system (especially if dealing with CC details). I also would not download, load and delete a pm file in the manner you suggest. What I would do is make a fast API interface available on that separate machine. This allows you to tightly restrict access and upgrade your secrets easily (or even implement a completely different system, maybe even to provide one-time secrets), along with giving you some additional logging abilities that loading a pm wouldn't necessarily allow.
Imagine if you know that when someone does x on your website that it causes a, b and c to happen, which generates 2 requests to your secrets API. Now if your logging detects that someone doing x has actually generated 4 requests to your secrets API, you've just identified a possible intrusion and you can do something about it before too many customers are potentially compromised.
In reply to Re^3: Effective database column level encryption?
by SimonPratt
in thread Effective database column level encryption?
by maruhige
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |