Micro Focus strongly recommends that you configure additional security to restrict access to your vault.
Restrict access to the vault files and to the
secrets.cfg file, which contains information required to read secrets from the vault. Modifying the filesystem permissions can be used
to achieve this.
On Windows platforms:
- Create a group named, for example, "Micro Focus ES". Add the Administrators group and the LOCAL_SYSTEM account to that group.
- Set an inheritable Access Control List (ACL) on
%PROGRAMDATA%\Micro Focus\Enterprise Developer\mfsecrets so that only the "Micro Focus ES" group can read, write, and delete.
Note: All users who start
enterprise server regions from the command line need to be members of the "Micro Focus ES" group; similarly any accounts used to start
enterprise server regions by running casstart (for example, schedulers) need to be members of that group; and similarly if the MFDS service account
is changed, it needs to be a member of that group.
On UNIX platforms:
- Create a group named, for example, "mfes". Add the
root user and the ES administration userid, also known as "ESadminID", specified at product installation or when the
casperm.sh script is run, to this group. Also add the userids of any users who will run commands that require vault access, such as
mfsecretsadmin.
- Change the owner of the
$COBDIR/etc/secrets directory and its contents to
root, and the group to the group created in the previous step. For example,
chown -R root.mfes $COBDIR/etc/secrets. ($COBDIR/etc/secrets is typically a symbolic link to a directory in the persistent configuration area, but by default commands such as
chown operate on the target of a symbolic link.)
- Change the permissions of the secrets directory to restrict access to owner and group only. For example,
chmod -R 770 $COBDIR/etc/secrets.
Note: All users who start
enterprise server regions from the command line need to be members of the "Micro Focus ES" group; similarly any accounts used to start
enterprise server regions by running casstart (for example, schedulers) need to be members of that group; and similarly if the MFDS service account
is changed, it needs to be a member of that group.
See
Hardening filesystem permissions for more information.