SUBJECT TO CHANGE
Please note this is an evolving service, with specifications subject to change in future. This document will be maintained based on any future specification changes that pertain to the sections in this document, (i.e. Microsoft Azure Storage Services Specification Changes by Microsoft).
At the time of writing Azure Storage is the only supported Storage Framework for Luware Recording.
Supported Azure Storage Targets
This section details the types of Storage and Storage Settings supported by Luware Recording. This section assumes that you are familiar with the concepts of Azure Storage account services.
Luware Recording requires that you create your own Azure Storage Account for the storage of your recordings. Luware only supports blob containers for the secure upload and "data at rest" storage of recordings. File, Queue and Table Azure storage services is not supported.
Connecting to the Customer Storage
Azure Private Endpoints are the recommended method to be used to access the customer storage by Luware. This method of connectivity to your Azure storage makes use of a dedicated private IP Address for communication towards your Azure Storage Account. Public IP Routing is not used in this method and therefore the data does not go over the public internet.
You will need to provide the resource ID of the Azure Storage Account, and approve the request once the private endpoint is provisioned in Luware Recording. Note that Cross Tenant VNET Peering is not required for this type of deployment.
Mutli-Tenant Germany
NOTE
Please note that while this connectivity provides a more secure connection to your Azure Storage accounts, it will not provide any resiliency in the event Azure region Germany West Central experiences a failure.
Luware Recording Germany is deployed into Germany West Central and Germany North.
The Luware recording services in Germany North will cache the recordings until Germany West Central is back online at which point the recordings will be uploaded to the customers Azure Storage account via the private endpoint in Germany West Central.
Please see supported regions for Private Link services from Microsoft:
Multi-Tenant Switzerland
NOTE
Please note that while this connectivity provides a more secure connection to customers Azure Storage accounts it will not provide any resiliency in the event Azure region Switzerland North experiences a failure.
Luware Recording is deployed into Switzerland North and Switzerland West.
The Luware recording services in Switzerland West will cache the recordings until Switzerland North is back online at which point the recordings will be uploaded to the customers Azure Storage Account via the Private Endpoint in Switzerland North.
Please see supported regions for Private Link services from Microsoft:
There is no need to configure Firewall Access Control Lists for Luware Recording IP addresses and/or VNETs against the customer Azure Storage Account. However, it is recommended to restrict access.
The private endpoint uses an IP address from the dedicated Private Endpoint Luware Recording VNet address space. Network traffic between the Luware Recording VNet and your storage account traverses over the VNet and a private link on the Microsoft backbone network, eliminating exposure from the public internet.
The Private Endpoint created will be approved by you to only allow access from the Luware Private IP Address space hosted in the Azure VNET.
🔍 Also see Azure Storage Private Endpoints.
Azure Storage Account Creation Guidance
The following sections provide guidance on how to create the Azure Storage Account. For any Azure Storage specific queries not covered in the following sections, refer to your Azure Storage specialist for further advice.
Basics
This section refers to the initial input values requested by Azure Portal for the initial creation of the Azure Storage Account.
Project Details
Field | Value |
---|---|
Resource Group | <Chosen Customer Resource Group> |
Subscription | <Chosen Customer Subscription> |
Instance Details
Field | Value |
---|---|
Storage Account Name | <Chosen Name of Customer Storage Account> |
Region | <Chosen Region of the Customer Storage Account> |
Redundancy | <LRS or GRS>* |
Performance | <Standard or Premium>** |
* Read Only GRS is not supported.
** If Premium is chosen, only Block Blobs are supported.
Advanced
Security
Field | Value |
---|---|
Require secure transfer for REST API operations | Enabled |
Enable Storage Account Access Key | Enabled |
Default to Azure Active Directory auth in the Azure Portal | Disabled |
Min TLS Version | Version 1.2 |
Hierarchical Namespace
Field | Value |
---|---|
Enable hierarchical namespace | Disabled |
Blob Storage
Field |
Value |
---|---|
Enable network File Share v3 | Disabled (Not Used for Blob) |
Access Tier | <Hot or Cold>*** |
*** The access tier settings is your choice, however, the information below may assist in the your decision making process on this element of storage settings.
- Hot - Data is kept on performance disks and is not subject to any conditions, this data meant for being constantly accessed frequently once written to disk.
- Cold - Data that is kept for a minimum of 30 days on Cold Storage will benefit from lower cost overheads, however the tradeoff is that this data is classified as “infrequently accessed data” and moved to lower tier of storage performance in Azure. If the expectation is that the call recordings will be accessed infrequently for the duration of the recording service, then this can be an option to consider.
In most cases Cold Tier storage will suffice as playback, export, etc., of recorded conversations at rest is usually only performed during legal discovery cases, and/or periodic checks in Azure Storage.
🔍 Also see Blog Storage Tiers.
Azure Files
Field |
Value |
---|---|
Enable large file shares | Enabled (Can't be disabled) |
Networking
Network Connectivity
Field |
Value |
---|---|
Connectivity method | Private Endpoint* |
* The options here are:
- Enable public access from all networks
- Enable public access from selected virtual networks and IP addresses
- Disable public access and use private access.
The option chosen here pertains to the very first section in this document which discusses the creation of the private link endpoint for connectivity to your Azure storage. We recommend choosing the 2nd or 3rd option. The Private Link Endpoint will be created later on by COPS and must not be configured at creation.
Virtual Networks
Leave this as default (unless you have other VNETs that requires access to this storage account).
Network Routing
Field |
Value |
---|---|
Routing Preference | Microsoft network routing |
Data Protection
The Version-Level Immutability Support feature provides additional protection for your files by leveraging Azure's retention policies. Here’s what happens when the checkbox to enable this feature is selected:
- File Locking: When enabled, Luware Recording will lock the uploaded file versions on Azure by applying an Azure Retention Period.
- Retention Period: During the retention period, the locked version of the file:
- Cannot be deleted or modified, even by an Azure Admin.
- Remains immutable until the retention period expires.
This ensures that your files are protected against accidental or intentional deletion, providing compliance and data integrity.
Important Note: Once a file version is locked, it is not editable or removable until the specified retention period ends. Ensure you understand the implications before enabling this feature, as even administrators cannot overwrite the immutability during the retention period.
For more detailed information on Azure's retention policies and immutability, refer to the official Microsoft documentation.
Field |
Value |
---|---|
Enable versioning for blobs | Enabled (must be enabled if “Enable version-level immutability support” is checked) |
Enable version-level immutability support | Enabled (if you want the file to be immutable in Azure as well) |
Encryption
Field |
Value |
---|---|
Encryption type | Microsoft-managed key (MMK) |
Enable support for customer-managed keys | Blobs and files only |
Enable infrastructure encryption | <Customer choice> |
Enable support for customer-managed keys | Disabled (Not used for Blob) |
Storage Capacity Calculations
Depending on the number of recorded users, the number of recorded conversations per average working day, and the retention settings of data at rest (i.e. delete after 30 days), will directly affect the sizing considerations that needs to be made for the Azure Storage Account created for this service.
The information below is intended to aid the customer in storage sizing estimations and cost estimations of per GB consumed in Azure.
- Luware Recording stores all recorded Audio Conversations as GSM-FR Codec.
- Luware Recording stores all recorded Video and Screen Share conversations as a proprietary Verba codec (VMF).
- Luware Recording stores all file attachments in their native format and have the same file size as in the moment they are sent.
- A single Audio Call lasting one hour will equate to around 5.5 MB of storage space.
- A single Video/Screen Sharing call lasting one hour will equate to 1.05 GB.
Based on the data at rest storage figures above, this can then be used to calculate the needed overall storage space requirements.
Multi-Tenant Germany
It is important to note that Luware Recording is 2N, this means the above calculations will need to be doubled to account for the primary and secondary recordings of each conversation recorded. This does not apply to chat and attachment recording which are 1N.
Encryption and Signing
Luware Recording natively encrypts and signs all recorded conversations files before uploading them to the customer's Azure Storage Account. This is done using a certificate and private key installed on the Luware Recording infrastructure which will be used for encryption and signing of every conversation. As the encryption of the records is done natively within Luware Recording, this ensures that the records are encrypted in transit and at rest.
Luware recommends that the customer provides their own certificate. This ensures that the customer's records are encrypted and signed using their own certificate, and can easily be decrypted outside of Luware Recording if necessary. Luware will require the certificate and private key in order to encrypt all calls. The customer's certificate and private key will be stored within Luware Recording securely. This certificate will then be used to encrypt and sign files as they are uploaded to the customers Azure Storage, as well as decrypt and verify the files during playback.
The certificate requirements are as follows:
- Certificates must have RSA keys (512, 1024, 2048, 4096)
- Supports SHA-512 and SHA-256
- Certificates used for encryption and signing must be valid, not expired or revoked
- All certificates used at any time (even if expired) must be available to provide decryption and validation for any recording
- Certificates for encryption must have a private and a public key
- The Private Key MUST be marked as Exportable
KEEP CERTIFICATES
Certificates, even if expired, must be kept permanently for decryption. If the private key is removed, files will not be decryptable anymore.
Please note: SHA-512 is used for the digest for encryption and RSA is used for the signing of the files (please note RSA Key length is governed by the issuing certificate authority).
The playback and read of the encrypted conversations is performed via the Luware Recording Web Portal. When a user signs in and requests the playback of a record, Luware will request the download of a copy of the record from the customers storage target, the conversation will be downloaded and decrypted within Luware Recording and presented for playback to the user. Luware Recording will temporarily cache the downloaded records, but these will be deleted from Luware Recording, but remain in the customers storage target.
Should the customer not wish to use their own certificate, Luware can create a Luware signed certificate for the encryption and signing of all the records. This will mean that the customer has no access to the certificate or public keys, however at additional service fees, Luware can decrypt the files stored on a customer’s storage in the event they need to be played back/read using a 3rd party tool.
Customer Azure Storage Details
In order for Luware Recording to upload the records to your storage target, the below information is required from your storage account:
- Azure Storage Account Name
- Azure Storage Blob Container Name
- Azure Storage Account Access Key #1
- Azure Storage Resource ID
These details are required so that Luware Recording can securely upload and download the records to/from your storage target. As some of the required information is sensitive, please arrange with your point of contact at Luware a method to securely transfer this information. The Storage Access Key will only be stored in encrypted format in Luware Recording and will not be stored in plain text anywhere within Luware.
Should you rotate the Storage Account Access keys, please inform Luware Support of the new key before the provide key expires.
Luware Support
INC Luware Support Address
Website https://luware.com/support/ Helpdesk https://helpdesk.luware.cloud Servi
Luware Website | https://luware.com/support/ |
---|---|
Luware Helpdesk | https://helpdesk.luware.cloud |
Cloud Service Status | https://status.luware.cloud/ |