10 Tips de Seguridad
1. Utilizar el mysqld como usuario ordinario.
2. Utilizar GRANT y REVOKE para limitar el acceso.
3. Revisar los privilegios concedidos granted regularmente.
4. Utilizar contraseñas fuertes.
5. Validar todas las entradas.
6. Limitar FILE privilege a los administradores de la base de datos.
7. No indexar los datos confidenciales.
8. Instalar parches en la base de datos y en el sistema operativo (OS).
9. Limit Access to the Database Server to Trusted Devices.
10. Aislar y minimizar el código que interactúa con la base de datos.
1. Utilizar el mysqld como usuario ordinario.
The MySQL daemon, mysqld, should not be run as root. Mysqld has FILE privilege, which allows it to write and read files on the host to any directory accessible to the account running the daemon.
By running mysqld as an ordinary user, one effectively limits the potential directories to which the process can write. If the process is compromised, for example by using a buffer overflow attack, and the attacker is able to write a file to the host, at least the damage will be limited to a subset of files and directories. Had the root account been used, any directory and file on the host would be vulnerable.
2. Utilizar GRANT y REVOKE para limitar el acceso.
Privileges can be granted at several levels. Granting a privilege at the database level applies to all objects in a database; table level grants apply to all columns in a table; and column level grants apply to a single column in a table. Table and column level privileges can be used to finely tune who is granted access to particular pieces of data. These are especially useful when combined with data modeling techniques to limit operations that users are allowed to execute. For example, when a database application must allow a number of different users to write to a table, such as an order table, rather than granting full insert and update privilege to the order table, users may be granted privileges to write to a pending order table which is then read and processed by a trusted procedure that writes transaction data to the order table. In this way, the functional requirement of allowing an arbitrary user to write data to the database does not expose other data to tampering.
Column level privileges are especially useful to limit access to sensitive data. The classic example is the salary column in an employee table. All employees may have access to read most data in the table but the salary column can be limited to just members of a manager group.
3. Revisar los privilegios concedidos regularmente
Database administrators should regularly review group membership and privileges granted to ensure no one has elevated privileges. Just as attackers who breach OS security may seek to create accounts with elevated privileges, the same principles hold with database security. A less malicious scenario is that employees or contractors may leave and their accounts are not removed. Regular reviews of users and granted privileges can help correct this.
2. Utilizar GRANT y REVOKE para limitar el acceso.
3. Revisar los privilegios concedidos granted regularmente.
4. Utilizar contraseñas fuertes.
5. Validar todas las entradas.
6. Limitar FILE privilege a los administradores de la base de datos.
7. No indexar los datos confidenciales.
8. Instalar parches en la base de datos y en el sistema operativo (OS).
9. Limit Access to the Database Server to Trusted Devices.
10. Aislar y minimizar el código que interactúa con la base de datos.
1. Utilizar el mysqld como usuario ordinario.
The MySQL daemon, mysqld, should not be run as root. Mysqld has FILE privilege, which allows it to write and read files on the host to any directory accessible to the account running the daemon.
By running mysqld as an ordinary user, one effectively limits the potential directories to which the process can write. If the process is compromised, for example by using a buffer overflow attack, and the attacker is able to write a file to the host, at least the damage will be limited to a subset of files and directories. Had the root account been used, any directory and file on the host would be vulnerable.
2. Utilizar GRANT y REVOKE para limitar el acceso.
Privileges can be granted at several levels. Granting a privilege at the database level applies to all objects in a database; table level grants apply to all columns in a table; and column level grants apply to a single column in a table. Table and column level privileges can be used to finely tune who is granted access to particular pieces of data. These are especially useful when combined with data modeling techniques to limit operations that users are allowed to execute. For example, when a database application must allow a number of different users to write to a table, such as an order table, rather than granting full insert and update privilege to the order table, users may be granted privileges to write to a pending order table which is then read and processed by a trusted procedure that writes transaction data to the order table. In this way, the functional requirement of allowing an arbitrary user to write data to the database does not expose other data to tampering.
Column level privileges are especially useful to limit access to sensitive data. The classic example is the salary column in an employee table. All employees may have access to read most data in the table but the salary column can be limited to just members of a manager group.
3. Revisar los privilegios concedidos regularmente
Database administrators should regularly review group membership and privileges granted to ensure no one has elevated privileges. Just as attackers who breach OS security may seek to create accounts with elevated privileges, the same principles hold with database security. A less malicious scenario is that employees or contractors may leave and their accounts are not removed. Regular reviews of users and granted privileges can help correct this.
4. Utilizar contraseñas fuertes
Password crackers are readily available on the Internet. Sometimes they are presented as administrator tools for password recovery but regardless of how they are described, these programs can be used to perform dictionary attacks and use other techniques to recover weak passwords. Strong passwords are not words found in the dictionary or simple combinations of words and numbers.
5. Validar todas las entradas
Never allow data input directly by a user to be passed to a dynamic SQL string. SQL injection attacks can be defeated by properly validating input. This includes verifying numeric parameters are actually numbers, that length of input is reasonable, and that strings are escaped to avoid the potential for changing the meaning of a dynamic SQL statement.
6. Limitar “FILE privilege” a los administradores de la base de datos
As noted earlier, the FILE privilege allows users to write files to the host file system. Generally, writing files should only be required when exporting data, which is usually done by database administrators. By limiting access to this privilege, if a database user account is compromised, there is a reduced risk of the attacker being able to write to the host file system.
7. No indexar los datos confidenciales
Recent discoveries by database security researchers indicate that it may be possible to recover confidential data from indexes used to improve performance. By writing data to a database and analyzing the resulting changes, attackers may be able to discover the underlying data used to create an index. This could expose confidential information, such as Social Security numbers and credit card numbers. Rather than index confidential data directly, calculate a hash value using MD5 or other hash function and store that value in a column that is indexed.
8. Instalar parches en la base de datos y en el sistema operativo (OS).
It is important to keep the database and OS patched. Vulnerabilities continue to be discovered and there is no reason to assume that any version of MySQL is “secure enough.”
To reduce risks from database and OS vulnerabilities, follow a patch management process that includes applying the patch to a test server that is as closely configured to the production server as possible. Run a series of regression tests on the test server to ensure that the patch did not break any functions within the database application.
9. Limit Access to the Database Server to Trusted Devices
Database servers should be protected behind DMZ and accessible only to trusted application servers. The database should not be directly accessible from the Internet. Connects to the database should be managed by a proxy application that performs preliminary input validation and limits the types of queries and commands sent to the database server.
10. Aislar y minimizar el código que interactúa con la base de datos.
As much as possible, isolate application code that interacts with the database to a set of
procedures that are called throughout the application. This allows for easier maintenance and can help improve security. Suppose, for example, that a vulnerability is found in a particular type of query and a workaround is proscribed that requires an extra validation check on the command.
Rather than search through all application code looking for instances where the command is used, developers could just update the database procedures.
Fuente:The Essentials Series Messaging and Web Security- vol2-Art15: 10 Tips for Securing MySQL Databases, by Dan Sullivan. Realtime Community
Password crackers are readily available on the Internet. Sometimes they are presented as administrator tools for password recovery but regardless of how they are described, these programs can be used to perform dictionary attacks and use other techniques to recover weak passwords. Strong passwords are not words found in the dictionary or simple combinations of words and numbers.
5. Validar todas las entradas
Never allow data input directly by a user to be passed to a dynamic SQL string. SQL injection attacks can be defeated by properly validating input. This includes verifying numeric parameters are actually numbers, that length of input is reasonable, and that strings are escaped to avoid the potential for changing the meaning of a dynamic SQL statement.
6. Limitar “FILE privilege” a los administradores de la base de datos
As noted earlier, the FILE privilege allows users to write files to the host file system. Generally, writing files should only be required when exporting data, which is usually done by database administrators. By limiting access to this privilege, if a database user account is compromised, there is a reduced risk of the attacker being able to write to the host file system.
7. No indexar los datos confidenciales
Recent discoveries by database security researchers indicate that it may be possible to recover confidential data from indexes used to improve performance. By writing data to a database and analyzing the resulting changes, attackers may be able to discover the underlying data used to create an index. This could expose confidential information, such as Social Security numbers and credit card numbers. Rather than index confidential data directly, calculate a hash value using MD5 or other hash function and store that value in a column that is indexed.
8. Instalar parches en la base de datos y en el sistema operativo (OS).
It is important to keep the database and OS patched. Vulnerabilities continue to be discovered and there is no reason to assume that any version of MySQL is “secure enough.”
To reduce risks from database and OS vulnerabilities, follow a patch management process that includes applying the patch to a test server that is as closely configured to the production server as possible. Run a series of regression tests on the test server to ensure that the patch did not break any functions within the database application.
9. Limit Access to the Database Server to Trusted Devices
Database servers should be protected behind DMZ and accessible only to trusted application servers. The database should not be directly accessible from the Internet. Connects to the database should be managed by a proxy application that performs preliminary input validation and limits the types of queries and commands sent to the database server.
10. Aislar y minimizar el código que interactúa con la base de datos.
As much as possible, isolate application code that interacts with the database to a set of
procedures that are called throughout the application. This allows for easier maintenance and can help improve security. Suppose, for example, that a vulnerability is found in a particular type of query and a workaround is proscribed that requires an extra validation check on the command.
Rather than search through all application code looking for instances where the command is used, developers could just update the database procedures.
Fuente:The Essentials Series Messaging and Web Security- vol2-Art15: 10 Tips for Securing MySQL Databases, by Dan Sullivan. Realtime Community
No hay comentarios:
Publicar un comentario