Atlassian Cloud
Архитектура Atlassian Cloud и методы работы
Узнайте больше об архитектуре Atlassian Cloud и используемых нами методах работы
Введение
Продукты и данные Atlassian Cloud размещаются у ведущего поставщика облачных услуг — Amazon Web Services (AWS). Наши продукты предоставляются по модели «платформа как сервис» (PaaS). Рабочая среда разделена на две области инфраструктуры, которые называются Micros и non-Micros. Jira, Confluence, Statuspage, Atlassian Access и Bitbucket работают на платформе Micros, а Opsgenie и Trello — на платформе non-Micros.
Облачная инфраструктура
Архитектура хостинга 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 снимки хранилища хранятся в течение 7 дней с поддержкой восстановления на определенный момент времени.
Мы не используем эти резервные копии для восстановления данных, уничтоженных клиентами, в том числе в результате перезаписи полей с помощью скриптов, удаления задач, проектов или сайтов. Во избежание потери данных рекомендуется выполнять регулярное резервное копирование. Подробнее о создании резервных копий см. в документации по поддержке конкретного продукта.
Безопасность ЦОД
AWS имеет ряд сертификаций по защите своих ЦОД. Они касаются физической защиты и безопасности среды, доступности системы, доступа к сети и IP-магистрали, создания пользователей и управления проблемами. Доступ к ЦОД осуществляется только уполномоченным персоналом после биометрической аутентификации. Меры физической защиты включают охрану на местах, видеонаблюдение, шлюзовые кабины и дополнительные меры защиты от вторжений.
Архитектура облачной платформы
Архитектура распределенных служб
В этой архитектуре AWS размещен ряд наших служб, которые обеспечивают работу платформы и продуктов, составляющих наши решения. Сюда относятся возможности платформы, которые применяются во множестве продуктов Atlassian, такие как Media, Identity и Commerce, пользовательские интерфейсы, такие как Editor, а также возможности для конкретных продуктов, такие как служба Jira Issue и Confluence Analytics.
Рисунок 1
Разработчики Atlassian предоставляют эти службы с помощью разработанной компанией платформы как сервис (PaaS) под названием Micros, которая автоматически организует развертывание общих служб, инфраструктуры, хранилищ данных и возможностей управления ими, включая требования к безопасности и соответствию требованиям (см. рис. 1 выше). Как правило, продукт Atlassian состоит из нескольких «контейнерных» служб, которые развертываются на AWS с помощью Micros. Продукты Atlassian используют базовые возможности платформы (см. рис. 2 ниже), которые варьируются от маршрутизации запросов до хранилищ двоичных объектов, аутентификации/авторизации, хранилищ транзакционного пользовательского контента (UGC) и связей сущностей, озер данных, общего ведения журнала, трассировки запросов, наблюдаемости и аналитических служб. Эти микросервисы построены с использованием утвержденных технических стеков, стандартизированных на уровне платформы:
Рисунок 2
Многоклиентская архитектура
На базе облачной инфраструктуры мы создали архитектуру микросервисов с поддержкой нескольких держателей, а также общую платформу, поддерживающую наши продукты. В архитектуре с несколькими держателями одна служба обслуживает множество клиентов, в том числе базы данных и экземпляры вычислительных ресурсов, необходимые для запуска наших облачных продуктов. Каждый сегмент (по сути, контейнер — см. рис. 3 ниже) содержит данные нескольких держателей, но данные каждого держателя изолированы и недоступны другим держателям. Обратите внимание, что мы не предлагаем архитектуру с одним держателем.
Рисунок 3
Наши микросервисы работают по принципу минимальных привилегий, чтобы предельно сократить уязвимости «нулевого дня» и снизить вероятность бокового смещения в облачной среде. У каждого микросервиса есть собственное хранилище данных, доступ к которому возможен только по протоколу аутентификации этого конкретного сервиса, то есть никакой другой сервис не имеет доступа к данному API с правами чтения либо записи.
Мы сосредоточились на изоляции микросервисов и данных, вместо того чтобы предоставлять выделенную инфраструктуру каждому держателю, поскольку это ограничивает доступ множества клиентов узкой областью данных внутри одной системы. За счет независимой логики, а также аутентификации и авторизации данных на уровне приложения достигается дополнительный контроль безопасности при отправке запросов к службам. Таким образом, при компрометации микросервиса будет ограничен доступ только к необходимым для него данным.
Создание и жизненный цикл держателей
При создании нового клиента ряд событий запускает оркестрацию распределенных служб и выделение ресурсов хранилищ данных. Эти события обычно можно сопоставить с одним из семи этапов жизненного цикла.
1. В коммерческие системы мгновенно поступают актуальные метаданные и информация о правах доступа, относящаяся к этому клиенту, после чего система оркестрации выделения согласовывает «состояние выделенных ресурсов» с состоянием лицензии посредством серии событий держателя и продукта.
События держателя
Эти события влияют на держателя в целом и могут быть следующими.
- Создание: держатель создается и используется для новых сайтов.
- Уничтожение: держатель полностью удаляется.
События продукта
- Активация: после активации лицензированных продуктов или сторонних приложений.
- Деактивация: после деактивации определенных продуктов или приложений.
- Приостановка: после приостановки работы определенного существующего продукта, в результате чего становится недоступен определенный сайт, владельцем которого является держатель.
- Отмена приостановки: после отмены приостановки работы определенного существующего продукта, в результате чего становится доступен сайт, владельцем которого является держатель.
- Обновление лицензии: содержит информацию о количестве рабочих мест лицензии для определенного продукта, а также о ее статусе (активна/неактивна).
2. Создается сайт клиента и активируется соответствующий набор продуктов для клиента. Модель сайта представляет контейнер, содержащий несколько продуктов, предоставленных по лицензии конкретному клиенту (например, Confluence и Jira Software для <имя сайта>.atlassian.net).
Рисунок 4
3. Продукты предоставляются на сайт клиента в указанном регионе.
При предоставлении продукта большая часть его содержимого размещается в регионе поблизости от того места, где пользователи получают к нему доступ. Чтобы оптимизировать производительность продукта, мы не ограничиваем перемещение данных, если он размещен глобально, и можем перемещать данные между регионами по мере необходимости.
Для некоторых наших продуктов мы даем возможность выбрать вариант размещения данных. Клиенты могут решить, будут ли данные о продуктах распределены по всему миру или же они будут храниться в одном из определенных нами географических мест.
4. Создаются и сохраняются основные метаданные и конфигурация сайта и продуктов клиента.
5. Создаются и сохраняются идентификационные данные сайта и продуктов, такие как пользователи, группы, права и т. д.
6. Выделяются ресурсы баз данных продуктов на сайт, например семейства продуктов Jira, Confluence, Compass, Atlas.
7. Предоставляются лицензированные приложения продуктов.
Рисунок 5
На рис. 5 выше показано, как развертывается сайт клиента в нашей распределенной архитектуре, а не просто в рамках отдельной базы данных или хранилища. На нем изображено множество физических и логических местоположений, в которых хранятся метаданные, данные конфигурации, данные продуктов, данные платформы и другая связанная с сайтом информация.
Разделение держателей
Хотя клиенты используют продукты Cloud в общей облачной инфраструктуре, мы принимаем меры для того, чтобы их данные были логически разделены. Таким образом, действия одного клиента не могут поставить под угрозу данные или работоспособность службы другого клиента.
В компании Atlassian для каждого приложения используется свой подход. Для логической изоляции клиентов Jira и Confluence Cloud применяется концепция под названием «контекст держателей». Она реализована в коде приложения и управляется посредством нашей службы контекста держателей (Tenant Context Service, TCS). Согласно этой концепции:
- данные каждого клиента при хранении логически обособлены от данных других держателей;
- все запросы к данным обрабатываются Jira или Confluence в контексте определенного держателя, исключая воздействие на других держателей.
В целом работа TCS сводится к хранению контекста для каждого отдельного держателя. Контекст привязан к уникальному идентификатору, который централизованно хранится в TCS и включает набор метаданных, связанных с держателем (например, базы данных с записями держателя, лицензии держателя, доступные ему возможности и прочую информацию, относящуюся к конфигурации). Когда клиент обращается к Jira или Confluence Cloud, служба TCS с помощью этого идентификатора отбирает соответствующие метаданные и связывает их со всеми действиями держателя во время сеанса использования приложения.
Границы Atlassian
Ваши данные также защищают пограничные серверы — виртуальные стены вокруг программного обеспечения. Запрос отправляется на ближайший пограничный сервер, где после серии проверок разрешается или отклоняется.
- Запрос поступает на ближайший пограничный сервер Atlassian, где с помощью вашей системы идентификации проверяется сеанс и личность пользователя.
- Этот сервер определяет местонахождение данных продукта на основе информации из TCS.
- Запрос перенаправляется на вычислительный узел в целевом регионе.
- Через систему с конфигурациями держателей узел определяет лицензию и местоположение баз данных и обращается к другим хранилищам и службам (например, к платформе Media, где хранятся изображения и вложения), чтобы получить необходимую информацию для обработки запроса.
- Исходный запрос пользователя дополняется информацией, собранной из предыдущих обращений к другим службам.
Средства безопасности
В основе наших облачных продуктов лежит многоклиентская архитектура, поэтому мы можем дополнительно защитить независимую логику приложений. В монолитном приложении отдельного держателя обычно нет дополнительных проверок полномочий или ограничений скорости, например при большом объеме запросов или операций экспорта данных. Воздействие отдельной уязвимости «нулевого дня» резко снижается по мере сужения области данных.
Кроме того, в продукты, которые полностью размещены на платформе Atlassian, встроены дополнительные профилактические меры контроля. Основные из них перечислены ниже.
- Аутентификация и авторизация служб
- Служба контекста держателей
- Управление ключами
- Шифрование данных
Аутентификация и авторизация служб
Для доступа к данным на платформе используется модель минимальных привилегий. Это означает, что все данные доступны только той службе, которая отвечает за их сохранение, обработку или извлечение. Например, для мультимедийных служб, обеспечивающих согласованную отправку и загрузку файлов между облачными продуктами, выделено хранилище, которое недоступно для всех остальных служб Atlassian. Любая служба, которой требуется доступ к медиаконтенту, должна взаимодействовать с API медиаслужб. В результате строгая аутентификация и авторизация на уровне служб также гарантируют строгое разделение обязанностей и доступ к данным с минимальными привилегиями.
Мы используем веб-токены JSON (JWT) для обеспечения права подписи вне приложения, поэтому наши системы идентификации и контекст держателей являются достоверным источником информации. Токены можно использовать для доступа только к тем данным, для которых был выдан токен. Если вы или участник вашей команды обращаетесь к микросервису или сегменту данных, токены передаются в вашу систему идентификации и проходят проверку. Этот процесс обеспечивает актуальность токена и наличие подписи до предоставления соответствующих данных. В сочетании с авторизацией и аутентификацией, необходимыми для доступа к этим микросервисам, это позволяет ограничить область данных, если служба скомпрометирована.
Мы знаем, что порой системы идентификации взламывают. Для снижения этого риска компания Atlassian использует два механизма. Первый — это высокий уровень репликации TCS и прокси-серверов удостоверений. Мы используем TCS-расширение почти для каждой микрослужбы и ответвляющиеся от органа идентификации расширения для прокси-серверов, чтобы обеспечить постоянную работу тысяч таких служб. При возникновении аномального поведения в одном или нескольких местах мы сможем быстро это заметить и устранить проблему.
Кроме того, мы не ждем, когда кто-то обнаружит уязвимость в наших продуктах или платформе. Наша компания активно выявляет такие сценарии для сокращения негативных последствий до минимума и ведет ряд программ обеспечения безопасности для выявления и обнаружения угроз безопасности, а также реагирования на них.
Служба контекста держателей
Мы следим за тем, чтобы запросы к любым микросервисам содержали метаданные о клиенте (или держателе), запрашивающем доступ. Это называется «службой контекста держателей». Она заполняется непосредственно из наших систем выделения ресурсов. При запуске запроса происходит считывание и поглощение контекста в исполняемый служебный код, который используется для авторизации пользователя. Для получения доступа к любой службе и, соответственно, к данным в Jira и Confluence требуется этот контекст держателя, в противном случае запрос будет отклонен.
Аутентификация и авторизация служб выполняются через протокол аутентификации служб Atlassian (ASAP). В списке явно разрешенных перечисляются службы, имеющие право на взаимодействие, а в сведениях об авторизации определяются доступные команды и пути. Это ограничивает возможное боковое смещение скомпрометированной службы.
Аутентификация и авторизация служб, а также исходящий трафик контролируются через набор выделенных прокси, что исключает возможность воздействия на эти элементы управления со стороны уязвимостей в коде приложений. Для удаленного выполнения кода придется не только изменить логику приложения, но и скомпрометировать базовый хост и обойти границы контейнера Docker. Однако в таком случае наша система обнаружения вторжений на уровне хоста отметит расхождения.
Эти прокси ограничивают поведение исходящего трафика в зависимости от предполагаемого поведения службы. Службам, которым не нужно выдавать веб-хуки или взаимодействовать с другими микросервисами, запрещено выполнять эти действия.
Шифрование данных
Данные клиентов, хранящиеся в облачных продуктах Atlassian, шифруются при передаче по общедоступным сетям с помощью протокола TLS 1.2+ с полной безопасностью пересылки (PFS) для защиты от несанкционированного раскрытия или изменения. Наша реализация TLS обеспечивает использование криптостойких шифров и ключей нужной длины, если это поддерживается браузером.
Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie, and Trello use full disk, industry-standard AES-256 encryption at rest.
Данные, позволяющие установить личность (PII), передаваемые по сети передачи данных, подлежат соответствующему контролю, гарантирующему, что они дойдут до предполагаемого места назначения. Внутренняя политика Atlassian, касающаяся криптографии и шифрования, определяет общие принципы внедрения механизмов шифрования и криптографии для снижения рисков, связанных с хранением и передачей PII по сетям. Тип алгоритма, используемого для шифрования PII, должен учитывать уровень классификации PII в соответствии с внутренними правилами управления безопасностью данных и жизненным циклом информации в Atlassian. Подробнее о сборе, использовании и раскрытии информации клиентов см. на странице политики конфиденциальности 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. Ни один этап данного процесса не влияет на удобство использования продукта.