Database security best practices
Important
This content is archived and is not being updated. For the latest documentation, see Microsoft Dynamics 365 product documentation. For the latest release plans, see Dynamics 365 and Microsoft Power Platform release plans.
Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012
If a malicious user were to gain access to the Microsoft Dynamics AX database, that user might gain access to data, including sensitive data such as credit card numbers, bank account numbers, and personal identification numbers. You should deploy the database as described in this section to protect data in your business or organization and reduce the overall attack surface of this core Microsoft Dynamics AX component.
We recommend that you do the following:
Follow SQL Server security recommended practices.
Use the table permissions framework.
Secure the database logs.
Follow SQL Server security recommended practices
We assume that you have followed the recommended transactional SQL Server security best practices described in the article Securing SQL Server. These best practices include:
Platform and network security, including physical, operating system and file security
Principals and database object security
We also assume that security best practices are in place for all functions of SQL Server throughout the environment:
Encrypt sensitive data
We recommend that you implement database encryption to enhance the security of data, including sensitive data, such as credit card numbers, bank account numbers, and personal identification numbers. If your business or organization processes and stores credit card information, we recommend that you adhere to the standards set by the PCI Security Standards Council for securing cardholder data. The PCI Data Security Standard requires the following:
Security standard |
Requirement |
|---|---|
Build and Maintain a Secure Network |
1. Install and maintain a firewall configuration to protect cardholder data. 2. Do not use vendor-supplied defaults for system passwords and other security parameters. |
Protect Cardholder Data |
3. Protect stored cardholder data. 4. Encrypt the transmission of cardholder data across open, public networks. |
Maintain a Vulnerability Management Program |
5. Use and regularly update antivirus software. 6. Develop and maintain secure systems and applications. |
Implement Strong Access Control Measures |
7. Restrict access to cardholder data. 8. Assign a unique ID to each user with computer access. 9. Restrict physical access to cardholder data. |
Regularly Monitor and Test Networks |
10. Track and monitor all access to network resources and cardholder data. 11. Regularly test security systems and processes. |
Maintain an Information Security Policy |
12. Maintain a policy that addresses information security. |
Enabling database encryption directly addresses the requirement to protect stored cardholder data. SQL Server includes an encryption feature called Transparent Data Encryption (TDE). TDE is designed to provide protection for the entire database while it is at rest, without affecting existing applications. Implementing encryption in a database traditionally involves complicated application changes, such as modifying table schemas, removing functionality, and significant performance degradations. Custom schemes are often used to resolve equality searches, and ranged searches often cannot be used at all. Even basic database elements, such as creating an index or using foreign keys often do not work with cell-level or column-level encryption schemes, because the use of these features inherently leaks information. TDE solves these problems by encrypting everything, including all data types, keys, and indexes. For more information, see Database Encryption in SQL Server 2008 Enterprise Edition.
Secure the database logs
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 .NET Business Connector, X++, alerts, or direct access to the database. To protect data, restrict the permissions on the sysdatabaselog table. For detailed information, see Table Properties.