SmartLock offers advanced data immutability and security capabilities, such as the protection of directories and files from deletion in a WORM state, the ability to disable privileged delete, and overall security. It is available in two different modes: Compliance and Enterprise. The administrative restrictions of Compliance mode have the potential to affect both compliance data as well as enterprise data. formed Consider the following guidelines and suggested best practices:
- Use SmartLock in Compliance mode only if your organization is legally obligated to do so under SEC rule 17-a4(f). As the Compliance mode installation or upgrade involves careful planning and preparation, it is recommended to be done with the assistance of Dell Support.
- Enterprise mode offers more than adequate security requirements for most users, in most situations. Moreover, the ‘superuser’ account remains available in Enterprise mode. Therefore, it is more administrator friendly compared to Compliance mode. Following are the best practices that need to be performed before putting an existing cluster in Compliance mode.
- Test and validate all workflows using a proof-of-concept Compliance mode cluster.
- Verify that the cluster time is correct before putting the cluster in Compliance mode.
- Avoid using ‘run-as-root’ on SMB shares. If you have previously configured SMB shares to ‘run-as-root’ then change the settings for those shares to specify access permissions to either ‘Full-Control’, ‘Read-Write’ or ‘Read’ before putting the cluster in Compliance mode.
- Use Role based access control (RBAC) for cluster access to perform file management and administrative operations. Enable RBAC, grant appropriate privileges, and then log in through the RBAC-enabled account to the command-line interface (CLI). ‘compadmin’ represents a regular data user in the context of the CLI.
- For any data migrations from a non-Compliance mode cluster to a cluster that you intend to put in Compliance mode, first verify that current ownership and access permissions are valid and appropriate on both clusters to allow data migration.
- Review the permissions and ownership of any files that exclusively permit the root account to manage or write data to them. Once an upgrade to Compliance mode is complete, if the existing OneFS configuration limits relevant POSIX access permissions to specific directories or files in any way, writing data or changing ownership of these objects will be blocked.
- If any root-owned workflow or datafiles exist, all ownership or permission changes should be performed before upgrading to Compliance mode. You should not change the ownership of any system files. The Compliance mode conversion process automates all required ownership changes to system files. Avoid changing the ownership of any files outside of /ifs, as no user data should reside outside of /ifs. As a best practice, change the ownership of files under /ifs that are owned by ‘root’ to the ‘compadmin’ account before upgrading to Compliance mode.
- In Compliance mode, the default POSIX permissions permit the compadmin account to write data. However, the following directories should not be modified unless the default permissions for these directories have been changed: /ifs/.ifsvar and /ifs/.snapshot
- Verify the available disaster recovery options on Compliance mode clusters in relation to SyncIQ.
- If NDMP is being used for backups, the NDMP backups of SmartLock Compliance data are not considered to be compliant with the SEC regulation 17-a4f.
For more information, see the SmartLock white paper.