[EMAIL PROTECTED] wrote:
> But surely, putting company data onto the DMZ goes against the rules of DMZ
> design? The servers in the DMZ cannot be trusted so data should not reside
> there true?
This largely depends on the business needs of your deployment. One scenario, may be
The need for an RDBMS on the Web server to hold catalog info, user personalization
information, and
orders.
The communication with an RDBMS at a bank or service bureau that holds credit card
numbers to be billed.
The communication with an RDBMS in the distribution center (DC) that collects orders
in batches from the
Web server.
There are some good things about this solution. You aren't responsible for keeping
customer credit card
numbers secure. Data that are needed for real-time decisions are kept close to the
programs that use the
data.
However, performance may dictate the architecture. For example, the Web server needs
a lot of data from
the DC tables before it can offer delivery information.
Hence, to address this, one may wish to keep COPIES of the necessary DC tables in the
Web server's RDBMS.
Every time an update or insert is made on the factory RDBMS, the transaction is
duplicated on the Web
server RDBMS. This database replication is readily available from companies like
Oracle.
On the other hand, you have to budget extra time and money to develop and maintain a
replication strategy.
So you might consider eliminating the RDBMS next to the Web server and configuring the
Web server program
to make an encrypted connection to the factory RDBMS.
Or... you have the option of replication or eliminating the DC database all together
and having the DC
client programs talk directly to the
Web server RDBMS.
With regards to the billing... Suppose that you want to offer customers the option to
"bill the same
credit card as on your last order" In that case you either need to keep the old credit
card numbers
yourself or have some means of communication between your database and your
transaction vendor (bank).
Or if your accounting system can run the credit card numbers. In that case, you will
probably want to
eliminate the RDBMS at the bank and tightly couple the Web site to whatever RDBMS
installation is running
the accounting system.
A step in the right direction would be to ask yourself, "What data is needed to be
presented in the web
server and where does it reside now?" Then ask, "Why I need this?" If justified - the
performance
questions kick in, i.e., "What are the acceptable performance parameters for data
accessibility?". Now
balance your answers with the Risk assessment questions, "What are the acceptable risk
factors that must
be accounted for...?"
Hence, its not DMZ philosophy that will drive your architecture - as with most IT
projects, as much as the
techie world may disagree, it will be your clients business needs that will drive it.
It will be up to
you to determine what percentage solution shall be driven to meet this need.
Hope this helps,
Jennifer
>
>
> Simon
>
>
> D Clyde
> Williamson To: [EMAIL PROTECTED],
>"'[EMAIL PROTECTED]'"
> <dclydew@inte <[EMAIL PROTECTED]>
> rhack.net> cc:
> Sent by: Subject: Re: Opening up ports 139,
>1494, 1604 - Am I safe?
> [EMAIL PROTECTED]
> imited.com
>
>
> 08/06/2000
> 15:12
>
>
>
> [EMAIL PROTECTED] wrote:
>
> >
> > Secondly most e-commerce businesses MUST open up ports from their DMZ to
> > their INTERNAL servers for reasons such as database transactions say, so
> > how do these people protect themselves from attack?
>
> That isn't entirely true. Many companies export their database to a DMZ
> server. Others
> use message brokers to ferry information back and forth. There's always
> more than one way
> to do it. If push comes to shove, you may want to place your SQL stuff
> in a second DMZ,
> internal users can access it, external users can access it. The downside
> is that it could
> be compromised. The upside is that if it gets compromised, the rest of
> your network is still
> protected.
>
> **********************************************************************
> If you are not the intended recipient of this e-mail and have received it
> in error, you are on notice that the e-mail and any attached files are
> confidential. Please notify us immediately by reply e-mail and then delete
> this message from your system. Please do not use, distribute, copy or
> take any action in reliance on it as to do so could be a breach
> of confidence. The sender does not accept any responsibility for any
> loss, disruption or damage to your data or computer system which may occur
> whilst using data contained in, or transmitted with, this e-mail. Thank
> you for your co-operation. If you need assistance, please contact
> Maritz Ltd - tel.: +44 (0)1628 486011 or e-mail: [EMAIL PROTECTED]
> **********************************************************************
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
