Este post contiene la tercera parte de los tips de seguridad orientados a la protección de su base de datos Oracle:

Cambiar las claves por defecto de los usuarios
La información almacenada en su base de datos puede verse seriamente comprometida si no se han cambiado las claves por defecto de los usuarios. Es recomendado por lo tanto colocar claves diferentes para cada una de las cuentas de los usuarios, sobre todo, si se trata de aquellas empleadas para el desempeño de roles de administración como: SYS, SYSTEM, SYSMAN y DBSNMP, esto, debe ser tomado en cuenta para todo tipo de ambiente, ya sea este de pruebas o de producción.

Si usted está trabajando en una base de datos con versión inferior a 9i, o más bien, si es usted un fanático de Oracle debe considerar también no colocar como claves de las cuentas mencionadas anteriormente CHANGE_ON_INSTALL o MANAGER y sus variaciones como MANAGER1, MANAGER10, etc., adicionalmente, se debe tener cuidado con cuentas como la del usuario SCOTT, la cual, actualmente no trae la clave por defecto que es TIGER pero es necesario asegurar que esté bloqueada y haya sido expirada tal como se explicó en el post Tips de seguridad para su base de datos (Parte II).

Es recomendada la utilización de reglas básicas de administración de claves como: tamaño de la clave, complejidad, etc., por lo que a continuación se detallan algunas reglas que consideramos básicas y deben ser tomadas en cuenta:

• Las claves de los usuarios que posean cuentas administrativas deben ser cambiadas al menos bimensualmente, deben tener una longitud de al menos diez caracteres alfanuméricos, contener letras mayúsculas y minúsculas, tener dígitos y caracteres de puntuación, no deben estar basadas en información personal y no deben ser palabras del diccionario, por ejemplo, una clave fácil de recordar que cumpla con estas características puede ser el título de su canción favorita, una frase célebre, etc., con algunas modificaciones por supuesto como se puede ver en el siguiente ejemplo: “Ecuador Oracle Users Group” es una frase sencilla de recordar para mí por lo que una clave podría ser “EcuOr4cl3UG!”.
• Las claves a nivel de usuario final deben ser cambiadas al menos cada cuatro meses.
• No es recomendado utilizar las mismas claves para el acceso a cuentas de la organización como para el acceso a cuentas de carácter personal, así como tambíen, no es recomendado utilizar la misma clave para ingresar a los diferentes servicios que su compañía otorga.
• No debe compartir las claves con ninguna persona y no debe revelarlas por teléfono, por correo electrónico o por cualquier otro medio.

Debido a los problemas de seguridad reportados con el algoritmo para el manejo de hashing de las claves de la base de datos, Oracle recomienda el uso de características especiales de la base de datos como Oracle Advanced Security, servicio que permite habilitar una fuerte autenticación a los usuarios con la finalidad de proveer una mejor protección ante accesos no autorizados a la base de datos.

Otros puntos a tomar en cuenta que a pesar de ser sencillos muchas veces no se consideran son: se debe evitar que los usuarios que acceden a la base de datos tengan el privilegio de sistema ANY, se debe configurar el parámetro O7_DICTIONARY_ACCESIBILITY a FALSE, lo que permite que solo usuarios autorizados tengan el privilegio de DBA sobre la base de datos, esta última recomendación va principalmente dirigida para usuarios de Oracle 8i, ya que ese parámetro viene configurado por defecto con el valor de TRUE.

Continuará …

Author: Paola Pullas

Como para el año nuevo siempre hay cosas nuevas el Ecuador Oracle Users Group (ECUOUG) pone a su disposición un foro donde ustedes podrán hacer preguntas a nuestros colaboradores y a todo aquel que sepa la respuesta y quiera apoyar a la comunidad de usuarios Oracle.

Para ingresar a nuestro foro pincha en el siguiente link: http://www.ecuoug.org/forum/, una vez ahí el primer paso es registrarte y listo!!, puedes participar.

