On Thu, Feb 15, 2001 at 10:51:26AM -0700, Sasha Pachev wrote:
>
> >What about the case where a slave can communicate with the master, but
> >clients of the slave can NOT communicate with the master (because of
> >firewall setups)?
> >
> >Security folks like this setup because the number of slaves is fairly
> >static. They are easy to keep track of. But the clients could be any
> >machines behind the firewall.
>
> If the slave can update the master by proxy, security-wise this is
> equivalent to anybody who connects to the slave being able to do
> anything a replication user can on the master. So in that case, this
> is the same as connecting directly to the master anyway with slave
> user privileges. Additionally, access to the master can be
> compromised by loose security on the slave. So while security folks
> may like this setup, it is actually less secure than allowing direct
> connection to the master from all places that are allowed to connect
> to slaves.
No, no, no, no...
Imagine this setup:
db.master <-----> firewall <----------> firewall <-----> db.slave
internet ^
|
|
client1 <-----+
|
|
client2 <-----+
|
|
clientN <-----+
Where db.master and db.slave are on the public internet (but behind
firewalls so that db.slave can only talk to db.master's TCP port
3306. And client's 1...N are in an internal, non-routable
network. They can't been seen from the outside. The only way for them
to update the master would be to go thru db.slave.
Are you saying that it'd be just as secure if I put clients 1...N on
the public internet as well, when they really don't need to be?
Jeremy
--
Jeremy D. Zawodny, <jzawodn@stripped>
Technical Yahoo - Yahoo Finance
Desk: (408) 328-7878 Fax: (408) 530-5454
Cell: (408) 439-9951