viernes, 19 de septiembre de 2008

Pablo Allois nos envía desde Rosario estas sugerencias de seguridad de IIS y SQL Server

Servidor:
  • Deshabilita toda la funcionalidad que no vayas a utilizar
  • Desinstala los componentes que no vayas a utilizar
  • Cerra todos los puertos que puedas en el firewall
  • Si tenes que exponer funcionalidad afuera, si es posible hacelo vía vpn
  • Parchealo

SQL Server:
  • No publicarlo a internet
  • Que el servicio corra con un usuario con minimos privilegios
  • Deshabilita toda la funcionalidad que no vayas a utilizar
  • Utiliza siempre que puedas seguridad integrada y, si es posible, deshabilita seguridad mixta
  • Si es posible deshabilita acceso remoto
  • Como minimo corre "SQL Server Surface Area Configuration"
  • Parchealo

IIS:
  • Que el application pool corra con un usuario con mínimos privilegios
  • Deshabilita toda la funcionalidad que no vayas a utilizar
  • Deshabilita las extensiones que no vayas a utilizar
  • Los usuarios para acceso anonimo del web site tienen que tener los privilegios mínimos, en especial en la base de datos y en el home de tu sitio
  • En el website deshabilita los verbos y las isapi extensions que no vayas a utilizar
  • Parchealo
Administración de la seguridad:
  • Dediquenle tiempo a la administración de seguridad
  • Actualizarse sobre novedades en ataques y vulnerabilidades
  • Revisar logs de IIS - Servidor - SQL y cualquier aplicación que expongan
Espero que les sirva, si tienen ampliaciones o correcciones, por favor déjenlas en los comentarios.

Muchas gracias

Carlos Peix

jueves, 18 de septiembre de 2008

Reunión EAS (Empanadas y Arquitectura de Software) de Agosto

Hola,

Les dejo las fotos de los asistentes a la reunión

De izquierda a derecha: Damian Herrera, Daniel Calvin, Diego Jancic, Leandro Tuttini y Fabio Maulo.

De izquierda a derecha: (alguien me recuerda el nombre de los dos primeros?) Claudio Meschini, Carlos Peix (yo), Santiago Casey, (otro que no recuerdo) y Angel "Java" Lopez

Hablamos varias cosas, pero el debate mas encendido estuvo alrededor de las opciones para construir aplicaciones Web en ASP.NET: WebForms o MVC (ASP.NET MVC y Monorail).

Tambien discutimos un poco sobre algunos preconceptos sobre SOA.

¿Me olvido de algo?

¿Las empanadas? Muuuuuuuuy buenas, por mucho lo mejor de la reunión.

Un Saludo,

Carlos Peix

jueves, 21 de febrero de 2008

Dos jornadas sobre NHibernate en el MUG

Ayer y hoy tuvimos la oportunidad de escuchar a Fabio Maulo y a Darío Quintana (dos "commiters" del equipo de NHibernate), con el silencioso aporte de Diego Jancic.
Una excelente introducción a NHibernate, el resto esta en sus manos.

Mas de 70 personas participaron, un récord absoluto para las reuniones de arquitectura. Un buen trabajo de organización, además (Gracias Oscar, Sandra, Mónica y al MUG).

Fue interesante la modalidad de la presentación: el primer día vimos las bases, la ideología de NHibernate. El segundo día fue a puro Visual Studio, todos los ejemplos fueron presentados utilizando las herramientas de Unit testing para ejecutarlos (aprovechando las capacidades de logging). Esto hizo que Fabio y Darío pudieran moverse ágilmente entre un ejemplo y otro.

"Lean la documentación" fue la última recomendación de los oradores y no puedo mas que estar de acuerdo con esta frase. Lean, investiguen, prueben, es la manera mas rápida y sólida de aprender.

Un agradecimiento a Fabio, por animarse, probo ser un orador divertido. Gracias también a Darío por molestarse viajando más de 1000 kilómetros de ida y de vuelta y a Diego por apoyar a los oradores con los ejemplos.

Pueden descargar desde aquí la presentación y los ejemplos:
http://groups.google.com/group/NHibernate-Hispano/files

Algunos enlaces útiles;
http://groups.google.com/group/NHibernate-Hispano
http://www.nhibernate.org/

Nos vemos en la próxima reunión!

Carlos Peix

jueves, 18 de octubre de 2007

Modelos de datos, muchos

Un catálogo interesante de modelos de datos. Tiene doble utilidad para los que no hablamos nativamente en inglés y necesitamos nombrar objetos y propiedades en ese idioma.

http://www.databaseanswers.org/data_models/index.htm

Nos vemos
Carlos Peix

viernes, 31 de agosto de 2007

Un proyecto interesante de un colega

Hola gente,

Los invito a ver el proyecto de Caludio Meschini, un colega. Vean aquí la explicación que el mismo da de su bebé.

El dice que todavía le falta pulir cosas, pero les viene bien para entretenerse el sábado a la tarde.

Carlos Peix

jueves, 23 de agosto de 2007

Un caso de arquitectura (agil)

Hola gente,

Me parece interesante la lectura este caso de aplicación web (basada en Ruby on rails) por su envergadura.

Carlos Peix

sábado, 18 de agosto de 2007

El principio de las cosas... Parte 2 de 2

En la primer entrega hablamos de Responsabilidad única, Principio abierto / cerrado y el Principio de Sustitución.

