Arquitectura y prácticas operativas de Atlassian Cloud

Arquitectura de alojamiento de Atlassian Cloud

Utilizamos Amazon Web Services (AWS) como proveedor de servicios en la nube y sus instalaciones de centros de datos de gran disponibilidad en varias regiones del mundo. Cada región de AWS es una ubicación geográfica independiente con diversos grupos de centros de datos aislados y físicamente separados, conocidos como zonas de disponibilidad (AZ).

Aprovechamos los servicios informáticos, de almacenamiento, de red y de datos de AWS para generar nuestros productos y componentes de plataforma, lo que nos permite utilizar las capacidades de redundancia que ofrece AWS, como las zonas y regiones de disponibilidad.

Zonas de disponibilidad

Todas las zonas de disponibilidad se han diseñado de forma que se puedan aislar de los fallos que se produzcan en otras zonas y con el fin de proporcionar conectividad de red barata y de baja latencia a otras AZ de la misma región. Esta alta disponibilidad multizona es la primera línea de defensa ante los riesgos geográficos y ambientales, y supone que los servicios que se ejecutan en implementaciones multi-AZ deben ser capaces de resistir el fallo de las AZ.

Jira y Confluence utilizan el modo de implementación multi-AZ para Amazon RDS (Amazon Relational Database Service). En una implementación como esta, Amazon RDS provee y mantiene una réplica síncrona en espera en una AZ distinta de la misma región para proporcionar redundancia y capacidad de conmutación por error. La conmutación por error de una AZ está automatizada y, por lo general, tarda entre 60 y 120 segundos, por lo que las operaciones de la base de datos se pueden reanudar con la mayor rapidez posible sin intervención administrativa. Opsgenie, Statuspage, Trello y Jira Align utilizan estrategias de implementación similares, con pequeñas variaciones en el tiempo de replicación y de conmutación por error.

Ubicación de los datos

Los datos de Jira y Confluence se encuentran en la región más cercana a la que estén la mayoría de tus usuarios al registrarse. No obstante, sabemos que algunos clientes pueden requerir que sus datos permanezcan en una ubicación concreta, así que ofrecemos la residencia de datos. Actualmente, ofrecemos residencia de datos en las regiones de EE. UU. y la UE, así como en Australia, y se pretende añadir nuevas regiones. Si quieres obtener información y suscribirte para recibir novedades, consulta nuestra página dedicada a la residencia de datos.

Data for Bitbucket is located in two different availability zones in the US-East region.

Copias de seguridad de datos

En Atlassian, utilizamos un programa integral de copia de seguridad. Este programa incluye nuestros sistemas internos, donde las medidas de copia de seguridad se determinan de acuerdo con los requisitos de recuperación del sistema. También contamos con amplias medidas de copia de seguridad para nuestros productos de la nube, y específicamente con respecto a tus datos y los datos de tus aplicaciones. Utilizamos la función de instantánea de Amazon RDS (Relational Database Service) para crear copias de seguridad diarias y automatizadas de cada instancia de RDS.

Las instantáneas de Amazon RDS se conservan durante 30 días, admiten la recuperación de un momento dado y se cifran mediante cifrado AES-256. Los datos de copia de seguridad no se almacenan fuera de las instalaciones, sino que se replican en varios centros de datos de una región de AWS determinada. Además, realizamos pruebas trimestrales de nuestras copias de seguridad.

For Bitbucket, storage snapshots are retained for 7 days with support for point-in-time recovery.

No utilizamos estas copias de seguridad para revertir cambios destructivos iniciados por el cliente, como campos sobrescritos mediante secuencias de comandos o incidencias, proyectos o sitios eliminados. Para evitar la pérdida de datos, recomendamos realizar copias de seguridad de forma habitual. En la documentación de tu producto, encontrarás más información sobre la creación de copias de seguridad.

Seguridad de los centros de datos

AWS cuenta con varias certificaciones sobre la protección de sus centros de datos. Estas certificaciones abordan la seguridad física y ambiental, la disponibilidad de los sistemas, el acceso a la red y a redes troncales de IP, el aprovisionamiento de clientes y la gestión de problemas. El acceso a los centros de datos está limitado únicamente al personal autorizado y se controla mediante medidas de verificación biométrica de la identidad. Las medidas de seguridad físicas incluyen guardias de seguridad en las instalaciones, vigilancia mediante vídeo de circuito cerrado, sistemas de doble puerta de seguridad y medidas adicionales de protección frente a intrusiones.

