Network Architecture

The Bravura Security Fabric is available both as a cloud-hosted and Bravura Security-operated service and for on-premises installation, where it can be managed by customers.

Introduction

Bravura Security Fabric exposes a web user interface using a set of self-contained CGI programs, compiled as Windows binaries and running under any standards-compliant web server on the Windows platform.

The CGI architecture eliminates the need for an application server – no .NET or Java runtime is needed to run the user interface. This both simplifies the architecture and improves runtime performance.

The CGI user interface programs accept input forms, assemble new screens using skin files (see below) and display new forms. CGI programs access user and policy data in the Bravura Security Fabric database. They can also communicate with services on the Bravura Security Fabric server and run connectors and plugin programs. Bravura Security Fabric web pages are constructed at runtime from language files and HTML “skin” files – consisting of HTML snippets. These may be modified to change the appearance of the UI, without having to modify product code.

Internal Components

Bravura Security server components show the main components within each Bravura Security Fabric server.

In the figure:

• A database replication service coordinates all reads from and writes to the database, which uses a local instance of Microsoft SQL Server for physical storage.
• The database contains information about accounts and entitlements drawn from integrated systems and applications, which is refreshed periodically by the auto-discovery system.
  
• The database also contains configuration information and workflow requests.
• Contents of the database are replicated between multiple Bravura Security Fabric servers, in a fault-tolerant, asynchronous, encrypted manner. This is handled by the application (not natively by the DB). In a typical deployment, two or more application servers are deployed behind a load balancer, for an active-active architecture.
• All user interaction is a web portal, behind an IIS web server. Some screens are traditional HTML/ single-page while others are more interactive, built using Angular and supported by an AJAX service to access live data.
• A password synchronization service accepts password change events (triggers) from suitably equipped systems and pushes synchronized password updates back to target systems, along with a retry mechanism. It is also responsible for executing and retrying password changes performed via the web UI.
• A password randomization service schedules password changes to machine-generated values on a schedule and in response to events such as access check-ins.
  
• Three separate API services are provided – a SOAP/HTTPS service, an extensible REST/HTTPS service and a local shared-memory-based API, used by business logic and batch processes.
• A set of connectors provides integration with a variety of target systems – to enumerate accounts and groups, to create and delete accounts and groups, to reset passwords, etc. One connector is provided for every type of system and application where Bravura Security Fabric is able to manage identities, entitlements or credentials. In some cases, a local connector communicates with a Bravura Security proxy server, which is co-located with one or more target systems and where the actual connector is run.
• A second set of connectors provides integration with a variety of help desk / incident management applications. These connectors create, update and close incidents in response to events that take place on the Bravura Security Fabric server.
• A log service aggregates all debug log information and forwards select messages to SIEM systems, if required.
• Batch jobs run to send notifications to users, automatically deactivate access, assign/revoke role- based access, etc.
• A mobile proxy maintains a connection pool to one or more proxy services (which have public URLs, because they are hosted in the cloud or a DMZ), to facilitate communication with the Bravura smart phone app.

A variety of authentication plugin programs support leveraging third party MFA systems, via RADIUS, RSA-native, SAML, SMS/PIN, SMS-mail or other mechanisms.

Run Time Environment

Depending on the features deployed and the architecture of the Acme network, the runtime environment for Bravura Security Fabric may incorporate multiple servers, each of which serves a different function:

Platform

Bravura Security Fabric must be installed on a Windows Server, with Windows 2019 or Windows 2016 being recommended at the current release level of Bravura Security Fabric.

Installing on a Windows server allows Bravura Security Fabric to leverage client software for most types of target systems, which is available primarily on the “Wintel” platform. In turn, this makes it possible for Bravura Security Fabric to manage passwords and accounts on target systems without installing a server-side agent.

Each Bravura Security Fabric application server requires a web server. IIS is used as it comes with the Windows 2016 & Windows 2019 Server OS.

Bravura Security Fabric is a security application and should be locked down accordingly. Please refer to the Bravura Security document about hardening Bravura Security Fabric servers to learn how to do this. In short, most of the native Windows services can and should be removed, leaving a very small attack surface, with exactly one inbound TCP/IP port (443):

