Tarea: Identificar patrones de seguridad
Durante la arquitectura inicial de un sistema, el arquitecto de seguridad es responsable de la identificación y selección de los patrones de seguridad clave que garantizan el nivel de seguridad que necesita el sistema.
Disciplinas: Análisis y diseño
Objetivo

Proporcionar mecanismos clave para el desarrollo de soluciones seguras mediante seleccionándolos a partir de patrones predefinidos.

Relaciones
Descripción principal

El objetivo de esta tarea es permitir que los arquitectos identifiquen patrones de seguridad de alto nivel adecuados para conectar los elementos arquitectónicos en respuesta a los requisitos y las políticas de seguridad. Estos patrones se ajustan posteriormente con patrones detallados adecuados para una tecnología particular y a las opciones de plataforma mediante tareas de implementación y diseño en sentido descendente.

Para obtener más información sobre patrones de seguridad, consulte Concepto: Patrones de seguridad.

Pasos
Identificar requisitos de seguridad

Durante este paso el Rol: Arquitecto de seguridad es responsable de la captura de los requisitos de seguridad de alto nivel de un proyecto y de los elementos arquitectónicos clave de dicho proyecto. Estos requisitos se capturan en Artefacto: Documento de arquitectura de software y Artefacto: Especificaciones complementarias, y en caso de que estos requisitos limiten de forma significativa la arquitectura de la solución deberán también incluirse en Artefacto: Arquitectura de referencia. El rol del arquitecto de seguridad es obtener estos requisitos complejos de los interesados en el proyecto y capturarlos en sentencias fáciles de entender (propósitos).

El motivo de poner énfasis en el propósito durante esta fase es que en muchos casos, cuando se pregunta por la seguridad en una sesión de obtención de requisitos (consulte Directriz: Taller de requisitos), la mayoría de los interesados responden que "por supuesto, todo debe estar protegido", lo que significa que todo esté cifrado, auditado, etc., por lo que la respuesta será "oh sí, por favor". Llegado a este punto, el arquitecto de seguridad explica las implicaciones de tal decisión, el coste, la complejidad y el grupo empezará a tener un importante discusión sobre qué patrones son importantes para determinados elementos de la arquitectura. Son estos patrones los que expresan el propósito del sistema respecto de la seguridad, considerando que los patrones de nivel de diseño expresan los mecanismos para cumplir con el propósito y, por último, los patrones de implementación expresan la tecnología utilizada para cumplir el propósito.

Identificar límites de confianza

La confianza es un aspecto clave en cualquier solución de seguridad. La necesidad de seguridad se basa en la premisa de que dos partes comparten algún nivel de confianza y de que dicho nivel puede estar en una escala de "totalmente fiable" (y por tanto no hay necesidad de seguridad) o "totalmente no fiable" (caso de las reglas de paranoia).

  1. Sin confianza ... también conocido como confianza ciega: El proveedor puede estar suministrando un servicio público y no tiene necesidad de confiar en el sistema de invocación. El sistema de invocación puede enviar una identidad sin prueba y esperar que el proveedor asuma la identidad al procesar la solicitud. Puede que no se tomen medidas para evitar ataques de suplantación de la identidad.
  2. Confianza basada en la configuración de una red: No existe ninguna configuración de software que proporcione confianza. La red está configurada, posiblemente a través de una división en subredes con cortafuegos, de tal modo que quede limitado el número de máquinas que puedan transmitir un mensaje al proveedor. El caso degenerativo sólo vería el sistema de invocación y el sistema de proveedor de la subred. A veces se utilizan VPN para limitar los sistemas de invocación potenciales.
  3. Confianza basada en infraestructura: La infraestructura (por ejemplo, protocolo de transporte... posiblemente MA SSL o SSL + BA) se configura para identificar al sistema de invocación y validar así que se trata de un sistema de confianza. En el mensaje de servicios web (SOAP) no hay nada aparte de la identidad del invocador, que el proveedor debería asumir al procesar la solicitud.
  4. Confianza basada en señal: Confianza de señal de punto a punto; existe una señal en el mensaje que afirma una identidad de invocador y que fue creada probablemente por un sistema de invocación de confianza (caso de SAML, LTPA). Confianza de señal de tercero: hay una señal en el mensaje que afirma la identidad del invocador y que se creó probablemente por un sistema KDC/STS de terceros de confianza (por ejemplo, SAML, Kerberos).
  5. Confianza basada en contexto de señal: Firma que cubre la señal y el mensaje;  Existe firma en el mensaje creada por un sistema de invocación de confianza que cubre el mensaje y la señal que afirma la identidad del invocador y que autentica al sistema de invocación. Dos señales en el mensaje: existe una señal en el mensaje que autentica al sistema de invocación como sistema de confianza y otra señal que identifica al invocador. Debería haber algún mecanismo que enlazara estas dos señales juntas y con el mensaje, caso de una firma.
  6. El extremo de "confianza" es autenticación. Cualquier señal que ofrezca prueba elimina la necesidad de un mecanismo extra cuyo propósito sea establecer la confianza.

