This example uses the command line utility file definition, from encUtilCmd, to describe the authorization rules, but it is analogous for the DSM Explorer; the rule sets are very similar.
It is possible to generate a simple set of rules, similar to those described below, using the encUtilCmd utility and its 'create' command. This also provides the ability to generate a test script at the same time to exercise the rules.
The following realms are used in this example:
This is the realm used for containing all of the infrastructure nodes (managers, servers, routers, and so on). The ENC infrastructure is managed by Forward, Inc. In this example, we bracket the realm name to make it stand out, but there is no requirement to do so; all realms names are equal. All of the infrastructure computers have certificate names with a common Relative Distinguished Name (RDN) of DC=forwardinc,DC=com.
This is an example realm holding all of the computers that make up the DSM infrastructure. We make a contextual distinction between the ENC infrastructure and the DSM infrastructure to make delineation between realms cleaner. All of the DSM computers have certificates names with the RDN of DC=forward-dsm,DC=com.
This is an example realm holding all of the computers from the 'east' company. All of the east computers have certificates with the RDN of DC=east,DC=com.
This is another example realm holding all of the computers from the 'west' company. All of the west computers have certificates with the RDN of DC=west,DC=com.
In this example, the ENC nodes, whilst they are DSM agent nodes as a minimum as well, are treated as stand-alone devices, which are separate from the DSM nodes. In the DSM ENC environment, the usual requirement is that DSM realm nodes can see and connect to all nodes within individual realms, and that realm agents can connect to nodes in the DSM realm, but members of a managed realm cannot see, or connect to, members of another managed realm.
You must now start defining authorization rules to allow the infrastructure to communicate and also for the realm computers to connect and utilize the virtual network. In the first instance, you must declare the realms to allow them to be used and cross-referenced.
The following is an extract for the authorization rules file: the realm section. It defines the four realms named above.
realm
{Name "[infrastructure]" Notes "ENC infrastructure realm"}
{Name "[dsm]" Notes "The DSM infrastructure realm"}
{Name "east" Notes "East Inc. Contact is admin@east.com"}
{Name "west" Notes "West Inc. Contact is admin@west.com"}
end
The next step is to define the mapping between certificate URIs and the realms themselves. This example uses pattern matching for all entries.
URIMapping
{URI ".*,DC=forwardinc,DC=com" Enabled "1" Type "Pattern" Realm "[infrastructure]"}
{URI ".*,DC=forward-dsm,DC=com" Enabled "1" Type "Pattern" Realm "[dsm]"}
{URI ".*,DC=east,DC=com" Enabled "1" Type "Pattern" Realm "east"}
{URI ".*,DC=west,DC=com" Enabled "1" Type "Pattern" Realm "west"}
end
You will deal with the IP address white-list next. In this example, you are allowing two public IPv4 subnets to access the ENC infrastructure.
IPAddWhiteList
{IPAddress "130\.119\..+" enabled "1" Type "Pattern"}
{IPAddress "141\.202\..+" enabled "1" Type "Pattern"}
{IPAddress "131\.119\..+" enabled "1" Type "Pattern"}
end
The last item to create before you progress to the individual access control entries is an active time-range. For the purposes of this example, the time range is active for all weekdays and covers all twenty-four hours of a day.
TimeRange
{Name "all-days" enabled "1" Hours "00:00 - 00:00" Type "normal" Weekdays "sunday - saturday"}
end
Now you have all the basic elements you need to proceed with the access rules; you can concentrate on the access control entries themselves. In this example, you will mainly use individual access control entries for clarity. In real-world situations, it can be simpler and more efficient to combine several rules into a single rule.
Following is a single access control entry for example purposes only. For all the rules we now discuss, they should be defined as follows - between the TimeACL and end tags - or created in the configuration UI.
This rule, named AC-[infrastructure]-[infrastructure], defines an entry that allows all members of the infrastructure realm to access and authenticate to other members of the infrastructure realm. It references the 'all-days' time range you previously defined so will be active all day, every day.
TimeACL
{Name "AC-[infrastructure]-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "[infrastructure]" SecObjType "realm" SecObj "[infrastructure]" Events "AuthenticatedConnection"}
...
end
You must add similar rules for the other realms; in this case, '[dsm]', 'east' and 'west'. The rules will be identical to those above but with the security principal changed to that of these other realms, as below.
{Name "AC-[dsm]-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "[dsm]" SecObjType "realm" SecObj "[infrastructure]" Events "AuthenticatedConnection"}
{Name "AC-east-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "east" SecObjType "realm" SecObj "[infrastructure]" Events "AuthenticatedConnection"}
{Name "AC-west-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "west" SecObjType "realm" SecObj "[infrastructure]" Events "AuthenticatedConnection"}
You now define some more infrastructure entries. These entries have comments with them to show their purpose. As mentioned before, these could have all been rationalized into a single entry with the Events field set to “ManagerRegisterServer ServerRegisterRouter ManagerRegisterRouter ManagerRegisterAgent”. A benefit of keeping the rules separate is that the verification tools and auditing logging within the ENC subsystems will use the unique rule name when recording why an operation was allowed or disallowed.
; This entry allows all infrastructure nodes to be able to register a server to the manager.
{Name "MRS-[infrastructure]-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "[infrastructure]" SecObjType "realm" SecObj "[infrastructure]" Events "ManagerRegisterServer"}
;
; This entry allows all infrastructure nodes to be able to register a router to the server.
{Name "SRR-[infrastructure]-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "[infrastructure]" SecObjType "realm" SecObj "[infrastructure]" Events "ServerRegisterRouter"}
;
; This entry allows all infrastructure nodes to be able to register a router to the manager.
{Name "MRR-[infrastructure]-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "[infrastructure]" SecObjType "realm" SecObj "[infrastructure]" Events "ManagerRegisterRouter"}
;
; This entry allows all infrastructure nodes to be able to register a client to the manager.
{Name "MRA-[infrastructure]-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "[infrastructure]" SecObjType "realm" SecObj "[infrastructure]" Events "ManagerRegisterAgent"}
Now you must declare the ability to register with the infrastructure nodes for the DSM and managed realms. The following entries provide this configuration.
{Name "SRA-[dsm]-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "[dsm]" SecObjType "realm" SecObj "[infrastructure]" Events "ServerRegisterAgent"}
{Name "SRA-east-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "east" SecObjType "realm" SecObj "[infrastructure]" Events "ServerRegisterAgent"}
{Name "SRA-west-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "west" SecObjType "realm" SecObj "[infrastructure]" Events "ServerRegisterAgent"}
The ENC Gateway routers also require authorization configuration for all nodes that will be connected to, and routed through, them. The following entries define this.
; These entries allow all DSM nodes to be able to connect to routers in the infrastructure realm.
{Name "RAC-[dsm]-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "[dsm]" SecObjType "realm" SecObj "[infrastructure]" Events "RouterAgentConnect"}
; These entries allow all agent nodes from the named realm(s) to be able to connect to routers in the infrastructure realm.
{Name "RAC-east-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "east" SecObjType "realm" SecObj "[infrastructure]" Events "RouterAgentConnect"}
{Name "RAC-west-[infrastructure]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "west" SecObjType "realm" SecObj "[infrastructure]" Events "RouterAgentConnect"}
You have now enough configuration data to allow all ENC nodes from the DSM and managed realms to be able to connect, authenticate and register with all of the nodes in the ENC infrastructure. The next step is to allow name lookup and agent connection functionality. The following entries do this.
There are mirror rules for all nodes: the managed realms are allowed to lookup the names of all DSM ENC-connected computers. And the DSM ENC-connected computers are allowed to look up all members of the managed realms. Rules and the mirror rules must be explicitly specified as shown below.
Note that there are no rules to allow 'east' to see 'west'; and conversely, there are no rules to allow 'west' to see 'east' , so look ups across the realms will not be possible. This namespace separation is vital to the secure operation of the virtual network.
; These entries allow all agent nodes from the named realm(s) to be able to perform lookups of ENC members in the DSM realm.
{Name "NL-east-[dsm]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "east" SecObjType "realm" SecObj "[dsm]" Events "ManagerNameLookup"}
{Name "NL-west-[dsm]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "west" SecObjType "realm" SecObj "[dsm]" Events "ManagerNameLookup"}
; These entries allow all DSM nodes to be able to perform lookups of ENC members in the named realms.
{Name "NL-[dsm]-east" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "[dsm]" SecObjType "realm" SecObj "east" Events "ManagerNameLookup"}
{Name "NL-[dsm]-west" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "[dsm]" SecObjType "realm" SecObj "west" Events "ManagerNameLookup"}
The following entries allow the agents to connect to/from the DSM and managed realms. Again, these entries could have been combined with the previous rule set, but the separation allows for more detailed logging and troubleshooting of rules.
; These entries allow all agent nodes from the named realm(s) to be able to connect to ENC members in the DSM realm.
{Name "ACN-east-[dsm]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "east" SecObjType "realm" SecObj "[dsm]" Events "AgentConnect"}
{Name "ACN-west-[dsm]" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "west" SecObjType "realm" SecObj "[dsm]" Events "AgentConnect"}
; These entries allow all DSM nodes to be able to connect to ENC members in the named realms.
{Name "ACN-[dsm]-east" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "[dsm]" SecObjType "realm" SecObj "east" Events "AgentConnect"}
{Name "ACN-[dsm]-west" enabled "1" RuleType "allow" TimeRange "all-days" SecPrincType "realm" SecPrinc "[dsm]" SecObjType "realm" SecObj "west" Events "AgentConnect"}
That concludes the example rule set.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|