PlateSpin Migrate provides several features to help you safeguard your data and increase security.
As a security best practice, you should apply patches that address security vulnerabilities to your PlateSpin Server host and PlateSpin Migrate Client host, as you would for other Windows servers in your enterprise.
Micro Focus is aware of the side-channel analysis vulnerabilities described in CVEs 2017-5715, 2017-5753 and 2017-5754, known as Meltdown and Spectre. The current recommended actions have been applied on the PlateSpin Server images in the cloud.
We strongly recommend that you apply security updates that address such threats as recommended by Microsoft for the Windows operating system for the PlateSpin hosts. Consult the vendor documentation for information. See Protect Your Windows Devices Against Spectre and Meltdown on the Microsoft Support website.
A PlateSpin Migrate server stores log files and database files in the PlateSpin Migration installation folder. While migration jobs are running, the PlateSpin Migrate server will update these files frequently. Anti-virus applications either block these updates or interrupt them, which impacts the PlateSpin Migrate server performance. Anti-virus applications should either not be installed on the PlateSpin Migrate server host, or the PlateSpin Migrate installation folder must be added to the anti-virus application exclusion list.
For source workloads, an anti-virus application might block discovery or replication actions if they improperly quarantine PlateSpin Migrate tools, such as the OFX Controller.
If an anti-virus application is running on the source Windows workload, add the following folder and executable file to the anti-virus application’s exclusion list:
C:\Windows\PlateSpin
C:\Windows\PlateSpin\Controller\ofxcontroller.exe
For Windows Workloads, we recommend that all the non-VSS compliant services and anti-virus applications are stopped temporarily on the source while the VSS snapshot is being captured on the source. When you configure a migration, select the Windows services that you want to be temporarily stopped on the source workload while the VSS snapshot is being captured on the source. Migrate restarts these services automatically as soon as the VSS snapshot creation completes.
NOTE:Some anti-virus applications will restart itself automatically if an application attempts to stop it. If the anti-virus application restarts before the VSS snapshot creation completes, the data transfer does not begin. If this conflict occurs, you must stop the anti-virus manually, modify the workload configuration to not stop the anti-virus application during replication, then start the replication. After the VSS snapshot is captured for the replication, you can manually restart the anti-virus.
An anti-virus application can also prevent successful replication. See the following information:
PlateSpin Migrate server supports connections using Transport Layer Security (TLS) 1.0, 1.1, or 1.2 protocol, according to the protocols enabled on its host operating system. PlateSpin Migrate server uses TLS 1.2 protocol by default for connections with source workloads if TLS 1.2 is enabled on the underlying OS and Microsoft .NET Framework on both the Migrate server host and the source workload. Migrate does not have a setting that forces clients to use TLS 1.2 to connect.
NOTE:Older Windows operating systems, such as Windows Server 2008, do not support TLS 1.2. You must enable TLS 1.0 or TLS 1.1 protocols in the Windows Registry settings on the Migrate server host to migrate these source workloads. See Configuring TLS Protocols for Migrate Hosts
in the PlateSpin Migrate 2019.5 Installation and Upgrade Guide.
To connect a source workload to the Migrate server using TLS 1.2:
Source workloads: Both the Windows operating system and Microsoft .NET Framework version must support TLS 1.2 or must be updated to support TLS 1.2, and the TLS 1.2 protocol must be enabled in the Windows Registry settings.
For Windows operating systems that do not support TLS 1.2 by default:
A Microsoft update for .NET Framework might be required on the source workload in order to add support for TLS System Default Version settings. A reboot is required.
Use Microsoft Windows Registry settings to force .NET Framework to choose TLS 1.2 when the workload connects with Migrate server.
For information and configuration instructions, see Support for TLS 1.2
in Transport Layer Security (TLS) Best Practices with the .NET Framework in Microsoft Documentation.
Migrate server:
The Windows Registry settings for the TLS 1.2 protocol must be enabled on the Migrate server host. See Configuring TLS Protocols for Migrate Hosts
in the PlateSpin Migrate 2019.5 Installation and Upgrade Guide.
To make the transfer of your workload data more secure, you can configure your migration jobs to encrypt the data in transit to the target. When encryption is enabled, over-the-network data transfer from the source to the target is encrypted by using 128-bit Advanced Encryption Standard (AES).For information about how to enable encryption during data transfer for a migration job, see Section 25.13, Encrypt Data Transfer.
You can configure your PlateSpin Server to use a data encryption algorithm that is compliant with FIPS (Federal Information Processing Standards, Publication 140-2). If compliance with FIPS is required, it must be set up on your system prior to the PlateSpin Server installation. See Enabling Support for FIPS-Compliant Data Encryption Algorithms (Optional)
in your Installation Guide.
If FIPS is enabled in a source workload, ensure that the EnforceFIPSCompliance parameter is enabled on the PlateSpin Migrate server before you discover the source workload. See Section 5.2, Enforcing FIPS Compliance for FIPS-Enabled Source Workloads.
Data transmission between the PlateSpin Server and the PlateSpin Migrate Client can be configured to use either HTTP (default) or HTTPS (Secure Hypertext Transfer Protocol). To secure data transmission between the client and the server, enable SSL on your PlateSpin Server host and use HTTPS when specifying the server URL. See Connecting to a PlateSpin Migrate Server.
Credentials that you use to access sources and targets in workload migration jobs are secured by the following measures:
Each PlateSpin Migrate server has a unique, randomly generated encryption key that it uses to encrypt credentials for source workloads and target platforms.
Migrate uses the server’s encryption key with industry-standard security algorithms to encrypt passwords for source and target credentials, and stores them encrypted in the PlateSpin database.
Credential passwords can be stored encrypted in exported data by using a user-supplied encryption password with the Import/Export utility.
The PlateSpin Migrate database is covered by the same security safeguards that you have in place for PlateSpin Server host (or for the PlateSpin database host if you use an external database).
NOTE:To improve security of communications between the Migrate Server host and an external PlateSpin database, you can configure the host operating systems to use the Transport Layer Security (TLS) 1.2 protocol for secure communications. See Database Server
in System Requirements for PlateSpin Server
in the PlateSpin Migrate 2019.5 Installation and Upgrade Guide.
Passwords might be included in diagnostics, which are accessible to accredited users. You should ensure workload migration projects are handled by authorized staff.
PlateSpin Migrate Client can store credentials locally on the Migrate Client host. The passwords are cached, encrypted, and securely stored by the PlateSpin Migrate Client, by using operating system APIs.
PlateSpin Migrate provides a role-based user authorization and authentication mechanism. See Section 4.1, Configuring User Authorization and Authentication.
NOTE:If you have installed a PlateSpin Migrate server localized for one language and a PlateSpin Migrate Client localized for a different language, do not use authorization credentials that include any language-specific characters. Using such characters in the login credentials causes miscommunication between the client and the server: the credentials are rejected as invalid.