Overview |
||||
|
wrapper.secure_file.check.windows.allowed_account.<n> Property |
||||||||||
These properties can be used to specify a list of allowed accounts when checking permissions of secure files on Windows. For simplicity, these properties apply to all secured files. So if different files grant permissions to different accounts, these properties should form a common list of allowed accounts across all secured files. Note that the following accounts are inherently insecure and cannot be allowed:
Let's assume a file containing passwords was created with permissions for NT AUTHORITY\SYSTEM, BUILTIN\Administrators and DESKTOP-06SJR11\john. Since the file contains passwords, it is considered sensitive and as such the following log output will be printed:
The first action to take is to remove any permissions that are not necessary: Right click on the file, select Properties, go to the Security Tab, click Edit, select a User or Group, click Remove. For example, you may remove 'john'. If the remaining permissions are necessary, you will need to explicitly allow them in the Wrapper configuration as follow:
After restarting the Wrapper, the message should no longer appear and it should start your application normally. 警告Windows often has permission inheritance enabled. This means that if a file is created, it will automatically inherit the permissions of its parent folder. Additional permissions can be added, but attempting to remove an inherited permission will result in the following message: 
In order to remove a permission that is inherited, you need to either store the file in a parent folder that has permission inheritance disabled, or remove permission inheritance for the file itself. |
wrapper.secure_file.check.unix.allowed_group.<n> Property |
||||||||||||
These properties can be used to specify a list of allowed groups when checking permissions of secure files on Unix systems. Group ownership can only be set to one group on Unix system, but these properties form a list of groups allowed across all secured files. If you need to allow multiple groups for separate secure files, you can list them by adding as many wrapper.secure_file.check.unix.allowed_group.<n> properties as needed, remembering to increment the <n> index for each group. Note that the following groups are too broad and thus not permitted:
Let's assume a file containing passwords was created with the following ownership and permissions:
The first action to take is to remove permissions for the 'other' class, for example using the following command: chmod o-r . In most cases, group permissions should also be removed, but scenarios such as multiple users belonging to the same group and being allowed to run the Wrapper are possible. If permissions for the group "team" should be kept, you may add it to the list of allowed groups by using the following configuration:
After restarting the Wrapper, the message should no longer appear and it should start your application normally. |
wrapper.secure_file.check.windows.allow_unsecured_volumes Property |
||||||||||
This property allows files containing sensitive data to be stored on volumes whose format does not support file permissions. On Windows, file systems such as FAT32 or exFAT do not support file permissions. This means that anyone with access to the volume can access the files on it. Unless you know that the access to the volume itself is secure (for example, when it is mounted only by authorized users), it is recommended that you store files containing sensitive data on a volume with a file system (like 'NTFS') that supports permissions and lock down these permissions to the essentials. By default, storing sensitive files on unsecured volumes is not allowed (the default value is FALSE). If a sensitive file is found on an unsecured volume, the Wrapper will print the following message and then stop:
The Wrapper will no longer show this message and be allowed to start if wrapper.secure_file.check.windows.allow_unsecured_volumes is set to TRUE.
|
wrapper.secure_file.check.unix.allow_unsecured_volumes Property |
||||||||||
This property allows files containing sensitive data to be stored on volumes whose format does not support file permissions. On Unix systems, file systems such as FAT32 or NTFS do not support file permissions. This means that anyone with access to the volume can access the files on it. This is the case, for example, of volumes hosted on a Windows server and shared with Linux systems. Unless you know that the access to the volume itself is secure (for example, when it is mounted only by authorized users), it is recommended that you store files containing sensitive data on a volume with a file system (like 'ext4') that supports permissions and lock down these permissions to the essentials. By default, storing sensitive files on unsecured volumes is not allowed (the default value is FALSE). If a sensitive file is found on an unsecured volume, the Wrapper will print the following message and then stop:
The Wrapper will no longer show this message and be allowed to start if wrapper.secure_file.check.unix.allow_unsecured_volumes is set to TRUE.
|
wrapper.secure_file.check.disable Property |
||||||||
This property can be used to disable permission checking for secure files. Note, however, that usage of forbidden accounts listed in red in the above sections will remain invalid and prevent the Wrapper from starting. The default value is FALSE.
|
wrapper.secure_file.check.loglevel Property |
||||||||
This property can be used to set the log level of messages printed when a problem with the permissions of a secured file has been detected. The default value is FATAL if wrapper.secure_file.check.srict is TRUE, WARN otherwise.
|
wrapper.secure_file.check.srict Property |
||||||||
This property can be used to define whether the Wrapper should stop or continue whenever a problem with the permissions of a secured file has been detected. It is recommended to keep this property set to TRUE so that permissions issues are detected and resolved as early as possible. For cases where the Wrapper is configured to start automatically without human interaction (e.g. when starting as a service), it may be useful to set this property to FALSE. The Wrapper will still report permissions issues with a default loglevel of WARN, and continue its execution. It is recommended that the user who later checks the logs, corrects the file permissions as soon as possible if any warnings were reported. The default value is TRUE.
|
wrapper.secure_file.additional.<n> Property |
||||||||
The Standard and Professional Editions offer the ability to list additional files that should be checked using the same rules as for files automatically detected as sensitive by the Wrapper. This can be useful for example for sensitive files that are not read by the Wrapper but by the Java application. <n> component:
Each element has a property name that starts with "wrapper.
|
参照： セキュリティ |
|
暗号設定：
セキュアファイル：
コマンド：
|