Принципы безопасности

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

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

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

Если не указано иное, информация на этой странице касается продуктов Atlassian Cloud — Jira, Confluence и Bitbucket.

Чем мы занимаемся

Система Atlassian Trust Management System (ATMS) учитывает потребности каждого клиента в обеспечении безопасности и формирует на их основе уникальный набор требований и инициатив для наших продуктов и сред. Подробнее о наших инициативах см. на сайте Atlassian Trust. Там вы сможете загрузить или запросить отчеты о сертификации нашей компании по стандартам ISO 27001 и SOC 2, изучить анкету CSA STAR, а также узнать подробнее о системе Atlassian Trust Management System (ATMS).

Встроенная безопасность

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

Архитектура

Концентрация на вопросах безопасности при проектировании приложений, сетей и бизнес-процессов

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

Приложения

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

Безопасность

Криптография и шифрование, управление угрозами и уязвимостями, управление инцидентами в сфере безопасности

Инфраструктура

Управление ресурсами, управление доступом, операции, безопасность коммуникаций

ЦОД и офисы

Физическая защита и безопасность среды

Corporate

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

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

Standard Спонсор Контрольные требования Темы

ISO 27001

Международная организация по стандартизации

26 требований

6 разделов

ISO 27002

Международная организация по стандартизации

114 требований

14 тем

PCI-DSS

Индустрия платежных карт

247 требований

6 тем

CSA CCM

Альянс безопасности облачных вычислений

133 процедуры контроля

16 тем

SOC2

Контрольные процедуры сервисных организаций

116 требований

5 принципов

SOX 404 (IT)

Федеральный закон США

22 требования

5 тем

GAPP

AICPA

106 требований

10 тем

Подробнее об этом см. на странице общей схемы контроля безопасности.

 

network

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

Мы внедряем средства контроля на каждом уровне стека, разделяя существующую инфраструктуру на зоны, среды и сервисы.

Ограничения по зонам включают в себя введение лимита сетевого трафика на уровне офиса, ЦОД или платформы. Изоляция сред подразумевает контроль подключений между средой разработки и рабочей средой. Для коммуникации между сервисами требуется явная авторизация с использованием «белого списка».

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

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

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

Приложение

Моделирование угроз нужно для разработки надлежащих средств противодействия им.

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

Мы используем в работе Microsoft Threat Modeling Tool и схему моделирования угроз STRIDE. STRIDE — это аббревиатура списка стандартных проблем безопасности: Spoofing (подмена), Tampering (несанкционированный доступ), Reputation (репутационные риски), Information Disclosure (раскрытие информации), Denial of Service (отказ в обслуживании) и Elevation of Privilege (несанкционированное получение прав).

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

Надежность

Клиенты используют наши продукты в разном объеме. Мы общаемся с ними и знаем, что продукты Jira или Confluence нередко становятся частью важнейших бизнес‑процессов компании. Наш бизнес тоже опирается на работу нашей линейки продуктов, поэтому мы понимаем, насколько важны надежность работы и быстрое восстановление.

Обеспечение доступности и избыточности для всей платформы

Мы работаем с множеством ЦОД в различных географических местоположениях

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

Мы заботимся о высокой доступности ваших данных и сервисов. Нам важно обеспечить отказоустойчивость продуктов, поэтому мы применяем стандарты и методы, которые позволяют максимально снизить время простоя. Наши методы обеспечения отказоустойчивости основываются на стандартах SOC 2, ISO 27002 и ISO 22301.

Хостинг для Jira, Confluence, Statuspage, Trello, Opsgenie и Jira Align предоставляется ведущим в отрасли поставщиком услуг облачного хостинга — Amazon Web Services (AWS). AWS обеспечивает оптимальную производительность, резервирование и восстановление данных после отказа для компаний по всему миру. Мы поддерживаем множество регионов и зон доступности в восточной и западной части США, на территории Европейского Союза и в странах Азиатско-Тихоокеанского региона.

Хостинг для Bitbucket Data Center предоставляется нашим партнером NTT, который обладает сертификатами SOC 2 и ISO 27001 в области безопасности и доступности. С NTT мы можем быть уверены, что такие аспекты, как физическая безопасность, доступ к сети и IP‑магистрали, создание аккаунтов клиентов и управление проблемами, контролируются на должном уровне.

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

