Mucho Snippo
> Someone wrote:
> > > > > Is putting your web server behind your firewall I wise thing to do?
>
> > > I disagree. You can put your web server in the DMZ when that web
> > > server has to interact with a database on the other side of the
> > > internal firewall.
>
> I am hoping to explain that if your web server has to access a database
> that must be behind the firewall, then you make sure you controll access
> at the internal firewall--making sure you apply all the necessary
> controls.
>
> Intenet -- External Firewall -- (DMZ) -- Internal Firewall -- Comany Net
Have had same question come up a lot, lately. This answer may not relate
to your problem, but:
I've had several requests for providing access to large amounts of data
on a mainframe or other large dataset via a web server. In all cases, the
requesting party wanted a public 'net presence, and also wanted to
provide access via a web server to corporate data for paying clients.
As the datasets changed frequently, and in a couple of cases were far too
large to be "sneaker-netted" between an internal and external system via
removable media, we decided that the best config was to set up two
different web servers; a public system in a dmz, between a screening
router and the firewall, and a second system, for "paying clients" only,
on a seperate feed, and also in a dmz as described above. The second
system is a commercial web server on a stripped down system, and the
screening router only permits traffic from specified client addresses (of
course, this is only as good as the security of the "trusted" systems).
Access from the commercial server to the internal data will be to a
"read-only" mirror of the dataset (don't ask how this is configured, I
don't mess with the datasets and this part hasn't been set up yet).
One of the datasets is on a 3090, accessed by an OpenConnect gateway
running on a Sun. The other dataset is to be an Oracle database running
on an HP 9000.
Anyone come up with a better solution?
- r.w.
References:
|
|
