Читать книгу The Official (ISC)2 SSCP CBK Reference - Mike Wills - Страница 154

Trust Relationships (One-Way, Two-Way, Transitive)

Оглавление

One of the key considerations in federating access between or across systems is the way that trust relationships do or do not transfer. One example might be a humanitarian relief operation that involves a number of nonprofit, nongovernmental organizations (NGOs) from different countries, sharing a consolidated planning, coordination, and information system platform operated by a major aid agency. Some of the NGOs might trust aid agency employees with shared access to their information systems; others might not. There might also be local organizations, working with some of the NGOs, who are not known to the international aid agency; even host nation government agencies might be part of this puzzle. The aid agency might want to grant only a limited set of accesses to some of the NGOs and their staff and maybe no access at all to a few of the NGOs. This demonstrates several types of trust relationships.

 One-way trust relationships exist where organization A trusts its users and trusts the users of organization B, but while B trusts its own people as users, it does not fully trust the users in organization A and must limit their access to B's systems and information resources.

 Two-way trust relationships exist when both organizations have the same level of trust in all of the users in the other's domain. This does not have to be as high a level of trust as what they repose in their own people but just a symmetric or matching degree of trust.

 Transitive trust relationships happen when organization A trusts organization B, organization B trusts C, and then in effect organization A trusts C.

Note how transitive relationships establish a chain of trust, with the trust anchor being the one at the root or start of that set of relationships. In the previous example, C has in effect delegated its trust authority to B, and B then provides its assurance of trustworthiness to A. As you'll see in a moment, these third-party connections can provide two different approaches to authentication and trustworthiness, known as hierarchical or web trust relationships.

As the complexity of the relationships between organizations, their systems and platforms, and the domains of user subjects (and objects) associated with those platforms increase, trust relationships can start to matrix together sometimes in convoluted ways. This could quickly overwhelm efforts by each organization's systems administrators to manage locally. Federated approaches to identity and access management are not by themselves simple, but they can be easier to manage, especially when the social or organizational context and trust relationships are straightforward. Federated systems also allow for much quicker, cleaner disconnects, such as when the relief operation ends or when one agency's systems are found to be less secure than can be tolerated by others in the federation.

Solutions to situations like this might contain elements of the following:

 Advanced firewall technologies

 Gateways and proxies as interface control points

 VLANs and restricted VLANs

 Public access zones

 Extranets for data center access

 Extensive Authentication Protocol (EAP)

 Using allowed list management to restrict execution of applications, with application visibility and control functions to monitor and enforce these policies

 Multifactor authentication of subjects

 Behavior and posture monitoring, such as enforcing device update status and using remediation or quarantine to enforce updates or limit access

 Network segmentation to include zero trust architectures where required

Let's take a closer look at some of these trust architectures and frameworks.

The Official (ISC)2 SSCP CBK Reference

Подняться наверх