Capítulo 1. Introducción Introducción
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
A menudo, la seguridad se simplifica reduciéndose a la selección de controles de seguridad o contramedidas que impidan la pérdida de confidencialidad, integridad y disponibilidad. Sin embargo, la integración de los controles es tan importante como la selección de los controles. Una serie de decisiones arquitectónicas, informadas por la sensibilidad de los datos y el contexto del entorno que rodea al sistema, guía la integración de los controles de seguridad.
Existen publicaciones que proporcionan orientaciones útiles sobre el diseño y la aplicación de la tecnología de ciberseguridad, el uso de métodos de arquitectura de software y la aplicación de servicios de seguridad en la nube. Sin embargo, se necesita una forma repetible y coherente de enfocar el pensamiento arquitectónico para el diseño seguro de un sistema de información alojado en una nube híbrida.
Es necesario comunicar claramente las prácticas de pensamiento arquitectónico y ofrecer garantías de que la implementación de los controles es eficaz y completa. En un entorno regulado, esto es especialmente importante, ya que debe haber transparencia, desde el diseño de los controles de seguridad hasta los mecanismos de garantía utilizados para demostrar su cumplimiento.
Este libro te llevará a través de un proceso paso a paso para arquitecturar la seguridad en una solución que resida en la nube híbrida. Este primer capítulo establecerá el contexto para el resto del libro describiendo:
-
La necesidad de una integración eficaz de las técnicas fundamentales de seguridad
-
El tipo de arquitecto que debe utilizar el pensamiento arquitectónico descrito en este libro
-
Cómo la estructura del libro utiliza un diagrama de dependencia de artefactos como hoja de ruta hacia el pensamiento arquitectónico para la seguridad
Una vez que hayas leído el capítulo introductorio, puedes saltar a un capítulo que sea relevante para la fase actual de tu pensamiento arquitectónico. Sin embargo, te animamos a que empieces por el principio, ya que el método de extremo a extremo te ayuda a comprender la trazabilidad de los requisitos, la descomposición de la arquitectura y el modelado de las amenazas que conducen a la detección y la respuesta. Una vez que hayas leído el método de extremo a extremo, el libro será una referencia útil en la que sumergirte para refrescarte en las técnicas mientras trabajas en la seguridad de la arquitectura de una solución.
Empecemos hablando de las técnicas de seguridad fundamentales para una integración eficaz de la seguridad y el cumplimiento en las soluciones de nube híbrida.
Técnicas básicas de seguridad
En se utilizan muchos controles de seguridad diferentes para proteger los datos de la pérdida de confidencialidad, integridad y disponibilidad. Las técnicas de seguridad fundamentales integran los controles en un sistema. Sin embargo, cada una de estas técnicas o conceptos suele debatirse de forma independiente y las elegidas suelen ser las favoritas del interesado o proveedor de soluciones más ruidoso. Ninguna de estas técnicas basta por sí sola para diseñar, construir y ejecutar un sistema seguro.
En este libro, integramos cuatro técnicas fundamentales de seguridad en un método integral:
-
Gestión del cumplimiento
-
Seguridad centrada en los datos
-
Seguridad desde el diseño con modelos de amenazas
-
Arquitectura de confianza cero
La Figura 1-1 muestra cómo se integran estas técnicas para formar la base del método que vamos a discutir.
En el centro del diagrama están las tres técnicas de pensamiento arquitectónico que utilizaremos para integrar la seguridad en la arquitectura de una solución. Todo ello se apoya en la demostración de conformidad que se muestra en el exterior.
El cumplimiento adopta un enfoque estático y desenfocado de la seguridad, pero los datos que circulan por un sistema son dinámicos, ya que se procesan mientras están en tránsito, en reposo y en uso. Empecemos por la técnica, que se centra en los flujos de transacciones y el procesamiento de los datos.
Figura 1-1. Técnicas de cimentación
Seguridad centrada en los datos
La seguridad centrada en los datos se centra en analizar el flujo de datos a través de un sistema, desde el inicio de una transacción hasta el final. En cada etapa del viaje, consideramos los controles de seguridad necesarios para proteger el flujo de transacciones en tránsito, en reposo y en uso.
El diagrama de la Figura 1-2 muestra el flujo de datos a su paso por un sistema:
En el diagrama, el comprador inicia una transacción para pedir unos productos. La caja representa la organización, y la elipse exterior representa el límite del sistema que procesa los datos. Dentro del sistema, hay tres subsistemas interconectados que procesan los datos. La línea de puntos representa los flujos de transacciones que transportan los datos a través de los subsistemas y requieren protección.
Figura 1-2. Seguridad centrada en los datos
Vamos a recorrer cada uno de los flujos de transacciones de por orden:
-
El pedido pasa primero como un flujo de transacción del comprador al subsistema "Core app". Cuando el pedido está listo para completarse, el flujo continúa hacia el subsistema "Pagos" y hacia un sistema de pago externo, como se muestra enel flujo 1.
-
Una vez completado el pago, la transacción vuelve al subsistema "Pagos" y pasa al subsistema "Entrega" para conectarse externamente y organizar la entrega, como se muestra en el flujo 2.
-
Una vez acordada la entrega, se devuelve la confirmación del pedido al subsistema "Core app" y a la persona que hizo el pedido, como se muestra en el flujo 3.
En muchas de las etapas de este flujo de transacciones, tienen lugar el procesamiento y la agregación de datos, lo que aumenta el valor de los datos y la necesidad de mayores controles. En todas las etapas del flujo de transacciones, debemos tener en cuenta los controles de seguridad para proteger los datos de la pérdida de confidencialidad, integridad y disponibilidad.
Una vez comprendidos los flujos de las transacciones, podemos pasar al diseño seguro mediante .
Seguridad desde el diseño con el modelado de amenazas
Secure by design utiliza el modelado de amenazas como forma de identificar controles de seguridad basados en el riesgo directamente para las transacciones y los datos que se mueven a través de un producto o sistema tecnológico.
En su documento, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure-by-Design and -Default (Cambiar el equilibrio del riesgo de ciberseguridad: principios y enfoques para la seguridad por diseño y por defecto), el CISA y otras organizaciones de seguridad nacional definen la seguridad por diseño como aquella en la que "los productos tecnológicos se construyen de forma que se protejan razonablemente contra los ciberactores maliciosos que acceden con éxito a dispositivos, datos e infraestructuras conectadas". Significa que los ingenieros deben integrar la seguridad en el diseño de un componente de software o hardware mediante una evaluación del riesgo llevando a cabo un modelado de amenazas.
El modelado de amenazas identifica amenazas específicas y se basa en políticas, prácticas y procesos de seguridad que no abordan específicamente los riesgos para los datos sensibles. Puedes ampliar la práctica al examen de la arquitectura de aplicaciones e infraestructuras para la identificación de controles basados en el riesgo.
Para garantizar la identificación de todos los datos sensibles, utilizamos un enfoque sistemático de pensamiento arquitectónico para el examen de todos los flujos de datos y transacciones importantes. Las prácticas de modelado de amenazas deben funcionar a escala en múltiples plataformas informáticas en un entorno de nube híbrida.
En el Capítulo 6 trataremos más a fondo el modelado de amenazas, incluyendo enfoques recientes como el ATT&CK (Tácticas, Técnicas y Conocimientos Comunes de los Adversarios) de MITRE.
Arquitectura de Confianza Cero
La informática en la nube y el uso de dispositivos móviles desafiaron el concepto tradicional de un modelo de seguridad basado en el perímetro. Los modelos tradicionales de seguridad de "castillo y foso" suponían que, una vez que los datos atravesaban el perímetro, se podía confiar implícitamente en todo lo que había dentro de un sistema. El cambio de mentalidad comenzó con la publicación por el Foro Jericó en 2007 de los Mandamientos del Foro Jericó para un mundo deperimiterizado en el que se asume que no existe un perímetro de red.
John Kindervag, de Forrester Research, ideó entonces el término "confianza cero" en 2010 y desarrolló la frase "nunca confíes, siempre verifica". Identificó la confianza cero como un modelo que elimina la confianza implícita dentro de los límites de un sistema y evalúa continuamente los riesgos aplicando mitigaciones a las transacciones empresariales y a los flujos de datos en cada paso de su recorrido. La frase "asumir el incumplimiento" también se asocia a menudo con la confianza cero y procede de la frase "asumir el compromiso" utilizada por el Departamento de Defensa de EEUU en la década de 1990.
El enfoque requiere una combinación de tecnologías, procesos, prácticas y cambios culturales para aplicarse con éxito. Implica un cambio fundamental en la forma en que las organizaciones abordan la ciberseguridad .
Conceptos básicos de la confianza cero
El modelo de confianza cero de asume que todas las transacciones empresariales y flujos de datos, se originen dentro o fuera de la red, son potencialmente maliciosos. Cada interacción en una transacción empresarial o flujo de datos debe validarse continuamente para garantizar que sólo los usuarios y dispositivos autorizados puedan acceder a los datos empresariales sensibles. En efecto, traslada el perímetro desde el límite del sistema al punto en el que tienen lugar la identificación, la autenticación y la autorización, con lo que la identidad se convierte en el nuevo perímetro. A menudo se simplifica todo el concepto al principio de "nunca confíes, siempre verifica", pero es más que eso.
La arquitectura de confianza cero requiere un cambio cultural que haga hincapié en la importancia de la seguridad y no sólo en el cumplimiento en toda la organización. Esto significa que la implementación de una arquitectura de confianza cero implica no sólo la implementación de tecnologías específicas, sino también el desarrollo de procesos y prácticas que promuevan una mentalidad que dé prioridad a la seguridad de los datos en toda la organización, basándose en el enfoque de seguridad centrado en los datos que hemos comentado anteriormente.
Al diseñar y desarrollar la seguridad de un sistema, un arquitecto debe seguir un conjunto de principios, dogmas o simplemente una forma de pensar para aplicar la confianza cero. La confianza cero no es un método integral, y un enfoque global requiere la integración con otras técnicas de pensamiento arquitectónico.
Principios de confianza cero
Las organizaciones ofrecen orientación en publicaciones, incluido el documento del Instituto Nacional de Estándares y Tecnología (NIST) de EE.UU. SP 800-207 Arquitectura de Confianza Cero que tiene un conjunto de principios de arquitectura de confianza cero y los principios de diseño de arquitectura de confianza cero del Centro Nacional de Ciberseguridad (NCSC) del Reino Unido.
Principios de la Arquitectura de Red de Confianza Cero
No te confundas con los "principios de arquitectura de red de confianza cero" que utilizan los proveedores de soluciones para describir sus productos; son un subconjunto de los principios generales de confianza cero.
A lo largo del libro, mostramos los principios y principios de la confianza cero integrados en el método. En la Tabla 1-1 hemos creado cinco principios rectores de nivel superior que se corresponden con los principios y postulados. Los hemos acercado a las frases familiares que puedes ver en marketing.
| Principios rectores | Principios de la Arquitectura de Confianza Cero NIST SP 800-207 | Principios de Diseño de la Arquitectura de Confianza Cero del NCSC del Reino Unido |
|---|---|---|
Seguridad centrada en los datos |
|
|
"Nunca confíes,verifica siempre"o |
|
|
Protección de datos en todas partes |
|
|
"Asumir la infracción" o |
|
|
Selección de componentes de confianza cero |
|
A continuación, llegamos a la necesidad de demostrar el cumplimiento, no sólo de las políticas, prácticas y procesos, sino también de las amenazas que hemos identificado.
Gestión del cumplimiento
Una organización utiliza procesos de gestión del cumplimiento para demostrar que sigue un conjunto de reglas, reglamentos o normas dictadas por organizaciones externas, como gobiernos y organismos del sector. El proceso garantiza que las empresas siguen estos estrictos requisitos de riesgo operativo, seguridad, privacidad y resistencia.
La gestión del cumplimiento incluye comprobar que un sistema de información cumple un conjunto de políticas, prácticas y procesos de la organización. Es posible que sólo cubran un subconjunto de los controles de seguridad necesarios para proteger la información sensible, ya que a menudo representan un nivel mínimo de seguridad que las organizaciones deben cumplir para evitar multas o sanciones legales.
A menudo, el equipo de seguridad no puede seguir el ritmo de los cambios tecnológicos, las nuevas vulnerabilidades de los sistemas, las amenazas emergentes o las técnicas de ataque avanzadas, lo que da lugar a actualizaciones lentas o retrasadas de las políticas y normas de seguridad. En algunos casos, hace falta un incidente de seguridad para forzar mejoras en la protección para hacer frente a nuevos tipos de ataques o vulnerabilidades de seguridad no identificadas o bloqueadas previamente.
La continua elevación del listón de cumplimiento exige a veces la implantación de nuevos controles, aunque el riesgo no justifique el aumento de los controles. El aumento del cumplimiento conlleva costes adicionales, y la protección puede seguir siendo ineficaz para los datos más sensibles.
El cumplimiento no es seguridad
Cumplimiento no es seguridad, y no conseguirás el cumplimiento sin seguridad. Hemos visto muchas organizaciones en las que se invierte mucho en demostrar el "incumplimiento" mediante comprobaciones de cumplimiento, revisiones de control y auditorías, pero se invierte poco en seguridad. Céntrate en la seguridad con trazabilidad para demostrar el cumplimiento.
En el Capítulo 4, hay un debate sobre las técnicas de validación de la conformidad, incluida la trazabilidad para demostrar la conformidad, y en el Capítulo 10, un debate sobre las técnicas de garantía de la conformidad.
Continuemos con un debate sobre los usuarios de las técnicas de seguridad fundamentales en la industria en la actualidad.
Usuarios de las Técnicas de Seguridad
Las técnicas o modelos de que tratamos en esta sección suelen ser utilizados principalmente por distintos tipos de profesionales de la seguridad, con el resultado de que cada uno de los distintos usuarios promueve su propia técnica favorita. No se suele escribir sobre la integración de estas técnicas ni se practica como un conjunto integrado de técnicas.
Entonces, ¿dónde vemos que se utilizan estas técnicas hoy en día?
- Seguridad centrada en los datos
-
Hemos visto en a arquitectos superponer flujos de datos coloreados para flujos de datos arquitectónicamente significativos, pero no es algo que veamos con regularidad. A veces se utiliza por seguridad, y otras simplemente para mostrar el flujo de transacciones.
- Seguridad desde el diseño con modelos de amenazas
-
seguro por diseño se refiere sobre todo al desarrollo de un producto de software utilizando el ciclo de vida de desarrollo de software. Trata sobre el uso de un modelo de amenazas como parte del diseño de un producto. Desde la publicación de Threat Modeling: Designing for Security (Wiley) de Adam Shostack en 2014, es más probable que los desarrolladores (o ingenieros) de software utilicen el modelado de amenazas como técnica durante el desarrollo de software. Vemos que la técnica se utiliza sobre todo en el desarrollo de software, más que para el diseño integral de toda una aplicación, sistema o sistema de sistemas.
- Arquitectura de confianza cero
-
Muchas organizaciones diferentes están adoptando la arquitectura de confianza cero, pero los proveedores de soluciones dominan allí donde utilizan la técnica para vender productos que tienden a centrarse en un dominio, como la seguridad de la red, la gestión de identidades o la gestión de amenazas.
- Conformidad
-
Cumplimiento suele ser el centro de atención de las organizaciones de riesgo y cumplimiento en muchos sectores regulados. Sospechamos que se debe a que a los auditores, consultores y ejecutivos les resulta más fácil pensar en una serie de listas de comprobación que no requieren los profundos conocimientos técnicos necesarios para utilizar otras técnicas.
Este libro te guiará a través de un método que integrará cada una de estas técnicas, pero antes de hablar de un método, consideremos quién debe diseñar la seguridad en una solución .
Funciones del arquitecto para la seguridad
Arquitectura pensar es la función principal de un arquitecto. Sin embargo, es una habilidad que también utilizan los consultores y los ingenieros de software que toman decisiones arquitectónicas. En el Capítulo 2 veremos cómo encaja el pensamiento arquitectónico con la consultoría y la ingeniería.
El pensamiento arquitectónico para el diseño seguro tampoco es sólo para los arquitectos de seguridad; una amplia gama de funciones de arquitecto necesitan aplicar la seguridad al desarrollo de un sistema de información. Los arquitectos que desarrollan infraestructuras o aplicaciones deberían adoptar este método, no sólo los arquitectos de seguridad.
En el desarrollo ágil, es necesario un papel híbrido llamado campeón de seguridad, que tendrá conocimientos tanto de arquitectura como de ingeniería. Debería poder utilizar este método para asesorar a los desarrolladores sobre la integración de la seguridad en DevSecOps.
Una serie de funciones diferentes de los arquitectos deben utilizar el pensamiento arquitectónico para las técnicas de seguridad, entre ellas:
-
Arquitecto de seguridad
-
Arquitecto de infraestructuras y aplicaciones
-
Campeón de seguridad
Continuemos hablando de cada una de estas funciones de arquitecto y de cómo deberían utilizar el método de este libro.
Arquitecto de seguridad
Un arquitecto de seguridad de es un arquitecto especializado en seguridad, cumplimiento y gestión de riesgos. Hemos dividido el papel de un arquitecto de seguridad en cuatro categorías: arquitecto de seguridad empresarial, arquitecto de seguridad de soluciones, arquitecto de seguridad de productos y arquitecto de seguridad asesor o consultor. Cada función tiene un conjunto común de habilidades de seguridad, pero un enfoque diferente con habilidades y experiencias adicionales:
- Arquitecto de seguridad empresarial
-
Un profesional de la seguridad de que es especialista en arquitectura empresarial y elabora orientaciones a nivel empresarial sobre la aplicación de la seguridad a una empresa. Desarrollan una arquitectura empresarial y unos principios rectores para alinearlos con la estrategia de seguridad y guiar el desarrollo de la seguridad en las arquitecturas de soluciones.
Deben tener un buen conocimiento de las amenazas actuales y de la dirección del sector, así como excelentes dotes de comunicación, para alinear a la empresa con la estrategia y la arquitectura de seguridad empresarial.
Si desempeñas esta función, este libro contiene algunas orientaciones generales sobre arquitectura empresarial en los Capítulos 2 y 3. Junto con el resto del libro, estos capítulos permiten a un arquitecto de seguridad empresarial comprender el pensamiento arquitectónico para el proceso de diseño seguro, de modo que pueda proporcionar las aportaciones adecuadas para apoyar a los arquitectos en la solución de la seguridad.
- Arquitecto de seguridad de soluciones
-
Un profesional de la seguridad de que es especialista en el desarrollo de arquitecturas de soluciones para la seguridad en proyectos o iniciativas concretas dentro de una organización. Por ejemplo, pueden desarrollar una arquitectura para una solución específica, como un servicio de gestión de acceso privilegiado.
Deben tener un profundo conocimiento de las amenazas y riesgos específicos asociados a la tecnología y una buena comprensión de la estrategia empresarial, la arquitectura empresarial, las políticas, las normas y las directrices de la organización.
Además, deben tener todas las habilidades de los arquitectos de infraestructuras y aplicaciones en cuanto a resistencia, escalabilidad y operaciones, ya que desarrollarán la arquitectura de una aplicación de seguridad.
Trabajarán en estrecha colaboración con ingenieros, desarrolladores, probadores y gestores de proyectos. Deben tener excelentes dotes de comunicación para explicar los problemas de seguridad a las partes interesadas no técnicas.
Si tienes esta función, todo este libro proporciona las actividades de arquitectura específicas de seguridad necesarias para una solución de seguridad, pero las técnicas de arquitectura genéricas, disponibles en otras publicaciones de arquitectura de software y aplicaciones, complementarán las técnicas tratadas en este libro. Al final de este capítulo encontrarás referencias a otras publicaciones útiles.
- Arquitecto de seguridad de producto
-
Un profesional de la seguridad de que es especialista en el desarrollo de un producto o conjunto de productos de seguridad. Suelen ser especialistas en un ámbito concreto de la seguridad, como la gestión de identidades y accesos o la detección de amenazas, con un profundo conocimiento de los requisitos de software y hardware de los productos.
Serán responsables del desarrollo de la arquitectura de un producto de seguridad y colaborarán estrechamente con los equipos de desarrollo y pruebas. Para que el producto se adopte rápidamente, tendrán que comprender cómo encaja en un entorno empresarial y las ventajas que aporta.
Necesitarán grandes dotes de comunicación para explicar las ventajas del producto al equipo de gestión del producto, que comercializará y venderá la solución.
Si tienes esta función, todo este libro proporciona las actividades de arquitectura específicas de seguridad necesarias para un producto de software, pero las técnicas de arquitectura genéricas, disponibles en otras publicaciones sobre arquitectura de software, complementarán las técnicas tratadas en este libro. Al final de este capítulo encontrarás referencias a otras publicaciones útiles.
- Arquitecto de seguridad asesor o consultor
-
Un profesional de la seguridad de es un especialista que asesora a una organización sobre cómo integrar controles de seguridad en su infraestructura y aplicaciones. Trabajan con el arquitecto principal o jefe del proyecto y, a veces, con arquitectos de otras disciplinas para integrar la seguridad en la solución desarrollada.
Deben conocer bien no sólo las buenas prácticas del sector, los requisitos normativos y las tecnologías de seguridad, sino también las soluciones de arquitectura de infraestructuras y aplicaciones. El arquitecto tiene habilidades "en forma de T", con un profundo conocimiento de la seguridad y una amplia gama de conocimientos relacionados con los sistemas de información.
Tienen que ser capaces de hablar de seguridad con una amplia gama de interesados, incluidos los que no son técnicos y los que trabajan en la aplicación concreta de los controles de seguridad y tienen profundos conocimientos de ingeniería.
Si tienes esta función, todo este libro proporciona las actividades de arquitectura específicas de seguridad necesarias para una arquitectura de infraestructura o de aplicaciones, y los artefactos que necesitarás para superponer a la arquitectura desarrollada por un arquitecto de infraestructura o de aplicaciones. El final de este capítulo contiene referencias a otras publicaciones útiles que te permitirán apoyar mejor a los arquitectos a los que asesores.
Si eres arquitecto de un sistema de información, piensa qué papel tienes en la integración de la seguridad en la arquitectura de la solución. La cuestión no es si eres responsable, sino en qué medida .
Arquitecto de Infraestructuras y Aplicaciones
En hay muchos proyectos o iniciativas que no necesitan los beneficios de un arquitecto especializado en seguridad, sino que el arquitecto de infraestructuras o de aplicaciones tendrá que integrar la seguridad en la solución. El arquitecto de infraestructuras puede estar diseñando una plataforma en la nube, mientras que el arquitecto de aplicaciones puede estar diseñando una plataforma de pagos alojada en la plataforma en la nube. En ambos casos, la seguridad será responsabilidad de estos arquitectos. Este libro les ayudará con el pensamiento arquitectónico para el diseño seguro necesario en sus funciones.
Campeón de Seguridad
En un entorno de desarrollo ágil o DevOps, un campeón de la seguridad puede asumir el papel de arquitecto asesor de seguridad. En este caso, el profesional de la seguridad tendrá una mezcla de pensamiento arquitectónico y conocimientos de ingeniería que le permitirán entrar en los detalles de asesorar a un desarrollador sobre cómo desarrollar código de forma segura. Encontrarás más detalles sobre esta función en el Capítulo 10.
Funciones y responsabilidades contextuales
Todas las funciones deben comprender el proceso de pensamiento arquitectónico integral de y los artefactos implicados. Las responsabilidades de cada papel para dirigir o ayudar en el desarrollo de los artefactos variarán. Como líderes técnicos, tendrán que adaptar sus responsabilidades en función del contexto de la organización, producto, proyecto o programa.
Ahora que hemos hablado de los conceptos fundamentales de seguridad que requieren la integración en un método y de las funciones del arquitecto, pasemos a hablar de la estructura del libro que permitirá un recorrido eficaz del método.
Estructura del libro
El libro tiene una serie de capítulos que construyen una arquitectura de seguridad utilizando técnicas para desarrollar artefactos a lo largo del libro. Cada capítulo se centra en artefactos y técnicas específicos, dándote la oportunidad de utilizar también el libro como manual de referencia. Cada capítulo destacará las técnicas que apoyan la confianza cero. Para ayudar a reforzar el aprendizaje del libro, hemos incluido ejemplos de artefactos basados en el caso práctico que figura en el Apéndice A.
Marco de artefactos
Empecemos en viendo el marco utilizado a lo largo de este libro, seguido del diagrama detallado de dependencia de artefactos.
En la Figura 1-3, mostramos un marco para el pensamiento arquitectónico que se utiliza para desarrollar una arquitectura de seguridad. Cada bloque del diagrama representa una agrupación de artefactos relacionados.
Figura 1-3. Marco de artefactos
En la parte superior, tenemos el contexto de la empresa, que incluye todas las aportaciones de la organización utilizadas para diseñar una arquitectura de la solución, incluido el contexto empresarial y las políticas de la organización. Estos artefactos se crean normalmente antes de la arquitectura de la solución, pero a veces no existen y el proyecto es responsable de su desarrollo. Puede que tengas que completar estos detalles, lo que añadirá un esfuerzo adicional al proyecto.
Debajo tenemos las secciones de requisitos, arquitectura y operaciones, que demuestran el desarrollo de izquierda a derecha de la arquitectura. La sección de requisitos incluye los artefactos para recopilar los requisitos funcionales y no funcionales de la solución. La sección de arquitectura incluye los artefactos para la descomposición descendente de la arquitectura de la solución, empezando por la visión general de la arquitectura y el contexto del sistema. Puede que la sección de operaciones sea la última de este cuadro, pero no es menos importante y contiene artefactos desarrollados a partir de las partes de requisitos y arquitectura del marco.
En la parte inferior izquierda de está la sección de gobernanza, que incluye los artefactos utilizados para apoyar el desarrollo general de la arquitectura y que se utilizan en todas las fases del desarrollo de la arquitectura.
Por último, en la parte inferior derecha de está la sección de garantía, que incluye todas las actividades necesarias para darnos confianza en el diseño y la aplicación de los controles de seguridad, y estas actividades continúan en las operaciones del Día 2.
Este es un punto de partida, y ahora tenemos que elaborar el marco.
Diagrama de dependencia de artefactos
El marco de la Figura 1-4 muestra un diagrama de dependencia de artefactos con los documentos, diagramas y tablas creados mediante las técnicas contenidas en este libro. En los capítulos siguientes, recorreremos la creación de los artefactos utilizando este diagrama como hoja de ruta.
El número de artefactos puede parecer abrumador, pero los artefactos pueden ser diagramas y tablas individuales en lugar de un gran documento. También tiene artefactos que contienen código, como una arquitectura desplegable. Utiliza los artefactos y las técnicas como herramientas, en función de los requisitos específicos del proyecto.
Formato del diagrama
Los diagramas originales que produjimos se han redibujado para mantener la coherencia y cumplir los requisitos de publicación. Si quieres ver los diagramas originales seleccionados, están alojados en el sitio web complementario del libro.
Es probable que, como arquitecto, te encuentres con estos artefactos, con distintos niveles de aportación en función de tu función. Como hemos dicho antes, el arquitecto de aplicaciones o de infraestructuras será el propietario de algunos de estos artefactos, y tú podrás añadirles contenido. En otros casos, te pertenecerán. Si alguien no es su propietario, lo más probable es que lo seas tú. Cuando se trata de artefactos de operaciones, puede que no los crees, pero eres responsable de garantizar su entrega.
Tampoco es necesario utilizar cada uno de los artefactos, y el tiempo dedicado a cada uno debe ser el justo para transmitir las características arquitectónicamente importantes de un sistema. Por ejemplo, al validar la eficacia de los mecanismos de control, no tienes que tener en cuenta todos y cada uno de los flujos de transacciones que podrían producirse en el sistema. En su lugar, debes buscar una colección representativa de flujos de transacciones arquitectónicamente significativos que te permitan revisar todas las rutas principales a través del sistema al menos una vez.
Figura 1-4. Diagrama de dependencia de artefactos; ver el diagrama original
Crea una documentación adecuada al contexto del proyecto y a la sensibilidad de los datos que procesa el sistema. Será necesario crear una documentación importante para una aplicación sujeta a normativas, a fin de dar garantías a la gestión interna de riesgos y a los auditores externos. Una organización menos tolerante al riesgo puede requerir la identificación de una lista ampliada de amenazas y contramedidas .
Ahora tenemos que debatir cuál es la mejor forma de demostrar el uso de las técnicas para crear artefactos .
Caso práctico
En hemos descubierto que la mejor forma de aprender las técnicas para crear los artefactos es mediante un caso práctico que defina un problema con cierto contexto empresarial, la arquitectura informática actual y un diagrama general de la arquitectura. Hacemos referencia al caso práctico que figura en el Apéndice A en cada capítulo y lo utilizamos para crear artefactos de ejemplo que muestren el uso de la técnica.
La Figura 1-5 muestra los artefactos contenidos en el estudio de caso. Proporciona un contexto empresarial general del proyecto, mediante un análisis de la necesidad de ofrecer un sistema para cobrar a los vehículos contaminantes por entrar en la ciudad. Describe la arquitectura informática actual, incluidas las organizaciones que tendrán que integrarse con el sistema, como Clean Air Pay, que necesita la integración de RabbitMQ. Si se tratara de un proyecto para una organización con muchas aplicaciones existentes, habría muchas más limitaciones para la solución.
Figura 1-5. Diagrama de dependencia de artefactos del caso práctico
Como el sistema procesa datos personales, la legislación vigente sobre privacidad de datos guiará los controles necesarios. La aplicación tiene que cumplir la Norma de Seguridad de Datos del Sector de las Tarjetas de Pago (PCI DSS), ya que procesa pagos. El estudio de caso dice poco sobre las políticas de seguridad existentes, pero sí habla de utilizar el Marco de Ciberseguridad del NIST como práctica que el proyecto debe aplicar al sistema.
El estudio de caso proporciona a un diagrama general de la arquitectura para mostrar el sistema global. No esperes que el diagrama muestre todos los actores externos del sistema, y puede que tengas que identificar información adicional a partir de la descripción o sistemas implícitos con los que integrarte. Este es el primer diagrama que probablemente te dará el proyecto, o tendrás que crearlo tú mismo. Es un diagrama que muestra una visión general de la solución, pero no se espera que tenga un formato estándar y será un diagrama que cualquiera pueda entender desde una perspectiva no técnica. En el diagrama del caso práctico, tenemos componentes unidos por líneas, pero podría ser simplemente un diagrama de bloques de capacidades en grupos sin líneas que muestren el control o el flujo de datos. También es probable que evolucione con el tiempo, así que estate atento a los cambios que haga el arquitecto jefe en este diagrama, ya que las actualizaciones pueden cambiar tu solución.
Utilizaremos un diagrama de dependencia de artefactos en cada capítulo, para destacar los artefactos de los que estamos hablando. Recorramos cada uno de los capítulos y su contenido en .
Organización del libro
Como ya hemos comentado en , el libro tiene capítulos organizados a grandes rasgos en el orden del proceso de desarrollo para construir una arquitectura de solución con seguridad incluida. La Figura 1-6 muestra el ciclo de vida de la solución, con los recuadros Planificar, Diseñar, Construir y Ejecutar representando las fases.
Todas estas fases del ciclo de vida de la solución alimentan la arquitectura de seguridad en la parte inferior del diagrama. Los bloques Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar se alinean con las seis funciones del Marco de Ciberseguridad del NIST, que trataremos en el Capítulo 2, junto con los dominios de seguridad que hemos definido para una arquitectura de seguridad empresarial.
Ahora te llevaremos a través de las diferentes partes del libro que se alinean con las fases del ciclo de vida de la solución de la Figura 1-6. Cada parte contiene uno o varios capítulos.
Figura 1-6. Pensamiento arquitectónico para el marco de seguridad; ver el diagrama original
Parte I. Conceptos
Comenzamos el libro con dos capítulos en los que se tratan los conceptos de seguridad y arquitectura utilizados en el libro. Estos capítulos proporcionan una base antes de adentrarnos en las fases del ciclo de vida de la solución:
- Introducción
-
El Capítulo 1 te pondrá en antecedentes sobre la arquitectura, la arquitectura de seguridad y el enfoque que utiliza este libro para recorrer el método.
- Conceptos de arquitectura
-
El Capítulo 2 trata de dónde encaja el pensamiento arquitectónico en el ciclo de vida del diseño y el desarrollo, y de la diferencia entre arquitectura empresarial y arquitectura de soluciones.
Parte II. Plan
En la Figura 1-6, continuamos con la fase Plan, en la que hablamos de la obtención de requisitos a partir del contexto de la empresa y, a continuación, de la definición de requisitos:
- Contexto empresarial
-
El Capítulo 3 trata de la información externa al desarrollo de la arquitectura de la solución, incluido el contexto empresarial, el entorno informático actual, las leyes y normativas, las políticas y normas, la arquitectura empresarial y los principios rectores.
- Requisitos y limitaciones
-
El Capítulo 4 trata de la recopilación de requisitos, empezando por las leyes externas, los reglamentos y las normas del sector. A continuación, trata de la documentación de los requisitos funcionales y no funcionales de un sistema.
Parte III. Diseño
Ahora que hemos reunido los requisitos, continuamos con la fase de Diseño de la Figura 1-6, en la que hablamos del diseño de la arquitectura de la solución, empezando por los componentes funcionales y pasando a la arquitectura de implementación:
- Contexto del sistema
-
El Capítulo 5 trata de la técnica central del pensamiento arquitectónico para proteger los activos sensibles centrándose en los límites del sistema, en dónde fluyen los datos, dónde se almacenan y dónde se procesan. Un arquitecto utiliza el diagrama de contexto del sistema para definir los límites del sistema y los actores externos que desencadenan los flujos de datos mediante interacciones con el sistema. El capítulo continúa describiendo la documentación de un registro de activos de información y la clasificación de los datos para identificar los tipos de controles en función de la sensibilidad de los datos.
- Seguridad de las aplicaciones
-
El Capítulo 6 trata de el desarrollo de una arquitectura funcional para una aplicación o carga de trabajo mediante la documentación de un diagrama de arquitectura de componentes. Continúa comenzando con el modelado de amenazas a alto nivel para los componentes de la aplicación.
- Responsabilidades compartidas
-
Enel capítulo 7, se tratará la implementación de subsistemas de aplicaciones en plataformas tecnológicas y se documentarán las responsabilidades compartidas para un conjunto de plataformas de nube híbrida.
- Seguridad de las infraestructuras
-
El Capítulo 8 continúa la elaboración de la solución mediante la implementación de los componentes funcionales en la infraestructura y garantizando que los flujos de datos utilicen principios de confianza cero para su protección. Un diagrama de arquitectura de implementación o un diagrama de arquitectura de nube proporciona a la documentación para una arquitectura de infraestructura de nube híbrida. En los diagramas de arquitectura se repetirá el modelado de amenazas.
- Patrones y decisiones de arquitectura
-
El capítulo 9 examina cómo puedes acelerar el pensamiento arquitectónico utilizando patrones de arquitectura y arquitecturas desplegables. A continuación, el capítulo introduce el uso de registros de decisiones arquitectónicas.
Parte IV. Construye
Una vez que hemos diseñado una arquitectura de solución, continuamos con la fase Construir de la Figura 1-6 considerando el ciclo de vida del desarrollo:
- Desarrollo y garantía de seguridad
-
El capítulo 10 examina en el ciclo de vida del desarrollo y cómo se integra en él el pensamiento arquitectónico para la seguridad, incluido el desarrollo ágil y el papel de un campeón de la seguridad. A continuación, examinamos el papel del registro de riesgos, problemas, suposiciones y dependencias durante el ciclo de vida de diseño y desarrollo.
Parte V. Corre
Por último, necesitamos que el sistema siga siendo seguro después de su puesta en marcha, por lo que tratamos los aspectos operativos del sistema, como se muestra en la fase Ejecutar de la Figura 1-6:
- Operaciones de Seguridad
-
Enel Capítulo 11 se analiza la elaboración de las funciones y responsabilidades identificadas con el diagrama de responsabilidad compartida en una tabla de Responsables, Contables, Consultados e Informados (RACI). A continuación, se documentan las responsabilidades mediante los procesos, procedimientos e instrucciones de trabajo necesarios para asegurar el sistema. A continuación, continuamos con la documentación de la detección de amenazas y la respuesta a incidentes mediante un caso de uso de detección de amenazas y un libro de ejecución de respuesta a incidentes.
Parte VI. Cerrar
Y el capítulo final incluye algunas reflexiones finales:
- Reflexiones finales
-
El capítulo 12 concluye el libro con algunas reflexiones sobre las buenas prácticas a la hora de integrar la seguridad en la arquitectura de una solución.
El pensamiento arquitectónico es la descomposición de una solución mediante un proceso iterativo en más y más detalles. Hablemos de cómo lo haremos.
Descomposición de la arquitectura de la solución
A lo largo de el libro, desglosamos la arquitectura de la solución del sistema de información en capas, como se muestra en la Figura 1-7. Comenzamos en la capa superior utilizando un diagrama de contexto del sistema para describir el límite del sistema y cómo se conecta con los actores humanos y del sistema externos. En el Capítulo 5 hablaremos más de esto.
A continuación, examinaremos los componentes funcionales de la aplicación, o carga de trabajo, que están dentro del límite del sistema. Describiremos cómo interactúan entre sí y empezaremos a examinar las amenazas para la aplicación. En el Capítulo 6 examinaremos esto con más detalle.
Figura 1-7. Capas de descomposición de la arquitectura de la solución
En la capa inferior, examinaremos la implementación de los componentes funcionales de la aplicación en la infraestructura y aplicaremos prácticas de arquitectura de confianza cero. En el Capítulo 8, exploraremos esta capa con más detalle.
Otros modelos de arquitectura pueden introducir capas adicionales, pero hemos intentado hacerlo sencillo para que puedas aplicar las técnicas a distintos métodos de arquitectura. Sin embargo, es probable que descompongas cada capa desde una perspectiva lógica a una física (o prescriptiva). Damos un ejemplo de esa descomposición en el Capítulo 5. Como otro ejemplo, observa la descomposición de contenedor, componente y diagrama de código en el Modelo C4.
Continuamos con un debate sobre los pasos del pensamiento arquitectónico y la descomposición .
Técnicas del método
En cada uno de los capítulos siguientes, encontrarás al menos una técnica de pensamiento arquitectónico tratada.
Dividimos las técnicas en dos tipos:
- Empresa
-
Las técnicas de tratadas se aplican a la arquitectura empresarial y no utilizan el estudio de casos.
- Estudio de caso
-
Las técnicas de analizadas utilizan el estudio de caso del Apéndice A para demostrar cómo aplicarlas.
La Tabla 1-2 enumera las técnicas y su tipo que se tratan en cada capítulo.
| Capítulo | Tipo de técnica | Técnica |
|---|---|---|
Empresa |
Arquitectura de seguridad empresarial |
|
Empresa |
Todos los artefactos del grupo de contexto empresarial |
|
Estudio de caso |
Caso práctico |
|
Estudio de caso |
Diagrama de contexto del sistema |
|
Estudio de caso |
Diagrama de flujo de datos |
|
Estudio de caso |
Diagrama de responsabilidad compartida |
|
Estudio de caso |
Diagrama de arquitectura de Implementación |
|
Estudio de caso |
Patrones de arquitectura |
|
Estudio de caso |
Registro de riesgos, suposiciones, problemas y dependencias (RAID) |
|
Estudio de caso |
Responsabilidades compartidas RACI |
Orden de las Técnicas
El orden de las técnicas a lo largo del libro utiliza el mismo orden que enseñamos a los alumnos del módulo de licenciatura en el Reino Unido. Diseñamos el orden para construir la arquitectura paso a paso. La documentación de los registros de decisiones arquitectónicas y de los artefactos RAID es algo que debería ocurrir desde el principio del proceso de pensamiento arquitectónico, pero tiene más sentido hablar de ello después de completar parte del pensamiento arquitectónico.
En muchos capítulos, ofrecemos una lista de comprobación de control de calidad o detalles adicionales sobre los pasos que debes realizar para ayudar a entregar artefactos de calidad.
Al final de cada capítulo hay una sección de Ejercicios con preguntas de respuesta múltiple. Las respuestas se encuentran en el Apéndice C. Además, en el sitio web complementario encontrarás preguntas sumativas con sus respuestas.
Cerremos este capítulo con algunas reflexiones finales.
Resumen
Empezamos hablando de cuatro técnicas fundamentales para diseñar la seguridad en los sistemas y de cómo es un problema cuando no se integran entre sí, creando un enfoque inconexo para integrar la seguridad en un sistema de información. Creemos que es necesario integrar las técnicas para crear un método sólido de arquitectura de la seguridad que se superponga a los métodos existentes de arquitectura de sistemas de información y software.
A continuación, hablamos de los distintos tipos de arquitectos que utilizarán el método. Creemos que todos los tipos de arquitectos de sistemas de información deben ser capaces de diseñar la seguridad de un sistema de información. Un arquitecto de seguridad está ahí para apoyar a otros arquitectos y desarrollar la arquitectura de los servicios de seguridad. Piensa en tu papel como consultor, arquitecto o ingeniero y en cómo encajará el pensamiento arquitectónico para la seguridad en tus proyectos actuales.
La sección final trataba de la estructura del libro, con el diagrama de dependencia de artefactos que ayuda a enmarcar el viaje a través del método de pensamiento arquitectónico para el diseño seguro. El capítulo contenía un resumen de los capítulos posteriores y de las técnicas utilizadas para crear los artefactos. Tal vez quieras crear una copia del diagrama de dependencia de artefactos para colgarla en tu pared y utilizarla como referencia en tu proyecto.
En el Capítulo 2, dedicaremos algún tiempo a reflexionar sobre dónde encaja el pensamiento arquitectónico en el ciclo de vida del desarrollo. A menudo vemos un salto del pensamiento de diseño a la ingeniería de software sin pensamiento arquitectónico, lo que causa problemas con los grandes cambios arquitectónicos necesarios en una fase posterior. También hablaremos de la diferencia entre arquitectura empresarial y arquitectura de soluciones, ya que a menudo puede confundirse. Estos temas ayudarán a dar contexto al capítulo siguiente, en el que iniciaremos el viaje a través del diagrama de dependencia de artefactos.
Otras lecturas
Aunque tratamos un método exhaustivo para la arquitectura de la seguridad en un sistema de información, será beneficioso conocer otros temas como la seguridad en la nube, la arquitectura del software, la arquitectura de la ciberseguridad y la arquitectura de la seguridad empresarial.
En lugar de ocultar esto al final del libro, tal vez quieras consultar algunos de estos otros libros y fuentes en línea mientras lees nuestro debate sobre el pensamiento arquitectónico para el diseño seguro.
Para la tecnología de seguridad en la nube que abarca varios proveedores de servicios en la nube, un buen punto de partida es Practical Cloud Security (O'Reilly) de Chris Dotson. Hay muchas otras fuentes en Internet y en libros que se centran en proveedores específicos de servicios en la nube.
Para la arquitectura de soluciones de ciberseguridad, te sugerimos que leas Arquitectura práctica de ciberseguridad (Packt Publishing), de Ed Moyle y Diana Kelley.
Si quieres saber más sobre los métodos de arquitectura de software, te sugerimos otras tres fuentes. Practical Software Architecture (IBM Press) de Tilak Mitra analiza un método utilizado ampliamente en IBM, centrado en la arquitectura local de los sistemas empresariales. Para la arquitectura de software con un enfoque de ingeniería, sugerimos la lectura de Fundamentals of Software Architecture (O'Reilly) de Mark Richards y Neal Ford. También mencionamos en varios lugares el Modelo C4 de Simon Brown, que proporciona un enfoque sencillo para visualizar la arquitectura del software.
Para arquitectura empresarial y de soluciones, Enterprise Security Architecture (CRC Press) de John Sherwood, Andrew Clark y David Lynas describe la arquitectura de seguridad de seis capas conocida como Sherwood Applied Business Security Architecture (SABSA). Se hace referencia a ella en otros lugares, incluido The Open Group. De The Open Group, existe la Arquitectura de Seguridad Empresarial Abierta (O-ESA) que tiene un marco para laarquitectura de seguridad empresarial.
A lo largo del libro, sugeriremos lecturas adicionales.
Ejercicios
-
¿Cuáles de las siguientes son las técnicas de seguridad fundamentales utilizadas en el método descrito en este libro? Selecciona todas las que corresponda.
-
Seguridad desde el diseño con modelos de amenazas
-
Arquitectura de confianza cero
-
Informática confidencial
-
Gestión del cumplimiento
-
Seguridad centrada en los datos
-
-
¿Cuáles son las características de la seguridad por diseño? Selecciona todas las que corresponda.
-
Incluye el modelado de amenazas.
-
Precede al pensamiento arquitectónico.
-
Está dirigido al diseño de productos tecnológicos.
-
Escala para diseñar un sistema de sistemas.
-
-
¿Cuáles son las características de la arquitectura de confianza cero? Selecciona todas las que correspondan.
-
"Nunca confíes, verifica siempre".
-
Sólo se trata de la seguridad de la red.
-
La identidad es el nuevo perímetro.
-
Es un producto o una solución.
-
-
¿Cuál de estas funciones de arquitecto se utiliza específicamente en un entorno de desarrollo ágil o DevOps?
-
Arquitecto de seguridad empresarial
-
Arquitecto de aplicaciones
-
Campeón de seguridad
-
Arquitecto asesor de seguridad
-
-
¿Cuál de las secciones de artefactos apoya el desarrollo general de la arquitectura durante todas las fases de desarrollo?
-
Requisitos
-
Arquitectura
-
Operaciones
-
Gobernanza
-
Garantía
-
-
¿El diagrama de dependencia de artefactos contiene cuál de los siguientes tipos de artefactos? Selecciona todos los que corresponda.
-
Diagramas
-
Registros de sucesos
-
Automatización
-
Tablas
-
-
¿Cuál de las siguientes afirmaciones es correcta?
-
La descomposición de la arquitectura de la solución incluye la arquitectura empresarial, la arquitectura de componentes y la arquitectura de implementación.
-
La descomposición de la arquitectura de la solución incluye la visión general de la arquitectura, la arquitectura de componentes y la arquitectura de implementación.
-
La descomposición de la arquitectura de la solución incluye el contexto del sistema, la arquitectura de componentes y la arquitectura de implementación.
-
La descomposición de la arquitectura de la solución incluye el contexto del sistema, la arquitectura de los componentes y el diagrama de flujo de datos.
-
Get Arquitectura de seguridad para la nube híbrida now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