Резервное копирование

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

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

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

Непрерывная работа бизнеса и аварийное восстановление

Мы разработали комплексные планы по обеспечению непрерывности бизнеса и аварийному восстановлению

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

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

  1. Управление. Участие руководства является ключевым моментом в реализации нашей программы DR.  Вовлекая руководство, мы учитываем в нашей стратегии обеспечения отказоустойчивости как техническую сторону вопроса, так и сторону бизнеса.
  2. Контроль и техническое обслуживание. В ходе мониторинга нашей программы DR и управления ею мы применяем упорядоченный подход к управлению, оценке рисков и обеспечению соответствия требованиям. Это позволяет более эффективно и результативно вести мониторинг, измерять показатели, составлять отчеты и устранять недостатки в основных мероприятиях нашей программы DR. Инженеры по обеспечению надежности сайта участвуют в регулярных собраниях по аварийному восстановлению и представляют свои критически важные сервисы. Они обсуждают недочеты, выявленные в программе DR, с командой по оценке рисков и обеспечению соответствия требованиям и устраняют нарушения на соответствующих уровнях.
  3. Тестирование. Мы проводим регулярное тестирование и непрерывно совершенствуем продукты в рамках жизненного цикла программы DR, чтобы обеспечить высокую доступность ваших данных и возможность их быстрой обработки.
    1. Мы тестируем уровни отказоустойчивости во всех зонах доступности AWS, чтобы максимально снизить время простоя в случае отказа зоны доступности.
    2. Мы осуществляем резервное копирование данных во всех региональных ЦОД AWS. Если регион прекратит работу вследствие критического инцидента, мы защитим ваши данные и обеспечим их хранение во вспомогательном регионе. 
    3. Мы тестируем регионы AWS на наличие сбоев. Мы понимаем, что полный отказ региона крайне маловероятен. Тем не менее, мы продолжаем тестировать наши возможности аварийного переключения сервисов и постоянно повышаем уровень отказоустойчивости регионов.
    4. Процедуры резервного копирования и восстановления функционируют и регулярно тестируются. Это означает, что в случае необходимости восстановления данных мы будем готовы вернуть вас к работе при помощи хорошо обученных сотрудников службы поддержки и полностью протестированных процедур.

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

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

Безопасность продукта

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

Шифрование и управление ключами

Шифрование при передаче

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

Шифрование при хранении

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

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

Управление ключами шифрования

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

Изоляция клиентов

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

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

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

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

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

Подробнее об архитектуре Atlassian Cloud можно узнать по ссылке.

Тестирование безопасности продукта

Мы поддерживаем программы внутреннего и внешнего тестирования безопасности с вознаграждением за найденные ошибки

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

Внутреннее тестирование

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

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

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

Внешнее тестирование

Как только релиз перемещается в рабочую среду, начинается внешнее тестирование. Этот подход основан на понятии «постоянного контроля». Мы опираемся не только на тестирование на проникновение в определенный момент времени — мы используем постоянно действующую модель тестирования, которая основана на общедоступной программе вознаграждения за найденные ошибки (Bug Bounty) по принципу краудсорсинга.

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

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

Наш подход к тестированию на проникновение является узконаправленным и специализированным. Как правило, тесты соответствуют следующим критериям.

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

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

Управление уязвимостями продуктов

Мы используем инновационные подходы к созданию качественного ПО

Чтобы обеспечить быстрое и безопасное внедрение новых возможностей, мы выходим за рамки традиционных процедур контроля качества (QA) и вводим понятие «помощь по качеству» (Quality Assistance)*. Мы хотим привить образ мышления, согласно которому за качество отвечает вся команда. Поэтому мы переносим роль QA с человека, непосредственно выполняющего задачи по QA, на фасилитатора. Мы также активно стимулируем и обучаем разработчиков, чтобы они могли тестировать созданные ими возможности в соответствии с нашими стандартами качества.

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

