Implemented Information Security Measures in the System

Authenticating Users in the System

User authentication can be performed in several ways:

1. By using a login and a password defined in the system. The system compares the hash of the password you enter for the specified login with the password hash stored in the database. On first sign-in, set your own password.
2. By integrating with Active Directory.
3. By using the SAML protocol.
4. By using the Kerberos protocol.
5. By using the OpenID protocol.

Protected System Objects

The protected objects are listed below.

• Security logs stored in log files:
  • On Windows — C:\ProgramData\Operavix\logs
  • On Linux — in the container /var/log/operavix
• User authentication information stored in the database:
  • On Windows — C:\ProgramData\Operavix\database
  • On Linux — in the container /var/lib/operavix/data/databases
• Configuration files stored in the database:
  • On Windows — C:\ProgramData\Operavix\database
  • On Linux — in the container /var/lib/operavix/data/databases
• Access rights stored in the database:
  • On Windows — C:\ProgramData\Operavix\database
  • On Linux — in the container /var/lib/operavix/data/databases
• Permission and audit mechanisms stored in the database:
  • On Windows — C:\ProgramData\Operavix\database
  • On Linux — in the container /var/lib/operavix/data/databases
• Executable files stored in the directory:
  • On Windows — C:\Program Files\Operavix
  • On Linux — /usr/sbin/operavix/
• Web interface assets stored in the directory:
  • On Windows — C:\Program Files\Operavix
  • On Linux — /usr/sbin/operavix/

Protect the following directories at the operating system level:

• C:\Program Files\Operavix
• C:\ProgramData\Operavix
• Docker service: operavix-clickhouse
• Docker volume: operavix-clickhouse

Enforcing User Password Security

You can configure password parameters for built-in authentication in the web interface: Settings/Authentication/Authentication Name.

Complex Password

Password security checking includes the following restrictions when you create or change a password:

• Uppercase letters: A to Z
• Lowercase letters: a to z
• Digits: 0 to 9
• Non-alphabetic characters: for example, !, $, #, %
• Password length
• Password reuse restriction

The system checks these requirements when passwords are created or changed. The system does not check whether the password contains characters from the user’s email address.

Minimum Password Length

You can configure the minimum password length only if the Complex password setting is enabled. This parameter specifies the minimum number of characters allowed when creating or changing a password. Allowed values: from 8 to 15 characters.

If the Complex password setting is in the state Off, the default minimum length is 4 characters. You can also view this setting in the web interface at the path above.

Password Expiration

The Password expiration (days) parameter sets the password lifetime starting from the moment it is created or changed. Allowed values: from 1 to 1000 days. After the period ends, the system prompts the user to set a new password. Access to the system is restricted until the user sets a new password. To make the password validity unlimited, leave the parameter empty.

If the Complex password setting is in the state Off, the user can reuse previously used passwords, except for the most recently set password.

If the password has not expired and the user changes the password to the same value that is currently set, the expiration counter is not reset. If the user changes the password to a different value before expiration, the counter resets and the period starts according to the defined parameter.

Encrypting Passwords

The system uses AES-256 for password encryption. AES is a symmetric block cipher (block size of 128 bits; key length of 128/192/256 bits).

During system initialization, a 256-bit key is created and, by default, stored in the following locations:

• On Windows — C:\ProgramData\Operavix\secret_key. The path is taken from the configuration file subsystem.core.json, which is located at C:\ProgramData\Operavix\config\com.operavix
• On Linux — in the container /var/lib/operavix/data/secret_key

The key is used to encrypt and decrypt stored passwords.

AES-256 password encryption is used:

• When integrating with Active Directory
• When connecting to the ClickHouse database
• When creating connections in a space

Encryption is also available for passwords of trusted certificates and their stores:

1. Provide --password and --secret_key_path arguments with the password and the path to the secret_key encryption key.
2. In the com.operavix.subsystem.frontend.json file, replace the ssl_cert_store_password and trust_store_password parameters with their encrypted versions: encrypted_ssl_cert_store_password and encrypted_trust_store_password.
3. Replace the password values in the parameters with the values obtained in the console.

After you save the changes, the passwords are stored in encrypted form.

Hashing User Passwords

The password the user enters is not sent to the server in cleartext. The system hashes the password with the SHA256 algorithm.

The server receives the password hash, applies the hash function again, and derives a secret key using PBKDF2 (PBKDF2WithHmacSHA512). The server stores two values in the database as a secret key: Salt + Hash (computed from the received password hash). You can also view this setting in the web interface at the path above.

