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

Наша команда

Уверены, что большинство компаний готовы сказать то же самое, — но мы бесконечно гордимся нашей командой по обеспечению безопасности. Мы считаем, что сформировали и вырастили команду самых лучших и талантливых специалистов в отрасли. Наша команда по обеспечению безопасности насчитывает более 100 сотрудников из офисов в Сиднее, Амстердаме, Бангалоре, Остине, Маунтин-Вью, Сан-Франциско и Нью-Йорке (плюс несколько участников, которые работают дистанционно); возглавляет команду генеральный директор по информационной безопасности в Сан-Франциско. Эта команда постоянно развивается, тем самым подтверждая, что безопасность является сферой особого внимания для Atlassian. У нас есть множество вспомогательных команд, в том числе:

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

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

Дополнительные программы, которые помогают нам поддерживать безопасность на должном уровне

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

Постоянное совершенствование нашей программы безопасности

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

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

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

Дополнительная информация

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

• Подход компании Atlassian к управлению данными клиентов
• Наш подход к внешнему тестированию безопасности
• Наш подход к управлению инцидентами безопасности
• Наш подход к управлению уязвимостями
• Общая ответственность за обеспечение облачной безопасности
• Наша система Atlassian Trust Management System
• Политики Atlassian в сфере безопасности и технологий

Обеспечение безопасного доступа к нашим сетям при помощи модели «нулевого доверия»

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

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

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

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

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

Защищенное управление доступом к нашим системам и сервисам

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

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

Защита наших конечных точек

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

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

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

Если какое-либо устройство определяется как не отвечающее требованиям, сотрудник получит по электронной почте соответствующее уведомление. Сотруднику дается 24 часа на исправление нарушения, прежде чем доступ для этого устройства будет прекращен.

Управление конфигурациями в наших системах

В нашей компании лишь ограниченному числу специалистов и архитекторов разрешено устанавливать программное обеспечение в рабочей среде. В большинстве случаев установка ПО невозможна. Для управления конфигурациями и изменениями на серверах в наших рабочих средах используются инструменты управления конфигурациями. Предполагается, что для непосредственного внесения изменений в эти системы утвержденная конфигурация передается посредством инструментов управления конфигурацией. Благодаря этому обеспечивается согласованность. Мы полагаемся на стандартные образы машин Amazon (Amazon Machine Image, AMI). Все изменения в наших AMI или операционных системах должны совершаться посредством нашего стандартного процесса управления изменениями. Мы отслеживаем конфигурации-исключения и сообщаем о них. Кроме того, у нас реализована изоляция ресурсов, чтобы проблемы с каким-либо сервисом не повлияли на работу других сервисов. Мы также используем процесс «Проверка коллегами, зеленая сборка» (PRGB). В ходе этого процесса множество проверяющих утверждают изменения конфигурации, переданные через инструменты управления конфигурациями. Все сборки снабжаются криптографической подписью. В нашей рабочей среде можно запускать только сборки такого типа.

Использование журналов

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

Основные системные журналы объединяются как во внутреннюю систему анализа журналов, так и в систему обнаружения вторжений.

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

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

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

Руководство компании вовлечено в планирование непрерывности бизнеса и аварийного восстановления. Такой контроль необходим, чтобы все команды чувствовали на себе личную ответственность за обеспечение устойчивости. В ходе мероприятий по планированию BC и DR мы стремимся найти подходящий баланс между затратами, выгодами и рисками. Для этого мы проводим анализ целевых сроков восстановления (RTO) и целевых точек восстановления (RPO) сервисов. В результате этого анализа мы создали простую систему из 4 уровней. С помощью нее можно поделить сервисы на группы в зависимости от того, какие требования выдвигаются к их восстановлению. Подробнее об этом подходе см. на странице «Подход компании Atlassian к управлению данными клиентов».

Наши программы BC и DR предполагают следующие мероприятия.

1. Встраивание средств обеспечения резервирования для удовлетворения требований к отказоустойчивости

2. Тестирование и проверка мер обеспечения избыточности

3. Использование результатов тестирования для непрерывного улучшения мер обеспечения BC и DR

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

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

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

Мы проводим ежегодную оценку последствий для бизнеса (BIA) с целью определить риски критически важных сервисов. Результаты оценки используются для определения стратегии по обеспечению DR и BC. Благодаря этому возможна разработка эффективных планов по DR и BC для критически важных сервисов.

Доступность сервисов

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

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

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

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

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

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

Физическая безопасность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общая ответственность при управлении данными клиентов

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

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

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

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

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

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

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

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

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

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