Decoupling policy decision and enforcement points to support zero-trust architecture on Oracle Cloud

January 22, 2024 | 5 minute read
Subba Bhamidipati
Senior Product Architect, Product Management, OCI
Text Size 100%:

To help reduce risk from constant threats, zero-trust architectures should use a separate control plane for policy decision point (PDP) while the policy enforcement point (PEP) is implemented on a data plane. In this blog post, we explore how to decouple a PDP and PEP implementation using Oracle Cloud services to support your zero-trust architecture and enhance access control on Oracle Cloud.

Oracle Cloud Infrastructure provides a compelling set of security capabilities to protect your mission-critical workloads and sensitive data. Oracle Cloud implements a zero-trust security model that is informed by the zero-trust architecture established by the National Institute of Standards & Technology (NIST). This model enables you to enforce a stringent security posture that requires verification from every user trying to gain access to systems, networks, and data.

Oracle Cloud offers robust capabilities around Identity and Access Management and API Gateways that will allow you to achieve separation of PEP and PDP in your cloud architecture.

Identity and Access Management

Oracle Cloud provides an enterprise-class identity-as-a-service (IDaaS) platform called Identity and Access Management (IAM). IAM uses identity domains to provision cloud identities, users, and secure applications. You can use IAM with Identity Domains as the PDP to allow or deny the access to various cloud resources or services by defining granular IAM policies.

The identity platform serves as both the front door into cloud services, as well as a standalone IDaaS platform for both enterprise users and consumers. This platform provides key identity management capabilities for applications and services running in Oracle Cloud, third-party clouds, and your on-premises data centers. IAM offers authentication, single sign-on (SSO), and identity lifecycle management for Oracle Cloud and for Oracle and non-Oracle applications, whether they are SaaS, cloud-hosted, or on-premises. IAM also allows you to control what type of access a group of users have and to which specific cloud resources.

For more details on IAM features, refer to the IAM product documentation.

API Gateway

Oracle Cloud builds services with a security-first design approach. With this approach, services like the API Gateway enable you to create data access policies that allow only authorized users or applications to access the data across the enterprise.

The API Gateway service allows you to create governed HTTP/S interfaces (APIs) for multiple backends, including Oracle cloud services, such as Load Balancers, Functions, Compute instances, and on-premises applications connected to the Oracle Cloud through VPN or FastConnect. API Gateway provides policy enforcement features, such as rate-limiting to HTTP/S endpoints, authentication with identity providers, and access to multiple RESTful services both in the cloud and on-premises.

API Gateway helps ensure that the caller is authenticated so that the backends connected to the gateway cannot be called anonymously. API Gateway can also check the authorization. API Gateway allows you to add HTTP and HTTP/S URLs to a back-end service to grant those services front-end access with policy enforcement. The HTTP/S URLs that you specify for the backend service can be one of the following options:

  • The URL of an Oracle Cloud service, such as Functions or Object Storage
  • The URL of a service in your own private or internal network that is connected to Oracle Cloud Infrastructure through VPN or FastConnect

For more details on API Gateway features, refer to API Gateway Product documentation.

Integrating IAM and API Gateway to achieve PDP and PEP separation

You can integrate Oracle Cloud IAM and API Gateway to achieve separation between the PDP and PEP. The following figure shows the integration between API Gateway and IAM. In this architecture, API Gateway acts as PEP by enforcing the policies, whereas IAM acts as PDP by authorizing the token and granting access for authorized users. This integration uses JSON Web token (JWT), or access token. JWT is an open industry standard that allows you to integrate with other IAM systems.

 Architecture diagram for API Gateway and IAM integration
API Gateway integration with IAM

 

The following steps explain the architecture authorization flow with API Gateway and IAM:

  1. The client application/end user generates access token (JWT) from the IAM (PDP) using IAM APIs.
  2. The access token (JWT) is sent to API Gateway as part of the HTTP request header of every API call. Optionally, the token can also contain scopes that have been specifically defined for the resources.
  3. The API Gateway (PEP) calls the IAM authorization API and passes the access token received from the client.
  4. The IAM Service (PDP) evaluates the token and returns a decision to either allow or deny.
  5. The API Gateway (PEP) grants or denies access to back-end services, such as Microservices running in OKE, Functions, Object Storage, or to a service endpoint exposed by an application running in a virtual machine (VM) based on the outcome of the IAM policy decision.
  6. The API Gateway (PEP) returns the status 200 OK (allow) or 403 Forbidden (deny) back to the caller.

You can implement this integration using the cloud console or GUI and REST calls. For more details on how to protect APIs using API Gateway and IAM JWT with scopes and claims, refer to the blog, Protect APIs with API Gateway using IDCS/IAM JWT with Scopes and Claims.

Secure your mission-critical workloads today

Oracle built our cloud with security-first design principles, implementing core zero-trust security from the ground up. By implementing appropriate controls on Oracle Cloud, you can suitably authenticate and authorize requests based on data access policies while monitoring access.

You can select the Oracle Cloud free tier in public regions to get started with a range of services, including compute, storage, and networking. If you prefer Oracle Dedicated Region or Oracle Government Cloud, including Oracle Cloud Isolated Regions, consult your Oracle sales representative for a proof of concept in the appropriate region.

For more information, see the following resources:

Subba Bhamidipati

Senior Product Architect, Product Management, OCI

Subba Bhamidipati is a Senior Product Architect on the Oracle Cloud Infrastructure Isolated Region team. Subba has extensive experience working in product development, product management, and customer-facing roles in delivering excellece with Oracle technology.  

Subba has a deep understanding across the 3 pillars of OCI (IaaS, PaaS, and SaaS), with a proven track record of successful customer implementations both on premises and on OCI. Subba has a high level of knowledge on building integration and SaaS (ERP Cloud, HCM, etc.) extensions using PaaS services including OIC, Visual Builder, Serverless Functions, etc.

Show more

Previous Post

An overview of using Terraform to deploy OCI’s managed PostgreSQL database

Akarsha Itigi | 5 min read

Next Post


Migrating applications to the cloud? Use OCI DNS Traffic Management

Jarrod Meschino | 5 min read
Oracle Chatbot
Disconnected