Merge branch '111-has50-add-shalls-5-2-6' into 'main'

### 5.2.6 Role based authorisation

The identity management is a corner piece in the larger puzzle of cybersecurity.

All actions with authority need to be identified when they are performed. If the system fails to identify such actions, or doesn't track who executed these commands, the system can fall into a state of chaos. Like a void pointer without boundaries.

The identity management is an essential piece in the larger puzzle of cybersecurity. A secure product is required to confirm the identity and authority of all users performing an action. If the system fails to identify such actions and authroity, or fails to track who executed commands, the system can easily fall into a state of chaos.

An identity management system provides the authentication of each user. It provides the assurance of that an entity has provided correct information to the product.<a href="#_ref_i.12">[i.12]</a> To have a functional authentication, the trusted source needs to be well maintained.

An identity management system provides for the authentication of each user. It provides the assurance of that an entity has authorization and has provided the correct information to the product to perform a specific action.<a href="#_ref_i.12">[i.12]</a> Only a well maintianed trusted source list can provide functional authenticantion.

If the source authentication is a company internal directory, the content needs to be up to date and reflect the status of persons granted current access.

These requirements are generally binding, and there is no low-medium-high tiering available.

These requirements apply to all network management systems, regardless of the product's use case and without variation for different tiers or risk.

- **[REQ-AUTH-0]:** The product is integrated into a state of the art identity management system.

- **[REQ-AUTH-1]:** 2-factor authentication is used to confirm the identity of a natural user.

- **[REQ-AUTH-2]:** Authenticated natural users's authorisation validity is no longer than a two days.

- **[REQ-AUTH-0]:** The product shall be integrated into a state of the art identity management system.

- **[REQ-AUTH-1]:** 2-factor authentication shall be used to confirm the identity of a natural user.

- **[REQ-AUTH-2]:** Authorisation validity for authenticated natural users shall be no longer than a two days.

When the identity of a user is established, the system grants the user access rights based on the users' role.The system can have multiple distinct roles, each are tailored to the users' perceived needs.

These roles can be, for example, monitoring data reader, interconnectivity admin, or just admin. If the product's deployment context calls for an all-powerful superuser, there may not be a need to split the responsibility among a variety of roles.

Identity information often comes with a group assignment, matched to a role inside the system.

There are many possible roles, with examples such as: monitoring data reader, interconnectivity administrator, or administrator. If the product's deployment context calls for an all-powerful superuser, this can be accomplished either with a single role with numerous responsibiltiies or by aggregating many available roles to that single user.

In many systems identity information includes a group assignment matched to a role inside the system.

The Role Based Access Control design and depth is outside of the scope of this standard, but the product must use some form of RBAC.

Role Based Access Control design and depth is outside of the scope of this standard, but the product must use some form of RBAC.

Both natural users, machine users, or equivalent structures need roles, despite often performing differently. Machine users can often have more exact limits on what functions they require. <a href="#_ref_i.13">[i.13]</a>

The product can serve traffic that is not meant to be identified.