Hardware: es muy básica esta primera aproximación pero todo LanRoom o sitio en el cual estén ubicados los servidores deberá tener llave y la misma deberá estar en manos de los responsables de la red o personal de soporte técnico, y su acceso restringido. Si bien esto puede resultar exasperantemente obvio, no siempre se cumple esta norma. Además, hay que cuidar la seguridad dentro del mismo recinto en cuanto a electricidad, fuego, humedad y cualquier otro factor que pueda alterar / destruir el mismo. Es indispensable contar con alarmas, un efectivo sistema de estabilización de la tensión, un sistema de suministro ininterrumpido de electricidad, una temperatura constante (refrigeración y calefacción) y esquema de ventilación.
Software: tanto el sistema operativo del servidor como el mismo SQL Server deberán mantenerse siempre actualizados con los service packs y hotfixes que se publiquen. Por otro lado, es altamente recomendable la actualización del BIOS del servidor a medida que el fabricante libere actualizaciones para el mismo.

Todo esto hará que los servidores funcionen sin inconvenientes ya que un SQL Server esta orientado a brindar un servicio 24 x 7 x 365.

La integración en seguridad entre Windows NT / 2000 y SQL Server es altísima y, por ende, muchos aspectos que afectan a la misma se originan y controlan en el propio sistema operativo. Los usuarios del dominio (o de otro dominio con acceso a este servidor) deberán observar unos lineamientos básicos de seguridad como son:

Todo usuario deberá estar protegido con un password (no admitir passwords en blanco).
Las contraseñas deberán caducar cada cierto tiempo.

Se deberá habilitar la auditoría para registrar los inicios de sesión no-válidos. Importante: que haya una persona encargada y responsable de revisar los logs diariamente o esto no tendra sentido.

Por otro lado, grandes fallas de seguridad vienen tambien por el diseño de la red y su estructura defensiva contra accesos externos: hablamos de firewalls. Hoy por hoy, toda empresa que necesite un motor de datos del tamaño de un SQL Server tiene acceso a internet y es importantísimo estar cubierto. Esta guía no apunta a cubrir la seguridad de la red en sí, pero es algo que habrá que cuidar mucho ya que tendrá un impacto directo sobre el servidor.

Backup del servidor Windows NT / 2000 a nivel configuración (usuarios, permisos, etc.) para poder restaurar eso en caso necesario.

Lo ideal seria que el servidor en el cual este instalado el SQL Server este protegido por un plan de Disaster-Recovery; esto es, un esquema de recuperación en caso de desastre. Que se considera desastre ? Planteando un caso extremo: si se incendia el servidor; en cuanto tiempo estara operativo un nuevo server ?.

Hablando del SQL Server en sí:

Se debe utilizar como esquema de seguridad de SQL la seguridad de Windows solamente y solo en casos realmente necesarios y justificables utilizar la seguridad de SQL y Windows a la vez. Esto es debido a que el control que se puede ejercer sobre las cuentas de usuario de Windows es mucho mayor que el admitido por SQL (cantidad de reintentos, bloqueos, etc, ...).

Es recomendable que los permisos dentro del servidor se asignen mediante roles y grupos de Windows y no a usuarios directos, ya que esto hará más fácil la tarea de administración. Además, de esta forma se evita con mayor facilidad los problemas de permisos opuestos.

Toda cuenta de acceso a SQL Server debe tener password (esto esta íntimamente ligado a la seguridad de la red previamente mencionada), sea de Windows o de SQL Server.

Microsoft ofrece una herramienta para ayudar en estos casos. El Microsoft Baseline Security Analizer esta desarrollado para inspeccionar y generar un reporte cubriendo un amplio espectro en la seguridad. Se lo puede descagr de manera gratuita de:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/Tools/MBSAhome.asp

Este software permite chequear el nivel de la actualización de la plataforma asi como también fallas y debilidades de configuración y seteos.

Contar con un backup adecuado. Todas las bases de datos alojadas en el servidor tienen 'algún' tipo de valor y, por lo tanto, deben tener una política de backup que las cubra. Se debe apuntar a desarrollar un esquema tal que en cualquier momento se pueda detener el servidor, bajar el backup y que la pérdida de datos sea mínima tendiendo a nula. Es importantísimo automatizar este proceso; cuanto menor sea la interacción humana, mejor. Algo que se debe tener siempre presente: en todo esquema de backup puede haber pérdida de datos; la meta es que sea mínima. Toda copia deberá tener registrada su fecha de caducación; es decir, hasta que fecha esa copia es válida de ser usada, para protegernos de restores de datos fuera de vigencia. Por otro lado, es altamente recomendable mantener en un almacenamiento externo al edificio (off-site) un juego actualizado de copias.

PERFORMANCE.

La configuración de hardware del servidor es fundamental a la hora de la performance, pero no es el único factor interviniente.

Algo que se puede verificar y subsanar rápidamente es que SQL Server sea la única aplicación server corriendo en esa máquina. Además, evitarle la carga de validación de usuarios y demás tareas administrativas. En definitiva, debería ser un member server del dominio con dedicación absoluta al SQL Server.

Es un error (si se lo puede llamar error) el pensar que una CPU potente aumentará el rendimiento. Si bien hay un regusto de razón al hablar de un sistema mono-procesador, siempre va a ser mejor contar con dos procesadores rápidos que no necesariamente sean lo último en el mercado que con un procesador que sea lo último disponible en CPUs.
SQL Server hace un muy intensivo trabajo de lectura / escritura en caché y disco debido a su actividad natural y no siempre se sacará ventaja por contar con un procesador extremadamente veloz para cálculos con precisión de 15 decimales. En cambio, es terriblemente sensible a la cantidad de memoria física instalada en el sistema y a la cantidad y tipo de almacenamiento disponible. Por ende, muchas veces las mejoras de hardware vienen por agregar memoria antes que un upgrade del procesador. De todas maneras, la mejor herramienta para determinar el cuello de botella es el Performance Monitor.

Un plan de mantenimiento completo es fundamental para las bases de datos instaladas. La frecuencia de ejecución que se especifique dependera directamente de la actividad de la base. Es decir, una base cuyas tablas tienen una muy frecuente actualizacion deberá ser mantenida más frecuentemente que aquella cuyos cambios sean mínimos.

Las bases que son de solo lectura para el sistema (bases de datos históricos, por ejemplo) conviene que se seteen de solo lectura ya que las conexiones se acelerarán al evitarse las sobrecargas por posibles bloqueos.

Ahora, es importante dejar muy en claro que nada de esto ayuda si el código ejecutado en el servidor es deficiente. Contra la mala programación no hay otra defensa que la re-escritura de los procesos y, a veces, un rediseño de la base.

Para cualquier tipo de sugerencia, colaboración o comunicación, diríjanse a

webmaster@helpdna.net