Zonas de confianza

En organizaciones grandes resulta a menudo eficaz subdividir la empresa en regiones administrativas y establecer distintas zonas de confianza. Entre las distintas zonas hay diversos subtipos de relaciones de confianza que se pueden establecer. Existen ejemplos de alguno de los modos en que dos partes pueden establecer una relación de confianza cuando sólo una de las partes tiene relación con el usuario final.

  • Confianza directa - Intercambio de señal: El dominio de confianza 1 autentica al usuario final y el dominio de confianza 2 necesita una identidad o identificador (propagación de identidad). En algunos casos (por ejemplo, sólo se necesita personalización) puede que no sea necesaria la autenticación.
  • Confianza directa - Validación de señal: El dominio de confianza 1 puede crear una nueva afirmación (una afirmación de identidad) que ofrezca su propia prueba de que se ha autenticado a usuario identificado. El dominio de confianza 2 evalúa que esta afirmación procede de alguien en el que confía (dominio de confianza 1) y lo utiliza en lugar de autenticar al propios usuario
  • ISP y servicios de señal: A veces las relaciones de confianza se establecen entre varias partes y la autenticación del usuario se hace aparte en un servicio independiente (proveedor de servicios de identidad). Estos proveedores de servicios de identidad tienen distintos grados de funcionalidad. Algunos observan el destino de la solicitud y determinan si el usuario ha sido autenticado, y qué ocurre si la señal actual necesita intercambiarse en el caso de una segunda señal y puede redirigir esta solicitud a las partes adecuadas.
  • Confianza indirecta: A veces, las partes no tienen una relación de confianza directa, pero comparten a un tercero al que ambos confían realizar de "intermediario" de un intercambio.
  • Delegación: Se pueden establecer combinaciones de relaciones de confianza directas e indirectas
Identificar patrones de seguridad de alto nivel

Los patrones de seguridad de alto nivel identificados en esta tarea son los siguientes. Los elementos del arquitecto de sistema a los que afecten los requisitos del sistema (la seguridad afecta tanto a elemento de software como de hardware) se pueden ahora asociar con uno o más de estos patrones (preferiblemente documentados en el Artefacto: Documento de arquitectura de software) de modo que puedan ser ajustados durante las actividades del período de diseño.

Identidad y autenticación

Un usuario final posee un identificador (nombre de usuario) y/o un conjunto de identificadores (títulos, roles, alias) y pruebas (contraseña) que guarda en algún sitio, quizás en un sistema de cliente como un portátil o PDA. Para autenticar, el usuario presenta el identificador y la prueba a una aplicación cuando se lo pida para identificarse él mismo ante la aplicación. Si la aplicación valida el identificador y la prueba, el usuario habrá sido "autenticado" correctamente y la identidad será ahora una "identidad autenticada". Cuando una aplicación implementa la lógica empresarial y cumple sus propias políticas de seguridad, necesita guardar sus datos/metadatos en un repositorio de datos/metadatos de identidad (sistema de archivos, base de datos, etc.). Con la llegada de Internet, el usuario final ha dejado de tener únicamente código de cliente de aplicación en su propio sistema sino que a menudo accede a aplicaciones a través de un navegador, y la red localiza la aplicación a través de un URI (identificador de recurso universal) suministrado por el usuario final.

Inicio de sesión único

Cuando un usuario tiene varias aplicaciones con distintos identificadores y pruebas, a veces resulta difícil gestionar los datos y metadatos de identidad para tomar las decisiones apropiadas. El inicio de sesión único (SSO) es un término aplicado a diversas técnicas (humanas y automatizadas) que reducen esta complejidad.

