Roles

No matter which option you choose, what is almost more important than the existence of user names and passwords is a roles and authorization strategy that you map to the central user directory. This is where things get tricky. Opinions differ on how to map permissions in LDAP and other identity management tools.

One method that is frequently used is based on LDAP groups. In terms of the logic, you map the access permissions to a resource as a group membership. Access to the service is granted only to users who belong to the corresponding LDAP group. However, it is not possible to fine-tune this group assignment, which is why workarounds have developed. Often there are different LDAP groups for users and administrators of services. The catch is that the service that is then coupled to LDAP must also be able to evaluate these groups. There are also other hurdles. After all, LDAP also support roles and additional hierarchy levels. These factors are often a central obstacle.

The complexity in assigning permissions underscores the fundamental importance of up-front planning in deploying zero trust models. Before system administrators even think about rolling out OpenLDAP or FreeIPA, they need to have a workable design for users and roles based on a RASCI matrix [5] that maps as many contingencies as possible in advance.

As usual, once the strategy is in place, far-reaching changes are difficult to implement and usually come at the cost of user resistance. On the other hand, if it is already clear in advance which authorizations are required for access to individual services, it is easier to implement the central user directory in a way that matches the design.

Finding Software

From the point of view of the system administrator, it is particularly problematic that zero trust has not yet been implemented as an established technical standard but instead only as a multitude of partly contradictory strategies. The definition provided with the SP 800-207 standard (described previously) is informative but a little vague. If you want your software to meet the requirements of zero trust, there is no ready-made script to guide you.

Network services and components can vary greatly in their support for zero trust. In most cases, central services such as existing groupware or mail servers offer the flexibility you need. Standard solutions such as Dovecot or Postfix, for example, can handle the connection to LDAP with many buttons for fine tuning, making it easy to implement a mail setup that supports zero trust.

The situation becomes more confusing when you are using proprietary tools that do not connect to LDAP at all or do not implement features such as two-factor authentication. In that case, you need to turn to workarounds: Libpam, for example, implicitly offers two-factor authentication and now has modules that integrate Google's Authenticator for one-time passwords. This even makes it possible to additionally secure SSH logins on remote systems when an SSH key is no longer sufficient by itself. However, implementing Authenticator via PAM in particular has massively affected performance in the past, so you need to consider your options carefully.

Several projects are intentionally designed to support the administrator in implementing zero trust. One well known candidate is Teleport (Figure 3), which is a broad-based replacement for OpenLDAP that promises "identity-aware authentication." In the background, Teleport relies on established standards such as X.509 or OpenID and exposes them to the user, while acting as a client for classic services such as SSH.

Figure 3: Teleport acts as a proxy between a zero trust architecture and other applications. © Teleport

In practice, Teleport acts as a proxy that greatly facilitates the migration to zero trust. This approach offers an advantage, especially with regard to proprietary or legacy software. These applications can only be integrated into zero trust architectures with services such as Teleport. Anyone who has ever tried to reinstall legacy in-house software knows how difficult this can be several years after the program was created.

It is no coincidence that the Teleport website puts banks at the top of its list of high-relevance customer groups. Banks often run legacy software that you would hardly dare to think about integrating into modern security architectures without a proxy or some form of compatibility layer.

Mobile Devices

Smartphones and tablets have long since mutated into fairly powerful computers that can be used to handle simple everyday tasks in a convenient way. Special rules already apply to mobile devices independently of zero trust. As with laptops, the risk of loss means that encryption of the data on the device must have high priority. If mobile devices are maintained under a zero-trust umbrella, the company has a vested interest in maintaining control over a device at all times, even if it has been stolen or lost. In that case, it should at least be possible to wipe the device remotely and prevent further use by means of an activation lock.

In environments based on the zero trust standard, mobile devices often play a significant role. Because authentication in a zero trust environment must be secured via multiple factors, a mobile device might act as a security token via a service such as Google Authenticator. Of course, this means that the security measures we have looked at thus far have to be observed even more strictly (think unlock mechanisms). If a device can be easily unlocked, the Google Authenticator installed on it as a second factor is rendered useless. A secure and suitable unlock configuration is therefore necessary.

As central as the role of mobile devices in zero trust environments is, there are hardly any sensible options for managing the devices centrally with Linux on-board tools. At least there is nothing at the software level that could even begin to compete with the central tools from Google (Figure 4) or Apple (Figure 5), which offer features such as the option to remotely wipe a lost smartphone. If you issue cell phones to employees, take the security of smartphones into account in your planning for zero trust. It is hard to avoid biting the bullet and hiring the services of the two major manufacturers to help with your zero trust strategy.

Figure 4: Mobile devices play a central role in zero trust systems. Admins find it hard to avoid using a device manager such as Google's setup for Android. © Google

Figure 5: Apple also offers the option of remotely enforcing policy compliance with rules for iOS devices. © Apple