Security, authentication, and authorization
This domain tests who can connect, how they prove identity, and what they may do. Client nodes authenticate with node passwords; administrators authenticate with admin IDs. Authorization is separate from authentication.
Core rules
Spectrum Protect administrative authority classes include System, Policy, Storage, Operator, and Analyst. Grant the least authority that supports the job. System authority is very broad and should be limited. Node passwords should be changed or reset through supported administrative commands when compromised. SSL/TLS protects data in flight between client and server; it does not by itself encrypt data at rest in storage pools. Audit admin IDs, failed logins, and authority changes through activity and event records.
Worked example
Create an admin ID ops1 for daily tape operations. Register the ID, grant Operator authority rather than System, and test that it can query sessions and volumes but cannot change policy. The reasoning is least privilege: authentication proves ops1 is valid, while authorization limits the commands available. If the person also needs policy changes, grant a separate, justified authority rather than making every operator a System administrator.
Traps
Do not treat an admin ID as a client node. Do not share admin IDs, which destroys auditability. Do not assume SSL/TLS encrypts stored backup data. Do not grant System authority for convenience. Do not forget that a node password reset affects client authentication, and do not confuse authority to query with authority to modify.