On 2009-10-02 13:57, Les Mikesell wrote:
> Alec Kloss wrote:
> > On 2009-10-02 14:08, Bob Archer wrote:
> > [chop]
> >> Some of this stuff also depends on what you are storing. Perhaps going another way would be better. For example, use NT Authentication to access your SQL servers rather than username/password. This way, the password isn't in the configuration file. I am sure there are similar LDAP type ways to deal with this for other technologies also.
> >>
> > [chop]
> >
> > Seconded. Passwords for services are a relic from the 80s.
> > Buildbots and so on should have a collection of keys that are used
> > to build things. Between GSSAPI, NTLM, PKI, and ssh public keys,
> > there shouldn't be too many technologies left that need a
> > clear-text password. Your source-controlled configuration files
> > should tell you which accounts should do what and you should have
> > encryption keys on the side accessable only by the accounts that
> > need them, and a rotation policy in place to ensure you don't find
> > yourself using a 512 bit PKI key you generated 10 years ago.
>
> OK, so how do you connect an assortment of perl/java/php services to an
> assortment of mysql/postgresql/sql server databases without something in
> the configurations that would be reusable if you can get a copy?
>
I'm more of a Kerberos than PKI/SSL guy, but the concepts are
essentially the same. You configure whatever unix account is going
to be running these services with access to some sort of encryption
key. Let's call this account "webapp". You use the OS itself
to harden access to the key so only webapp can access it. In
Kerberos, this would normally be a "keytab" and in PKI, it's a
PKI private key (plus associated certificates). This key is the
only thing you omit from your configuration change control. You
then configure each application that will be run by the webapp
service to know that it can use this key to authenticate to any
external resources it needs, like a RDBMS, Subversion, and so on.
It's clear in the event of a disaster recovery that the only thing
that needs to be regenerated is this encryption key. All other
information, like which key to use, is all change controlled.
As for the specific software you mention, I'm sure there's a lot of
variety in capilities. Postgresql definitely supports Kerberos and
I suspect also supports PKI, MSSQL probably supports both too, and
almost definitely supports Kerberos. I don't really know about
mysql. As for clients, I suspect since perl usually wraps the
native client libraries for things, it'll support anything the
servers will. Java is usually bad at this, as people like to
rewrite client drivers in Java without fully implementing the
server protocol. I'm not much a PHP user, so I can't say about it.
Worst case, since all of these use a TCP socket to communicate with
a server, you can use a third-party tool like stunnel or plain old
SSH tunnels to create authenticated tunnels between the machine
that webapp is running services on and the servers it needs to
connect to. This is a substantial pain, but can be done.
--
Alec.Kloss_at_oracle.com Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956
- application/pgp-signature attachment: stored
Received on 2009-10-02 22:10:37 CEST