ENISA: Agencia de la Unión Europea para la Ciberseguridad

La Agencia de la Unión Europea para la Ciberseguridad (ENISA) es un centro especializado en redes e información. Colabora estrechamente con los estados miembros de la UE y el sector privado ofreciendo orientación y recomendaciones sobre prácticas eficaces de ciberseguridad. La ENISA también ayuda a desarrollar y aplicar las políticas y las leyes de la UE relacionadas con la seguridad nacional de la información.

El Marco de garantía de la información (IAF) de la computación en la nube de la ENISA es un conjunto de criterios de garantía que las organizaciones pueden revisar con los proveedores de servicios en la nube (CSP) para asegurarse de que cuentan con la protección suficiente en relación con los datos de los clientes. El objetivo del IAF es evaluar el riesgo de la adopción de Cloud y reducir la carga de control de los CSP.

Atlassian se rige por el IAF mediante su adhesión a la Matriz de controles en la nube (CCM) de Cloud Security Alliance (CSA), que asigna los dominios y los controles de la CCM a los criterios de garantía del IAF, así como al certificado ISO 27001.

Atlassian mantiene las siguientes garantías en función de la CCM:

• Autoevaluación CSA Star 1

La siguiente guía proporciona criterios de garantía para ayudar a las organizaciones a elegir un proveedor de servicios en la nube. Si tienes alguna pregunta sobre detalles específicos, ponte en contacto con nuestro equipo de ventas empresariales en https://www.atlassian.com/es/enterprise/contact?formType=product-features.

6.01

La mayoría de las preguntas relacionadas con el personal son parecidas a las que le harías a tu propio personal de TI o al personal que se ocupe de tu TI. Como en la mayoría de las evaluaciones, existe un equilibrio entre el riesgo y el coste.

6.01. (a)

¿Qué políticas y procedimientos implementas para contratar a tus administradores de TI o a otras personas con acceso al sistema? Estos deberían incluir:

• Verificaciones previas a la contratación (identidad, nacionalidad o estatus, historial y referencias laborales, condenas penales e investigación de antecedentes [para el personal sénior que ocupa puestos de alto privilegio]).

De acuerdo con las leyes de su lugar de residencia, a los nuevos Atlassians se les exige completar una verificación de antecedentes. De acuerdo con las leyes de su lugar de residencia, a los empleados recién contratados como resultado de una adquisición se les realiza una verificación de antecedentes tras la fecha de adquisición. Se realiza una comprobación de antecedentes penales a todos los nuevos empleados y los contratistas independientes; a la que se suma una verificación de educación, una verificación de empleo o una verificación de solvencia si el puesto o el nivel del puesto lo exigen. Realizamos verificaciones completas de antecedentes para puestos de ejecutivos sénior y contabilidad.

6.01. (b)

¿Hay políticas diferentes según el lugar donde se almacenen los datos o se ejecuten las aplicaciones?

• Por ejemplo, las políticas de contratación de una región pueden ser diferentes a las de otra.
• Las prácticas deben ser coherentes en todas las regiones.
• Puede ser que los datos confidenciales se almacenen en una región en particular con el personal adecuado.

Atlassian mantiene las restricciones al personal que necesite acceder a nuestros sistemas, aplicaciones e infraestructuras para cumplir sus funciones y responsabilidades laborales en función de los privilegios mínimos, y se aplican mediante nuestros procesos de autenticación. Todos los accesos se realizan mediante sesiones autenticadas y se basan en los permisos establecidos.

Todos los sistemas del nivel 1 se gestionan mediante una solución centralizada de inicio de sesión único (SSO) y directorio de Atlassian. Los usuarios reciben los derechos de acceso adecuados en función de estos perfiles, según el flujo de trabajo de nuestro sistema de gestión de recursos humanos. Atlassian utiliza la MFA para acceder a todos los sistemas del nivel 1. Hemos habilitado la autenticación de dos factores en la consola de gestión del hipervisor y en la API de AWS, y un informe de auditoría diario sobre todos los accesos a las funciones de gestión del hipervisor. Las listas de acceso a la consola de gestión del hipervisor y a la API de AWS se revisan trimestralmente. También mantenemos una sincronización de 8 horas entre nuestro sistema de recursos humanos y nuestro almacén de identidades.

En términos más generales, los controles relacionados con el control de acceso se tratan en la Política de gestión de accesos y este es un extracto: https://www.atlassian.com/es/trust

6.01. (c)

¿Qué programa de educación en materia de seguridad se ofrece para todo el personal?

Atlassian ofrece formación sobre la seguridad de la información como parte de la formación de incorporación ("primer día") para las nuevas contrataciones y de forma continua a todo el personal.

Además de esta formación general sobre la seguridad de la información, ofrecemos a nuestros desarrolladores una formación más específica sobre la codificación segura, que cuenta con el apoyo de nuestro programa de ingenieros de seguridad integrados.

También ofrecemos formación continua sobre temas relacionados con el malware, la suplantación de identidad y otros problemas de seguridad. Para obtener más información, consulta: https://www.atlassian.com/es/trust/security/security-practices#our-approach

Mantenemos un registro formal de la finalización de la formación del personal interno. Los empleados deben aceptar el Código de Conducta y ratificarlo anualmente. Esta política se proporciona a todos los empleados. Los requisitos de concienciación en materia de seguridad, confidencialidad y privacidad se presentan en sus cursos de formación del primer día y están a disposición de todos los empleados en Confluence.

6.01. (d)

¿Hay un proceso de evaluación continua?

• ¿Con qué frecuencia ocurre?
• Más entrevistas.
• Revisiones de acceso y privilegios de seguridad.
• Revisiones de políticas y procedimientos.

Atlassian ha obtenido las certificaciones SOC2, ISO27001 e ISO27018 para los servicios en la nube. Realizamos auditorías internas o de preparación y auditorías externas al menos una vez al año. Atlassian cuenta con la certificación ISO en varios productos, lo que exige evaluaciones de riesgos y revisiones periódicas de las prácticas de datos.

Para obtener más información, consulta: https://www.atlassian.com/es/trust/data-protection. Los clientes deben descargar y revisar periódicamente las actualizaciones de nuestros certificados e informes de conformidad en este sitio.

Atlassian tiene un marco político documentado con nuestra política de seguridad como la política principal. Tenemos un programa de gestión de políticas (PMP, por sus siglas en inglés) bien definido que incluye obligaciones relacionadas con la propiedad, la disponibilidad y el ciclo de revisión, y describe nuestros objetivos generales. Nuestras políticas se revisan al menos una vez al año y son aprobadas por la alta dirección. Obtén más información sobre nuestro PMP en: https://www.atlassian.com/es/trust/security/security-management-program

También hemos publicado extractos de cada una de nuestras políticas de alto nivel con los principios básicos, que se encuentran en: https://www.atlassian.com/es/trust/security/ismp-policies#policy-risk-governance

Todos los sistemas y proyectos se someten a una evaluación de impacto en lo que respecta a la información de identificación personal.

Nuestros acuerdos con terceros de Atlassian incluyen disposiciones de seguridad y privacidad, según corresponda. Los nuevos proveedores de Atlassian deben aceptar las políticas de privacidad y seguridad de nuestros contratos. Nuestros equipos jurídicos y de adquisiciones revisan los contratos, los SLA y las políticas internas de los proveedores para gestionar los riesgos asociados con la seguridad, la disponibilidad y la confidencialidad. El Programa de gestión de riesgos empresariales (ERM) de Atlassian realiza una evaluación de riesgos anual que incorpora la probabilidad y el impacto en todas las categorías de riesgo y se rige por el modelo de riesgo COSO. También realizamos evaluaciones de riesgos funcionales según corresponda en función del perfil de riesgo. Las evaluaciones de riesgos se revisan como parte de la renovación de la política y cada vez que la relación con el proveedor cambia de manera significativa.

6.02.

Las siguientes preguntas se aplican cuando el proveedor de servicios en la nube subcontrata a terceros para determinadas operaciones clave para la seguridad del funcionamiento (por ejemplo, cuando un proveedor de SaaS subcontrata la plataforma subyacente a un proveedor externo, cuando un proveedor de servicios en la nube subcontrata los servicios de seguridad a un proveedor de servicios de seguridad gestionados, cuando se usa un proveedor externo para la gestión de identidad de los sistemas operativos, etc.). Aquí también se incluyen los casos en los que hay terceros con acceso físico o remoto a la infraestructura del proveedor de servicios en la nube. Se da por hecho que todo este cuestionario se puede aplicar de forma recurrente a proveedores de servicios en la nube de terceros (o cualquier otro proveedor externo).

6.02. (a)

Define los servicios que se subcontratan en tu cadena de suministro de servicios y que son primordiales para la seguridad (incluida la disponibilidad) de tus operaciones.

Atlassian trabaja con subcontratistas externos para proporcionar sitios web, desarrollo de aplicaciones, alojamiento, mantenimiento, copias de seguridad, almacenamiento, infraestructura virtual, procesamiento de pagos, análisis y otros servicios. En https://www.atlassian.com/legal/sub-processors encontrarás una lista de los subprocesadores contratados actualmente por Atlassian y autorizados por el cliente.

6.02. (b)

Expón los procedimientos utilizados para garantizar el acceso de terceros a tu infraestructura (física o lógica).

• ¿Sometes a tus subcontratistas a auditorías? En caso afirmativo, ¿con qué frecuencia?

Nuestros equipos jurídicos y de adquisiciones revisan los contratos, los SLA y las políticas internas de los proveedores para gestionar los riesgos asociados a la seguridad, la disponibilidad y la confidencialidad. También realizamos evaluaciones de riesgos funcionales según corresponda en función del perfil de riesgo. Las evaluaciones de riesgos se revisan como parte de la renovación de la política y cada vez que la relación con el proveedor cambia de manera significativa. Nuestra política de gestión de datos de proveedores y terceros abarca este proceso, del que hay un extracto disponible aquí: https://www.atlassian.com/trust/security/ismp-policies

6.02. (c)

¿Los subcontratistas garantizan alguna disposición del SLA que sea inferior a los SLA que ofreces a tus clientes? Si no es así, ¿dispones de redundancia de proveedores?

Según el acuerdo de licencia, nuestras condiciones de la nube para clientes deben revisarse en el momento de la renovación de la suscripción mensual o anual. Nuestros equipos jurídicos y de adquisiciones revisan los contratos, los SLA y las políticas internas de los proveedores para gestionar los riesgos asociados a la seguridad, la disponibilidad y la confidencialidad. El Programa de gestión de riesgos empresariales (ERM, por sus siglas en inglés) de Atlassian realiza una evaluación de riesgos anual que incorpora la probabilidad y el impacto en todas las categorías de riesgo y se rige por el modelo de riesgo COSO. También realizamos evaluaciones de riesgos funcionales según corresponda en función del perfil de riesgo. Las evaluaciones de riesgos se revisan como parte de la renovación de la política y cada vez que la relación con el proveedor cambia de manera significativa.

6.02. (d)

¿Qué medidas se toman para asegurar que se cumplan y mantengan los niveles de servicio de terceros?

Nuestros equipos jurídicos y de adquisiciones revisan los contratos, los SLA y las políticas internas de los proveedores para gestionar los riesgos asociados a la seguridad, la disponibilidad y la confidencialidad. También realizamos evaluaciones de riesgos funcionales según corresponda en función del perfil de riesgo. Las evaluaciones de riesgos se revisan como parte de la renovación de la política y cada vez que la relación con el proveedor cambia de manera significativa. Nuestra política de gestión de datos de proveedores y terceros abarca este proceso, del que hay un extracto disponible aquí: https://www.atlassian.com/trust/security/ismp-policies

6.02. (e)

¿El proveedor de servicios en la nube puede confirmar que la política y los controles de seguridad se aplican (por contrato) a sus proveedores externos?

Todos los sistemas y proyectos se someten a una evaluación de impacto en lo que respecta a la PII. Nuestros acuerdos con terceros de Atlassian incluyen disposiciones de seguridad y privacidad, según corresponda. Los nuevos proveedores de Atlassian deben aceptar las políticas de privacidad y seguridad de nuestros contratos.

Nuestros equipos jurídicos y de adquisiciones revisan los contratos, los SLA y las políticas internas de los proveedores para gestionar los riesgos asociados a la seguridad, la disponibilidad y la confidencialidad. El Programa de gestión de riesgos empresariales (ERM, por sus siglas en inglés) de Atlassian realiza una evaluación de riesgos anual que incorpora la probabilidad y el impacto en todas las categorías de riesgo y se rige por el modelo de riesgo COSO. También realizamos evaluaciones de riesgos funcionales según corresponda en función del perfil de riesgo. Las evaluaciones de riesgos se revisan como parte de la renovación de la política y cada vez que la relación con el proveedor cambia de manera significativa.

6.03.

Se espera que en cualquier acuerdo comercial con proveedores externos se incluyan los niveles de servicio de todos los servicios de red. Sin embargo, además del acuerdo definido, el cliente final debe asegurarse de que el proveedor emplee los controles adecuados para evitar la divulgación no autorizada.

6.03. (a)

Expón tu política y procedimiento de control de cambios. También debes incluir el proceso utilizado para volver a evaluar los riesgos como consecuencia de los cambios y aclarar si los resultados están disponibles para los clientes finales.

Atlassian cuenta con un programa de gestión de riesgos empresariales (ERM, por sus siglas en inglés) de conformidad con el modelo de riesgos COSO y la ISO 31000. En el programa ERM se implementa un marco y una metodología de gestión de riesgos en Atlassian y se realizan evaluaciones de riesgos anuales, evaluaciones periódicas de riesgos específicos del entorno de los productos y evaluaciones de riesgos funcionales según sea necesario en función del perfil de riesgo.

En concreto, el marco de gestión de riesgos de Atlassian proporciona estándares, procesos, funciones y responsabilidades, tolerancias de riesgo aceptables y directivas para completar las actividades de evaluación de riesgos. Nuestros procesos y prácticas de gestión de riesgos impulsan la realización de nuestras evaluaciones de riesgos, que son repetibles y producen resultados válidos, uniformes y comparables. Las evaluaciones de riesgos que realiza Atlassian incorporan la probabilidad y el impacto en todas las categorías de riesgo, así como el tratamiento de todos los riesgos por encima de nuestro interés por el riesgo establecido internamente. Durante todas las fases del programa ERM, el equipo de riesgos y cumplimiento se comunica con las partes interesadas pertinentes y consulta a las pymes correspondientes.

El personal que interviene en los procesos de gestión de riesgos de Atlassian conoce bien sus responsabilidades y el desempeño de sus funciones y ha recibido formación al respecto. Todos los riesgos se controlan y gestionan con nuestra propia herramienta de Jira, cuya propiedad está en manos del equipo de gestión, con proyectos y planes de tratamiento asociados. Para obtener más información, consulta: https://www.atlassian.com/trust/security/security-management-program o https://www.atlassian.com/trust/compliance/risk-management-program

Nuestro proceso de gestión de cambios de Atlassian no es exactamente igual que los procesos de cambio tradicionales. Empleamos un proceso de control llamado Revisión por compañeros y compilación correcta (PRGB, por sus siglas en inglés) para todos los cambios, ya sean en el código, las aplicaciones o la infraestructura. La revisión por compañeros está configurada en nuestra herramienta de CD, en la que deben designarse las ramas críticas para tener varios revisores para cada solicitud de extracción. Por lo general, estos son dos desarrolladores y el responsable del equipo. La parte de compilación correcta del proceso de control quiere decir que las integraciones de la fase de CI deben superar todas las pruebas funcionales, de integración, de seguridad y de otro tipo que se hayan desarrollado. Si no se superan estas pruebas (la compilación es defectuosa), el código no se fusionará y habrá que volver a revisarlo para corregir los errores. Cuando se supere la fase de compilación correcta, el binario se firmará criptográficamente y nuestro entorno de producción solo ejecutará los binarios que estén firmados con nuestra clave. Nuestro proceso de pruebas incluye componentes de evaluación automatizada y manual. Nos encanta publicar en nuestro blog todo lo que hacemos bien. Nuestro enfoque de uso de la "Asistencia de calidad" (en lugar del tradicional "Control de calidad") nos apasiona: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance

6.03. (b)

Define la política de acceso remoto.

Los requisitos de acceso remoto se definen en la política de gestión de accesos y en los estándares asociados. Los datos de los clientes se pueden replicar en las estaciones de trabajo de los empleados con fines de soporte o migración y con un ticket de atención al cliente activo. El cortafuegos tiene normas estrictas con las que se limita al entorno de producción el acceso a nuestra red VPN y sistemas autorizados. Nuestro acceso a la VPN requiere una autenticación de varios factores.

Todos los dispositivos (propiedad de Atlassian o BYOD) que utilizan los empleados de Atlassian para acceder a CUALQUIER herramienta de Atlassian se incorporan a la gestión de dispositivos mediante comprobaciones del nivel de seguridad y perfiles de seguridad del software MDM. Atlassian utiliza un modelo de seguridad de confianza cero en todos sus dispositivos. Puedes obtener más información aquí: https://www.atlassian.com/trust/compliance/resources/eba/eba-guidance

6.03. (c)

¿El proveedor mantiene procedimientos operativos documentados para los sistemas de información?

Los principios básicos de seguridad de las operaciones de Atlassian incluyen el desarrollo de documentos de procedimientos operativos estándar. También hemos publicado extractos de cada una de nuestras políticas de alto nivel con los principios básicos, que se encuentran en: https://www.atlassian.com/trust/security/ismp-policies

6.03. (d)

¿Existe un entorno por etapas para reducir el riesgo, como, por ejemplo, entornos de desarrollo, de pruebas y operativos? En caso afirmativo, ¿están separados dichos entornos?

Atlassian tiene políticas de seguridad de la información que prohíben el uso de datos de producción en entornos que no sean de producción, y cualquier intento de migración de datos de un entorno a otro se identificaría mediante el proceso de gestión de cambios. El código atraviesa un sistema de compilación centralizado en el que primero debe superar pruebas unitarias. Luego, pasa a la validación de la rama de funciones, donde se lleva a cabo la automatización adicional de las pruebas y los equipos de gestión de productos, desarrollo y control de calidad se encargan de hacer revisiones para determinar si pasa a la siguiente fase. Después, se somete a pruebas de aceptación de usuario, seguridad y validación del rendimiento. Los desarrolladores no pueden transferir directamente el código a producción. Encontrarás más información en https://www.atlassian.com/trust/security/security-practices#managing-changes-in-our-environment

Mantenemos una separación lógica y física de los entornos de producción y no producción (desarrollo), que se aíslan utilizando distintos métodos.

Nuestro entorno de ensayo está separado de forma lógica, aunque no física, pero se gestiona mediante procesos de acceso y control de cambios diseñados para la producción. Para obtener más información sobre nuestras prácticas de seguridad para los códigos, consulta: https://www.atlassian.com/trust/security/security-in-development.

6.03. (e)

Define los controles host y de red empleados para proteger los sistemas que alojan las aplicaciones y la información del cliente final. En estos se deben incluir detalles de la certificación según estándares externos (por ejemplo, la ISO 27001/2).

Atlassian Network Engineering utiliza tecnologías IPS integradas en nuestros cortafuegos en la nube y la oficina, y Atlassian las ha implementado en nuestros entornos de oficina. La protección contra las amenazas de la red la lleva a cabo AWS, incluida la protección contra DDoS y algunas funciones del cortafuegos de las aplicaciones web. Todos los datos de nuestros servicios se cifran en tránsito mediante TLS para protegerlos de la divulgación o la modificación no autorizadas, ya sea a través de HTTPS o SMTPS.

Atlassian ha obtenido las certificaciones SOC2, ISO27001 e ISO27018 para los servicios en la nube. Realizamos auditorías internas o de preparación y auditorías externas al menos una vez al año.

Para obtener más información, consulta: https://www.atlassian.com/trust/compliance. Los clientes deben descargar y revisar periódicamente las actualizaciones de nuestros certificados e informes de conformidad en este sitio.

6.03. (f)

Especifica los controles de protección que utilizas frente al código malicioso.

