Timeline for Public-private key pair handling on a Windows ecosystem
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 14, 2012 at 21:11 | history | bounty awarded | Machado | ||
| Aug 9, 2012 at 14:12 | history | edited | user53019 | CC BY-SA 3.0 |
Add'l references for DB security
|
| Aug 9, 2012 at 12:34 | comment | added | Machado | As a side note, I just read both Key Recovery links you provided, and I am convinced that this is not what I want to do. | |
| Aug 9, 2012 at 12:15 | comment | added | Machado | How this would prevent a developer with the restored database to view the data ? | |
| Aug 9, 2012 at 2:49 | comment | added | user53019 | You can easily automate the scheme that I'm suggesting, so I don't foresee that as a problem. Ultimately, some geek, some where, would be able to break the rules and look at the information if they so chose. Which is why I recommended putting auditing in place. If it's really, really, really a big deal, then create a separate DB and have the System password assigned by a trusted 3rd party or whoever. That can make maintenance a real PITA, so ponder carefully if that's the route you want to go down. You'll have the same problem or worse if you use certificates / keys. | |
| Aug 8, 2012 at 21:36 | comment | added | Machado | Sorry, I think I did not made clear that a DBA with access to the database should not be able to view the comments by SELECT'ting data. We don't want to give access to all the private keys tom someone, and the whole key-creation, delivering and management should be automated. | |
| Aug 7, 2012 at 20:09 | history | answered | user53019 | CC BY-SA 3.0 |