Re: iSeries vs. Unix vs. SQL Server vs. Oracle & Security/Dataseparation???

["Nathan M. Andelin" <nandelin@xxxxxxxxxxxxxxxxxxx>]

> from: "Adam Lang" <aalang@xxxxxxxxxxxxxxxxxxxx>
> Yes it is.  The difference is, you have one firewall
> separating a malevolent person from everything.

Who is suggesting just one firewall?  A company may have several LANs, each
offering a point of control within the company.  Each LAN segment may be
controlled by a different firewall.  Each segment may serve a different
purpose.  A malevolent person should have no idea of the route to the
iSeries
server, or the number of segments a request passes through after connecting
to the public IP address, or the purpose of those segments, or what
protocols are supported on a segment, or what filters or translations a
message may pass through before connecting to the HTTP server.

When the malevolent hacker finally connects to the HTTP Server, what will he
think when the server responds with something like "Hello, you've just
connected to HTTP under OS/400"?  Why would you suggest that connecting to
an OS/400 HTTP Server would offer access to "everything"?  It sounds like
you're trying to pull a fast one!

> Whereas with a segmented tier structure, you, typically,
> have 2 firewalls and an application layer separating your
> data from said person.

Concerning the "application layer", shouldn't the question be which platform
offers the most secure environment for applications?

> If LPARing an iSeries will allow you to treat a
> web interface and application/data layer the same
> as segmenting it, then great, do it.

Someone must have suggested that multiple platforms are needed for security
purpose, and you believed them.  That's sad.

> But if you can't, then it is not an extremely acceptable
> method.

Isn't the real reason for dividing Web services, applications, and database
services across multiple tiers in the Wintel world because a single box
won't handle the workload?  You really haven't shown that it has anything to
do with security!

Nathan M. Andelin
www.relational-data.com