Архитектура 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 расположены в регионе «Восток США», а для аварийного восстановления используется регион «Запад США».

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

Компания Atlassian реализует комплексную программу резервного копирования. Она охватывает внутренние системы компании, средства резервного копирования которых соответствуют требованиям к восстановлению работоспособности систем. Кроме того, в отношении облачных продуктов (особенно данных клиентов и приложений) применяются расширенные средства резервного копирования. Для ежедневного автоматического резервного копирования каждого экземпляра RDS используется возможность создания снимков Amazon RDS (сервиса реляционных баз данных).

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

Данные Bitbucket копируются в другой регион AWS. Кроме того, для каждого региона ежедневно создаются независимые резервные копии.

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

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

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

Для хранения репозиториев Bitbucket используется сервис NetApp CVS. Это файловая система, управляемая компанией NetApp и размещенная в ее центре обработки данных. NetApp соблюдает требования международных законов о защите данных, принимая разумные меры безопасности при хранении, передаче и обработке данных. Кроме того, чтобы обеспечить соответствие требованиям, NetApp проводит как самостоятельную оценку, так и сторонние аудиты. Подробнее см. на страницах, посвященных принципам безопасности и сертификатам соответствия NetApp.

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

В этой архитектуре AWS размещен ряд наших служб, которые обеспечивают работу платформы и продуктов, составляющих наши решения. Сюда относятся возможности платформы, которые применяются во множестве продуктов Atlassian, такие как Media, Identity и Commerce, пользовательские интерфейсы, такие как Editor, а также возможности для конкретных продуктов, такие как служба Jira Issue и Confluence Analytics.

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

На базе облачной инфраструктуры мы создали архитектуру микросервисов с поддержкой нескольких держателей, а также общую платформу, поддерживающую наши продукты. В архитектуре с несколькими держателями одна служба обслуживает множество клиентов, в том числе базы данных и экземпляры вычислительных ресурсов, необходимые для запуска наших облачных продуктов. Каждый сегмент (по сути, контейнер — см. рис. 3 ниже) содержит данные нескольких держателей, но данные каждого держателя изолированы и недоступны другим держателям. Обратите внимание, что мы не предлагаем архитектуру с одним держателем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Границы Atlassian

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

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

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

Для доступа к данным на платформе используется модель минимальных привилегий. Это означает, что все данные доступны только той службе, которая отвечает за их сохранение, обработку или извлечение. Например, для мультимедийных служб, обеспечивающих согласованную отправку и загрузку файлов между облачными продуктами, выделено хранилище, которое недоступно для всех остальных служб Atlassian. Любая служба, которой требуется доступ к медиаконтенту, должна взаимодействовать с API медиаслужб. В результате строгая аутентификация и авторизация на уровне служб также гарантируют строгое разделение обязанностей и доступ к данным с минимальными привилегиями.

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

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

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

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

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

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

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

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

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

Данные клиентов, хранящиеся в облачных продуктах Atlassian, шифруются при передаче по общедоступным сетям с помощью протокола TLS 1.2+ с полной безопасностью пересылки (PFS) для защиты от несанкционированного раскрытия или изменения. Наша реализация TLS обеспечивает использование криптостойких шифров и ключей нужной длины, если это поддерживается браузером.

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

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

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

Управление ключами

Для управления ключами компания Atlassian использует AWS Key Management Service (KMS). Чтобы обеспечить дополнительную конфиденциальность данных, KMS является генератором и секретным хранилищем этих ключей. Процесс шифрования, дешифрования и управления ключами регулярно проверяется и контролируется AWS в рамках внутренних процессов утверждения. Для каждого ключа назначается владелец, который отвечает за его надлежащую защиту. При изменении ролей или статусов сотрудников ключи Atlassian ротируются.

Кроме того, мы применяем шифрование конвертов. Главный ключ, который мы никогда не видим, находится на стороне AWS, и для любых запросов на шифрование или расшифровку ключей требуются соответствующие роли и разрешения AWS. Если же для создания или генерации ключей для отдельных клиентов используется шифрование конвертов, в хранилищах данных используются разные ключи для разных типов данных. В дополнение мы применяем шифрование на внутреннем прикладном уровне, которое предоставляет резервные ключи данных в других регионах AWS. Ключи ежегодно автоматически ротируются; при этом один и тот же ключ не используется чаще, чем на 100 000 элементов данных.

В скором времени мы предложим шифрование с использованием собственного ключа (BYOK), чтобы вы могли шифровать данные облачных продуктов в AWS KMS с помощью ключей с самостоятельным управлением. С BYOK вы получите полный контроль над своими ключами и сможете в любое время назначать права доступа для конечных пользователей и систем Atlassian или отзывать их.

Чтобы получить журналы об использовании всех ключей, AWS KMS можно интегрировать с AWS CloudTrail в аккаунте AWS. С помощью этого решения шифруются данные клиентов на различных уровнях приложений, например в базах данных, хранилище файлов, а также во внутренних кэшах и очередях событий Atlassian. Ни один этап данного процесса не влияет на удобство использования продукта.