by: VMware Lead Middleware Architect Chakravarthy Gajula
Middleware logic, via an Oracle service-oriented architecture (SOA) and Oracle Service Bus (OSB), play major integration roles in the VMware enterprise application landscape. Business-critical applications, such as our common SaaS platform (CSP), MyVMware, Oracle eBusiness Suite (eBS), and several other applications depend on these services being constantly available.
NSX Data Center enables micro-segmentation by providing fine-grained network security policies that are distributed throughout the network based on a VM’s purpose. Micro-segmentation policies follow a VM as it moves. Many successful infrastructure-related attacks are due to mistakes made over time or poor maintenance. Because the policy follows the VM, the application is protected throughout its lifecycle and administrative overhead is reduced.
If an intended application port is blocked, the complete business flow breaks, impacting customer experience and revenue. By implementing micro-segmentation on the SOA/OSB layer, we have secured one of the most complex components of the IT infrastructure. The implementation required careful planning and testing but was completed within a relatively short period of time. Our experience and findings are detailed below.
Overview
Below is the SOA architecture before implementing micro-segmentation. Firewall rules protect external access, but east-west communications are not secured.
Micro-Segmentation Process
Using NSX Data Center to do micro-segmentation, we were able to implement a security model in which security services specify permitted traffic and everything else is blocked, or a Zero-Trust architecture. NSX micro-segmentation was implemented using a well-defined process, which starts with application discovery (the process of identifying unique data flows), followed by dynamic security groups and policy creation, traffic analysis, firewall review, testing, and deployment.
Here are the steps we followed for the micro-segmentation of Oracle SOA/OSB:
- Server identification. Captured server names and grouped them according to functionality–web, application, databases, etc. We checked sys log settings and firewall exceptions, so they could be configured at the ESXi host level. The sys logs were forwarded to log management tools such as VMware Log Insight. (We have since switched to vRealize Network Insight for our micro-segmentation projects.)
- Server groups. Divided servers into functional groups. For example, the database application and integration servers were assigned to separate groups. By applying firewall rules to a group instead of individual VMs, management was simplified and centralized.
- Group security policies. Wrote separate firewall rules for each group, then mapped the security policies to the security groups.
- Traffic capture/analysis. Used VMware Log Insight to capture, identify, and analyze flows in and out of the middleware logic.
- Firewall rules. Reviewed the firewall rules for east-west traffic with the application development teams for each module, including the usual traffic between the load balancer, application servers, and databases. We also evaluated traffic from other tools connected to the application servers or database, including middleware and tools. Then we enabled and tested them.
- Testing and deployment. We did extensive testing in a pre-production environment to ensure Oracle SOA/OSB functioned normally. We reviewed issues that were reported during pre-production testing, checked the relevant source-target IPs and port numbers, and made the required modifications. Pre-production testing helped us sort out and fix many issues early. We followed the same process to implement the rules into production.
This diagram shows Oracle SOA/OSB with micro-segmentation. The entire application is secured using NSX distributed firewalls that protect integrations and the application and database layers. Each VM now acts as its own perimeter. Unauthorized traffic is blocked because security policies are aligned with logical groups.
Micro-Segmentation Rules
Below is the complete rule set for the Oracle SOA/OSB micro-segmentation, excluding monitoring and security management tools.
Micro-Segmentation Key Learnings
We experienced one production escalation during the micro-segmentation process. Following the micro-segmentation implementation on the SOA and OSB servers, ports to the SOA database node were blocked. A large number of threads began to pile up on the SOA servers, causing issues across the board.
Using VMware Log Insight, we were able to quickly determine that the 1521 port to the SOA database was unintentionally blocked. This rule had not been carried forward from the non-production to production rule set. We revised our process to ensure that we accounted for these types of rule changes in future projects.
By implementing micro-segmentation with NSX Data Center on Oracle SOA/OSB middleware logic, we ensured that all calls coming to and from the middleware logic are secured and authorized, with no unintended access to these servers. This includes both internal and external access requests. For example, if an internal person is not authorized to run a script in production, it will block this request.
Oracle SOA/OSB was one of the first micro-segmented applications for our Oracle environment. Stay tuned to the NSX page to see more blogs on other applications that have been micro-segmented.
To read more about the deployment of micro-segmentation with NSX Data Center in various IT applications, click here.
VMware on VMware blogs are written by IT subject matter experts sharing stories about our digital transformation using VMware products and services in a global production environment. Contact your sales rep or [email protected] to schedule a briefing on this topic. Visit the VMware on VMware microsite and follow us on Twitter.
