File Access Policy Type
File access policy management
Overview
File Access policies control access to specific files, implementing fine-grained access control for sensitive data, configuration files and system files.
The file access policy restricts access to executable files and non-executable files.
File Access policies may operate within broader default-deny enforcement models, requiring explicit authorization or policy approval before sensitive files can be accessed or executed.
How it works
Executable files are restricted at the point of execution, similar to the elevation policy.
Non-executable file enforcement, which leverages the native operating system's ACLs, (e.g. text file, database file, configuration file, etc) will deny
READ/WRITE/DELETEof the file without adhering to the enforcement (MFA, justification, approval).The File Access policy will apply to any user of the system, not just a standard user.
File Access requests can be initiated from both the Keeper Client and command-line interface, ensuring consistent enforcement and workflow parity across user interaction models.
Special Considerations
If you have file access and elevation policy on the same executable, the file access policy won't apply and Keeper will only apply the elevation policy.
File Access policy evaluation may incorporate contextual risk signals as part of enforcement decisions, supporting organizations that align file governance with broader risk management strategies.
Keeper supports Path Variables for assigning policy to a common folder or path on the endpoint.
Keeper modifies the ACL of a target file explicitly to a user that the policy has been applied to. Keeper will explicitly add the user, then apply the ACL. When a user requests access to a file, and the file access is approved, Keeper modifies the ACL for that user read/write permission to "allow". On Linux systems, if the user is a member of a group which already has "allow" permissions, the user will be able to access the file based on their group membership, regardless of what Keeper enforces.
Create an Application Collection
Before creating the policy, the target files must be organized into an Application Collection. Navigate to Collections → Applications and click on the New Collection button. This will bring up the New Collection modal form. Select Applications from the Type select box, give your collection a recognizable descriptive name, and click the Next button.
You sholud now see the Add Item to Collection modal form. You can either Type object to add and select from the objects that match the string that you type, or you can check the Manually define resource checkbox and manually define your resources.
Add each target file as a custom resource, using Path Variables where applicable to avoid hardcoded paths (e.g. {system32}\powershell.exe). Once you have selected or entered the resource that you want to add to your collection, click the Add button and repeat the process until youhave all of the resources that you would like to see in your application collection added.
Tip: Give the collection a descriptive name that reflects its purpose — for example, "Restricted System Tools" or "Protected Config Files" — to make it easy to identify when assigning it to a policy.
Configure the Policy
Fill in the policy details:
Policy Name — Enter a descriptive name (e.g.
File Access – Restricted System Tools,File Access – Protected Config Files)Policy Type — Select
File AccessStatus — Select
Enforceto apply the policy actively
Tip: Consider starting with Monitor status to observe how frequently the policy would match before enabling enforcement.
Select a Control
Click Add Control and select the control to apply when a user triggers an elevation event:
Require Approval — Elevation is blocked until an assigned approver grants the request
Require MFA — User must verify their identity with a TOTP code before elevation proceeds
Require Justification — User must provide a written reason before elevation proceeds
Multiple controls can be added to a single policy. When controls are stacked, all must be satisfied before the elevation is permitted.
Set Policy Filters
Below the Add Control button, define the scope of the policy by applying filters:
User Groups — Select the user group collections to target, or choose Select All to apply to all users
Machines — Select the machine collections to target, or choose Select All to apply to all enrolled endpoints
Applications — Select the Application Collection created in Step 1
Date & Time Window — Optionally restrict the policy to specific dates, days of the week, or time ranges
Selecting Select All on any filter dimension creates a wildcard that automatically includes new users, machines, or applications added to those collections in the future.
Save and Deploy
Once the form has been sufficiently filled in per the previous steps, the Save button will be changed from an inactive to an active state. Click on the Save button.
The policy will be pushed to all in-scope endpoints within approximately 30 minutes. Users on affected endpoints can also trigger an immediate sync via the Refresh Policies option in the Keeper agent.
When the policy is applied, affected users will receive an on-screen notification informing them that they have been removed from the local Administrators group.
Example 1: File Access Policy on Executables
As an example, let's say you want to restrict users from executing specific applications that are typically only used by IT team members. This may prevent threats such as "living off the land" where malware takes advantage of common tools. A list of tools that fall into this category might look like this:
Create Collection
In the Collections > Applications, create a new Collection. For example, this one is called "Restricted Files on Windows". Add the files to the collection as custom resources.
Note: the {system32} variable is defined in our list of Path Variables.
User Experience
When the user (in this case, the "standard" user) attempts to execute any of the applications listed, they will receive a prompt from Keeper that requests justification and approval.
After the request is approved, the Keeper Client application will display the request. The user can then launch it directly from the user interface.
Example 2: Protection of a System File
In this example, we will require approval to access a protected file called "netlogon.inf" on all Windows machines.
Create a Policy
From the Policy tab, click on Create Policy and select:
Policy Type: File Access
Status: Enforce
Add Control: Select MFA, Justification or Approval
User Groups: Select the users or groups affected, or All Users and Groups
Machines: Select which machines to apply the policy, or All Machines
Applications: Select the "Protected Files" collection as defined above.
To require approval by an admin for accessing the file resource, select "Requires Approval" and then select the approver(s).
After saving the policy, it will apply to all affected machines within a few minutes.
Path Variables
When defining a File Access policy, variables can be used to simplify the policy creation process, and to avoid hard-coded paths.
Built-in Path Variables
Windows Variables
{windows}→C:\Windows(Windows directory){system32}→C:\Windows\System32(System32 directory){syswow64}→C:\Windows\SysWOW64(32-bit system directory){systemdrive}→C:\(System drive root){userprofile}→C:\Users\username(User profile directory){programdata}→C:\ProgramData(Program data directory){programfiles}→C:\Program Files(Program Files directory){programfilesx86}→C:\Program Files (x86)(32-bit Program Files){temp}→C:\Users\username\AppData\Local\Temp(Temp directory){appdata}→C:\Users\username\AppData\Roaming(Application data){localappdata}→C:\Users\username\AppData\Local(Local application data)
macOS Variables
{system}→/System(System directory){library}→/Library(Library directory){home}→/Users/username(User home directory){applications}→/Applications(Applications directory){volumes}→/Volumes(Volumes directory){temp}→/tmp(Temporary directory)
Linux Variables
{usr}→/usr(User directory){home}→/home/username(User home directory){temp}→/tmp(Temporary directory){root}→/(Root directory)
Cross-Platform Variables
{userdocuments}→ User Documents directory{userdesktop}→ User Desktop directory
Protected Paths
Keeper Endpoint Privilege Manager maintains a comprehensive list of protected paths across all supported platforms. These paths represent critical system directories and files that should not be modified by standard users and are excluded from ACL enforcement to maintain system integrity.
Protection Categories
1. Protected Directories
System directories that are automatically protected from ACL modifications.
2. High-Risk Paths
Critical system files that should never be modified and are blocked from storage operations.
3. Critical System Paths
Virtual filesystems and problematic paths that are avoided during inventory scanning.
Platform-Specific Protected Paths
Windows Protected Directories
The following directories are protected on Windows systems:
Variable-Based Protected Paths (resolved at runtime):
Windows High-Risk Paths
Critical system files that should never be modified:
Linux Protected Directories
Critical system directories and files on Linux systems:
Linux High-Risk Paths
Critical system files on Linux:
macOS Protected Directories
System directories and critical files on macOS:
macOS High-Risk Paths
Critical system paths on macOS:
Generic Unix Protected Directories
Fallback protected directories for unknown Unix variants:
Mac and Linux Policy Enforcement
On macOS and Linux devices, the File Access policy currently requires the use of the Keeper Client application user interface. To request file access, the user has to request it via the system tray "Request Access" feature.
Last updated
Was this helpful?