Data Loss Prevention

 View Only

  • 1.  DLP Enforce in High Availability mode

    Posted Feb 21, 2018 03:50 AM

    Hi Everyone,

    I am planning to setup Symantec DLP Enforce in High Availability mode. I have gone through some articles on the forum bu they are suggesting to implement Veritas Cluster Server, but I need to implement it without VCS.

    Please guide.

     

    Best Regards,

    Atif

     

     



  • 2.  RE: DLP Enforce in High Availability mode
    Best Answer

    Posted Feb 21, 2018 07:20 AM

    Hi Atif,

     

    I suspect you need VCS as this is tightly coupled to the way in which it monitors the application and services and fails this over.

    However, VCS is not on these forums anymore, and I would recommend that you close this query off and reopen your VCS query on the link below:

    https://vox.veritas.com

    Thanks!



  • 3.  RE: DLP Enforce in High Availability mode

    Posted Feb 23, 2018 07:43 AM

    This article was on the support site some time ago, but now appears to be gone. The Alternate Manual Solution IS NOT A SUPPORTED CONFIGURATION. Consider or use it at your own risk.

    Issue

     

    Can Enforce be setup in a High Availability  ( HA ) mode ?

     

    Solution

     

    Fully Certified Solution

    Symantec DLP is currently has only certified a VCS based HA solution.

    If the customer is interested in pursuing a VCS based solution, please contact the SE or Account Manager for more details.

    The VCS based HA solution is for V11 on Windows 64 Bit only, VCS Agents for Enforce and the Database exists to complement each other.

    The agents and documentation can be downloaded from https://vos.symantec.com/agents

     

    Alternate Manual Solution

    There is an alternative method by invoking the following manual steps. It is always recommended to perform a full DB backup to ensure that in case of an error a restoration can be performed.

    For more details about reinstalling an environment with preserved schema, please also review KB 54659

    NOTE: The following system for a failover system has been setup successfully at various customer sites. However, it is important to understand that this should be only considered a suggestion and is by no means a certified solution. You are responsible for proper testing and backup mechanisms to ensure that in case of corruption the environment can be restored.

    The current certified High Availability solution is Veritas Clustering Services (VCS) . If you require a vetted solution, setup and testing we highly recommend to engage Symantec Professional Services for setting up a HA solution as outlined below.

    Important: A full outline regarding the scope of support regarding supported and alternate configurations can be found in http://www.symantec.com/business/support/Enterprise_Technical_Support_Policy.pdf . Please note that the referenced alternated configurations are referring to environments and processes that have not been certified.

     

    Prerequisites

    1. Primary Enforce server used for management of the DLP system.

    2. Secondary Enforce server with Symantec DLP installed and configured the same as the primary Enforce server.

    3. DNS record pointing to the primary Enforce server.

    4. Method for replication of configuration files (syncing) between the primary and secondary Enforce servers.

     

    Setting up Primary and Secondary Enforce Servers

    The DR solution proposed assumes that the primary and secondary Enforce servers will exist on the same Symantec DLP platform build. That means the version and hotfixes of both servers are in sync.  The DLP services on the primary Enforce server should be set to start automatically (default behavior when installing Enforce).  The services on the secondary Enforce server must be set after the initial install to require manual starting, and should be set to disabled to avoid accidental starting.  The specific services that this is referring to are:

    ·         VontuNotifier

    ·         VontuIncidentPersister

    ·         VontuManager

    ·         VontuMonitorController

    ·         VontuUpdate

    ·         VontuMonitor (only if running a detection server on the Enforce server)

     

    NOTE: It is critical that steps be taken to ensure that the Primary and Secondary Enforce servers are not started at the same time, as this could cause inconsistencies of data and control of detection servers, resulting in data corruption and system instability.

     

    DNS Entry

    It is assumed that a DNS record will be configured to allow access to the user interface through an alias.  This should point to the primary Enforce server only, with an additional commented out entry that points to the secondary Enforce server.  The DNS entry will need to be modified to switch to the secondary Enforce server in the event of a failover situation.

     

    Data Replication

    There are several folders that will need to be kept in sync between the primary and secondary Enforce servers in order to assure proper operation of the secondary server should it need to be used.  These are all located in the /opt/Vontu (Linux) or Vontu/Protect (Windows) directory.  This list represents all folders where any data may change on a periodic basis and that need to be kept in synch between the primary and secondary Enforce servers for the purpose of system operation and/or user continuity.

    NOTE: It is imperative that the failover server is synchronized with the primary server before it comes online

     

    1.       config

    Contains custom configuration and settings for the Enforce server that should be kept identical between the servers.  Properties and configuration files within this directory should not change on a frequent basis.

    2.       datafiles

    The datafiles directory is where files can be uploaded for indexing to use within an Exact Data Match (EDM) profile.   This should not change often as the indexing process for CUSTOMER’s EDMs will be automated, and will upload those files to the index directory. It will be used infrequently for creating ad hoc data indices, but should be synchronized in order to maintain continuity for users that may be utilizing this feature.

    3.       documentprofiles

    The document profiles directory has the same function as the datafiles directory, except it is used for document collections in a zipped archive for Indexed Document indexing.  It will be used infrequently for creating ad hoc document indices, but should be synchronized in order to maintain continuity for users that may be utilizing this feature.

    4.       index

    Contains indexed data that is pushed out to detection servers on a scheduled basis, and will be loaded with indices created remotely. 

    5.       keystore

    Contains CUSTOMER specific keystore files used for encryption of traffic between the detection servers and Enforce.  Keystores contained in this folder will not change on a frequent basis but should be kept synchronized in the event a keystore is updated.

    6.       license

    Contains CUSTOMER’s specific site license files (slf files) that enable functionality based on CUSTOMER’s licensed products.  Should not change on a frequent basis.

    7.       plugins

    Contains plugins that are used for data lookups.  By convention, customer specific plugins and scripts are contained within this directory.  These will not change on a frequent basis.

    8.       sharelists

    Used for defining Discover targets.  Although Discover is not being used at this point in the project, replication of this folder should be included in this process for the future.

     

    Manual Steps to Failover to Secondary Enforce Server

     

    In the event that the primary Enforce server becomes non-responsive or otherwise incapacitated, the following steps must be taken to enable the secondary Enforce server.  These steps assume all pre-requisites listed herein have been accommodated, and that the data replication between these servers as outlined above has been enabled and performed on a regular basis.

    1.       If possible, log onto the primary Enforce server:

    a.       Stop all Symantec DLP (Vontu) services on the primary Enforce server. 

    b.      Change all services to either “disabled” or “start manually” so that if the server is fixed, the DLP application does not try to reestablish a connection to the database.

     

    Important! If the server is non-responsive and it is not possible to change the services on the primary Enforce server, it’s critical that the server not be brought back up/restored in a connected state while the secondary Enforce server is running.  If it is, and the Vontu services successfully start and connect to the database, it could may result in system instability and unrecoverable data inconsistencies.

    2.       Change the DNS Entry to route the alias to the secondary Enforce server.

    3.       Change the DLP services on the secondary Enforce server to start automatically.

    4.       Start the DLP services on the secondary Enforce server in the following order:

    • VontuNotifier
    • VontuIncidentPersister
    • VontuManager
    • VontuMonitorController
    • VontuUpdate
    • VontuMonitor (only if running a detection server on the Enforce server)

    5.       Test UI access

    6.       Check Detection Servers in the System Overview page to ensure they are properly connecting back to the Enforce server.

     

    Legacy ID

     

    54575

     

    From <http://www.symantec.com/business/support/index?page=content&id=TECH219827&actp=search&viewlocale=en_US&searchid=1409832971976>