Solution architecture

Protection Server component

Kaspersky Security Protection Server (hereinafter also referred to as the "Protection Server") is a scanserver service installed on a special virtual machine called an SVM (secure virtual machine). An SVM is included in the Kaspersky Security distribution kit as a virtual machine image. During installation of the solution, you need to deploy SVMs from an image on hypervisors in the virtual infrastructure.

Protection Server performs the following functions:

• Scans the fragments of files sent by Light Agents installed on virtual machines for viruses and other malware. The SharedCache technology is used for scan. It optimizes the speed of file scan by excluding files that have been already scanned on another virtual machine. The Protection Server stores information about scanned files in a cache on the SVM in order to not scan them again.
• This ensures that the application receives an update package from the Kaspersky Security Center Administration Server repository, which contains the database and application module updates necessary for operation of the solution.
• Manages license keys and licensing restrictions.

Light Agent component

Kaspersky Security Light Agent (hereinafter also referred to as "Light Agent") is an application installed on each virtual machine that needs to be protected using the Kaspersky Security solution. A virtual machine with the Light Agent component installed is called protected virtual machine.

If Kaspersky Security is used to protect VDI, Light Agent is installed on virtual machine templates from which persistent or non-persistent virtual machines are created.

The Kaspersky Security solution includes:

• The Light Agent for Linux component is designed to protect virtual machines with Linux operating systems.

  The Kaspersky Security solution uses Kaspersky Endpoint Security for Linux in Light Agent mode as the Light Agent for Linux. The application protects virtual machines running Linux operating systems from various types of threats, network attacks and fraud. For more information about the capabilities of Kaspersky Endpoint Security for Linux commands, see the application help of the relevant version.

• The Light Agent for Windows component is designed to protect virtual machines with Windows operating systems.

  The Kaspersky Security solution uses Kaspersky Endpoint Security for Windows in Light Agent mode as the Light Agent for Windows. The application protects virtual machines running Windows operating systems from various types of threats, network attacks and fraud. For more information about the capabilities of Kaspersky Endpoint Security for Windows commands, see the application help of the relevant version.

When launched, the Light Agent establishes and maintains a connection to the SVM in order to interact with the Protection Server component.

Integration Server component

Kaspersky Security for Virtualization Light Agent Integration Server (hereinafter also referred to as the "Integration Server") is an application designed to be installed on a device running the Linux operating system or on a device running a Windows operating system in your infrastructure. The Integration Server facilitates interaction between the Kaspersky Security solution components and the virtual infrastructure.

The Integration Server is used for performing the following tasks:

• Deploying, removing, and reconfiguring SVMs with Protection Servers.
• Receiving information about the protected infrastructure from the virtual infrastructure and sending it to Protection Servers. The Integration Server can connect to hypervisors, virtual infrastructure administration servers, or cloud infrastructure microservices to acquire this information (depending on the type of virtual infrastructure).
• Receipt by Light Agents of a list of SVMs available for connection and information about them. This information is necessary for interaction between Light Agents and Protection Servers on the SVMs.
• Deploying and using the Kaspersky Security solution in multi-tenancy mode.

The Kaspersky Security solution includes:

• An Integration Server designed to be installed on a device with a Windows operating system (hereinafter also referred to as the "Windows-based Integration Server").
• An Integration Server designed to be installed on a device with a Linux operating system (hereinafter also referred to as the "Linux-based Integration Server").

You can use the Integration Server that corresponds to your infrastructure.

To manage the Windows-based Integration Server, you can use the following management consoles:

• Integration Server Console
• Integration Server Web Console

To manage the Linux-based Integration Server, you can use Integration Server Web Console.

We do not recommend using Integration Server Console to manage the Linux-based Integration Server.

You can also manage the Integration Server using the Integration Server REST API without using management consoles (open a description of REST API requests).

To use the Integration Server in the operation of Light Agents and Protection Servers, you need to configure the settings for connecting SVMs and Light Agents to the Integration Server.

After configuring the settings for connecting SVM to the Integration Server, SVM transmits the following information to the Integration Server every 5 minutes:

• IP address and number of ports for connecting to the SVM.
• Information about the SVM path in the virtual infrastructure.
• Information about the license used to activate the solution on the SVM.
• Information about the average load of the Protection Server on the SVM.

