Re: Where are all of the /400's going. Was: QUSER on ODBC requests

["John Earl" <johnearl@xxxxxxxxxxxxxxxxxx>]

> >
> > I think it would be beneficial to the list to reflect on what
you
> > _really_ just said.
>
> Or at least your perception of it.
>
> > You said (and I'm paraphrasing heavily here), "Rather than
> > properly securing your OS/400 applications, you're better off
> > pulling data off of the /400 and dropping it on a Linux or
> > Windows machine that you don't have to bother securing."
>
> I said nothing of the sort.  If you read the thread, I
carefully separated
> data into two categories: secured and unsecured.  This is a
real and vital
> differentiation.  Secure data should be on a secure server, and
for me,
> that's OS/400.  Unsecured data, on the other hand, is more
problematic.

I typed "said" and perhaps should have typed "heavily implied".

While I agree on the task of separating data into "secured and
unsecured", I disagree that this distance requires the physical
space afforded by two different hardware platforms.  If you've
got the robust security features of OS/400 available to you, you
can separate the data on the same box.  For you Separation seems
to be at the hardware level, I maintain that library level would
be adequate.  But I suspect you and I will have to agree to
disagree on this point.

>  It depends on the currency requirement in relation to secure
data - that is,
> how closely does the unsecured data have to reflect secured
data.  Static
> web pages by definition have no such requirement, while account
status in an
> online trading system requires pretty much direct access to
secured data.
> The less current the data needs to be, the better the argument
for
> offloading it for two reasons: security and system load.

I think that this paragraph's reference to system load can be a
convincing argument for offloading static web pages to a less
expensive (to purchase) platform.  However, the arguement that
"static" information has no need for security just doesn't make
sense.  There is lot's of static information that is well
deserving of the best protection money can buy.  My Social
Security number, the Coca Cola formula, Sate Farm's actuarial
algorithms, etc. etc.  Just because data does not normally change
doen't mean it should be left unsecured.  Remember that
disclosure is the most common security breach.  This is true
whether you are serving the data via web pages or not.

jte