Security vs. Performance. Make sure you understand the trade-offs involved.
Brief: The built-in security features of OS/400 are one of its great strengths. By understanding how security is implemented, you can reap performance benefits without sacrificing any control. In this article, one of the architects of AS/400 security examines how OS/400 security checks impact performance. He sums up with recommendations that can help you design applications with optimum security and optimum performance.
System performance on the AS/400 can change significantly, based upon the method used to secure objects. A clear understanding of the security checks that take place when you run a program or access a file helps you design applications that improve performance without jeopardizing security. Although you cannot control when the system validates security, the security you implement directly affects the overhead for each security check. Therefore, some security features should be used with caution since they have a negative impact on performance.
You may find that the factors discussed in this article only affect a small percentage of your applications, or you may find that other design considerations override the performance considerations presented here. However, in many cases by using this article as a guideline, you'll be able to design applications that maximize performance without sacrificing control. The "Security Internals" sidebar provides some background about AS/400 security design and the processing that takes place on each object reference. (For background on the terminology and concepts discussed, consult the Basic Security Reference.)
How It Works
Each time an application references an object, the system validates the user's access to the object. Whenever a user calls a program, opens a file or runs a command, the machine instruction includes an access check to determine whether to allow or deny access to the object. At security levels below 30, access checks do not significantly impact performance since every user has *ALLOBJ authority. At security levels 30 and above if the user is authorized to the object, the instruction continues; otherwise, the system signals a not- authorized exception.
An access check requires zero, one or more authority searches (inquiries to user profile objects). An authority search tests whether or not a specific user profile (or *PUBLIC authority) has sufficient authority to access the object. Access is based on a user profile, a group profile, *PUBLIC authority or an adopted profile. In some cases, the authority search quickly locates all the information it needs either in the object or in the user profile information stored with the job. In other instances, the authority search may include zero, one or two authority lookups. An authority lookup retrieves specific authority, or authority based on an authorization list from a user profile. An authority lookup requires more CPU resources than an authority search which is resolved without an authority lookup. Therefore, our goal will be to design security implementations that avoid authority lookups whenever possible.
The same object security can be implemented in different ways. By choosing the correct implementation, you can optimize your performance without sacrificing any security. You cannot control the number of times that the AS/400 checks access, but you can select a security implementation that minimizes the authority lookups for each access check.
1 shows the access checks for a CL program that updates an invoice number stored in a data area. Each time this CL program runs, the system makes seven access checks. (The access checks and the object being checked are shown to the right of the program.) The system performs more checks than you may have anticipated for such a simple program. It's easy to see that a typical application can cause a significant number of access checks to occur.
Figure 1 shows the access checks for a CL program that updates an invoice number stored in a data area. Each time this CL program runs, the system makes seven access checks. (The access checks and the object being checked are shown to the right of the program.) The system performs more checks than you may have anticipated for such a simple program. It's easy to see that a typical application can cause a significant number of access checks to occur.
Object Structure
To minimize authority lookup operations, you'll need to understand how the system stores security information about objects. 2 illustrates the composition of an AS/400 object. Each object includes an object header and a functional part that varies depending on the object type. For example, the functional part of a program object contains instructions, and the functional part of a physical file object contains data records.
To minimize authority lookup operations, you'll need to understand how the system stores security information about objects. Figure 2 illustrates the composition of an AS/400 object. Each object includes an object header and a functional part that varies depending on the object type. For example, the functional part of a program object contains instructions, and the functional part of a physical file object contains data records.
The structure of the object header is the same for all objects. The object header contains the object type, name and related information (these appear in the figure as nonsecurity information) and six elements of security-related data.
Public authority stores a bit-encoded representation of *PUBLIC authority for the object.
Owner's authority stores a bit-encoded representation of authority for the owner of the object.
No private authority indicates that the only authorizations to the object are *PUBLIC and the owner's authority. No user has specific authority to the object.
No private authority less than *PUBLIC is a performance flag that remains activated unless a user has less authority than the *PUBLIC authority. (Users may have private authorities that are greater than the *PUBLIC authority.) If *PUBLIC authority (stored in the header) is adequate for the access requested, the system has no need to search individual user profiles. Thus, you can optimize performance by trying to ensure that the no private authority less than *PUBLIC flag remains activated.
The owner's user profile pointer contains the address of the individual or group profile that owns the object. It is used to determine if the user profile being checked is the owner of the object.
The authorization list pointer contains the address of the authorization list that secures the object, if applicable.
Authority Search Order
The security design goal is to balance efficient and effective control of access to system resources. An efficient security option would entail assigning the *PUBLIC authority of *ALL for every object or giving all users *ALLOBJ access. But this design would not be effective. The simplest way to improve security performance is to reduce the number of authority lookups before authority is granted or denied. You can eliminate some of the authority lookup steps by taking advantage of information stored in the object header.
The authority to objects can come from *PUBLIC authority, owner's authority, private authority, group profiles, authorization lists, *ALLOBJ special authority, programs that adopt their owner's authority and authority holders. The order of the search is quite complex. 3 illustrates the hierarchy of authority searches. An authority search on a user profile (or group profile) requires zero, one or two authority lookup operations. Perfor-mance is improved when the number of lookup operations is minimized. (The Security Reference Manual gives the detailed search order and the impact on performance.)
The authority to objects can come from *PUBLIC authority, owner's authority, private authority, group profiles, authorization lists, *ALLOBJ special authority, programs that adopt their owner's authority and authority holders. The order of the search is quite complex. Figure 3 illustrates the hierarchy of authority searches. An authority search on a user profile (or group profile) requires zero, one or two authority lookup operations. Perfor-mance is improved when the number of lookup operations is minimized. (The Security Reference Manual gives the detailed search order and the impact on performance.)
Design Recommendations
Plan your security design so that the majority of access checks are completed with information stored in the object header.
When access can't be determined from the object header, the search becomes more complex. The amount of CPU resources used in an authority lookup to a user profile is many times greater than for the object header. The recommendations I've collected here will help you to achieve your performance goals. In many cases, you can reduce the overhead required for access checks without any impact on either control or security maintenance issues.
Recommendation 1: Use public authority for objects that do not need protection.
Authority to objects is similar to the door locks used to limit access to rooms. Just as you do not put locks on every door in your home, you should not secure every object in the system. If you had to lock and unlock a door every time you moved between rooms, it would be a waste of time. To minimize this overhead, try to make *PUBLIC authority adequate for most operations. Avoid granting users specific authority when *PUBLIC authority will suffice. This simplifies security management and reduces the time required to save user profiles because there are fewer authority entries.
Recommendation 2: Avoid giving users less authority than *public authority.
Giving any user less authority than *PUBLIC causes the system to perform an authority search for every user. Giving a user less authority than *PUBLIC is like placing a guard at a door to prevent one particular person from entering. Every person who approaches the door must produce identification, but all except one can enter. This delays the process for everyone and constitutes an inefficient use of resources.
The object header flag no private authority less than *PUBLIC eliminates the need to search individual user profiles when *PUBLIC authority is adequate for the operation. If a single user has less authority than *PUBLIC access, the flag is turned off, resulting in an authority search for every user that references the object.
In terms of performance, it is better to reduce *PUBLIC authority to the lowest access and give many users private authority than to give any user less authority than *PUBLIC. Performance improves because the system searches user profiles only when the operation requested requires more authority than *PUBLIC.
Recommendation 3: Use private authorities-not authorization lists-to grant users more access than *public.
You can grant users (including group profiles) more access than *PUBLIC through explicit private authority or the use of an authorization list. When every user with private authority has authority that equals or exceeds the *PUBLIC authority, specific authorities should be used rather than an authorization list.
This relates to the performance advantage of my first recommendation. If an authorization list is used, the performance advantage of the no private authority less than *PUBLIC flag is lost because the authorization list will be checked regardless of the status of this flag. Therefore, when granting access greater than *PUBLIC, specific authorities by user profile are usually a better choice than using an authorization list.
This does not mean that you should avoid use of authorization lists completely. Several considerations apply, including the type of object, granting authority less than *PUBLIC, and maintenance versus performance considerations. You should simply be aware that using an authorization list to give users more authority than *PUBLIC causes additional authorization lookups.
For example, using an authorization list to secure files is extremely useful and may be worth the performance overhead. Access to a file is checked once at the time the file is opened and not with every read or write operation. One additional authority lookup operation at file-open time is minimal compared to the advantages of using an authorization list.
Recommendation 4: Use authorization lists or private authority to secure objects. Do not use both methods.
Authorization lists are useful to simplify security management and allow security changes while files are open. However, checking an authorization list creates additional overhead-as if the guard at the door had to check both an employee badge (private authority) and a checklist of people signed up for a special event. The no private access flag can speed up this process. It tells the guard that he does not need to check employee badges-everyone who may enter is included on his checklist.
Recommendation 5: Group objects into libraries and restrict access to the libraries. Assign *public authority for objects within the library.
Accessing an object requires authority to both the library and the object in the library. Users must have at least *USE authority to a library to access the objects within the library. If you limit access to the library, then the individual objects in the library can have *PUBLIC authority.
This technique of securing the library and using public authority for the objects in the library is referred to as library security. Returning to our analogy, library security is like positioning one guard at the entrance to the house so you can do away with other guards positioned at the entrance to each room.
Library security has three advantages. First, it is an effective method to restrict access to selected users. Second, giving objects in the library *PUBLIC authority improves performance by limiting authority lookup operations to the library. Finally, restricting the library (rather than each of the objects within it) simplifies your security management task.
4 shows the number of access checks categorized by the library and object for a CL program. Fifty percent of the access checks are for objects. You can significantly reduce the number of authority lookup operations by assigning *PUBLIC authority to the object.
Figure 4 shows the number of access checks categorized by the library and object for a CL program. Fifty percent of the access checks are for objects. You can significantly reduce the number of authority lookup operations by assigning *PUBLIC authority to the object.
Recommendation 6: Use *LIBL rather than the specific library name.
When a library is placed on the library list (*LIBL), the system checks the user's access to the library and stores the result in a pointer on the library list. Storing authority in the pointer eliminates the authority lookup operations on each library reference. It may seem that using a specific library name would be faster than using the library list, but this is not usually the case. When a fully qualified name (LIB/OBJ) is used, the system first must resolve the library name into a system pointer and then validate the user's access to the library. When the library list (*LIBL) is used, the system checks the previously resolved authorized pointers.
This recommendation is easy to implement because most CL commands default to use *LIBL to access objects. This default has the performance advantage of only checking a user's access once, when adding the library to the library list. Implement-ing the *LIBL and library security (Recommendation 5) can dramatically reduce the number of authority lookup operations and still provide adequate security.
As with my authorization list recommendations, you'll witness some trade-offs. The system performs better when the library list is kept as short as possible. You can achieve a minor performance gain by placing the library containing frequently used objects near the top of the library list.
The use of a qualified name is advantageous in any of the following situations:
When the object you are using is not in the library list for the job.
When there is more than one object of the same name in the library list and you want one in a specific library.
When you want to ensure that a specific library is used for security reasons.
Recommendation 7: Group profiles should own objects.
Often, several users in the same group profile share access to an object. Because the object header contains the owner's authority when the group profile owns the object, members of the group do not require lookup operations when searching for specific authority for the group profile. (There may be authority lookup operations for specific authority for the individual user profile.) This is particularly true for objects with *PUBLIC authority of *EXCLUDE.
This recommendation also applies to programs that adopt authority. Performance improves when the same user profile owns both the adopting program and the objects referenced by the program. This takes advantage of the object owner's authority stored in the object header.
Technical Summary
5 (page 28) illustrates the advantages of these recommendations. The figure shows various types of security implementations for the same object, and the maximum number of authority lookup operations conducted before determining that the user is not authorized to the object. (The number of lookup operations may be less if the user has authorization to the object.)
Figure 5 (page 28) illustrates the advantages of these recommendations. The figure shows various types of security implementations for the same object, and the maximum number of authority lookup operations conducted before determining that the user is not authorized to the object. (The number of lookup operations may be less if the user has authorization to the object.)
The last column of the table shows the order of the required authority lookup operations using the following sequence. The system searches in the order shown below, although it skips some of these steps depending on how the object is secured.
1. Private access to the object from the user profile. 2. Authorization list access from the user profile. 3. Private access to the object from the group profile. 4. Authorization list access from the group profile.
If you study the table, you will note that group profiles have the potential for doubling the authority lookup operations. One might incorrectly conclude that group profiles should not be used. However, in general, the benefit of group profiles overrides any potential impact on performance. Recommendation 7 eliminates the need to do an authority lookup if the group is the owner of the object.
This article has focused on how security impacts performance. Though many nonsecurity-related factors can combine to cause poor performance, 5 certainly shows how adhering to a few recommendations can reduce performance hits resulting from less-than-optimal security implementations.
This article has focused on how security impacts performance. Though many nonsecurity-related factors can combine to cause poor performance, Figure 5 certainly shows how adhering to a few recommendations can reduce performance hits resulting from less-than-optimal security implementations.
Wayne O. Evans is an AS/400 security consultant and a frequent speaker on security topics. During his 27 years with IBM Corporation, he was involved with AS/400 security design issues. Direct your security-related questions to Wayne via fax at (507) 252-9615.
REFERENCES Basic Security Guide (CD-ROM QBKA9K00 SC41-0047). Work Management Guide (CD-ROM QBKA9J01 SC41-8078-01). Performance Tools/400 Guide (CD-ROM QBKA9F01 SC41-8084-01, Program Number 5738- PT1). Security Reference Guide (CD-ROM QBKA9H01 SC41-8083-01).
SIDEBAR: Security Internals
This overview of the AS/400 authority-checking internals gives you the background needed to understand the performance impact of different methods used to secure objects.
The hallmark of the AS/400 is the simplified system operation resulting from the integration of function by the machine and operating system. A1 contrasts the traditional system with the AS/400. The traditional system often has separately installed products for communications, security and database. The AS/400 integrates all of these features into OS/400.
The hallmark of the AS/400 is the simplified system operation resulting from the integration of function by the machine and operating system. Figure A1 contrasts the traditional system with the AS/400. The traditional system often has separately installed products for communications, security and database. The AS/400 integrates all of these features into OS/400.
Determining access to an "object" in a traditional system may require a call to a separate security product. The security product performs the access control checks and returns a go or no-go indication to the operating system. The operating system proceeds with the operation or issues an appropriate message.
The AS/400 access control checks are built into the machine instructions. Each time an AS/400 program runs any instruction that uses a system pointer to reference data, the machine performs an access control check automatically. Examples of instructions that reference data using system pointers include running a CL command, calling a program, opening a file and sending a message stored in a message file.
If the user is authorized to the object, the instruction continues. If the user is not authorized, the instruction does not continue. The machine signals a not-authorized exception. The highly integrated nature of AS/400 security makes it difficult to circumvent, even when writing programs that have access to system pointers such as MI or C programs. On a traditional system, a programmer has the potential of altering the operating system to bypass security. However, the AS/400 performs an access check on each instruction that uses a system pointer.
Different products may have their own access control recommendations and enrollment. The AS/400 operating system, database and communications functions all use the same access check rules and security enrollment.
Sometimes, the operating system stores the user's authority on first reference to an object. This eliminates the authority search on subsequent references to the same object. The system checks the user's access when a program opens a database file and stores an authorized pointer. Subsequent read and write operations to the open file do not require searching for authority.
Unlike file open, most CL commands are not able to retain the authorized pointer after the command has completed. As a result, the machine repeats access checks for each command issued. This may cause several access checks for a single CL command.
Security Design for Performance
Figure 1 Access Check Example
UNABLE TO REPRODUCE GRAPHIC
Security Design for Performance
Figure 2 Object Structure
UNABLE TO REPRODUCE GRAPHIC
Security Design for Performance
Figure 3 Sequence of Access Checks
1. Fast check for *PUBLIC access. The user is authorized to the object if all of the following conditions are met: The *PUBLIC authority is adequate for the operation There is no authorization list attached to the object. The performance flag, no private authority less the *PUBLIC, is on. Zero authority lookups. 2. Check user profile. If the user profile has *ALLOBJ special authority the user is authorized to the object. Zero authority lookups. If the user profile owns the object the access check is resolved. (the user is authorized to the object unless the owner's authority has been revoked.) Zero authority lookups. If the no private authority flag is on bypass specific authority check (continue with authorization list). If the user profile has specific authority to the object the access check is resolved (the user may or may not be authorized). Authority lookup required. If the user profile appears on the authorization list of the object the access check is resolved (the user may or may not be authorized). Authority lookup required. 3. Check group profile. If the group profile has *ALLOBJ special authority the user is authorized to the object. Zero authority lookups. If the group profile owns the object the access check is resolved. (the user is authorized to the object unless the owner's authority has been revoked.) Zero authority lookups. If the no private authority flag is on bypass specific authority check (continue with authorization list). If the group profile has specific authority to the object the access check is resolved (the user may or may not be authorized). Authority lookup required. If the group profile appears on the authorization list of the object the access check is resolved (the user may or may not be authorized). Authority lookup required. 4. Check *PUBLIC authority. If *PUBLIC authority is sufficient for the operation the user is authorized to the object. If *PUBLIC appears on the authorization list for the object the access check is resolved (the user may or may not be authorized). Authority lookup required. 5. Check adopted authority. If the program owner's user profile has *ALLOBJ special authority the user is authorized to the object. Zero authority lookups. If the no private authority flag is on bypass specific authority check (continue with authorization list). If the program owner's user profile has specific authority to the object the access check is resolved (the user may or may not be authorized). Authority lookup required. If the program owner's user profile appears on the authorization list of the object the access check is resolved (the user may or may not be authorized). Authority lookup required.
Security Design for Performance
Figure 4 Access Checks by Library and Object
UNABLE TO REPRODUCE GRAPHIC
Security Design for Performance
Figure 5 Authority Lookup Summary
UNABLE TO REPRODUCE CHART
Security Design for Performance
Figure A1 Contrast of Traditional and AS/400 Architecture
TRADITIONAL SYSTEMS AS/400 User Application Programs User Application Programs Compilers Compilers Compilers OS/400 Security Security Products Communications Database Communictions Communications Machine Instruction Boundary Database Machine Interface Operating System Access Control Machine Instruction Boundary Communication Data access Hardware Hardware *Limited integration; often *Function integrated into the multiple products OS/400 *Operating system calls security *Machine instructions perform product for access checks access checks *Access checked once per user *Access may be checked multiple request times in a single user request /ef
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