Wednesday, March 7, 2012

my whole company and customer info/credit cards on the internet

I've been searching for a new ERP solution for my company for a while and I
think I've finally found the best one for us. But now I'm being cautioned
about some things so I need some good arguments about how I should setup the
database server.
The application is written in .net it is a N tiered application (I guess
that's what it's called) and it also has a tightly integrated commerce site.
The system was designed to work best with the app db and commerce db on the
same sql server. Desktop clients can connect by internet access if that
server isn't on the LAN and the website can even connect to the LAN but this
obviously wouldn't work because we're only using DSL here.
I've been cautioned that I shouldn't have internet access on my database
server. I somewhat understand the reasoning for this but to me it seems most
data is about as secure as the applications that access them in the first
place. So even if I had a state of the art network in place, a security flaw
in the app could screw me over regardless.
What is good business security practice for handling/storing sensitive
customer information on the internet and what is overkill/paranoia? This is
a serious questions so I'd appreciate not to be mocked.
I'm not a DBA so maybe I'm a little off on my terms, feel free to correct me
where I'm wrong. But it seems to me that if didn't use the same db server
for both the website and main system I'd have a lot of extra work like
replicating web data to web enabled sql server in our office and from the
"live server" on our LAN and then back again.
Thanks in advance for your advice/criticism/suggestions.
RobertForgot to mention. I was assuming to set it up like this
[dedicated sql server] - the only port enabled on this box is for mssql
would probably use a non default port
[dedicated web/email/application server] ports, email and web/ssl
(25/80/110/443)|||Normally what you do is expose the middle-tier (or even yet another system)
to the Internet, and then you only allow that system to connect to your
database server. Yes, if that system is compromised, there can also be
issues, but if you code correctly the only things exposed would be those tha
t
stored procedures or view expose. There are several good books on designing
secure web applications, so I suggest you check out your local bookstore for
one that fits your style.
"Rob" wrote:

> I've been searching for a new ERP solution for my company for a while and
I
> think I've finally found the best one for us. But now I'm being cautioned
> about some things so I need some good arguments about how I should setup t
he
> database server.
> The application is written in .net it is a N tiered application (I guess
> that's what it's called) and it also has a tightly integrated commerce sit
e.
> The system was designed to work best with the app db and commerce db on th
e
> same sql server. Desktop clients can connect by internet access if that
> server isn't on the LAN and the website can even connect to the LAN but th
is
> obviously wouldn't work because we're only using DSL here.
> I've been cautioned that I shouldn't have internet access on my database
> server. I somewhat understand the reasoning for this but to me it seems mo
st
> data is about as secure as the applications that access them in the first
> place. So even if I had a state of the art network in place, a security fl
aw
> in the app could screw me over regardless.
> What is good business security practice for handling/storing sensitive
> customer information on the internet and what is overkill/paranoia? This i
s
> a serious questions so I'd appreciate not to be mocked.
> I'm not a DBA so maybe I'm a little off on my terms, feel free to correct
me
> where I'm wrong. But it seems to me that if didn't use the same db server
> for both the website and main system I'd have a lot of extra work like
> replicating web data to web enabled sql server in our office and from the
> "live server" on our LAN and then back again.
> Thanks in advance for your advice/criticism/suggestions.
> Robert
>
>

No comments:

Post a Comment