|
> From: rob@dekko.com > > Everyone may rant on how hard coding user id's and passwords are > a bad idea > but there are some applications where this is a necessity. Well, > I suppose > you could put them in a dataarea or some such animal but you get the same > results. > > For example, you want to do some batch ftp between one system and another. > Remember I said batch. And you get this EDI process that runs unattended. > I have no urge to hire someone to key in a userid and password. If I did, > I'd make the poor bugger click on icons or some other worthless > application > to look busy. > > Again, I have a Domino application which gets data from the 400. The > people running this application sometimes don't even have iSeries > passwords. Are you saying that instead of just clicking on a button to > retrieve the data, that now I should also pop up a box that prompts them > for an iSeries user id and password? Ludicrous! There are two kinds of data: secured and unsecured. Examples of unsecured data are public web pages and the data they display. Now, if you have a Domino application that is designed to access AS/400 data, you have to decide whether the data is secured or unsecured. If the data is, for sound business reasons, meant to be unsecured yet hosted on the AS/400, then by all means create a user profile with access to the data and make the user ID and password public. 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. This can also be usd for batch transfers into the AS/400, although it's a little more work. Not much - one very simple solution involves a data queue and the Java Toolbox. And it's far more secure than just allowing someone to pump data onto your machine. > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > Benjamin Franklin I might paraphrase this: those that are willing to give up essential security in order to make their job a little easier deserve neither security nor a job.
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.