4.3.3. Architecture

4.3.3.1. Components

The deployment of the Segmentation module requires the installation of two components:

• ON Core: Performs centralized management of the solution, capture of discovery events, profiling of discovered assets, and implementation of business logic.

• ON Analytics: Performs management and visualization of the collected information, dashboards generation, and reports visualization.

The deployment of additional components depends on final project requirements.

4.3.3.1.1. ON Core

On Core provides the centralized administration console. This is where the access policy engine resides, together with user authentication, authorization and accounting manager, processes and validates the user posture/profiling, integrating with the corporate identity manager. It also manages and validates the double authentication factor.

It is a mandatory component of the solution that includes critical components such as:

• Policy Engine: It is the solution’s brain; all modules are implemented using this component.

• CMDB: It is the memory of the solution where all the configuration, assets and its features are saved.

• Administration Portal: It is the control panel for the solution.

Note

It is a critical component in the solution. The implementation of one or more nodes will depend on the requirements of the deployment, and the final architecture design to provide high availability.

With this component offline, we would lose the ability to authenticate requests, so it is necessary to configure allowing traffic (bypass mode) in the network devices.

4.3.3.1.2. ON Analytics:

ON Analytics, is based on the Stack ELK, receives the different solution logs, as well as the metadata of the traffic processed in ON Sensor via Filebeat. It gives structure to metadata and builds the datalake to display dashboards, allow searches, and report building.

It is a mandatory component of the solution that includes non-critical components such as:

• Aggregator: An enrichment of all the information generated by any component of OpenNAC Enterprise.

• Search Engine: Based on an elastic search engine that allows you to easily search the information generated and collected by the OpenNAC Enterprise components.

• Dashboards and reports: The solution includes a set of dashboards and reports based on common technical information gathered. You can create and generate your own custom dashboards

Note

ON Analytics is a non-critical component for the solution, therefore, it does NOT require high availability. The implementation of one or more nodes will depend on the requirements of the deployment, and the final architecture design. If this component is outlined, the main functionality of OpenNac Enterprise modules would continue working, with the exception that during the outlined period we would no longer have the ability to process and display the information of the solution.

In deployments where a large amount of data is generated, it may be necessary to deploy multiple Analytics nodes to load balancing the storage. Analytics has two types of roles, typically within the same node, a role with aggregation functions (Aggregator) that receives information through Filebeat and process logs with Logstash, the other role (Analytics) with data management functions performed by ElasticSearch and visualization through Kibana.

4.3.3.2. Standard Architecture

A reference architecture requires the components described above and depends on the network architecture available to the customer, as well as the number of users on the network.

Based on mandatory components and location in the network, the following points should be considered:

• The network devices can support more than one RADIUS server in its configuration, so the architecture may consider having two or more ON Cores to be deployed. Otherwise, we can include the configuration of a Proxy RADIUS that performs the balancing to multiple ON Cores and use a single RADIUS server in the settings.

Here we can see the architecture that shows the suggested components location:

Note

The high availability deployment depends on the needs and customer network resources, so an additional component such as a RADIUS Proxy (provided by OpenNAC Enterprise) or a load balancer can be added. This works if all nodes work in active mode and in case of shutdown event of one of them there is no service interruption in the authentication.

4.3.3.3. Standard Sizing

Based on the reference architecture, the standard sizing of the solution for the Segmentation module supports up to 5.000 concurrent users. Keep in mind that when it comes to authentication, the solution is sensitive to latency, so a maximum of 10ms is recommended between the communication of the network electronics and the ON Core.

4.3.3.3.1. Sizing

Concurrent user growth is achieved by adding more nodes in an N + 1 scheme through a RADIUS proxy or load balancer.

Component	Number	CPU	Memory	Disc/Type	Network Int.
ON Core	1	8 Cores	16 GB	160 GB/SSD	2 NIC
ON Analytics	1	8 Cores	16 GB	200 GB/SSD	2 NIC

Note

The 2 network interfaces are mainly for service and management (internal communication between the different nodes)

To continue with the Segmentation module, read next section Segmentation configuration.