“An expert is a person who has made all the mistakes that can be made in a very narrow field”.

Niels Bohr

Una de las primeras cosas que debe tomarse en cuenta antes de iniciar un proyecto de TI es la realización de un análisis de costo beneficio que permita determinar si la inversión de tiempo y dinero que se hará tiene sentido para la organización, para esto, es común que se nos solicite un análisis del retorno sobre la inversión (ROI) del proyecto, sin embargo, en el camino debemos enfrentar algunos inconvenientes como por ejemplo que los resultados del análisis ROI pueden ser cambiados realizando ajustes a los puntos que se hubieren asumido, que los beneficios intangibles por lo general no son valorados e incluso no suelen ser incluídos en el análisis, que es complicado realizar estimaciones de como la tecnología permitirá incrementar las ganancias de la organización, etc.

La mayor parte de proveedores de tecnología publican en sus sitios web análisis ROI para productos específicos e industrias específicas, lo cual puede ser de ayuda, sin embargo, en este tipo de análisis se puede palpar claramente como realizando ajustes los resultados pueden ser diferentes, para dar un ejemplo, Microsoft ha publicado un sinnúmero de análisis ROI que muestran asombrosamente que la implementación de Linux es mucho más costosa que la de Windows, y también podemos encontrar lo contrario, análisis que muestran que Linux es mucho menos costoso que sus competidores, ahora, nosotros como miembros de los departamentos de TI debemos tener muy claro que los puntos de análisis para estos estudios aplican solamente a cierto tipo de compañías y bajo ciertas condiciones específicas por lo que lo más aconsejable es que sea usted quien realice su propio análisis y lo ajuste a las condiciones de su organización.

En este post pondremos enfoque en las consideraciones que deben tomarse en cuenta para realizar un análisis ROI en proyectos Open Source, para esto, es necesario tomar en cuenta que la fórmula de cálculo es muy parecida a la que se utiliza en el manejo de proyectos de software comercial:

ROI = (Ganancia + Ahorros) / (Costos de evaluación + Costos de licencias y mantenimiento + Costos de instalación y configuración + costos de integración y personalización + Costos soporte y operación)

A continuación se detallan algunos puntos a tomar en cuenta previo a la realización de este tipo de análisis:

• La naturaleza de los costos del software comercial y el open source es completamente diferente, por lo que, para la realización de un análisis ROI se debe tomar en cuenta otros factores como: los ahorros que se obtienen para la organización fruto de la implementación de un software específico en términos de confiabilidad, disponibilidad, procedimientos de mantenimiento, etc., los cuales son importantes a pesar de ser difíciles de cuantificar.
• El tiempo y costos de evaluación del software open source pueden ser mayores que el del software comercial, esto se debe a que los proveedores de software comercial invierten mucho dinero en whitepapers, material de mercadeo, conferencias y otro tipo de contenido que permita promocionar sus productos, mientras que para el software open source existe muy poco material que explique porque se necesita el software, por esta razón, la realización de pruebas de este tipo de productos involucra que el staff de TI de su organización esté comprometido en la investigación y comprensión de la funcionalidad del producto con la finalidad de determinar si lo que se está evaluando cubre las expectativas y requerimientos de la organización. En base a esto, es claro entonces que el número de recursos que se tenga que emplear para un prototipo con software open source es mayor que el que se usaría para probar software comercial, pero a cambio se puede lograr una mayor comprensión del software y como éste satisface los requerimientos de la compañía.
• La implementación de un prototipo con software open source de manera general estará liderada por el staff técnico de la organización debido a la complejidad que esto representa mientras que en el caso del software comercial la implementación puede estar liderada por el staff comercial, por esta razón, es necesario asegurarse que en ninguno de los casos se produzca un rompimiento del lazo negocio – tecnología ya que los dos puntos se complementan en la fase de evaluación de productos.
• El software open source de manera general significa un ahorro en el tema de licenciamiento de los productos, ya que por ejemplo el software comercial implica que tengamos que pagar un monto correspondiente al licenciamiento de los productos, a lo que se suma el monto correspondiente al mantenimiento lo cual corresponde incluso hasta un 22% del monto pagado por las licencias. Lo expresado anteriormente no ocurre en el caso del software open source donde se pagan ciertos fees o cantidades de dinero pero con un enfoque diferente, por ejemplo: Red Hat Enteprise Linux ofrece servicios de soporte por niveles a monto de dinero pero no se tiene la figura de compra de licenciamiento del producto. Ahora, esto no quiere decir que un ahorro en las licencias nos garantice que el software open source es la solución más adecuada para nuestra organización, siempre antes de realizar una adquisición es necesario:
  Analizar si la organización tiene la necesidad de adquirir el producto
  Analizar si la oferta del proveedor es la mejor opción para la organización