Arquitectura de los servicios distribuidos

Con esta arquitectura de AWS, alojamos una serie de servicios de plataforma y de producto que se utilizan en nuestras soluciones. Esto incluye funciones de plataforma que se comparten y consumen en varios productos de Atlassian, como Media, Identity, Commerce, experiencias como nuestro Editor, así como funciones específicas de productos, como el servicio Jira Issue y el Análisis de Confluence.

Arquitectura de varios inquilinos

Además de nuestra infraestructura en la nube, hemos desarrollado y utilizamos una arquitectura de microservicios de varios inquilinos junto con una plataforma compartida que respalda nuestros productos. En la arquitectura de varios inquilinos, un solo servicio sirve a varios clientes, incluyendo las bases de datos y las instancias de cómputo necesarias para ejecutar nuestros productos en la nube. Cada fragmento (esencialmente un contenedor; consulta la figura 3 a continuación) contiene los datos de varios inquilinos, pero los datos de cada inquilino están aislados y son inaccesibles para otros inquilinos. Es importante tener en cuenta que no ofrecemos una arquitectura de inquilino único.

Aprovisionamiento y ciclo de vida de inquilinos

Cuando se aprovisiona a un cliente nuevo, una serie de eventos desencadenan la orquestación de servicios distribuidos y el aprovisionamiento de almacenes de datos. Por lo general, estos eventos se pueden asignar a uno de los siete pasos del ciclo de vida:

1. Los sistemas de comercio se actualizan inmediatamente con los metadatos y la información de control de acceso más recientes para ese cliente y, a continuación, un sistema de orquestación de aprovisionamiento alinea el "estado de los recursos aprovisionados" con el estado de la licencia a través de una serie de eventos de inquilinos y productos.

Eventos de inquilinos

Estos eventos afectan al inquilino en su conjunto y pueden ser:

• Creación: se crea un inquilino y se utiliza para sitios nuevos
• Destrucción: se elimina todo un inquilino

Eventos de productos

• Activación: tras la activación de productos con licencia o aplicaciones de terceros
• Desactivación: tras la desactivación de determinados productos o aplicaciones
• Suspensión: tras la suspensión de un producto existente determinado, con lo que se deshabilita el acceso de los clientes a un sitio del que son propietarios
• Anulación de la suspensión: tras la anulación de la suspensión de un producto existente determinado, con lo que se habilita el acceso de los clientes a un sitio del que son propietarios
• Actualización de licencia: contiene información sobre el número de licencias de un producto determinado, así como sobre su estado (activo/inactivo)

2. Creación del sitio del cliente y activación del conjunto correcto de productos para el cliente. El concepto de un sitio es el contenedor de varios productos con licencia para un cliente en particular (por ejemplo, Confluence y Jira Software para ＜site-name＞ .atlassian.net).

Separación de inquilinos

Aunque nuestros clientes comparten una infraestructura común basada en la nube cuando utilizan nuestros productos de Cloud, contamos con medidas para garantizar la separación lógica, de modo que las acciones de un cliente no puedan poner en riesgo los datos o el servicio de otros.

La estrategia de Atlassian para conseguirlo cambia según la aplicación. Para Jira y Confluence Cloud, empleamos el concepto “contexto de inquilino” para el aislamiento lógico de los clientes. Se ha implementado en el código de cada aplicación y está gestionado por lo que denominamos “servicio de contexto de inquilino” (TCS, por sus siglas en inglés). Dicho concepto garantiza lo siguiente:

• Los datos de los clientes se conservan separados de forma lógica de otros inquilinos cuando están en reposo.
• Cualquier solicitud procesada por Jira o Confluence cuenta con una vista de “inquilino específico” para que no afecte a otros inquilinos.