A Light Agent attempts to connect to the Integration Server once every 30 seconds if the Light Agent has no information about any SVM and the last attempt to connect to the Integration Server failed. After a Light Agent receives information about SVMs from the Integration Server, the connection interval increases to 5 minutes.

During its operation, the Integration Server saves the following information:

• Internal Integration Server accounts. These accounts are used to connect management consoles, SVMs and Light Agents to the Integration Server.
• Settings for connecting the Integration Server to the virtual infrastructure and the Kaspersky Security Center Administration Server.
• If the solution is used in multi-tenancy mode: a list of registered tenants and information about the time that virtual machines were protected by the solution.
• SVM service data.

All data is stored in encrypted form. Information is stored on the device on which Integration Server is installed and is not sent to Kaspersky.

Management plug-ins and Network Agent

The interface for managing Kaspersky Security solution components using Kaspersky Security Center is provided by Kaspersky Security management plug-ins.

Network Agent, a component of Kaspersky Security Center, facilitates interaction between the Kaspersky Security solution and Kaspersky Security Center, and also provides the ability to manage Kaspersky Security solution components via Kaspersky Security Center.

Network Agent must be installed on each virtual machine that needs to be protected using the Kaspersky Security solution. Network Agent does not need to be installed on SVMs because this component is included in the SVM images.

SVM deployment options

VMware vSphere platform

The following options are available for deploying SVMs on VMware virtual infrastructure:

• Deployment on a standalone VMware ESXi hypervisor managed by a VMware vCenter Server.
• Deployment on VMware ESXi hypervisors that are part of a cluster managed by a VMware vCenter Server.

  After deployment, the SVM is automatically assigned to the hypervisor, i.e. it does not migrate to other VMware ESXi hypervisors within the cluster.

• Deployment on VMware ESXi hypervisors managed by VMware vCenter servers in Linked mode.

If you use Integration Server Console to manage the Integration Server, when deploying SVMs on VMware ESXi hypervisors, you can use the Microsoft SCVMM virtual infrastructure management server. If you use Integration Server Web Console or REST API to manage the Integration Server. Connecting to Microsoft SCVMM is not supported.

XenServer platform

The following SVM deployment options are available on a XenServer virtual infrastructure:

• Deployment on a standalone XenServer hypervisor
• Deployment on a hypervisor that is part of a XenServer hypervisor pool.

  An SVM can be deployed in the local storage of the hypervisor or in the shared storage of a XenServer hypervisor pool.

  After startup, an SVM deployed in shared storage is run on the hypervisor within the XenServer hypervisor pool that has the most resources and/or is under the least load. If a key with a limitation on the number of processor cores key has been installed on an SVM, the number of processor cores on the hypervisor the SVMs are running on is considered when checking the license restrictions.

Microsoft Hyper-V platform

The following options are available for deploying SVMs on Microsoft Hyper-V virtual infrastructure:

• Deployment on a standalone Microsoft Windows Server (Hyper-V) hypervisor.
• Deployment on Microsoft Windows Server (Hyper-V) hypervisors that are part of a hypervisor cluster managed by the Windows Failover Clustering service.

During deployment of an SVM on a Microsoft Windows Server (Hyper-V) hypervisor, all files required for operation of the SVM are stored in a separate folder. This folder is assigned the same name as the SVM.

If you use Integration Server Console to manage the Integration Server, when deploying SVMs on Microsoft Windows Server (Hyper-V) hypervisors, you can use the Microsoft SCVMM virtual infrastructure management server. If you use Integration Server Web Console or REST API to manage the Integration Server. Connecting to Microsoft SCVMM is not supported.

KVM platform

SVM deployment on a standalone KVM hypervisor is supported.

Proxmox VE platform

SVM deployment on a standalone Proxmox VE hypervisor is supported.

Basis platform

SVM deployment on R-Virtualization hypervisors included in a hypervisor cluster managed by a Basis.vControl server is supported.

Skala-R platform

SVM deployment on R-Virtualization hypervisors that are part of a hypervisor cluster managed by a Skala-R Management server is supported.

HUAWEI FusionSphere platform

The following options are available for deploying SVMs on HUAWEI virtual infrastructure:

• Deployment on a standalone HUAWEI FusionCompute CNA hypervisor managed by a HUAWEI FusionCompute VRM server.
• Deployment on HUAWEI FusionCompute CNA hypervisors that are part of a cluster managed by a HUAWEI FusionCompute VRM server.

Nutanix Acropolis platform

The following options are available for deploying SVMs on Nutanix Acropolis virtual infrastructure:

• Deployment on Nutanix AHV hypervisors that are a part of a hypervisor cluster managed by a Nutanix Prism Element server.
• Deployment on Nutanix AHV hypervisors that are a part of a hypervisor cluster managed by a Nutanix Prism Element server that is managed by Nutanix Prism Central.

OpenStack platform, VK Cloud platform, and TIONIX Cloud Platform

SVMs are deployed on hypervisors used within

ALT Virtualization Server platform

An SVM can be deployed on a standalone hypervisor of the ALT Virtualization Server platform.

Astra Linux Platform

SVM deployment on a standalone KVM hypervisor running on the Astra Linux Platform is supported.

Numa vServer platform

SVM deployment on a standalone Numa vServer hypervisor is supported.

Connecting Light Agent to SVM

For the Kaspersky Security solution to function, constant interaction between the Light Agent and the Protection Server is required. If there is no connection to the Protection Server, the Light Agent cannot transfer file fragments to the Protection Server for scanning, and scanning is not performed. If Light Agent loses a connection to the Protection Server for more than 5 minutes while running scan tasks, the scan tasks stop and return an error.

To interact with the Protection Server, the Light Agent establishes and maintains a connection to the SVM on which this Protection Server is installed.

Light Agent can only connect to an SVM whose version is compatible with the Light Agent version.

To connect to an SVM, Light Agent must receive information about the SVMs to which a connection can be made. Light Agent selects an available SVM that is optimal for connection according to the SVM selection algorithm.

Regardless of the algorithm used in selecting SVMs, Light Agents also take into account the following parameters:

• Availability of a valid license (a license key that is not in the denylist is added to the SVM, and the license associated with the key has not expired). Light Agent first connects to the SVM on which the solution is activated (the key is added).
• Type of the license key added to the SVM. If you use a licensing scheme based on the number of virtual machines protected by the solution (server keys and desktop keys), the Light Agent first connects to the SVM on which the key type matches the operating system installed on the virtual machine with the Light Agent.
• Protecting the connection between the Light Agent and the Protection Server. A Light Agent for which connection protection is enabled can only connect to SVMs for which encryption of the data channel between the Light Agent and the Protection Server is enabled. A Light Agent for which connection protection is disabled can only connect to SVMs for which channel encryption is disabled or an unsecure connection between the Light Agent and the Protection Server is allowed.
• SVM connection tags. If a tag is assigned to a Light Agent, the Light Agent can only connect to SVMs that are configured to use that connection tag.

The ability to connect the Light Agent to the SVM also depends on the settings for downloading updates to the SVM, which are specified in the policy for the Protection Server. Only Light Agents for which database updates are downloaded to this SVM can connect to the SVM.

Keep in mind that the scope of functionality available on the Light Agent depends on the license under which the solution is activated on the SVM:

• If you want to use the Light Agent functionality included in the Enterprise license, you need to connect the Light Agent to a SVM on which the solution is activated under the Enterprise license. When connecting to an SVM on which the solution is activated under a Standard license, less functionality is available on the Light Agent.
• If you want to use additional Light Agent functionality (for example, integration the Kaspersky Detection and Response solution or integration with Kaspersky Unified Monitoring and Analysis Platform), you need to connect the Light Agent to an SVM on which the solution is activated under a license that includes this additional functionality, or to an SVM for which a separate license key for activating the additional functionality has been added. When a Light Agent is disconnected from the current SVM and connects to an SVM on which additional functionality has not been activated, the functionality becomes unavailable on the Light Agent.

To prevent Light Agents from switching between SVMs with different license types, you can use connection tags or a list of SVMs available for connection to limit the number of SVMs available to a Light Agent.

You can get information about the status of the Light Agent's connection to the SVM in the following ways:

