Muchas
veces, al participar de proyectos de
desarrollo hacemos esfuerzos y los repetimos
una y otra vez, definiendo las mismas
cuestiones entre una aplicación
y otra. Investigando surge una posible
opción que puede ayudar a la
reutilización de soluciones optimizadas
y probadas.
Introducción
En los últimos años, he
tenido la oportunidad de participar
en varios proyectos de desarrollo interno
que, como parte de sus requisitos, debían
incorporar aspectos de seguridad.
Al
ir pasando el tiempo, fueron dándose
varios cambios y avances en lo que respecta
a tecnologías y herramientas
de desarrollo; sin embargo, hay problemas
recurrentes, que repetidamente hicimos
el esfuerzo por solucionar del mejor
modo posible.
Varias
veces me hice la pregunta: ¿habrá
una forma de reaprovechar esta solución
que adoptamos en el futuro?
Por
otro lado, a menudo los desarrolladores
tienen la tendencia de querer reinventar
la rueda (o complicarse sin sentido).
Ese comportamiento los lleva a cometer
errores capitales, en la falsa creencia
de que su solución frente a la
seguridad es la mejor.
Dos
ejemplos típicos de este fenómeno:
1.
Desarrollar algoritmos de encripción
propietarios (seguridad por oscuridad).
2. Desarrollar esquemas de identificación/autenticación
propios de la aplicación.
Para
el ejemplo 1, por más seguro
que uno crea que es su algoritmo, es
un hecho que, en realidad, no lo es.
Lo más lógico, antes de
hacer el esfuerzo de generar un algoritmo,
sería aplicar este esfuerzo a
entender y utilizar implementaciones
de algoritmos estándar, realmente
probados por especialistas y que salieron
airosos frente al escrutinio de éstos.
Para
el ejemplo 2 se está “comprando”
la problemática del manejo de
userID y passwords por parte de la aplicación,
donde en gran parte de los casos las
passwords no están debidamente
protegidas, o son encriptadas propietariamente,
no se protege el canal de autenticación,
etc. Lo más conveniente es tratar
de integrar con servicios de infraestructura
existentes (ejemplo: autenticación
vía dominio Windows, Radius).
Hasta
aquí dos problemas sencillos,
con soluciones casi de sentido común,
sin excesivas complicaciones. Cosas
que la mayoría de nosotros propondría.
Y
aquí vuelve a surgir la pregunta:
¿se podrá reaprovechar
esta solución?
Patrones
de diseño
En
1994 se editó el libro "Design
Patterns: Elements of Reusable Object
Oriented Sofware", escrito por
los famosos Gang of Four*. Fue luego
de la publicación de este libro
que empezó a difundirse con más
fuerza la idea de patrones de diseño.
Resulta
ser que no todos los problemas son tan
simples de resolver y, por cada uno
que se nos presenta, pensamos formas
de resolverlos y tomamos la que consideramos
mejor.
Así,
a medida que vamos ganando mayor experiencia,
nuestro abanico para generar soluciones
a problemas crece, aunque siempre habrá
una solución que es la que mejor
se adapte a la aplicación que
estamos desarrollando. Si la solución
es lo suficientemente genérica
y la documentamos, podemos reutilizarla
y compartirla para resolver de la mejor
manera un problema específico.
Los
patrones de diseño son una abstracción
de una solución en un nivel alto
(soluciones exitosas a problemas comunes).
Las formas de implementar esos patrones
son llamadas estrategias.
Los
patrones solucionan problemas que existen
en muchos niveles de abstracción.
Algunos abarcan las distintas etapas
del desarrollo: desde el análisis
hasta el diseño, y desde la arquitectura
hasta la implementación.
Patrones
de seguridad
Si
extendemos el paradigma de los patrones
de diseño, podrían usarse
patrones específicos para resolver
problemas de seguridad.
Básicamente,
los patrones de seguridad describen
problemas particulares y recurrentes
de seguridad que se dan en contextos
específicos, y presentan esquemas
genéricos bien definidos para
su solución.
En
general, una de las cuestiones que existe
es que los desarrolladores de software
no conocen demasiado de seguridad (o
manejan conceptos erróneos),
y los patrones podrían ser una
forma simple de mejorar su entendimiento
de las problemáticas de seguridad.
En
la actualidad ya hay varios esfuerzos
para la generación de patrones
de seguridad disponibles públicamente
(ver referencias**). Estos patrones
son aplicables a varios contextos o
niveles (algunos exceden a los desarrollos
de software).
Recientemente
se han presentado dos libros sobre esta
temática específica, lo
cual va marcando una tendencia que puede
ser interesante*** .
Conclusiones
Si
bien el uso de patrones todavía
no es masivo, su aplicación puede
llevar a que los equipos de desarrollo
comprendan mejor los puntos que deben
tener en cuenta al crear nuevas aplicaciones.
Contar
con un catálogo de patrones también
evitaría que los desarrolladores
caigan en la tentación de reinventar
cosas que ya existen.
Finalmente,
en teoría, usar patrones permitiría
evitar el “retrabajo” cada
vez que queremos resolver un problema.
Si contamos con una solución
dentro de nuestro catálogo, sólo
habría que concentrarse en la
aplicación de ésta. Si
no contamos con una solución
y se considera que el problema será
recurrente, puede aplicarse un esfuerzo
mayor y generar un patrón genérico
e incorporarlo al catálogo. Al
cabo de un tiempo y al ir madurando,
tendríamos un catálogo
lo suficientemente vasto como para resolver
la mayoría de los problemas en
forma estandarizada y consistente.
Nota
al pie
*Design Patterns: Elements of Reusable
Object-Oriented Software"- Addison-Wesley
Professional Computing Series - January
15, 1995 - ISBN: 0201633612.
**Ver
http://www.securitypatterns.org/, http://www.coresecuritypatterns.com/
y http://www.opengroup.org/security/gsp.htm
***Core Security Patterns : Best Practices
and Strategies for J2EE(TM), Web Services,
and Identity Management" - Prentice
Hall PTR - October 14, 2005.
Security
Patterns : Integrating Security and
Systems Engineering" (Wiley Software
Patterns Series) - John Wiley &
Sons - March 13, 2006.
