Zero trust architecture using MuleSoft
Introduction:
Trust is the #1 value of Salesforce. As a technology vendor, it is critical for us to guide and enable our customers to maintain trust relationships with their customers when they directly or indirectly interact with Salesforce technologies. The fourth industrial revolution resulted in an unprecedented proliferation of technologies and systems, an exponential increase in generated data, distributed deployments, and a growing need for OpenAPI adoption to share data. The resulting complexities and evolving security threats make it imperative for governments and enterprises alike to consider zero-trust security architecture as a critical success factor for business instead of treating it as just another IT initiative. Despite available technologies and several points of view, there have been limited prescriptive solutions and case studies on mapping the high-level zero trust vision to actual implementation. It is therefore important for the technical stakeholders such as enterprise architects to connect the dots across the concepts of open APIs, API security, identity management (IDM), and data access control methods to enable secure data access across producers and consumers of data. The combination of a robust design and implementation strategy joined with MuleSoft’s strengths as an API management platform along with a compliant identity management solution, creates a best practice zero trust architecture that can be adopted at scale across organizations and geographies. This best practice zero trust architecture facilitates a rich and secure customer experience.
What is Zero trust architecture?
Zero trust a concept seeded by Forrester alum John Kindervag in 2009 is based on securing systems at the transaction level and every touch point rather than only at the point of entry or at a blanket level. A blanket or implicit security model worked well when systems were deployed in on-premises networks where the limited scope of systems and users along with data center level security allowed this model to suffice the security needs. The introduction and wide adoption of multi-cloud deployment models, SaaS systems along with traditional data centers across different geographies made it necessary to secure every touch point to prevent data leaks, ransomware and reputational damage for organizations.
MuleSoft overview:
MuleSoft (from Salesforce) provides a iPaaS(integration platform as a service) and automation platform that allows IT and business users to connect and automate applications, data and devices. This includes integrating data and systems, automating workflows and processes, and creating incredible digital experiences — all on a single, easy-to-use platform. With a unique approach, IT creates the digital building blocks that teams can use as they need, all with the right security, governance, and compliance measures built in.
Key concepts and solution architecture:
Zero trust architecture with attribute based access control(ABAC):
The zero trust architecture, can technically be achieved by enforcing security at each point of entry using commonly used security policies such as client id /secret enforcement, basic authentication, ip address whitelisting, OAuth etc. These security policies bring industry standard compliance to the architecture. However, their static enforcement approach lacks the dynamism that ABAC based implementation (explained in detail later) can bring by capturing and validating the attributes that can change with every interaction. An ABAC based approach brings complementarity to the zero trust architecture and can significantly improve the security for an organization.
The recommended zero-trust solution leverages OAuth 2.0 security principles, identity management, attribute-based access control (ABAC), and API management weaved together using an API-led architecture approach. Combining these product capabilities and concepts is substantiated into a tangible solution that demonstrates how each API/micro-service can be protected with the API manager capabilities. The API manager is a key component to authenticate/authorize an API access request based on the end consumer’s dynamic request attributes such as IP address, user identifier, device type, and physical location. This baseline solution can be extended/amended as needed to support different security postures, organization or industry-specific security guidelines, and deployment models.
From a technology selection and functional implementation standpoint, the solution is based on deploying multiple MuleSoft APIs exposing data from underlying SaaS and on-premises systems of records, a process orchestration layer collating data from the underlying systems, and an experience layer providing secure access to a consumer-facing system such as a mobile app or web portal. A vital part of this solution is the identity management solution and a delegated OAuth API that works together to make authentication/authorization decisions. Because each API has a policy enforcement point, their interactions across them are also protected, thereby achieving zero trust architecture for both north-south and east-west traffic.
However, before diving into the detailed solution, let’s try to understand the concept of attribute-based access control (ABAC), how it is different from the more prevalent approach of role-based access control (RBAC), and the need to consider the former vs. the latter to achieve zero trust security architecture. The ABAC concept relies on granting permissions to resources and information based on the dynamic attributes of the user requests, such as IP address, device type, location, network type, etc. These dynamic rules are enforced at the point of entry(a.k.a. policy enforcement point or PEP) and validated at the policy decision point(or PEP). The below diagram illustrates the interactions between these components.
RBAC approach, on the other hand, is based on roles and associated permissions that are static in nature. Also, as the complexity of permission rules and granularity increases, the RBAC approach is not very scalable. A critical limitation of RBAC is its inability to support dynamic user attributes such as IP address, device type, location, connection type, etc. Given the sensitive nature of personally identifiable information(PII) or restricted government information, applying dynamic rules based on dynamic attributes becomes critical. For example, it might be suitable to allow access to highly confidential information to authorized government personnel when they’re trying to access secure government premises in their home country using a work laptop vs. accessing the same using their mobile devices on a public wifi network in a foreign country. The table below highlights the key differences between RBAC and ABAC.
ABAC and identity management solutions:
ABAC as a concept is not very new, and while OKTA and ping federate were the early adopters of supporting it out of the box(OOTB), other major identity providers such as MS Azure and AWS incognito now also support ABAC configurations. The ABAC configurations can be applied and enforced when end-user systems are configured to use single sign-on(SSO) using these IDMs. Data sharing across different front-end and back-end systems(or core systems of records) is done through APIs, and to achieve zero trust, there is a need to enforce the same dynamic rules at each point of entry or hop when users or systems attempt to access information collated across different systems. Each hop, regardless of whether it is an API proxy uncovering the data from a traditional SOA service, a modern REST API being invoked through a mobile application, or a single-page web app, requires a secure point of entry protected with the same attribute-based dynamic rules.
Zero trust API-led solution architecture using ABAC:
Diving a little deeper into how the overall solution implementation would look like, let’s start with a use case of 4 critical systems of records, each with a confidentiality rating of 1) No risk /publicly available information, 2) Low Risk / official or limited to government staff 3) Medium Risk or sensitive information limited to select staff 4) High Risk or top secret or classified information restricted only top select top government officials. Referring to MuleSoft’s API-led architecture, each of these systems can have a System API for logic, connectivity, and built-in API manager policy enforcement. If the underlying API or service is implemented using a non-MuleSoft technology, and the need is only to provide API security, it is possible to do so using the API proxy pattern. If there is a need to connect to each of these systems for exchanging or collating data, a process-level API can also be introduced with its own PEP. Moving up the architectural layer, an experience layer(most commonly considered for a customer-facing system, such as a web portal or mobile application with a front-end developer-friendly data model and security setup) can be implemented with its own PEP. To reiterate, having a PEP ensures zero trust is maintained at every interaction. The idea of PEP is based on authorization and authentication using industry-standard OAuth 2.0 framework and JSON Web Token(JWT) format(although the same concepts can be applied using OAuth alternatives if needed). The OAuth / JWT is based on token generation directly with the IDM and validating the token signature, expiry, scopes, user-id, claims, and any dynamic attributes at the point of entry using the public key URL(a.k.a. JWKS URI). This URI gets configured for each API in the API-Led architecture(i.e., to ensure zero trust architecture).
The next part of this solution combines the ideas of using ABAC-supported IDM in conjunction with what can be called delegated OAuth API to create a policy decision point(PDP). This delegated OAuth API is an optional but recommended component to facilitate additional logic and rules that may be difficult or expensive to do directly inside the IDM(on top of what IDM supports out of the box). For example, there might be a need to do additional validations from another system or registry(in addition to IDM) as part of the dynamic ruleset. This technology-agnostic component may or may not be built using MuleSoft. This delegated OAuth Service, when configured as a JWKS URI, performs the validation for token signature/expiry/scopes/claims/dynamics attributes, acting as a central checkpoint for each API for the zero trust API-led architecture. To improve performance and scalability, this API can be equipped with multi-node high availability(HA) setup and caching to speed up response for static information from IDM.
The diagram below represents the overall API-led architecture solution based on the aforementioned explanations.
Applying API governance to the zero trust architecture:
Additionally, looking at zero trust architecture from the lens of API governance, each API component technically follows an API specification that dictates specific API policies, request/response models, header values, etc. An additional governance layer can also be introduced for a design/runtime check to periodically validate if agreed-upon organization-specific zero-trust guidelines are indeed implemented. These automated checks can identify and report any violations or gaps at design time or runtime in the lower/test environments before being promoted to production. This segregation of responsibilities of setting up and monitoring compliance guardrails by security owners/architects and functional implementation with developers results in overall efficiency for both parties.
Conclusion:
Finally, when it comes to implementing the zero trust architecture, the choice of technologies is as important as driving the organizational change and setting up the operating model and governance in terms of processes and people. While it may be possible to implement the above-mentioned zero trust solution using different technologies, it is important to consider aspects such as managing different products, upskilling the team with multiple products, pricing models, breadth/depth of capabilities, deployment topologies, and fitment into your enterprise architecture. MuleSoft provides a single unified platform to meet all the required technical capabilities, best practices harvested from actual implementations, and operating model playbooks to help deliver not only zero-trust solutions but also other strategic integration initiatives.
To summarise, with the unprecedented pace of emerging technologies and the need to exchange data across growing systems, zero trust is a naturally growing phenomenon to counter evolving threats. The distributed nature of technology deployments, a combination of multi-cloud and on-premises hosting, and organization-specific security guidelines make it significantly complex to envision a zero-trust model, drive the change for correct adoption, remain in sync with industry security best practices and periodic re-calibration to ensure compliance. MuleSoft, as part of Salesforce, is committed to investing in making products more secure and compliant in line with industry trends, as well as providing thought leadership to enable our customers to provide an awesome yet secure experience to their customers.
Acknowledgements:
Thorin Greene, Director of Technical Architecture, Salesforce
References:
- Zero trust in Australia: https://www.itnews.com.au/news/australia-sets-whole-of-government-zero-trust-target-602646
- MuleSoft API Manager: https://www.mulesoft.com/platform/api/manager
- JWT Policy: https://docs.mulesoft.com/gateway/latest/policies-included-jwt-validation
- API Led Architecture Approach: https://blogs.mulesoft.com/learn-apis/api-led-connectivity/
- OKTA ABAC: https://developer.okta.com/books/api-security/authz/attribute-based/
- OAuth 2.0: https://oauth.net/2/
- MuleSoft API Governance: https://docs.mulesoft.com/api-governance/
- Zero Trust Forester: https://www.forrester.com/blogs/a-look-back-at-zero-trust-never-trust-always-verify/
- MuleSoft: https://www.mulesoft.com/
Further Readings:-
