The first step toward helping to secure Microsoft Dynamics AX is to make sure that it is deployed in a secure environment. For a network connected to any other network, including the Internet, extranets, and other internal networks, this means making sure that sufficient measures are taken to keep the network secure from external threats.
Additionally, whenever you make a change to the system, part of your planning should include attention to helping make the new system secure. For more information, see the Microsoft Dynamics AX Installation Guide.
For the latest information about security, see the TechNet Security Center. It provides security tools, security response information, such as security bulletins and virus alerts, and the most prescriptive security guidance Microsoft has to offer to help IT Professionals in securing their systems.
Microsoft Dynamics AX requires Active Directory to support its user structure. The Active Directory should be configured correctly to make sure it complies with your company’s security policies regarding user access. The computers that are running Microsoft Dynamics AX must have access to computers in the same domain running Active Directory configured in native mode. It may be the case that not all network users need access to Microsoft Dynamics AX. Therefore, it is more secure to simply not grant them access in Active Directory. For more information about how Microsoft Dynamics AX integrates with Active Directory for security, see Working with users from Active Directory. For the latest recommendations for configuring Active Directory, see the Microsoft Windows Server 2003 Active Directory Technology Center.
For deployments that include the Enterprise Portal component, there are additional environmental security issues to address. The network should have a firewall. It should also have one or two domain controllers. When there are two domain controllers, one should be in the internal network and the other in the perimeter network.
This configuration is performed with Active Directory. For more information about how to set up security for Enterprise Portal, see Configuring Enterprise Portal security in the Enterprise Portal Administration Guide.
When the Application Object Server (AOS) is installed, the user for the AOS service is set to either the Network Service account or a domain account. If you decide to use a domain account for the AOS service, you should make sure that the new account has the lowest (most restrictive) possible privileges, to help reduce the risk of processes that could cause harm to the server. For more information, see the Microsoft Dynamics AX Installation Guide.
Database logs can contain sensitive data. By default, any database log that is created can be queried by any user who has access to the database. Users can query the log by using Business Connector, X++, alerts, or by using direct access to the database. To protect data, restrict the permissions on the sysdatabaselog table. For detailed information, see Table Properties in the Microsoft Dynamics AX SDK.
Use the following security best practices to prevent users from submitting to batch groups that are processed with a higher permission level:
- Limit the number of user groups that have access to the > > menu item and the > > menu item. For more information, see Manage security permissions for user groups and domain combinations.
- Apply record level security restrictions on the BatchGroup table. For more information, see Manage record level security.
To help prevent denial of service attacks on your Enterprise Portal, you can adjust the values of the following configuration commands in the configuration file of the Application Object Server (AOS):
- MaxConcurrentGuestSessions – This value controls the maximum number of concurrent Guest (anonymous user) sessions. The default value is 65535. By decreasing this value, you can reduce the number of sessions that an attacker can hold. After you set this value, you must restart the AOS for the change to be applied.
- MaxConcurrentWebSessions – This value controls the maximum number of concurrent Enterprise Portal sessions that includes Guest sessions. The default value is 65535. By decreasing this value, you can reduce the number of sessions that an attacker can hold. After you set this value, you must restart the AOS for the change to be applied.
- MaxMemLoad – This value controls the maximum amount of memory usage (the maximum percentage of physical memory that is used on the computer). The default value is 100. By decreasing this value, you can reduce the number of sessions that an attacker can start. After you set this value, you must restart the AOS for the change to be applied.
For detailed information about how to use MaxConcurrentGuestSessions, MaxConcurrentWebSessions, MaxMemLoad and other configuration commands, see Using the command line to manage the AOS.
The following are best practices for administering security of your Microsoft Dynamics AX environment:
- All Microsoft Dynamics AX user accounts should reside in restricted, well-defined user groups. A domain user account should be created and used to run Microsoft Dynamics AX.
- We recommend restricting user group access to the Admin domain. To do this, in the form, select a non-administrator user group and select the Admin domain. On the tab, click . Repeat this procedure for each non-administrator user group. Create separate domains containing just the companies that users should have access to.To prevent user groups from accessing information in domains that they do not belong to, set the permission level on the Open domain access security key to .
- Following the principle of least privilege, anyone using the Microsoft Dynamics AX system should have minimal rights. If you are uncertain about whether to allow permission to a certain item, leave the permissions level set to . It is better to deny permission to an item and force an individual to request permission for their group than to grant permission to an area that a group should be unable to access.
- Restrict the number of users who are members of the Administrators group, which has access to all fields, tables, reports, and modules in Microsoft Dynamics AX by default. If users are made members of theAdministrators group, they can potentially view reports or data that they should not be able to see, or change configurations and business logic in the system. Ideally, only those individuals who are configuring and administering Microsoft Dynamics AX should be members of the Administrators group. Access in the Administrators group cannot be altered.
- Work with managers who oversee the different groups in the business or organization to determine permission levels. For example, work with a manager in the Finance department to determine permission levels for the Finance group or groups. The manager knows which groups should have permissions to items like General ledger and Bank, including permissions on child nodes.
- Passwords should never be used across systems and domains. For example, an administrator responsible for two domains may create Domain Administrator accounts in each that use the same password, and even set local administrator passwords on domain computers that are the same across the domain. If this happens, a compromise of a single account or computer could lead to a compromise of the whole domain. Passwords should never be reused in this manner.
- Service accounts should never be domain administrator accounts, and they should be limited in privilege as much as possible. Domain Administrator accounts are typically used as service accounts for common services such as backup systems. However, it is a security risk to use Domain Administrator accounts as service accounts, because the password must be stored, or cached, locally on every computer where the service resides. The password can easily be retrieved by anyone with administrative rights over the computer. If this happens, the compromise of a single computer could lead to a compromise of the whole domain. Service accounts should never be domain administrator accounts, and they should be limited in privilege as much as possible.
- If you change permissions for a user group, especially if you demote permissions, restart the server after you make the change. If you do not restart the server, members of the group might keep their former permissions until the next time that the server is restarted.
- As a best practice, ask members of a group to log off Microsoft Dynamics AX before changing permissions and inform all Microsoft Dynamics AX users of the impending server restart. If it is necessary, before changing user group permissions, select users in ( > Common Forms > ) and then click .For more information, see Remove users.
No comments:
Post a Comment
Your comment will be appreciated.