Securing Individual Database Fields
The AS/400 database does not directly support field-level security for a file; that is, there's no direct way to protect an individual field from unauthorized access while leaving all others unprotected. At most, you can give users *READ authority (to read records), *ADD (to add records), *UPD (to update records) or *DLT (to delete records), but this is a blanket authority that covers the entire record-not a specific field.
However, there's a circumvention to protect a particular field in a physical file: create a logical file that contains a subset of the fields in the physical file. For example, picture an Employee Master file. You want anyone to be able to read the nonsensitive part of the record, such as employee number, name, and the department number. You don't want anyone outside of Human Resources to be able to read the rest of the fields, such as hourly pay rate and deductions. 1 shows the physical file and 2 the logical file. The logical file only "sees" the employee number, name and department number-but not the rest of the information, which is confidential.
However, there's a circumvention to protect a particular field in a physical file: create a logical file that contains a subset of the fields in the physical file. For example, picture an Employee Master file. You want anyone to be able to read the nonsensitive part of the record, such as employee number, name, and the department number. You don't want anyone outside of Human Resources to be able to read the rest of the fields, such as hourly pay rate and deductions. Figure 1 shows the physical file and Figure 2 the logical file. The logical file only "sees" the employee number, name and department number-but not the rest of the information, which is confidential.
Now consider which users would be given access to the limited information. Give them all *OBJOPR authority to the logical file. This gives the users the authority to open the logical file and use the data authorities of the physical file on which the logical is based (the Employee Master).
Then give the users the desired data rights to the physical file. If you only want them capable of reading the data, give them *READ authority to the physical file. Don't give them *OBJOPR authority to the physical file, though. Because they don't have *OBJOPR authority, they cannot open the physical file itself, thus protecting the confidential fields.
You can use the same technique to allow some users to change certain fields but not others. Again, create a logical file with *OBJOPR authority to the users, and give *CHANGE authority (but not *OBJOPR) to the physical file.
TechTalk: Securing Individual Database Fields
Figure 1 Employee Master Physical File
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A R EMREC A EMEMPL 5P 0 TEXT('Employee number') A EMNAME 30A TEXT('Employee name') A EMADR1 30A TEXT('Address line 1') A EMADR2 30A TEXT('Address line 2') A EMCITY 25A TEXT('City') A EMSTAT 2A TEXT('State') A EMZIP 9P 0 TEXT('Zip code') A EMDEPT 4P 0 TEXT('Department number') A EMHIRE 8P 0 TEXT('Hire date, YYYYMMDD') A EMHPAY 5P 2 TEXT('Hourly pay rate') A K EMEMPL ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
TechTalk: Securing Individual Database Fields
Figure 2 Employee Master Logical File for Restricted Access
... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 A R EMREC PFILE(EMPMST) A EMEMPL A EMNAME A EMDEPT A K EMEMPL ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online