Security
Authorization in 21RISK
To honor the principle of least privilege, 21RISK offers a range of features described in this chapter.
Roles and permissions
In 21RISK the foundation of authorization is permissions. We have the following permissions in the system:
- updateGroup
- createFactories
- readFactories
- updateFactories
- deleteFactories
- accessAllFactories
- readAudits
- shareReports
- createAuditDrafts
- readAuditDrafts
- updateAuditDraft
- deleteAuditDrafts
- publishAuditDrafts
- createRecommendations
- readRecommendations
- updateRecommendations
- reviewRecommendations
- createUsers
- readUsers
- updateUsers
- disableUsers
- modifyUserRoles
- createLabels
- readLabels
- updateLabels
- deleteLabels
- createRiskTypes
- readRiskTypes
- updateRiskTypes
- deleteRiskTypes
- billing
- sysAdmin
- inviteExternalUsers
- createApiKeys
- readApiKeys
- updateApiKeys
- deleteApiKeys
- modifyColumns
A role in 21RISK can have one or more permissions. A user can have zero or one role. Customers can create and configure there own roles. Users can only update users, if they have the same privileges as the other user.
Note
Customers in 21RISK can create their own custom roles, or use prebuilt roles.
Locations
Permissions is not the only factor that can limit a given users authorization to a resource.
If a user is only given access to location AAA, then the user can only update a resource if it’s related to location AAA. Users can also be restricted from specific locations.
Risk Types
If a user is only given access to riskType AAA, then the user can only update a resource if it’s related to riskType AAA. Users can also be restricted from specific riskTypes.
Note
We are working on a "new navigation" experience, that will launch end of 2023/beginning 2024. This will scope users to a "board" - similar to risk types today. Stay tuned for more information.
API-keys
21RISK features a powerful OData REST API, a perfect match for analytical platforms like PowerBI, Qlik, Tableau etc. To give access to such resources, users (with the right permissions) can generate API keys. When the keys are generated, the key is only shown to the user once. In 21RISK we only store a SHA256 hashed. The keys users must store safely, i.e. the API keys, have the following shape:
21RISK.ND.${keyId}.${secret}
We keep track of the generated keys when they are being used, to keep track of key-usage.
Session management
In 21RISK we have build and control session management. We use a secure cookie to do this, and on every single request with our backend we validate the session. This makes it easy to invalidate compromised sessions, or when users are deleted from the system.
- Secure Flag Our session cookies are only sent over secure, HTTPS connections. This prevents cookies from being transmitted over unencrypted HTTP, where they could be intercepted by an attacker.
- HttpOnly Flag Our session cookie is marked with HttpOnly, preventing client-side scripts from accessing them. This reduces the risk of cross-site scripting (XSS) attacks stealing the session cookies.
- SameSite attribute is configured to protect against some cross-site request forgery (CSRF) attacks.
- Unique Secure Session IDs We generate cryptographically strong random session ids, making it very difficult for attackers to guess or predict session IDs.
- Cookie domain and path Session cookies are scoped to 21RISK.com
- Logs and anomaly detection We log all session activity, and periodically inspect suspecious activity.