• Otros puntos a tomar en cuenta durante un análisis ROI son los costos de instalación y configuración y de integración y personalización de los productos. Aquí es necesario tomar en cuenta que si bien el software open source parecería más susceptible a generar problemas durante esta fase, también es cierto que ya se cuenta con productos muy estables en el mercado como por ejemplo: Red Hat, Suse, Jboss, etc., los cuales cuentan con servicios de suscripción de soporte, aliados de negocios calificados, documentación, presencia en el mercado, etc., lo cual disminuye los riesgos en estas fases de implementación de los proyectos, esto obviamente no es general y todavía existen productos no muy maduros en el mercado que implican que los tiempos asignados a los proyectos sean mucho mayores que si se los realizara con software comercial.
• Un punto de discusión en este tipo de análisis son los costos asociados a la operación y mantenimiento del software, lo cual desde mi punto de vista es lo mismo tanto para el software comercial como para el software open source ya que una vez que se ha pasado por las fases de instalación, configuración e integración, el software es solo eso, software, no importa si es open source o no. Un punto que si tiene mucha relevancia y está muy asociado a este tema es el nivel de conocimiento del staff de IT ya que si este es muy bajo, el mantenimiento y operación de cualquier tipo de software puede considerarse un problema.

En base a los puntos expuestos anteriormente se puede ya empezar a realizar un análisis ROI propio y en esto insistimos, no es la mejor opción basar sus decisiones en los análisis publicados por su proveedor ya que no reflejan la realidad de su organización.
La realización del análisis ROI puede ayudarle a identificar los verdaderos costos y riesgos de un proyecto y ayudarle a su departamento de IT a prepararse para ello. Ahora, para comenzar abra su hoja de cálculo e ingrese la fórmula que le hemos dados al inicio de este post, no sin antes colocar un periodo de análisis por ejemplo de tres años, esto es, debería tener en cada fila las ganancias y costos asociados al proyecto (creación de un ambiente de prueba, instalación y configuración de software, tiempo del staff de IT empleado en la elaboración de prototipos, etc.) y en cada columna representar el tiempo de análisis.

Si necesita ayuda con este tema del ROI coloca tus comentarios o escríbenos.

Author: Paola Pullas

Muchos creen que las personas que apoyamos el Software Libre somos fanáticos y que vamos en pos de una corriente, pero la verdad es muy distinta.

Las personas que por lo general utilizan Software Libre escogen sobre todas las cosas la calidad, y aunque todos queremos calidad en nuestras vidas no siempre sabemos diferenciarla o medirla de la manera más adecuada, siendo uno de los factores influyentes el completo desconocimiento de las alternativas presentes en el mercado, las mismas, que en muchas ocasiones son mejores que el software que hemos estado acostumbrados ha utilizar de manera rutinaria, por eso, si nos preguntamos por que un usuario Mac jamás dejará de serlo es simplemente por la calidad.

