Consideraciones de Seguridad
Las consideraciones de seguridad desde la perspectica del usuario del API se explicaron en
la lección Miscelánea.
Como desarrolladores de proveedores de servicio, deberíamos tener en cuenta las siguientes
consideraciones adicionales.
Código Privilegiado
La Java 2 Platform,
Standard Edition, define un modelo de
seguridad para que administradores de sistemas y usuarios configuren la política
de seguridad para ejecutar aplicaciones. Deberíamos estar familiarizados con este modelo
de seguridad antes de escribir ningún código del proveedor de servicio. Esta explicación
cubre algunos problemas pertenecientes al código del proveedor de servicio pero no es un
sustituto para que no leamos y entendamos perfectament la
Java Security
Guide.
El modelo de seguridad nos permite marcar secciones de nuestro código como
privilegiadas envolviendo cada sección dentro de un bloque
doPrivileged. El administrador del sistema o el usuario pueden
conceder permisos a nuestro código de forma separada de aquelos que conceden a otros componentes
de la aplicación. Como el proveedor de servicio normalmente se considera código del "sistema" y
se le conceden todos los permisos por parte del administrador y de los usuarios, debemos ser
cuidadosos con los permisos que el proveedor de servicio solicita. O más precisamente, debemos
ser cuidadosos con las secciones de código que ponemos dentro de bloques
doPrivileged. De otro modo, podríamos introducir agujeros de
seguridad que podrían ser explotados por aplicaciones maliciosas.
En general, un bloque doPrivileged no debería ser accesible
públicamente. En vez de eso, debería ser accesible en un ámbito lo más pequeño posible, con el
ámbito de package-private siendo el más amplio recomendado.
El código dentro de un bloque doPrivileged sólo debería realizar
la funcionalidad requerida.
Por ejemplo, nunca deberíamos tener un bloque doPrivileged
para leer propiedades del sistema arbitrariamente, acceder a ficheros locales, o crear
conexiones de red. Por otro lado, podría ser razonable tener un bloque
doPrivileged para leer propiedades específicas del sistema, leer
un fichero de configuración específico, o crear una conexión de red a una máquina local sobre
un número de puerto específico.
En general, siempre debemos al mínimo el número de bloques
doPrivileged. Siempre debemos preguntarnos si es razonable que el
administrador o el usuario conozcan que una aplicación requiere dichos permisos (y por lo tanto
evitar la oportunidad de denegar la petición) o si la acción es lo suficientemente importante
como para que el proveedor deba pedir permiso para realizar la acción en beneficio de la
aplicación.
Puedes ver una descripción general del modelo de seguridad Java y de los bloques
doPrivileged en la página
Java Security
Guide.
Propiedades de Entorno
La lección
Miscelánea habla sobre las
consideraciones de seguridad asociadas con las propiedades de entorno. La sección
Propiedades de Entorno de esta lección
describe cómo un proveedor debería manejar las propiedades de entorno. El principal problema
de seguridad a observar desde esta explicación es que, un escritor de proveedores de entorno,
nunca debería devolver una copia de sus propiedades de entorno de su contexto. En vez de eso,
siempre deberíamos tener un clon o una copia. Esto evitará cualquier corrupción accidental
o provocada del estado de una de las propiedades de entorno del ejemplar
de Context.
Si nuestra implementación de contexto es serializable, deberíamos evitar serializar cualquier
passoword u otras propiedades de entorno sensibles a la seguridad.
Seguridad en Red
Muchos de los servicios de nombres y directorios se acceden a través de la red. Aunque los
datos requeridos están protegidos por la autentificación del servidor y los mecanismos de
control de acceso, algunos protocolos no protegen (encriptan) los datos que envía como
respuestas. Esto no es un problema particular de un cliente usando JNDI sino que es un
problema para cualquier cliente que acceda al servicio. La documentación de nuestro
proveedor de servicio debería describir las implicaciones de seguridad asociadas con el
acceso al servicio correspondiente a través de la red.
Tutoriales