A grandes rasgos, el TCS funciona almacenando un contexto para cada uno de los inquilinos clientes. El contexto de cada inquilino está asociado con un ID único que el TCS almacena centralmente y que incluye diversos metadatos asociados con el inquilino (como las bases de datos en las que está incluido, qué licencias posee, a qué funciones puede acceder y otra información de configuración). Cuando un cliente accede a Jira o Confluence Cloud, el TCS emplea el ID de inquilino para cotejar esos metadatos y, a continuación, los vincula a cualesquiera operaciones que el inquilino realice en la aplicación durante la sesión.

Los bordes de Atlassian

Tus datos también se protegen a través de algo que llamamos “borde”: muros virtuales que construimos en torno a nuestro software. Cuando llega una solicitud, se envía al borde más cercano. Mediante una serie de validaciones, la solicitud se permite o se deniega.

• Llegan al borde de Atlassian más cercano al usuario. El borde verifica la sesión y la identidad del usuario a través de tu sistema de identidad.
• El borde determina dónde se encuentran los datos de tus productos según la información del TCS.
• El borde deriva la solicitud a la región de destino, donde llega a un nodo informático.
• El nodo usa el sistema de configuración del inquilino para determinar información, como la licencia y la ubicación de la base de datos, y llama a varios otros almacenes de datos y servicios (por ejemplo, la plataforma multimedia que aloja imágenes y archivos adjuntos) para recuperar la información que se necesita para atender la solicitud.
• La solicitud original del usuario con información recopilada de sus llamadas anteriores a otros servicios.

Autenticación y autorización de servicios

Nuestra plataforma utiliza un modelo de privilegios mínimos para acceder a los datos, mediante el cual estos últimos quedan restringidos únicamente al servicio responsable de guardarlos, tratarlos o recuperarlos. Por ejemplo, los servicios multimedia que te permiten tener una experiencia de carga y descarga de archivos uniforme en todos nuestros productos de Cloud cuentan con un almacenamiento exclusivo al que no puede acceder ningún otro servicio de Atlassian. Cualquier servicio que requiera acceso al contenido multimedia debe interactuar con la API de servicios multimedia. Como resultado, una autenticación y autorización sólidas en la capa de servicio también imponen una fuerte separación de funciones y un acceso a los datos con privilegios mínimos.

Utilizamos tokens web JSON (JWT) para garantizar la autoridad de firma fuera de la aplicación, por lo que nuestros sistemas de identidad y el contexto del inquilino son la fuente de información fidedigna. Los tokens no se pueden usar con otros fines que para los que están autorizados. Cuando tú o alguien de tu equipo hace una llamada a un microservicio o partición, los tokens se transfieren a tu sistema de identidad y se validan en él. Este proceso sirve para comprobar que el token esté actualizado y firmado antes de compartir los datos correspondientes. Cuando se combina con la autorización y la autenticación necesarias para acceder a estos microservicios, se consigue que las vulneraciones de los servicios tengan una repercusión limitada.

No obstante, sabemos que a veces pueden vulnerarse los sistemas de identidad. Para mitigar este riesgo, utilizamos dos mecanismos. En primer lugar, el TCS y los proxies de identidad están muy replicados. Tenemos un sidecar de TCS para casi todos los microservicios y utilizamos sidecars de proxy que se ramifican a la autoridad de identificación, por lo que hay miles de estos servicios en funcionamiento en todo momento. Si hay un comportamiento anómalo en uno o más de esos servicios, podemos detectarlo rápidamente y remediar el problema.

Además, no esperamos a que alguien encuentre una vulnerabilidad en nuestros productos o plataforma. Identificamos activamente estas situaciones para que tengan un impacto mínimo para ti y ejecutamos una serie de programas de seguridad para identificar y detectar las amenazas de seguridad y darles respuesta.

Servicio de contexto de inquilino

Nos aseguramos de que las solicitudes a cualquier microservicio contengan metadatos sobre el cliente (o inquilino) que solicita acceso. Esto se denomina servicio de contexto de inquilino. Los datos se obtienen directamente de nuestros sistemas de aprovisionamiento. Cuando se inicia una solicitud, el contexto se lee e internaliza en el código de servicio en ejecución, que se utiliza para autorizar al usuario. Todos los accesos a los servicios (y, por lo tanto, los accesos a los datos) en Jira y Confluence requieren este contexto de inquilino, o la solicitud se rechazará.

