|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.