Security management
This page describes important security consideration for the Content Software for File cluster management.
The Content Software for File system is a secured environment. It deploys a combination of security controls to ensure secured communication and secured user data.
The security controls include the following:
- HTTPS access: To access the Weka GUI, you connect only to one of the system servers using HTTPS through port 14000.
- Authentication tokens: The authentication tokens are used for accessing the Weka system API and to allow the mounting of secure filesystems.
- KMS: When creating an encrypted filesystem, a KMS must be used to properly secure the encryption keys. The KMS encrypts and decrypts filesystem keys.
- TLS certificates: By default, the system deploys a self-signed certificate to access the GUI, CLI, and API through HTTPS. You can deploy your certificate by providing an unencrypted private key and certificate PEM files.
- CA certificates: The system uses well-known CA certificates to establish trust with external services. For example, when using a KMS.
- Account lockout: To prevent brute force attacks, if several login attempts fail (default: 5), the user account is locked for several minutes (default: 2 minutes).
- Login banner: The login banner provides a security statement or a legal message displayed on the sign-in page.
- GUI session automatic termination: The user is signed out after 30 minutes of inactivity.
Obtaining authentication tokens
The authentication tokens include two types: an access token and a refresh token.
- Access token: The access token is a short-live token (five minutes) used for accessing the Weka system API and to allow the mounting of secure filesystems.
- Refresh token: The refresh token is a long-live token (one year) used for obtaining an additional access token.
Procedure
Do one of the following:
- To obtain the refresh token and access token, through the CLI, log in to the system using the command:
weka user login. The system creates an authentication token file and saves it in:~/.weka/auth-token.json. The token file contains both the access token and refresh token.
- To obtain the refresh token and access token, through the REST API, use the
POST /login. The API returns the token in the response body.
- To obtain the refresh token and access token, through the CLI, log in to the system using the command:
Generating an access token for API usage (for internal users only)
When working with the REST API, internal Weka users may require using a longer-lived access token (a token that doesn't require a refresh every 5 minutes).
You can generate a longer-lived access token using the CLI command:
weka user generate-token [--access-token-timeout timeout]
The default timeout is 30 days.
To revoke the access and refresh tokens, use the CLI command:
weka user revoke-tokens
KMS management
The management of a Key Management System (KMS) within the Content Software for File system is described.
Overview
When creating an encrypted filesystem, a KMS must be used to properly secure the encryption keys.
The Weka system uses the KMS to encrypt filesystem keys. When the Content Software for File system comes up, it uses the KMS to decrypt the filesystem keys and use its in-memory capabilities for data encrypting/decrypting operations.
When a snapshot is taken using the Snap-To-Object feature, the encrypted filesystem key is saved along with the encrypted data. In the event of rehydrating this snapshot to a different filesystem (or when recovering from a disaster to the same filesystem in the Content Software for File cluster), the KMS is used to decrypt the filesystem key. Consequently, the same KMS data must be present when performing such operations.
For increased security, the Content Software for File system does not save any information that can reconstruct the KMS encryption keys, which is performed by the KMS configuration alone. Therefore, the following should be considered:
- If the KMS configuration is lost, the encrypted data may also be lost. Therefore, a proper DR strategy should be set when deploying the KMS in a production environment.
- The KMS must be available when the Content Software for File system comes up when a new filesystem is created, and from time to time when key rotations must be performed. Therefore, it is recommended that the KMS be highly available.
For more information, refer to KMS Best Practices.
The Content Software for File system supports the following KMS type:
- Key Management Interoperability Protocol (KMIP)-compliant KMS (protocol version 1.2 and up).
For additional information on KMS support, contact your Hitachi representative.
KMS best practices
The KMS is the only source holding the key to decrypt Content Software for File system filesystem keys. For non-disruptive operation, it is highly recommended to follow these guidelines:
- Set up DR for the KMS (backup/replication) to avoid any chance of data loss.
- Ensure that the KMS is highly available (note that the KMS is represented by a single URL in the Content Software for File system).
- Provide access to the KMS from the Content Software for File system backend hosts.
- Verify the methods used by the KMS being implemented (each KMS has different methods for securing/unsealing keys and for reconstructing lost keys, for example, Vault unsealing methods, which enable the configuration of auto unsealing using a trusted service).
- Refer to Production Hardening for additional best practices suggested by HashiCorp when using Vault.
Managing KMS using the GUI
How to manage KMS using the GUI.
Adding a KMS
From the menu, select Configure > Cluster Settings.
From the left pane, select Security.
On the Security page, select Configure KMS.
On the Configure KMS dialog, select the KMS type to deploy: HashiCorp Vault or Kmip.
Configure KMS of HashiCorp Vault type 
Configure KMS of Kmpi type 
Enter the connection properties. The required properties depend on the KMS type you select.
For the HashiCorp Vault type, enter the following:- Address: The KMS address
- Key Identifier: The identifier of the KMS.
- Token: The API token that you obtain from the vault.
For the Kmip type, enter the following:
- Address: The KMS address
- KMS Identifier: The identifier of the KMS.
- Client Cert and Client Key: The client certificate and key that you obtain for the Kmip-based KMS.
- CA Cert: (Optional) A digital certificate from the Certificate Authority (CA).
Click Save.
Viewing the KMS
From the menu, select Configure > Cluster Settings.
From the left pane, select Security.
The Security page displays the configured KMS.
Updating the KMS configuration
From the menu, select Configure > Cluster Settings.
From the left pane, select Security.
The Security page displays the configured KMS.
Select Update KMS, and update its settings.
Select Save.
Removing the KMS
Before you begin
Removing a KMS configuration is possible only if no encrypted filesystems exist.
Procedure
From the menu, select Configure > Cluster Settings.
From the left pane, select Security.
The Security page displays the configured KMS.
Select Reset KMS.
In the message that appears, select Yes to confirm the KMS configuration reset.
TLS certificate management
This page describes how manage the TLS certificate.
TLS certificates are used to protect both the clients' information while it's in transfer and to authenticate the system identity to ensure users are interacting with legitimate system owners.
By default, the system deploys a self-signed certificate to access the GUI, CLI, and API through HTTPS. You can deploy your certificate by providing an unencrypted private key and certificate PEM files.
The system supports TLS 1.2 and higher with at least 128-bit ciphers.
Managing the TLS certificate using the GUI
Once the system installation is completed, the cluster TLS certificate is enabled with an auto-generated self-signed certificate to access the GUI, CLI, and API through HTTPS. If you have a custom TLS certificate, you can set it instead of the auto-generated self-signed certificate.
You can also download the existing TLS certificate for later use if you want to use the self-signed certificate.
Procedure
From the menu, select Configure > Cluster Settings.
From the left pane, select Security.
In the TLS Certificate section, select Set TLS certificate.
In the Set Custom TLS Certificate dialog, do one of the following:
- Select Upload TLS certificate files, and upload the TLS certificate and private key files.
- Select Paste the custom certificate content, and paste the content of the TLS certificate and private key.
To download the existing TLS certificate, select Download TLS certificate. In the dialog, set a name for the certificate and select Download.
Account lockout threshold policy management
To prevent brute force attacks, if several sign-in attempts fail (default: 5), the user account is locked for several minutes (default: 2 minutes).
You can control these default values using the GUI or the CLI.
Manage the account lockout threshold policy using GUI
Using the GUI, you can set the number of failed attempts until the account is locked and the lockout duration. You can also reset the account lockout threshold policy properties to the default values
Procedure
From the menu, select Configure > Cluster Settings.
From the left pane, select Security.
In the Account Lockout Threshold Policy section, select Set Account Lockout Policy.
In the Set Lockout Policy dialog, do the following:
- Failed Attempts Until Lockout: Set the number of sign-in attempts to lockout between 2 (minimum) to 50 (maximum).
- Lockout Duration: Set the lockout duration between 30 secs (minimum) to 60 minutes (maximum).
Select Save.
To reset the account lockout threshold policy properties to the default values, select Reset account lockout policy. In the confirmation message, select Yes.
Managing the login banner
How to set a login banner displayed on the sign-in page.
The login banner provides a security statement or a legal message displayed on the sign-in page displayed on the GUI. The statement can be a definitive warning to any possible intruders that may want to access your system that certain types of activity are illegal, but at the same time, it also advises the authorized and legitimate users of their obligations relating to acceptable use of the system.
Managing the login banner using the GUI
You can set a login banner containing a security statement or a legal message displayed on the sign-in page. You can also disable, edit, or reset the login banner.
Procedure
From the menu, select Configure > Cluster Settings.
From the Cluster Settings pane, select Security.
On the Security page, select Login Banner.
Select Edit Banner.
In the Edit Login Banner, write your organization statement in the banner text box.
Select Save.
To prevent displaying the login banner, select Disable Login Banner.
To clear the banner text, select Clear Login Banner Message.