La autenticación y autorización de servicios se aplican a través del protocolo de autenticación de servicios de Atlassian (ASAP). Una lista de admitidos explícita determina qué servicios pueden comunicarse y los detalles de autorización especifican qué comandos y rutas están disponibles. Esto limita el posible movimiento lateral de un servicio vulnerado.

La autenticación y autorización de servicios, así como la salida, se controlan mediante un conjunto de proxies dedicados. Esto elimina la posibilidad de que las vulnerabilidades del código de la aplicación afecten a estos controles. La ejecución de código remota requeriría comprometer el host subyacente y eludir los límites del contenedor de Docker, no solo la capacidad de modificar la lógica de la aplicación. Más bien, nuestra detección de intrusiones a nivel de host detecta las discrepancias.

Estos proxies restringen el comportamiento de salida en función del comportamiento previsto del servicio. Los servicios que no necesitan emitir webhooks ni comunicarse con otros microservicios tienen prohibido hacerlo.

Cifrado de los datos

Los datos de los clientes almacenados en los productos de Atlassian Cloud se cifran durante el tránsito por las redes públicas mediante el protocolo TLS 1.2+ con confidencialidad directa total (PFS) para protegerlos contra la divulgación o modificación no autorizada. Nuestra implementación de TLS impone el uso de códigos y longitudes de clave eficaces cuando lo admite el navegador.

Las unidades de datos de los servidores que alojan los archivos adjuntos y los datos de los clientes de Jira Cloud, Jira Service Management Cloud, Bitbucket Cloud, Confluence Cloud, Jira Product Discovery, Statuspage, Opsgenie y Trello utilizan el cifrado de disco completo AES-256 estándar del sector para el cifrado de datos en reposo.

PII transmitted using a data-transmission network are subject to appropriate controls designed to ensure that data reaches its intended destination. Atlassian's internal Cryptography & Encryption Policy sets out the general principles for Atlassian's implementation of encryption & cryptography mechanisms to mitigate the risks involved in storing PII and transmitting it over networks. The type of encryption algorithm used to encrypt PII must take into account the classification level of the PII in accordance with Atlassian's internal Data Security & Information Lifecycle Management. To learn more about how we collect, share, and use customer data, refer to our privacy page.

To keep up to date on additional data encryption capabilities, see our cloud roadmap.

Gestión de claves

En Atlassian utilizamos AWS Key Management Service (KMS) para gestionar las claves. Para asegurar aún más la privacidad de los datos, KMS es el creador y almacenador secreto de estas claves. AWS inspecciona y gestiona de forma periódica e interna el proceso de cifrado, descifrado y gestión de claves como parte de sus procesos de validación interna. A cada clave se le asigna un propietario que será responsable de asegurar el nivel adecuado de controles de seguridad. Las claves que gestiona Atlassian se rotan cuando se producen cambios relevantes de funciones o de situación laboral.

También usamos el cifrado de sobres. AWS tiene la clave maestra, que nosotros nunca podemos ver, y cualquier solicitud de cifrado o descifrado de claves requiere las funciones y los permisos correctos de AWS. Al utilizar el cifrado de sobres para crear o generar claves para clientes individuales, tenemos diferentes claves para distintos tipos de datos a través de nuestros almacenes de datos. Además, tenemos un enfoque de cifrado para la capa de aplicación interna que proporciona claves de datos de respaldo en otras regiones de AWS. Las claves se rotan automáticamente cada año y la misma clave de datos no se usa para más de 100 000 elementos de datos.

Pronto, ofreceremos el cifrado “Bring Your Own Key” (BYOK, uso de claves de cifrado propias), que te permitirá cifrar los datos de tus productos de Cloud con claves autogestionadas en AWS KMS. Con BYOK, tendrás un control total sobre la gestión de tus claves y podrás conceder o revocar el acceso en cualquier momento, tanto para tus propios usuarios finales como para los sistemas de Atlassian.

Puedes integrar AWS KMS con AWS CloudTrail en tu cuenta de AWS para obtener registros de todo el uso de las claves. Esta solución permite el cifrado de tus datos en diferentes capas de las aplicaciones, como bases de datos, almacenamiento de archivos, así como nuestras memorias caché internas y la cola de eventos. El proceso no afectará al uso del producto.