*Примечание. Термин «помощь по качеству» (Quality Assistance) придуман Сэмом Канером. Если вы хотите узнать больше об этом и о нашем процессе обеспечения качества в целом, читайте нашу серию записей в блоге на тему QA.

Методы работы

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

Доступ к данным клиентов

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

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

В Atlassian данные клиентов, хранящиеся в наших приложениях, доступны только уполномоченным сотрудникам. Аутентификация выполняется с помощью индивидуальных открытых ключей, защищенных парольной фразой, а серверы принимают входящие SSH‑соединения только из Atlassian и внутренних ЦОД.

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

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

Расширенная политика по управлению доступом к данным и метаданным клиентов включена в нашу политику конфиденциальности.

Доступ со стороны службы поддержки

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

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

Обучение и осведомленность

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

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

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

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

Чемпионы безопасности

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

Помимо программы повышения осведомленности мы также разработали собственную программу «Чемпионы безопасности».  С ее помощью мы хотим сделать так, чтобы безопасность занимала важное место в каждой команде Atlassian (то есть «встроить безопасность»). Кроме того, мы хотим сделать тему безопасности более доступной. Один из способов достичь этой цели — обучать сотрудников, которые обладают основными навыками в области безопасности, будь то повседневная деятельность или разработка. В конечном итоге мы хотим привлекать профильных специалистов, которые интересуются безопасностью и демонстрируют способности в этой сфере, в команду на условиях неполного рабочего дня. Так они получат возможность распространять наши идеи по всей компании.

Управление изменениями

Мы внедрили управление изменениями в стиле проектов с открытым исходным кодом

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

Наем сотрудников

Мы стремимся нанимать лучших

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

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

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

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

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

Пропуск платежей

Если клиент пропускает платеж или не может произвести оплату, действие подписки на все продукты заканчивается через 15 дней после наступления срока оплаты. Затем данные клиента будут храниться в холодном резервном хранилище в течение 60 дней, после чего удалятся. Клиенты могут предотвратить удаление данных. Для этого нужно внести пропущенные платежи в течение 15 дней. После этого срока восстановление данных клиента станет невозможным вне зависимости от оплаты.

Отмена подписки

Если клиент прерывает действие подписки намеренно, его данные удаляются через 60 дней после окончания срока действия подписки (для платных сайтов).

Для Jira: если клиент отменяет подписку на один продукт Jira (например, Jira Software) и сохраняет подписку на другой (например, Jira Service Desk), его данные Jira будут сохранены. Этот принцип применим и к пробным версиям: если заканчивается срок действия пробной версии для продукта Jira, но у клиента все еще есть подписка на другие продукты Jira, его данные Jira будут сохранены. Однако если клиент отменяет подписку на все продукты Jira, то его данные Jira будут немедленно удалены.

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

Окончание срока действия пробной версии

Если срок действия пробной версии для клиента заканчивается без перехода на платную подписку, его данные удаляются через 15 дней (для сайтов пробной версии).

В любом из описанных случаев данные клиента удаляются без возможности восстановления.

Уничтожение данных

Ваши данные удаляются через 15 дней (для сайтов пробной версии) или 60 дней (для сайтов с платной подпиской) после отмены подписки на продукт Atlassian или потери доступа из-за пропуска платежа.

Что произойдет при пропуске платежа или отмене подписки на отдельный продукт?

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

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

Сохранение данных

Сайт деактивируется через 15 дней после окончания срока действия подписки. Atlassian хранит данные неактивных сайтов в течение 15 дней (для сайтов пробной версии) или 60 дней (для сайтов с платной подпиской) после окончания срока действия подписки. 

Срок действия пробных версий отдельных продуктов Atlassian, для которых применяется годовая подписка, составляет 30 дней. При отсутствии оплаты подписка на продукты Jira и Confluence отменяется через 17 дней после наступления срока платежа. С этого момента пользователи потеряют доступ к Jira и Confluence.

Данные Confluence удаляются через 15 дней после отмены подписки на этот продукт. Если срок действия вашей пробной версии продукта Jira (например, Jira Service Desk) заканчивается, но ваша годовая подписка включает другие продукты Jira (например, Jira Software), то данные Jira не будут удалены. Эти данные будут удалены только при отмене подписки на все продукты Jira. 

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

Как подготовить данные к перемещению на другой сайт?

Процессы обеспечения безопасности

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

Управление инцидентами безопасности

Инциденты неизбежны, но быстрое и эффективное реагирование на них помогает нам минимизировать последствия

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

При возникновении серьезного инцидента безопасности Atlassian расследует его до полного решения. Для этого компания обращается к знаниям внутри организации и пользуется услугами сторонних профильных специалистов. База данных наших инцидентов безопасности каталогизирована с использованием платформы VERIS.

Узнайте больше о нашем процессе управления инцидентами безопасности и общих обязанностях во время инцидента безопасности.

Управление уязвимостями

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

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

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

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

Подробнее о тестировании безопасности в нашей компании см. на странице о нашем подходе к внешнему тестированию безопасности.

Подробнее о нашей программе управления уязвимостями см. на странице об управлении уязвимостями в Atlassian.

Вознаграждение за найденные ошибки (Bug Bounty)

Наша программа вознаграждения за найденные ошибки (Bug Bounty) обеспечивает постоянное тестирование систем

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

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

Подробнее о тестировании безопасности в нашей компании см. на странице о нашем подходе к внешнему тестированию безопасности.

Загрузить текущие отчеты о тестировании

Все уязвимости системы безопасности, описанные в приведенных ниже отчетах, отслеживаются нашей внутренней системой Jira по мере их регистрации в программе вознаграждения за найденные ошибки (Bug Bounty). Закрытие уязвимостей происходит в соответствии со сроками, определенными в SLA для политики устранения багов безопасности.

 

Соответствие требованиям

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

В настоящее время мы сертифицированы на соответствие стандартам SOC 2, ISO 27001, PCI DSS и CSA STAR. Подробнее об этих программах см. на странице соответствия требованиям.

Standard

Спонсор

Состояние

ISO 27001

Международная организация по стандартизации

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

ISO/IEC 27001 также включает в себя комплексные средства защиты безопасности, описанные в стандарте ISO/IEC 27002. Условие прохождения сертификации — разработка и внедрение программы строгого контроля безопасности, включая разработку и внедрение системы управления информационной безопасностью (ISMS). Этот широко признанный и уважаемый международный стандарт безопасности предъявляет к компаниям, претендующим на прохождение сертификации, следующие требования.

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

Просмотреть сертификат ISO/IEC 27001 компании Atlassian.

ISO 27018

Международная организация по стандартизации

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

ISO/IEC 27018 — это свод правил, направленный на защиту персональных данных в облаке. Он основан на стандарте информационной безопасности ISO/IEC 27002 и представляет дополнительные рекомендации по внедрению средств контроля ISO/IEC 27002 в отношении расположенных в общедоступном облаке персональных данных. Он также предоставляет дополнительные средства контроля и соответствующие руководства, направленные на удовлетворение требований по защите персональных данных в общедоступном облаке, не включенных в текущий стандарт ISO/IEC 27002.

Просмотреть сертификат ISO/IEC 27018 компании Atlassian.

PCI-DSS

Индустрия платежных карт

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

Используя кредитную карту для оплаты продуктов и услуг Atlassian, вы можете быть уверены в том, что мы обеспечиваем надлежащую безопасность транзакции. Мы являемся торговой компанией уровня 2 и пользуемся услугами квалифицированного аудитора систем безопасности (QSA) для оценки соответствия стандартам безопасности данных индустрии платежных карт PCI DSS. В настоящее время мы соответствуем требованиям PCI DSS версии 3.2 и SAQ A.

Просмотрите или загрузите наши сертификаты соответствия PCI (AoC):

CSA CCM / STAR

Альянс безопасности облачных вычислений

Опросник CSA STAR уровня 1 для компании Atlassian можно загрузить на веб-сайте реестра CSA STAR.

