Métodos o modelos de enseñanza aprendizaje

You’ve seen several ways to give users access to resources that are based solely on the identity of the person accessing the resource. Consider the access list entry: If you are on the access list with the correct level of authority or in a group that is on the access list with the correct level of author- ity, you are allowed access to the data.

You can also control access to data based on the characteristics of the data and the user by assigning a security level and one or more categories to the user and the data.

Warning

Security labels and categories can be useful in controlling access to data. However, they are discretionaryaccess controls, in the sense that once the data is accessible by the user, the user can reclassify the data, potentially to alower (or no) sensitivity level or a different set of categories—possibly the empty set.

3.3.1 Defining the Policy

To activate security data checking, run this command: SETR CLASSACT(SECDATA)

3.3.1.1 Security Levels

A security level is a hierarchical classification of the sensitivity level of a resource. For example, if you have a data set that anyone is allowed to access, you might assign that data set the security level of PUBLIC. A data set that is allowed only to employees could be assigned the security level ofEMPONLY. Confidential information could be assigned the security level of CORPCONF. These levels are hierarchical, in the sense that CORPCONFis more sensitive than EMPONLY, which is, in turn, more sensitive than PUBLIC.

RACF implements security levels by allowing you to define labels such as PUBLIC, EMPONLY, and CORPCONF, and assigning them a numeric value between 1and255, which repre- sents the level of sensitivity.

All of an installation’s security levels are defined in the SECLEVELprofile in the RACF SECDATAgeneral resource class. The z/OS security administrator defines these profiles using the RDEFINEcommand.

This command creates the security levels profile: RDEFINE SECDATA SECLEVEL

This command adds security levels. It implements the three security levels explained previously:

RALTER SECDATA SECLEVEL ADDMEM(PUBLIC/10 EMPONLY/50 CORPCONF/100)

This is the command to use to list the security levels: RLIST SECDATA SECLEVEL

3.3.1.2 Categories

You can also assign one or more categories to a resource. A category is a description of the infor- mation contained in the resource. For example, FINANCIAL,DESIGN, and TEST could all be categories. With categories, no hierarchical relationship exists: The operating system can’t tell from the category name which category is more sensitive.

All of an installation’s categories are defined in the CATEGORY profile in the RACF SECDATAgeneral resource class. The z/OS security administrator defines these profiles using the RDEFINEcommand, as shown here.

This command creates the new categories profile: RDEFINE SECDATA CATEGORY UACC(NONE)

This command adds categories:

RALTER SECDATA CATEGORY ADDMEM(FINANCIAL DESIGN TEST) This is the command to use to list the categories:

RLIST SECDATA CATEGORY

3.3.2 Assigning Security Levels and Categories

Just defining the security levels and categories does nothing to change who is allowed access to what resources. You must assign levels or categories to users and resources. After that, access to the resource is allowed only under these conditions:

1. The user has been assigned a security level that is not lower than the security level of the sources.

2. The user has been assigned all the categories that are assigned to the resource.

Security levels are assigned to users using either the RACF panels or the RACF commands. For example, this RACF ALTUSERcommand can be used to assign the security label EMPONLY and the categories DESIGNandTESTto the user ID MYUSER:

ALTUSER MYUSER SECLEVEL(EMPONLY) ADDCATEGORY(DESIGN TEST)

You can also assign categories and levels to data sets using either the RACF panels or the RACF commands. This is the RACF ALTDSDcommand to add the security level CORPCONFand the category TESTto the data set RACFBK.CNTL:

ALTDSD RACFBK.CNTL SECLEVEL(CORPCONF) ADDCATEGORY(TEST) Now add MYUSER to the ACL for RACFBK.CNTL:

PERMIT RACFBK.CNTL ACCESS(READ) ID(MYUSER)

MYUSER should not have access to RACFBK.CNTL, despite the ACL, because of the secu- rity level. Log on as MYUSER and try to edit <your user name>.RACFBK.CNTL(HELLOW). You will get the error shown in Figure 3.31.

Figure 3.31 Accessdeniedbecause of security level

To allow access, run this command to modify MYUSER’s security level: ALTUSER MYUSER SECLEVEL(CORPCONF)

Log off as MYUSER and log back on. Now MYUSER should be able to read the data set member in the editor.

Note

The security level of a user is cached during a TSO session. Therefore, it is necessary to log MYUSER off and then back on before the new security level takes effect.

3.3.3 Security Labels (SECLABELs)

Security labels (SECLABELs) are a means of aggregating security levels and categories into a single entity that can be assigned to users and resources. Using SECLABELs allows an installa- tion to protect against the data owner or the user of the data using their discretionary access con- trol (DAC) authority to change the classification or categorization of data. By controlling these discretionary powers, you can move your installation into a mandatory access control (MAC) environment. Moving into MAC allows the safe concurrent processing of multiple levels of secu- rity within the same computing environment. This is called Multilevel Security (MLS). This enables an organization to set rules on data access that the data and application administrators cannot override. The authority to modify those data access rules can be limited to a small number of trusted security administrators.

Although MAC environments are often thought of as being of interest only to three-letter government agencies, there is significant commercial benefit to a MAC environment. For example, if a company wants to isolate information from different divisions or has information that must not be divulged across some IT boundary, an MLS environment could be an excellent solution.

To activate security labels, run these commands: SETR CLASSACT(SECLABEL)

SETR RACLIST(SECLABEL)

SECLABELs are profiles within the RACF SECLABEL general resource class. SECLA- BELs can be defined with the RDEFINE RACFcommand. For example, this command defines a SECLABEL called FINCONF:

RDEFINE SECLABEL FINCONF SECLEVEL(CORPCONF) ADDCATEGORY(FINANCIAL) UACC(NONE)

After the SECLABEL is defined, you assign it to resources using either the RACF panels or the RACF commands. For example, to assign the FINCONF SECLABEL to <username>. RACFBK.CNTL, use this ALTDSDcommand:

ALTDSD RACFBK.CNTL SECLABEL(FINCONF)

This command classifies RACFBK.CNTL as having “FINCONF” data. After you run it, MYUSER would fail to access <username>.RACFBK.CNTLand would see the error message shown in Figure 3.32.

3.3 Security Data (Levels, Categories, and Labels) 67

Figure 3.32 Accessdeniedbecause of security label

To grant MYUSER the right to access resources that have the FINCONFSECLABEL, mod- ify the ACL to give it read access to the SECLABEL. These commands specify that MYUSER is allowed to access FINCONFclassified information.

PERMIT FINCONF CLASS(SECLABEL) ID(MYUSER) ACCESS(READ) SETROPTS REFRESH RACLIST(SECLABEL)

When users start their work, they need to identify what SECLABEL is to be used. For TSO users, this is done on the TSO LOGON panel, as shown in Figure 3.33. For batch jobs, this is done using the SECLABELJCL keyword. Other environments have their own ways of specifying what SECLABEL is to be assigned to the work.

Figure 3.33 TSO logonwith SECLABEL