Sign-in Attempt Limit

The Sign-in attempt limit parameter sets how many times a user can attempt to sign in to the system. Allowed values: from 1 to 100. An attempt occurs when the user enters a correct login, enters an incorrect password, and clicks Sign In.

When the number of attempts reaches the configured value, the user account is blocked, and access to the system is restricted. To remove the limit on the number of sign-in attempts, leave the parameter empty.

By default, the period after which the user’s sign-in attempts are reset is 10 minutes. If the interval between attempts is no more than 10 minutes, the attempts are considered consecutive (1, 2, 3, 4, etc.), and the account is blocked when the configured limit is reached. When 10 minutes pass, the counter resets.

You can change this period through the configuration file on Windows only. To change the reset period:

1. Go to: C:\ProgramData\Operavix\config.
2. Open the configuration file: operavix.subsystem.core.json.
3. Change the parameter value: reset_count_invalid_logon_duration (you can specify days, hours, minutes, and seconds).

Password Reset Link Lifetime

If a user forgets a password, they can reset it by email. The message is sent if the outgoing mail server is configured in the Operavix system. The email contains a link that allows the user to create a new password according to the password policy settings. By default, the Password reset link lifetime parameter is 1 day (24 hours). You cannot change this parameter through the web interface. You can change the period through the configuration file on Windows only.

To change the period:

1. Open the folder: C:\ProgramData\Operavix\config.
2. Open the configuration file: com.operavix.subsystem.core.json.
3. Change the restorelink_timeout parameter (you can specify days, hours, minutes, and seconds).

Inactive Session Lifetime

By default, the inactive session lifetime for each user is 1 week (7 days). You cannot change this parameter through the web interface. You can change the period through the configuration file on Windows only.

To change the period:

1. Open the folder: C:\ProgramData\Operavix\config.
2. Open the configuration file: com.operavix.subsystem.fronted.json.
3. Change the session_timeout parameter (you can specify days, hours, minutes, and seconds).
4. Restart the operavix service.

Identification and Authentication of Subjects and Access Objects

All users and software processes are subject to identification, authentication, and authorization. A user who fails authentication is not granted access to the system. The system includes mechanisms for managing user accounts: creating, activating, blocking, granting and changing permissions, and so on.

Managing system components requires its own authorization. The following requirements apply:

• Upon sign-in, the system identifies and authenticates access subjects.
• Password hashes and identifiers are transmitted only over the network and stored in encrypted form.
• It is impossible to change a password by replacing the object that stores the encrypted password.
• You can set the minimum password length (at least 8 characters) and password validity period (password policy).
• You can set the password complexity level (password policy).
• You can prohibit password reuse (password policy).
• Users can change their own passwords.
• System administrators cannot access user passwords.
• The system monitors and counts all sign-in attempts (successful or unsuccessful, i.e., unauthorized).
• The system notifies the user when the number of failed sign-in attempts is exceeded. After exceeding the configured number of failed attempts, access is denied. When entering the correct password, the user is not informed that the password is correct.
• The system allows the user to manually block their own session.

Blocking System Users

User accounts can be blocked in the following ways:

1. Through the web interface: Settings/Employees/Employee Profile. In the Access tab, in the Authentication parameter of the required employee, remove active authentication entries.
2. Through mass assignment: For users whose access should be restricted, use the mass assignment function to select Authentication and disable active authentications. Save your changes.
3. By using a GraphQL request to block the account from an external system. Send the following request:

mutation {
    employee {
        set_authentication(target_employee_ids:[id],
         authentication_ids:[])
    }
}

Where id is the user ID.

Once a user is blocked, they are immediately disconnected from the system and their current session is terminated. On each new sign-in attempt, the user must re-enter authentication credentials.

Blocking Users from an External System

To automatically disable users from an external system, you must have an API Key with the required permissions. To block system users from an external system, execute the following requests:

<http://127.0.0.1:8010/graphql?query={employee{employees{id,login}}}&api_key=826ac84312a0481ea57cc160fd1b59dc>

Where 127.0.0.1:8010 is the server address, and 826ac84312a0481ea57cc160fd1b59dc is the API Key.

Use the following request to determine the user ID in the system:

Where localhost:8093 is the server address, fd7dbbf252fd43daad15628989d5eb0a is the API Key, and id is the unique ID of the specific user.

After determining the ID, proceed to block the employee.