Nos quedaron en el tintero, se esperaba que por pocos días, Inversión de dependencia y Segregación de interface.

d - Inversión de dependencia



Modelamos, sea en papel, en UML, en nuestra mente, como sea, lo hacemos. Creamos artefactos, clases por lo general, y relacionamos esos artefactos unos con otros.



Cuando hacemos esto, relacionar artefactos, establecemos dependencia entre ellos. Un artefacto deberá conocer a otro. El artefacto B requiere un artefacto del tipo C y otro del tipo D.

Vamos a implementar un pequeño modulo de registro de eventos para tener un ejemplo concreto de como nos afectan las dependencias en un modelo.

Nuestro módulo de registro incluirá unas pocas clases, veamos un diagrama:


Lo primero que se aprecia es la asignación correcta de responsabilidades, hemos asimilados los principios OOD vistos hasta ahora. :)


Por supuesto siempre existe un contexto, ese contexto nos dará un marco para poder determinar problemas potenciales.

Si miramos el diagrama tenemos una violación potencial al principio Abierto / Cerrado.

Este modulo tiene como fin ser incluido en cualquier aplicación que desarrollemos y su objetivo es poder registrar información en algún dispositivo de salida.

Un ejemplo sería registrar errores en tiempo de ejecución, inicios de sesión por parte de los usuarios de un sistema, lo que creamos necesario.

Ese es mi contexto, puedo decir que mis mensajes serán muy uniformes, esos mensajes forman parte de mi dominio, son un concepto bien conocido, no existen grandes posibilidades de cambio en el corto plazo. Esto es una definición, no una estimación.

Por otra parte esa misma definición me habla de algún dispositivo de salida, allí la cosa es mas abierta, deberé de alguna manera estar preparado al cambio.

Volviendo al diagrama ahora puedo señalar algunas cuestiones:

  1. La clase LogHelper depende de Message
  2. La clase LogHelper depende de TextFile
El primer caso, teniendo en cuenta el contexto, la definición del negocio, esa dependencia no me preocupa. Alguien podría señalar que produce acoplamiento, en mi contexto no lo consideraré como tal. ( No hacer esto podría aportar complejidad innecesaria al modelo, una buena práctica es mantener la simplicidad. )

El segundo caso es más complejo, mi definición habla de algún dispositivo de salida, mi primer dispositivo es TextFile, cambiar o agregar algún otro dispositivo de salida implicará cambios profundos en LogHelper.

Este último problema va más allá del acoplamiento, nuestro modelo esta acoplado y además es rígido.

El principio de Inversión de dependencia nos ayuda a eliminar o acotar este tipo de problemas, que nos dice el principio?

Los módulos de nivel superior no deben depender de módulos de bajo nivel.
Ambos deben depender de abstracciones.

Los detalles deben depender de abstracciones y no lo contrario.

Veamos ahora algunos cambios en el diagrama que reflejen la aplicación del principio.

LogHelper ya no depende de TextFile, lo hace de OutPutProvider, la notación itálica nos indica que es una clase abstracta.

Hemos logrado que nuestro modulo de registro no sea tan rígido, será mucho más simple lograr su reutilización.

Quiero resaltar un concepto, en la definición del principio hablamos de Módulo de Nivel Superior.

Estos son menos propensos al cambio, son los que expresan nuestro negocio, representan el dominio del problema, su mención no es casual.

En cada Nivel atenderemos un Negocio determinado, aplicar Inversión de dependencia implica conocer los límites, el borde de cada nivel.

e - Segregación de interface

Existen situaciones en las que una misma clase será consumida por distintos clientes, agentes que solo necesitan conocer un conjunto acotado de responsabilidades de esa clase. Sin embargo esas clases siguen representando un concepto único en el modelo.

Es una situación ambigua, la clase sigue siendo cohesiva y quienes la consumen manejan un concepto acotado de la misma en el dominio.

Supongamos una clase Cliente, nuestra clase es consumida por agentes que están interesados en distintos aspectos:

Estos atributos parecen estar directamente vinculados con las responsabilidades de Cliente, no hemos violado ningún principio, nuestra clase es cohesiva.

En estos términos veamos ahora como afecta esto a los artefactos consumidores de Cliente.

  1. Despacho
    Solo necesita conocer el Domicilio
  2. BuzonEletronico
    Solo necesita cono cer la dirección electrónica.

Si vamos un poco mas allá nos damos cuenta también que estos artefactos que consumen la clase Cliente manejan conceptos que parciales respecto a la clase que consumen.

Un cambio en Cliente, implica cambios profundos nuevamente, la reutilización de Despacho y BuzonElectronico se ve seriamente limitada, y la lista continúa....

Algo entonces esta fuera de lugar, veamos que nos dice el principio de segregación de interface:

Los clientes no deben ser forzados a depender de interfaces que no utilizan.

Apliquemos el principio, creemos interfaces acotadas que serán consumidas por BuzonElectronico y por Despacho, Cliente ahora implementará esas interfaces.

Tenemos ahora un modelo mas elegante, mas cohesivo, poco acoplado.

Conclusiones:

Los principios de diseño nos permiten adelantarnos a los problemas, son conceptos que debemos manejar en forma natural, debemos integrarlos a nuestra forma de pensar al modelar o implementar aplicaciones orientadas a objeto.

La cuestión no termina aquí, es el comienzo, sobre estos principios se construyen muchos conceptos teóricos mas avanzados, se construyen patrones, etc.

Me despido ahora, nos vemos pronto.