1. No ASP, JSP or PHP are used, so such code interpreters should be disabled.
2. Web-facing .NET is not used and should be disabled (some connectors require it, due to .NET API bindings).
3. No ODBC or DCOM are required inbound, so these services should be filtered or disabled at the web server. As with .NET, ODBC is sometimes needed to connect to target systems.
4. Inbound file sharing should be disabled.
5. Remote registry services should be disabled.
6. Inbound TCP/IP connections should be firewalled, allowing only port 443, remote desktop services (to configure the software) and a handful of ports between Bravura Security Fabric servers, mainly for data replication.

Each Bravura Security Fabric server requires a database instance. Microsoft SQL 2016 or 2019 are the recommended versions.

Bravura Security Fabric is compatible with 64-bit Windows Servers:

Virtualization

Bravura Security officially supports running Bravura Security Fabric on these virtual servers and will make the best effort to support customers who run on other hypervisors.

So long as the database server that hosts the Bravura Security Fabric back-end has access to reasonably fast I/O (e.g., NAS or similar) and so long as connectivity between the Bravura Security Fabric application server and the database is fast and low latency (e.g., 1Gbps/1ms) there should is no adverse performance impact when comparing Bravura Security Fabric installed on hardware vs. Bravura Security Fabric installed on a similarly-equipped virtual server.

The key point above is to ensure sufficient I/O capacity for the database (MSSQL). If the database server is virtualized, using network-attached storage (NAS) is recommended, as virtualized I/O (files such as VMDK’s emulating an HDD image) is often substantially slower than physical I/O.

Even where customers choose to deploy the main Bravura Security Fabric servers on raw hardware, virtual machines are an excellent platform for proxy servers, test servers, development servers and model PCs.

A related question is often “how large can the deployment get before we have to move from a VM to hardware?” Unfortunately, there is no simple, universal answer:

• Virtual servers vary in capabilities – they may have a 32-bit or a 64-bit CPU, may have 1, 2, 4 or 8 CPU cores allocated, may have different amounts of memory and may link to different types of storage infrastructure.
• The load created by the application also varies – is there complex business logic? Do users access the application at random times or all at once? Are there just a few or thousands of integrations?

This variability means that the safest bet is to use benchmark results, using a configuration as similar as possible to the production setup, to gauge the performance of Bravura Security Fabric on representative physical and virtual servers.

Application server: hardware and OS

Production Bravura Security Fabric application servers are normally configured as follows:

• Hardware requirements or equivalent VM capacity:
• Operating system:
  • Windows Server 2019 (recommended) or 2016. Windows Server 2012 R2 is supported by Bravura Security but not recommended.
  • All available service packs and hotfixes should be applied (automatically).
  • It is recommended that the server is not a domain controller.
  • Core mode on Windows Server is supported.
• Installed and tested software on the server:
  • TCP/IP networking, with a static IP address and DNS name.
  • IIS web server with a valid SSL certificate and the following configured: CGI, HTTP redirect, URL Rewrite, and Dynamic Compression.
  • At least one web browser (i.e. Chrome) and PDF viewer.
  • Python 3.5.3 (64-bit).
  • A Git client (for revision control).
• A Microsoft SQL Server 2019 (recommended), 2016 or 2014 instance is required to host the Bravura Security Fabric schema:
  • Normally one database instance per application server.
  • The SQL Server database software can be deployed on the same server as the Bravura Security Fabric application, as this reduces hardware cost and allows application administrators full DBA access for troubleshooting and performance tuning purposes.

SQL Server 2019, 2016 or 2014 Standard is recommended in almost all cases – SQL Express is acceptable for small deployments and evaluations.

Database server: compatible software 

Bravura Security Fabric requires MS SQL Server 2019 or 2016, typically with one database instance per application server. In most environments, the Microsoft SQL Server software is installed on the same hardware or VM as the Bravura Security Fabric software, on each Bravura Security Fabric server node. This reduces hardware cost, eliminates network latency, and reduces the security surface of the combined solution.

Be sure to install the following components that come with Microsoft SQL Server 2019 and 2016:

• Database Engine Services
• Client Tools Connectivity
• Management Tools - Basic
• Management Tools - Complete

Database I/O performance on a virtualized filesystem (e.g., VMDK or equivalent) is slow. If the database server software runs on a VM, please use a fast, nearby NAS or SAN to store the actual data files.

