Support Center > Search Results > SecureKnowledge Details
Using Auto Provision in Multi-Domain Security Management Server Environment Technical Level
Solution

Overview

NOTE - for instructions on using Auto Provision in Multi-Domain Security Management Server Environment with Microsoft Azure Scale Sets, see the Virtual Machine Scale Sets (VMSS) for Microsoft Azure Administration Guide

 

Automatic provisioning enables the management of CloudGuard Security Gateways deployed in the cloud environments by a single or a multi-domain (MDS) Check Point Security Management Server.

The Security Management Server periodically scans the cloud environment for newly deployed Security Gateways, creates trusted connections with them, and automatically provisions them by creating the corresponding gateway object in the Management Server and installing the policy on the gateway. For more information, see section Automatic Provisioning with Security Management Server in sk130372 and section Configure the Check Point Management Server in sk115533. Those solutions describe how to work with a single-domain Security Management Server.

The purpose of this solution is to instruct you on how to work with a Multi-Domain Security Management Server.

This article assumes that you are familiar with the automatic provisioning concepts, and will only explain the details that are specific to working with a Multi-Domain Security Management Server.

In this article, all configuration is done using the autoprov-cfg CLI configuration tool.

The Security Management Server login credentials should allow the script access to all the relevant Domain Management Servers. There would be a single instance of the autoprovision service that will be responsible for provisioning in all the Domain Management Servers.

 

Use Cases

  1. Working with a single domain in the Multi-Domain Security Management Server

    Here, the provisioning is to be done in a single Domain Management Server that resides in a Multi-Domain Security Management Server, rather than being done in a single-domain Security Management Server.

    For this use case, the domain of the Domain Management Server should be specified by running the following command:

    autoprov-cfg set management -d <DOMAIN-NAME>

    Replace <DOMAIN-NAME> with the name of the relevant Domain Management Server in the Multi-Domain Security Management Server.
  2. Working with multiple domains and multiple cloud accounts

    Here, there is more than one Domain Management Server. We assume that for each Domain Management Server there is a different dedicated cloud account (AWS account).
    The assumption is that, based on the given cloud credentials, each of the accounts will return a mutually exclusive set of objects.
    That is, it is not possible, for example, that the same instance/VM will be returned by the different set of credentials.

    For this use case, instead of specifying the domain of the Security Management Server, you should specify a domain for each of the controllers used to connect to your cloud environments (a controller contains configurations required to connect to a cloud environment, such as credentials, regions or a subscription ID). Multiple controllers can have the same "domain" value. The meaning would be that all the objects retrieved by these controllers would be defined in the same domain. You can achieve this by running the following command:

    autoprov-cfg set controller AWS -cn <CONTROLLER-NAME> -cd <DOMAIN-NAME> 

    Replace <CONTROLLER-NAME> with the name of the controller used to connect to the cloud environment and <DOMAIN-NAME> with the name of an existing domain.

    Hence, there is a requirement for exclusivity of the returned objects from different accounts in the same domain. If the same CloudGuard Security Gateway instance/VM is returned from two different accounts, the autoprovision service will try to provision it twice, once from each of the different accounts.

    The configuration and policy of a CloudGuard Security Gateway is determined by a configuration template that can be created and edited with the autoprov-cfg CLI configuration tool, and setting a tag on the instance/VM with the configuration template name.

    By default, any Security Gateway may be tagged with the name of any existing configuration template to then be provisioned with the parameters in it. If there is a requirement that certain templates should only be used by a specific domain, it is possible to enforce it by running the following command:

    autoprov-cfg set controller AWS -cn <CONTROLLER-NAME> -ct <CONFIGURATION-TEMPLATES-NAMES>

    Replace <CONTROLLER-NAME> with the name of the controller for which you have specified a domain and <CONFIGURATION-TEMPLATES-NAMES> with a list of configuration template names that can be used by that specific domain, e.g. 'TEMPLATE1-NAME TEMPLATE2-NAME'.

  3. Working with multiple domains and a single cloud account

    There are cases, where the environment requires that all the cloud objects are managed by one cloud account, but the security management is divided across multiple domains.

    We could define multiple controllers with the same credentials, but specify a different domain for each.
    As explained above, this would lead to the same CloudGuard Security Gateway being retrieved by multiple controllers and an attempt to provision the same gateway in multiple domains.

    The solution is to define exclusive templates for each Domain Management Server. In order to avoid duplication of attributes shared by multiple configuration templates, it is possible to define a prototype configuration template that will be used by multiple exclusive configuration templates. For example, to specify a prototype configuration template with a Security Policy, gateway version and a one time password so these attributes will be shared by multiple exclusive configuration templates, use the following commands:

    autoprov-cfg add template -tn <BASE-CONFIGURATION-TEMPLATE-NAME> -po <POLICY> -ver <VERSION> -otp <ONE-TIME-PASSWORD>
    autoprov-cfg set template -tn <EXCLUSIVE-CONFIGURATION-TEMPLATE-NAME> -pr <BASE-CONFIGURATION-TEMPLATE-NAME> 

    In the first command, which creates a new prototype configuration template, replace <BASE-CONFIGURATION-TEMPLATE-NAME> with a name to represent the prototype configuration template (e.g. 'base-template'), <POLICY> with The name of a Security Policy intended to be installed on the Gateways (e.g. 'Standard'), <VERSION> with the gateway version and <ONE-TIME-PASSWORD> with the Secure Internal Communication (SIC) key. In the second command, replace <EXCLUSIVE-CONFIGURATION-TEMPLATE-NAME> with the name of the exclusive configuration template for it to use the prototype configuration template values (run once for each exclusive template).

    Once we have a set of templates dedicated for each Domain Management Server, we can specify them for each controller, as explained in the previous use case above. Each of the controllers that share credentials will retrieve the same set of Security Gateways. However, the provisioning will be skipped for the gateways, whose template tag would not match the configuration templates list enforced on the controller.

 