Atlassian ha implementado Crowdstrike Falcon (https://www.crowdstrike.com/falcon-platform/) para nuestros dispositivos Windows y Mac. No utilizamos antimalware en nuestros equipos con Linux. El antimalware forma parte de nuestra política de gestión de vulnerabilidades.

Mantenemos una política de gestión de amenazas y vulnerabilidades. Tenemos un programa de gestión de políticas (PMP, por sus siglas en inglés) bien definido en el que se incluyen obligaciones relacionadas con la propiedad, la disponibilidad y el ciclo de revisión, y en el que se describen nuestros objetivos generales. Nuestras políticas se revisan al menos una vez al año y son aprobadas por la alta dirección. Obtén más información sobre nuestro PMP en: https://www.atlassian.com/es/trust/security/security-management-program

También hemos publicado extractos de cada una de nuestras políticas de alto nivel con los principios básicos, que se encuentran en: https://www.atlassian.com/trust/security/ismp-policies

6.03. (g)

¿Se implementan configuraciones seguras para permitir únicamente la ejecución del código móvil autorizado y las funciones autorizadas (por ejemplo, ejecutar solo comandos específicos)?

Todos los servidores están configurados mediante nuestro sistema centralizado de configuración de Puppet según nuestro entorno operativo estándar, lo que incluye la eliminación de algunos paquetes de la imagen predeterminada y las actualizaciones críticas de los paquetes. Todos los roles de servidor están configurados de forma predeterminada para denegar todas las solicitudes de red entrantes, y solo están abiertos algunos puertos a los demás roles de servidor que requieren acceso a un determinado puerto para cumplir su función.

Nuestra red corporativa está separada de nuestra red de producción, y nuestras imágenes de máquinas están reforzadas para permitir solo los puertos y protocolos necesarios. Todos los sistemas de producción están alojados actualmente en las regiones estadounidenses de nuestro proveedor de servicios en la nube. Todos los datos en tránsito fuera de las redes de nube privada virtual (VPC) reforzadas se cifran a través de los canales estándar del sector.

Además, hay un sistema IDS en todos los servidores de producción, que incluye la supervisión y las alertas en tiempo real de cualquier cambio en los archivos o la configuración del sistema de producción y de eventos de seguridad anómalos.

Asimismo, hemos implementado una solución de gestión de sistemas centralizada (https://www.jamf.com/lp/apple-mobile-device-management-mdm-jamf/) para todos nuestros portátiles Mac. Usamos el cifrado de disco completo en nuestros ordenadores portátiles. También hemos implementado una solución de gestión de dispositivos móviles para nuestros smartphones (https://www.vmware.com/products/workspace-one.html). Todos los dispositivos deben estar inscritos para acceder a los sistemas y aplicaciones internos. Si un dispositivo móvil no lo está, no podrá acceder a ningún recurso interno y se encontrará en una red de invitados con la que solo se puede acceder a Internet. El acceso se gestiona mediante controles de acceso basados en roles para asegurar que solo lo tengan los usuarios que necesiten acceder a los datos de los clientes o inquilinos.

6.03. (h)

Detalla las políticas y procedimientos de las copias de seguridad. Esto debería incluir procedimientos para la gestión de los medios extraíbles; ya no se necesitan métodos para destruir de forma segura los medios. (Según sus requisitos empresariales, es posible que el cliente quiera poner en marcha una estrategia de copia de seguridad independiente. Esto resulta especialmente relevante cuando es necesario acceder a la copia de seguridad de manera urgente).

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. En el caso de Bitbucket, los datos se replican en una región diferente de AWS y se realizan copias de seguridad independientes a diario en cada región.

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. Los clientes también deben realizar sus propias copias de seguridad periódicas para poder anular los cambios iniciados por los clientes. Para obtener más información, consulta: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/#Can-Atlassian%E2%80%99s-RDS-backups-be-used-to-roll-back-changes.

Atlassian mantiene un estándar de retención y destrucción de datos que determina cuánto tiempo necesitamos conservar los distintos tipos de datos. Los datos se clasifican de acuerdo con nuestra política de seguridad de datos y ciclo de vida de la información de Atlassian y los controles se implementan en función de ella. En cuanto a los datos de los clientes, al rescindir un contrato de Atlassian, los datos que pertenezcan al equipo del cliente se eliminarán de la base de datos de producción en vivo y todos los archivos adjuntos subidos directamente a Atlassian se eliminarán en un plazo de 14 días. Los datos del equipo permanecerán en copias de seguridad cifradas hasta que esas copias de seguridad superen el período de retención de 90 días y se destruyan de acuerdo con la política de retención de datos de Atlassian. En caso de que sea necesario restaurar una base de datos en un plazo de 90 días a partir de la solicitud de eliminación de los datos, el equipo de operaciones volverá a borrar los datos en cuanto sea razonablemente posible una vez que el sistema de producción en vivo esté completamente restaurado. Para obtener más información, consulta: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Los registros de auditoría se usan si es necesario investigar un incidente, así como para solucionar problemas. Para ello, el cliente final deberá asegurarse de que dicha información está disponible.

6.03. (i)

¿Puede el proveedor detallar qué información se recoge en los registros de auditoría?

• ¿Durante cuánto tiempo se conservan estos datos?
• ¿Es posible segmentar los datos de los registros de auditoría para ponerlos a disposición del cliente final o de las autoridades sin perjudicar a otros clientes y que sigan siendo admisibles ante un tribunal?
• ¿Qué controles se emplean para proteger los registros del acceso no autorizado o la manipulación?
• ¿Qué método se utiliza para comprobar y proteger la integridad de los registros de auditoría?

Los registros clave del sistema se reenvían desde cada sistema a una plataforma de registro centralizada, donde los registros son solo de lectura. El equipo de seguridad en Atlassian crea alertas en nuestra plataforma de análisis de seguridad (Splunk) y supervisa los indicadores de compromiso. Nuestros equipos de SRE utilizan la plataforma para supervisar problemas de disponibilidad o rendimiento. Los registros se conservan durante 30 días en copia de seguridad en caliente y 365 días en copia de seguridad en frío.

Atlassian restringe la capacidad de ver y leer los registros de auditoría al personal autorizado de nuestra plataforma de registro centralizada.

Atlassian mantiene un estándar de retención y destrucción de datos que determina cuánto tiempo necesitamos conservar los distintos tipos de datos. Los datos se clasifican de acuerdo con nuestra política de seguridad de datos y ciclo de vida de la información de Atlassian y los controles se implementan en función de ella. En cuanto a los datos de los clientes, al rescindir un contrato de Atlassian, los datos que pertenezcan al equipo del cliente se eliminarán de la base de datos de producción en vivo y todos los archivos adjuntos subidos directamente a Atlassian se eliminarán en un plazo de 14 días. Los datos del equipo permanecerán en copias de seguridad cifradas hasta que esas copias de seguridad superen el período de retención de 90 días y se destruyan de acuerdo con la política de retención de datos de Atlassian. En caso de que sea necesario restaurar una base de datos en un plazo de 90 días a partir de la solicitud de eliminación de los datos, el equipo de operaciones volverá a borrar los datos en cuanto sea razonablemente posible una vez que el sistema de producción en vivo esté completamente restaurado. Para obtener más información, consulta: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

6.03. (j)

¿Cómo se revisan los registros de auditoría? ¿Qué eventos registrados hacen que se tomen medidas?

Los registros clave del sistema se reenvían desde cada sistema a una plataforma de registro centralizada, donde los registros son solo de lectura. El equipo de seguridad en Atlassian crea alertas en nuestra plataforma de análisis de seguridad (Splunk) y supervisa los indicadores de compromiso. Nuestros equipos de SRE utilizan la plataforma para supervisar problemas de disponibilidad o rendimiento. Los registros se conservan durante 30 días en copia de seguridad en caliente y 365 días en copia de seguridad en frío.

Atlassian restringe la capacidad de ver y leer los registros de auditoría al personal autorizado de nuestra plataforma de registro centralizada.

6.03. (k)

¿Qué fuente de tiempo se utiliza para sincronizar los sistemas y proporcionar una marca de fecha y hora precisa en el registro de auditoría?

Atlassian Cloud usa AWS Time Sync en todas las instancias implementadas.

6.03.01. (a)

Define los controles utilizados para proteger la integridad del sistema operativo y el software de aplicaciones empleados. Incluye los estándares que se sigan; p. ej., OWASP, SANS Checklist o SAFECode.

Nuestro equipo de ingenieros de seguridad revisa continuamente todo el código fuente de nuestros productos como parte del ciclo de desarrollo. Se emplean técnicas automatizadas y manuales. También utilizamos un proceso obligatorio de doble revisión por compañeros, en el que varios desarrolladores sénior o principales revisan todas las confirmaciones en la rama maestra. Los flujos de trabajo ágiles nos permiten identificar y corregir cualquier vulnerabilidad rápidamente, en especial, en nuestros servicios en la nube.

El proceso de revisión del código seguro de Atlassian incluye el análisis automatizado (es decir, el análisis de la composición del software) en busca de vulnerabilidades conocidas, incluidas las aprovechadas en ataques reales. Además, nuestro programa de gestión de vulnerabilidades analiza las imágenes de los contenedores y los hosts en busca de vulnerabilidades conocidas mediante Snyk. Para obtener más información, consulta: https://www.atlassian.com/trust/security/vulnerability-management.

Colaboramos con BugCrowd para mantener un programa de recompensas por errores y llevar a cabo evaluaciones continuas de las vulnerabilidades de nuestras aplicaciones y servicios disponibles al público; el programa se puede consultar en: https://bugcrowd.com/atlassian. Compartimos los resultados de las pruebas de penetración en curso de nuestro programa de recompensas por errores en: https://www.atlassian.com/trust/security/security-testing.

6.03.01. (b)

¿Cómo se valida que las nuevas publicaciones sean adecuadas para su propósito o no tengan riesgos (puertas traseras, troyanos, etc.)? ¿Se revisan antes de su uso?

Nuestro proceso de gestión de cambios de Atlassian no es exactamente igual que los procesos de cambio tradicionales. Empleamos un proceso de control de revisión por compañeros y compilación correcta (PRGB, por sus siglas en inglés) para todos los cambios, ya sean en el código, las aplicaciones o la infraestructura. La revisión por compañeros está configurada en nuestra herramienta de CD, en la que deben designarse las ramas críticas para tener varios revisores para cada solicitud de extracción. Por lo general, participan dos desarrolladores y el responsable del equipo. La parte de compilación correcta del proceso de control implica que la integración durante la fase de CI debe superar todas las pruebas funcionales, de integración, de seguridad y de otro tipo que se hayan desarrollado. Si no se superan estas pruebas (la compilación es defectuosa), el código no se fusionará y habrá que volver a revisarlo para corregir los errores. Cuando se supere la fase de compilación correcta, el binario se firmará criptográficamente y nuestro entorno de producción solo ejecutará los binarios que estén firmados con nuestra clave. Nuestro proceso de pruebas incluye componentes de evaluación automatizada y manual. Nos encanta publicar en nuestro blog todo lo que hacemos bien. Nuestro enfoque de uso de la "asistencia de calidad" (en lugar del tradicional "control de calidad") nos apasiona: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance.

Después de la implementación, hacemos regularmente análisis de vulnerabilidades automatizados y contamos con un programa de recompensas por errores líder del sector (https://bugcrowd.com/atlassian) para tener un control permanente de nuestras aplicaciones. Los cambios en la configuración del sistema se gestionan mediante un proceso automatizado que incluye la revisión.

El proceso de revisión del código seguro de Atlassian incluye el análisis automatizado (es decir, el análisis de la composición del software) en busca de vulnerabilidades conocidas, incluidas las aprovechadas en ataques reales. Además, nuestro programa de gestión de vulnerabilidades analiza las imágenes de los contenedores y los hosts en busca de vulnerabilidades conocidas mediante Snyk. Para obtener más información, consulta: https://www.atlassian.com/trust/security/vulnerability-management.

6.03.01. (c)

¿Qué prácticas se siguen para mantener la seguridad de las aplicaciones?

Nuestras aplicaciones requieren un proceso de revisión por compañeros y compilación correcta (PRGB, por sus siglas en inglés), tras lo cual los artefactos de las aplicaciones se firman criptográficamente, estos se implementan de manera automática mediante nuestra canalización de CI/CD y solo las aplicaciones firmadas por Atlassian pueden ejecutarse en nuestro entorno de producción.

Atlassian utiliza prácticas de desarrollo seguras en todas las fases del ciclo de vida del desarrollo. Consulta https://www.atlassian.com/trust/security/security-in-development para obtener más información.

En la fase de diseño, se incluyen prácticas como el modelado de amenazas, la revisión del diseño y nuestra biblioteca de estándares de seguridad, que se actualiza periódicamente. De este modo, nos aseguramos de que se tengan en cuenta los requisitos de seguridad. Durante el desarrollo, nos basamos en un proceso obligatorio de revisión por compañeros como primera línea de revisión de seguridad. Este proceso cuenta con comprobaciones de análisis estático automatizadas (SAST) y pruebas de seguridad manuales, tanto por parte de equipos internos como por expertos externos, como determina nuestro proceso de evaluación de riesgos. El desarrollo también está respaldado por programas de formación en seguridad de aplicaciones y una base de conocimientos sobre seguridad mantenida por el equipo de seguridad. Los procesos formales de preparación operativa y control de cambios garantizan que solo se implementen en la producción los cambios aprobados. Después de la implementación, hacemos regularmente análisis de vulnerabilidades automatizados y contamos con un programa de recompensas por errores líder del sector (https://bugcrowd.com/atlassian) para tener un control permanente de nuestras aplicaciones. Los cambios en la configuración del sistema se gestionan mediante un proceso automatizado que incluye la revisión de todos los cambios antes de su implementación en producción. Las operaciones de servicio de Atlassian pueden implementar parches en cuanto se identifique un riesgo importante. Tenemos criterios internos para determinar la rapidez con la que se implementan los parches y podemos aplicarlos en un plazo de 12 horas en todos los equipos. También existe un sistema IDS que incluye la supervisión de los archivos de configuración del sistema.

6.03.01. (d)

¿Se prueba la penetración de la publicación de un software para garantizar que no contiene vulnerabilidades? Si se descubren vulnerabilidades, ¿cuál es el proceso para solucionarlas?

Atlassian utiliza prácticas de desarrollo seguras en todas las fases del ciclo de vida del desarrollo. Consulta https://www.atlassian.com/trust/security/security-in-development para obtener más información.

Durante el desarrollo, nos basamos en un proceso obligatorio de revisión por compañeros como primera línea de revisión de seguridad. Este proceso cuenta con comprobaciones de análisis estático automatizadas (SAST) y pruebas de seguridad manuales, tanto por parte de equipos internos como por expertos externos, como determina nuestro proceso de evaluación de riesgos. El desarrollo también está respaldado por programas de formación en seguridad de aplicaciones y una base de conocimientos sobre seguridad mantenida por el equipo de seguridad.

Los procesos formales de preparación operativa y control de cambios garantizan que solo se implementen en la producción los cambios aprobados. Después de la implementación, hacemos regularmente análisis de vulnerabilidades automatizados y contamos con un programa de recompensas por errores líder del sector (https://bugcrowd.com/atlassian) para tener un control permanente de nuestras aplicaciones.

6.03.02. (a)

¿Se proporcionan detalles del procedimiento de gestión de parches seguido?

Mantenemos una política de gestión de amenazas y vulnerabilidades. Tenemos un programa de gestión de políticas (PMP, por sus siglas en inglés) bien definido en el que se incluyen obligaciones relacionadas con la propiedad, la disponibilidad y el ciclo de revisión, y en el que se describen nuestros objetivos generales. Nuestras políticas se revisan al menos una vez al año y la alta dirección se encarga de aprobarlas. Obtén más información sobre nuestro PMP en: https://www.atlassian.com/trust/security/security-management-program.

También hemos publicado extractos de cada una de nuestras políticas de alto nivel con los principios básicos, que se encuentran en: https://www.atlassian.com/trust/security/ismp-policies.

En Atlassian combinamos la gestión de terminales para implementar actualizaciones y parches en los sistemas operativos y las aplicaciones clave de todos los dispositivos terminales. También hemos implementado varias soluciones de protección de terminales contra amenazas tales como el malware. Para obtener más información, consulta: https://www.atlassian.com/trust/security/security-practices#keeping-track-of-information-assets.

6.03.02. (b)

¿Es posible asegurar que el proceso de gestión de parches abarque todos los niveles de las tecnologías de entrega en la nube, es decir, la red (componentes de la infraestructura, routers y conmutadores, etc.), los sistemas operativos de servidor, el software de virtualización, las aplicaciones y los subsistemas de seguridad (cortafuegos, puertas de enlace de antivirus, sistemas de detección de intrusos, etc.)?

Los cambios en la configuración del sistema se gestionan mediante un proceso automatizado que incluye la revisión de todos los cambios antes de su implementación en producción. Las operaciones de servicio de Atlassian pueden implementar parches en cuanto se identifique un riesgo importante. Tenemos criterios internos para determinar la rapidez con la que se implementan los parches y podemos aplicarlos en un plazo de 12 horas en todos los equipos. Existe un sistema IDS que incluye la supervisión de los archivos de configuración del sistema.

Los productos de Atlassian Cloud se pueden actualizar a la AMI más reciente en cuanto sea necesario. Nuestras aplicaciones de SaaS se actualizan varias veces a la semana. Tenemos mecanismos de implementación rápidos y controlados para actualizar nuestro código y las configuraciones del sistema. Atlassian utiliza activamente un control de cambios para los cambios no programados y de emergencia.

6.03.03. (a)

Define los controles utilizados para mitigar los ataques DDoS (denegación de servicio distribuida).

• Defensa en profundidad (análisis profundo de paquetes, limitación del tráfico, agujeros negros en paquetes, etc.).
• ¿Existen defensas contra los ataques "internos" (que se originan en las redes de los proveedores de servicios en la nube) y contra los ataques externos (que se originan en Internet o en las redes de los clientes)?
<

Los requisitos de seguridad de redes se definen en la política de seguridad de las comunicaciones, que se revisa anualmente de acuerdo con nuestro programa de gestión de políticas (PMP, por sus siglas en inglés). Para obtener más información sobre nuestro PMP, consulta: https://www.atlassian.com/trust/security/security-management-program.

Nuestra plataforma Atlassian Cloud tiene muy poca superficie expuesta a través de los cortafuegos. Revisamos las reglas de cortafuegos periódicamente. Hemos implementado un sistema IDS en nuestras oficinas y en nuestro entorno de alojamiento en la nube. En la plataforma Atlassian Cloud, el reenvío de registros se integra con una plataforma de análisis de seguridad. A nivel de contenedor de la plataforma Cloud, se mantiene la integridad de los archivos, ya que las instancias no se pueden modificar. Atlassian Network Engineering utiliza tecnologías IPS integradas en nuestros cortafuegos y hemos implementado sistemas IDS en nuestros entornos de oficina y en la nube. Nuestro proveedor u operador de servicios de Internet proporciona capacidades de prevención de ataques DDoS.

El rendimiento de nuestros cortafuegos también se evalúa periódicamente mediante nuestros programas de evaluación de vulnerabilidades (https://www.atlassian.com/trust/security/vulnerability-management) y pruebas de penetración (https://www.atlassian.com/trust/security/security-testing).

6.03.03. (b)

¿Qué niveles de aislamiento se utilizan?

• Para máquinas virtuales, máquinas físicas, redes, almacenamiento (por ejemplo, redes de área de almacenamiento), redes de gestión y sistemas de soporte a la gestión, etc.
<

Atlassian es una aplicación de SaaS para varios inquilinos. La solución con varios inquilinos es una función clave de Atlassian Cloud que permite a varios clientes compartir una instancia de la capa de aplicaciones de Jira o Confluence y, al mismo tiempo, aislar los datos de las aplicaciones de cada inquilino del cliente. Atlassian Cloud lo logra a través del "Servicio de contexto de inquilino" (TCS, por sus siglas en inglés). Cada ID de usuario está asociado exactamente a un inquilino, que se utiliza para acceder a las aplicaciones de Atlassian Cloud. Para obtener más información, consulta https://www.atlassian.com/es/trust/security/security-practices#our-approach.

Mantenemos una separación lógica y física de los entornos de producción y no producción (desarrollo), que se aíslan utilizando distintos métodos.

Nuestro entorno de ensayo está separado de forma lógica, pero no física, pero se gestiona mediante procesos de acceso y control de cambios diseñados para la producción.

6.03.03. (c)

¿La arquitectura permite operar de forma continuada desde la nube cuando la empresa se ha separado del proveedor de servicios y viceversa (por ejemplo, si hay una dependencia crítica del sistema LDAP del cliente)?

Existe tanto una política como un plan de continuidad empresarial y recuperación ante desastres que revisa anualmente el comité directivo dedicado a ambos temas. Para obtener más información, consulta https://www.atlassian.com/es/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e y https://www.atlassian.com/es/trust/security/data-management.

Atlassian utiliza centros de datos de alta disponibilidad de AWS en varias regiones del mundo para asegurar su funcionamiento continuo. Para obtener más información, consulta https://www.atlassian.com/es/trust/security/data-management.

6.03.03. (d)

¿La infraestructura de redes virtuales que utilizan los proveedores de servicios en la nube (en la arquitectura de PVLAN y VLAN con etiquetas 802.1q) está protegida según los estándares específicos del proveedor o de las prácticas recomendadas (por ejemplo, se evitan la suplantación de MAC, los ataques de "ARP poisoning", etc., mediante una configuración de seguridad específica)?

Los requisitos de seguridad de redes se definen en la política de seguridad de las comunicaciones, que se revisa anualmente de acuerdo con nuestro Programa de gestión de políticas (PMP, por sus siglas en inglés). Para obtener más información sobre nuestro PMP, consulta https://www.atlassian.com/es/trust/security/security-management-program.

Nuestra plataforma Atlassian Cloud tiene muy poca superficie expuesta a través de los cortafuegos. Revisamos las normas de cortafuegos periódicamente. Hemos implementado un sistema de detección de intrusiones en nuestras oficinas y en nuestro entorno de alojamiento en la nube. En la plataforma Atlassian Cloud, el reenvío de registros se integra con una plataforma de análisis de seguridad. A nivel de contenedor de la plataforma de Cloud, se mantiene la integridad de los archivos, ya que las instancias no se pueden modificar. Atlassian Network Engineering utiliza tecnologías IPS integradas en nuestros cortafuegos y las hemos implementado en nuestros entornos de oficina y en la nube. Nuestro proveedor u operador de servicios de Internet proporciona capacidades de prevención de ataques DDoS.

El rendimiento de nuestros cortafuegos también se evalúa periódicamente mediante nuestros programas de evaluación de vulnerabilidades (https://www.atlassian.com/es/trust/security/vulnerability-management) y pruebas de penetración (https://www.atlassian.com/es/trust/security/security-testing).

Además, en Atlassian supervisamos la configuración de nuestros entornos de AWS con respecto a líneas base de configuración establecidas.

6.03.04. (a)

¿El proveedor se asegura de que las imágenes virtuales estén reforzadas de forma predeterminada?

Todos los servidores están configurados mediante nuestro sistema centralizado de configuración de Puppet según nuestro entorno operativo estándar, lo que incluye la eliminación de algunos paquetes de la imagen predeterminada y las actualizaciones críticas de los paquetes. Todos los roles de servidor están configurados de forma predeterminada para denegar todas las solicitudes de red entrantes, y solo están abiertos algunos puertos a los demás roles de servidor que requieren acceso a un determinado puerto para cumplir su función.

Nuestra red corporativa está separada de nuestra red de producción, y nuestras imágenes de máquinas están reforzadas para permitir solo los puertos y protocolos necesarios. Todos los sistemas de producción están alojados actualmente en regiones estadounidenses de nuestro proveedor de servicios en la nube. Todos los datos en tránsito fuera de las redes de nube privada virtual (VPC, por sus siglas en inglés) reforzadas se cifran a través de canales estándar del sector.

Además, hay un sistema IDS en todos los servidores de producción, que incluye la supervisión y las alertas en tiempo real de cualquier cambio en los archivos o la configuración del sistema de producción y de eventos de seguridad anómalos.

En la plataforma Atlassian Cloud, los contenedores individuales no tienen una imagen. Cuando se inicia el contenedor, se elige una imagen de un repositorio estándar. Hacemos una auditoría continua de cada una de las imágenes y nuestras herramientas de configuración permiten volver a aplicarlas cuando es necesario. Como resultado, no se realizan cambios en las imágenes de máquina virtual.

Las compilaciones de imágenes del sistema operativo base de la AMI de AWS Linux tienen puertos, protocolos y servicios limitados. Comparamos nuestras compilaciones con las de la versión actual de la AMI para asegurarnos de que la configuración es adecuada.

Nuestras imágenes de Docker se gestionan en un entorno de cambios estrictamente controlado para asegurar la revisión y aprobación adecuadas de todos los cambios.

6.03.04. (b)

¿La imagen virtual reforzada está protegida contra el acceso no autorizado?

Todos los servidores están configurados mediante nuestro sistema centralizado de configuración de Puppet según nuestro entorno operativo estándar, lo que incluye la eliminación de algunos paquetes de la imagen predeterminada y las actualizaciones críticas de los paquetes. Todos los roles de servidor están configurados de forma predeterminada para denegar todas las solicitudes de red entrantes, y solo están abiertos algunos puertos a los demás roles de servidor que requieren acceso a un determinado puerto para cumplir su función.

Nuestra red corporativa está separada de nuestra red de producción, y nuestras imágenes de máquinas están reforzadas para permitir solo los puertos y protocolos necesarios. Todos los sistemas de producción están alojados actualmente en regiones estadounidenses de nuestro proveedor de servicios en la nube. Todos los datos en tránsito fuera de las redes VPC reforzadas se cifran a través de canales estándar del sector.

Además, hay un sistema IDS en todos los servidores de producción, que incluye la supervisión y las alertas en tiempo real de cualquier cambio en los archivos o la configuración del sistema de producción y de eventos de seguridad anómalos.

En la plataforma Atlassian Cloud, los contenedores individuales no tienen una imagen. Cuando se inicia el contenedor, se elige una imagen de un repositorio estándar. Hacemos una auditoría continua de cada una de las imágenes y nuestras herramientas de configuración permiten volver a aplicarlas cuando es necesario. Como resultado, no se realizan cambios en las imágenes de máquina virtual.

Las compilaciones de imágenes del sistema operativo base de la AMI de AWS Linux tienen puertos, protocolos y servicios limitados. Comparamos nuestras compilaciones con las de la versión actual de la AMI para asegurarnos de que la configuración es adecuada.

Nuestras imágenes de Docker se gestionan en un entorno de cambios estrictamente controlado para asegurar la revisión y aprobación adecuadas de todos los cambios.

Nuestro equipo de soporte global dispone de una cuenta en todos los sistemas y aplicaciones alojados con fines de mantenimiento y soporte. Dicho equipo puede acceder a las aplicaciones y datos alojados únicamente para supervisar su estado y realizar tareas de mantenimiento de los sistemas y aplicaciones, y solo cuando lo solicite el cliente a través de nuestro sistema de soporte.

6.03.04. (c)

¿Puede el proveedor confirmar que la imagen virtualizada no contiene las credenciales de autenticación?

Todos los servidores están configurados mediante nuestro sistema centralizado de configuración de Puppet según nuestro entorno operativo estándar, lo que incluye la eliminación de algunos paquetes de la imagen predeterminada y las actualizaciones críticas de los paquetes. Todos los roles de servidor están configurados de forma predeterminada para denegar todas las solicitudes de red entrantes, y solo están abiertos algunos puertos a los demás roles de servidor que requieren acceso a un determinado puerto para cumplir su función.

Nuestra red corporativa está separada de nuestra red de producción, y nuestras imágenes de máquinas están reforzadas para permitir solo los puertos y protocolos necesarios. Todos los sistemas de producción están alojados actualmente en regiones estadounidenses de nuestro proveedor de servicios en la nube. Todos los datos en tránsito fuera de las redes VPC reforzadas se cifran a través de canales estándar del sector.

Además, hay un sistema IDS en todos los servidores de producción, que incluye la supervisión y las alertas en tiempo real de cualquier cambio en los archivos o la configuración del sistema de producción y de eventos de seguridad anómalos.

En la plataforma Atlassian Cloud, los contenedores individuales no tienen una imagen. Cuando se inicia el contenedor, se elige una imagen de un repositorio estándar. Hacemos una auditoría continua de cada una de las imágenes y nuestras herramientas de configuración permiten volver a aplicarlas cuando es necesario. Como resultado, no se realizan cambios en las imágenes de máquina virtual.

Las compilaciones de imágenes del sistema operativo base de la AMI de AWS Linux tienen puertos, protocolos y servicios limitados. Comparamos nuestras compilaciones con las de la versión actual de la AMI para asegurarnos de que la configuración es adecuada.

Nuestras imágenes de Docker se gestionan en un entorno de cambios estrictamente controlado para asegurar la revisión y aprobación adecuadas de todos los cambios.

Nuestro equipo de soporte global dispone de una cuenta en todos los sistemas y aplicaciones alojados con fines de mantenimiento y soporte. Dicho equipo puede acceder a las aplicaciones y datos alojados únicamente para supervisar su estado y realizar tareas de mantenimiento de los sistemas y aplicaciones, y solo cuando lo solicite el cliente a través de nuestro sistema de soporte.

6.03.04. (d)

¿El cortafuegos del host funciona solo con los puertos mínimos necesarios para respaldar los servicios de la instancia virtual?

Todos los servidores están configurados mediante nuestro sistema centralizado de configuración de Puppet según nuestro entorno operativo estándar, lo que incluye la eliminación de algunos paquetes de la imagen predeterminada y las actualizaciones críticas de los paquetes. Todos los roles de servidor están configurados de forma predeterminada para denegar todas las solicitudes de red entrantes, y solo están abiertos algunos puertos a los demás roles de servidor que requieren acceso a un determinado puerto para cumplir su función.

Nuestra red corporativa está separada de nuestra red de producción, y nuestras imágenes de máquinas están reforzadas para permitir solo los puertos y protocolos necesarios. Todos los sistemas de producción están alojados actualmente en regiones estadounidenses de nuestro proveedor de servicios en la nube. Todos los datos en tránsito fuera de las redes VPC reforzadas se cifran a través de canales estándar del sector.

Nuestra plataforma Atlassian Cloud tiene muy poca superficie expuesta a través de los cortafuegos. Revisamos las normas de cortafuegos periódicamente. Hemos implementado un sistema de detección de intrusiones en nuestras oficinas y en nuestro entorno de alojamiento en la nube. En la plataforma Atlassian Cloud, el reenvío de registros se integra con una plataforma de análisis de seguridad. A nivel de contenedor de la plataforma de Cloud, se mantiene la integridad de los archivos, ya que las instancias no se pueden modificar. Atlassian Network Engineering utiliza tecnologías IPS integradas en nuestros cortafuegos y las hemos implementado en nuestros entornos de oficina y en la nube. Nuestro proveedor u operador de servicios de Internet proporciona capacidades de prevención de ataques DDoS.

El rendimiento de nuestros cortafuegos también se evalúa periódicamente mediante nuestros programas de evaluación de vulnerabilidades (https://www.atlassian.com/es/trust/security/vulnerability-management) y pruebas de penetración (https://www.atlassian.com/es/trust/security/security-testing).

6.03.04. (e)

¿Se puede ejecutar un servicio de prevención de intrusiones (IPS) basado en el host en la instancia virtual?

No se puede ejecutar, ya que Atlassian utiliza un modelo de software como servicio (SaaS).

6.03.05.

En términos generales, los proveedores de servicios de PaaS son responsables de la seguridad de la pila de software de la plataforma, y las recomendaciones de este documento son una buena base para asegurar que el proveedor de PaaS ha tenido en cuenta los principios de seguridad al diseñar y gestionar su plataforma de PaaS. A menudo es difícil obtener información detallada de los proveedores de PaaS sobre cómo protegen exactamente sus plataformas; sin embargo, las siguientes preguntas, junto con otras secciones de este documento, deberían ayudar a evaluar sus ofertas.

6.03.05. (a)

Solicita información sobre cómo se aíslan entre sí las aplicaciones con varios inquilinos. Es necesaria una descripción general de las medidas de contención y aislamiento.

No se puede ejecutar, ya que Atlassian utiliza un modelo de software como servicio (SaaS).

6.03.05. (b)

¿Qué garantía puede ofrecer el proveedor de PaaS de que el acceso a tus datos está restringido a los usuarios de tu empresa y a las aplicaciones de tu propiedad?

No se puede ejecutar, ya que Atlassian utiliza un modelo de software como servicio (SaaS).

6.03.05. (c)

La arquitectura de la plataforma debe ser el clásico "entorno aislado". ¿El proveedor se asegura de que la plataforma PaaS esté supervisada para detectar nuevos errores y vulnerabilidades?

No se puede ejecutar, ya que Atlassian utiliza un modelo de software como servicio (SaaS).

6.03.05. (d)

Los proveedores de PaaS deberían poder ofrecer un conjunto de funciones de seguridad (reutilizables entre sus clientes): ¿esto incluye la autenticación de usuarios, el inicio de sesión único, la autorización (gestión de privilegios) y SSL/TLS (disponible mediante una API)?

No se puede ejecutar, ya que Atlassian utiliza un modelo de software como servicio (SaaS).

6.03.06.

El modelo SaaS exige que el proveedor gestione el conjunto completo de aplicaciones que se entregan a los usuarios finales. Por lo tanto, los proveedores de SaaS son los principales responsables de proteger dichas aplicaciones. Los clientes normalmente son responsables de los procesos de seguridad operativa (gestión de usuarios y accesos). Las siguientes preguntas y otras secciones de este documento pueden ayudarte a evaluar las distintas opciones:

6.03.06. (a)

¿Qué controles de administración se proporcionan y se pueden utilizar para asignar privilegios de lectura y escritura a otros usuarios?

Los clientes de Cloud Enterprise y Premium tienen acceso a un panel de control de administración centralizado. Los administradores de la organización pueden gestionar el acceso y los permisos de los usuarios en todas las instancias de productos. Consulta nuestra entrada de blog aquí: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Los clientes de Atlassian pueden utilizar el proveedor de identidades externo que elijan si Atlassian lo admite. En la página de soporte de Atlassian https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/ se detallan estas funciones y cómo conectar el proveedor de identidades que has elegido.

6.03.06. (b)

¿El control de acceso del SaaS es detallado y personalizable según la política de tu organización?

Los clientes de Cloud Enterprise y Premium tienen acceso a un panel de control de administración centralizado. Los administradores de la organización pueden gestionar el acceso y los permisos de los usuarios en todas las instancias de productos. Consulta nuestra entrada de blog aquí: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Los clientes de Atlassian pueden utilizar el proveedor de identidades externo que elijan si Atlassian lo admite. En la página de soporte de Atlassian https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/ se detallan estas funciones y cómo conectar el proveedor de identidades que has elegido.

6.03.07. (a)

¿En caso de sobrecarga de los recursos (procesamiento, memoria, almacenamiento, red)...

• ¿Qué información se proporciona sobre la prioridad relativa asignada a mi solicitud en caso de que se produzca un error en el aprovisionamiento?
• ¿Existen plazos en los niveles de servicio y los cambios en los requisitos?
<

Atlassian planifica la capacidad con una antelación de 6 a 12 meses, y la planificación estratégica general se hace con 36 meses de anticipación.

Atlassian se encarga de los análisis de la arquitectura de escalado de Cloud AWS y Azure, y utiliza estos datos para diseñar el crecimiento de los productos de Atlassian. Estos datos no se comparten con los clientes en este momento.

6.03.07. (b)

¿Hasta qué punto puedes escalar hacia arriba? ¿El proveedor ofrece garantías sobre el máximo de recursos disponibles en un período mínimo?

Atlassian planifica la capacidad con una antelación de 6 a 12 meses, y la planificación estratégica general se hace con 36 meses de anticipación.

Atlassian se encarga de los análisis de la arquitectura de escalado de Cloud AWS y Azure, y utiliza estos datos para diseñar el crecimiento de los productos de Atlassian. Estos datos no se comparten con los clientes en este momento.

6.03.07. (c)

¿A qué velocidad puedes escalar? ¿El proveedor ofrece garantías sobre la disponibilidad de los recursos adicionales en un período mínimo?

Atlassian planifica la capacidad con una antelación de 6 a 12 meses, y la planificación estratégica general se hace con 36 meses de anticipación.

Atlassian se encarga de los análisis de la arquitectura de escalado de Cloud AWS y Azure, y utiliza estos datos para diseñar el crecimiento de los productos de Atlassian. Estos datos no se comparten con los clientes en este momento.

6.03.07. (d)

¿Qué procesos hay para gestionar las tendencias a gran escala en el uso de los recursos (por ejemplo, los efectos estacionales)?

Atlassian planifica la capacidad con una antelación de 6 a 12 meses, y la planificación estratégica general se hace con 36 meses de anticipación.

Atlassian se encarga de los análisis de la arquitectura de escalado de Cloud AWS y Azure, y utiliza estos datos para diseñar el crecimiento de los productos de Atlassian. Estos datos no se comparten con los clientes en este momento.

6.04.01.

Los siguientes controles se aplican a los sistemas de gestión de identidades y accesos del proveedor de servicios en la nube (los que están bajo su control).

6.04.01. (a)

¿Alguna cuenta tiene privilegios para todo el sistema en la nube? De ser así, ¿para qué operaciones (lectura/escritura/eliminación)?

Nuestro equipo de soporte global dispone de una cuenta en todos los sistemas y aplicaciones alojados con fines de mantenimiento y soporte. Dicho equipo puede acceder a las aplicaciones y datos alojados únicamente para supervisar su estado y realizar tareas de mantenimiento de los sistemas y aplicaciones, y solo cuando lo solicite el cliente a través de nuestro sistema de soporte.

6.04.01. (b)

¿Cómo se autentican y gestionan las cuentas con el nivel más alto de privilegios?

Atlassian mantiene las restricciones al personal que necesite este acceso para realizar sus funciones y responsabilidades laborales. Todos los sistemas del nivel 1 se gestionan mediante una solución centralizada de inicio de sesión único (SSO) y directorio de Atlassian. Los usuarios reciben los derechos de acceso adecuados en función de estos perfiles, según el flujo de trabajo de nuestro sistema de gestión de recursos humanos. Atlassian utiliza la MFA para acceder a todos los sistemas del nivel 1. Hemos habilitado la autenticación de dos factores en la consola de gestión del hipervisor y en la API de AWS y un informe de auditoría diario sobre todos los accesos a las funciones de gestión del hipervisor. Las listas de acceso a la consola de gestión del hipervisor y a la API de AWS se revisan trimestralmente. También mantenemos una sincronización de 8 horas entre nuestro sistema de recursos humanos y nuestro almacén de identidades.

6.04.01. (c)

¿Cómo se autorizan las decisiones más importantes (por ejemplo, el desaprovisionamiento simultáneo de grandes bloques de recursos), con identificación de factor único o de doble factor? ¿Qué roles de la organización se encargan de ello?

Atlassian mantiene las restricciones al personal que necesite este acceso para realizar sus funciones y responsabilidades laborales. Todos los sistemas del nivel 1 se gestionan mediante una solución centralizada de inicio de sesión único (SSO) y directorio de Atlassian. Los usuarios reciben los derechos de acceso adecuados en función de estos perfiles, según el flujo de trabajo de nuestro sistema de gestión de recursos humanos. Atlassian utiliza la MFA para acceder a todos los sistemas del nivel 1. Hemos habilitado la autenticación de dos factores en la consola de gestión del hipervisor y en la API de AWS y un informe de auditoría diario sobre todos los accesos a las funciones de gestión del hipervisor. Las listas de acceso a la consola de gestión del hipervisor y a la API de AWS se revisan trimestralmente. También mantenemos una sincronización de 8 horas entre nuestro sistema de recursos humanos y nuestro almacén de identidades.

Nuestros productos principales cuentan con controles de segregación de tareas, lo que incluye, entre otras cosas:

• Revisión de los controles de acceso
• Grupos de seguridad gestionados por aplicaciones de RR. HH.
• Aprobación de cambios/revisión por pares/implementación (PRGB)
• Controles del flujo de trabajo

6.04.01. (d)

¿Hay algún rol de alto privilegio asignado a la misma persona? ¿Esta asignación infringe las reglas de segregación de tareas o de privilegios mínimos?

Atlassian mantiene las restricciones al personal que necesite este acceso para realizar sus funciones y responsabilidades laborales. Todos los sistemas del nivel 1 se gestionan mediante una solución centralizada de inicio de sesión único (SSO) y directorio de Atlassian. Los usuarios reciben los derechos de acceso adecuados en función de estos perfiles, según el flujo de trabajo de nuestro sistema de gestión de recursos humanos. Atlassian utiliza la MFA para acceder a todos los sistemas del nivel 1. Hemos habilitado la autenticación de dos factores en la consola de gestión del hipervisor y en la API de AWS y un informe de auditoría diario sobre todos los accesos a las funciones de gestión del hipervisor. Las listas de acceso a la consola de gestión del hipervisor y a la API de AWS se revisan trimestralmente. También mantenemos una sincronización de 8 horas entre nuestro sistema de recursos humanos y nuestro almacén de identidades.

Nuestros productos principales cuentan con controles de segregación de tareas, lo que incluye, entre otras cosas:

• Revisión de los controles de acceso
• Grupos de seguridad gestionados por aplicaciones de RR. HH.
• Aprobación de cambios/revisión por pares/implementación (PRGB)
• Controles del flujo de trabajo

6.04.01. (e)

¿Utilizas el control de acceso basado en roles (RBAC)? ¿Se sigue el principio de privilegios mínimos?

Disponemos de un flujo de trabajo establecido que vincula nuestro sistema de gestión de RR. HH. y nuestro sistema de aprovisionamiento de acceso. Usamos un control de acceso basado en roles según perfiles de usuario predefinidos. La administración debe aprobar todas las cuentas de usuario antes de que puedan acceder a los datos, las aplicaciones, la infraestructura o los componentes de la red.

Atlassian mantiene las restricciones al personal que necesite acceder a nuestros sistemas, aplicaciones e infraestructuras para cumplir sus funciones y responsabilidades laborales en función de los privilegios mínimos, y se aplican mediante nuestros procesos de autenticación.

6.04.01. (f)

¿Qué cambios, si los hay, se llevan a cabo en los privilegios y roles de administrador para permitir un acceso extraordinario en caso de emergencia?

Nuestro equipo de soporte global dispone de una cuenta en todos los sistemas y aplicaciones alojados con fines de mantenimiento y soporte. Dicho equipo puede acceder a las aplicaciones y datos alojados únicamente para supervisar su estado y realizar tareas de mantenimiento de los sistemas y aplicaciones, y solo cuando lo solicite el cliente a través de nuestro sistema de soporte.

6.04.01. (g)

¿Existe el rol de administrador para el cliente? Por ejemplo, ¿el administrador del cliente puede añadir nuevos usuarios pero no tiene permitido cambiar el almacenamiento subyacente?

Atlassian proporciona a los clientes el rol de "administrador de la organización" para que administre los usuarios y grupos de sus productos. Para obtener más información, consulta la página https://support.atlassian.com/user-management/docs/give-users-admin-permissions/.

6.04.02. (a)

¿Qué comprobaciones de la identidad de las cuentas de usuario se llevan a cabo en el momento de registrarse? ¿Se sigue algún estándar como, por ejemplo, el marco de interoperabilidad de la administración electrónica?

• ¿Hay diferentes niveles de comprobaciones de la identidad en función de los recursos obligatorios?

A los nuevos Atlassians de todo el mundo se les exige completar una verificación de antecedentes. A los empleados recién contratados como resultado de una adquisición se les realiza una verificación de antecedentes tras la fecha de adquisición. Se realiza una comprobación de antecedentes penales a todos los nuevos empleados y los contratistas independientes, a la que se suma una verificación de educación, una verificación de empleo o una verificación de solvencia si el rol o el nivel del puesto lo exige. Realizamos verificaciones completas de antecedentes para puestos de ejecutivos sénior y contabilidad.

Disponemos de un flujo de trabajo establecido que vincula nuestro sistema de gestión de RR. HH. y nuestro sistema de aprovisionamiento de acceso. Usamos un control de acceso basado en roles según perfiles de usuario predefinidos. La administración debe aprobar todas las cuentas de usuario para que puedan acceder a los datos, las aplicaciones, la infraestructura o los componentes de la red.

6.04.02. (b)

¿Qué procesos hay para el desaprovisionamiento de credenciales?

Nuestro proceso de desaprovisionamiento ahora incluye la rescisión de la relación laboral, el contrato o el acuerdo. Los usuarios que cambian de puesto a nivel interno suelen mantener sus derechos de acceso para permitir la colaboración y el soporte continuos. Para ofrecer un equipo centrado en el cliente flexible, con una gran capacidad de respuesta y que vaya en línea con los valores de nuestra empresa, nos centramos en detectar el uso no autorizado del acceso en lugar de restringir el acceso, ya que esto último podría ralentizar nuestra capacidad de respuesta.

6.04.02. (c)

¿Las credenciales se aprovisionan y desaprovisionan simultáneamente en todo el sistema en la nube o existe algún riesgo al desaprovisionarlas en varias ubicaciones distribuidas geográficamente?

Disponemos de un flujo de trabajo establecido que vincula nuestro sistema de gestión de RR. HH. y nuestro sistema de aprovisionamiento de acceso. Usamos un control de acceso basado en roles según perfiles de usuario predefinidos. La administración debe aprobar todas las cuentas de usuario antes de que puedan acceder a los datos, las aplicaciones, la infraestructura o los componentes de la red.

Nuestra aplicación de RR. HH. se sincroniza con nuestra tienda de identidades interna cada 8 horas y elimina cualquier cuenta de los empleados o contratistas que ya no formen parte de la empresa.

6.04.03. (a)

¿Qué controles de almacenamiento y protección de datos se aplican al directorio de usuarios (por ejemplo, AD o LDAP) y al acceso a él?

Los datos se clasifican y gestionan de acuerdo con nuestra Política de ciclo de vida de la información y seguridad de los datos, y los controles se implementan en función de dicha política. Para obtener más información, consulta la página https://www.atlassian.com/es/trust/security/security-practices#our-approach.

Todos los sistemas y proyectos se someten a una evaluación de impacto en lo que respecta a la PII. Nuestros acuerdos con terceros de Atlassian incluyen disposiciones de seguridad y privacidad, según corresponda. Los nuevos proveedores de Atlassian deben aceptar las políticas de privacidad y seguridad de nuestros contratos.

Atlassian cuenta con la certificación ISO en varios productos, lo que exige evaluaciones de riesgos y revisiones periódicas de las prácticas de datos.

Nuestra evaluación del impacto de la transferencia de datos puede consultarse en la página https://www.atlassian.com/legal/data-transfer-impact-assessment.

Atlassian mantiene un estándar de retención y destrucción de datos que determina cuánto tiempo necesitamos conservar los distintos tipos de datos. Los datos se clasifican de acuerdo con nuestra política de seguridad de datos y ciclo de vida de la información de Atlassian y los controles se implementan en función de ella.

En cuanto a los datos de los clientes, al rescindir un contrato de Atlassian, los datos que pertenezcan al equipo del cliente se eliminarán de la base de datos de producción en vivo y todos los archivos adjuntos subidos directamente a Atlassian se eliminarán en un plazo de 14 días. Los datos del equipo permanecerán en copias de seguridad cifradas hasta que esas copias de seguridad superen el período de retención de 90 días y se destruyan de acuerdo con la política de retención de datos de Atlassian. En caso de que sea necesario restaurar la base de datos en un plazo de 90 días a partir de la solicitud de eliminación de los datos, el equipo de operaciones volverá a borrar los datos tan pronto como sea posible una vez que el sistema de producción en vivo esté completamente restaurado. Para obtener más información, consulta la página https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

6.04.03. (b)

¿Se pueden exportar los datos del directorio de usuarios en un formato interoperable?

Los administradores pueden exportar el directorio de usuarios desde el panel de administración. Las guías están disponibles en la siguiente página de soporte de Atlassian: https://support.atlassian.com/organization-administration/docs/export-users-from-a-site/.

6.04.03. (c)

¿El proveedor de servicios en la nube otorga acceso a los datos del cliente según sea necesario?

Atlassian mantiene las restricciones al personal que necesite este acceso para realizar sus funciones y responsabilidades laborales. Todos los sistemas del nivel 1 se gestionan mediante una solución centralizada de inicio de sesión único (SSO) y directorio de Atlassian. Los usuarios reciben los derechos de acceso adecuados en función de estos perfiles, según el flujo de trabajo de nuestro sistema de gestión de recursos humanos. Atlassian utiliza la MFA para acceder a todos los sistemas del nivel 1. Hemos habilitado la autenticación de dos factores en la consola de gestión del hipervisor y en la API de AWS y un informe de auditoría diario sobre todos los accesos a las funciones de gestión del hipervisor. Las listas de acceso a la consola de gestión del hipervisor y a la API de AWS se revisan trimestralmente. También mantenemos una sincronización de 8 horas entre nuestro sistema de recursos humanos y nuestro almacén de identidades.

Nuestros productos principales cuentan con controles de segregación de tareas, lo que incluye, entre otras cosas:

• Revisión de los controles de acceso
• Grupos de seguridad gestionados por aplicaciones de RR. HH.
• Aprobación de cambios/revisión por pares/implementación (PRGB)
• Controles del flujo de trabajo

6.04.04.

En cuanto a las claves en manos del proveedor de servicios en la nube:

6.04.04. (a)

¿Existen controles de seguridad para la lectura y escritura de las claves? Por ejemplo, políticas de contraseñas seguras, claves almacenadas en un sistema independiente, módulos de seguridad de hardware (HSM) para las claves del certificado raíz, autenticación basada en tarjetas inteligentes, acceso blindado directo al almacenamiento, claves de duración corta, etc.

Atlassian cuenta con políticas de cifrado y criptografía, y directrices de implementación. Estas políticas se revisan y actualizan anualmente de acuerdo con nuestro Programa de gestión de políticas (PMP). Para obtener más información, consulta la página https://www.atlassian.com/es/trust/security/security-management-program.

Atlassian dispone de procedimientos de gestión de claves documentados para nuestra infraestructura en la nube. Las claves de cifrado de los archivos adjuntos de Amazon, almacenados en S3, se gestionan mediante el Servicio de gestión de claves (KMS) de Amazon. Amazon inspecciona y verifica internamente el proceso de cifrado, gestión de claves y descifrado de forma periódica como parte de su proceso de auditoría actual. Las claves que gestiona Atlassian se rotan cuando se producen cambios relevantes de funciones o de situación laboral. El Servicio de gestión de claves de AWS cumple con los estándares SOC 1, SOC 2 y SOC 3. Para obtener más información, consulta la página https://aws.amazon.com/kms/.

6.04.04. (b)

¿Existen controles de seguridad para usar esas claves para firmar y cifrar los datos?

Atlassian dispone de procedimientos de gestión de claves documentados para nuestra infraestructura en la nube. Las claves de cifrado de los archivos adjuntos de Amazon, almacenados en S3, se gestionan mediante el Servicio de gestión de claves (KMS) de Amazon. Amazon inspecciona y verifica internamente el proceso de cifrado, gestión de claves y descifrado de forma periódica como parte de su proceso de auditoría actual. Las claves maestras de KMS, tras su creación, permiten una rotación automática para generar material de claves maestras cada 365 días, es decir, anualmente.

6.04.04. (c)

¿Existen procedimientos en caso de que las claves se vean comprometidas? Por ejemplo, listas de revocación de claves.

Atlassian dispone de procedimientos de gestión de claves documentados para nuestra infraestructura de Cloud. Las claves de cifrado de los archivos adjuntos de Amazon, almacenados en S3, se gestionan mediante el Servicio de gestión de claves (KMS) de Amazon. Amazon inspecciona y verifica internamente el proceso de cifrado, gestión de claves y descifrado de forma periódica como parte de su proceso de auditoría actual. Las claves que gestiona Atlassian se rotan cuando se producen cambios relevantes de funciones o de situación laboral. El Servicio de gestión de claves de AWS cumple con los estándares SOC 1, SOC 2 y SOC 3. Para obtener más información, consulta la página https://aws.amazon.com/kms/.

6.04.04. (c)

¿Existen procedimientos en caso de que las claves se vean comprometidas? Por ejemplo, listas de revocación de claves.

Atlassian dispone de procedimientos de gestión de claves documentados para nuestra infraestructura de Cloud. Las claves de cifrado de los archivos adjuntos de Amazon, almacenados en S3, se gestionan mediante el Servicio de gestión de claves (KMS) de Amazon. Amazon inspecciona y verifica internamente el proceso de cifrado, gestión de claves y descifrado de forma periódica como parte de su proceso de auditoría actual. Las claves que gestiona Atlassian se rotan cuando se producen cambios relevantes de funciones o de situación laboral. El Servicio de gestión de claves de AWS cumple con los estándares SOC 1, SOC 2 y SOC 3. Para obtener más información, consulta la página https://aws.amazon.com/kms/.

6.04.04. (d)

¿La revocación de claves puede solucionar problemas de simultaneidad en varios sitios?

Atlassian dispone de procedimientos de gestión de claves documentados para nuestra infraestructura de Cloud. Las claves de cifrado de los archivos adjuntos de Amazon, almacenados en S3, se gestionan mediante el Servicio de gestión de claves (KMS) de Amazon. Amazon inspecciona y verifica internamente el proceso de cifrado, gestión de claves y descifrado de forma periódica como parte de su proceso de auditoría actual. Las claves que gestiona Atlassian se rotan cuando se producen cambios relevantes de funciones o de situación laboral. El Servicio de gestión de claves de AWS cumple con los estándares SOC 1, SOC 2 y SOC 3. Para obtener más información, consulta la página https://aws.amazon.com/kms/.

6.04.04. (e)

¿Las imágenes del sistema del cliente están protegidas o cifradas?

Atlassian utiliza la versión 1.2 de Seguridad de la capa de transporte ("TLS"), estándar del sector, para crear una conexión segura mediante el Estándar de cifrado avanzado ("AES") de 256 ­bits. Los servidores que contienen los datos del usuario utilizan el cifrado AES de disco completo, estándar del sector. Los datos de los inquilinos se cifran en las copias de seguridad de AWS RDS o RDS y también se cifran en el almacenamiento a largo plazo (S3), así como en todos los archivos adjuntos. Para obtener más información, consulta: https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management.

Todos los datos de los clientes que se almacenan en los productos y servicios de Atlassian Cloud se cifran durante el tránsito por las redes públicas mediante el protocolo de Seguridad de la capa de transporte (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 Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, OpsGenie y Trello utilizan el cifrado de disco completo AES-256 estándar del sector para el cifrado de datos en reposo.

Para el cifrado de datos en reposo, ciframos específicamente los datos de cliente que se almacenan en un disco, como los datos de incidencias de Jira (detalles, comentarios, archivos adjuntos) o los datos de página de Confluence (contenido de página, comentarios, archivos adjuntos). El cifrado de datos en reposo ayuda a evitar el acceso no autorizado y garantiza que solo puedan acceder a los datos las funciones y servicios autorizados con acceso controlado a las claves de cifrado.

6.04.05. (a)

El cifrado se puede usar en varios lugares, ¿dónde se usa?

• ¿Datos en tránsito?
• ¿Datos en reposo?
• ¿Datos en el procesador o en la memoria?

Atlassian cuenta con políticas de cifrado y criptografía, y directrices de implementación. Estas políticas se revisan y actualizan anualmente de acuerdo con nuestro Programa de gestión de políticas (PMP). Para obtener más información, consulta la página https://www.atlassian.com/es/trust/security/security-management-program. .

Atlassian dispone de procedimientos de gestión de claves documentados para nuestra infraestructura de Cloud. Las claves de cifrado de los archivos adjuntos de Amazon, almacenados en S3, se gestionan mediante el Servicio de gestión de claves (KMS) de Amazon. Amazon inspecciona y verifica internamente el proceso de cifrado, gestión de claves y descifrado de forma periódica como parte de su proceso de auditoría actual. Las claves que gestiona Atlassian se rotan cuando se producen cambios relevantes de funciones o de situación laboral.

Todos los datos de los clientes que se almacenan en los productos y servicios de Atlassian Cloud se cifran durante el tránsito por las redes públicas mediante el protocolo de Seguridad de la capa de transporte (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 Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, OpsGenie y Trello utilizan el cifrado de disco completo AES-256 estándar del sector para el cifrado de datos en reposo.

Para el cifrado de datos en reposo, ciframos específicamente los datos de cliente que se almacenan en un disco, como los datos de incidencias de Jira (detalles, comentarios, archivos adjuntos) o los datos de página de Confluence (contenido de página, comentarios, archivos adjuntos). El cifrado de datos en reposo ayuda a evitar el acceso no autorizado y garantiza que solo puedan acceder a los datos las funciones y servicios autorizados con acceso controlado a las claves de cifrado.

6.04.05. (b)

¿Existe una política bien definida sobre qué debe cifrarse y qué no?

Atlassian cuenta con políticas de cifrado y criptografía, y directrices de implementación. Estas políticas se revisan y actualizan anualmente de acuerdo con nuestro Programa de gestión de políticas (PMP). Para obtener más información, consulta la página https://www.atlassian.com/es/trust/security/security-management-program.

Atlassian dispone de procedimientos de gestión de claves documentados para nuestra infraestructura en la nube. Las claves de cifrado de los archivos adjuntos de Amazon, almacenados en S3, se gestionan mediante el Servicio de gestión de claves (KMS) de Amazon. Amazon inspecciona y verifica internamente el proceso de cifrado, gestión de claves y descifrado de forma periódica como parte de su proceso de auditoría actual. Las claves que gestiona Atlassian se rotan cuando se producen cambios relevantes de funciones o de situación laboral.

6.04.05. (d)

¿Quién tiene las claves de acceso?

Atlassian utiliza el Servicio de gestión de claves de AWS (KMS) para gestionar las 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.

6.04.05. (e)

¿Cómo están protegidas las claves?

Atlassian utiliza el Servicio de gestión de claves de AWS (KMS) para gestionar las 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.

6.04.06. (a)

¿Qué métodos de autenticación se utilizan para las operaciones que requieren un alto nivel de seguridad? Esto puede incluir el inicio de sesión en interfaces de gestión, la creación de claves, el acceso a cuentas de varios usuarios, la configuración del cortafuegos, el acceso remoto, etc.

• ¿Se utiliza la autenticación de dos factores para gestionar los componentes críticos de la infraestructura, como los cortafuegos, etc.?

Seguimos las directrices descritas en la publicación especial 800-63B del NIST. Consulta: https://pages.nist.gov/800-63-3/sp800-63b.html.

El proceso de asignación de contraseñas se describe en la Política de contraseñas de Atlassian. Las nuevas contraseñas no se comunicarán electrónicamente, excepto en los casos en los que se envíe una contraseña inicial de un solo uso. En estos casos, el usuario se verá obligado a cambiar la contraseña de un solo uso la primera vez.

En términos más generales, los controles relacionados con el control de acceso se tratan en la Política de gestión de accesos; puedes consultar un extracto de esta aquí: https://www.atlassian.com/trust/security/ismp-policies.

Atlassian mantiene las restricciones al personal que necesite acceder a nuestros sistemas, aplicaciones e infraestructuras para cumplir sus funciones y responsabilidades laborales en función de los privilegios mínimos, y se aplican mediante nuestros procesos de autenticación. Todos los accesos se realizan mediante sesiones autenticadas y se basan en los permisos establecidos.

Atlassian mantiene las restricciones al personal que necesite este acceso para realizar sus funciones y responsabilidades laborales. Todos los sistemas del nivel 1 se gestionan mediante una solución centralizada de inicio de sesión único (SSO) y directorio de Atlassian. Los usuarios reciben los derechos de acceso adecuados en función de estos perfiles, según el flujo de trabajo de nuestro sistema de gestión de recursos humanos. Atlassian utiliza la MFA para acceder a todos los sistemas del nivel 1. Hemos habilitado la autenticación de dos factores en la consola de gestión del hipervisor y en la API de AWS , así como un informe de auditoría diario sobre todos los accesos a las funciones de gestión del hipervisor. Las listas de acceso a la consola de gestión del hipervisor y a la API de AWS se revisan trimestralmente. También mantenemos una sincronización de 8 horas entre nuestro sistema de recursos humanos y nuestro almacén de identidades.

6.04.07. (a)

¿Ofrecéis detección de anomalías (la capacidad de detectar el tráfico IP inusual y potencialmente perjudicial y los comportamientos de los usuarios o del equipo de soporte)? Por ejemplo, el análisis de los inicios de sesión fallidos y correctos, una hora del día inusual, los inicios de sesión múltiples, etc.

Nuestra plataforma Atlassian Cloud tiene muy poca superficie expuesta a través de los cortafuegos. Revisamos las normas de cortafuegos periódicamente. Hemos implementado un sistema de detección de intrusiones en nuestras oficinas y en nuestro entorno de alojamiento en la nube. En la plataforma Atlassian Cloud, el reenvío de registros se integra con una plataforma de análisis de seguridad. A nivel de contenedor de la plataforma de Cloud, se mantiene la integridad de los archivos, ya que las instancias no se pueden modificar. Atlassian Network Engineering utiliza tecnologías IPS integradas en nuestros cortafuegos y las hemos implementado sistemas de detección de intrusiones en nuestros entornos de oficina y en la nube. Nuestro proveedor u operador de servicios de Internet proporciona capacidades de prevención de ataques DDoS.

Los registros clave del sistema se reenvían desde cada sistema a una plataforma de registro centralizada, donde los registros son solo de lectura. El equipo de Seguridad en Atlassian crea alertas en nuestra plataforma de análisis de seguridad (Splunk) y supervisa los indicadores de compromiso. Nuestros equipos de SRE utilizan la plataforma para supervisar problemas de disponibilidad o rendimiento. Los registros se conservan durante 30 días en copia de seguridad en caliente y 365 días en copia de seguridad en frío.

6.04.07. (b)

¿Qué disposiciones existen en caso de robo de las credenciales de un cliente (detección, revocación, pruebas de acciones)?

En el contexto de los servicios de Atlassian Cloud, nuestros clientes pueden ser responsables de algunos o de todos los aspectos de la gestión del acceso de los usuarios de su servicio que estén bajo su control.

En consecuencia, en Atlassian permitimos a nuestros clientes gestionar el acceso de los usuarios del servicio bajo el control del cliente del servicio, por ejemplo, proporcionando derechos administrativos para gestionar o anular el acceso. Atlassian también compara las credenciales de los clientes con bases de datos de credenciales filtradas y obliga a los usuarios a actualizar su contraseña.

Atlassian no proporciona prevención de pérdida de datos (DLP) directamente como parte de las implementaciones en Cloud. Sin embargo, hay vendedores en Atlassian Marketplace, como Nightfall, que Atlassian recomienda a los clientes que desean esta función de DLP. Consulta la página de productos de Nightfall en Marketplace aquí: https://marketplace.atlassian.com/vendors/1217783/nightfall. Nightfall incluye el escaneo automático de información confidencial, incluidas las credenciales, los secretos y las claves de API.

Atlassian ha lanzado Beacon, en versión beta y con más funciones de DLP. Hasta que Beacon salga de esta fase beta, Atlassian seguirá recomendando Nightfall. Consulta más información sobre Atlassian Beacon en: https://www.atlassian.com/software/beacon.

Tenemos una política y un plan de respuesta ante incidentes de seguridad documentados, cuyos principios clave incluyen lo siguiente:

• Prever los incidentes de seguridad y prepararse para afrontarlos.
• Contener los incidentes, erradicarlos y recuperarse de ellos.
• Invertir en nuestro personal, nuestros procesos y nuestras tecnologías para asegurarnos de que tenemos la capacidad de detectar y analizar un incidente en cuanto se produzca.
• Establecer como máxima prioridad la protección de los datos personales y de los clientes durante los incidentes de seguridad.
• Probar periódicamente el proceso de respuesta ante incidentes de seguridad.
• Aprender de la función de gestión de incidentes de seguridad y mejorarla.
• Comunicar los incidentes de seguridad críticos al equipo de liderazgo de Atlassian.

6.04.08.

Las siguientes preguntas hacen referencia a los sistemas de gestión de accesos e identidades que ofrece el proveedor de servicios en la nube para que los utilice y controle el cliente de la nube.

6.04.08.01. (a)

¿El sistema permite una infraestructura de IDM federada que sea interoperable tanto para sistemas de alta seguridad (sistemas OTP, cuando sea necesario) como para sistema de baja seguridad (p. ej. nombre de usuario y contraseña)?

Atlassian Access admite los estándares de federación de identidades en todos nuestros productos de Atlassian (Confluence, Jira, Jira Align, Bitbucket, etc.). Atlassian Access sincroniza automáticamente tu Active Directory en Atlassian con Okta, Azure AD o OneLogin. Para obtener más información, consulta: https://www.atlassian.com/enterprise/cloud/access. Configuración de inicio de sesión único (SSO) de producto específico (SAML v2.0 genérico, Google, Okta, OneLogin, PingIdentity y ADFS):

• Opsgenie admite varios proveedores de SSO. Para obtener más información, consulta: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/.
• Trello es compatible con varios proveedores de SSO. Para obtener más información, consulta: https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization.
• Statuspage admite varios proveedores de SSO. Para obtener más información, consulta: https://help.statuspage.io/knowledge_base/categories/single-sign-on-2.

6.04.08.01. (b)

¿El proveedor de nube es interoperable con proveedores de identidades de terceros?

Los clientes de Atlassian pueden usar el proveedor de identidades externo que elijan si Atlassian lo admite. Se detallan estas funciones y cómo conectar el proveedor de identidades que has elegido en la página de soporte de Atlassian: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.04.08.01. (c)

¿Existe la posibilidad de incorporar el SSO?

Atlassian admite el uso de las identidades de Google, Microsoft y Apple para la autenticación de la mayoría de los productos. También admitimos SAML para nuestros servicios en la nube de Atlassian a través de Atlassian Access. Consulta: https://www.atlassian.com/enterprise/cloud/access.

6.04.08.02. (a)

¿El sistema de credenciales de cliente permite separar las funciones y responsabilidades, así como varios dominios (o una sola clave para varios dominios, funciones y responsabilidades)?

Atlassian es una aplicación de SaaS para varios inquilinos. La solución con varios inquilinos es una función clave de Atlassian Cloud que permite a varios clientes compartir una instancia de la capa de aplicaciones de Jira o Confluence y, al mismo tiempo, aislar los datos de las aplicaciones de cada inquilino del cliente. Atlassian Cloud lo logra a través del Servicio de contexto de inquilino (TCS). Cada ID de usuario está asociado exactamente a un inquilino, que se utiliza para acceder a las aplicaciones de Atlassian Cloud. Para obtener más información, consulta https://www.atlassian.com/es/trust/security/security-practices#tenant-isolation.

Los clientes de Cloud Enterprise y Premium tienen acceso a un panel de control de administración centralizado. Los administradores de la organización pueden gestionar el acceso y los permisos de los usuarios en todas las instancias de productos. Consulta nuestra entrada de blog aquí: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Atlassian proporciona a los clientes el rol de "administrador de la organización" para que administre los usuarios y grupos de sus productos. Para obtener más información, consulta https://support.atlassian.com/user-management/docs/give-users-admin-permissions/.

6.04.08.02. (b)

¿Cómo se gestiona el acceso a las imágenes del sistema del cliente y se garantiza que las claves criptográficas y de autenticación no figuran en ellas?

Nuestro equipo de soporte global dispone de una cuenta en todos los sistemas y aplicaciones alojados con fines de mantenimiento y soporte. Dicho equipo puede acceder a las aplicaciones y datos alojados únicamente para supervisar su estado y realizar tareas de mantenimiento de los sistemas y aplicaciones, y solo cuando lo solicite el cliente a través de nuestro sistema de soporte.

6.04.08.03. (a)

¿Cómo se identifica el proveedor de servicios en la nube ante el cliente (es decir, existe una autenticación mutua)?

• ¿Cuándo envía el cliente los comandos de la API?
• ¿Cuándo inicia sesión el cliente en la interfaz de gestión?

Atlassian utiliza la autenticación mutua para identificarse ante el cliente. La documentación de la API de Atlassian puede consultarse en: https://developer.atlassian.com/cloud/. El protocolo de autenticación de servicios de Atlassian (ASAP) es un protocolo de autenticación de servicio a servicio que utiliza un token de acceso implementado con el token web JSON (JWT) y firmado con claves RSA de una autoridad de confianza de Atlassian. Para obtener más información, consulta el protocolo de autenticación de servicios de Atlassian. No utilizamos las nociones tradicionales de "cuentas de servicio", sino que nos basamos en la autenticación y autorización de servicio a servicio.

6.04.08.03. (b)

¿Admites un mecanismo federado de autenticación?

Atlassian Access admite los estándares de federación de identidades en todos nuestros productos de Atlassian (Confluence, Jira, Jira Align, Bitbucket, etc.). Atlassian Access sincroniza automáticamente tu Active Directory en Atlassian con Okta, Azure AD o OneLogin. Para obtener más información, consulta: https://www.atlassian.com/enterprise/cloud/access. Configuración de inicio de sesión único (SSO) de producto específico (SAML v2.0 genérico, Google, Okta, OneLogin, PingIdentity y ADFS):

• Opsgenie admite varios proveedores de SSO. Para obtener más información, consulta: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/.
• Trello es compatible con varios proveedores de SSO. Para obtener más información, consulta: https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization.
• Statuspage admite varios proveedores de SSO. Para obtener más información, consulta: https://help.statuspage.io/knowledge_base/categories/single-sign-on-2.

6.05.

Es importante asegurarse de que el proveedor mantenga una lista actualizada de los activos de hardware y software (aplicaciones) bajo el control del proveedor de servicios en la nube. Esto permite comprobar que todos los sistemas cuentan con los controles adecuados y no se pueden utilizar como puerta trasera a la infraestructura.

6.05. (a)

¿Dispone el proveedor de un medio automatizado para inventariar todos los activos, lo que facilite su adecuada gestión?

Nuestros sistemas de producción se encuentran en infraestructuras obtenidas a través de proveedores de servicios en la nube. Estos sistemas no se rastrean a nivel de hardware por la propia naturaleza del servicio. Los microservicios subyacentes sobre los que se ejecutan nuestros productos se rastrean en una base de datos de "Servicio" personalizada. Esta base de datos se actualiza automáticamente al implementar un servicio.

Nuestro equipo de tecnología del lugar de trabajo mantiene un inventario de activos de todos los terminales utilizando nuestro propio software Jira para realizar su seguimiento.

6.05. (b)

¿Existe una lista de activos que el cliente ha utilizado durante un intervalo de tiempo determinado?

Atlassian es una aplicación de SaaS para varios inquilinos. La solución con varios inquilinos es una función clave de Atlassian Cloud que permite a varios clientes compartir una instancia de la capa de aplicaciones de Jira o Confluence y, al mismo tiempo, aislar los datos de las aplicaciones de cada inquilino del cliente. Atlassian Cloud lo logra a través del "Servicio de contexto de inquilino" (TCS, por sus siglas en inglés). Cada ID de usuario está asociado exactamente a un inquilino, que se utiliza para acceder a las aplicaciones de Atlassian Cloud. Para obtener más información, consulta: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Las siguientes preguntas deben utilizarse cuando el cliente final despliegue datos que requieran protección adicional (es decir, considerados sensibles).

6.05. (c)

¿Se clasifican los activos en términos de su sensibilidad y criticidad?

• En caso afirmativo, ¿emplea el proveedor la segregación adecuada entre los sistemas con diferentes clasificaciones y para un mismo cliente que tenga sistemas con clasificaciones de seguridad distintas?

Atlassian mantiene una calificación de 4 niveles en nuestros activos y servicios, con requisitos de tiempo de actividad, nivel de servicio y continuidad establecidos por nivel. Para obtener más información, consulta: https://www.atlassian.com/trust/security/data-management.

6.06.

Este conjunto de preguntas debe tenerse en cuenta para comprender los riesgos relacionados con la dependencia del proveedor.

6.06. (a)

¿Existen procedimientos documentados y API para exportar datos desde la nube?

Los datos de los clientes están disponibles a través de la aplicación web y la API. A continuación, se ofrece información detallada sobre productos concretos.

• Confluence, Jira y Jira Align: los detalles sobre nuestra API de Atlassian se pueden encontrar en: https://developer.atlassian.com/cloud/jira/platform/rest/v3/
• Trello: los miembros del consejo pueden exportar los datos del tablero en formato JSON a través de la API REST de Trello. Los archivos adjuntos se pueden recuperar de forma individual directamente desde Amazon S3 mediante el hipervínculo único del archivo. Las ediciones Trello Business Class y Enterprise ofrecen un proceso de exportación de datos simplificado para todos los datos y archivos adjuntos de la organización. Cada organización Business Class y Enterprise incluye la exportación con un clic de todos los tableros de la organización. De forma opcional, los archivos adjuntos que se suban directamente a Trello se pueden incluir en el archivo de exportación. En la exportación, los datos de cada tablero se incluyen en formato JSON y de valores separados por comas ("CSV").
• Opsgenie. La API está en: https://docs.opsgenie.com/docs/api-overview
• Statuspage. La API se encuentra en: https://doers.statuspage.io/api/v1/
• Bitbucket. Cualquier código fuente o repositorio se puede descargar o exportar desde Bitbucket por motivos de interoperabilidad. Consulta: https://confluence.atlassian.com/bitbucket/does-bitbucket-backup-my-repositories-288658413.html
• Halp. Tiene una función de exportación de CSV. Puedes leer más documentación aquí: https://plz.halp.com/article/5790zlyrun-export-to-csv

6.06. (b)

¿Proporciona el proveedor formatos de exportación interoperables para todos los datos almacenados en la nube?

Atlassian facilita las solicitudes de los clientes para exportar sus datos, en caso de que estén alojados en productos de Atlassian. Se dispone de sólidas herramientas de portabilidad y gestión de datos para exportar datos de productos y usuarios. Para obtener más información sobre la exportación de datos de Atlassian Cloud, consulta nuestra documentación sobre importación y exportación aquí: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Además, consulta: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ para obtener más detalles sobre la exportación de datos a formatos comunes, como CSV, HTML y XML.

6.06. (c)

En el caso del SaaS, ¿están estandarizadas las interfaces API utilizadas?

Puedes encontrar más información sobre nuestras API de Atlassian Cloud en: https://developer.atlassian.com/explore-the-apis/

Detalles específicos de la API del producto:

• Trello. La documentación de la API está disponible en: https://developer.atlassian.com/cloud/trello
• Jira Align. la API se encuentra en: https://help.jiraalign.com/hc/en-us/articles/360045371954-Getting-started-with-the-REST-API-2-0
• Statuspage. La API se encuentra en: https://doers.statuspage.io/api/v1
• Opsgenie. La API está en: https://docs.opsgenie.com/docs/api-overview
• Halp. No tiene API pública en este momento.

6.06. (d)

¿Existe alguna disposición para exportar las aplicaciones creadas por los usuarios en un formato estándar?

No se puede ejecutar, ya que Atlassian utiliza un modelo de software como servicio (SaaS).

6.06. (e)

¿Existen procesos para comprobar que los datos pueden exportarse a otro proveedor de servicios en la nube, por ejemplo, si el cliente desea cambiar de proveedor?

Atlassian facilita las solicitudes de los clientes para exportar sus datos, en caso de que estén alojados en productos de Atlassian. Se dispone de sólidas herramientas de portabilidad y gestión de datos para exportar datos de productos y usuarios. Para obtener más información sobre la exportación de datos de Atlassian Cloud, consulta nuestra documentación sobre importación y exportación aquí: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Además, consulta: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ para obtener más detalles sobre la exportación de datos a formatos comunes, como CSV, HTML y XML.

6.06. (f)

¿Puede el cliente realizar su propia extracción de datos para verificar que el formato es universal y se puede migrar a otro proveedor de servicios en la nube?

Atlassian facilita las solicitudes de los clientes para exportar sus datos, en caso de que estén alojados en productos de Atlassian. Se dispone de sólidas herramientas de portabilidad y gestión de datos para exportar datos de productos y usuarios. Para obtener más información sobre la exportación de datos de Atlassian Cloud, consulta nuestra documentación sobre importación y exportación aquí: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Además, consulta: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ para obtener más detalles sobre la exportación de datos a formatos comunes, como CSV, HTML y XML.

6.07.

Dar continuidad es importante para una organización. Aunque es posible establecer acuerdos de nivel de servicio en los que se detalle el tiempo mínimo de disponibilidad de los sistemas, sigue habiendo una serie de consideraciones adicionales.

6.07. (a)

¿Mantiene el proveedor un método documentado que detalle el impacto de una interrupción?

• ¿Cuáles son el RPO (objetivo de punto de recuperación) y el RTO (objetivo de tiempo de recuperación) de los servicios? Detallar según la criticidad del servicio.
• ¿Se abordan adecuadamente las actividades de seguridad de la información en el proceso de restauración?
• ¿Cuáles son las líneas de comunicación con los clientes finales en caso de una interrupción?
• ¿Están claramente identificadas las funciones y responsabilidades de los equipos a la hora de hacer frente a una interrupción?

Existe una política de continuidad empresarial y recuperación ante desastres y un plan de continuidad empresarial y recuperación ante desastres que revisa anualmente el comité directivo de continuidad empresarial y recuperación ante desastres. Para obtener más información (incluso en relación con los RPO, los RTO y la resiliencia mediante el uso de zonas de disponibilidad), consulta: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management y https://www.atlassian.com/trust/security/data-management.

Los centros de datos de nuestros socios mantienen varias certificaciones de cumplimiento. Estas certificaciones abordan la seguridad física, 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. Puedes encontrar la información sobre la garantía de protección física de AWS en: http://aws.amazon.com/compliance/

6.07. (b)

¿Ha categorizado el proveedor la prioridad de recuperación y cuál sería nuestra prioridad relativa (el cliente final) que restaurar? Nota: Esta puede ser una categoría (ALTA/MEDIA/BAJA).

Todos los propietarios de sistemas, procesos o servicios críticos garantizan una continuidad empresarial o una recuperación ante desastres adecuadas que se ajusta a la tolerancia a las interrupciones en caso de desastre. Los planes BCDR se prueban trimestralmente y se abordan todas las incidencias identificadas. Para obtener más información, consulta: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management y https://www.atlassian.com/trust/security/data-management.

6.07. (c)

¿Qué dependencias son relevantes para el proceso de restauración? Incluye a los proveedores y socios externos.

Atlassian dispone de un procedimiento y un registro de los esfuerzos de restauración de datos. En un nivel superior, esto se recoge en nuestra normativa interna de copias de seguridad y en la política de continuidad empresarial y recuperación ante desastres. Sin embargo, para cada servicio de Atlassian, tenemos varios documentos internos que incluyen libros de ejecución, planificaciones y procedimientos para las restauraciones iniciadas por el cliente y las restauraciones iniciadas por Atlassian.

6.07. (d)

En caso de que el sitio principal no esté disponible, ¿cuál es la separación mínima para la ubicación del sitio secundario?

Los centros de datos de nuestros socios mantienen varias certificaciones de cumplimiento. Estas certificaciones abordan la seguridad física, 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 se restringe 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. Puedes encontrar la información sobre la garantía de protección física de AWS en: http://aws.amazon.com/compliance/

6.07.01.

La gestión de incidentes y la respuesta ante estos forman parte de la gestión de la continuidad empresarial. El objetivo de este proceso es contener el impacto de eventos inesperados y potencialmente perturbadores hasta un nivel aceptable para una organización. Para evaluar la capacidad de una organización de minimizar la probabilidad de que se produzca o reducir el impacto negativo de un incidente de seguridad de la información, hay que hacerle las siguientes preguntas al proveedor de servicios en la nube:

6.07.01. (a)

¿Dispone el proveedor de un proceso formal para detectar, identificar, analizar y responder a los incidentes?

Disponemos de una política y un plan de respuesta ante incidentes de seguridad documentados, cuyos principios clave incluyen los siguientes:

• Prever los incidentes de seguridad y prepararse para afrontarlos.
• Contener los incidentes, erradicarlos y recuperarse de ellos.
• Invertir en nuestro personal, nuestros procesos y nuestras tecnologías para asegurarnos de que tenemos la capacidad de detectar y analizar un incidente en cuanto se produzca.
• Establecer como máxima prioridad la protección de los datos personales y de los clientes durante los incidentes de seguridad.
• Probar periódicamente el proceso de respuesta ante incidentes de seguridad.
• Aprender de la función de gestión de incidentes de seguridad y mejorarla.
• Comunicar los incidentes de seguridad críticos al equipo de liderazgo de Atlassian.


Según esta política, Atlassian mantiene un plan de respuesta ante incidentes de seguridad. Para obtener más información sobre nuestro proceso de respuesta ante incidentes de seguridad, consulta: https://www.atlassian.com/trust/security/security-incident-management

Los registros clave del sistema se reenvían desde cada sistema a una plataforma de registro centralizada, donde los registros son solo de lectura. El equipo de Seguridad en Atlassian crea alertas en nuestra plataforma de análisis de seguridad (Splunk) y supervisa los indicadores de compromiso. Nuestros equipos de SRE utilizan la plataforma para supervisar problemas de disponibilidad o rendimiento. Los registros se conservan durante 30 días en copia de seguridad en caliente y 365 días en copia de seguridad en frío.

Para obtener más información sobre nuestro programa de detecciones, consulta: https://www.atlassian.com/trust/security/detections-program

6.07.01. (b)

¿Se ensaya este proceso para comprobar que los procesos de gestión de incidentes son eficaces? ¿Se asegura también el proveedor, durante el ensayo, de que todos los miembros de la organización de asistencia del proveedor de servicios en la nube conocen el proceso y sus funciones durante la gestión de los incidentes (tanto durante el incidente como después del análisis)?

Para nuestros servicios de Atlassian Cloud, los planes de continuidad empresarial y recuperación ante desastres se prueban al menos trimestralmente. La disponibilidad en varias regiones se controla en tiempo real. Cada semana se realizan pruebas de conmutación por error regionales automatizadas en el entorno de preproducción. Las pruebas automatizadas de restauración de datos de configuración se realizan a diario en producción. Cada trimestre, todos los servicios de Atlassian realizan pruebas de resiliencia de la zona de disponibilidad en el entorno de preproducción. Para obtener más información sobre nuestro programa de continuidad empresarial, consulta: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Nuestros auditores externos prueban y validan nuestros planes de recuperación ante desastres como parte de nuestro programa de cumplimiento. Para obtener más información, consulta: https://www.atlassian.com/trust/compliance/resources

Hemos puesto en práctica nuestro plan de respuesta ante incidentes de seguridad a través de incidentes reales. Mantenemos un enfoque de mejora continua para optimizar nuestras capacidades de respuesta.

Una vez resuelto un incidente de gravedad alta 1 o 2, se cierra el ticket del incidente original y se inicia un proceso de revisión posterior al incidente (PIR). En el caso de incidentes de gravedad elevada, el equipo de seguridad realiza un análisis de la causa raíz y propone posibles mejoras del sistema o de la gestión del problema.

6.07.01. (c)

¿Cómo están estructuradas las capacidades de detección?

• ¿Cómo puede el cliente de la nube informar al proveedor de anomalías y eventos de seguridad?
• ¿Qué facilidades permite el proveedor para que los servicios RTSM de terceros seleccionados por el cliente intervengan en sus sistemas (cuando proceda) o coordinen las capacidades de respuesta ante incidentes con el proveedor de servicios en la nube?
• ¿Existe un servicio de supervisión de la seguridad en tiempo real (RTSM)? ¿Se externaliza el servicio? ¿Qué tipo de parámetros y servicios se controlan?
• ¿Proporcionas (previa solicitud) un informe periódico sobre los incidentes de seguridad (p. ej., según la definición de ITIL)?
• ¿Durante cuánto tiempo se conservan los registros de seguridad? ¿Están esos registros almacenados de forma segura? ¿Quién tiene acceso a los registros?
• ¿Es posible que el cliente cree un HIPS/HIDS en la imagen de la máquina virtual? ¿Es posible integrar la información que recopilan los sistemas de detección y prevención de intrusiones del cliente en el servicio RTSM del proveedor de servicios en la nube o en el de un tercero?

Nuestra plataforma Atlassian Cloud tiene muy poca superficie expuesta a través de los cortafuegos. Revisamos las normas de cortafuegos periódicamente. Hemos implementado IDS en nuestras oficinas y en nuestro entorno de alojamiento en la nube. En la plataforma Atlassian Cloud, el reenvío de registros se integra con una plataforma de análisis de seguridad. A nivel de contenedor de la plataforma de Cloud, se mantiene la integridad de los archivos, ya que las instancias no se pueden modificar. Atlassian Network Engineering utiliza tecnologías IPS integradas en nuestros cortafuegos y hemos implementado las tecnologías IDS en nuestros entornos de oficina y en la nube. Nuestro proveedor u operador de servicios de Internet proporciona capacidades de DDoS. Para obtener más información sobre nuestro programa de detecciones, consulta https://www.atlassian.com/es/trust/security/detections-program. Los registros clave del sistema se reenvían desde cada sistema a una plataforma de registro centralizada, donde los registros son solo de lectura. El equipo de Seguridad en Atlassian crea alertas en nuestra plataforma de análisis de seguridad (Splunk) y supervisa los indicadores de compromiso. Nuestros equipos de SRE utilizan la plataforma para supervisar incidencias de disponibilidad o rendimiento. Los registros se conservan durante 30 días en copia de seguridad en caliente y 365 días en copia de seguridad en frío. Atlassian restringe la capacidad de ver y leer los registros de auditoría al personal autorizado de nuestra plataforma de registro centralizada. Atlassian mantiene canales de información externos a través de los cuales podemos enterarnos de vulnerabilidades o incidentes, que incluyen nuestro programa de recompensas por errores, nuestro portal de soporte al cliente, así como buzones de correo electrónico y números de teléfono de seguridad definidos. Atlassian anima a los clientes a denunciar cualquier acceso no autorizado o comportamiento malintencionado. Para obtener más información, consulta https://www.atlassian.com/es/trust/security/security-incident-management y https://www.atlassian.com/es/trust/security/security-incident-responsibilities.

6.07.01. (d)

¿Cómo se definen los niveles de gravedad?

Atlassian utiliza el sistema común de puntuación de vulnerabilidades (CVSS) como método para evaluar el riesgo de seguridad y priorizar cada vulnerabilidad detectada. Los niveles de seguridad utilizados se basan en la puntuación del CVSS autocalculada de Atlassian, incluyen:

• Crítico;
• Alto;
• Medio y
• Bajo.


Para obtener más información, como los rangos de puntuación que determinan la gravedad, consulta https://www.atlassian.com/es/trust/security/security-severity-levels.

6.07.01. (e)

¿Cómo se definen los procedimientos de escalado? ¿Cuándo participa el cliente de Cloud (si es que lo hace alguna vez)?

Disponemos de una política y un plan de respuesta ante incidentes de seguridad documentados, cuyos principios clave incluyen los siguientes:

• Prever los incidentes de seguridad y prepararse para afrontarlos.
• Contener los incidentes, erradicarlos y recuperarse de ellos.
• Invertir en nuestro personal, nuestros procesos y nuestras tecnologías para asegurarnos de que tenemos la capacidad de detectar y analizar un incidente en cuanto se produzca.
• Establecer como máxima prioridad la protección de los datos personales y de los clientes durante los incidentes de seguridad.
• Probar periódicamente el proceso de respuesta ante incidentes de seguridad.
• Aprender de la función de gestión de incidentes de seguridad y mejorarla.
• Comunicar los incidentes de seguridad críticos al equipo de liderazgo de Atlassian.


Según esta política, Atlassian mantiene un plan de respuesta ante incidentes de seguridad. Para obtener más información sobre nuestro proceso de respuesta ante incidentes de seguridad, consulta https://www.atlassian.com/es/trust/security/security-incident-management

Atlassian entiende lo importante que es que se te notifique sin demora de cualquier vulneración de datos. Por eso Atlassian ha creado un equipo y un proceso amplio y multifuncional para gestionar los incidentes de seguridad, tal como se describe en esta página: https://www.atlassian.com/es/trust/security/security-incident-management.

Atlassian tiene un sólido historial de notificación puntual y proactiva de los incidentes y de trabajar con nuestros clientes en las mitigaciones necesarias.

Como es fundamental que los equipos de respuesta ante incidentes de seguridad de Atlassian se centren inmediatamente en clasificar y mitigar un incidente a medida que se desarrolla, no podemos acordar un plazo de 72 horas. En cambio, ofrecemos a los clientes la notificación "sin demoras indebidas", según el requisito legal del RGPD para los procesadores de datos, que cumple con las necesidades legales de la mayoría de nuestros clientes.

Los incidentes pueden ser simples o increíblemente complejos, por lo que, si bien podemos ofrecer lo que es necesario según la ley, no podemos acordar un plazo único para todos.

6.07.01. (f)

¿Cómo se documentan los incidentes y cómo se recogen las pruebas?

Los tickets de Jira se crean con fines de seguimiento y corrección y las fechas de vencimiento se asignan de acuerdo con nuestro SLO en función de la gravedad y el origen de la vulnerabilidad. Contamos con un proceso continuo de emisión de tickets de las vulnerabilidades identificadas a los propietarios del sistema; nuestro equipo de gestión de seguridad revisa cualquier vulnerabilidad comunicada y se asegura de que se tomen las medidas necesarias para solucionarla.

Una vez resuelto un incidente de gravedad alta 1 o 2, se cierra el ticket del incidente original y se inicia un proceso de revisión posterior al incidente (PIR). En el caso de incidentes de gravedad elevada, el equipo de seguridad realiza un análisis de la causa raíz y propone posibles mejoras del sistema o de la gestión de la incidencia.

6.07.01. (g)

Además de la autenticación, la contabilidad y la auditoría, ¿qué otros controles existen para evitar (o minimizar el impacto de) la actividad maliciosa de personas con información privilegiada?

Hemos implementado IDS en nuestras oficinas y en nuestro entorno de alojamiento en la nube. El reenvío de registros se integra con una plataforma de análisis de seguridad para la plataforma Atlassian Cloud. Los registros clave del sistema se reenvían desde cada sistema a una plataforma de registro centralizada, donde los registros son solo de lectura. El equipo de Seguridad en Atlassian crea alertas en nuestra plataforma de análisis de seguridad (Splunk) y supervisa los indicadores de compromiso. Para obtener más información sobre nuestro programa de detecciones, consulta https://www.atlassian.com/es/trust/security/detections-program.

6.07.01. (h)

¿Recopila el proveedor métricas e indicadores de incidentes (es decir, número de incidentes detectados o denunciados al mes, número de incidentes causados por los subcontratistas del proveedor de servicios en la nube y número total de incidentes de este tipo, tiempo medio de respuesta y resolución, etc.)?

• ¿Cuál de las siguientes opciones pone el proveedor a disposición del público (tenga en cuenta que no todos los datos de notificación de incidentes pueden hacerse públicos, ya que pueden comprometer la confidencialidad de los clientes y revelar información crítica para la seguridad)?

En este momento, no hacemos públicas nuestras métricas internas, pero sí que compartimos las acciones posteriores al incidente para los incidentes operativos de nivel de gravedad 0 o 1 en nuestra Statuspage, que puedes consultar aquí: https://status.atlassian.com/.

6.07.01. (j)

¿Con qué frecuencia pone a prueba el proveedor los planes de recuperación ante desastres y continuidad empresarial?

Para nuestros servicios de Atlassian Cloud, los planes de continuidad empresarial y recuperación ante desastres se prueban al menos trimestralmente. La disponibilidad en varias regiones se controla en tiempo real. Cada semana se realizan pruebas de conmutación por error regionales automatizadas en el entorno de preproducción. Las pruebas automatizadas de restauración de datos de configuración se realizan a diario en producción. Cada trimestre, todos los servicios de Atlassian realizan pruebas de resiliencia de la zona de disponibilidad en el entorno de preproducción. Para obtener más información sobre nuestro programa de continuidad empresarial, consulta: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Nuestros auditores externos prueban y validan nuestros planes de recuperación ante desastres como parte de nuestro programa de cumplimiento. Para obtener más información, consulta https://www.atlassian.com/es/trust/compliance/resources.

6.07.01. (k)

¿Recopila el proveedor datos sobre los niveles de satisfacción con los SLA?

Supervisamos el rendimiento y la disponibilidad de todas las instancias de Cloud, pero actualmente no ofrecemos un SLA formal de disponibilidad de las aplicaciones. Nuestro equipo de soporte proporciona un SLA con tiempo de respuesta inicial y, aunque no tenemos un SLA oficial de resolución de soporte, nuestro objetivo interno es resolver todos los casos asignados en un plazo de 48 horas. Atlassian muestra las estadísticas del estado más reciente del sistema de Cloud aquí: https://status.atlassian.com.

Si decides utilizar nuestras ofertas Premium o Enterprise, sí, ofrecemos garantías de SLA.

6.07.01. (l)

¿Realiza el proveedor pruebas del servicio de asistencia? Por ejemplo:

• pruebas de suplantación (¿es la persona al otro lado del teléfono que solicita el restablecimiento de la contraseña realmente quien dice ser?) o los llamados ataques de "ingeniería social".

Atlassian ofrece formación sobre la seguridad de la información como parte de la formación de incorporación ("primer día") para los que empiezan y de forma continua a todo el personal.

Además de esta formación general sobre la seguridad de la información, ofrecemos a nuestros desarrolladores una formación más específica sobre la codificación segura, que cuenta con el apoyo de nuestro programa de ingenieros de seguridad integrados.

También ofrecemos formación continua sobre temas relacionados con el malware, la suplantación de identidad y otros problemas de seguridad. https://www.atlassian.com/trust/security/security-practices#security-awareness-training

Mantenemos un registro formal de la finalización de la formación del personal interno. Los empleados deben aceptar el Código de Conducta y ratificarlo anualmente. Esta política se proporciona a todos los empleados. Los requisitos de concienciación en materia de seguridad, confidencialidad y privacidad se presentan en sus cursos de formación del primer día y están a disposición de todos los empleados en Confluence.

6.07.01. (m)

¿Realiza el proveedor pruebas de penetración? ¿Con qué frecuencia? ¿Qué se comprueba realmente durante la prueba de penetración? Por ejemplo, ¿se comprueba el aislamiento de seguridad de cada imagen para asegurarse de que no es posible "dividir" una imagen en otra y acceder también a la infraestructura de alojamiento? Las pruebas también deberían comprobar si es posible acceder, a través de la imagen virtual, a los sistemas de gestión y soporte del proveedor de servicios en la nube (por ejemplo, a los sistemas de control de acceso de administración y aprovisionamiento).

Mantenemos un equipo rojo interno que lleva a cabo pruebas de penetración continuas de toda nuestra infraestructura, servicios en la nube y personas.

Contratamos consultorías externas para que realicen pruebas de penetración anuales en las aplicaciones externas. También complementamos estas pruebas con pruebas de seguridad más pequeñas y continuas realizadas por nuestro equipo interno de pruebas de seguridad. Puedes consultar las cartas de evaluación de estas pruebas de penetración aquí, junto con más información sobre nuestro proceso de pruebas y nuestra estrategia de pruebas de seguridad externas, aquí: https://www.atlassian.com/es/trust/security/security-testing.

6.07.01. (n)

¿Realiza el proveedor pruebas de vulnerabilidad? ¿Con qué frecuencia?

El equipo de Seguridad en Atlassian lleva a cabo análisis continuos de vulnerabilidades de red de la infraestructura interna y externa utilizando un escáner de vulnerabilidades reconocido en el sector. Para obtener más información sobre nuestro programa de gestión de vulnerabilidades, consulta https://www.atlassian.com/es/trust/security/vulnerability-management.

6.07.01. (o)

¿Cuál es el proceso para corregir las vulnerabilidades (correcciones urgentes, reconfiguración, actualización a versiones posteriores del software, etc.)?

Los tickets de Jira se crean con fines de seguimiento y corrección y las fechas de vencimiento se asignan de acuerdo con nuestro SLO en función de la gravedad y el origen de la vulnerabilidad. Contamos con un proceso continuo de emisión de tickets de las vulnerabilidades identificadas a los propietarios del sistema; nuestro equipo de gestión de seguridad revisa cualquier vulnerabilidad comunicada y se asegura de que se tomen las medidas necesarias para solucionarla.

Para obtener más información sobre nuestro programa de gestión de vulnerabilidades, consulta https://www.atlassian.com/es/trust/security/vulnerability-management.

6.08.

Al igual que con la seguridad del personal, muchas de las posibles incidencias se deben a que la infraestructura de TI está bajo el control de un tercero. Como ocurre en la subcontratación tradicional, el efecto de una brecha de seguridad física puede afectar a varios clientes (organizaciones).

6.08. (a)

¿Qué garantías ofrecéis al cliente con respecto a la seguridad física del lugar? Proporciona ejemplos e indicar cualquier norma que se cumpla, p. ej. Sección 9 de la ISO 27001/2.

Los controles de seguridad física de nuestras oficinas se rigen por nuestra política de seguridad física y ambiental, que garantiza la implementación de una seguridad física sólida en nuestros entornos, ya sean locales o en la nube.

Los centros de datos de nuestros partners cumplen con SOC-2, como requisito mínimo. Estas certificaciones abordan diversos controles de seguridad, incluida la protección y la seguridad físicas y ambientales. El acceso a los centros de datos se restringe 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.

6.08. (a) (i)

¿Quién, aparte del personal de TI autorizado, tiene acceso sin escolta (físico) a la infraestructura de TI?

• Por ejemplo, limpiadores, gestores, personal de "seguridad física", contratistas, consultores, vendedores, etc.

Nuestras oficinas de Atlassian se rigen por la política interna de seguridad física y ambiental, que incluye la supervisión de los puntos físicos de entrada y salida. Hemos publicado extractos de todas nuestras políticas internas de seguridad y operaciones tecnológicas en https://www.atlassian.com/es/trust/security/ismp-policies#policy-risk-governance.

Las oficinas de Atlassian tienen controles de acceso que incluyen lectores de tarjetas y cámaras de vigilancia, y pueden restringir el acceso a horas y días específicos según sea necesario. La administración de edificios mantiene los registros de acceso a los edificios de oficinas y Workplace Experience los puede consultar con fines de investigación.

Los centros de datos de nuestros partners mantienen varias certificaciones de cumplimiento. Estas certificaciones abordan la seguridad física, 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. Puedes encontrar la información sobre la garantía de protección física de AWS en http://aws.amazon.com/compliance/.

6.08. (a) (ii)

¿Con qué frecuencia se revisan los derechos de acceso?

• ¿Con qué rapidez se pueden revocar los derechos de acceso?

Atlassian evalúa el rendimiento y la eficacia de su SGSI mediante las métricas apropiadas. Supervisamos el rendimiento del Atlassian Trust Management System (ATMS) y los controles pertinentes mediante revisiones de auditoría internas y externas. El equipo de conformidad de Atlassian gestiona nuestra planificación de auditorías de preparación internas e internas y la de auditorías externas (que se documentan internamente en nuestra página de hojas de ruta de auditoría). Las auditorías internas se centran en las áreas de alto riesgo de Atlassian y se realizan de forma regular según unos programas predeterminados y según el programa de auditoría empresarial acordado entre el equipo de riesgos y conformidad y el de auditorías internas. En este momento, no hacemos públicas nuestras métricas internas. El ATMS lo evalúan anualmente terceros independientes, también en función de cualquier cambio significativo. Atlassian ha obtenido las certificaciones SOC 2, ISO27001 e ISO7018 para los servicios en la nube. Atlassian también supervisa cada uno de los pilares del ATMS mediante reuniones periódicas de revisión operativa, que incluyen métricas específicas para cada uno de ellos. Esto incluye revisiones semanales del estado de conformidad del ATMS y otras reuniones que se documentan internamente en nuestro ATMS: la página de revisión del estado de la conformidad y la página de notas de las reuniones del ATMS. Para obtener más información, consulta https://www.atlassian.com/es/trust/compliance.

Tenemos un programa formal de gestión de la seguridad y revisamos nuestro Programa de gestión de la seguridad de la información (ISMP) anualmente. Para obtener más información sobre nuestro Programa de gestión de seguridad, consulta https://www.atlassian.com/es/trust/security/security-management-program.

6.08. (a) (iii)

¿Se evalúan los riesgos de seguridad y los perímetros de forma periódica?

• ¿Con qué frecuencia?

Atlassian evalúa el rendimiento y la eficacia de su SGSI mediante las métricas apropiadas. Supervisamos el rendimiento del Atlassian Trust Management System (ATMS) y los controles pertinentes mediante revisiones de auditoría internas y externas. El equipo de conformidad de Atlassian gestiona nuestra planificación de auditorías de preparación internas e internas y la de auditorías externas (que se documentan internamente en nuestra página de hojas de ruta de auditoría). Las auditorías internas se centran en las áreas de alto riesgo de Atlassian y se realizan de forma regular según unos programas predeterminados y según el programa de auditoría empresarial acordado entre el equipo de riesgos y conformidad y el de auditorías internas. En este momento, no hacemos públicas nuestras métricas internas. El ATMS lo evalúan anualmente terceros independientes, también en función de cualquier cambio significativo. Atlassian ha obtenido las certificaciones SOC 2, ISO27001 e ISO7018 para los servicios en la nube. Atlassian también supervisa cada uno de los pilares del ATMS mediante reuniones periódicas de revisión operativa, que incluyen métricas específicas para cada uno de ellos. Esto incluye revisiones semanales del estado de conformidad del ATMS y otras reuniones que se documentan internamente en nuestro ATMS: la página de revisión del estado de la conformidad y la página de notas de las reuniones del ATMS. Para obtener más información, consulta https://www.atlassian.com/es/trust/compliance.

Tenemos un programa formal de gestión de la seguridad y revisamos nuestro Programa de gestión de la seguridad de la información (ISMP) anualmente. Para obtener más información sobre nuestro Programa de gestión de seguridad, consulta https://www.atlassian.com/es/trust/security/security-management-program.

6.08. (a) (iv)

¿Se realizan evaluaciones de riesgos periódicas que incluyan aspectos como los edificios vecinos?

Atlassian evalúa el rendimiento y la eficacia de su SGSI mediante las métricas apropiadas. Supervisamos el rendimiento del Atlassian Trust Management System (ATMS) y los controles pertinentes mediante revisiones de auditoría internas y externas. El equipo de conformidad de Atlassian gestiona nuestra planificación de auditorías de preparación internas e internas y la de auditorías externas (que se documentan internamente en nuestra página de hojas de ruta de auditoría). Las auditorías internas se centran en las áreas de alto riesgo de Atlassian y se realizan de forma regular según unos programas predeterminados y según el programa de auditoría empresarial acordado entre el equipo de riesgos y conformidad y el de auditorías internas. En este momento, no hacemos públicas nuestras métricas internas. El ATMS lo evalúan anualmente terceros independientes, también en función de cualquier cambio significativo. Atlassian ha obtenido las certificaciones SOC 2, ISO27001 e ISO7018 para los servicios en la nube. Atlassian también supervisa cada uno de los pilares del ATMS mediante reuniones periódicas de revisión operativa, que incluyen métricas específicas para cada uno de ellos. Esto incluye revisiones semanales del estado de conformidad del ATMS y otras reuniones que se documentan internamente en nuestro ATMS: la página de revisión del estado de la conformidad y la página de notas de las reuniones del ATMS. Para obtener más información, consulta https://www.atlassian.com/es/trust/compliance.

Tenemos un programa formal de gestión de la seguridad y revisamos nuestro Programa de gestión de la seguridad de la información (ISMP) anualmente. Para obtener más información sobre nuestro Programa de gestión de seguridad, consulta https://www.atlassian.com/es/trust/security/security-management-program.

6.08. (a) (v)

¿Se controla o supervisa al personal (incluidos los terceros) que accede a las zonas seguras?

Nuestras oficinas de Atlassian se rigen por la política interna de seguridad física y ambiental, que incluye la supervisión de los puntos físicos de entrada y salida. Hemos publicado extractos de todas nuestras políticas internas de seguridad y operaciones tecnológicas en: https://www.atlassian.com/trust/security/ismp-policies

Las oficinas de Atlassian tienen controles de acceso que incluyen lectores de tarjetas y cámaras de vigilancia, y pueden restringir el acceso a horas y días específicos según sea necesario. La administración de edificios mantiene los registros de acceso a los edificios de oficinas y Workplace Experience los puede consultar con fines de investigación.

Los centros de datos de nuestros socios mantienen varias certificaciones de cumplimiento. Estas certificaciones abordan la seguridad física, 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. Podéis encontrar la información sobre la garantía de protección física de AWS en: http://aws.amazon.com/compliance

6.08. (a) (vi)

¿Qué políticas o procedimientos se aplican a la carga, descarga e instalación de equipos?

En las oficinas de Atlassian, los muelles de carga están aislados de las áreas de trabajo y están vigilados por cámaras de seguridad y el personal del edificio en todo momento. Nuestros socios de alojamiento de centros de datos gestionan la seguridad física y confiamos en sus certificaciones de cumplimiento para validar que los controles son eficaces.

6.08. (a) (vii)

¿Se inspeccionan las entregas para detectar riesgos antes de la instalación?

En las oficinas de Atlassian, los muelles de carga están aislados de las áreas de trabajo y están vigilados por cámaras de seguridad y el personal del edificio en todo momento. Nuestros socios de alojamiento de centros de datos gestionan la seguridad física y confiamos en sus certificaciones de cumplimiento para validar que los controles son eficaces.

6.08. (a) (viii)

¿Hay un inventario físico actualizado de los elementos en el centro de datos?

Un extracto de nuestra política de gestión de activos está disponible en https://www.atlassian.com/trust/security/ismp-policies. Atlassian mantiene un inventario de todos los activos de producción junto con sus propietarios. Todos nuestros sistemas están ubicados en centros de datos basados en AWS. Nuestros sistemas AWS no se rastrean a nivel de hardware por la propia naturaleza del servicio.

Todos los microservicios se rastrean en una base de datos de Service personalizada, que se actualiza a medida que se implementa cualquier Service. El equipo de Tecnología del lugar de trabajo (WPT, por sus siglas en inglés) de Atlassian mantiene un inventario de activos de todos los terminales utilizando nuestro propio software de Jira para realizar su seguimiento.

Todos los microservicios se clasifican en niveles, que tienen expectativas de tiempo de actividad, disponibilidad, RTO y RPO asociadas a cada nivel. Para ver ejemplos, consulta: https://www.atlassian.com/trust/security/data-management

6.08. (a) (ix)

¿Los cables de red pasan por las áreas de acceso público?

• ¿Se utilizan cables o conductos blindados?

Nuestras oficinas de Atlassian se rigen por la política interna de seguridad física y ambiental, que incluye la supervisión de los puntos físicos de entrada y salida. Hemos publicado extractos de todas nuestras políticas internas de seguridad y operaciones tecnológicas en: https://www.atlassian.com/trust/security/ismp-policies

Las oficinas de Atlassian tienen controles de acceso que incluyen lectores de tarjetas y cámaras de vigilancia, y pueden restringir el acceso a horas y días específicos según sea necesario. La administración de edificios mantiene los registros de acceso a los edificios de oficinas y Workplace Experience los puede consultar con fines de investigación.

6.08. (a) (x)

¿Se inspeccionan con frecuencia las instalaciones en busca de equipos no autorizados?

Un extracto de nuestra política de gestión de activos está disponible en https://www.atlassian.com/trust/security/ismp-policies. Atlassian mantiene un inventario de todos los activos de producción junto con sus propietarios. Todos nuestros sistemas están ubicados en centros de datos basados en AWS. Nuestros sistemas AWS no se rastrean a nivel de hardware por la propia naturaleza del servicio.

Todos los microservicios se rastrean en una base de datos de Service personalizada, que se actualiza a medida que se implementa cualquier Service. El equipo de Tecnología del lugar de trabajo (WPT, por sus siglas en inglés) de Atlassian mantiene un inventario de activos de todos los terminales utilizando nuestro propio Jira Software para realizar su seguimiento.

6.08. (a) (xi)

¿Hay algún equipo externo?

• ¿Cómo está protegido?

Un extracto de nuestra política de gestión de activos está disponible en https://www.atlassian.com/trust/security/ismp-policies. Atlassian mantiene un inventario de todos los activos de producción junto con sus propietarios. Todos nuestros sistemas están ubicados en centros de datos basados en AWS. Nuestros sistemas AWS no se rastrean a nivel de hardware por la propia naturaleza del servicio.

Todos los microservicios se rastrean en una base de datos de Service personalizada, que se actualiza a medida que se implementa cualquier Service. El equipo de Tecnología del lugar de trabajo (WPT, por sus siglas en inglés) de Atlassian mantiene un inventario de activos de todos los terminales utilizando nuestro propio Jira Software para realizar su seguimiento.

6.08. (a) (xii)

¿Tu personal utiliza equipos portátiles (p. ej., ordenadores portátiles, teléfonos inteligentes) que puedan dar acceso al centro de datos?

• ¿Cómo están protegidos?

Los centros de datos de nuestros socios mantienen varias certificaciones de cumplimiento. Estas certificaciones abordan la seguridad física, 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. La información sobre la garantía de protección física de AWS puede consultarse en: http://aws.amazon.com/compliance/

Los miembros formados y autorizados de los equipos de ingeniería de Atlassian, que se han sometido a una verificación de antecedentes, se autentican en la VPN con contraseñas seguras únicas y autenticaciones en dos fases basadas en TOTP, y solo acceden al entorno de producción a través de conexiones de terminales SSH mediante certificados RSA personales protegidos con contraseña. Hay un sistema IDS en todos los servidores de producción, que incluye la supervisión y las alertas en tiempo real de cualquier cambio en los archivos o la configuración del sistema de producción y de eventos de seguridad anómalos. Para aquellos miembros formados y autorizados del equipo de operaciones con acceso al sistema de producción, cualquier estación de trabajo con Windows u OS X que se utilice como terminal SSH para acceder al entorno de producción debe tener un software antivirus actual y activo. Los datos de los clientes no se replican en las estaciones de trabajo ni en los dispositivos móviles de los empleados.

6.08. (a) (xiii)

¿Qué medidas existen para controlar las tarjetas de acceso?

Nuestras oficinas de Atlassian se rigen por la política interna de seguridad física y ambiental, que incluye la supervisión de los puntos físicos de entrada y salida. Hemos publicado extractos de todas nuestras políticas internas de seguridad y operaciones tecnológicas en: https://www.atlassian.com/trust/security/ismp-policies

Las oficinas de Atlassian tienen controles de acceso que incluyen lectores de tarjetas y cámaras de vigilancia, y pueden restringir el acceso a horas y días específicos según sea necesario. La administración de edificios mantiene los registros de acceso a los edificios de oficinas y Workplace Experience los puede consultar con fines de investigación.

6.08. (a) (xiv)

¿Qué procesos o procedimientos existen para destruir los soportes o sistemas antiguos cuando es necesario hacerlo?

• ¿Datos sobrescritos?
• ¿Destrucción física?

El departamento de Tecnología del lugar de trabajo se encarga de este proceso: el equipo se desinfecta y desmagnetiza adecuadamente. Atlassian no gestiona ningún soporte físico que sea compatible con nuestros productos y servicios en la nube.

6.08. (a) (xv)

¿Qué procesos de autorización existen para el traslado de equipos de un sitio a otro?

• ¿Cómo se identifica al personal (o a los contratistas) que están autorizados a hacerlo?

Los socios de alojamiento de centros de datos de Atlassian (AWS) gestionan la seguridad física, mientras que nosotros confiamos en su SOC2 para validar que los controles son eficaces.

Los productos de Atlassian Cloud no transfieren los datos de los clientes físicamente. Los discos duros con datos de los clientes se destruyen o desinfectan antes de salir de nuestros centros de datos de AWS seguros. En el caso de los sistemas alojados en AWS, los datos pueden moverse de una región a otra en caso de redundancia, pero permanecerán dentro de AWS. Para obtener más información sobre nuestras regiones de AWS, consulta: https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvi)

¿Con qué frecuencia se realizan auditorías de los equipos para supervisar que se retiran los no autorizados?

Los socios de alojamiento de centros de datos de Atlassian (AWS) gestionan la seguridad física, mientras que nosotros confiamos en su SOC2 para validar que los controles son eficaces.

Los productos de Atlassian Cloud no transfieren los datos de los clientes físicamente. Los discos duros con datos de los clientes se destruyen o desinfectan antes de salir de nuestros centros de datos de AWS seguros. En el caso de los sistemas alojados en AWS, los datos pueden moverse de una región a otra en caso de redundancia, pero permanecerán dentro de AWS. Para obtener más información sobre nuestras regiones de AWS, consulta: https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvii)

¿Con qué frecuencia se realizan controles para garantizar que el entorno cumple con los requisitos legales y normativos correspondientes?

El equipo jurídico y los equipos de conformidad de Atlassian supervisan nuestras exigencias normativas. Consulta https://www.atlassian.com/legal/ para ver nuestro programa legal. Puedes obtener más información sobre nuestro programa de cumplimiento en: https://www.atlassian.com/trust/compliance.

6.09. (a)

¿Qué procedimientos o políticas existen para garantizar que los problemas medioambientales no provoquen una interrupción del servicio?

Nuestras oficinas de Atlassian se rigen por la política interna de seguridad física y ambiental, que incluye la supervisión de los puntos físicos de entrada y salida.

Los centros de datos de nuestros socios mantienen varias certificaciones de cumplimiento. Estas certificaciones abordan la seguridad física, 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. La información sobre la garantía de protección física de AWS puede consultarse en: http://aws.amazon.com/compliance/

Existe tanto una política como un plan de continuidad empresarial y recuperación ante desastres que revisa anualmente el comité directivo dedicado a ambos temas. Todos los propietarios de sistemas, procesos o servicios críticos garantizan una continuidad empresarial o una recuperación ante desastres adecuadas que se ajusta a la tolerancia a las interrupciones en caso de desastre. Los planes BCDR se prueban trimestralmente y se abordan todas las incidencias identificadas. Para obtener más información, consulta: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management y https://www.atlassian.com/trust/security/data-management.

6.09. (b)

¿Qué métodos se emplean para evitar los daños causados por un incendio, una inundación, un terremoto, etc.?

• En caso de desastre, ¿qué medidas de seguridad adicionales se adoptan para proteger el acceso físico?
• ¿Tanto en la sede principal como en la secundaria?

En Atlassian, confiamos en nuestros socios de alojamiento de datos para validar los controles ambientales y de seguridad de sus centros de datos. Para AWS, consulta https://aws.amazon.com/compliance/programs.

6.09. (c)

¿Se supervisan la temperatura y la humedad en el centro de datos?

• ¿Consideraciones o supervisión del aire acondicionado?

En Atlassian, confiamos en nuestros socios de alojamiento de datos para validar los controles ambientales y de seguridad de sus centros de datos. Para AWS, consulta https://aws.amazon.com/compliance/programs.

6.09. (d)

¿Se protegen los edificios de la caída de rayos?

• ¿Incluidas las líneas eléctricas y de comunicación?

En Atlassian, confiamos en nuestros socios de alojamiento de datos para validar los controles ambientales y de seguridad de sus centros de datos. Para AWS, consulta https://aws.amazon.com/compliance/programs.

6.09. (e)

¿Tienes generadores independientes en caso de que se produzca un corte de energía?

• ¿Durante cuánto tiempo pueden funcionar?
• ¿Hay suministros de combustible adecuados?
• ¿Hay generadores de conmutación por error?
• ¿Con qué frecuencia se revisa el equipo de SAI?
• ¿Con qué frecuencia se revisan tus generadores?
• ¿Tienes varios proveedores de energía?

En Atlassian, confiamos en nuestros socios de alojamiento de datos para validar los controles ambientales y de seguridad de sus centros de datos. Para AWS, consulta https://aws.amazon.com/compliance/programs.

6.09. (f)

¿Todos los servicios públicos (electricidad, agua, etc.) son capaces de suministrar tu entorno?

• ¿Con qué frecuencia se reevalúan y se ponen a prueba?

En Atlassian, confiamos en nuestros socios de alojamiento de datos para validar los controles ambientales y de seguridad de sus centros de datos. Para AWS, consulta https://aws.amazon.com/compliance/programs.

6.09. (g)

¿Tu aire acondicionado es capaz de abastecer tu entorno?

• ¿Con qué frecuencia se prueba?

En Atlassian, confiamos en nuestros socios de alojamiento de datos para validar los controles ambientales y de seguridad de sus centros de datos. Para AWS, consulta https://aws.amazon.com/compliance/programs.

6.09. (h)

¿Se siguen los períodos de mantenimiento recomendados por los fabricantes?

En Atlassian, confiamos en nuestros socios de alojamiento de datos para validar los controles ambientales y de seguridad de sus centros de datos. Para AWS, consulta https://aws.amazon.com/compliance/programs.

6.09. (i)

¿Solo permites que el personal autorizado de mantenimiento o reparación entre al sitio?

• ¿Cómo se comprueba su identidad?

El acceso físico a las oficinas está protegido por tarjetas electrónicas, recepción en horario laboral con registro obligatorio para los visitantes y cámaras de seguridad en todos los puntos de entrada y salida del edificio. Los muelles de carga están vigilados por cámaras de seguridad y por el personal del edificio en todo momento. Nuestros socios de alojamiento de centros de datos gestionan la seguridad física y confiamos en sus certificaciones de cumplimiento para validar que los controles son eficaces.

6.09. (j)

Cuando se envía el equipo para su reparación, ¿se limpian primero sus datos?

• ¿Cómo se hace?

El departamento de Tecnología del lugar de trabajo se encarga de este proceso: el equipo se desinfecta y desmagnetiza adecuadamente. Atlassian no gestiona ningún soporte físico que sea compatible con nuestros productos y servicios en la nube.

6.10.

Los clientes y posibles clientes de los proveedores de servicios en la nube deben tener en cuenta sus respectivas obligaciones nacionales y supranacionales de cumplimiento de los marcos reglamentarios y asegurarse de que dichas obligaciones se cumplen adecuadamente.

Las principales preguntas legales que el cliente debe hacerle al proveedor de servicios en la nube son:

6.10. (a)

¿En qué país se encuentra el proveedor de servicios en la nube?

Atlassian tiene 12 oficinas en 8 países, incluidos Sídney, Ámsterdam, Ankara, Boston, Bangalore, San Francisco, Mountain View, Austin, Texas, Nueva York, Manila, Gdansk y Japón. Para obtener más información, consulta: https://www.atlassian.com/company/contact.

6.10. (b)

¿La infraestructura del proveedor de servicios en la nube está ubicada en el mismo país o en países diferentes?

En el caso de Atlassian Cloud, actualmente estamos alojados en zonas de disponibilidad de AWS redundantes. Para obtener información sobre regiones específicas, consulta: https://www.atlassian.com/trust/reliability/infrastructure.

6.10. (c)

¿Empleará el proveedor de servicios en la nube otras empresas cuya infraestructura esté ubicada fuera de la del proveedor de servicios en la nube?

Los datos y productos de Atlassian Cloud se alojan en el proveedor de servicios en la nube líder del sector, Amazon Web Services (AWS). Nuestros productos se ejecutan en un entorno de plataforma como servicio (PaaS) que se divide en dos conjuntos principales de infraestructura que conocemos con los nombres de "micros" y "no micros". Jira, Confluence, Statuspage, Access y Bitbucket se ejecutan en la plataforma micros, mientras que Opsgenie y Trello lo hacen en la plataforma no micros.

6.10. (d)

¿Dónde se ubicarán físicamente los datos?

Atlassian utiliza Amazon Web Services (AWS) en las regiones de Este de EE. UU., Oeste de EE. UU., Irlanda, Fráncfort, Singapur y Sídney (Confluence y Jira).

Detalles específicos del producto:

• Trello: disponible en AWS en Este de EE. UU. (Ohio).
• Jira Align: la ubicación física de los datos del cliente se puede solicitar mediante una solicitud de ticket de asistencia. Consulta: https://support.atlassian.com/jira-align/.
• Statuspage: disponible en AWS en las regiones de Oeste de EE. UU. (Oregón, California) y Este de EE. UU. (Ohio).
• Opsgenie: tiene cuentas de AWS en EE. UU. y Europa. El cliente deberá optar por AWS EE. UU. (Oregón, California) o la UE (Fráncfort) al registrarse.
• Halp: alojado en AWS en las regiones Este de EE. UU 2 y Oeste de EE. UU. 2.
• Bitbucket: los repositorios y las funciones principales de la aplicación están alojados en AWS en Este de EE. UU. y Oeste de EE. UU.


Para obtener más información sobre la residencia de datos, consulta: https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/.

6.10. (e)

¿Se dividirá la jurisdicción sobre las condiciones del contrato y los datos?

La legislación aplicable predeterminada para el contrato de cliente de Atlassian es la ley de California. Contacta con nuestro equipo de ventas Enterprise si quieres más información.

6.10. (f)

¿Se subcontratará alguno de los servicios del proveedor en la nube?

Atlassian trabaja con subcontratistas externos para proporcionar sitios web, desarrollo de aplicaciones, alojamiento, mantenimiento, copias de seguridad, almacenamiento, infraestructura virtual, procesamiento de pagos, análisis y otros servicios. Con el fin de proporcionar dichos servicios, estos proveedores pueden tener acceso a la información de identificación personal (PII) o procesarla para nosotros.

Atlassian pone en conocimiento de sus clientes todo uso o procesamiento que haga cualquier subcontratista de su información de identificación personal, mediante notificación y antes de que se produzca dicho procesamiento. En la página Encargados del tratamiento de los datos personales subcontratados de Atlassian: https://www.atlassian.com/legal/sub-processors, se proporciona una lista externa de los subcontratistas con los que trabaja Atlassian. Puedes suscribirte a una fuente RSS para recibir una notificación cada vez que se añada un encargado del tratamiento de los datos personales subcontratados de Atlassian nuevo.

6.10. (g)

¿Se externalizará alguno de los servicios del proveedor en la nube?

Siempre que Atlassian contrata a proveedores externos, nos aseguramos de que esas colaboraciones no pongan en peligro de ninguna manera a nuestros clientes o sus datos. Los departamentos jurídicos y de adquisiciones de Atlassian revisan los contratos, los SLA y las políticas internas de los proveedores para determinar si el proveedor cumple los requisitos de seguridad, disponibilidad y confidencialidad. Para obtener más información, consulta: https://www.atlassian.com/trust/security/security-practices#supplier-risk-management.

6.10. (h)

¿Cómo se recopilarán, procesarán y transferirán los datos proporcionados por el cliente y los clientes del cliente?

Atlassian procesa la información de una manera compatible con los fines para los que se ha recopilado o con la autorización posterior del usuario y, en particular, de acuerdo con la política de privacidad externa de Atlassian.

Nos importa la privacidad del usuario y queremos ser transparentes acerca de la manera en que recopilamos, usamos y compartimos información sobre los usuarios. Para obtener más información, consulta nuestra página "Privacidad en Atlassian", que forma parte de Atlassian Trust Center: https://www.atlassian.com/trust/privacy y nuestra política de privacidad: https://www.atlassian.com/legal/privacy-policy.

6.10. (i)

¿Qué ocurre con los datos enviados al proveedor de servicios en la nube tras la rescisión del contrato?

Atlassian mantiene un estándar de retención y destrucción de datos que determina cuánto tiempo necesitamos conservar los distintos tipos de datos. Los datos se clasifican de acuerdo con nuestra política de seguridad de datos y ciclo de vida de la información de Atlassian y los controles se implementan en función de ella. En cuanto a los datos de los clientes, al rescindir un contrato de Atlassian, los datos que pertenezcan al equipo del cliente se eliminarán de la base de datos de producción en vivo y todos los archivos adjuntos subidos directamente a Atlassian se eliminarán en un plazo de 14 días. Los datos del equipo permanecerán en copias de seguridad cifradas hasta que esas copias de seguridad superen el período de retención de 90 días y se destruyan de acuerdo con la política de retención de datos de Atlassian. En caso de que sea necesario restaurar la base de datos en un plazo de 90 días a partir de la solicitud de eliminación de los datos, el equipo de operaciones volverá a borrar los datos tan pronto como sea posible una vez que el sistema de producción en vivo esté completamente restaurado. Para obtener más información, consulta: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/