Bravura Security Fabric can leverage an existing database server cluster, but Bravura Security recommends a dedicated database server instance, preferably one per Bravura Security Fabric application server, installed on the same OS image as the core application.

1. The data managed by Bravura Security Fabric is extremely sensitive, so it is desirable to minimize the number of DBAs who can access it (despite use of encryption).
2. SQL Server has limited features to isolate workloads between database instances on the same server. This means that a burst of activity from Bravura Security Fabric (as happens during auto-discovery) would cause slow responses in other applications. Conversely, other applications experiencing high DB load would slow down Bravura Security Fabric.
3. Bravura Security Fabric already includes real-time, fault-tolerant, WAN-friendly, encrypted database replication between application nodes, each with its own back-end database. Use of an expensive DB server cluster is neither required nor beneficial.
4. Deploying the database to localhost has performance advantages (minimal packet latency from the application to its storage).
5. Allowing Bravura Security Fabric administrators full control over the database simplifies performance and related diagnostics and troubleshooting, especially when we consider that database administrators in most organizations are few in number and very busy.

Eliminating reliance on shared database infrastructure also eliminates the need to coordinate events such as database version upgrades, which involve reboots. Some Bravura Security customers who leverage a shared database infrastructure have experienced application disruption due to unscheduled and un-communicated database outages and restarts.

Deploying multiple servers

Bravura Security Fabric supports multiple, load-balanced servers.

Each server can host multiple Bravura Security Fabric instances, each with its own users, target systems, features and policies.

Bravura Security Fabric instances can and normally do span multiple servers. Every server hosting a given instance is functionally identical. User traffic is load balanced between servers supporting the instance. Load balancing may be accomplished using DNS (round-robin is built into most DNS servers) or at the IP level with a device from Cisco, F5, etc.

High availability is accomplished by combining load balancing with server health monitoring and automatic fail-out. Bravura Security Fabric includes server monitoring tools that can be configured on each server to monitor its peers and when a failure is detected to trigger an alarm (e.g., by email) and to automatically update DDNS records to remove the failed server from circulation. Bravura Security also provides these tools for Unix/BIND with traditional DNS.

There is no coded limit to the number of concurrent, replicated servers. With more than 10 servers, replication may become slow. Since the three largest customers of Bravura Security run with just two production servers each, this is only a theoretical problem.

Using proxy servers to reach distant or firewalled systems

In some cases, the connection to a target system may be slow, insecure or blocked. This may be because the connection spans multiple data centers or uses an insecure network protocol.

To address such connectivity problems, Bravura Security Fabric includes a connector proxy server. When a proxy server is deployed, the main Bravura Security Fabric server ceases to make direct connections to some target systems and instead forwards all communication to those systems through one or more connector proxies, which are co-located with the target systems in question.

Communication from the main Bravura Security Fabric server to the connector proxy is encrypted and works well even when there is low bandwidth or high packet latency. It uses a single, arbitrarily- numbered TCP port number. Connections are established from the main Bravura Security Fabric application server to the proxy server. A single TCP port supports an arbitrarily large number of target systems at the connector proxy’s location.

It is simple for firewall administrators to open a single TCP port per proxy server. Since connections are efficient and encrypted, there are usually no objections to doing so.
Communication between the proxy server and target systems continues to use whatever protocol each system supports natively. This communication is confined to a physically secure data center with a high-bandwidth, low-latency local network.

Arrangement of Servers

Most Bravura Security Fabric deployments call for at least two and as many as four production application servers, preferably distributed across multiple data centers, to provide high availability and business continuity in the event of a disaster. These servers are normally virtualized.

Incoming traffic to the servers is load-balanced, as Bravura Security Fabric provides an active-active, multi-master architecture. In the event of a disaster, inaccessible servers are removed from load balancing, but the remaining servers simply continue to work.

There should also be at least one development server (typically configured with a smaller capacity) and at least one testing server. Note that development and UAT servers should be placed in test environments, with representative instances of as many integrated systems as possible, to allow for testing against non-production systems.

See Bravura Security Fabric server hardware and software configuration.

Server Configuration

Bravura Security Fabric Server Configuration: