File System Security

Below is a Crash Plan scenario we’ve tested that mitigates the issue but also introduces a bit of administrative overhead. The basic idea is to lock out backup selections by default which disables access to the host’s file system through the Crash Desktop application and from the web console.  Administrators would need to enable backup selection by device as needed.  Here are the steps:

1. Set org device defaults for Backup>File Selection, Included Files to “none”, lock the setting and leave it locked.
2. Whenever a device is first registered to a standard user no files can be selected for backup until the setting is toggled by an administrator.
3. Unlock backup file selection per device (device>edit>unlock). End users can then select backup items at their discretion or admins can select for them.
4. If a client is de-authorized and registered to another user it will disconnect from the previous user’s backup archive and device settings, create a new device entry (duplicate name but unique GUID) and inherit the locked “none” backup selection until an admin intervenes.
   1. Important to note is when file system access is locked out, the CP Desktop Application will allow users to browse /select directories and files but does not save any selections.  
      

There are some shortcomings to this scenario since it cripples product conveniences and implementing these controls on a production org removes existing device backup selections as the setting is pushed to all devices (automated).  During this push, however, existing backup archives are left intact. 

Short of this arrangement the only other solutions I can think of would be leveraging Group Policy to severely restrict local logon rights or submitting a feature request to Code42 for toggling command line functionality on CP clients.