Архитектура Atlassian Cloud и методы работы

Архитектура хостинга Atlassian Cloud

Поставщик облачных услуг Atlassian — компания Amazon Web Services (AWS). Atlassian использует высокодоступные центры обработки данных AWS в нескольких регионах мира. Каждый регион AWS представляет собой отдельное географическое местоположение с несколькими изолированными и физически разделенными группами центров обработки данных — так называемыми зонами доступности (AZ).

Для разработки своих продуктов и компонентов платформы мы используем вычислительные сервисы, сервисы хранения данных, сетевые сервисы и сервисы аналитики AWS. Благодаря этому мы можем задействовать возможности обеспечения избыточности, предлагаемые AWS, такие как зоны доступности и регионы.

Зоны доступности

Каждая зона доступности проектируется так, чтобы не зависеть от сбоев в других зонах и поддерживать экономичное сетевое соединение с низкой задержкой с другими зонами доступности своего региона. Такая высокая доступность, достигаемая за счет многозональности, служит первой линией защиты от рисков, связанных с географией и средой. Службы, работающие в многозональных развертываниях, сохраняют работоспособность при отказе отдельных зон доступности.

В Jira и Confluence используется режим развертывания в нескольких зонах доступности для Amazon RDS (Amazon Relational Database Service). При многозональном развертывании Amazon RDS выполняет и поддерживает синхронную репликацию в различных зонах доступности одного региона для резервирования данных и обеспечения возможности переключения при отказе. Переключение зоны доступности при отказе выполняется автоматически и обычно занимает 60–120 секунд, поэтому операции с базой данных могут возобновиться в кратчайшие сроки и без вмешательства администратора. В Opsgenie, Statuspage, Trello и Jira Align используются аналогичные стратегии развертывания с небольшими отличиями во времени репликации и переключения при отказе.

Расположение данных

Данные Jira и Confluence размещаются в регионе, самом близком к большинству ваших зарегистрированных пользователей. Данные Bitbucket хранятся в двух разных зонах доступности в регионе Восток США.

Однако мы понимаем, что некоторым клиентам может потребоваться хранить данные в определенном месте, поэтому мы предлагаем выбор места хранения данных. В настоящее время выбор доступен для Jira, Jira Service Management, Jira Product Discovery и Confluence в 11 регионах, включая Австралию, Великобританию, Германию, ЕС, Индию, Канаду, Сингапур, США, Швейцарию, Южную Корею и Японию. Ознакомьтесь с нашей документацией, чтобы узнать больше о месте хранения данных и о данных продуктов, на которые распространяется эта опция. Кроме того, следите за нашей дорожной картой, где публикуются новости о местах хранения данных, добавлении поддержки новых продуктов, регионов и типов данных.

Резервное копирование данных

We operate a comprehensive backup program at Atlassian. This includes our internal systems, where our backup measures are designed in line with system recovery requirements. With respect to our cloud apps, and specifically referring to you and your application data, we also have extensive backup measures in place. We use the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance.

Снимки состояния Amazon RDS хранятся в течение 30 дней. Они позволяют восстановить экземпляр до состояния на определенный момент времени и зашифрованы по стандарту AES-256. Резервные копии данных не хранятся удаленно, а реплицируются в несколько ЦОД в определенном регионе AWS. Кроме того, мы проводим ежеквартальное тестирование своих резервных копий.

Для Bitbucket снимки хранилища хранятся в течение 7 дней с поддержкой восстановления на определенный момент времени.

We don’t use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted work items, projects, or sites. To avoid data loss, we recommend making regular backups. Learn more about creating backups in the support documentation for your product.

Безопасность ЦОД

Компания AWS поддерживает ряд сертификаций по защите своих центров обработки данных. Они касаются физической защиты и безопасности среды, доступности системы, доступа к сети и IP-магистрали, создания пользователей и управления проблемами. Доступ к центрам обработки данных осуществляется только уполномоченным персоналом после биометрической аутентификации. Меры физической защиты включают охрану на местах, видеонаблюдение, шлюзовые кабины и дополнительные меры защиты от вторжений.

Архитектура распределенных служб

With this AWS architecture, we host a number of platform and product services that are used across our solutions. This includes platform capabilities that are shared and consumed across multiple Atlassian products, such as Media, Identity, and Commerce, experiences such as our Editor, and product-specific capabilities, like Jira Work Item service and Confluence Analytics.

Многоклиентская архитектура

On top of our cloud infrastructure, we built and operate a multi-tenant micro-service architecture along with a shared platform that supports our products. In a multi-tenant architecture, a single service serves multiple customers, including databases and compute instances required to run our cloud apps. Each shard (essentially a container – see figure 3 below) contains the data for multiple tenants, but each tenant's data is isolated and inaccessible to other tenants. It is important to note that we do not offer a single tenant architecture.

Создание и жизненный цикл держателей

При создании нового клиента ряд событий запускает оркестрацию распределенных служб и выделение ресурсов хранилищ данных. Эти события обычно можно сопоставить с одним из семи этапов жизненного цикла.

1. В коммерческие системы мгновенно поступают актуальные метаданные и информация о правах доступа, относящаяся к этому клиенту, после чего система оркестрации выделения согласовывает «состояние выделенных ресурсов» с состоянием лицензии посредством серии событий держателя и продукта.

События держателя

Эти события влияют на держателя в целом и могут быть следующими.

• Создание: держатель создается и используется для новых сайтов.
• Уничтожение: держатель полностью удаляется.

События продукта

• Активация: после активации лицензированных продуктов или сторонних приложений.
• Деактивация: после деактивации определенных продуктов или приложений.
• Приостановка: после приостановки работы определенного существующего продукта, в результате чего становится недоступен определенный сайт, владельцем которого является держатель.
• Отмена приостановки: после отмены приостановки работы определенного существующего продукта, в результате чего становится доступен сайт, владельцем которого является держатель.
• Обновление лицензии: содержит информацию о количестве рабочих мест лицензии для определенного продукта, а также о ее статусе (активна/неактивна).

2. Создается сайт клиента и активируется соответствующий набор продуктов для клиента. Модель сайта представляет контейнер, содержащий несколько продуктов, предоставленных по лицензии конкретному клиенту (например, Confluence и Jira Software для <имя сайта＞.atlassian.net).

Разделение держателей

While our customers share a common cloud-based infrastructure when using our cloud apps, we have measures in place to ensure they are logically separated so that the actions of one customer cannot compromise the data or service of other customers.

В компании Atlassian для каждого приложения используется свой подход. Для логической изоляции клиентов Jira и Confluence Cloud применяется концепция под названием «контекст держателей». Она реализована в коде приложения и управляется посредством нашей службы контекста держателей (Tenant Context Service, TCS). Согласно этой концепции:

• данные каждого клиента при хранении логически обособлены от данных других держателей;
• все запросы к данным обрабатываются Jira или Confluence в контексте определенного держателя, исключая воздействие на других держателей.

В целом работа TCS сводится к хранению контекста для каждого отдельного держателя. Контекст привязан к уникальному идентификатору, который централизованно хранится в TCS и включает набор метаданных, связанных с держателем (например, базы данных с записями держателя, лицензии держателя, доступные ему возможности и прочую информацию, относящуюся к конфигурации). Когда клиент обращается к Jira или Confluence Cloud, служба TCS с помощью этого идентификатора отбирает соответствующие метаданные и связывает их со всеми действиями держателя во время сеанса использования приложения.

Границы Atlassian

Ваши данные также защищают пограничные серверы — виртуальные стены вокруг программного обеспечения. Запрос отправляется на ближайший пограничный сервер, где после серии проверок разрешается или отклоняется.

• Запрос поступает на ближайший пограничный сервер Atlassian, где с помощью вашей системы идентификации проверяется сеанс и личность пользователя.
• Этот сервер определяет местонахождение данных продукта на основе информации из TCS.
• Запрос перенаправляется на вычислительный узел в целевом регионе.
• Через систему с конфигурациями держателей узел определяет лицензию и местоположение баз данных и обращается к другим хранилищам и службам (например, к платформе Media, где хранятся изображения и вложения), чтобы получить необходимую информацию для обработки запроса.
• Исходный запрос пользователя дополняется информацией, собранной из предыдущих обращений к другим службам.

Аутентификация и авторизация служб

Our platform uses a least privilege model for accessing data. This means that all data is restricted to only the service responsible for saving, processing, or retrieving it. For example, the media services, which allows you to have a consistent file upload and download experience across our cloud apps, have dedicated storage provisioned that no other services at Atlassian can access. Any service that requires access to the media content needs to interact with the media services API. As a result, strong authentication and authorization at the service layer also enforces strong separation of duties and least privilege access to data.

