# Install and configure the Security Audit 3.0 or 2.4.1 module > [HTML Version](audit-module-settings.html) After completing the preliminary configuration for [Security Audit 3.0](security-audit-3.md) or [Security Audit 2.4.1](install-audit-service.md), you can proceed with installing the required module. To do this: 1. [Install the required module version](#settings-audit-service). To get the installation file, please contact your BRIX sales rep. 2. [Configure the downloaded module](#module-settings). ## Step 1: Download the module 1. Go to **Administration > Modules **and in the upper right corner, click **+Module**. 2. In the window that appears, choose the **Download** option. In the BRIX Store catalog, select the **Security Audit** module and click the **Install Module** button. ```` начало примечание ```` **Note** BRIX Store will be available soon. Please contact your sales rep to request the installation file and [upload](upload-solution-file.md) it. ```` конец примечание 3. ```` In the window that appears, click **Next**. Wait for the module to finish loading into the system. Installing a module in a closed environment without internet access To install a module in a closed environment without internet access, first download the module file on a computer with an internet connection. Then install the downloaded file. To do this: 1. In the **Administration > Modules** workspace, click the **+ Module** button in the upper right corner. 2. In the window that appears, click **Upload File** and select the file. 3. Click **Next**. Wait for the module to install into the system. ## Step 2: Set up the module 1. Go to the installed module and fill in the the main settings: **(Security-audit-2.png)** - **The Audit service address**. The field is available and filled in when using the **Security Audit 2.4.1** module. Enter the URL address of the Security Audit service. The default value when installed inside the BRIX cluster is **http://audit.audit.svc:3000**. - **Users with access to the audit widget**. Select the employees who will have access to the table with the audit result. The table is displayed in the **Security Audit** widget. The widget is placed on a separate page that is visible to all users. At the same time, only [administrators](360006871932.md#administrators) can view the widget data. The option will allow selected employees to work with the audit result without having other administrator rights. 2. [Set the secrets settings](#secrets) to define a list of apps with sensitive information. Events on the items of such apps will be logged, but users will not see the values of their fields in the **Security Audit** widget. 3. [Enable event archiving](#archive) to move outdated data to temporary and long-term archives. This will optimize the search for events in the **Security Audit** widget. 4. To save space in the event database, you can disable extended logging. This will reduce the amount of information stored for the following actions: - Creating or deleting an app item, or adding a comment to its associated activity stream—the event page does not record the item's contents, so the **Event data** field remains empty. - Updating an app item—the event page records only changed field values, not all the item's data. 5. Save the changes. After installing the module, the **Security Audit** widget will be available in the [interface designer](interface_designer.md). For more information on placing the widget and working with it, read the [Security audit report](audit_extension.md) article. ### Configure secrets By configuring secrets, you can mark apps that contain confidential information. All data from items in such apps will not be displayed in the registered events. Confidential information includes: - Trade secrets. - Personal data. - Medical secrets. For example, specify in the module settings that confidential information is stored in the **Contractors** app. As a result, on the page with security audit data, users will not be able to view the properties of items for which events are logged. To configure secrets, follow these steps: 1. On the settings page of the **Security Audit** module, fill out the table: **(Security-audit-1.png)** - **App\***. Enter the app URL storing confidential information, in the \[OBJECT\] format. For example, if the full URL address of the app is \[OBJECT\], you should enter \[OBJECT\] in the field. - **Secret\***. Click on the input field and from the drop-down list select what information is contained in the app. **PD** is for** **personal data, **TS**, for trade secrets, and **MS**, for medical secrets. You can specify multiple types of secrets in one field. 2. Save the changes. After saving the settings, all fields from the listed apps will not be displayed in the detailed information on logged events. ### Configure archiving of events You can enable archiving of old events in the **Security Audit** service. This will speed up the search when users want to find events in the table with registered records. Events will be stored in the database as follows: - **Operational storage**. Contains recent events. The period of their placement is defined in the module settings. By default, users search for these data in the **Security Audit** widget. - **Temporary archive**. These are events moved from the operational storage. The data remain here for one year. To search for archived events in the **Security Audit** widget, users need to enable a special option. - **Long-term archive**. These are outdated events from the temporary archive. Such data are not searchable. Events are not automatically deleted from the archive. Users with access to the database can clear the archive manually for new events. ```` начало внимание ```` Once event archiving is enabled in the **Security Audit** module settings, the option cannot be disabled. ```` конец внимание ```` Follow these steps: 1. On the settings page of the **Security Audit** module, activate the **Enable archiving of events\*** option. **(Security-audit-3.png)** 2. In the **Period for storing recent events\*** field, specify the number of months after which the data are moved to the temporary archive. The maximum value is 12 months. 3. Save the changes. ## Registered events Below is the list of events registered by the security audit in different system components. ### Users 1. Successful and failed authentication, user logout from the system. 2. User creation. 3. User deletion. 4. User update. 5. User status change. 6. User locked by administrator. 7. User locked after exceeded number of password attempts. ### Apps 1. App item creation. 2. App item deletion. 3. App item update. 4. App item status change. 5. Changing the access permissions for an app item. 6. Viewing the app item page. 7. Adding a comment to an app item. 8. App data import. 9. App data export. ### Files 1. File creation. 2. File deletion. 3. File update. 4. File download. 5. File view. 6. Access permissions for the file are changed. 7. A comment is added. ### Directories 1. Directory creation. 2. Directory deletion. 3. Directory update (renamed or moved). 4. Access permissions for the directory are changed. ### Tasks and CRM Tasks 1. Task creation, update, cancellation, and completion. 2. CRM task creation, update, cancellation, and completion. ### Modules 1. Module enabled. 2. Module disabled. 3. Module installed. 4. Module updated. 5. Additional parameters change. 6. Secrets are set up in the **Security Audit** module. 7. Access to the **Security Audit** module. 8. Changing the operational event storage period. 9. Starting the event archiving operation. 10. Starting the operation of transferring operational events to a temporary archive. 11. Starting the event data clearing. 12. Enabling and disabling extended logging.