• For Light Agent for Linux: using the Kaspersky Endpoint Security for Linux command kesl-control --svm-info. For details, see the Kaspersky Endpoint Security for Linux Help of the relevant version.
• For Light Agent for Windows:
  • in the local interface of Kaspersky Endpoint Security for Windows
  • using the Kaspersky Endpoint Security for Windows command avp.com SVMINFO.

  For details, see the Kaspersky Endpoint Security for Windows Help of the relevant version.

The lack of a connection between Light Agent and an SVM is communicated in Kaspersky Security Center through the status of the host device: if the connection to an SVM is not established, the status of the protected virtual machine changes to Critical. Information about the loss and restoration of the connection of the Light Agent and SVM is saved as events in Kaspersky Security Center.

We do not recommend using live snapshots of virtual machines taken on a running guest OS for SVMs and virtual machines with Light Agent for Linux installed. Restoring from such snapshots results in loss of the connection between Light Agents and the SVMs and degrades the performance of the virtual infrastructure. You can use virtual machine snapshots taken on a running guest OS only if the "Notify only" mode is enabled in the Light Agent settings. For details, see the Kaspersky Endpoint Security for Linux Help of the relevant version.

About SVM discovery

Light Agent can discover SVMs running on the network in one of the following ways:

• Using the Integration Server. SVMs relay information about themselves to the Integration Server. The Integration Server compiles a list of SVMs available for connection, and sends this list to Light Agents.

  In a large-sized virtual infrastructure running the OpenStack platform, VK Cloud platform, or TIONIX Cloud Platform, you can limit the size of the list of SVMs available for connection that the Integration Server relays to Light Agents. The Integration Server can transfer information only about the limited number of available SVMs, which you specified in the Integration Server configuration file.

  To use this method of SVM discovery, you must connect SVMs and Light Agents to the Integration Server.

• With the use of the list of SVM addresses. You can specify a list of SVM addresses to which Light Agents can connect.

If the extended SVM selection algorithm is used for the Light Agent, and large infrastructure protection mode is enabled on the SVMs, it is recommended to select the Integration Server as the method for Light Agents to discover SVMs.

Each Light Agent can only use one of two possible SVM detection methods.

You can configure SVM detection settings for Light Agents in the following ways:

• For Light Agent for Linux: in the policy for Kaspersky Endpoint Security for Linux
• For Light Agent for Windows:
  • in the policy for Kaspersky Endpoint Security for Windows
  • in the local interface of Kaspersky Endpoint Security for Windows

About the SVM selection algorithms

Light Agents can apply one of the following SVM selection algorithms for connection:

• A standard SVM selection algorithm

  If this algorithm is applied, after installing and running on a virtual machine, the Light Agent selects an SVM to connect to that is local to Light Agent.

  SVM locality relative to Light Agent is determined depending on the type of virtual infrastructure:

  • In a virtual infrastructure based on Microsoft Hyper-V, XenServer, VMware vSphere, KVM, Proxmox VE, Basis, Skala-R, HUAWEI FusionSphere, Nutanix Acropolis, Alt Virtualization Server, Astra Linux, or Numa vServer, the SVM that is considered to be local to a Light Agent is the SVM that is deployed on the same hypervisor as the virtual machine with the Light Agent installed.
  • In a virtual infrastructure running on the OpenStack platform, VK Cloud platform, or TIONIX Cloud Platform, you can specify how SVM locality relative to the Light Agent is determined using the StandardAlgorithmSvmLocality parameter in the HypervisorSpecificSettings:Openstack section in the Integration Server configuration file appsettings.json. Depending on the version of the Integration Server, the file is located at one of the following paths:
    • /var/opt/kaspersky/viis/common/ for the Linux-based Integration Server
    • %ProgramFiles(x86)%\Kaspersky Lab\Kaspersky VIISLA\ for the Windows-based Integration Server.

    The StandardAlgorithmSvmLocality parameter can take the following values:

    • ServerGroup – if this value is selected, SVM is considered local for Light Agent if it is located within the same server group as the virtual machine where Light Agent is installed. This value is used by default.
    • Project – if this value is selected, SVM is considered as local for Light Agent if it is deployed within the same OpenStack project as the virtual machine with the installed Light Agent.
    • AvailabilityZone – if this value is selected, SVM is considered as local for Light Agent if it is located within the same availability zone as the virtual machine with the installed Light Agent.

  If there are no local SVMs for connection, Light Agent selects a SVM with the lowest number of Light Agent connections regardless of SVM path in the virtual infrastructure.

  The application does not determine whether the SVM is local relative to the Light Agent if large infrastructure protection mode is enabled for the Protection Server on the SVM. In this case, it is recommended to use the extended SVM selection algorithm and select the Integration Server as the SVM discovery method.