MDS and Global Policy

The following section is relevant for customers who wish to use global policy in conjunction with automatic provisioning.

On an event of a identifying a newly deployed gateway, an internal access policy named 'restrictive policy' is installed. As one might expect, the restrictive policy is meant to drop all traffic.

Any rules defined in the global policy will conflict with the restrictive policy and will cause a policy installation failure.

However, it is possible to prevent the installation failure by using a custom restrictive policy that will be excluded from the global policy assignment manually. To do so, follow these steps:

  1. If you have yet to create a global policy, create one in the global domain: 
    1. Connect to the Smart Domain Management Server with SmartConsole
    2. Select Global Domain
    3. Create a Security Policy with the desired rules. 
    4. Publish changes.
  2. Create a new restrictive policy in each domain:
    1. Reconnect to the Smart Domain Management Server with SmartConsole
    2. For each domain: 
      1. Create a restrictive policy. Since this policy is for internal purposes, the following rule is recommended: source: any, destination: any, action: drop 
      2. Publish changes. 
  3. In the MDS SmartConsole, exclude the restrictive policy created in step 2: 
    1. Reconnect to the Smart Domain Management Server with SmartConsole
    2. Select MDS.
    3. Open the Global Assignments view.
    4. Select Advanced under Access Control
    5. Click on Assign Global Access Control Policy to all domain policies except: 
    6. Select the restrictive policy object created in step 2.
  4. Set the newly created restrictive policy as the default restrictive policy:
    1. Connect to the Smart Domain Management Server via SSH. 
    2. For each domain, set the name of the restrictive policy package created in step 2 as the default restrictive policy. This can be achieved with the following command: 

      autoprov-cfg set template -tn <CONFIGURATION-TEMPLATE-NAME> -rp <RESTRICTIVE-POLICY-PACKAGE-NAME>

      Replace <CONFIGURATION-TEMPLATE-NAME> with the name of the relevant configuration template and <RESTRICTIVE-POLICY-PACKAGE-NAME> with the name of the restrictive policy package created in step 2.

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment