Subject | final: Where I find a really good security specific IB/FB group? |
---|---|
Author | ale_pira |
Post date | 2002-07-16T11:33:46Z |
Hi all,
My big thanks to everybody that answered, and my apologies for this
little 'gap answering'..
I taked some decisions here, and as you, want to share my point of
view:
1) For local (programs) access, I'll test a tunneling software, since
my network clients can see my db machine, or snif on the wire;
but this is really difficult to implement: a demand of installing new
software on hundreds machines is painful (almost sure to not do it..);
2) For web access, will take place a mid-tier machine, the only one
from 'extranet' wire that could connect to my db machine;
3) This registered machine will be surelly SSL-enabled, to protect
the public internet side of the access;
4) The traffic of these two machines will be done over a switch, then
only they will be seeing the data packets transmitted;
5) Console access highly restricted, remote console impossible;
6) Some users/roles accounts on db for read-only/web purposes, when
applicable;
7) On final phase, add a mid-tier machine for internal use, with
logging and alert facilities, watching for massive access (force
brute tasks) - this may be a good (but not pro-active) substitute for
task 1)..
This is all for the moment, thanks again!!
ale_pira
My big thanks to everybody that answered, and my apologies for this
little 'gap answering'..
I taked some decisions here, and as you, want to share my point of
view:
1) For local (programs) access, I'll test a tunneling software, since
my network clients can see my db machine, or snif on the wire;
but this is really difficult to implement: a demand of installing new
software on hundreds machines is painful (almost sure to not do it..);
2) For web access, will take place a mid-tier machine, the only one
from 'extranet' wire that could connect to my db machine;
3) This registered machine will be surelly SSL-enabled, to protect
the public internet side of the access;
4) The traffic of these two machines will be done over a switch, then
only they will be seeing the data packets transmitted;
5) Console access highly restricted, remote console impossible;
6) Some users/roles accounts on db for read-only/web purposes, when
applicable;
7) On final phase, add a mid-tier machine for internal use, with
logging and alert facilities, watching for massive access (force
brute tasks) - this may be a good (but not pro-active) substitute for
task 1)..
This is all for the moment, thanks again!!
ale_pira