• An extended SVM selection algorithm

  If this algorithm is applied, you can define the following SVM selection settings:

  • whether to consider or ignore the SVM location in the infrastructure when choosing SVMs for connection
  • if the SVM location is considered, how to determine the locality of SVMs relative to the Light Agent.

  If Light Agents ignore the location of SVMs in the infrastructure, Light Agents will be able to connect to any SVMs available for connection.

  If Light Agents must consider the location of SVMs in the infrastructure, you need to select the SVM path type that will be considered when determining the SVM locality relative to the Light Agent. SVM locality relative to Light Agent is determined differently depending on the virtual infrastructure.

  In a virtual infrastructure based on Microsoft Hyper-V, XenServer, VMware vSphere, KVM, Proxmox VE, Basis, Skala-R, HUAWEI FusionSphere, Nutanix Acropolis, Alt Virtualization Server, Astra Linux, or Numa vServer, an SVM can be considered local for the Light Agent in any one of the following cases:

  • The SVM is deployed on the same hypervisor as the virtual machine with the installed Light Agent.
  • The SVM is deployed on the same hypervisor cluster as the virtual machine with the installed Light Agent.
  • SVM is deployed in the same data center as the virtual machine with the installed Light Agent.

  In a virtual infrastructure running on the OpenStack platform, VK Cloud platform, or TIONIX Cloud Platform, an SVM can be considered as local for Light Agent in one of the following cases:

  • The SVM is located in the same server group as the virtual machine with the installed Light Agent.
  • The SVM is deployed within the same OpenStack project as the virtual machine with the installed Light Agent.
  • The SVM is located in the same availability zone as the virtual machine with the installed Light Agent.

  If Light Agents consider the location of SVMs in the infrastructure when choosing which SVM to connect to, Light Agents can only connect to SVMs that are local.

  For example, if you specify hypervisor cluster as SVM path type, all SVMs deployed on this hypervisor cluster will be considered as local for Light Agent, and Light Agent can connect only to one of this SVMs. If there are no SVMs available for connection in the same cluster in which the Light Agent is running, the Light Agent does not connect to an SVM.

  When selecting SVMs, Light Agents also consider the number of connected Light Agents to ensure that Light Agents are evenly distributed among SVMs available for connection.

  If a Light Agent uses the extended SVM selection algorithm, a list of SVM addresses is selected as the SVM discovery method, and large infrastructure protection mode is enabled on an SVM, then connecting a Light Agent to this SVM is only possible if the SVM path is ignored.

You can specify which SVM selection algorithm the Light Agents will use, and configure the settings for using the extended SVM selection algorithm.

About data processing

During their operation, Kaspersky Security solution components may save and send to other solution components and to other Kaspersky applications the following information that may contain personal and confidential data:

• While deploying the SVM and editing SVM settings, the SVM Management Wizard or the Integration Server (also when using the Integration Server REST API) send the root and klconfig passwords configured by the user to the SVM.
• To make the installation and operation of the solution possible, the SVM Management Wizard and the Integration Server (also when using the Integration Server REST API) receive information about the virtual infrastructure, save it, and transmit it between each other and to the Protection Server. The transmitted data can contain names of the virtual machines, IP-addresses or names of the hypervisors, virtual infrastructure administration servers, or cloud infrastructure microservices, as well as account settings for connecting to virtual infrastructure.
• The Protection Server sends the Kaspersky Security Center Administration Server a list of Light Agents connected to the SVM. The transmitted information may include the name of the protected virtual machine, the BIOS ID of the protected virtual machine, and the path to it in the virtual infrastructure.
• The Integration Server Console sends the Integration Server the data necessary for configuring the solution's operating settings. The transmitted data can contain addresses of hypervisors, virtual infrastructure administration servers, or cloud infrastructure microservices, as well as account settings for connecting to virtual infrastructure. If the solution is installed in an infrastructure managed by a VMware vCenter Server and VMware NSX Manager, the address and settings of the accounts used to connect to VMware NSX Manager may also be sent.
• Light Agent sends the following data to the Protection Server:
  • To activate the Light Agent: the validity term of the license key status confirmation; the ID (BIOS ID) of the protected virtual machine; information about the license that the Light Agent needs to work.
  • To update the Light Agent databases: software identifier obtained from the license; full version of the software; software license identifier; software installation identifier (PCID); processed web address; license type; identifier of the update start.
  • To provide protection, while scan tasks are running: information that is necessary for scanning objects. The transmitted information may include the names of files and paths to them in the file system, the checksums of files, web addresses, and the scanned objects or their fragments.
  • To obtain statistics: OS version of the protected virtual machine; localization of the Light Agent; names of the active Light Agent components; ID (BIOS ID) of the protected virtual machine.
• To get information that is used when selecting an SVM for connection, the Light Agent sends the identifier of the protected virtual machine to the Integration Server and the Protection Server.
• In an infrastructure managed by a VMware vCenter Server and VMware NSX Manager, Light Agents and the Protection Server may send the Integration Server information about security tags that are assigned to a protected virtual machine upon detection of viruses, malware, or activity that is typical of network attacks. The IDs of protected virtual machines are also sent.
• The Protection Server and Light Agent receive the operating settings specified using policies from the Kaspersky Security Center Administration Server. The transmitted information may include the paths to files and registry keys, web addresses, IP addresses of the Integration Server and SVMs, settings for connecting SVMs and Light Agents to the Integration Server, public and private keys of SVMs, and the public key of the Integration Server.
• When using the solution in multitenancy mode, the Integration Server receives information about tenants and their virtual machines via the Integration Server REST API and stores it in the database. The following data may be sent: tenant name, identifier, and description, and other information about the tenant specified by the service provider's administrator; identifier of a tenant's virtual machine; account settings for connecting to a virtual Kaspersky Security Center Administration Server configured for the tenant; identifier of virtual Kaspersky Security Center Administration Server. The Integration Server may send information stored in the database about tenants and tenant virtual machines to the Integration Server Console for display or upon request to the Integration Server REST API.
• When using the solution in multitenancy mode, the information necessary for generating tenant protection reports may be sent to the Protection Server from Light Agents, and from the Protection Server to the Integration Server. The following may be transmitted: IDs of the SVM and the protected virtual machine, time periods when the Light Agent was connected to the SVM.
• When using the application in multitenancy mode, the Integration Server sends to Kaspersky Security Center Administration Server the information required to create a tenant protection infrastructure: tenant name, account settings for connecting to the virtual Kaspersky Security Center Administration Server, and operating settings specified using policies, including IP addresses of the Integration Server and SVMs.
• During the execution of tasks, the Protection Server and Light Agent send information about the task settings and results to the Kaspersky Security Center Administration Server. The transmitted information may include the user name and password indicated in the task settings for the user account used to run the task.
• To generate reports and events, the Protection Server and Light Agents send information about the operation of the solution to Kaspersky Security Center Administration Server. The transmitted information may include user names, names of processed files and paths to them in the file system, and processed web addresses.
• While activating the solution, the Protection Server receives from the Kaspersky Security Center Administration Server and saves license information, including information about the client to which the license was issued, and the number of the license specified in the license certificate. After activation, the Protection Server sends to the Kaspersky Security Center Administration Server information about the license that was used to activate the solution; this is done to keep track of license limits and generate a report about license key usage. The Protection Server also sends information about the license that was used to activate the solution to the Light Agent, this is done to activate the Light Agent.

For a description of the data that applications running in Light Agent mode can transmit to other Kaspersky applications, see the Help for the relevant application.

The specified information is transmitted over encrypted data channels (except for the information necessary for scanning objects, and the information that is used when selecting SVMs). The connection between Light Agents and Protection Servers is not encrypted by default. You can enable encryption of the data channel between the Light Agents and the Protection Servers in the solution settings.