|
midrange.com
NOW your getting the idea.
(Tongue now firmly out of cheek)
I never said that this procedure was easy.
>>> <rob@dekko.com> 07/27/01 02:45PM >>>
Oh, I agree with you, that the data should be secured, with each partition
of data secured to the correct parties. Many applications will have to be
redesigned, however. Take payroll maintenance for example. If you wanted
data security set up so that it was valid in 5250, odbc and what not, you
would have many 5250 programs to access the data.
I) Pre 5250 alternatives strategy
Have one monolithic employee master file. Use Protect field and Non
display on data the individual was not allowed to. Write separate program
which kept track of who gets what indicators set on.
II) Pre V5 sample
A) Have one monolithic employee master file with logical files. No one
has access to the master file, except via logical files. The logical files
would only include fields that targeted individuals were allowed access to.
Open up the security on the logical files to correct parties only.
B) Break up the employee master file into various other files: Address,
Rate, etc. (I've seen this in some packages). Open up the security on the
files to correct parties only.
Break up employee maintenance program so that various options maintain
certain logical files or broke apart files.
Change menu system to check if user has access to major file(s) used by
that option prior to displaying that option.
III) V5 sample
A) Have one monolithic employee master file with logical files. No one
has access to the master file, except via logical files. The logical files
would only include fields that targeted individuals were allowed access to.
Open up the security on the logical files to correct parties only.
B) Break up the employee master file into various other files: Address,
Rate, etc. Open up the security on the files to correct parties only.
C) Or use field level security.
Change menu system to check if user has access to major file(s) used by
that option prior to displaying that option.
Unless you really redesign your software you have to be careful.
What happens if you chain to a record in a file, and the user is secured
out of one field?
This may be one good reason to use SQL instead of native file access. Read
only the fields required for that application.
What happens if I insert a new record? What will it set the values to for
fields that I do not have access to?
How many authorization lists would you have on a system with the following
configuration:
Supporting 20 separate divisions ERP. Each division has the following
modules: OE, purchasing and 10 others. A payroll system for everyone. An
accounting package for 20 divisions with it's own modules. And 1,663 user
profiles loaded on the system?
When you start looking at the workload that the security person would have
here, then you might discover why someone may lock all users out except for
program adopted authority. And if a certain users needs access, with CA or
odbc or whatever, then add that individual to the file.
Rob Berendt
==================
A smart person learns from their mistakes,
but a wise person learns from OTHER peoples mistakes.
"alan shore"
<SHOREA@dime.com> To: <RPG400-L@midrange.com>
Sent by: cc:
owner-rpg400-l@mi Subject: RE: Programing
Question/Authority...
drange.com
07/27/2001 11:18
AM
Please respond to
RPG400-L
PLEASE NOTE : No sarcasm is intended, however, I know that sarcasm WILL be
projected from my response to this.
Lets take this from the sublime to the WAY ridiculous.
Somebody requires access to High level Top secret documents, but to obtain
this data "they then have to jump through all sorts of hoops."
So lets make it easier to obtain this data. Oh, did'nt they do that at some
military installation in California just recently.
Sarcasm switch now turned off.
Implementing a security procedure is NOT easy, and it is (or should be)
ALWAYS revised. If it is hard for a person to be able to obtain data, then
surely the security is working.
Letting an application handle the security (even if users only see the
options they need to see) is NOT (this is strictly my opinion) the
procedure to use. If fred Bloggs should never have access to the payroll
master file, then the security should be in place that he is NOT allowed
access, even through the application, thet he may or may not have. If he
should have access to the payroll master file, give him direct access. If
not, he falls into the category of PUBLIC *EXCLUDE.
>>> <rob@dekko.com> 07/27/01 11:10AM >>>
But, Alan, most of the geezers are very comfortable with 5250 menu
security. They've created fancy menus that are customized to the user.
Certain users only have certain options. People who should not withdraw
funds cannot. This technique used to be valid until the arrival of the
S/36 and the S/38. When these machines came along alternative methods of
access came into being, one of the early ones being Client Access. Now
that we have Client Access, ftp, odbc, etc., then the recommended way of
securing things so that your menu system has any validity at all is to
allow no access to data except via adopted programs.
The other alternative is to either purchase a package to handle all exit
point programs, or write your own. Of course, with IBM adding new exit
points with every release, we went with the package option.
Of course, when one DOES want to access a file with Client Access, or
whatnot, and has a valid business reason for doing so, they then have to
jump through all sorts of hoops.
Rob Berendt
==================
A smart person learns from their mistakes,
but a wise person learns from OTHER peoples mistakes.
"alan shore"
<SHOREA@dime.com> To:
<RPG400-L@midrange.com>
Sent by: cc:
owner-rpg400-l@mi Subject: RE: Programing
Question/Authority...
drange.com
07/27/2001 08:38
AM
Please respond to
RPG400-L
I have been VERY cautious in taking this approach, as this means that
ANYBODY that can sign onto the system can really play havoc with the system
JUST by using the application.
Fred Blogs has a valid profile/password to sign onto the system, and even
with NO command line can apply payments, withdraw funds, place orders etc.
just by following the menu options, because there is NO security to stop
him due to the application giving him the authority because he is signed
on.
Whereas, if authorization per Group profile or user profile was applied to
the files within the production libraries, the security would stop him
because he is NOT authorized to update a particular master file. He is only
allowed to read the master file.
Using adopted owner authority should be used ONLY where needed, NOT across
the gamut of the application.
But then thats just my opinion, for what its worth.
>>> "Njal Fisketjon" <n.f@figu.no> 07/26/01 08:43PM >>>
I am a bit surprised to see all the postings regarding USRPRF(*OWNER)
I always thought this was the recommended way of handling db security:
- use public *Exclude on all libraries
- let each application (all programs and files) be owned by an owner
profile with pwd *none
- use USRPRF(*OWNER) on all application programs
Something important must have slipped by me if this is no longer a
recommended approach.
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
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.
