PDF 6-por-pág

Sistemas Operativos Distribuidos
Conceptos Básicos
Sistemas Operativos Distribuidos
• Diversos elementos de un sistema distribuido pueden fallar:
– Procesadores, red, dispositivos, software, etc.
• Tipos de fallos:
Fiabilidad y
Seguridad
– Transitorios.
– Intermitentes.
– Permanentes.
• Semántica de los fallos:
– fail-stop.
– bizantina: funcionamiento arbitrario y/o malicioso.
• Soluciones basadas generalmente en replicación.
Sistemas Operativos Distribuidos
2
Replicación
Sistema Replicado
• Disponer de copias de datos, servicios o recursos
• Objetivos
• El elemento a replicar se suele denominar objeto.
• Un objeto está compuesto por una serie de copias físicas
denominadas réplicas.
– Mejorar el rendimiento
– Mejorar la disponibilidad
– Tolerancia a fallos
• Un sistema replicado debe contemplar:
• Requisitos
– Modelo de Sistema: Como funcionan cada uno de los gestores de
replicas.
– Comunicación del Sistema: Intercambio de información entre los
gestores de replicas. Muy útil mecanismos multicast.
– Transparencia
– Coherencia
– Rendimiento
Sistemas Operativos Distribuidos
3
Fernando Pérez Costoya
José María Peña Sánchez
Modelo de Sistema Replicado
Cada gestor de replicas debe garantizar
las propiedades de una transacción
dentro de sus datos asociados.
Características:
– Funcionamiento determinista.
– Recuperabilidad.
– Conjunto estático o dinámico.
Fases de una petición:
– Recepción (front-end).
– Coordinación.
– Ejecución.
Todos los RMs
– Acuerdo.
– Respuesta.
Sistemas Operativos Distribuidos
5
7-Seguridad
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
4
Fernando Pérez Costoya
José María Peña Sánchez
Mantenimiento de las Réplicas
Coherencia de réplicas:
Cliente
– Débil: operaciones pueden devolver valor obsoleto
• Ejemplos: DNS y NIS de Sun
Front end
RM
RM
RM
SERVICIO
– Estricta: operaciones devuelven siempre valor actualizado
• Menos eficiente (compromiso coherencia-eficiencia)
Posibles esquemas:
– Replicación con copia primaria
– Replicación con copias simétricas
RM: Gestor de replicas
(Replica Manager)
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
6
Fernando Pérez Costoya
José María Peña Sánchez
1
Sistemas Operativos Distribuidos
Esquema con Copia Primaria
Esquema con Copia Primaria
Existe una copia primaria y copias secundarias:
– Lecturas sobre cualquier copia
– Actualizaciones sobre la primaria que las propaga a secundarias
• Dependiendo del método de propagación, la coherencia será débil o
estricta.
• Alternativa: avisar a secundarias para que lean nueva versión.
BACKUP
Front end
RM
PRIMARIO
RM
BACKUP
RM
SERVICIO
Sistemas Operativos Distribuidos
7
Fernando Pérez Costoya
José María Peña Sánchez
Esquema con Copia Primaria
Discusión:
–
–
–
–
–
– El front-end recibe la petición.
• Coordinación:
– El RM primario recibe la petición, la procesa de forma atómica.
– Si ya la ha ejecutado (ID unico ya procesado), re-envia la respuesta.
• Ejecución:
– Si servidor primario falla, se elige otro.
Cliente
• Recepción:
– El RM primario ejecuta y almacena el resultado.
• Acuerdo:
– Si la petición es una actualización se notifica a los RM secundarios.
• Respuesta:
– El RM primario responde al front-end.
Sistemas Operativos Distribuidos
8
Fernando Pérez Costoya
José María Peña Sánchez
Esquema con Copias Simétricas
Esquema de votación:
Vale para servicios no deterministas.
Si hay N servidores el servicio sobrevive a N-1 fallos.
No soporta fallos bizantinos (en el primario).
El servicio requiere múltiples comunicaciones.
Permite descargar los procesos de solo-lectura a los backups.
– N réplicas: cada una con un número de versión.
– Lectura requiere quórum.
– Escritura requiere quórum.
Ejemplo:
Front end
– Servicio de NIS.
Cliente
RM
Votación
RM
RM
SERVICIO
Sistemas Operativos Distribuidos
9
Fernando Pérez Costoya
José María Peña Sánchez
Esquema con Copia Simétricas
• Recepción:
Sistemas Operativos Distribuidos
10
Fernando Pérez Costoya
José María Peña Sánchez
Esquema con Copia Simétricas
Discusión:
– El front-end recibe la petición y re-envia (multicast) al grupo de RM.
• Coordinación:
– Del modelo de comunicación se requiere transmisión fiable y en
orden.
• Ejecución:
– La suposición de un multicast fiable y ordenado es clave.
– Un sistema de 2N+1 elementos soporta hasta N fallos bizantinos.
– Se relajan las necesidades del sistema en relación a la ordenación
(operaciones conmutables), pero se compromete la consistencia.
– Permite descargar los procesos de solo-lectura a una replica.
– Se procesa la misma petición en cada RM.
• Acuerdo:
– Debido a la semántica multicast no se requiere fase de acuerdo.
• Respuesta:
– Se evalúan todas las respuestas recogidas por el front-end.
Sistemas Operativos Distribuidos
11
7-Seguridad
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
12
Fernando Pérez Costoya
José María Peña Sánchez
2
Sistemas Operativos Distribuidos
Protección
Seguridad
• Mismas alternativas que en sistema centralizado:
– ACLs o capabilities.
– Uso más frecuente de capabilities que en sistemas centralizados.
• Amoeba (Tanenbaum)
– Usa capabilities para nombrar y proteger objetos.
– capability:
• dir. servidor + id. de objeto + derechos de acceso + validación.
– Propietario de objeto tiene capability con todos los derechos
• cuando se crea objeto se genera número aleatorio que se almacena en
el servidor.
– Puede crear capabilities restringidas y pasarlas a otros.
– Cliente malicioso no puede añadir derechos a capability:
• Sistema distribuido inherentemente inseguro.
• Diversas formas de ataque a la seguridad:
– Escucha de mensajes, inyección de mensajes falsos, retransmisión
de mensajes escuchados anteriormente, suplantación de cliente o
servidor, privación de servicio, etc.
• 2 aspectos:
– Autenticación: verificación de la identidad de un componente
– Integridad y carácter confidencial de los datos transmitidos
• Solución a ambos basada generalmente en criptografía
• Validación= Cifrado(derechos XOR aleatorio)
Sistemas Operativos Distribuidos
13
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
14
Cifrado
Tipos de Sistemas de Cifrado
• Cifrado de la información con clave KC:
• Sistemas de clave secreta:
– C(Info, KC) → InfoCif.
– Notación típica: {Info}KC
–
–
–
–
• Descifrado con clave KD:
– D(InfoCif, KD) → Info. original
KC = KD
Emisor y receptor comparten la clave
Ejemplo: DES
Problema de la distribución de la clave
• Sistemas de clave pública:
• 2 alternativas:
–
–
–
–
–
–
– sistemas de clave secreta
– sistemas de clave pública
Sistemas Operativos Distribuidos
15
Fernando Pérez Costoya
José María Peña Sánchez
Fernando Pérez Costoya
José María Peña Sánchez
KC ≠ KD
KD es la clave secreta del servidor
KC es la clave pública del servidor
KD no puede deducirse a partir de KC
Menos eficientes que sistemas de clave secreta
Ejemplo: RSA
Sistemas Operativos Distribuidos
16
Kerberos
Fernando Pérez Costoya
José María Peña Sánchez
Kerberos
• Sistemas de autenticación desarrollado en M.I.T. (mediados
80)
– Basado en sistemas de clave secreta
• Usado en muchos sistemas; AFS, RPC de Sun, Windows
2000
• Autenticación de cliente y servidor basado en tercer
componente
Características:
–
–
–
–
–
–
Claves de clientes y servidores no se transmiten por la red.
Claves no se almacenan mucho tiempo en clientes.
Timestamps para detectar retransmisiones maliciosas.
Claves con plazo de expiración.
Permite autenticación entre dominios.
Puede usarse también para cifrar los datos.
– Reside en máquina “segura”
– Conoce claves secretas de clientes y servidores
Sistemas Operativos Distribuidos
17
7-Seguridad
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
18
Fernando Pérez Costoya
José María Peña Sánchez
3
Sistemas Operativos Distribuidos
Tickets y Autenticadores
• Objetos básicos en la autenticación
• Ticket:
– Registro que cliente incluye en mensaje que permite a servidor
verificar su identidad
– Está cifrado con clave del servidor e incluye entre otros:
Componentes
• 2 componentes implementados normalmente como una
entidad
• Servidor de autenticación (AS):
– Proporciona el ticket inicial:
• Ticket de concesión de tickets (TGT)
• identidad del cliente, clave para la sesión, plazo de expiración
– Normalmente se solicita TGT en el login del usuario
– El TGT se usa para comunicarse con el TGS
• Autenticador:
– Registro que cliente incluye en mensaje que asegura que el
mensaje se ha generado recientemente y no se ha modificado
– Está cifrado con clave de sesión e incluye entre otros:
• tiempo actual y checksum
Sistemas Operativos Distribuidos
19
Fernando Pérez Costoya
José María Peña Sánchez
• Servidor de concesión de tickets (TGS)
– Cuando cliente necesita comunicarse con un nuevo servidor, le
solicita usando TGT un ticket para identificarse
• AS serviría para obtener tickets para identificarse ante
cualquier servidor pero normalmente sólo se usa para
comunicarse con TGS
Sistemas Operativos Distribuidos
Fernando Pérez Costoya
20
José María Peña Sánchez
Protocolo con AS
Necesidad del TGS
• Secuencia de mensajes (C cliente;S servidor,normalmente
TGS):
• AS es suficiente pero genera un problema de seguridad:
– C→AS:
• {C,S,...} sin cifrar
– AS genera una clave se sesión aleatoria KSESy envía mensaje:
• {KSES, S, Texpiración,...}KC
• {Ticket} KS que contiene {KSES, C, Texpiración,...}KS
– C→S: envía mensaje con ticket y autenticador:
• {Ticket} KS + {marca de tiempo, checksum,...} KSES
• Servidor comprueba que no se ha modificado mensaje y que la marca
de tiempo es reciente
– S→C:
– Clave del cliente (generada normalmente a partir de contraseña)
disponible todo el tiempo en nodo cliente
– O se pide contraseña periódicamente a usuario o se almacena en
la máquina
– Ambas soluciones inadecuadas
• Solución: Uso de TGS
– En login se obtiene de AS el ticket para TGS (TGT)
– Tickets para nuevos servidores se piden a TGS
– TGT es diferente en cada login y tiene una vida corta
• {marca de tiempo} KSES
• Si se precisa integridad de datos pueden cifrarse con KSES
Sistemas Operativos Distribuidos
21
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
22
Fernando Pérez Costoya
José María Peña Sánchez
Protocolo Completo
• Protocolo en login (ya analizado):
– C solicita a AS ticket para comunicarse con TGS (TGT)
– AS devuelve TGT y clave de sesión con TGS (KSESTGS)
• Protocolo con TGS: C quiere autenticación con nuevo
servidor S
– C→TGS: solicita ticket para identificarse ante S
• {TGT}KTGS + {marca de tiempo, checksum,...} KSESTGS +{S}
– TGS→C envía mensaje con clave de sesión y ticket:
• {KSES, S, Texpiración,...}KSESTGS + {Ticket} KS
– C→S: envía mensaje con ticket y autenticador:
• {Ticket} KS + {marca de tiempo, checksum,...} KSES
– S→C:
• {marca de tiempo} KSES
Sistemas Operativos Distribuidos
23
7-Seguridad
Fernando Pérez Costoya
José María Peña Sánchez
4