4.3.3. Architecture

This section outlines the necessary nodes for the use case, offering essential information on its architecture, including components, simplified architecture, and recommended sizing.

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

The ON Core is a critical component of the solution. The implementation of one or more nodes to ensure high availability will depend on the deployment requirements and the final architecture design.

If this component goes offline, the solution will lose the ability to authenticate requests.

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 of the solution and therefore does not require high availability. The decision to implement one or more nodes will depend on the specific deployment requirements and the final architecture design.

If this component is taken offline, the main functionality of the OpenNAC Enterprise modules will remain operational. However, during this downtime, the system will not be able to process or display solution-related data.

In deployments where large volumes of data are generated, it may be necessary to deploy multiple Analytics nodes to balance the storage load.

The Analytics component has two roles, typically running on the same node:

• Aggregator: This role receives information via Filebeat and processes logs using Logstash.

• Analytics: This role handles data management through Elasticsearch and provides data

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.