HP Archive Backup System for OpenVMS Guide to Operations
HP Archive Backup System for OpenVMS Guide to Operations HP Archive Backup System for OpenVMS Guide to Operations
Security 5.2 Access Control 5.2 Access Control Access control complements the MDMS rights access by granting object-based control over operations. You can assign up to 32 access control entries on any MDMS object, and define the types of access that the user in the entry is granted. There are seven kinds of access that users can be granted as shown in the following table: Table 5–3 Access Control Allowed Operations Allowed Access CONTROL EXECUTE DELETE READ SET SHOW WRITE Explanation The user may modify the object’s access control The user may perform operations on the object The user may delete the object The user may perform restore requests using this object (ABS only) The user may modify the attributes of this object The user may show this object The user may perform save requests using this object (ABS only) You can manipulate access control from MDMSView using the Access tab on an object’s Show screen. From the DCL, you can use the /ACCESS qualifier. In either case, the user name specification should include both node name and user name in the format: node::username From either interface, wildcards are supported in both the node and username portions of the specification. For example: HOUST%::SMITH* allows users whose name begins with SMITH access from HOUST% JUNGLE::* allows all users access from node JUNGLE *::SYSTEM allows all users named SYSTEM from all nodes SYS001::JAMES allows user JAMES from node SYS001 only If an access control entry matches a requesting user, only the access that is granted in the entry is granted to the user. Allowances that are not specifically listed are not granted. Access control checks are optionally performed depending on attributes that you can set in the domain. The following table explains the settings: Table 5–4 Domain Access Control Options Check Access Relaxed Access Explanation Clear Clear No access control checking is done Clear Set No access control checking is done Set Clear Access control is checked; if there are no access control entries, access is denied. 5-4 Security
Table 5–4 Domain Access Control Options Check Access Relaxed Access Explanation Security 5.3 Implementing a Security Strategy Set Set Access control is checked; if there are no access control entries, access is granted. Because of the nature of access control, it is possible to set up access control on an object so that no-one can access the object (even to restore its access control to a usable value). As such, MDMS provides three “escape” mechanisms to allow certain individuals to access the object even if not normally allowed through the access control mechanism: • The owner of an object always has full access to the object. You can disable this feature by clearing the owner field in the object. • Any user that is listed in the access control list of the domain has the same level of access to all objects. • Finally, the user designated by “Last Updated By” in the domain has full access to all objects. This is the user who last modified the domain object, and so is assumed to be a trusted individual with recent access to the object. To help in determining who the authorized domain users are, the SHOW DOMAIN operation does not use access control checking, so that anyone with MDMS_SHOW_ALL rights can show the domain. Note Access control checking is in addition to MDMS rights checking; both must be validated for access to be granted. In addition, if access control checking is disabled in the domain, MDMS rights checking is still performed for all operations. 5.3 Implementing a Security Strategy Before assigning rights and access control entries to specific users you, as the system administrator, should carefully review your MDMS and ABS domain and determine what kind of access to allow your users. The MDMS domain is a key determining factor as to what level of security you should implement. The MDMS includes all locations, nodes, jukeboxes, drives, volumes and other MDMS objects that are served by a single MDMS database. Implicit in this statement are that all users, operators and system managers on nodes in the domain are also part of the MDMS domain and need to be granted appropriate access to the domain resources. Another key issue is what kind of security to the MDMS domain resources, including backup tape volumes, jukeboxes and drives, do you wish to assign to the domain users. Some possible scenarios with suggestions are shown below: • Your domain consists of a single site that is managed by a single organization in a relatively free environment: MDMS high-level rights assigned to specific users are probably all that is necessary here. This is the simplest form of security to maintain. Security 5–5
- Page 51 and 52: Saving and Restoring Data 3.5 Saves
- Page 53 and 54: Table 3-3 Disk, File, Path and Data
- Page 55 and 56: Saving and Restoring Data 3.5 Saves
- Page 57 and 58: Saving and Restoring Data 3.5 Saves
- Page 59 and 60: • First disk/file specification p
- Page 61 and 62: 3.5.17.1 HOLIDAYS.DAT Record Format
- Page 63 and 64: Saving and Restoring Data 3.6 Selec
- Page 65 and 66: 3.7.2 Command 3.7.3 Restriction Sav
- Page 67: 3.7.5 Include and Exclude 3.7.6 Tim
- Page 70 and 71: Media Management 4.2 Domain 4.2.1 A
- Page 72 and 73: Media Management 4.2 Domain 4.2.15
- Page 74 and 75: Media Management 4.3 Drives 4.3.5 D
- Page 76 and 77: Media Management 4.3 Drives 4.3.15
- Page 78 and 79: Media Management 4.5 Jukeboxes 4.5.
- Page 80 and 81: Media Management 4.5 Jukeboxes 4.5.
- Page 82 and 83: Media Management 4.7 Magazines 4.6.
- Page 84 and 85: Media Management 4.8 Media Types 4.
- Page 86 and 87: Media Management 4.11 Volumes 4.10.
- Page 88 and 89: Media Management 4.11 Volumes Table
- Page 90 and 91: Media Management 4.11 Volumes 4.11.
- Page 92 and 93: Media Management 4.11 Volumes neede
- Page 94 and 95: Media Management 4.11 Volumes • R
- Page 96 and 97: Media Management 4.11 Volumes 4.11.
- Page 99 and 100: 5 Security The security model used
- Page 101: Security 5.1 MDMS Rights Table 5-1
- Page 105 and 106: 6 User Interfaces ABS and MDMS supp
- Page 107 and 108: 6.1.3 Logging In User Interfaces 6.
- Page 109 and 110: User Interfaces 6.1 Graphical User
- Page 111 and 112: User Interfaces 6.1 Graphical User
- Page 113 and 114: Figure 6-5 Domain View Showing Expa
- Page 115 and 116: User Interfaces 6.1 Graphical User
- Page 117 and 118: 6.1.13 Viewing MDMS Audit and Event
- Page 119 and 120: 6.2.1 Syntax Overview User Interfac
- Page 121 and 122: User Interfaces 6.3 User Interface
- Page 123 and 124: 7 Preparing For Disaster Recovery I
- Page 125 and 126: 7.1.2 Backup of MDMS$ROOT Preparing
- Page 127 and 128: 7.2 Prolog and Epilog Procedure Pre
- Page 129 and 130: 7.2.1 Restoring The System Disk To
- Page 131 and 132: 8 Remote Devices 8.1 RDF Installati
- Page 133 and 134: Remote Devices 8.4 Monitoring and T
- Page 135 and 136: 8.4.4 Changing Network Parameters f
- Page 137 and 138: • Free Space is 20 Remote Devices
- Page 139 and 140: Remote Devices 8.5 Controlling Acce
- Page 141: Remote Devices 8.7 RDF Error Messag
- Page 144 and 145: System Backup to Tape for Oracle Da
- Page 146 and 147: System Backup to Tape for Oracle Da
- Page 148 and 149: System Backup to Tape for Oracle Da
- Page 150 and 151: System Backup to Tape for Oracle Da
Table 5–4 Domain Access Control Options<br />
Check Access Relaxed Access Explanation<br />
Security<br />
5.3 Implementing a Security Strategy<br />
Set Set Access control is checked; if there<br />
are no access control entries, access<br />
is granted.<br />
Because of the nature of access control, it is possible <strong>to</strong> set up access control on an object so that<br />
no-one can access the object (even <strong>to</strong> res<strong>to</strong>re its access control <strong>to</strong> a usable value). As such,<br />
MDMS provides three “escape” mechanisms <strong>to</strong> allow certain individuals <strong>to</strong> access the object<br />
even if not normally allowed through the access control mechanism:<br />
• The owner of an object always has full access <strong>to</strong> the object. You can disable this feature by<br />
clearing the owner field in the object.<br />
• Any user that is listed in the access control list of the domain has the same level of access <strong>to</strong><br />
all objects.<br />
• Finally, the user designated by “Last Updated By” in the domain has full access <strong>to</strong> all<br />
objects. This is the user who last modified the domain object, and so is assumed <strong>to</strong> be a<br />
trusted individual with recent access <strong>to</strong> the object.<br />
To help in determining who the authorized domain users are, the SHOW DOMAIN operation<br />
does not use access control checking, so that anyone with MDMS_SHOW_ALL rights can show<br />
the domain.<br />
Note<br />
Access control checking is in addition <strong>to</strong> MDMS rights checking; both must be validated<br />
<strong>for</strong> access <strong>to</strong> be granted. In addition, if access control checking is disabled in the<br />
domain, MDMS rights checking is still per<strong>for</strong>med <strong>for</strong> all operations.<br />
5.3 Implementing a Security Strategy<br />
Be<strong>for</strong>e assigning rights and access control entries <strong>to</strong> specific users you, as the system administra<strong>to</strong>r,<br />
should carefully review your MDMS and ABS domain and determine what kind of access <strong>to</strong><br />
allow your users.<br />
The MDMS domain is a key determining fac<strong>to</strong>r as <strong>to</strong> what level of security you should implement.<br />
The MDMS includes all locations, nodes, jukeboxes, drives, volumes and other MDMS<br />
objects that are served by a single MDMS database. Implicit in this statement are that all users,<br />
opera<strong>to</strong>rs and system managers on nodes in the domain are also part of the MDMS domain and<br />
need <strong>to</strong> be granted appropriate access <strong>to</strong> the domain resources.<br />
Another key issue is what kind of security <strong>to</strong> the MDMS domain resources, including backup<br />
tape volumes, jukeboxes and drives, do you wish <strong>to</strong> assign <strong>to</strong> the domain users. Some possible<br />
scenarios with suggestions are shown below:<br />
• Your domain consists of a single site that is managed by a single organization in a relatively<br />
free environment: MDMS high-level rights assigned <strong>to</strong> specific users are probably all that is<br />
necessary here. This is the simplest <strong>for</strong>m of security <strong>to</strong> maintain.<br />
Security 5–5