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

Joe,

> However, in order to create any kind of "public" user profile
on your
> machine (such as a public demo user ID), there are a number of
steps to take
> to make sure this doesn't breach your security.  You must make
sure that
> this user profile is highly limited to only the data it is
intended to
> access - for example, set the initial program to *SIGNOFF.
Make sure you
> have a real security policy in place, with *PUBLIC authority
set to *EXCLUDE
> on all your objects and authority granted solely through group
profiles.  If
> you are using this "public" profile for FTP, you may also want
to write an
> FTP exit program that further secures and limits the requests -
for example,
> specifically disallowing remote command calls.
>
> A rather more secure answer to this thorny issue is to have a
staging area
> in your demilitarized zone.  Put a Linux or Windows machine on
your network
> and transfer "public" data to that machine.  There are a number
of products
> that will perform this sort of mirroring.  If you prefer, and
if your data
> is relatively static (that is, data can be updated nightly or
even hourly)
> you can roll your own data mirroring product without too much
effort.
> Transfer to the staging machine is entirely under the control
of the AS/400,
> in a "push" rather than "pull" communication, thereby ensuring
that the
> AS/400 is secure.

I think it would be beneficial to the list to reflect on what you
_really_ just said.

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."  This is
consistent with what appears to be the Windows Architecture
model, which is (IMHO) "If it's too difficult to figure out, just
drop another server onto the network" and separate (and
duplicate) the data.  I may be missing the real point here, but
it seems to me that a solution such as this adds complexity,
maintenance, cost, and when Security is involved, vulnerability.

Some of the wisest words that I ever heard on this list were Evan
Harris' response to the question "Should I put my production /400
on the internet?"  Evan's answer was "If you don't, it won't be
your production system much longer".  The reality of the
situation is that if we (collectively as a community of AS/400
aficionados) don't get security figured out on this machine to
the point where we are comfortable putting it directly on the
internet, the OS/400 is doomed to a dwindling legacy of green
screen apps that may get maintained, but won't be enhanced.

(That's not to say that the lack of properly secured applications
is the only thing holding the OS/400 architecture back - just
that it is now a big part of, and will in the future grow to be
an even bigger part of, why the machine get's replaced by Windows
and **IX solutions.)

Please don't take this note personally Joe, because your
suggestion represents a very prevalent current train of thought.
And while the first part of this post (and many of your previous
posts) demonstrate that you are someone who has taken the time to
understand /400 Security, I would hazard that the vast majority
of our colleagues have not.  And as you already know, it's just
not that hard (Hey, even I could figure it out so what does that
say?).

My bottom line is that security is important (else I wouldn't be
in this business, no?) - it may not be easy, or convenient, or
cheap, but if it's data, and it's on your /400, it's worth
securing.

jte

--
John Earl
johnearl@powertechgroup.com
The Powertech Group          www.powertechgroup.com
Kent, Washington, USA       +1 253-872-7788