La misma medida es posible tomar en GNU/Linux, claro, que con una porcentaje de aproximadamente el 30% de personas que desisten de utilizarlo en el primer intento.
¿A qué se debe este porcentaje?
La única explicación que me ha convencido del todo es que las personas cuando hablamos de software estamos muy acostumbradas al facilismo. No estoy seguro, o mejor dicho no recuerdo que tan difícil se me hizo el cambio, pero si recuerdo y muy claramente que mi primer tropiezo con GNU/Linux fue el módem, y por supuesto, trabajé mucho para poder conectarlo y lo logré a medias, ya que mi módem como el de la mayoría era un Winmodem, por lo tanto, muy difícil de configurar en GNU/Linux. En aquella época estaba utilizando Red Hat Linux 9, para ese entonces, lo último que había liberado Red Hat, ¿la solución más rentable a mi problema?, salir a la calle y comprar un módem de verdad. Estoy completamente seguro que no es la opción que todos quisiéramos, pero en mi caso, el costo de un módem nuevo compatible con Linux, abarató algunos días de asistir al psicólogo para explicarle mi problema con Microsoft y mi cambio a GNU/Linux.

En realidad, la mejor solución hubiera sido que mi módem y el resto de periféricos se conectasen prácticamente sin dolor, pero todavía no llegamos a ese punto. Por supuesto, si lo vemos desde esa perspectiva, para la mitad de usuarios que se aventuran por usar GNU/Linux el simple hecho de no poder instalar un periférico es razón suficiente para decir “Linux no sirve”, y pues creo que están en todo su derecho, pero de nuevo, si lo vemos más fondo podemos concluir que el costo de configurar un sistema operativo GNU/Linux y contar con todas las seguridades y la estabilidad es más que suficiente para optar por el cambio y tratar de armarnos de paciencia cuando estos pequeños problemas ocurren ya que el resultado final será verdaderamente agradable.

A nivel empresarial estos problemas por lo general no ocurren ya que actualmente contamos con distribuciones muy sólidas que brindan un servicio de soporte al producto gracias a que las empresas ha tomado en serio y muy en serio a GNU/Linux, en este campo, sin desmerecer a otros proveedores, Red Hat ha sido el caudillo del movimiento hacia el cambio, gracias a su afinidad con muchas empresas del mercado que han certificado sus aplicaciones para esta plataforma, lo cual ha permitido crear un modelo de negocio sustentable, orientado a servir y seguir entregando productos de calidad lo que ha puesto en evidencia que se puede tener un sistema operativo completamente libre y mitigando los problemas de compatibilidad, accesibilidad y soporte, paradigmas típicos del Open Source. A pesar de esto, en un momento la comunidad vio con ojos de recelo el paso de Red Hat a un modelo netamente comercial pero al transcurrir los años la misma comunidad se ha dado cuenta que Red Hat no existiría sin la comunidad, a lo que se suma que la comunidad se alimenta de los desarrollos que se gestan en Red Hat.

La decisión de liberar sus fuentes, el apoyo a la Fundación Fedora, el aporte a un sin número de características de las cuales se ven beneficiados los clientes permiten tener un sistema operativo con una filosofía y calidad únicos que a su vez indica el total compromiso de Red Hat con la comunidad Open Source. De toda esta sinergia han nacido proyectos como Whitebox Linux, CentOS y muchos otros que permiten el contínuo desarrollo de una comunidad que crece a mayor velocidad cada día.
La ventaja de este movimiento es el desarrollo de drivers y aplicaciones compatibles con GNU/Linux que pueden ser utilizadas por otros proyectos, aunque, es cierto que si deseo contar con todas las actualizaciones, los drivers, aplicaciones certificadas y el mejor soporte a nivel mundial, debo utilizar Red Hat Enterprise Linux, a un costo mínimo en comparación a lo que se recibe.

Las empresas han tomado estas características de Red Hat con mucho agrado y cada día se ve como el modelo de suscripciones de Red Hat está en aumento, empresas de la talla de Amazon, Petrobras, etc., han confiado sus sistemas a GNU/Linux y específicamente a Red Hat Enterprise Linux.