Реестр безопасности, доверия и достоверности (STAR) Альянса безопасности облачных вычислений (CSA) — это бесплатный общедоступный реестр, документирующий средства контроля безопасности, которые используются в различных платформах облачных вычислений. С его помощью клиенты могут оценивать безопасность поставщиков облачных услуг, с которыми они работают или планируют заключить договор. Компания Atlassian зарегистрирована в реестре STAR. Она является корпоративным членом Альянса безопасности облачных вычислений (CSA) и предоставила информацию по всем пунктам опросника в рамках инициативы по отраслевой оценке (CAIQ), разработанной CSA. Последняя версия CAIQ соответствует Матрице контроля облачных вычислений CSA (CCM) версии 3.0.1 и содержит ответы более чем на 300 вопросов, которые могут возникнуть у пользователя или аудитора безопасности облачных вычислений к поставщику этой услуги.

См. заполненный опросник CIAQ Atlassian в реестре CSA Star.

SOC 2 / SOC 3 

Контрольные процедуры сервисных организаций

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

Компания Atlassian прошла сертификацию SOC 2 для многих своих продуктов. Загрузить сертификаты SOC 2 и SOC 3 компании Atlassian.

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

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

Соответствие требованиям GDPR

Мы прилагаем все усилия, чтобы помогать нашим клиентам добиваться успеха и защищать их данные. Один из способов выполнить это обещание — разъяснить клиентам и пользователям Atlassian назначение Общего регламента по защите данных (GDPR), а также помочь выполнить его требования там, где это возможно. Регламент GDPR является самым значительным изменением в европейском законодательстве о конфиденциальности данных за последние 20 лет. Он вступил в силу 25 мая 2018 года.

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

Ниже перечислено несколько инициатив GDPR для наших облачных продуктов.

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

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

Конфиденциальность

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

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

См. подробнее о нашем подходе к конфиденциальности в нашей политике конфиденциальности.

Обработка запросов правоохранительных органов

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

Общая ответственность

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

На высоком уровне Atlassian управляет безопасностью самих приложений, систем, в которых они работают, и сред, в которых эти системы размещены.  Мы следим за тем, чтобы эти системы и среды отвечали требованиям соответствующих стандартов, включая PCI DSS и SOC 2, когда это необходимо.

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

Дерево ответственности

Ниже кратко описаны несколько вещей, на которые мы рекомендуем обратить внимание нашим клиентам.

Ключевые решения

Ваши решения о том, как будут настроены наши продукты, оказывают большое влияние на реализацию безопасности.  Ключевые решения:

  • Все продукты: подтверждение домена и централизованное управление. Вы можете подтвердить права на один или несколько доменов, чтобы доказать, что вы или ваша организация являются их владельцами. Подтверждение домена позволит вашей организации централизованно управлять всеми аккаунтами Atlassian своих сотрудников и применять политики аутентификации (включая требования к паролю и SAML). После подтверждения домена все пользователи, имеющие аккаунты Atlassian в этом домене, получат по электронной почте уведомление о том, что их аккаунты станут управляемыми. Любой пользователь, создавший новый аккаунт Atlassian в этом домене, увидит, что этот аккаунт является управляемым.
  • Bitbucket: открытые и закрытые репозитории. Вы определяете, являются ли репозитории открытыми (так что просматривать их может любой пользователь Интернета) или закрытыми (в этом случае доступ к этим репозиториям будут иметь только лица с правами доступа).
  • Trello: публичные и приватные команды и доски. В Trello можно настраивать видимость досок, в том числе делать доски публичными (с некоторыми ограничениями, если ваш аккаунт Trello является управляемым). Публичную доску может увидеть любой пользователь Интернета. Она может отображаться в результатах поиска различных поисковых систем, например Google. Подробнее о настройках видимости досок Trello можно узнать здесь. Вы также можете сделать публичной свою команду, чтобы ее профиль мог просматривать любой пользователь Интернета. Подробнее от настройках видимости команды Trello можно узнать здесь.
  • Все продукты: предоставление доступа. Наши продукты предназначены для совместной работы. Совместная работа требует предоставления доступа. Однако при предоставлении прав доступа к вашим данным другим пользователям и приложениям следует проявлять осторожность. Как только вы предоставите такие права доступа, мы не сможем запретить этим пользователям выполнять действия, разрешенные в соответствии с этими правами, даже если вы не одобряете их.

Доступ пользователей

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

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

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

Экосистема

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

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

Хотите узнать больше?

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