Мы используем веб-токены JSON (JWT) для обеспечения права подписи вне приложения, поэтому наши системы идентификации и контекст держателей являются достоверным источником информации. Токены можно использовать для доступа только к тем данным, для которых был выдан токен. Если вы или участник вашей команды обращаетесь к микросервису или сегменту данных, токены передаются в вашу систему идентификации и проходят проверку. Этот процесс обеспечивает актуальность токена и наличие подписи до предоставления соответствующих данных. В сочетании с авторизацией и аутентификацией, необходимыми для доступа к этим микросервисам, это позволяет ограничить область данных, если служба скомпрометирована.

Мы знаем, что порой системы идентификации взламывают. Для снижения этого риска компания Atlassian использует два механизма. Первый — это высокий уровень репликации TCS и прокси-серверов удостоверений. Мы используем TCS-расширение почти для каждой микрослужбы и ответвляющиеся от органа идентификации расширения для прокси-серверов, чтобы обеспечить постоянную работу тысяч таких служб. При возникновении аномального поведения в одном или нескольких местах мы сможем быстро это заметить и устранить проблему.

Кроме того, мы не ждем, когда кто-то обнаружит уязвимость в наших продуктах или платформе. Наша компания активно выявляет такие сценарии для сокращения негативных последствий до минимума и ведет ряд программ обеспечения безопасности для выявления и обнаружения угроз безопасности, а также реагирования на них.

Служба контекста держателей

Мы следим за тем, чтобы запросы к любым микросервисам содержали метаданные о клиенте (или держателе), запрашивающем доступ. Это называется «службой контекста держателей». Она заполняется непосредственно из наших систем выделения ресурсов. При запуске запроса происходит считывание и поглощение контекста в исполняемый служебный код, который используется для авторизации пользователя. Для получения доступа к любой службе и, соответственно, к данным в Jira и Confluence требуется этот контекст держателя, в противном случае запрос будет отклонен.

Аутентификация и авторизация служб выполняются через протокол аутентификации служб Atlassian (ASAP). В списке явно разрешенных перечисляются службы, имеющие право на взаимодействие, а в сведениях об авторизации определяются доступные команды и пути. Это ограничивает возможное боковое смещение скомпрометированной службы.

Аутентификация и авторизация служб, а также исходящий трафик контролируются через набор выделенных прокси, что исключает возможность воздействия на эти элементы управления со стороны уязвимостей в коде приложений. Для удаленного выполнения кода придется не только изменить логику приложения, но и скомпрометировать базовый хост и обойти границы контейнера Docker. Однако в таком случае наша система обнаружения вторжений на уровне хоста отметит расхождения.

Эти прокси ограничивают поведение исходящего трафика в зависимости от предполагаемого поведения службы. Службам, которым не нужно выдавать веб-хуки или взаимодействовать с другими микросервисами, запрещено выполнять эти действия.

Шифрование данных

Customer data in Atlassian cloud apps is encrypted during transmission utilizing TLS 1.2 or higher, incorporating perfect forward secrecy (PFS) to safeguard against unauthorized information disclosure and data modification. We adhere to NIST-recommended TLS 1.2+ protocols, which enforce the use of strong ciphers and key lengths as supported by the browser.

Данные клиентов, включая вложения, хранящиеся в облачных сервисах, таких как Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie и Trello, при хранении защищены шифрованием на основе отраслевого стандарта AES-256.

Передача персональных данных (Personally Identifiable Information, PII) защищена шифрованием и надежными средствами контроля доступа, которые обеспечивают безопасную передачу данных в место назначения. В Политике криптографии и шифрования Atlassian изложены принципы внедрения шифрования и криптографии для снижения рисков, связанных с хранением и передачей персональных данных. Согласно внутренним политикам Atlassian по безопасности данных и управлению жизненным циклом информации, алгоритмы шифрования для защиты персональных данных должны соответствовать уровню классификации персональных данных. Это обеспечивает надлежащую защиту конфиденциальных данных с учетом их классификации. Подробнее о сборе, использовании и раскрытии информации клиентов см. на странице политики конфиденциальности Atlassian.

Следите за появлением дополнительных возможностей по шифрованию данных на нашей дорожной карте развития продуктов Cloud.