Las soluciones para SSO pueden estar basadas en cliente o en servidor/servicio y pueden estar acopladas estrecha o no estrechamente con las aplicaciones. El inicio de sesión único basado en web se refiere a soluciones basadas en navegador que normalmente incluyen cookies. En el inicio de sesión basado en cliente estrechamente acoplado, es responsabilidad del usuario registrar y sincronizar diversos ID/contraseñas que se mantienen en varios repositorios de aplicación. Algunos inicios de sesión únicos dependen de la "correlación de identidades", otros suministran "propagación de identidad" o "afirmaciones de identidad". Las nuevas iniciativas en SSO federado permiten que un usuario se registre con otro proveedor de servicios de identidad, quien gestiona la información del usuario y le ofrece una alternativa no estrechamente acoplada. En las empresas, un SSO de fondo puede incluir a la empresa que actúa como ISP. El SSO de fondo incluye un repositorio común para todas las aplicaciones, y cada aplicación/servidor se configura para que no use un repositorio local. El SSO de fondo también puede mantener varios repositorios para información del usuario y utilizar un proceso de gestión para forzar la sincronización de los datos de identidad en varios repositorios. Cuando están implicadas varias identidades a menudo existen requisitos para aislar las aplicaciones en dominios, que a menudo se correlacionan con dominios administrativos.

Identidades digitales

Como las personas y las empresas se han vuelto más dependientes de la tecnología informática, se ha producido una proliferación de identidad creada con información relacionada. Teniendo en mente la sustracción de identidad, las direcciones están legislando requisitos para las empresas sobre protección de la información personal custodiada por ellas.

Soluciones de identidad digital: hay dos estrategias fundamentales para gestionar las identidades digitales. Una está "centrada en el usuario", y se basa en un usuario que participa activamente en la protección de la identidad, "registrándose" con proveedores de terceros y otorgando permisos de acceso a sus datos y metadatos de identidad a los proveedores en los que confían. La Liberty Alliance es un consorcio que ha estado liderando esta estrategia, pero también existe un esfuerzo de origen abierto dirigido por la iniciativa Higgins en asociación con The Apache Foundation.

El segundo es un modelo centrado en la empresa en el que una empresa proporciona servicios de gestión de identidad a sus clientes, socios y empleados. La tecnología subyacente es la misma para cada enfoque, pero la dirección y la responsabilidad al ofrecer gestión de identidad digital es diferente. Las empresas tratan volúmenes de información distintos a los tratados por los individuos y, por lo tanto, tienen distintos requisitos de ajuste. Las empresas también necesitan tener sus propios sistemas para gestionar el acceso de usuarios basado en roles de empresa y cambiar las condiciones empresariales (por ejemplo, usted siempre será "Yo mismo", pero puede que no siempre trabaje para la empresa xyz).

Autorización

Como las personas y las empresas se han vuelto más dependientes de la tecnología informática, las reglas sobre quién puede acceder a los recursos se han codificado. Al diseñar aplicaciones, la decisión de quién puede acceder a qué tipo de información, dependerá de la información de contexto de la empresa o puede externalizarse a la aplicación y ser controlada por un conjunto de middleware independiente. La mayoría de productos y sistemas de software han implementado un conjunto de mecanismos de "control de acceso" pero cada uno normalmente mantiene su propia correlación de nombres de usuario autorizados con los nombres de recursos, y esto se denomina "listas de control de acceso".

Protección de mensajes

Existen dos tipos básicos de protección; protección de integridad (prueba que el mensaje no se ha cambiado durante el viaje) y de confidencialidad (aplicación de criptografía para garantizar que sólo los destinatarios autorizados pueden ver el mensaje). Cuando se envían mensajes a través de un protocolo cada mensaje se puede firmar o cifrar digitalmente o el protocolo de red puede firmar/cifrar todo el tráfico entre los dos puntos de entrada. Cuando el protocolo proporciona la protección, a menudo se dice que es de "punto a punto" (por ejemplo, punto final de red a punto final de red).

Factores clave
Los patrones de seguridad identificados durante esta tarea son de nivel alto y no tienen dependencia en tecnologías o plataformas concretas; cada uno de estos patrones será soportado a su vez por un determinado número de patrones específicos de tecnología y plataforma. La definición de estos patrones detallados debe estar a disposición del implementador de la tecnología y la plataformas escogidas por el proyecto.
Más información