Lo único que necesita GNU/Linux es contar con esa facilidad que los usuarios finales reclamen y veremos como toda esa calidad pasa a manos de un público muy exigente.

Author: Christian Pazmiño

Este post contiene la segunda parte de los tips de seguridad orientados a la protección de su base de datos Oracle:

Bloquear y expirar las cuentas de usuario creadas por defecto
La base de datos Oracle instala algunas cuentas de usuario por defecto, la mayoría de las cuales, después de una instalación exitosa son bloqueadas y expiradas de manera automática por el utilitario Oracle Database Configuration Assistant.

En el caso de que se haya realizado una instalación manual, esto es, sin la ayuda del utilitario de instalación, las cuentas de usuario que se crean por defecto no son bloqueadas, por lo que, podrían ser utilizadas para lograr un acceso no autorizado a los datos. De igual manera, se debe tomar en cuenta que la instalación de productos y componentes adicionales implica la generación de cuentas de usuario adicionales, algunas de las cuales serán bloqueadas solo si se está utilizando el utilitario de instalación, caso contrario, será necesaria la utilización de las herramientas de gestión de claves y/o sentencias SQL que proporciona Oracle para el efecto.

A continuación se detallan por versión de base de datos las cuentas de usuario creadas por defecto para una instalación de la versión Enterprise Edition:

Oracle 8i Release 8.1.7.3 Enterprise Edition
ADAMS, AURORA$JIS$UTILITY$, AURORA$ORB$UNAUTHENTICATED, BLAKE, CLARK, CTXSYS, DBSNMP, JONES, LBACSYS, MDSYS, ORDPLUGINS, ORDSYS, OSE$HTTP$ADMIN, OUTLN, SCOTT, SYS, SYSTEM, TRACESVR

Oracle 9i Release 1 Enterprise Edition
ADAMS, AURORA$JIS$UTILITY$, AURORA$ORB$UNAUTHENTICATED, BLAKE, CLARK, CTXSYS, DBSNMP, JONES, OE, HR, LBACSYS, MDSYS, OLAPSVR, OLAPSYS, ORDPLUGINS, ORDSYS, OSE$HTTP$ADMIN, OUTLN, PM, QS, QS_ADM, QS_CB, QS_CBADM, QS_CS, QS_ES, QS_OS, QS_WS, SCOTT, SH, SYS, SYSTEM

Oracle 9i Release 2 Enterprise Edition
ADAMS, CTXSYS, DBSNMP, HR, LBACSYS, MDSYS, ODM, ODM_MTR, ORDPLUGINS, ORDSYS, OUTLN, PM, QS, QS_ADM, QS_CB, QS_CBADM, QS_CS, QS_ES, QS_OS, QS_WS, SCOTT, SH, SYS, SYSTEM, WKPROXY, WKSYS, WMSYS, XDB

Oracle 10g Release 1, Release 2 Enterprise Edition
ANONYMOUS, CTXSYS, DBSNMP, DIP, DMSYS, EXFSYS, HR, LBACSYS, MDDATA, MDSYS, MGMT_VIEW, ODM, ODM_MTR, OE, OLAPSYS, ORDPLUGINS, ORDSYS, OUTLN, PM, QS, QS_ADM, QS_CB, QS_CBADM, QS_CS, QS_ES, QS_OS, QS_WS, RMAN, SCOTT, SH, SI_INFORMTN_SCHEMA, SYS, SYSMAN, SYSTEM, TSMSYS, WK_TEST, WKPROXY, WKSYS, WMSYS, XDB

Con base en esto, es necesario entonces revisar como mínimo estas cuentas de usuario y proceder a verificar si se las está utilizando, caso contrario, dichas cuentas deben ser bloquedas para evitar accesos no autorizados a la base de datos.

Continuará …

Author: Paola Pullas