ENISA: Европейское агентство по сетевой и информационной безопасности

Европейское агентство по сетевой и информационной безопасности (ENISA) — это центр передовых знаний по защите сетей и информации. Оно тесно сотрудничает со странами ЕС и предприятиями частного сектора, предоставляя консультации и рекомендации по эффективному обеспечению кибербезопасности. Помимо этого, ENISA поддерживает разработку и внедрение политик и законов ЕС, связанных с национальной информационной безопасностью.

Свод правил защиты информации (IAF) ENISA в сфере облачных вычислений — это набор критериев, по которым организации могут проверять, гарантируют ли поставщики облачных услуг (CSP) достаточные меры защиты данных их клиентов. IAF помогает оценить риск внедрения облачных услуг и облегчить для CSP подтверждение соответствия требованиям.

Для соблюдения IAF компания Atlassian применяет матрицу контроля облачных вычислений (CCM) Альянса облачной безопасности (CSA), в которой области и меры контроля сопоставлены с критериями безопасности IAF, а также проходит сертификацию по стандарту ISO 27001.

Atlassian предоставляет следующие гарантии согласно CCM.

• Самостоятельная оценка CSA STAR уровня 1

В этом руководстве представлены критерии обеспечения безопасности, которые помогут организациям выбрать поставщика облачных услуг. Если у вас есть вопросы о конкретных пунктах, свяжитесь с нашей командой по продажам для корпоративных клиентов по адресу https://www.atlassian.com/enterprise/contact?formType=product-features.

6.01

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

6.01. (a)

Какими политиками и процедурами вы руководствуетесь при найме ИТ-администраторов или других сотрудников, которым предоставляется доступ к системе? Они должны включать следующее.

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

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

6.01. (b)

Различаются ли политики в зависимости от места хранения данных или выполнения приложений?

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

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

Для управления всеми системами 1-го уровня используется централизованное решение Atlassian, за счет которого реализована система единого входа (SSO) и каталоги пользователей. Эти профили определяют, какие права доступа предоставляются пользователям, в соответствии с рабочим процессом нашей системы управления кадрами. Для доступа ко всем системам 1-го уровня используется многофакторная аутентификация. Для доступа к консоли управления гипервизором и API AWS нужно пройти двухфакторную аутентификацию. Кроме того, ежедневно составляется отчет о проверке, в котором содержатся данные обо всех случаях получения доступа к функциям управления гипервизором. Списки доступа к консоли управления гипервизором и API AWS подвергаются ревизии ежеквартально. Синхронизация между системой управления кадрами и хранилищем учетных данных происходит в течение восьмичасового окна.

В более широком контексте меры контроля доступа описаны в Политике управления доступом, выдержка из которой доступна здесь: https://www.atlassian.com/trust.

6.01. (c)

Какую программу обучения по вопросам безопасности вы проводите для всех сотрудников?

Компания Atlassian проводит обучение по вопросам безопасности в рамках адаптации новых сотрудников («День 1») и на постоянной основе для всех сотрудников.

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

Мы также проводим постоянное обучение по актуальным вопросам безопасности, связанным с вредоносными программами, фишингом и другими проблемами. Подробнее см. на странице https://www.atlassian.com/trust/security/security-practices#security-awareness-training.

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

6.01. (d)

Существует ли процесс непрерывной оценки?

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

Облачные сервисы Atlassian прошли сертификацию на соответствие стандартам SOC 2, ISO 27001 и ISO 27018. Не реже одного раза в год мы проводим внутренние и внешние аудиторские проверки готовности. Ряд продуктов Atlassian сертифицирован по стандартам ISO, что требует регулярной оценки рисков и пересмотра политик обработки данных.

Подробнее см. на странице https://www.atlassian.com/trust/compliance. Клиентам рекомендуется регулярно загружать и изучать обновления наших сертификатов соответствия и отчетов с этого сайта.

В Atlassian задокументирована система политик, основной из которых является политика безопасности. Мы разработали четкую Программу управления политиками (PMP), включающую вопросы владения, доступности и цикла пересмотра, а также определяющую наши общие цели. Наши политики пересматриваются не реже одного раза в год и утверждаются высшим руководством. Узнать больше о нашей программе PMP можно по ссылке https://www.atlassian.com/trust/security/security-management-program.

Мы также опубликовали выдержки из каждой из наших политик высокого уровня с тезисным изложением. Их можно найти по адресу https://www.atlassian.com/trust/security/ismp-policies.

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

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

6.02.

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

6.02. (a)

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

Компания Atlassian сотрудничает со сторонними субподрядчиками, предоставляющими такие услуги, как разработка сайтов и приложений, хостинг, техническое обслуживание, резервное копирование, хранение, виртуальная инфраструктура, обработка платежей, анализ и другие. Список дополнительных обработчиков данных, в настоящее время привлекаемых Atlassian и одобренных клиентом, указан на сайте https://www.atlassian.com/legal/sub-processors.

6.02. (b)

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

• Проверяете ли вы своих партнеров по аутсорсингу и субподрядчиков и как часто?

Наши специалисты по юридическим вопросам и закупкам анализируют договоры, соглашения об уровне обслуживания и внутренние политики поставщиков для управления рисками, связанными с безопасностью, доступностью и конфиденциальностью. При необходимости мы также проводим оценку функциональных рисков, как того требует профиль рисков. Оценка рисков пересматривается в рамках обновления политики и каждый раз при существенных изменениях во взаимоотношениях с поставщиком. Этот процесс описан в нашей Политике управления данными поставщиков и третьих лиц, выдержка из которой доступна здесь: https://www.atlassian.com/trust/security/ismp-policies.

6.02. (c)

Предлагают ли партнеры по аутсорсингу какие-либо условия SLA ниже тех условий SLA, которые вы предлагаете своим клиентам? Если нет, предусмотрен ли у вас запасной резерв поставщиков?

В зависимости от условий лицензирования наши Условия для клиентов продуктов Cloud следует перечитывать при продлении месячной либо годовой подписки. Наши специалисты по юридическим вопросам и закупкам анализируют договоры, соглашения об уровне обслуживания и внутренние политики поставщиков для управления рисками, связанными с безопасностью, доступностью и конфиденциальностью. В рамках Программы управления корпоративными рисками (ERM) компания Atlassian проводит ежегодную оценку рисков, которая учитывает вероятность и воздействие для всех категорий рисков и соответствует модели рисков COSO. При необходимости мы также проводим оценку функциональных рисков, как того требует профиль рисков. Оценка рисков пересматривается в рамках обновления политики и каждый раз при существенных изменениях во взаимоотношениях с поставщиком.

6.02. (d)

Какие меры предпринимаются для обеспечения и поддержания уровней обслуживания третьих сторон?

Наши специалисты по юридическим вопросам и закупкам анализируют договоры, соглашения об уровне обслуживания и внутренние политики поставщиков для управления рисками, связанными с безопасностью, доступностью и конфиденциальностью. При необходимости мы также проводим оценку функциональных рисков, как того требует профиль рисков. Оценка рисков пересматривается в рамках обновления политики и каждый раз при существенных изменениях во взаимоотношениях с поставщиком. Этот процесс описан в нашей Политике управления данными поставщиков и третьих лиц, выдержка из которой доступна здесь: https://www.atlassian.com/trust/security/ismp-policies.

6.02. (e)

Может ли поставщик облачных услуг подтвердить, что к его сторонним поставщикам применяются (по договору) политика безопасности и средства контроля?

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

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

6.03.

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

6.03. (a)

Подробно опишите процедуру и политику управления изменениями. Сюда также следует включить процесс, используемый для повторной оценки рисков в результате изменений, и уточнить, доступны ли результаты конечным клиентам.

В Atlassian действует Программа управления корпоративными рисками (ERM), согласованная с моделью управления рисками COSO и стандартом ISO 31000. Согласно программе ERM, в масштабе всей компании Atlassian реализованы система и методология управления рисками, проводятся ежегодная оценка рисков, периодическая оценка конкретных рисков в рабочей среде и оценки функциональных рисков, как того требует профиль рисков.

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

Сотрудники, участвующие в процессах управления рисками Atlassian, в достаточной степени осведомлены о своих обязанностях и обучены их выполнению. Отслеживание всех рисков и управление ими осуществляется с помощью собственного инструмента Jira, при этом ответственность за соответствующие планы и проекты мер нейтрализации несут руководители. Подробнее см. на странице https://www.atlassian.com/trust/security/security-management-program или https://www.atlassian.com/trust/compliance/risk-management-program.

Процесс управления изменениями в Atlassian немного отличается от традиционных. При внесении любых изменений, будь то изменения в коде, приложении или инфраструктуре, мы полагаемся на подход, называемый «Оценка коллегами, зеленая сборка» (PRGB). «Оценка коллегами» настраивается в нашем инструменте CD, где критически важным веткам для каждого запроса pull необходимо назначить несколько проверяющих. Обычно это два разработчика и руководитель команды. «Зеленая сборка» означает, что интеграция на этапе CI должна пройти все разработанные интеграционные, функциональные, защитные и другие тесты. Если эти тесты завершатся неудачно («красная сборка»), слияния кода не произойдет, код необходимо будет снова проверить и устранить ошибки. После успешной «зеленой сборки» на двоичный файл ставится криптографическая подпись, и в нашей рабочей среде выполняются только двоичные файлы, подписанные нашим ключом. Процесс тестирования включает в себя как автоматизированные, так и ручные компоненты оценки. Мы любим писать в блоге о том, что у нас хорошо получается. Особое значение для нас имеет использование подхода под названием «Обеспечение качества путем содействия» вместо привычного контроля качества. Подробнее о нем см. на странице https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance.

6.03. (b)

Определите политику удаленного доступа.

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

Все устройства (принадлежащие Atlassian или личные), используемые сотрудниками Atlassian и имеющие доступ к ЛЮБЫМ инструментам Atlassian, регистрируются в системе управления устройствами с применением профилей безопасности программного обеспечения MDM и проверки состояния безопасности. Ко всем устройствам Atlassian мы применяем модель безопасности, основанную на принципе «нулевого доверия». Подробнее см. здесь: https://www.atlassian.com/trust/compliance/resources/eba/eba-guidance.

6.03. (c)

Поддерживает ли поставщик документированные операционные процедуры для информационных систем?

Основные принципы операционной безопасности Atlassian включают разработку документации по стандартным операционным процедурам. Мы также опубликовали выдержки из каждой из наших политик высокого уровня с тезисным изложением. Их можно найти по адресу https://www.atlassian.com/trust/security/ismp-policies.

6.03. (d)

Существует ли промежуточная среда для снижения рисков? Например, разграничивают ли отдельные среды разработки, тестирования и эксплуатации?

В Atlassian действуют политики информационной безопасности, запрещающие использование данных рабочей среды за ее пределами, а любые попытки переноса данных между средами будут выявляться в процессе управления изменениями. Код переносится из централизованной системы сборки с предварительным проведением модульного тестирования. Затем проводится проверка функциональной ветки с помощью дополнительного автоматизированного теста и оценка результатов в контрольных точках со стороны руководителя проекта, разработчиков и специалистов по контролю качества. Затем проводятся приемочное пользовательское тестирование (UAT), а также проверка безопасности и производительности. Разработчики не могут продвигать код непосредственно в рабочую среду. Подробнее см. на странице https://www.atlassian.com/trust/security/security-practices#managing-changes-in-our-environment.

Мы соблюдаем логическое и физическое разделение сред на рабочую и нерабочую (т. е. среду разработки) и применяем методы изоляции этих сред.

Для раздела проиндексированных файлов существует логическое разделение (но не физическое), но управляется он процессами контроля изменений и доступа, отвечающими уровню рабочей среды. Подробнее о методах обеспечения безопасности кода см. на странице https://www.atlassian.com/trust/security/security-in-development.

6.03. (e)

Определите средства контроля хоста и сети, используемые для защиты систем, на которых размещаются приложения и информация для конечного клиента. Сюда следует включить сведения о сертификации по внешним стандартам (например, ISO 27001/2).

Команда по проектированию сетей Atlassian использует технологии предотвращения вторжений (IPS), встроенные в брандмауэры нашего облака и офисов, а в офисных средах внедрены технологии обнаружения вторжений (IDS). Компания AWS обеспечивает защиту от сетевых угроз, включая защиту от DDoS-атак. Кроме того, для защиты служит ряд функций брандмауэра веб-приложений. Для шифрования всех данных наших сервисов при передаче используется протокол TLS, что позволяет защитить их от несанкционированного раскрытия или изменения при передаче как по протоколу HTTPS, так и по SMTPS.

Облачные сервисы Atlassian прошли сертификацию на соответствие стандартам SOC 2, ISO 27001 и ISO 27018. Не реже одного раза в год мы проводим внутренние и внешние аудиторские проверки готовности.

Подробнее см. на странице https://www.atlassian.com/trust/compliance. Клиентам рекомендуется регулярно загружать и изучать обновления наших сертификатов соответствия и отчетов с этого сайта.

6.03. (f)

Укажите средства контроля, используемые для защиты от вредоносного кода.

Компания Atlassian внедрила систему Crowdstrike Falcon (https://www.crowdstrike.com/falcon-platform/) для своего парка машин под управлением Windows и машин Mac. Мы не используем средства защиты от вредоносного ПО на компьютерах под управлением Linux. Защита от вредоносного ПО включена в нашу политику управления уязвимостями.

Мы соблюдаем Политику защиты от угроз и управления уязвимостями. Мы разработали четкую Программу управления политиками (PMP), включающую вопросы владения, доступности и цикла пересмотра, а также определяющую наши общие цели. Наши политики пересматриваются не реже одного раза в год и утверждаются высшим руководством. Узнать больше о нашей программе PMP можно по ссылке https://www.atlassian.com/trust/security/security-management-program.

Мы также опубликовали выдержки из каждой из наших политик высокого уровня с тезисным изложением. Их можно найти по адресу https://www.atlassian.com/trust/security/ismp-policies.

6.03. (g)

Развернуты ли безопасные конфигурации, позволяющие выполнять только авторизованный мобильный код и авторизованные функции (например, выполнять только определенные команды)?

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

Наша корпоративная сеть отделена от рабочей сети, а образы машин усилены и позволяют использовать только необходимые порты и протоколы. В настоящее время все рабочие системы размещены у нашего поставщика облачных услуг в регионах США. Все данные, передаваемые за пределами усиленных виртуальных частных облачных сетей (VPC), шифруются и направляются по стандартным каналам.

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

Мы также внедрили централизованное решение для управления системой (https://www.jamf.com/lp/apple-mobile-device-management-mdm-jamf/) для своего парка ноутбуков Mac. На ноутбуках мы используем полное шифрование диска. Кроме того, мы внедрили решение для управления мобильными устройствами для своих смартфонов (https://www.vmware.com/products/workspace-one.html). Для доступа к внутренним системам и приложениям все устройства должны быть зарегистрированы. Если мобильное устройство не зарегистрировано, оно не может получить доступ к внутренним ресурсам и подключается к гостевой сети, имеющей только доступ к Интернету. Управление доступом осуществляется с помощью средств контроля на основе ролей, которые гарантируют предоставление доступа к данным клиентов/держателей только для тех пользователей, которым он требуется.

6.03. (h)

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

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

Мы не используем эти резервные копии для восстановления данных, уничтоженных клиентами, в том числе в результате перезаписи полей с помощью скриптов, удаления задач, проектов или сайтов. Во избежание потери данных рекомендуется выполнять регулярное резервное копирование. Подробнее о создании резервных копий см. в документации по поддержке конкретного продукта. Клиентам также следует периодически выполнять резервное копирование, чтобы иметь возможность отменять изменения, инициированные ими. Дополнительные сведения см. на сайте 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 придерживается стандарта по сохранению и уничтожению данных, в котором определены сроки хранения данных разных типов. Данные подразделяются на категории в соответствии с политикой безопасности данных и жизненного цикла информации Atlassian, и на ее основе реализованы механизмы контроля. При прекращении действия договора с Atlassian данные, принадлежащие команде клиента, будут удалены из рабочей базы данных, а все вложенные файлы, загруженные непосредственно в системы Atlassian, будут удалены в течение 14 дней. Данные команды будут храниться в зашифрованных резервных копиях до истечения 90-дневного периода хранения резервных копий, после чего они будут уничтожены в соответствии с политикой хранения данных Atlassian. Если в течение 90 дней после запрошенного удаления данных потребуется восстановить базу данных, операционная команда повторно удалит данные в разумно возможный кратчайший срок после того, как рабочая система будет полностью восстановлена. Подробнее см. на странице https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

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

6.03. (i)

Может ли поставщик указать, какая информация записывается в журналы?

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

Основные системные журналы передаются из каждой системы на централизованную платформу журналов, причем журналы доступны только для чтения. Команда по обеспечению безопасности Atlassian создает оповещения на нашей платформе аналитики безопасности (Splunk) и отслеживает признаки угрозы. Наши команды по обеспечению надежности используют эту платформу, чтобы отслеживать проблемы, влияющие на доступность или производительность. Журналы хранятся в течение 30 дней в архивах «горячего» резервирования и в течение 365 дней в архивах «холодного» резервирования.

Atlassian предоставляет доступ для просмотра и чтения журналов только уполномоченным сотрудникам на нашей централизованной платформе.

Компания Atlassian придерживается стандарта по сохранению и уничтожению данных, в котором определены сроки хранения данных разных типов. Данные подразделяются на категории в соответствии с политикой безопасности данных и жизненного цикла информации Atlassian, и на ее основе реализованы механизмы контроля. При прекращении действия договора с Atlassian данные, принадлежащие команде клиента, будут удалены из рабочей базы данных, а все вложенные файлы, загруженные непосредственно в системы Atlassian, будут удалены в течение 14 дней. Данные команды будут храниться в зашифрованных резервных копиях до истечения 90-дневного периода хранения резервных копий, после чего они будут уничтожены в соответствии с политикой хранения данных Atlassian. Если в течение 90 дней после запрошенного удаления данных потребуется восстановить базу данных, операционная команда повторно удалит данные в разумно возможный кратчайший срок после того, как рабочая система будет полностью восстановлена. Подробнее см. на странице https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.03. (j)

Как проверяются журналы? Какие записанные события приводят к принятию мер?

Основные системные журналы передаются из каждой системы на централизованную платформу журналов, причем журналы доступны только для чтения. Команда по обеспечению безопасности Atlassian создает оповещения на нашей платформе аналитики безопасности (Splunk) и отслеживает признаки угрозы. Наши команды по обеспечению надежности используют эту платформу, чтобы отслеживать проблемы, влияющие на доступность или производительность. Журналы хранятся в течение 30 дней в архивах «горячего» резервирования и в течение 365 дней в архивах «холодного» резервирования.

Atlassian предоставляет доступ для просмотра и чтения журналов только уполномоченным сотрудникам на нашей централизованной платформе.

6.03. (k)

Какой источник времени используется для синхронизации систем и указания меток точного времени в журнале?

В Atlassian Cloud для всех развернутых экземпляров используется AWS Time Sync.

6.03.01. (a)

Определите средства контроля, используемые для защиты целостности операционной системы и используемых приложений. Включите любые соблюдаемые стандарты, например OWASP, Контрольный список SANS, SAFECode.

Наша команда инженеров по безопасности постоянно проверяет весь исходный код наших продуктов в рамках цикла разработки. Используются как автоматизированные, так и ручные методы. Мы также используем обязательный процесс двойной проверки коллегами, когда несколько старших или ведущих разработчиков проверяют все коммиты в главную ветку. Рабочие процессы Agile позволяют нам быстро выявлять и исправлять любые уязвимости, особенно в наших облачных сервисах.

Процесс проверки защищенного кода Atlassian включает автоматическое сканирование (т. е. анализ композиции программного обеспечения) на наличие известных уязвимостей, в том числе используемых в реальных атаках. Кроме того, наша программа управления уязвимостями сканирует хосты и образы контейнеров на наличие известных уязвимостей с помощью Snyk. Подробнее см. по ссылке https://www.atlassian.com/trust/security/vulnerability-management.

Мы сотрудничаем с BugCrowd, чтобы поддерживать программу вознаграждения за найденные ошибки и проводить постоянные оценки уязвимости наших общедоступных приложений и служб. С программой можно ознакомиться на странице https://bugcrowd.com/atlassian. Мы публикуем текущие результаты тестирования на проникновение в рамках нашей программы вознаграждения за найденные ошибки на странице https://www.atlassian.com/trust/security/security-testing.

6.03.01. (b)

Как убедиться, что новые релизы пригодны для использования и не содержат рисков (бэкдоров, троянов и т. п.)? Проверяются ли они перед использованием?

Процесс управления изменениями в Atlassian немного отличается от традиционных. При внесении любых изменений, будь то изменения в коде, приложении или инфраструктуре, мы полагаемся на подход, называемый «Проверка коллегами, зеленая сборка» (PRGB). «Проверка коллегами» реализована в нашем инструменте CD, где критически важным веткам для каждого запроса pull необходимо назначить несколько проверяющих. Обычно это два разработчика и руководитель команды. «Зеленая сборка» означает, что интеграция на этапе CI должна пройти все разработанные интеграционные, функциональные, защитные и другие тесты. Если эти тесты завершатся неудачно («красная сборка»), слияние кода не выполняется, код необходимо будет снова проверить и устранить ошибки. После успешной «зеленой сборки» на двоичный файл ставится криптографическая подпись, и в нашей рабочей среде выполняются только двоичные файлы, подписанные нашим ключом. Процесс тестирования включает в себя как автоматизированные, так и ручные компоненты оценки. Мы любим писать в блоге о том, что у нас хорошо получается. Особое значение для нас имеет использование подхода под названием «Содействие в обеспечении качества» (а не привычный «контроль качества»). Подробнее о нем см. на странице https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance.

После развертывания регулярно проводится автоматизированное сканирование на предмет уязвимостей, а также используется ведущая в отрасли программа вознаграждения за найденные ошибки (https://bugcrowd.com/atlassian), которая обеспечивает непрерывную проверку безопасности наших приложений. Управление изменениями конфигурации системы осуществляется с помощью автоматизированного процесса, включающего проверку.

Процесс проверки защищенного кода Atlassian включает автоматическое сканирование (т. е. анализ композиции программного обеспечения) на наличие известных уязвимостей, в том числе используемых в реальных атаках. Кроме того, наша программа управления уязвимостями сканирует хосты и образы контейнеров на наличие известных уязвимостей с помощью Snyk. Подробнее см. по ссылке https://www.atlassian.com/trust/security/data-management.

6.03.01. (c)

Какие методы используются для обеспечения безопасности приложений?

Для наших приложений требуется проверка коллегами и зеленая сборка (PRGB), после чего артефакты приложений снабжаются криптографической подписью и автоматически развертываются нашим конвейером CI/CD. Только приложения, подписанные Atlassian, могут запускаться в нашей рабочей среде.

Методы обеспечения безопасности Atlassian охватывают каждый этап жизненного цикла разработки. Подробнее см. на странице https://www.atlassian.com/trust/security/security-in-development.

На этапе дизайна такие методы, как моделирование угроз, оценка проекта, а также реализация стандартов безопасности из регулярно обновляемой библиотеки, гарантируют соблюдение требований к безопасности. В ходе разработки проводится обязательная проверка коллегами, которая играет роль проверки безопасности первого уровня. Проверка предполагает автоматический статический анализ (SAST) и ручное тестирование безопасности и выполняется как штатными специалистами, так и сторонними экспертами согласно внутренней процедуре оценки рисков. Разработка ведется в том числе при поддержке обучающих программ по безопасности приложений, а также базы знаний, которую регулярно пополняет команда безопасности. Оценка формальной готовности к запуску и процессы контроля изменений обеспечивают развертывание только подтвержденных изменений. После развертывания регулярно проводится автоматизированное сканирование на предмет уязвимостей, а также используется ведущая в отрасли программа вознаграждения за найденные ошибки (https://bugcrowd.com/atlassian), которая обеспечивает непрерывную проверку безопасности наших приложений. Управление изменениями конфигурации системы осуществляется с помощью автоматизированного процесса, включающего проверку всех изменений перед развертыванием в рабочей среде. Отдел работы служб Atlassian может развертывать исправления сразу после выявления серьезного риска. У нас есть внутренние критерии, определяющие, как быстро необходимо внедрять исправления, и мы можем применить их на всех машинах в течение 12 часов. Также предусмотрена система IDS, включающая мониторинг файлов конфигурации системы.

6.03.01. (d)

Проходят ли релизы ПО проверку на проникновение, чтобы гарантировать отсутствие уязвимостей? Если уязвимости обнаружены, каков процесс их устранения?

Методы обеспечения безопасности Atlassian охватывают каждый этап жизненного цикла разработки. Подробнее см. на странице https://www.atlassian.com/trust/security/security-in-development.

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

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

6.03.02. (a)

Предоставляются ли подробные сведения об используемой процедуре управления исправлениями?

Мы соблюдаем Политику управления угрозами и уязвимостями. Мы разработали четкую Программу управления политиками (PMP), включающую вопросы владения, доступности и цикла пересмотра, а также определяющую наши общие цели. Наши политики пересматриваются не реже одного раза в год и утверждаются высшим руководством. Узнать больше о нашей программе PMP можно по ссылке https://www.atlassian.com/trust/security/security-management-program.

Мы также опубликовали выдержки из каждой из наших высокоуровневых политик с тезисным изложением. Их можно найти по адресу https://www.atlassian.com/trust/security/ismp-policies

Компания Atlassian использует несколько решений по управлению конечными точками, чтобы развертывать обновления и патчи для операционных систем и ключевых приложений на всем комплексе наших конечных точек. Мы также внедрили множество решений по защите конечных точек, чтобы устранить такие угрозы, как вредоносное ПО. Подробнее см. на странице https://www.atlassian.com/trust/security/security-practices#keeping-track-of-information-assets

6.03.02. (b)

Можно ли обеспечить, чтобы процесс управления исправлениями охватывал все уровни технологий доставки в облаке — сеть (компоненты инфраструктуры, маршрутизаторы и коммутаторы и т. п.), серверные операционные системы, программное обеспечение для виртуализации, приложения и подсистемы безопасности (брандмауэры, антивирусные шлюзы, системы обнаружения вторжений и т. п.)?

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

Продукты Atlassian Cloud можно обновлять до последней версии AMI настолько быстро, насколько это необходимо. Наши приложения SaaS обновляются несколько раз в неделю. У нас есть механизмы быстрого и контролируемого развертывания обновлений программного кода и конфигураций систем. Atlassian активно использует систему управления изменениями для внеплановых и экстренных изменений.

6.03.03. (a)

Определите средства контроля, используемые для предотвращения DDoS-атак (распределенных атак типа «отказ в обслуживании»).

• Многоуровневая защита (глубокий анализ пакетов, регулирование трафика, нулевая маршрутизация пакетов и т. д.).
• Есть ли у вас средства защиты от «внутренних» (исходящих из сетей поставщиков облачных услуг), а также от внешних (исходящих из Интернета или сетей клиентов) атак?
<

Требования к безопасности сети определены в Политике безопасности коммуникации, которая ежегодно пересматривается в соответствии с нашей Программой управления политиками (PMP). Подробнее о нашей программе PMP см. по ссылке https://www.atlassian.com/trust/security/security-management-program.

Лишь очень небольшая область платформы Atlassian Cloud открыта для доступа через брандмауэры. Мы периодически пересматриваем правила брандмауэров. В наших офисах и в облачной среде размещения развернута система обнаружения вторжений (IDS). На платформе Atlassian Cloud функция пересылки журналов встроена в платформу аналитики безопасности. На уровне контейнеров облачной платформы целостность файлов сохраняется, поскольку экземпляры нельзя изменять. Команда по проектированию сетей Atlassian использует технологии предотвращения вторжений (IPS), встроенные в наши брандмауэры, а в офисных и облачных средах внедрены технологии обнаружения вторжений (IDS). Возможности противодействия DDoS-атакам предоставляются нашим интернет-провайдером/оператором связи.

Эффективность работы наших брандмауэров также регулярно оценивается с помощью программ для оценки уязвимостей (https://www.atlassian.com/trust/security/vulnerability-management) и тестирования на проникновение (https://www.atlassian.com/trust/security/security-testing).

6.03.03. (b)

Какие уровни изоляции используются?

• Для виртуальных машин, физических машин, сетей, хранилищ (например, сетей хранения данных), административных сетей, систем поддержки управления и т. д.
<

Atlassian — это SaaS-приложение, рассчитанное на множество держателей. Архитектура с несколькими держателями является ключевой особенностью Atlassian Cloud, которая позволяет нескольким клиентам совместно использовать один экземпляр уровня приложений Jira или Confluence, изолируя при этом данные приложений каждого держателя. Atlassian Cloud решает эту задачу с помощью службы контекста держателей (TCS). Каждый идентификатор пользователя, используемый для доступа к приложениям Atlassian Cloud, связан ровно с одним держателем. Подробнее см. на странице https://www.atlassian.com/trust/security/security-practices#tenant-isolation.

Мы соблюдаем логическое и физическое разделение сред на рабочую и нерабочую (т. е. среду разработки) и применяем методы изоляции этих сред.

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

6.03.03. (c)

Поддерживает ли архитектура непрерывную работу из облака, когда компания отделена от поставщика услуг и наоборот (например, существует ли критическая зависимость от системы LDAP клиента)?

В компании действует политика обеспечения непрерывности бизнеса и аварийного восстановления, а также одноименный план, которые ежегодно пересматриваются руководящим комитетом по обеспечению непрерывности бизнеса и аварийному восстановлению. Подробнее см. на страницах https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e и https://www.atlassian.com/trust/security/data-management.

Atlassian использует высокодоступные ЦОД AWS в разных регионах по всему миру для поддержания непрерывной работы. Подробнее см. по ссылке https://www.atlassian.com/trust/security/data-management.

6.03.03. (d)

Защищена ли инфраструктура виртуальной сети, используемая поставщиками облачных услуг (в архитектуре PVLAN и VLAN с тегированием 802.1q), в соответствии со стандартами поставщика и (или) передовых практик (например, предотвращается ли подмена MAC, отравление ARP и т. д. с помощью специальной конфигурации безопасности)?

Требования к безопасности сети определены в Политике безопасности коммуникации, которая ежегодно пересматривается в соответствии с нашей Программой управления политиками (PMP). Подробнее о нашей программе PMP см. по ссылке https://www.atlassian.com/trust/security/security-management-program.

Лишь очень небольшая область платформы Atlassian Cloud открыта для доступа через брандмауэры. Мы периодически пересматриваем правила брандмауэров. В наших офисах и в облачной среде размещения развернута система обнаружения вторжений (IDS). На платформе Atlassian Cloud функция пересылки журналов встроена в платформу аналитики безопасности. На уровне контейнеров облачной платформы целостность файлов сохраняется, поскольку экземпляры нельзя изменять. Команда по проектированию сетей Atlassian использует технологии предотвращения вторжений (IPS), встроенные в наши брандмауэры, а в офисных и облачных средах внедрены технологии обнаружения вторжений (IDS). Возможности противодействия DDoS-атакам предоставляются нашим интернет-провайдером/оператором связи.

Эффективность работы наших брандмауэров также регулярно оценивается с помощью программ для оценки уязвимостей (https://www.atlassian.com/trust/security/vulnerability-management) и тестирования на проникновение (https://www.atlassian.com/trust/security/security-testing).

Кроме того, компания Atlassian отслеживает конфигурации своих сред AWS и контролирует их соответствие установленным стандартам.

6.03.04. (a)

Внедрено ли у поставщика реализованное по умолчанию усиление защиты виртуальных образов?

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

Наша корпоративная сеть отделена от рабочей сети, а образы машин усилены и позволяют использовать только необходимые порты и протоколы. В настоящее время все рабочие системы размещены у нашего поставщика облачных услуг в регионах США. Все данные, передаваемые за пределами усиленных виртуальных частных облачных сетей (VPC), шифруются и направляются по стандартным каналам.

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

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

Базовые сборки образов ОС AWS Linux AMI имеют ограниченное количество портов, протоколов и служб. Мы сравниваем наши сборки с текущей версией AMI, чтобы проверить правильность настроек.

Управление образами Docker осуществляется в строго контролируемой среде изменений, благодаря чему все изменения надлежащим образом проверяются и подтверждаются.

6.03.04. (b)

Защищен ли усиленный виртуальный образ от несанкционированного доступа?

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

Наша корпоративная сеть отделена от рабочей сети, а образы машин усилены и позволяют использовать только необходимые порты и протоколы. В настоящее время все рабочие системы размещены у нашего поставщика облачных услуг в регионах США. Все данные, передаваемые за пределами усиленных виртуальных частных облачных сетей (VPC), шифруются и направляются по стандартным каналам.

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

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

Базовые сборки образов ОС AWS Linux AMI имеют ограниченное количество портов, протоколов и служб. Мы сравниваем наши сборки с текущей версией AMI, чтобы проверить правильность настроек.

Управление образами Docker осуществляется в строго контролируемой среде изменений, благодаря чему все изменения надлежащим образом проверяются и подтверждаются.

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

6.03.04. (c)

Может ли поставщик подтвердить, что виртуализованный образ не содержит учетных данных для аутентификации?

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

Наша корпоративная сеть отделена от рабочей сети, а образы машин усилены и позволяют использовать только необходимые порты и протоколы. В настоящее время все рабочие системы размещены у нашего поставщика облачных услуг в регионах США. Все данные, передаваемые за пределами усиленных виртуальных частных облачных сетей (VPC), шифруются и направляются по стандартным каналам.

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

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

Базовые сборки образов ОС AWS Linux AMI имеют ограниченное количество портов, протоколов и служб. Мы сравниваем наши сборки с текущей версией AMI, чтобы проверить правильность настроек.

Управление образами Docker осуществляется в строго контролируемой среде изменений, благодаря чему все изменения надлежащим образом проверяются и подтверждаются.

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

6.03.04. (d)

В брандмауэре хоста задействовано только минимальное количество портов, необходимых для поддержки служб в виртуальном экземпляре?

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

Наша корпоративная сеть отделена от рабочей сети, а образы машин усилены и позволяют использовать только необходимые порты и протоколы. В настоящее время все рабочие системы размещены у нашего поставщика облачных услуг в регионах США. Все данные, передаваемые за пределами усиленных виртуальных частных облачных сетей (VPC), шифруются и направляются по стандартным каналам.

Лишь очень небольшая область платформы Atlassian Cloud открыта для доступа через брандмауэры. Мы периодически пересматриваем правила брандмауэров. В наших офисах и в облачной среде размещения развернута система обнаружения вторжений (IDS). На платформе Atlassian Cloud функция пересылки журналов встроена в платформу аналитики безопасности. На уровне контейнеров облачной платформы целостность файлов сохраняется, поскольку экземпляры нельзя изменять. Команда по проектированию сетей Atlassian использует технологии предотвращения вторжений (IPS), встроенные в наши брандмауэры, а в офисных и облачных средах внедрены технологии обнаружения вторжений (IDS). Возможности противодействия DDoS-атакам предоставляются нашим интернет-провайдером/оператором связи.

Эффективность работы наших брандмауэров также регулярно оценивается с помощью программ для оценки уязвимостей (https://www.atlassian.com/trust/security/vulnerability-management) и тестирования на проникновение (https://www.atlassian.com/trust/security/security-testing).

6.03.04. (e)

Можно ли запустить в виртуальном экземпляре службу предотвращения вторжений (IPS) на базе хоста?

Это неприменимо, поскольку Atlassian использует модель «ПО как услуга» (SaaS).

6.03.05.

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

6.03.05. (a)

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

Это неприменимо, поскольку Atlassian использует модель «ПО как услуга» (SaaS).

6.03.05. (b)

Как поставщик PaaS может гарантировать, что доступ к вашим данным предоставляется только корпоративным пользователям и принадлежащим вам приложениям?

Это неприменимо, поскольку Atlassian использует модель «ПО как услуга» (SaaS).

6.03.05. (c)

Архитектура платформы должна быть классической «песочницей». Осуществляет ли поставщик мониторинг «песочницы» платформы PaaS на предмет новых ошибок и уязвимостей?

Это неприменимо, поскольку Atlassian использует модель «ПО как услуга» (SaaS).

6.03.05. (d)

Поставщики PaaS должны предлагать набор функций безопасности (для многократного использования клиентами). Входят ли в их число аутентификация пользователей, система единого входа, авторизация (управление правами доступа) и протоколы SSL/TLS (доступные через API)?

Это неприменимо, поскольку Atlassian использует модель «ПО как услуга» (SaaS).

6.03.06.

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

6.03.06. (a)

Какие средства администрирования предусмотрены и можно ли их использовать для назначения другим пользователям прав на чтение или запись.

Клиенты продуктов Enterprise и Premium Cloud имеют доступ к централизованной панели администрирования. Администраторы организации могут управлять доступом и правами пользователей во всех экземплярах продуктов. См. запись в блоге: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Клиенты Atlassian могут использовать выбранного ими стороннего поставщика учетных данных, если он поддерживается Atlassian. Эти возможности и способ подключения выбранного поставщика учетных данных подробно описаны на странице поддержки Atlassian: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.06. (b)

Детализировано ли управление доступом в SaaS и можно ли его настроить в соответствии с политикой организации?

Клиенты продуктов Enterprise и Premium Cloud имеют доступ к централизованной панели администрирования. Администраторы организации могут управлять доступом и правами пользователей во всех экземплярах продуктов. См. запись в блоге: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Клиенты Atlassian могут использовать выбранного ими стороннего поставщика учетных данных, если он поддерживается Atlassian. Эти возможности и способ подключения выбранного поставщика учетных данных подробно описаны на странице поддержки Atlassian: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.07. (a)

При возникновении перегрузки ресурсов (обработки, памяти, хранилища, сети):

• Какая информация об относительном приоритете запроса предоставляется в случае невозможности выделить ресурсы?
• Существуют ли какие-то сроки по уровням обслуживания и изменениям требований?
<

Компания Atlassian планирует доступность ресурсов на 6–12 месяцев вперед, а ее горизонт общего стратегического планирования составляет 36 месяцев.

Atlassian собирает аналитику по горизонтально масштабируемой облачной архитектуре AWS и Azure и использует эти данные при разработке для совершенствования продуктов Atlassian. Однако в настоящее время эти данные клиентам не предоставляются.

6.03.07. (b)

Насколько можно увеличить масштаб? Предоставляет ли поставщик гарантии максимального количества доступных ресурсов в течение минимального периода времени?

Компания Atlassian планирует доступность ресурсов на 6–12 месяцев вперед, а ее горизонт общего стратегического планирования составляет 36 месяцев.

Atlassian собирает аналитику по горизонтально масштабируемой облачной архитектуре AWS и Azure и использует эти данные при разработке для совершенствования продуктов Atlassian. Однако в настоящее время эти данные клиентам не предоставляются.

6.03.07. (c)

Как быстро можно увеличить масштаб? Предоставляет ли поставщик гарантии доступности дополнительных ресурсов в течение минимального периода времени?

Компания Atlassian планирует доступность ресурсов на 6–12 месяцев вперед, а ее горизонт общего стратегического планирования составляет 36 месяцев.

Atlassian собирает аналитику по горизонтально масштабируемой облачной архитектуре AWS и Azure и использует эти данные при разработке для совершенствования продуктов Atlassian. Однако в настоящее время эти данные клиентам не предоставляются.

6.03.07. (d)

Предусмотрены ли процессы, которые позволяют справиться со значительными изменениями в использовании ресурсов (например, сезонными колебаниями)?

Компания Atlassian планирует доступность ресурсов на 6–12 месяцев вперед, а ее горизонт общего стратегического планирования составляет 36 месяцев.

Atlassian собирает аналитику по горизонтально масштабируемой облачной архитектуре AWS и Azure и использует эти данные при разработке для совершенствования продуктов Atlassian. Однако в настоящее время эти данные клиентам не предоставляются.

6.04.01.

Следующие элементы управления относятся к системам поставщика облачных услуг, предназначенным для управления учетными данными и доступом (и находящимся под его контролем).

6.04.01. (a)

Имеются ли аккаунты с правами на уровне всей облачной системы и если да, то для каких операций (чтение/запись/удаление)?

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

6.04.01. (b)

Как происходит аутентификация аккаунтов с максимальным уровнем доступа и управление ими?

Atlassian ограничивает круг сотрудников, которым необходим этот уровень доступа для выполнения должностных обязанностей. Для управления всеми системами 1-го уровня используется централизованное решение Atlassian, в рамках которого реализована система единого входа (SSO) и каталоги пользователей. Пользователям предоставляются права доступа на основании этих профилей, которые формируются рабочим процессом в нашей системе управления кадрами. Для доступа ко всем системам 1-го уровня используется многофакторная аутентификация. Для доступа к консоли управления гипервизором и к API AWS нужно пройти двухфакторную аутентификацию. Кроме того, ежедневно составляется отчет о проверке, в котором содержатся данные обо всех случаях доступа к функциям управления гипервизором. Списки доступа к консоли управления гипервизором и API AWS пересматриваются ежеквартально. Синхронизация между системой управления кадрами и хранилищем учетных данных происходит каждые 8 часов.

6.04.01. (c)

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

Atlassian ограничивает круг сотрудников, которым необходим этот уровень доступа для выполнения должностных обязанностей. Для управления всеми системами 1-го уровня используется централизованное решение Atlassian, в рамках которого реализована система единого входа (SSO) и каталоги пользователей. Пользователям предоставляются права доступа на основании этих профилей, которые формируются рабочим процессом в нашей системе управления кадрами. Для доступа ко всем системам 1-го уровня используется многофакторная аутентификация. Для доступа к консоли управления гипервизором и к API AWS нужно пройти двухфакторную аутентификацию. Кроме того, ежедневно составляется отчет о проверке, в котором содержатся данные обо всех случаях доступа к функциям управления гипервизором. Списки доступа к консоли управления гипервизором и API AWS пересматриваются ежеквартально. Синхронизация между системой управления кадрами и хранилищем учетных данных происходит каждые 8 часов.

В наших основных продуктах предусмотрены средства контроля за разделением обязанностей, в том числе:

• Проверка средств управления доступом
• Группы безопасности, которые контролирует приложение по управлению персоналом
• Подтверждение, оценка и реализация изменений (PRGB)
• Средства управления рабочим процессом

6.04.01. (d)

Назначаются ли роли с правами высокого уровня одному и тому же человеку? Нарушается ли при таком назначении распределение обязанностей или правило минимальных привилегий?

Atlassian ограничивает круг сотрудников, которым необходим этот уровень доступа для выполнения должностных обязанностей. Для управления всеми системами 1-го уровня используется централизованное решение Atlassian, в рамках которого реализована система единого входа (SSO) и каталоги пользователей. Пользователям предоставляются права доступа на основании этих профилей, которые формируются рабочим процессом в нашей системе управления кадрами. Для доступа ко всем системам 1-го уровня используется многофакторная аутентификация. Для доступа к консоли управления гипервизором и к API AWS нужно пройти двухфакторную аутентификацию. Кроме того, ежедневно составляется отчет о проверке, в котором содержатся данные обо всех случаях доступа к функциям управления гипервизором. Списки доступа к консоли управления гипервизором и API AWS пересматриваются ежеквартально. Синхронизация между системой управления кадрами и хранилищем учетных данных происходит каждые 8 часов.

В наших основных продуктах предусмотрены средства контроля за разделением обязанностей, в том числе:

• Проверка средств управления доступом
• Группы безопасности, которые контролирует приложение по управлению персоналом
• Подтверждение, оценка и реализация изменений (PRGB)
• Средства управления рабочим процессом

6.04.01. (e)

Используете ли вы управление доступом на основе ролей (RBAC)? Соблюдается ли принцип минимальных привилегий?

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

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

6.04.01. (f)

Какие изменения (если это предусмотрено) вносятся в права и роли администраторов в экстренных ситуациях для предоставления чрезвычайного доступа?

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

6.04.01. (g)

Предусмотрена ли для клиента роль администратора? Например, может ли клиент-администратор участвовать в добавлении новых пользователей (без права изменять базовую систему хранения!)?

В Atlassian для клиентов предусмотрена роль администратора организации, который управляет пользователями и группами в продуктах клиента. Подробнее см. на странице https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.02. (a)

Какие проверки личности пользователей проводятся при регистрации их аккаунтов? Соблюдаются ли какие-либо стандарты? Например, стандарты взаимодействия электронного правительства (e-GIF)?

• Существуют ли разные уровни проверок личности в зависимости от требуемых ресурсов?

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

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

6.04.02. (b)

Какие процессы предусмотрены для отзыва учетных данных?

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

6.04.02. (c)

Происходит ли предоставление и отзыв учетных данных одновременно во всей облачной системе, или же при отзыве учетных данных в нескольких географически распределенных местах возникают риски?

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

Наше приложение по управлению персоналом синхронизируется с внутренним хранилищем учетных данных каждые 8 часов и удаляет все аккаунты сотрудников и подрядчиков, которые больше не работают в компании.

6.04.03. (a)

Какие средства управления хранением и защитой данных (например AD, LDAP) применяются к каталогу пользователей и как предоставляется доступ к нему?

Данные классифицируются и обрабатываются в соответствии с нашей политикой жизненного цикла информации и безопасности данных, и на ее основе реализуются механизмы контроля. Подробнее см. на странице https://www.atlassian.com/trust/security/security-practices

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

Ряд продуктов Atlassian сертифицирован по стандартам ISO, что требует регулярной оценки рисков и пересмотра политик обработки данных.

С нашей оценкой последствий передачи данных можно ознакомиться на странице https://www.atlassian.com/legal/data-transfer-impact-assessment

Компания Atlassian придерживается стандарта по хранению и уничтожению данных, в котором определены сроки хранения данных разных типов. Данные классифицируются в соответствии с политикой безопасности данных и жизненного цикла информации Atlassian, и на ее основе реализуются механизмы контроля.

При прекращении действия договора с Atlassian данные, принадлежащие команде клиента, будут удалены из рабочей базы данных, а все вложенные файлы, загруженные непосредственно в системы Atlassian, будут удалены в течение 14 дней. Данные команды будут храниться в зашифрованных резервных копиях до истечения 90-дневного периода хранения резервных копий, после чего они будут уничтожены в соответствии с политикой хранения данных Atlassian. Если в течение 90 дней после запрошенного удаления данных потребуется восстановить базу данных, операционная команда повторно удалит данные в разумно возможный кратчайший срок после того, как рабочая система будет полностью восстановлена. Подробнее см. на странице https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.04.03. (b)

Можно ли экспортировать данные каталога пользователей в формате, с которым можно взаимодействовать?

Администраторы могут экспортировать каталог пользователей с панели администратора. См. руководства на сайте поддержки Atlassian: https://support.atlassian.com/organization-administration/docs/export-users-from-a-site/

6.04.03. (c)

Использует ли поставщик облачных услуг принцип минимальной осведомленности как основу для предоставления доступа к данным клиентов?

Atlassian ограничивает круг сотрудников, которым необходим этот уровень доступа для выполнения должностных обязанностей. Для управления всеми системами 1-го уровня используется централизованное решение Atlassian, в рамках которого реализована система единого входа (SSO) и каталоги пользователей. Пользователям предоставляются права доступа на основании этих профилей, которые формируются рабочим процессом в нашей системе управления кадрами. Для доступа ко всем системам 1-го уровня используется многофакторная аутентификация. Для доступа к консоли управления гипервизором и к API AWS нужно пройти двухфакторную аутентификацию. Кроме того, ежедневно составляется отчет о проверке, в котором содержатся данные обо всех случаях доступа к функциям управления гипервизором. Списки доступа к консоли управления гипервизором и API AWS пересматриваются ежеквартально. Синхронизация между системой управления кадрами и хранилищем учетных данных происходит каждые 8 часов.

В наших основных продуктах предусмотрены средства контроля за разделением обязанностей, в том числе:

• Проверка средств управления доступом
• Группы безопасности, которые контролирует приложение по управлению персоналом
• Подтверждение, оценка и реализация изменений (PRGB)
• Средства управления рабочим процессом

6.04.04.

В отношении ключей, находящихся под контролем поставщика облачных услуг:

6.04.04. (a)

Предусмотрены ли средства обеспечения безопасности при чтении и записи ключей? Например, политики надежных паролей, хранение ключей в отдельной системе, модули аппаратной защиты (HSM) для ключей корневых сертификатов, аутентификация на основе смарт-карт, прямой экранированный доступ к хранилищу, короткий срок действия ключей и т. д.

В Atlassian разработана и поддерживается политика шифрования и криптографии, а также рекомендации по ее внедрению. Эта политика ежегодно пересматривается и обновляется в соответствии с нашей Программой управления политиками (PMP). Подробнее см. на странице https://www.atlassian.com/trust/security/security-management-program.

В Atlassian разработаны и поддерживаются документированные процедуры управления ключами для облачной инфраструктуры. Ключами шифрования для вложений Amazon, хранящихся в S3, управляет служба KMS Amazon. Процесс шифрования, управления ключами и дешифрования регулярно проверяется и контролируется компанией Amazon в рамках существующего процесса аудита. При изменении ролей или статуса занятости сотрудников ключи Atlassian ротируются. Служба KMS AWS соответствует требованиям SOC 1, SOC 2 и SOC 3. Подробнее см. на странице https://aws.amazon.com/kms/

6.04.04. (b)

Предусмотрены ли средства обеспечения безопасности при использовании ключей для подписи и шифрования данных?

В Atlassian разработаны и поддерживаются документированные процедуры управления ключами для облачной инфраструктуры. Ключами шифрования для вложений Amazon, хранящихся в S3, управляет служба KMS Amazon. Процесс шифрования, управления ключами и дешифрования регулярно проверяется и контролируется компанией Amazon в рамках существующего процесса аудита. Главные ключи в KMS после их создания обеспечивают автоматическую ротацию и генерацию материала главного ключа каждые 365 дней (ежегодно).

6.04.04. (c)

Предусмотрены ли процедуры на случай раскрытия ключа? Например, списки для отзыва ключей.

В Atlassian разработаны и поддерживаются документированные процедуры управления ключами для облачной инфраструктуры. Ключами шифрования для вложений Amazon, хранящихся в S3, управляет служба KMS Amazon. Процесс шифрования, управления ключами и дешифрования регулярно проверяется и контролируется компанией Amazon в рамках существующего процесса аудита. При изменении ролей или статусов сотрудников ключи Atlassian ротируются. Служба KMS AWS соответствует требованиям SOC 1, SOC 2 и SOC 3. Подробнее см. на странице https://aws.amazon.com/kms/

6.04.04. (c)

Предусмотрены ли процедуры на случай раскрытия ключа? Например, списки для отзыва ключей.

В Atlassian разработаны и поддерживаются документированные процедуры управления ключами для облачной инфраструктуры. Ключами шифрования для вложений Amazon, хранящихся в S3, управляет служба KMS Amazon. Процесс шифрования, управления ключами и дешифрования регулярно проверяется и контролируется компанией Amazon в рамках существующего процесса аудита. При изменении ролей или статусов сотрудников ключи Atlassian ротируются. Служба KMS AWS соответствует требованиям SOC 1, SOC 2 и SOC 3. Подробнее см. на странице https://aws.amazon.com/kms/

6.04.04. (d)

Может ли отзыв ключа решить проблему одновременности для нескольких сайтов?

В Atlassian разработаны и поддерживаются документированные процедуры управления ключами для облачной инфраструктуры. Ключами шифрования для вложений Amazon, хранящихся в S3, управляет служба KMS Amazon. Процесс шифрования, управления ключами и дешифрования регулярно проверяется и контролируется компанией Amazon в рамках существующего процесса аудита. При изменении ролей или статусов сотрудников ключи Atlassian ротируются. Служба KMS AWS соответствует требованиям SOC 1, SOC 2 и SOC 3. Подробнее см. на странице https://aws.amazon.com/kms/

6.04.04. (e)

Образы клиентских систем защищены или зашифрованы?

Atlassian использует являющийся отраслевым стандартом протокол Transport Layer Security (TLS) версии 1.2 для создания защищенного соединения, а также 256-битное шифрование по алгоритму Advanced Encryption Standard (AES). На серверах, где хранятся данные пользователей, используется стандартное полнодисковое шифрование по алгоритму AES. Данные держателей шифруются в резервных копиях AWS RDS или RDS, а также шифруются в долгосрочном хранилище (S3) вместе со всеми вложениями. Подробнее см. на странице https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management

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

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

При хранении мы, в частности, шифруем хранящиеся на диске данные клиентов, например данные о задачах Jira (подробности, комментарии, вложения) или данные страниц Confluence (содержимое страниц, комментарии, вложения). Шифрование данных при хранении помогает защитить их от несанкционированного доступа и обеспечивает доступ к данным только авторизованным ролям и сервисам с контролируемым доступом к ключам шифрования.

6.04.05. (a)

Шифрование может применяться в различных местах. Где оно используется?

• При передаче данных?
• При хранении данных?
• Для данных в процессоре или памяти?

В Atlassian разработана и поддерживается политика шифрования и криптографии, а также рекомендации по ее внедрению. Эта политика ежегодно пересматривается и обновляется в соответствии с нашей Программой управления политиками (PMP). Подробнее см. на странице https://www.atlassian.com/trust/security/security-management-program .

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

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

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

При хранении мы, в частности, шифруем хранящиеся на диске данные клиентов, например данные о задачах Jira (подробности, комментарии, вложения) или данные страниц Confluence (содержимое страниц, комментарии, вложения). Шифрование данных при хранении помогает защитить их от несанкционированного доступа и обеспечивает доступ к данным только авторизованным ролям и сервисам с контролируемым доступом к ключам шифрования.

6.04.05. (b)

Существует ли четко определенная политика в отношении того, что следует шифровать, а что нет?

В Atlassian разработана и поддерживается политика шифрования и криптографии, а также рекомендации по ее внедрению. Эта политика ежегодно пересматривается и обновляется в соответствии с нашей Программой управления политиками (PMP). Подробнее см. на странице https://www.atlassian.com/trust/security/security-management-program.

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

6.04.05. (d)

У кого есть ключи доступа?

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

6.04.05. (e)

Как защищены ключи?

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

6.04.06. (a)

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

• Используется ли двухфакторная аутентификация для управления критическими компонентами инфраструктуры, такими как брандмауэры и т. п.?

Мы следуем рекомендациям, изложенным в специальной публикации NIST 800-63B. См.: https://pages.nist.gov/800-63-3/sp800-63b.html

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

В более широком контексте меры контроля доступа описаны в Политике управления доступом, выдержка из которой доступна здесь: https://www.atlassian.com/trust/security/ismp-policies

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

В Atlassian ограничен круг сотрудников, которым необходим этот уровень доступа для выполнения работы и исполнения обязанностей. Для управления всеми системами 1-го уровня используется централизованное решение Atlassian, за счет которого реализована система единого входа (SSO) и каталоги пользователей. Пользователям предоставляются права доступа на основании этих профилей, которые формируются рабочим процессом в нашей системе управления кадрами. Для доступа ко всем системам 1-го уровня используется многофакторная аутентификация. Для доступа к консоли управления гипервизором и API AWS нужно пройти двухфакторную аутентификацию. Кроме того, ежедневно составляется отчет о проверке, в котором содержатся данные обо всех случаях получения доступа к функциям управления гипервизором. Списки доступа к консоли управления гипервизором и API AWS пересматриваются ежеквартально. Синхронизация между системой управления кадрами и хранилищем учетных данных происходит каждые 8 часов.

6.04.07. (a)

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

Лишь очень небольшая область платформы Atlassian Cloud открыта для доступа через брандмауэры. Мы периодически пересматриваем правила брандмауэров. В наших офисах и в облачной среде размещения развернута система обнаружения вторжений (IDS). На платформе Atlassian Cloud функция пересылки журналов встроена в платформу аналитики безопасности. На уровне контейнеров облачной платформы целостность файлов сохраняется, поскольку экземпляры нельзя изменять. Команда по проектированию сетей Atlassian использует технологии предотвращения вторжений (IPS), встроенные в наши брандмауэры, а в офисных и облачных средах внедрены технологии обнаружения вторжений (IDS). Возможности противодействия DDoS-атакам предоставляются нашим интернет-провайдером / оператором связи.

Основные системные журналы передаются из каждой системы на централизованную платформу журналов, причем журналы доступны только для чтения. Команда по обеспечению безопасности Atlassian создает оповещения на нашей платформе аналитики безопасности (Splunk) и отслеживает признаки угрозы. Наши команды по обеспечению надежности используют эту платформу, чтобы отслеживать проблемы, влияющие на доступность или производительность. Журналы хранятся в течение 30 дней в архивах «горячего» резервирования и в течение 365 дней в архивах «холодного» резервирования.

6.04.07. (b)

Какие условия предусмотрены на случай кражи учетных данных клиента (обнаружение, отзыв, доказательства для действий)?

В контексте облачных сервисов Atlassian наши клиенты могут нести ответственность за некоторые или все аспекты управления доступом для подконтрольных им пользователей сервисов.

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

Atlassian не предоставляет систем предотвращения потери данных (DLP) непосредственно в рамках облачных развертываний. Однако в Atlassian Marketplace есть поставщики, такие как Nightfall, которых Atlassian рекомендует клиентам, желающим получить возможность DLP. Посмотреть страницу продукта Nightfall в Marketplace можно здесь: https://marketplace.atlassian.com/vendors/1217783/nightfall. Nightfall включает автоматическое сканирование конфиденциальной информации, включая учетные данные, секретные коды и ключи API.

Компания Atlassian выпустила бета-версию продукта Beacon, который предоставляет функции DLP. До выхода Beacon из бета-версии Atlassian по-прежнему рекомендует использовать Nightfall. Дополнительную информацию об Atlassian Beacon можно найти на странице https://www.atlassian.com/software/beacon.

У нас есть документированная политика и план реагирования на инциденты безопасности, ключевые принципы которых включают:

• Прогнозирование инцидентов безопасности и подготовка к реакции на инциденты.
• Сдерживание последствий инцидентов, их устранение и восстановление систем.
• Принятие мер, направленных на то, чтобы наши сотрудники, процессы и технологии были полностью готовы к выявлению и анализу инцидентов безопасности в случае их возникновения
• Защита персональных данных и данных клиентов становится нашей главной задачей во время инцидентов безопасности.
• Регулярная проверка процедуры реакции на инциденты безопасности.
• Мы накапливаем опыт и совершенствуем все функции, связанные с управлением инцидентами безопасности
• Мы информируем руководящую группу Atlassian о критических инцидентах безопасности.

6.04.08.

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

6.04.08.01. (a)

Позволяет ли система создать федеративную инфраструктуру IDM, совместимую как с высоким уровнем надежности (системы OTP при необходимости), так и с низким уровнем надежности (например, имя пользователя и пароль)?

Atlassian Access поддерживает единые стандарты учетных данных во всех наших продуктах Atlassian (Confluence, Jira, Jira Align, Bitbucket и т. д.). Atlassian Access может автоматически синхронизировать каталог Active Directory с Atlassian с помощью Okta, Azure AD или Onelogin. Подробнее см. на странице https://www.atlassian.com/enterprise/cloud/access. Настройка единого входа для конкретных продуктов (общая версия SAML 2.0, Google, Okta, OneLogin, PingIdentity, ADFS):

• Opsgenie поддерживает несколько поставщиков SSO. Подробнее см. на странице https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• Trello поддерживает несколько поставщиков SSO. Подробнее см. на странице https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• Statuspage поддерживает несколько поставщиков SSO. Подробнее см. на странице: https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.04.08.01. (b)

Совместим ли поставщик облачных услуг со сторонними поставщиками идентификационных данных?

Клиенты Atlassian могут использовать выбранного ими стороннего поставщика учетных данных, если он поддерживается Atlassian. Эти возможности и способ подключения выбранного поставщика учетных данных подробно описаны на странице поддержки Atlassian: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.04.08.01. (c)

Есть ли возможность внедрить систему единого входа?

Для аутентификации в большинстве продуктов Atlassian можно использовать учетные данные Google, Microsoft и Apple. Для облачных сервисов Atlassian также реализована поддержка SAML — за счет подписки Atlassian Access. Подробнее о ней см. на странице https://www.atlassian.com/enterprise/cloud/access.

6.04.08.02. (a)

Позволяет ли система учетных данных клиентов разделять роли и обязанности и использовать несколько доменов (или один ключ для нескольких доменов, ролей и обязанностей)?

Atlassian — это SaaS-приложение, рассчитанное на множество держателей. Архитектура с несколькими держателями является ключевой особенностью Atlassian Cloud, которая позволяет нескольким клиентам совместно использовать один экземпляр уровня приложений Jira или Confluence, изолируя при этом данные приложений каждого держателя. Atlassian Cloud решает эту задачу с помощью службы контекста держателей (TCS). Каждый идентификатор пользователя, используемый для доступа к приложениям Atlassian Cloud, связан ровно с одним держателем. Подробнее см. на странице https://www.atlassian.com/trust/security/security-practices#tenant-isolation.

Клиенты продуктов Enterprise и Premium Cloud имеют доступ к централизованной панели администрирования. Администраторы организации могут управлять доступом и правами пользователей во всех экземплярах продуктов. См. запись в блоге: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

В Atlassian для клиентов предусмотрена роль администратора организации, который управляет пользователями и группами в продуктах клиента. Подробнее см. на странице https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.08.02. (b)

Как вы управляете доступом к образам клиентских систем и гарантируете, что в них не содержатся аутентификационные и криптографические ключи?

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

6.04.08.03. (a)

Как поставщик облачных услуг идентифицирует себя для клиента (например, существует ли взаимная аутентификация)?

• Когда клиент отправляет команды API?
• Когда клиент входит в интерфейс управления?

Atlassian использует взаимную аутентификацию, чтобы идентифицировать себя для клиента. Документация по API Atlassian доступна по ссылке https://developer.atlassian.com/cloud/. Протокол аутентификации служб Atlassian (ASAP) — это протокол аутентификации между сервисами, в котором используется маркер доступа, реализованный с помощью JSON Web Token (JWT) и подписанный с использованием ключей RSA от доверенного центра Atlassian. Подробнее см. в разделе Протокол аутентификации служб Atlassian. Мы не используем «служебные аккаунты» в традиционном понимании. Мы полагаемся на аутентификацию и авторизацию между сервисами.

6.04.08.03. (b)

Поддерживаете ли вы федеративный механизм аутентификации?

Atlassian Access поддерживает единые стандарты учетных данных во всех наших продуктах Atlassian (Confluence, Jira, Jira Align, Bitbucket и т. д.). Atlassian Access может автоматически синхронизировать каталог Active Directory с Atlassian с помощью Okta, Azure AD или Onelogin. Подробнее см. на странице https://www.atlassian.com/enterprise/cloud/access. Настройка единого входа для конкретных продуктов (общая версия SAML 2.0, Google, Okta, OneLogin, PingIdentity, ADFS):

• Opsgenie поддерживает несколько поставщиков SSO. Подробнее см. на странице https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• Trello поддерживает несколько поставщиков SSO. Подробнее см. на странице https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• Statuspage поддерживает несколько поставщиков SSO. Подробнее см. на странице: https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.05.

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

6.05. (a)

Есть ли у поставщика автоматизированные средства инвентаризации всех активов, которые облегчают надлежащее управление ими?

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

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

6.05. (b)

Есть ли список активов, которые клиент использовал в течение определенного периода времени?

Atlassian — это многопользовательское SaaS-приложение. Архитектура с несколькими держателями является ключевой особенностью Atlassian Cloud, которая позволяет нескольким клиентам совместно использовать один экземпляр уровня приложений Jira или Confluence, изолируя при этом данные приложений каждого держателя. Atlassian Cloud решает эту задачу с помощью службы контекста держателей (TCS). Каждый идентификатор пользователя связан ровно с одним держателем, который затем используется для доступа к приложениям Atlassian Cloud. Подробнее см. на странице https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Следующие вопросы следует использовать, когда конечный клиент развертывает данные, требующие дополнительной защиты (например, считающиеся конфиденциальными).

6.05. (c)

Классифицируются ли активы по степени конфиденциальности и критичности?

• Если да, то применяет ли поставщик надлежащее разделение между системами с различной классификацией и для одного клиента, у которого есть системы с различной классификацией безопасности?

Atlassian поддерживает 4-уровневый рейтинг наших ресурсов и служб. Для каждого уровня установлены требования ко времени безотказной работы, уровню обслуживания и непрерывности. Подробнее см. по ссылке https://www.atlassian.com/trust/security/data-management.

6.06.

Этот набор вопросов следует рассмотреть, чтобы понять риски, связанные с привязкой к поставщику.

6.06. (a)

Существуют ли документированные процедуры и API для экспорта данных из облака?

Доступ к данным клиентов можно получить через веб-приложение и API. Подробная информация о конкретных продуктах приведена ниже.

• Confluence, Jira и Jira Align: подробную информацию об API Atlassian можно найти на странице https://developer.atlassian.com/cloud/jira/platform/rest/v3/
• Trello: все участники доски могут экспортировать данные доски в формате JSON через REST API для Trello. Прикрепленные файлы можно получить по отдельности непосредственно из Amazon S3, используя уникальную гиперссылку на файл. Версии Trello Business Class и Enterprise предлагают упрощенный процесс экспорта данных для всех данных и вложений организации. Для каждой организации в Business Class и Enterprise включен экспорт всех досок организации одним нажатием. При желании в файл экспорта можно включить прикрепленные файлы, загруженные непосредственно в Trello. При экспорте данные каждой доски включены как в формате JSON, так и в формате CSV.
• Opsgenie: API можно найти на странице https://docs.opsgenie.com/docs/api-overview
• Statuspage: API можно найти на странице https://doers.statuspage.io/api/v1/
• Bitbucket: любой исходный код или репозиторий можно загрузить или экспортировать из Bitbucket для целей совместимости. См.: https://confluence.atlassian.com/bitbucket/does-bitbucket-backup-my-repositories-288658413.html
• Halp: есть функция экспорта в формате CSV. Дополнительную документацию можно найти здесь: https://plz.halp.com/article/5790zlyrun-export-to-csv

6.06. (b)

Предоставляет ли поставщик совместимые форматы экспорта для всех данных, хранящихся в облаке?

Atlassian помогает клиентам с запросами на экспорт принадлежащих им данных, если данные размещаются в составе продуктов Atlassian. Доступные надежные инструменты обеспечения переносимости данных и управления ими позволяют экспортировать данные продуктов и пользователей. Узнать больше об экспорте данных Atlassian Cloud можно из нашей документации по импорту и экспорту: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Дополнительные сведения об экспорте данных в распространенные форматы, такие как CSV, HTML и XML: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/.

6.06. (c)

Стандартизированы ли используемые интерфейсы API в случае SaaS?

Подробную информацию о наших API Atlassian Cloud можно найти здесь: https://developer.atlassian.com/explore-the-apis/

Сведения об API конкретных продуктов:

• Trello: документация по API доступна на странице https://developer.atlassian.com/cloud/trello
• Jira Align: API можно найти на странице https://help.jiraalign.com/hc/en-us/articles/360045371954-Getting-started-with-the-REST-API-2-0
• Statuspage: API можно найти на странице https://doers.statuspage.io/api/v1
• Opsgenie: API можно найти на странице https://docs.opsgenie.com/docs/api-overview
• Halp: в настоящее время нет публичного API.

6.06. (d)

Предусмотрен ли экспорт созданных пользователем приложений в стандартном формате?

Это неприменимо, поскольку Atlassian использует модель «ПО как услуга» (SaaS).

6.06. (e)

Существуют ли процедуры, чтобы проверить возможность экспорта данных другому поставщику облачных услуг — например, если клиент захочет сменить поставщика?

Atlassian помогает клиентам с запросами на экспорт принадлежащих им данных, если данные размещаются в составе продуктов Atlassian. Доступные надежные инструменты обеспечения переносимости данных и управления ими позволяют экспортировать данные продуктов и пользователей. Узнать больше об экспорте данных Atlassian Cloud можно из нашей документации по импорту и экспорту: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Дополнительные сведения об экспорте данных в распространенные форматы, такие как CSV, HTML и XML: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/.

6.06. (f)

Может ли клиент самостоятельно извлечь данные, чтобы убедиться в универсальности формата и возможности его переноса к другому поставщику облачных услуг?

Atlassian помогает клиентам с запросами на экспорт принадлежащих им данных, если данные размещаются в составе продуктов Atlassian. Доступные надежные инструменты обеспечения переносимости данных и управления ими позволяют экспортировать данные продуктов и пользователей. Узнать больше об экспорте данных Atlassian Cloud можно из нашей документации по импорту и экспорту: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Дополнительные сведения об экспорте данных в распространенные форматы, такие как CSV, HTML и XML: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/.

6.07.

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

6.07. (a)

Использует ли поставщик документированный метод, подробно описывающий последствия сбоев?

• Каковы целевая точка восстановления (RPO) и целевое время восстановления (RTO) для служб? Опишите подробнее в зависимости от значимости службы.
• Уделяется ли должное внимание мероприятиям по обеспечению информационной безопасности в процессе восстановления?
• Каковы каналы связи с конечными клиентами в случае сбоев?
• Четко ли определены роли и обязанности команд при работе со сбоями?

В компании действует политика непрерывности бизнеса и аварийного восстановления, а также план по обеспечению непрерывности бизнеса и аварийному восстановлению, который ежегодно пересматривается руководящим комитетом по обеспечению непрерывности бизнеса и аварийного восстановления. Более подробную информацию (в том числе в отношении RPO, RTO и отказоустойчивости за счет использования зон доступности) можно найти на страницах https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management и https://www.atlassian.com/trust/security/data-management.

Соответствие требованиям центров обработки данных наших партнеров подтверждается множеством сертификатов. Они касаются физической защиты, доступности системы, доступа к сети и IP-магистрали, создания пользователей и управления проблемами. Доступ к центрам обработки данных осуществляется только уполномоченным персоналом после биометрической аутентификации. Меры физической защиты включают охрану на местах, видеонаблюдение, шлюзовые кабины и дополнительные меры защиты от вторжений. Подробнее об обеспечении физической защиты AWS см. на странице http://aws.amazon.com/compliance/

6.07. (b)

Классифицировал ли поставщик приоритет восстановления и каков будет наш (как конечного клиента) относительный приоритет на восстановление? Примечание. Это может быть категория (например, высокий/средний/низкий).

Владельцы критически важных для бизнеса систем, процессов и сервисов в полной мере реализуют непрерывную работу и (или) аварийное восстановление, которое соответствует должной отказоустойчивости на случай аварии. Планы BCDR проверяются ежеквартально. Все выявленные проблемы устраняются. Подробнее см. на странице https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management и https://www.atlassian.com/trust/security/data-management.

6.07. (c)

Какие существуют зависимости, которые относятся к процессу восстановления? Включите поставщиков и партнеров по аутсорсингу.

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

6.07. (d)

Если основной сайт недоступен, насколько близко к нему может располагаться дополнительный сайт?

Соответствие требованиям центров обработки данных наших партнеров подтверждается множеством сертификатов. Они касаются физической защиты, доступности системы, доступа к сети и IP-магистрали, создания пользователей и управления проблемами. Доступ к центрам обработки данных осуществляется только уполномоченным персоналом после биометрической аутентификации. Меры физической защиты включают охрану на местах, видеонаблюдение, шлюзовые кабины и дополнительные меры защиты от вторжений. Подробнее об обеспечении физической защиты AWS см. на странице http://aws.amazon.com/compliance/

6.07.01.

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

6.07.01. (a)

Есть ли у поставщика официальный процесс для обнаружения, идентификации, анализа инцидентов и реагирования на них?

Мы располагаем документированной политикой и планом реагирования на инциденты безопасности, ключевые принципы которых включают:

• Прогнозирование инцидентов безопасности и подготовка к реакции на инциденты.
• Сдерживание последствий инцидентов, их устранение и восстановление систем.
• Принятие мер, направленных на то, чтобы наши сотрудники, процессы и технологии были полностью готовы к выявлению и анализу инцидентов безопасности в случае их возникновения.
• Защита персональных данных и данных клиентов становится нашей главной задачей во время инцидентов безопасности.
• Регулярная проверка процедуры реакции на инциденты безопасности.
• Мы накапливаем опыт и совершенствуем все функции, связанные с управлением инцидентами безопасности
• Мы информируем руководящую группу Atlassian о критических инцидентах безопасности.


В соответствии с этой политикой Atlassian придерживается плана реагирования на инциденты безопасности. Узнать больше о нашей процедуре реагирования на инциденты безопасности можно по ссылке сайте: https://www.atlassian.com/trust/security/security-incident-management

Основные системные журналы передаются из каждой системы на централизованную платформу журналов, причем журналы доступны только для чтения. Команда по обеспечению безопасности Atlassian создает оповещения на нашей платформе аналитики безопасности (Splunk) и отслеживает признаки угрозы. Наши команды по обеспечению надежности используют эту платформу, чтобы отслеживать проблемы, влияющие на доступность или производительность. Журналы хранятся в течение 30 дней в архивах «горячего» резервирования и в течение 365 дней в архивах «холодного» резервирования.

Подробнее о нашей программе поддержки безопасности см. на странице https://www.atlassian.com/trust/security/detections-program

6.07.01. (b)

Отрабатывается ли эта процедура, чтобы проверить эффективность процессов обработки инцидентов? Обеспечивает ли поставщик в ходе такой отработки осведомленность всех сотрудников службы поддержки поставщика облачных услуг о процессе и их роли в ходе обработки инцидента (как во время инцидента, так и после его анализа)?

Мы ежеквартально тестируем облачные сервисы Atlassian, официальные планы обеспечения непрерывности бизнеса и аварийного восстановления. Доступность в разных регионах отслеживается в реальном времени. Каждую неделю в среде для подготовки к релизу проводятся автоматические проверки аварийного переключения в регионах. Проверки автоматизированного восстановления конфигурационных данных проводятся ежедневно в процессе работы. Все сервисы Atlassian ежеквартально проводят тестирование отказоустойчивости в зоне доступности в среде для подготовки к релизу. Дополнительную информацию о нашей программе непрерывности бизнеса см. на странице https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Наши планы аварийного восстановления протестированы и утверждены внешними аудиторами в рамках нашей Программы соответствия требованиям. Подробнее см. на странице https://www.atlassian.com/trust/compliance/resources

Мы отработали план реагирования на инциденты безопасности в реальном времени. Мы постоянно совершенствуем и оптимизируем наши возможности реагирования.

После разрешения инцидента высокого уровня опасности 1 или 2 исходная заявка об инциденте закрывается, и начинается анализ результатов реагирования на инцидент (PIR). В случае инцидентов высокого уровня опасности команда по обеспечению безопасности проводит анализ основных причин и предлагает возможные улучшения системы и (или) способы решения проблемы.

6.07.01. (c)

Как выглядит структура возможностей обнаружения?

• Как клиент облачных услуг может сообщать поставщику об аномалиях и событиях безопасности?
• Какие возможности поставщик предоставляет сторонним службам RTSM, выбранным клиентом, для вмешательства в их системы (при необходимости) или для координации возможностей реагирования на инциденты с поставщиком облачных услуг?
• Существует ли служба мониторинга безопасности в реальном времени (RTSM)? Передана ли служба на аутсорсинг? Какие параметры и сервисы отслеживаются?
• Предоставляете ли вы (по запросу) периодический отчет об инцидентах безопасности (например, согласно определению ITIL)?
• Как долго хранятся журналы безопасности? Защищены ли эти журналы? У кого есть доступ к ним?
• Может ли клиент создать хостовую систему предотвращения вторжений (HIPS) или хостовую систему обнаружения вторжений (HIDS) в образе виртуальной машины? Возможно ли интегрировать информацию, собранную системами обнаружения и предотвращения вторжений клиента, в службу RTSM поставщика облачных услуг или третьей стороны?

Лишь очень небольшая область платформы Atlassian Cloud открыта для доступа через брандмауэры. Мы периодически пересматриваем правила брандмауэров. В наших офисах и в облачной среде размещения развернута система обнаружения вторжений (IDS). На платформе Atlassian Cloud функция пересылки журналов встроена в платформу аналитики безопасности. На уровне контейнеров облачной платформы целостность файлов сохраняется, поскольку экземпляры нельзя изменять. Команда по проектированию сетей Atlassian использует технологии предотвращения вторжений (IPS), встроенные в наши брандмауэры, а в офисных и облачных средах внедрены технологии обнаружения вторжений (IDS). Возможности противодействия DDoS-атакам предоставляются нашим интернет-провайдером/оператором связи. Подробнее о нашей программе поддержки безопасности см. на странице https://www.atlassian.com/trust/security/detections-program. Основные системные журналы передаются из каждой системы на централизованную платформу журналов, причем журналы доступны только для чтения. Команда по обеспечению безопасности Atlassian создает оповещения на нашей платформе аналитики безопасности (Splunk) и отслеживает признаки угрозы. Наши команды по обеспечению надежности используют эту платформу, чтобы отслеживать проблемы, влияющие на доступность или производительность. Журналы хранятся в течение 30 дней в архивах «горячего» резервирования и в течение 365 дней в архивах «холодного» резервирования. Atlassian предоставляет доступ для просмотра и чтения журналов только уполномоченным сотрудникам на нашей централизованной платформе. Atlassian также поддерживает специальные внешние каналы, которые помогают узнавать об уязвимостях или инцидентах, в т. ч. через Программу вознаграждения за найденные ошибки, клиентский портал, а также выделенные электронные адреса и номера телефонов для сбора информации, касающейся безопасности. Atlassian рекомендует клиентам сообщать о любом несанкционированном доступе или вредоносном поведении. Подробнее см. на странице https://www.atlassian.com/trust/security/security-incident-management и https://www.atlassian.com/trust/security/security-incident-responsibilities.

6.07.01. (d)

Как определяются уровни серьезности?

Atlassian применяет общую систему оценки уязвимостей (Common Vulnerability Scoring System, CVSS) для оценки рисков безопасности и приоритизации обнаруженных уязвимостей. На основе рассчитанных Atlassian баллов CVSS выделяют уровни:

• критический,
• высокий,
• средний,
• низкий.


Подробную информацию, в том числе о том, какие диапазоны баллов соответствуют уровням серьезности, см. на странице https://www.atlassian.com/trust/security/security-severity-levels.

6.07.01. (e)

Как определяются процедуры эскалации? Когда принимает участие клиент облачных услуг (если принимает)?

Мы располагаем документированной политикой и планом реагирования на инциденты безопасности, ключевые принципы которых включают:

• Прогнозирование инцидентов безопасности и подготовка к реакции на инциденты.
• Сдерживание последствий инцидентов, их устранение и восстановление систем.
• Принятие мер, направленных на то, чтобы наши сотрудники, процессы и технологии были полностью готовы к выявлению и анализу инцидентов безопасности в случае их возникновения.
• Защита персональных данных и данных клиентов становится нашей главной задачей во время инцидентов безопасности.
• Регулярная проверка процедуры реакции на инциденты безопасности.
• Мы накапливаем опыт и совершенствуем все функции, связанные с управлением инцидентами безопасности
• Мы информируем руководящую группу Atlassian о критических инцидентах безопасности.


В соответствии с этой политикой Atlassian придерживается плана реагирования на инциденты безопасности. Узнать больше о нашей процедуре реагирования на инциденты безопасности можно по ссылке https://www.atlassian.com/trust/security/security-incident-management.

Atlassian понимает, насколько важно своевременно получать уведомления о любой утечке данных. Вот почему компания Atlassian создала большую межфункциональную команду и процесс для урегулирования инцидентов безопасности, как описано на странице https://www.atlassian.com/trust/security/security-incident-management.

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

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

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

6.07.01. (f)

Как документируются инциденты и собираются доказательства?

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

После разрешения инцидента высокого уровня серьезности (1 или 2) исходная заявка об инциденте закрывается, и начинается анализ результатов реагирования на инцидент (PIR). В случае инцидентов высокого уровня серьезности команда по обеспечению безопасности проводит анализ основных причин и предлагает возможные улучшения системы и (или) способы решения проблемы.

6.07.01. (g)

Помимо аутентификации, учета и аудита, существуют ли другие средства контроля для предотвращения (или минимизации воздействия) вредоносных действий внутренних нарушителей?

В офисах и в облачной среде размещения Atlassian развернута система обнаружения вторжений (IDS). Функция пересылки журналов встроена в платформу аналитики безопасности для платформы Atlassian Cloud. Основные системные журналы передаются из каждой системы на централизованную платформу журналов, причем журналы доступны только для чтения. Команда по обеспечению безопасности Atlassian создает оповещения на нашей платформе аналитики безопасности (Splunk) и отслеживает признаки угрозы. Подробнее о нашей программе поддержки безопасности см. на странице https://www.atlassian.com/trust/security/detections-program.

6.07.01. (h)

Собирает ли поставщик показатели и индикаторы инцидентов (например, количество обнаруженных или зарегистрированных инцидентов в месяц, количество инцидентов, вызванных субподрядчиками поставщика облачных услуг, общее количество таких инцидентов, среднее время реагирования и разрешения и т. д.)?

• Какие из них поставщик публикует в общем доступе? (Примечание: не все данные об инцидентах могут быть обнародованы, поскольку это может нарушить конфиденциальность клиента и раскрыть критическую для безопасности информацию.)

В настоящее время мы не публикуем внутренние показатели, но делимся информацией о мерах, принимаемых после возникновения операционных инцидентов 0-й или 1-й степени серьезности, на нашей странице Statuspage, см.: https://status.atlassian.com/.

6.07.01. (j)

Как часто поставщик тестирует планы аварийного восстановления и обеспечения непрерывности бизнеса?

Мы тестируем планы обеспечения непрерывности бизнеса и аварийного восстановления для сервисов Atlassian Cloud по меньшей мере один раз в квартал. Доступность в разных регионах отслеживается в реальном времени. Каждую неделю в среде для подготовки к релизу проводятся автоматические проверки аварийного переключения в регионах. Проверки автоматизированного восстановления конфигурационных данных проводятся ежедневно в рабочей среде. Все сервисы Atlassian ежеквартально проводят тестирование отказоустойчивости в зоне доступности в среде для подготовки к релизу. Подробнее о нашей программе обеспечения непрерывности бизнеса см. на странице https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e.

Наши планы аварийного восстановления протестированы и утверждены внешними аудиторами в рамках нашей программы соответствия требованиям. Подробнее см. на странице https://www.atlassian.com/trust/compliance/resources.

6.07.01. (k)

Собирает ли поставщик данные об уровне удовлетворенности SLA?

Мы отслеживаем производительность и доступность всех экземпляров Cloud, однако в настоящее время у нас нет официального соглашения SLA с условиями о доступности приложений. Наша служба поддержки предоставляет SLA о первоначальном времени отклика. В отсутствие официального соглашения SLA по решениям поддержки мы стремимся решать все назначенные обращения в течение 48 часов. Atlassian публикует статистику последних статусов наших систем Cloud здесь: https://status.atlassian.com.

Да, мы предлагаем гарантии SLA, если вы решите использовать наши предложения Premium или Enterprise.

6.07.01. (l)

Проводит ли поставщик проверки справочной службы? Например, следующие.

• Тесты с имитацией прав доступа (действительно ли человек, который звонит по телефону и требует сброса пароля, является тем, за кого себя выдает?) или так называемые атаки «социальной инженерии».

Компания Atlassian проводит обучение по вопросам безопасности в рамках адаптации новых сотрудников («День 1») и на постоянной основе для всех сотрудников.

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

Мы также проводим постоянное обучение по актуальным вопросам безопасности, связанным с вредоносными программами, фишингом и другими проблемами. https://www.atlassian.com/trust/security/security-practices#security-awareness-training

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

6.07.01. (m)

Проводит ли поставщик тестирование на проникновение? Как часто? Что фактически проверяется во время теста на проникновение: например, проверяется ли защитная изоляция каждого образа, чтобы исключить возможность «прорыва» одного образа в другой, а также получения доступа к инфраструктуре хоста? При тестировании также проверяется, можно ли получить доступ через виртуальный образ к системам управления и поддержки поставщика облачных услуг (например, системам выделения ресурсов и контроля доступа администраторов).

Наша внутренняя команда Red Team постоянно проводит тестирования на проникновение всей нашей инфраструктуры, облачных сервисов и сотрудников.

Мы привлекаем сторонних консультантов для проведения ежегодных тестов на проникновение во внешние приложения. Кроме того, мы дополняем эти тесты более мелкими текущими работами по проверке безопасности, которые выполняет наша команда внутреннего тестирования безопасности. Письма об оценке таких тестов на проникновение, а также подробную информацию о нашем процессе тестирования и подходе к внешнему тестированию безопасности можно найти здесь: https://www.atlassian.com/trust/security/security-testing.

6.07.01. (n)

Проводит ли поставщик тестирование на наличие уязвимостей? Как часто?

Команда Atlassian по обеспечению безопасности выполняет непрерывное сканирование как внутренней, так и внешней инфраструктуры на предмет сетевых уязвимостей с использованием признанного в отрасли сканера уязвимостей. Подробнее о нашей программе управления уязвимостями см. на странице https://www.atlassian.com/trust/security/vulnerability-management.

6.07.01. (o)

Каков процесс устранения уязвимостей (быстрые исправления, реконфигурация, переход на более поздние версии программного обеспечения и т. д.)?

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

Подробнее о нашей программе управления уязвимостями см. на странице https://www.atlassian.com/trust/security/vulnerability-management.

6.08.

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

6.08. (a)

Какие гарантии вы предоставляете клиенту в отношении физической безопасности объекта? Приведите примеры и укажите, какие стандарты при этом соблюдаются, например Раздел 9 стандарта ISO 27001/2.

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

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

6.08. (a) (i)

У кого, кроме уполномоченных ИТ-специалистов, есть доступ без сопровождения (физический) к ИТ-инфраструктуре?

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

В офисах Atlassian следуют нашей внутренней Политике обеспечения физической защиты и безопасности среды, в которой, помимо прочего, описывается порядок мониторинга физических точек входа и выхода. Мы опубликовали выдержки из всех наших внутренних политик для управления технологическими операциями и безопасностью. Их можно найти по адресу https://www.atlassian.com/trust/security/ismp-policies.

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

Соответствие требованиям центров обработки данных наших партнеров подтверждается множеством сертификатов. Они касаются физической защиты, доступности системы, доступа к сети и IP-магистрали, создания пользователей и управления проблемами. Доступ к центрам обработки данных осуществляется только уполномоченным персоналом после биометрической аутентификации. Меры физической защиты включают охрану на местах, видеонаблюдение, шлюзовые кабины и дополнительные меры защиты от вторжений. Подробнее об обеспечении физической защиты AWS см. на странице http://aws.amazon.com/compliance.

6.08. (a) (ii)

Как часто пересматриваются права доступа?

• Как быстро можно отозвать права доступа?

Atlassian оценивает производительность и эффективность своей системы управления информационной безопасностью (ISMS) с помощью соответствующих показателей. Мы отслеживаем эффективность системы Atlassian Trust Management System (ATMS) и соответствующих средств контроля с помощью внутренних и внешних аудиторских проверок. Команда Atlassian по соответствию требованиям управляет как графиком внутреннего аудита (в том числе аудита готовности), так и графиком внешнего аудита (которые во внутренней документации отражены на странице дорожных карт аудита). Внутренние аудиты сосредоточены на областях повышенного риска в компании Atlassian и проводятся регулярно по заранее составленным графикам, а также в соответствии с графиком корпоративного аудита, согласованным между командой по оценке рисков и обеспечению соответствия требованиям и командой внутреннего аудита. В настоящее время мы не публикуем внутренние показатели. Оценка ATMS проводится ежегодно независимыми третьими сторонами, а также после любых существенных изменений. Основные облачные сервисы Atlassian прошли сертификацию на соответствие стандартам SOC 2, ISO 27001 и ISO 27018. Atlassian также отслеживает компоненты ATMS путем проведения периодических собраний по оперативному анализу, включая рассмотрение конкретных показателей по каждому из компонентов. Сюда входят еженедельный анализ работы системы соответствия требованиям для ATMS и другие собрания, которые внутренне документируются на нашей странице «ATMS: анализ работы системы соответствия требованиям» и на странице протоколов собраний ATMS. Подробнее см. на странице https://www.atlassian.com/trust/compliance.

У нас есть официальная программа управления безопасностью, и мы ежегодно пересматриваем нашу программу управления информационной безопасностью (ISMP). Подробнее о нашей программе управления безопасностью см. на странице https://www.atlassian.com/trust/security/security-management-program.

6.08. (a) (iii)

Проводите ли вы регулярную оценку рисков безопасности и оценку периметров?

• Как часто?

Atlassian оценивает производительность и эффективность своей системы управления информационной безопасностью (ISMS) с помощью соответствующих показателей. Мы отслеживаем эффективность системы Atlassian Trust Management System (ATMS) и соответствующих средств контроля с помощью внутренних и внешних аудиторских проверок. Команда Atlassian по соответствию требованиям управляет как графиком внутреннего аудита (в том числе аудита готовности), так и графиком внешнего аудита (которые во внутренней документации отражены на странице дорожных карт аудита). Внутренние аудиты сосредоточены на областях повышенного риска в компании Atlassian и проводятся регулярно по заранее составленным графикам, а также в соответствии с графиком корпоративного аудита, согласованным между командой по оценке рисков и обеспечению соответствия требованиям и командой внутреннего аудита. В настоящее время мы не публикуем внутренние показатели. Оценка ATMS проводится ежегодно независимыми третьими сторонами, а также после любых существенных изменений. Основные облачные сервисы Atlassian прошли сертификацию на соответствие стандартам SOC 2, ISO 27001 и ISO 27018. Atlassian также отслеживает компоненты ATMS путем проведения периодических собраний по оперативному анализу, включая рассмотрение конкретных показателей по каждому из компонентов. Сюда входят еженедельный анализ работы системы соответствия требованиям для ATMS и другие собрания, которые внутренне документируются на нашей странице «ATMS: анализ работы системы соответствия требованиям» и на странице протоколов собраний ATMS. Подробнее см. на странице https://www.atlassian.com/trust/compliance.

У нас есть официальная программа управления безопасностью, и мы ежегодно пересматриваем нашу программу управления информационной безопасностью (ISMP). Подробнее о нашей программе управления безопасностью см. на странице https://www.atlassian.com/trust/security/security-management-program.

6.08. (a) (iv)

Проводите ли вы регулярную оценку рисков, включающую такие пункты, как соседние здания?

Atlassian оценивает производительность и эффективность своей системы управления информационной безопасностью (ISMS) с помощью соответствующих показателей. Мы отслеживаем эффективность системы Atlassian Trust Management System (ATMS) и соответствующих средств контроля с помощью внутренних и внешних аудиторских проверок. Команда Atlassian по соответствию требованиям управляет как графиком внутреннего аудита (в том числе аудита готовности), так и графиком внешнего аудита (которые во внутренней документации отражены на странице дорожных карт аудита). Внутренние аудиты сосредоточены на областях повышенного риска в компании Atlassian и проводятся регулярно по заранее составленным графикам, а также в соответствии с графиком корпоративного аудита, согласованным между командой по оценке рисков и обеспечению соответствия требованиям и командой внутреннего аудита. В настоящее время мы не публикуем внутренние показатели. Оценка ATMS проводится ежегодно независимыми третьими сторонами, а также после любых существенных изменений. Основные облачные сервисы Atlassian прошли сертификацию на соответствие стандартам SOC 2, ISO 27001 и ISO 27018. Atlassian также отслеживает компоненты ATMS путем проведения периодических собраний по оперативному анализу, включая рассмотрение конкретных показателей по каждому из компонентов. Сюда входят еженедельный анализ работы системы соответствия требованиям для ATMS и другие собрания, которые внутренне документируются на нашей странице «ATMS: анализ работы системы соответствия требованиям» и на странице протоколов собраний ATMS. Подробнее см. на странице https://www.atlassian.com/trust/compliance.

У нас есть официальная программа управления безопасностью, и мы ежегодно пересматриваем нашу программу управления информационной безопасностью (ISMP). Подробнее о нашей программе управления безопасностью см. на странице https://www.atlassian.com/trust/security/security-management-program.

6.08. (a) (v)

Осуществляется ли контроль или мониторинг сотрудников (включая третьи стороны), которые получают доступ к охраняемым зонам?

В офисах Atlassian следуют нашей внутренней Политике обеспечения физической защиты и безопасности среды, в которой, помимо прочего, описывается порядок мониторинга физических точек входа и выхода. Мы опубликовали выдержки из всех наших внутренних политик для управления технологическими операциями и безопасностью. Их можно найти по адресу https://www.atlassian.com/trust/security/ismp-policies.

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

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

6.08. (a) (vi)

Какие политики или процедуры существуют для погрузки, разгрузки и установки оборудования?

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

6.08. (a) (vii)

Проверяется ли поставляемое оборудование на наличие рисков перед установкой?

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

6.08. (a) (viii)

Имеется ли актуальная инвентаризационная опись оборудования в центре обработки данных?

Выдержка из нашей Политики управления активами доступна по адресу https://www.atlassian.com/trust/security/ismp-policies. Atlassian ведет инвентаризацию всех производственных активов с указанием их владельцев. Все наши системы расположены в центрах обработки данных на базе AWS. Из-за характера этих услуг системы AWS не отслеживаются на аппаратном уровне.

Все микрослужбы отслеживаются в специально созданной базе данных, которая обновляется по мере развертывания любой службы. Наша команда по технологиям рабочего места (WPT) проводит инвентаризацию всех конечных точек, отслеживая активы с помощью ПО Atlassian, Jira Software.

Все микрослужбы делятся на уровни, с каждым из которых связаны ожидания относительно времени безотказной работы, доступности, целевого времени восстановления (RTO) и целевых точек восстановления (RPO). Вот несколько примеров: https://www.atlassian.com/trust/security/data-management.

6.08. (a) (ix)

Проходят ли сетевые кабели через зоны общественного доступа?

• Используете ли вы бронированные кабели или кабелепроводы?

В офисах Atlassian следуют нашей внутренней Политике обеспечения физической защиты и безопасности среды, в которой, помимо прочего, описывается порядок мониторинга физических точек входа и выхода. Мы опубликовали выдержки из всех наших внутренних политик для управления технологическими операциями и безопасностью. Их можно найти по адресу https://www.atlassian.com/trust/security/ismp-policies.

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

6.08. (a) (x)

Проводится ли регулярное обследование помещений для выявления несанкционированного оборудования?

Выдержка из нашей Политики управления активами доступна по адресу https://www.atlassian.com/trust/security/ismp-policies. Atlassian ведет инвентаризацию всех производственных активов с указанием их владельцев. Все наши системы расположены в центрах обработки данных на базе AWS. Из-за характера этих услуг системы AWS не отслеживаются на аппаратном уровне.

Все микрослужбы отслеживаются в специально созданной базе данных, которая обновляется по мере развертывания любой службы. Наша команда по технологиям рабочего места (WPT) проводит инвентаризацию всех конечных точек, отслеживая активы с помощью ПО Atlassian, Jira Software.

6.08. (a) (xi)

Есть ли оборудование, которое размещено за пределами объектов?

• Как оно защищено?

Выдержка из нашей Политики управления активами доступна по адресу https://www.atlassian.com/trust/security/ismp-policies. Atlassian ведет инвентаризацию всех производственных активов с указанием их владельцев. Все наши системы расположены в центрах обработки данных на базе AWS. Из-за характера этих услуг системы AWS не отслеживаются на аппаратном уровне.

Все микрослужбы отслеживаются в специально созданной базе данных, которая обновляется по мере развертывания любой службы. Наша команда по технологиям рабочего места (WPT) проводит инвентаризацию всех конечных точек, отслеживая активы с помощью ПО Atlassian, Jira Software.

6.08. (a) (xii)

Используют ли ваши сотрудники портативное оборудование (например, ноутбуки, смартфоны), через которое можно получить доступ к центру обработки данных?

• Как защищено такое оборудование?

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

Авторизованные и обученные участники инженерных команд Atlassian, прошедшие проверку биографических данных, аутентифицируются в VPN с помощью уникальных надежных паролей и двухфакторной аутентификации на основе TOTP, а затем получают доступ к рабочей среде только через терминалы с SSH-соединением, используя защищенные секретной фразой персональные сертификаты RSA. На всех рабочих серверах установлена система IDS, которая включает мониторинг в режиме реального времени, а также оповещение о любых изменениях в файлах или конфигурации рабочей системы и аномальных событиях безопасности. Для авторизованных и обученных участников операционной команды, имеющих доступ к рабочей системе, на всех рабочих станциях под управлением Windows или OS X, используемых для доступа по терминалу SSH к рабочей среде, должно быть установлено актуальное и активное антивирусное программное обеспечение. Данные клиентов не реплицируются на рабочие станции или мобильные устройства сотрудников.

6.08. (a) (xiii)

Какие меры предусмотрены для контроля карт доступа?

В офисах Atlassian следуют нашей внутренней Политике обеспечения физической защиты и безопасности среды, в которой, помимо прочего, описывается порядок мониторинга физических точек входа и выхода. Мы опубликовали выдержки из всех наших внутренних политик для управления технологическими операциями и безопасностью. Их можно найти по адресу https://www.atlassian.com/trust/security/ismp-policies.

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

6.08. (a) (xiv)

Какие существуют процессы или процедуры для уничтожения старых носителей или систем, когда это необходимо?

• Перезапись данных?
• Физическое уничтожение?

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

6.08. (a) (xv)

Какие существуют процессы авторизации при перемещении оборудования из одного объекта в другой?

• Как обозначаются сотрудники (или подрядчики), уполномоченные на это?

Партнеры Atlassian по хостингу центров обработки данных (AWS) обеспечивают физическую безопасность, и мы полагаемся на их сертификаты SOC 2 при подтверждении эффективности средств контроля.

Продукты Atlassian Cloud физически не перемещают данные клиентов. Жесткие диски с данными клиентов уничтожаются или очищаются перед тем, как покинуть наши защищенные центры обработки данных AWS. В системах, размещенных в AWS, данные можно перемещать между регионами в рамках сценария обеспечения избыточности, но они остаются в AWS. Подробнее о наших регионах AWS см. на странице https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvi)

Как часто проводятся аудиты оборудования на предмет несанкционированного избавления от него?

Партнеры Atlassian по хостингу центров обработки данных (AWS) обеспечивают физическую безопасность, и мы полагаемся на их сертификаты SOC 2 при подтверждении эффективности средств контроля.

Продукты Atlassian Cloud физически не перемещают данные клиентов. Жесткие диски с данными клиентов уничтожаются или очищаются перед тем, как покинуть наши защищенные центры обработки данных AWS. В системах, размещенных в AWS, данные можно перемещать между регионами в рамках сценария обеспечения избыточности, но они остаются в AWS. Подробнее о наших регионах AWS см. на странице https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvii)

Как часто проводятся проверки на соответствие среды применимым законодательным и нормативным требованиям?

Наш юридический отдел и команда по соответствию требованиям следят за выполнением наших нормативных обязательств. Наша Юридическая программа приведена на странице https://www.atlassian.com/legal/. Подробнее о нашей Программе соответствия требованиям можно узнать на странице https://www.atlassian.com/trust/compliance.

6.09. (a)

Какие существуют процедуры или политики, гарантирующие, что проблемы среды не приведут к сбою в обслуживании?

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

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

В компании действует Политика обеспечения непрерывности бизнеса и аварийного восстановления, а также одноименный План, которые ежегодно пересматриваются руководящим комитетом по обеспечению непрерывности бизнеса и аварийному восстановлению. Владельцы критически важных для бизнеса систем, процессов и служб в полной мере реализуют непрерывную работу и (или) аварийное восстановление, которое соответствует должной отказоустойчивости на случай аварии. Планы, касающиеся непрерывности бизнеса и аварийного восстановления, проверяются ежеквартально. Все выявленные проблемы устраняются. Подробнее см. на странице https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management и https://www.atlassian.com/trust/security/data-management.

6.09. (b)

Какие методы используются для предотвращения ущерба от пожара, наводнения, землетрясения и т. д.?

• Какие дополнительные меры безопасности принимаются в случае аварии для защиты физического доступа?
• Как на основных, так и на вторичных объектах?

Atlassian полагается на гарантии своих партнеров по хостингу данных в отношении безопасности их центров обработки данных и эффективности средств контроля среды. Подробнее об AWS см. на странице https://aws.amazon.com/compliance/programs.

6.09. (c)

Контролируете ли вы температуру и влажность в центре обработки данных?

• Кондиционирование воздуха или мониторинг?

Atlassian полагается на гарантии своих партнеров по хостингу данных в отношении безопасности их центров обработки данных и эффективности средств контроля среды. Подробнее об AWS см. на странице https://aws.amazon.com/compliance/programs.

6.09. (d)

Защищаете ли вы свои здания от ударов молний?

• В том числе линии электропередачи и связи?

Atlassian полагается на гарантии своих партнеров по хостингу данных в отношении безопасности их центров обработки данных и эффективности средств контроля среды. Подробнее об AWS см. на странице https://aws.amazon.com/compliance/programs.

6.09. (e)

Есть ли у вас автономные генераторы на случай сбоя в энергоснабжении?

• Как долго они могут работать?
• Есть ли достаточные запасы топлива?
• Реализовано ли аварийное переключение генераторов?
• Как часто вы проверяете оборудование ИБП?
• Как часто вы проверяете генераторы?
• У вас несколько поставщиков электроэнергии?

Atlassian полагается на гарантии своих партнеров по хостингу данных в отношении безопасности их центров обработки данных и эффективности средств контроля среды. Подробнее об AWS см. на странице https://aws.amazon.com/compliance/programs.

6.09. (f)

Все ли коммунальные услуги (электричество, вода и т. д.) способны поддерживать вашу среду?

• Как часто проводится переоценка и проверка?

Atlassian полагается на гарантии своих партнеров по хостингу данных в отношении безопасности их центров обработки данных и эффективности средств контроля среды. Подробнее об AWS см. на странице https://aws.amazon.com/compliance/programs.

6.09. (g)

Способна ли ваша система кондиционирования воздуха поддерживать вашу среду?

• Как часто ее тестируют?

Atlassian полагается на гарантии своих партнеров по хостингу данных в отношении безопасности их центров обработки данных и эффективности средств контроля среды. Подробнее об AWS см. на странице https://aws.amazon.com/compliance/programs.

6.09. (h)

Соблюдаете ли вы рекомендованные производителем графики технического обслуживания?

Atlassian полагается на гарантии своих партнеров по хостингу данных в отношении безопасности их центров обработки данных и эффективности средств контроля среды. Подробнее об AWS см. на странице https://aws.amazon.com/compliance/programs.

6.09. (i)

Допускаете ли вы на объект только авторизованных специалистов по техническому обслуживанию или ремонту?

• Как вы проверяете их личность?

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

6.09. (j)

Когда оборудование отправляется в ремонт, с него предварительно удаляются данные?

• Как это делается?

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

6.10.

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

Вот основные юридические вопросы, которые клиент должен задать поставщику облачных услуг.

6.10. (a)

В какой стране находится поставщик облачных услуг?

Atlassian имеет 12 офисов в 8 странах, в том числе в Сиднее, Амстердаме, Анкаре, Бостоне, Бангалоре, Сан-Франциско, Маунтин-Вью, Остине (штат Техас), Нью-Йорке, Маниле, Гданьске и Японии. Подробнее см. на странице https://www.atlassian.com/company/contact.

6.10. (b)

Расположена ли инфраструктура поставщика облачных услуг в одной стране или в разных странах?

В настоящее время Atlassian Cloud размещается в зонах доступности AWS с соблюдением принципа избыточности ресурсов. Информацию о конкретных регионах см. на странице https://www.atlassian.com/trust/reliability/infrastructure.

6.10. (c)

Будет ли поставщик облачных услуг привлекать другие компании, чья инфраструктура находится за пределами его инфраструктуры?

Продукты и данные Atlassian Cloud размещаются у ведущего поставщика облачных услуг — Amazon Web Services (AWS). Наши продукты предоставляются по модели «платформа как сервис» (PaaS). Рабочая среда разделена на две области инфраструктуры, которые называются Micros и non-Micros. Jira, Confluence, Statuspage, Atlassian Access и Bitbucket работают на платформе Micros, а Opsgenie и Trello — на платформе non-Micros.

6.10. (d)

Где физически будут находиться данные?

Atlassian использует Amazon Web Services (AWS) в следующих регионах: Восток США, Запад США, Ирландия, Франкфурт, Сингапур и Сидней (Confluence и Jira).

Сведения о конкретных продуктах.

• Trello: сервис доступен в регионе AWS Восток США (Огайо).
• Jira Align: для запроса физического местонахождения данных клиентов можно подать заявку в службу поддержки. См. https://support.atlassian.com/jira-align/.
• Statuspage: инструмент доступен в регионах AWS Запад США (Орегон, Калифорния), Восток США (Огайо).
• Opsgenie: имеет аккаунты AWS в США и Европе. При регистрации клиент должен выбрать США (Орегон, Калифорния) или ЕС (Франкфурт) для AWS.
• Halp: размещается в регионах AWS Восток США 2 и Запад США 2.
• Bitbucket: репозитории и основные функции приложений размещены в регионах AWS Восток США и Запад США.


Более подробную информацию о месте хранения данных см. на странице https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/.

6.10. (e)

Будет ли разделена юрисдикция в отношении условий договора и в отношении данных?

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

6.10. (f)

Будут ли какие-либо услуги поставщика облачных услуг передаваться на субподряд?

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

Atlassian заблаговременно отправляет своим клиентам уведомления о привлечении субподрядчиков, которые могут обрабатывать их персональные данные. Список внешних подрядчиков Atlassian опубликован на странице «Субобработчики данных Atlassian» по адресу https://www.atlassian.com/legal/sub-processors. На этой странице можно подписаться на ленту новостей RSS, чтобы получать уведомления о добавлении новых субобработчиков данных Atlassian.

6.10. (g)

Будут ли какие-либо услуги поставщика облачных услуг передаваться на аутсорсинг?

При сотрудничестве со сторонними поставщиками компания Atlassian делает все, чтобы оградить от риска своих клиентов и их данные. Юридический отдел и отдел закупок Atlassian анализируют договоры, SLA и внутренние политики поставщиков и проверяют их на соответствие требованиям безопасности, доступности и конфиденциальности. Подробнее см. на странице https://www.atlassian.com/trust/security/security-practices#supplier-risk-management.

6.10. (h)

Как будут собираться, обрабатываться и передаваться данные, предоставляемые клиентом и его клиентами?

Atlassian обрабатывает информацию в строгом соответствии с целями, для которых она собиралась или которые впоследствии были одобрены пользователем, и в соответствии с политикой внешней конфиденциальности Atlassian.

Конфиденциальность пользователей имеет для Atlassian большое значение, поэтому мы придерживаемся принципов прозрачности во всем, что касается сбора, использования и раскрытия информации о пользователях. Подробнее см. на странице «Конфиденциальность в Atlassian» в разделе Atlassian Trust Center по адресу https://www.atlassian.com/trust/privacy, а также в нашей Политике конфиденциальности по адресу https://www.atlassian.com/legal/privacy-policy.

6.10. (i)

Что происходит с данными, отправленными поставщику облачных услуг, после расторжения договора?

Компания Atlassian придерживается стандарта по сохранению и уничтожению данных, в котором определены сроки хранения данных разных типов. Данные подразделяются на категории в соответствии с политикой безопасности данных и жизненного цикла информации Atlassian, и на ее основе реализованы механизмы контроля. При прекращении действия договора с Atlassian данные, принадлежащие команде клиента, будут удалены из рабочей базы данных, а все вложенные файлы, загруженные непосредственно в системы Atlassian, будут удалены в течение 14 дней. Данные команды будут храниться в зашифрованных резервных копиях до истечения 90-дневного периода хранения резервных копий, после чего они будут уничтожены в соответствии с политикой хранения данных Atlassian. Если в течение 90 дней после запрошенного удаления данных потребуется восстановить базу данных, операционная команда повторно удалит данные в разумно возможный кратчайший срок после того, как рабочая система будет полностью восстановлена. Подробнее см. на странице https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/