Download Seguridad en Java Agenda

Módulo IV.- Seguridad Aplicativa
Seguridad en Java
Módulo IV.- Seguridad Aplicativa
Agenda
•
•
•
•
•
Objetivo.
Cómputo Distribuido.
Arquitectura J2EE.
Introducción a la seguridad con Java.
Recursos, Directores y Recursos.
1
Módulo IV.- Seguridad Aplicativa
Objetivo
• Conocer la arquitectura general de una
aplicación desarrollada con Java con J2EE.
• Introducir los conceptos de seguridad que se
manejan en una aplicación basada en J2EE.
Módulo IV.- Seguridad Aplicativa
Cómputo distribuido
2
Módulo IV.- Seguridad Aplicativa
Cómputo distribuido
• Se basa en el principio de dividir una tarea
en tareas más pequeñas.
• Cada tarea se puede asignar a diferentes
equipos “más pequeños” que funcionan en
conjunto.
• El cómputo distribuido permite reutilizar
componentes, ya que estos tienen bien
definidas sus interfaces.
Módulo IV.- Seguridad Aplicativa
Cómputo distribuido
• Soporte a la interoperabilidad y
portabilidad.
• Seguridad en el acceso a las aplicaciones.
• Los sistemas distribuidos ofrecen
transparencia.
• Se programa de manera modular. Permite
separar cada capa del sistema.
3
Módulo IV.- Seguridad Aplicativa
Guías de diseño
• Las aplicaciones deben ser modulares, dividiendo:
– Interfaz de usuario.
– Reglas de negocio.
– Datos.
• Esto brinda flexibilidad al mantenimiento del sistema.
• El diseño se recomienda sea realizado basado en
componentes.
• La funcionalidad final se alcanza a través de diferentes
tareas internas que son implementadas por los
componentes.
• Los componentes pueden ser comprados o
desarrollados de manera interna.
Módulo IV.- Seguridad Aplicativa
Guías de diseño
• El crear un componente demasiado extenso, puede
provocar un gran esfuerzo para modificar su
funcionamiento.
• Se recomienda que las capas que componen una
aplicación sean independientes unas de otras.
– Procedimientos almacenados hacen dependiente la capa de
lógica de negocio de la de datos.
• Los componentes deben se reutilizables. Se deben
separar de acuerdo a los servicios que ofrecen.
• Se debe soportar la escalabilidad.
– Usar pool de conexiones.
– Uso de cache.
– “Granjas” de servidores.
4
Módulo IV.- Seguridad Aplicativa
Arquitectura J2EE
Módulo IV.- Seguridad Aplicativa
Introducción
• Plataforma que permite el desarrollo de aplicaciones
basadas en componentes, multicapa y distribuidas,
para ofrecer el soporte al cliente y al servidor.
• Beneficios.
– Diseño y desarrollo sencillo.
– Se puede seleccionar, servidores, herramientas y
componentes.
– Escalable.
– Modelo de seguridad.
– Recursos para Integrar aplicaciones empresariales. (EIS)
5
Módulo IV.- Seguridad Aplicativa
Introducción
• La arquitectura J2EE esta basada en Java y utiliza
los estándares del mercado, lo que le permite
interactuar con el servidor de aplicaciones.
Módulo IV.- Seguridad Aplicativa
Ventajas del modelo de desarrollo
• El modelo de desarrollo es estandarizado lo que
permite seleccionar:
– Servidores.
– Herramientas.
– Componentes.
• Modelo escalable.
– Contenedores diseñados
Para proveer escalabilidad
6
Módulo IV.- Seguridad Aplicativa
Ventajas del modelo de desarrollo
• Modelo de seguridad incluido.
– Los parámetros de seguridad se configuran
durante el proceso de instalación de la
aplicación.
– Permite la configuración de la aplicación de
manera independiente del código.
• El modelo permite la integración con los
sistemas de información existentes a través
del J2EE Connector Architecture JCA.
Módulo IV.- Seguridad Aplicativa
Roles de la plataforma
• Proveedor del J2EE.
– Crea los contenedores de los componentes de
acuerdo a la especificación.
– Provee un ambiente estandarizado al momento de
ejecución para los componentes.
– Provee el conjunto de servicios definidos por J2EE
(API).
– Ofrece las herramientas necesarias para instalar,
configurar y poner a punto la aplicación, así como
para la administración del ambiente operativo.
7
Módulo IV.- Seguridad Aplicativa
Roles de la plataforma
• Proveedor de componentes.
– Es el encargado de entregar los componentes utilizados
en una aplicación J2EE, el cual entrega la funcionalidad
requerida.
– Define la forma en la que se puede ejecutar el
componente.
• Ensamblador de Aplicaciones.
– Encargado de unificar el funcionamiento de un grupo
de componentes para crear una aplicación.
• Crea la descripción de la aplicación.
• Identifica los recursos externos necesarios.
• Genera el EAR.
Módulo IV.- Seguridad Aplicativa
Roles de la plataforma
• Instalador.
– Después de que se tiene la aplicación, esta se instala en
un ambiente operacional específico.
• Administrador del sistema.
– Es responsable por el monitoreo de la aplicación
instalada, así como de configurar los contenedores
J2EE.
• Proveedor de herramientas.
– Responsable de entregar las herramientas necesarias
para instalar, crear y empaquetar una aplicación.
8
Módulo IV.- Seguridad Aplicativa
Componentes tecnológicos
• La plataforma soporta diferentes componentes.
–
–
–
–
Applets.
Clientes.
EJB.
Web.
• Se ensamblan en los módulos J2EE y se instalan en los
contenedores.
• Los contenedores ofrecen la siguiente funcionalidad:
–
–
–
–
Administración del ciclo de vida.
Seguridad.
Administración de transacciones.
“Threading components”
Módulo IV.- Seguridad Aplicativa
Componentes tecnológicos
– Los componentes corren en varias capas del
modelo.
– El modelo de la aplicación J2EE define:
• La capa cliente.
• La capa media (middle)
– Capa Web.
– Capa EJB.
• La capa EIS.
9
Módulo IV.- Seguridad Aplicativa
Servicios Tecnológicos
• La plataforma permite
que las aplicaciones
J2EE hagan uso de
diferentes servicios:
– De directorio.
– Correo electrónico.
– Soporte de
transacciones.
Módulo IV.- Seguridad Aplicativa
Servicios tecnológicos
• JNDI
– Con el API JNDI se puede acceder a los servicios de nombres y
directorios, utilizando librerías estándar de Java.
• LDAP.
• DNS.
• NIS
– También se puede utilizar para obtener una referencia a un EJB a través
de una aplicación empresarial.
• JDBC
– Es un API que permite a una aplicación el acceso a una base de datos
relacional.
– Permite al desarrollador crear código independiente de la base de datos.
– Permite utilizar diferentes bases de datos en un ambiente heterogéneo.
10
Módulo IV.- Seguridad Aplicativa
Servicios tecnológicos
• JTA y JTS.
– Son API’s que facilitan las transacciones entre aplicaciones J2EE.
– JTA:
• interactúa con el código de la aplicación y ofrece una interfaz que la
aplicación ocupa para controlar las transacciones.
• Habilita el uso de transacciones distribuidas.
• Habilita el control del inicio y fin de una transacción.
– JTS:
• Especifica la implementación del administrador de la transacción.
• El cual soporta JTA para ofrecer el soporte de transacciones a las entidades
involucradas en la misma.
– Servidor de transacciones.
– Administrador de recursos.
– Entre los dos ofrecen el soporte a transacciones confiables a los
componentes de una aplicación.
Módulo IV.- Seguridad Aplicativa
Servicios tecnológicos
• Conector de Arquitecturas.
– Es el API estándar de los vendedores de J2EE que
permite soportar conexiones hacia los EIS.
• ERP’s.
• Manejo de transacciones mainframe.
• Sistemas de bases de datos.
– Se implementan a través del desarrollo de
adaptadores que permiten la iteración entres las
aplicaciones J2EE y los EIS.
11
Módulo IV.- Seguridad Aplicativa
Servicios tecnológicos
• JAXP:
– Permite que la aplicación valide y transforme
un documento XML.
– es flexible y trabaja de manera independiente
de una implementación particular XML.
Módulo IV.- Seguridad Aplicativa
Introducción a la seguridad
con Java
12
Módulo IV.- Seguridad Aplicativa
Definir los requerimientos
• El primer paso en la implementación de seguridad con Java
es la definición de los requerimientos de seguridad.
• El desarrollador debe especificar las necesidades de
seguridad.
• Esto se establece en una lista de verificación que se
implementa por el encargado de “subir” la aplicación en el
servidor de aplicaciones y que se encarga de configurarla.
• Existen dos formas asegurar una aplicación utilizando
Java.
– Seguridad declarativa.
– Seguridad programada.
Módulo IV.- Seguridad Aplicativa
Seguridad declarativa
• Este mecanismo de seguridad se expresa en sintaxis de XML.
• Se deja en un documento llamado “deployment descriptor”.
• Describe la estructura de la seguridad.
– Roles.
– Control de acceso.
– Requerimientos de autenticación de la aplicación.
• El desarrollador describe los requerimientos de seguridad.
• El encargado de “subir” la aplicación utiliza las herramientas
necesarias.
– Para “mapear” el “deployment descriptor” a un mecanismo de
seguridad implementado por los contenedores J2EE.
13
Módulo IV.- Seguridad Aplicativa
Seguridad Programada
• Se encuentra en la aplicación misma.
• Se refiere a las acciones de seguridad programadas
en la aplicación.
• Se utiliza cuando la seguridad declarativa no es
suficiente.
• Ejemplo.
– Se puede programar que las autorizaciones :
•
•
•
•
Sucedan en cierto horario del día.
Estén basadas en los parámetros de la llamada.
Dependan del estado de un EJB.
Dependiendo de la información del usuario en la base de datos.
Módulo IV.- Seguridad Aplicativa
Modelo de seguridad J2EE
• Las aplicaciones Java pueden ser colocadas en diferentes
contenedores.
• Permite crear aplicaciones multicapa.
• El objetivo del modelo de seguridad J2EE es tener
seguridad punto a punto asegurando cada capa de la
aplicación.
14
Módulo IV.- Seguridad Aplicativa
Modelo de seguridad J2EE
• Las capas contienen recursos seguros y no
seguros.
• En tiempo de ejecución los contenedores utilizan
el modelo de seguridad para forzar la autorización.
• Para asegurar que sólo los usuarios autorizados
pueden acceder a un recurso se utiliza:
– La identificación.
– La Autenticación.
– La autorización.
Módulo IV.- Seguridad Aplicativa
Identificación.
• Proceso que permite reconocer a una
entidad por el sistema..
15
Módulo IV.- Seguridad Aplicativa
Autenticación
• Proceso que verifica la identidad de un
usuario, dispositivo o cualquier otra entidad
en el sistema.
• Prerrequisito para permitir el acceso a un
recurso en el sistema.
Módulo IV.- Seguridad Aplicativa
Autorización
• Permite el acceso controlado a los recursos
protegidos y se basa en la identificación y
autenticación.
16
Módulo IV.- Seguridad Aplicativa
Modelo de seguridad J2EE
• El modelo de programación de la aplicación J2EE hace que
esta sea independiente de los mecanismos específicos de
implementación de la seguridad por parte del servidor de
aplicaciones, lo que permite su portabilidad
Módulo IV.- Seguridad Aplicativa
Recursos, Directores y
Roles
17
Módulo IV.- Seguridad Aplicativa
Políticas de Seguridad
•
En Java se manejan dos dominios de políticas de seguridad.
– Dominio empresarial.
– Dominio de la aplicación o componente de la aplicación.
•
Los recursos que son “desplegados” en el dominio de políticas de
seguridad de la empresa son diferentes de los “desplegados” en el
dominio de las políticas de seguridad de la aplicación.
Módulo IV.- Seguridad Aplicativa
Requerimientos de Autenticación de
los Recursos
• En una aplicación J2EE se utilizan diferentes
mecanismos que permiten proveer de los
requerimientos de autenticación a los recursos..
–
–
–
–
–
Configuración de la identidad.
Autenticación programada.
Mapeo de “directores”.
Llamada no personalizada.
Mapeo de credenciales.
18
Módulo IV.- Seguridad Aplicativa
Configuración de la identidad
• El contenedor J2EE asegura el acceso a un recurso
a través de la autenticación.
– Director, se refiere a un usuario final o alguna otra
entidad que requiere acceso a la aplicación.
– Información de autenticación, se provee durante el
proceso de “despliegue” de la aplicación en el servidor
de aplicaciones.
Módulo IV.- Seguridad Aplicativa
Autenticación programada
• Un producto J2EE debe proveer de los datos de los directores y la
autenticación para un recurso en tiempo de ejecución.
• La aplicación los recibe de diferentes maneras:
– Cómo parámetros.
– De los parámetros del ambiente del componente.
• A esta técnica se le conoce como autenticación programada.
19
Módulo IV.- Seguridad Aplicativa
Mapeo de directores
• Es un requerimiento de seguridad adicional.
• El recurso obtiene la información de los directores y los
atributos de seguridad a través del mapeo de la identidad y
los atributos de seguridad del director que realiza la
llamada.
• El mapeo del director es recomendada pero no es
obligatoria.
Módulo IV.- Seguridad Aplicativa
Llamada no personalizada
• Una director del recurso actúa entre el director que realiza
la llamada y el recurso.
• Asigna la identidad y las credenciales del “llamador” al
administrador de recursos.
• Esta técnica se utiliza para verificar una llamada no
personalizada.
20
Módulo IV.- Seguridad Aplicativa
Mapeo de credenciales
• Esta técnica se utiliza cuando el servidor de
aplicaciones y un sistema de información
empresarial manejan diferentes dominios de
autenticación.
Módulo IV.- Seguridad Aplicativa
El director
• Un director representa a un usuario que requiere acceso a un
recurso.
• Es decir una entidad que puede ser autenticada por un protocolo
de autenticación en un servicio de seguridad implementado en
la empresa.
• Se puede identificar a un director por su nombre principal y
autenticarlo utilizando los datos de autenticación.
21
Módulo IV.- Seguridad Aplicativa
Tipos de directores
• Dominio de la política de seguridad.
– Determina el alcance que define el administrador de seguridad para la
política.
• Dominio de la tecnología de seguridad.
– Es el alcance sobre el que actúa la tecnología de seguridad para
garantizar una política de seguridad.
– Por ejemplo si se utiliza Kerberos para mantener la seguridad en
diferentes sistemas, estos sistemas se encuentran bajo el mismo dominio
tecnológico, aunque puede afectar diferentes dominios de políticas de
seguridad.
• Atributos y credenciales.
– Cada director se asocia con un conjunto de atributos de seguridad, que
tienen acceso a los recursos protegidos.
– Una credencial contiene los atributos de un director, y se utiliza para
autenticarlo.
Módulo IV.- Seguridad Aplicativa
Rol
• Un rol es un grupo lógico de usuarios.
• Se realiza un mapeo entre estos y las identidades de
seguridad (directores y grupos) por el responsable del
“despliegue” de las aplicaciones.
• Se utilizan en la seguridad declarativa y programada.
22
Módulo IV.- Seguridad Aplicativa
Rol
•
•
•
La autorización declarativa se utiliza para controlar el acceso a un
método de un EJB.
Este método se asocia a los elementos de permisos de los métodos que
se implementan en el descriptor.
Un director puede ejecutar el método si este tiene acceso al método en
el rol.
Módulo IV.- Seguridad Aplicativa
Rol
• Cada director se asocia a un rol que le permite
acceder a un recurso.
• La aplicación de las reglas de seguridad en los
recursos WEB o en los EJ B depende de que exista
la asociación del director y la llamada al recurso
en el rol.
• El contenedor puede determinar esto basado en los
atributos de seguridad del director.
23
Módulo IV.- Seguridad Aplicativa
Rol
• Los roles son definidos en un archivo XML llamado
“deployment descriptor”.
• Contiene elementos XMl que permiten la
implementación de la seguridad.
• El creador de la aplicación asigna los métodos
principal y de componentes de un EJB a los roles de
seguridad.
• Esté también define cada rol utilizando un elemento
“rol-seguridad”.
• Cada elemento se encuentra a nivel del archivo ejb-jar
y aplica a todos los EJBs que están en este nivel.
Módulo IV.- Seguridad Aplicativa
Rol
• Un usuario puede tener asignados varios roles.
24
Módulo IV.- Seguridad Aplicativa
Acceso a los recursos
•
Al acceder a un recurso el usuario puede:
– Utilizarlo como el que llama.
– Utilizar una identidad alterna.
Módulo IV.- Seguridad Aplicativa
Acceso a los recursos
25