Endpoint Data Protection Best Practices Part 2 — Setup

In part one of our endpoint best practices mini-series, we covered the steps to correctly plan for deployment, including building the best strategy and outlined the impact/issues of improper or no planning. Continuing with this series, in part two, we’ll discuss why certain critical settings/options have to be configured and what might be the impacts if these are missed.

Setup

Once the Infrastructure/environment details have been captured, the next steps are to set up or configure the Druva console. This includes security, deployment, and configuration options.

Security

More than one cloud administrator

The first and most important step is to make sure access to the Druva environment is restricted with all correct security policies in place. Druva does not have access to the customer’s backup environment once the account has been created. This means if for some reason an administrator loses or forgets the login to the Druva portal, then Druva cannot reset the password.

Having more than one Druva Cloud administrator will help in scenarios where there are unusual activities like user and device deletions or unusual restores or if an admin account gets compromised where another admin can take corrective actions by deleting the account or resetting the credentials.

Here, the best practice is to create two or more cloud administrator accounts. You can use the forgot password link to reset your administrator password or you can ask another Druva Cloud administrator to reset it. This avoids any data loss scenario.

Restricting access to the admin console

Organizations have different teams on the infrastructure side, such as IT, the help desk, legal, eDiscovery, and backup. There is always the concern that giving too many privileges or too much access can result in unauthorized access and potentially lead to deletions. This can be tightened with proper Role-Based Access (RBAC).

As a cloud administrator, you should create custom roles with custom access and privileges according to your organization’s needs. These roles can then be assigned to the different admin accounts you plan to create.

Authentication using Single Sign On (SSO)

To make access more secure, integrating the IDP (Okta, Azure, PingOne, ADFS, etc.) in all one’s applications is the norm. Druva provides this functionality of SAML integration with most widely used IDPs. Administrators can configure their IDPs and add another layer of security to access the backup data. This can be set up both for administrators and users.

Geo-fencing

With corporate work culture moving from the office environment to remote or work-from-home culture. It’s the topmost priority to make sure users/employees are accessing resources remotely by connecting to the corporate network using VPNs.

Security or the Druva Cloud administrator does not want data to be restored/downloaded or for admins to access the console outside the corporate network — while a conservative step, this ensures there is no unauthorized access. Druva provides this capability by implementing geo-fencing both for administrators and users, thereby allowing access to the console or restore/download only through the corporate network.

MFA

Administrators can turn on MFA (multi-factor authentication) functionalities to further harden/tighten security.

Network/Firewall 

The Druva agent communicates over port 443 with the Druva Cloud for activation, backups, and restores, where organizations usually have strictly defined rules on their firewall for their existing set of web/SaaS applications. This can block agents from activation and backups/restores. So the network administrator needs to make sure that Druva traffic is approved or allow wildcard traffic, for example, “*.druva.com,” which will make sure agents’ connectivity with the cloud is not broken.

Antivirus scan

The Druva agent creates some local cache/dbs, config. files, and log files to log all activities. These files are accessed and modified every minute/second. Antivirus applications generally categorize these activities as malicious, and this can result in Druva files getting corrupted which could cause the agent to lose authentication to the cloud. So admins should exclude Druva-related services, processes, files, and folders from real-time and scheduled scans.

Deployment and Configuration

Once the security configurations have been set correctly, the next steps are to get the basic console configurations set up. These include:

• Audits, alerts, and reports
  • Set the audit retention to specific deadlines or forever depending on your requirements. 
  • Subscribe to critical alerts required for tracking backup, restore, and storage-related metrics.
  • Configure weekly reports like user rollout, user provisioning during deployment, inactive devices, and preserved users. Implement activity reports to monitor users, their backups, and restores.
• Other miscellaneous
  • Restrict backups over networks like mobile data and hotspots.
  • Co-branding — Adding company information like IT team contact details and the company logo that will be displayed on the agent.

Profiles

• If you have administrators or help desk teams managing users per department or based on geographical regions. 
• If there are different backup policies to be defined for an executive vs. normal user, or if there need to be different backup policies by region, then have separate profiles created. Otherwise, just have one profile for all users to simplify management.
• Configure the basic settings such as how many devices per user, authentication, retention, schedule, blackout window, bandwidth, CPU priority, and the files and folders to be backed up.

User management service

• Depending on your environment, choose the right integration method.
  • Microsoft on-premise active directory
    • Install and register the AD connector.
    • Register the domain controller or global catalog using the correct IP/FQDN and port.
    • Create AD mappings targeting the right security group, profile, and storage.
  • Microsoft Azure AD integration
    • Integrate Microsoft Azure AD.
  • Integration using SCIM protocol
    • Integrate Okta and Azure by following Druva documentation.
    • Create mappings for all users or based on filters like department or country.

• Mass deployment package
  • Generate a mass deployment token and set an expiry based on your requirements.
  • Create the mass deployment package based on the integration service used.
• UAT (User acceptance testing)
  • Identify a pilot batch and deploy the mass deployment package.
  • Verify this process goes through successfully.
  • Verify the data is backed up and then initiate restores.
  • Collect user feedback and see if changes are needed to the profile configuration.

Deployment

• Once all the security, basic configuration, and UAT are done, it is time to get the users deployed into the production environment. 
• Depending on the batch of users/devices to be rolled out/calculated in the planning phase, start deploying the package to the endpoints. 
• Monitor live activities to see that devices are being backed up and verify the user rollout report to keep track of the deployment.

This concludes part two (setup, configuration, and deployment) where we explored the crucial and critical areas of configuration. Following these best practices will result in a successful deployment.

Read part three in the blog series now to take a look at backup and restore monitoring and integration.

Visit the endpoints page to learn more about how Druva provides a secure, reliable, and fast endpoint backup solution, so your teams can always recover clean end-user data. Druva’s integrated backup, eDiscovery, and compliance monitoring simplify endpoint data protection, ensure regulatory compliance, and improve data visibility for the mobile workforce.