Security optimization

Relution is a powerful tool with which users sometimes have extensive authorisations on managed devices. The system should therefore be optimally protected against unauthorised access. The Relution portal can be optimised in terms of security at various points with built-in functions. Added to this is the targeted distribution of necessary authorisations.

Use a secure password #

If a new user account is created in Relution, a complex password is suggested here. This can be accepted or changed. In any case, make sure the password complies with the complexity recommendation of the BSI →.

Add a second factor for authentication #

Relution supports login with a second factor. Users must configure this themselves for their own account. To do this, click on the user name > Profile at the top right. An MFA token for an authenticator app or email verification can be stored there. Be sure to use this function!

Use access token #

In Relution, an access token for using the API can also be stored in the user account profile. This token offers the advantage that no username/password combination needs to be stored in plain text in scripts. In addition, the token can be given an expiry date to ensure that it is not active for longer than is really necessary.

Configuring IP Access Rules & Fail2Ban #

In the Global Organisation, both IP access rules and Fail2Ban can be configured under
Settings → System Security.

This allows defining rules such as blocking an IP address for a certain period after a number of failed login attempts (e.g. 10).

IP access rules generally control from which IP addresses or networks a login is allowed or blocked. Both single IPs and entire ranges can be defined.

Meaning of status values #

Allowed

• Login is currently possible
• Is automatically set as soon as a login attempt occurs (even if unsuccessful)
• Mainly used for visibility and logging

Permanently allowed

• IP address is explicitly whitelisted
• Takes precedence over other rules
• Remains permanently active
• Recommended for trusted locations (e.g. office or VPN)

Blocked

• IP address is temporarily blocked
• Can be unblocked at any time

Permanently blocked

• IP address is permanently blocked
• No login possible anymore
• Useful for clearly unwanted access attempts

Use of IP ranges #

The so-called CIDR prefix defines how large the IP range is that a rule applies to.

Basic rule:
The smaller the number, the larger the covered IP range.

CIDR examples #

• 192.168.1.10/32
  → Affects exactly one single device

• 192.168.1.0/24
  → Affects all devices from 192.168.1.1 to 192.168.1.254

Example: Block everything except allowed IPs #

Define trusted IPs #

• Define own or known networks
• Configure them as “Permanently allowed”
• Examples:
  • Office network
  • VPN access

Create global block rule #

• Create a rule covering all remaining IP addresses
• Example: 0.0.0.0/0 (covers all IPs worldwide)
• Status: “Permanently blocked”

Security optimizations for enrollments #

The link and QR code of an enrollment act like an access key: as long as the enrollment is valid, it can be used to enroll a device in Relution. The device then receives the policies and rulesets linked to the enrollment – which may include Wi-Fi credentials, certificates or access to company services. Open enrollments should therefore be kept to a minimum.

• Keep the validity short: When an enrollment is created, Valid until is set to seven days in the future by default. The period should not be longer than actually required for the planned enrollment. If the time is not sufficient, enrollments that have not yet been used can be extended later via Extend Enrollments – long validity periods as a precaution are therefore not necessary.
• Prefer single-use enrollments: By default, each enrollment can only be used for a single device. A Multi-use enrollment, on the other hand, allows any number of devices to be enrolled until the expiration date, limited only by the available licenses. It should therefore only be used specifically for larger rollouts and combined with a particularly short validity.
• Delete enrollments that are no longer needed: Open enrollments that are no longer required – for example after a rollout has been completed or if a device is not enrolled after all – should be deleted under Devices → Enrollments. Devices that have already been enrolled via a multi-use enrollment remain enrolled. For Android Enterprise, the associated enrollment token is also deleted at Google, so the QR code no longer works.
• Do not share links and QR codes publicly: Enrollment links are only sent to the intended recipients and are not published on the intranet, in wikis or via large mailing lists. Printed QR codes are destroyed after the rollout.
• Review enrollments regularly: The list under Devices → Enrollments shows, based on status and Valid until, which enrollments are still open. In addition, the device inventory should be checked for unexpected devices.
• macOS: profile removal password: For macOS enrollments, Use profile removal password can be enabled. The MDM profile can then only be removed from the device with an automatically generated password.

Manage permissions #

Relution offers twelve authorisation preconfigurations as standard. Check which functions are active in which authorisation preset. To do this, click on Users → Permissions and pay attention to the entries that have been created by the system. These roles cannot be edited. However, new authorisations can be created at any time, enabling the necessary functions for individual users on a fine-grained basis. The authorisations correlate with the user groups created by Relution.