Общие сведения о защите данных
Azure DevOps Services
Azure DevOps Services — это облачное приложение для проектов разработки, от планирования до развертывания. На основе локальных возможностей с дополнительными облачными службами мы управляем исходным кодом, рабочими элементами, сборками и тестами. Azure DevOps использует инфраструктуру как службу (PaaS) и многие службы Azure, включая SQL Azure, для обеспечения надежной, глобально доступной службы для проектов разработки.
В этой статье рассматриваются шаги, которые корпорация Майкрософт предпринимает для обеспечения безопасности, доступности, безопасности и конфиденциальности проектов. В нем описывается роль, которую вы играете в обеспечении безопасности и безопасности проектов.
Эта статья предназначена для администраторов организации и ИТ-специалистов, которые управляют своими ресурсами проекта ежедневно. Это наиболее полезно для пользователей, которые уже знакомы с Azure DevOps и хотят узнать больше о том, как Корпорация Майкрософт защищает сохраненные ресурсы в Azure DevOps.
Наши обязательства
Корпорация Майкрософт помогает гарантировать, что проекты остаются безопасными и безопасными без исключения. При хранении проектов в Azure DevOps они получают преимущества от нескольких уровней технологий безопасности и управления, операционных методик и политик соответствия требованиям. Мы применяем конфиденциальность и целостность данных как в состоянии хранения, так и при передаче.
Угрозы, с которыми вы сталкиваетесь, находятся в четырех основных категориях: доступность данных, доступность служб, безопасность служб и конфиденциальность данных. В этой статье рассматриваются конкретные угрозы в каждой категории и объясняется, что делает Azure DevOps для их устранения. В этой статье описывается, как хранятся данные и как Azure DevOps управляет доступом к данным.
Защита данных требует активного участия администраторов и пользователей, которые знают, какие шаги необходимо предпринять для защиты ресурсов от несанкционированного раскрытия и изменения. Будьте явными при предоставлении разрешений для точек доступа пользователей, поэтому только правильные пользователи получают доступ к данным в Azure DevOps.
Следует учитывать, что все данные могут быть потенциально подвержены риску, независимо от того, где он находится или как он используется. Эта инструкция относится как к данным, хранящимся в облаке, так и к данным, хранящимся в частном центре обработки данных. Важно классифицировать данные, его конфиденциальность и риск, а также ущерб, который он может сделать, если он становится скомпрометирован. Кроме того, классифицируйте данные относительно общей политики управления информационной безопасностью.
Создано в Azure
Мы размещаем Azure DevOps полностью в центрах обработки данных Azure. Azure DevOps использует множество основных служб Azure, включая вычислительные ресурсы, хранилище, сеть, SQL Azure, управление удостоверениями и доступом, а также Служебная шина Azure.
Azure DevOps использует службу хранилища Azure в качестве основного репозитория для метаданных службы и данных клиента. В зависимости от типа данных и требований к хранилищу и извлечению azure DevOps использует Хранилище BLOB-объектов Azure и хранилище База данных SQL Azure.
Чтобы понять подход Azure DevOps Services к защите данных, ниже приведены некоторые сведения о службах хранилища:
Хранилище BLOB-объектов Azure хранит большие фрагменты неструктурированных данных. Все проекты используют эту службу. Данные включают потенциально конфиденциальную или частную информацию, например, содержимое исходных файлов и вложений для рабочих элементов. Для большинства проектов большинство используемых хранилищ — это тип неструктурированного хранилища BLOB-объектов.
База данных SQL Azure хранит структурированные и транзакционные аспекты организации, включая метаданные проекта, журнал управления версиями и сведения о рабочих элементах. Хранилище базы данных обеспечивает быстрый доступ к важным элементам проекта. Он предоставляет индексы в хранилище BLOB-объектов для поиска файлов и вложений.
Администраторы могут управлять доступом к ресурсам путем предоставления или ограничения разрешений на удостоверения пользователя или группы. Azure DevOps использует федеративную проверку подлинности удостоверений пользователей с помощью идентификатора Microsoft Entra и учетных записей Майкрософт.
Во время проверки подлинности пользователь направляется поставщику проверки подлинности, где они предоставляют свои учетные данные. После того как поставщик проверки подлинности проверяет учетные данные пользователя, Azure DevOps выдает пользователю файл cookie проверки подлинности. Этот файл cookie позволяет пользователю оставаться прошедшим проверку подлинности в Azure DevOps.
Таким образом, учетные данные пользователя никогда не используются напрямую с Azure DevOps. Для каждого ресурса Azure DevOps, который пользователь пытается получить доступ, проверка разрешений основана на явных разрешениях пользователя и на разрешениях, унаследованных пользователем через членство в группах.
Администраторы могут использовать элементы управления доступом для защиты доступа к организации, коллекциям проектов, командным проектам и данным, а также функциональным возможностям группы. Администраторы также могут использовать элементы управления доступом для определенных ресурсов, таких как папки для управления версиями и путей к областям для рабочих элементов.
Доступность данных
Azure DevOps использует множество функций служба хранилища Azure для обеспечения доступности данных в случае сбоя оборудования, сбоя службы или региональной аварии. Кроме того, команда Azure DevOps выполняет процедуры, помогающие защитить данные от случайного или вредоносного удаления.
Избыточность данных
Чтобы защитить данные во время сбоев оборудования или служб, служба хранилища Azure геореплицирует данные клиента между двумя регионами в одном географическом расположении. Например, служба хранилища Azure могут геореплицировать данные между Северной и Западной Европой или между Северной и Южной США.
Для Хранилище BLOB-объектов Azure данные клиента реплицируются три раза в одном регионе. Данные клиента реплицируются асинхронно в второй регион в том же географическом расположении. Таким образом, Azure всегда поддерживает эквивалент шести копий данных.
Наличие нескольких копий позволяет выполнить отработку отказа в отдельный регион, если произошел серьезный сбой или авария, а также наличие локальной избыточности для сбоев оборудования в регионе. Для хранения База данных SQL Azure ежедневные резервные копии сохраняются вне сайта, если произошла региональная катастрофа.
Что касается избыточности данных и отработки отказа:
- Существует встроенная разность, измеряемая в минутах, когда корпорация Майкрософт реплицирует данные между основным и вторичным регионом.
- Отработка отказа в дополнительный регион — это решение, которое корпорация Майкрософт должна принимать централизованно, так как она влияет на всех клиентов в определенном масштабируемом модуле. За исключением чрезвычайных обстоятельств, корпорация Майкрософт решит избежать отработки отказа, чтобы данные клиента не были потеряны.
- Azure DevOps предлагает соглашение об уровне обслуживания (SLA) на 99,9 процента времени простоя. Azure DevOps возвращает часть ежемесячных расходов, если она пропустит соглашение об уровне обслуживания за определенный месяц.
- Так как в Бразилии существует только один регион, данные клиентов в Бразилии реплицируются в регион южной части США для аварийного восстановления.
Ошибки происходят
Для защиты от случайной потери данных корпорация Майкрософт использует резервные копии на определенный момент времени для больших двоичных объектов, хранящихся в Хранилище BLOB-объектов Azure и базах данных в База данных SQL Azure. Каждая учетная запись хранения поддерживает отдельную копию всех больших двоичных объектов, при этом изменения добавляются к существующим данным. Эти резервные копии неизменяемы, устраняя необходимость перезаписи существующего хранилища во время процедур резервного копирования.
База данных SQL Azure включает стандартные функции резервного копирования, используемые Azure DevOps. Данные хранятся в течение 28 дней, при этом эти резервные копии также реплицируются в парном регионе, чтобы упростить восстановление во время регионального сбоя.
После удаления можно восстановить удаленные организации или проекты в 28-дневном окне. Но после истечения этого периода времени эти сущности окончательно удаляются и не могут быть восстановлены. Хотя эти резервные копии служат важным компонентом аварийного восстановления, важно, чтобы клиенты практиковали соответствующие стратегии управления данными и резервного копирования, чтобы обеспечить комплексную защиту своих данных.
Внимание
- Случайное удаление здесь относится к сценариям, которые возникают в результате инцидента в наших службах. Он не включает случайное удаление ресурсов клиентов (например, репозитории, рабочие элементы, вложения или артефакты).
- Мы не поддерживаем восстановление ресурсов, которые клиенты случайно удаляют. Эти резервные копии предназначены только для обеспечения непрерывности бизнес-процессов и для помощи в восстановлении из-за сбоя или аварийных сценариев.
- В редких случаях процесс удаления может занять до 70 дней из-за повторных попыток серверной части и необходимости удаления данных из нескольких источников.
Практика имеет решающее значение
Наличие нескольких резервных копий данных является хорошим, но без практики восстановление может быть непредсказуемым. Люди говорят, что "резервные копии никогда не завершаются ошибкой; восстановление выполняется". Хотя заявление технически неправильно, тональность правильна.
Корпорация Майкрософт регулярно практикует восстановление наборов данных из резервной копии. Мы регулярно проверяем геоизбыточное хранилище из Azure. Существует множество сочетаний сценариев аварийного восстановления и повреждения данных. Мы продолжаем регулярно планировать и запускать новые тесты для этих сценариев.
Доступность службы
Azure DevOps предлагает распределенные защиты от отказов в обслуживании (DDoS) и ответ на динамический сайт, чтобы обеспечить доступ к вашей организации и связанным ресурсам.
Защита от атак DDoS
В некоторых случаях атака DDoS злоумышленника может повлиять на доступность службы. Azure имеет систему защиты от атак DDoS, которая помогает предотвратить атаки на нашу службу. В нем используются стандартные методы обнаружения и устранения рисков, такие как файлы cookie SYN, ограничение скорости и ограничения подключения. Система предназначена для того, чтобы противостоять атакам не только извне, но и из Azure.
Для атак, относящихся к приложениям, которые могут проникать в системы защиты Azure, Azure DevOps устанавливает квоты уровня приложений и уровня организации и регулирование. Эта практика помогает предотвратить чрезмерное использование ключевых ресурсов службы во время атаки или случайного использования ресурсов.
Ответ на динамический сайт
В редких случаях может потребоваться динамический ответ сайта на проблему с доступностью службы. У нас есть группа операций, которая постоянно доступна для быстрого выявления проблемы и привлечения необходимых ресурсов группы разработки.
Затем ресурсы группы разработчиков решают проблему. Они также стремятся обновить страницу состояния службы в течение нескольких минут после обнаружения проблемы, которая влияет на службу. После решения проблемы ресурсы группы разработчиков определяют первопричину и отслеживают необходимые изменения, чтобы предотвратить аналогичные проблемы в будущем.
Процессы Azure DevOps для динамического управления сайтами сосредоточены на вашем опыте и работоспособности службы. Эти процессы свести к минимуму время для обнаружения, реагирования и устранения проблем. Все инженерные дисциплины участвуют и отвечают, поэтому постоянные улучшения развиваются из прямого опыта. Мониторинг, диагностика, устойчивость и процессы проверки качества, а затем улучшаются с течением времени.
Управление динамическими сайтами в Azure DevOps содержит три отдельных трека: телеметрию, управление инцидентами и просмотр динамических сайтов. Вот что влечет за собой следующие пути:
Группа операций также отслеживает метрики доступности для отдельных организаций. Эти метрики предоставляют аналитические сведения о конкретных условиях, которые могут повлиять только на некоторых наших клиентов. Исследования этих данных часто могут привести к целевым улучшениям для решения проблем, связанных с клиентом. В некоторых случаях корпорация Майкрософт даже может обратиться к вам напрямую, чтобы понять свой опыт и работать с вами, чтобы улучшить службу.
Корпорация Майкрософт публикует соглашение об уровне обслуживания и предоставляет финансовую гарантию, чтобы обеспечить соблюдение этого соглашения каждый месяц. Дополнительные сведения см. в статье об уровне обслуживания для Azure DevOps.
Иногда команды партнеров или зависимости имеют инциденты, влияющие на Azure DevOps. Все команды партнеров следуют аналогичным подходам к выявлению, разрешению и обучению из этих сбоев служб.
Безопасность службы
Для обеспечения безопасности службы требуется постоянная бдительность, от надлежащих методов проектирования и написания кода до операционных факторов. Корпорация Майкрософт активно инвестирует в предотвращение дыр в безопасности и в обнаружении нарушений. При возникновении нарушения корпорация Майкрософт использует планы реагирования на безопасность для минимизации утечки данных, потери или повреждения. Дополнительные сведения см. в разделе "Сведения о безопасности, проверке подлинности и авторизации".
Безопасность по проектированию
Azure DevOps предназначен для обеспечения безопасности. Azure DevOps использует жизненный цикл разработки безопасности Майкрософт в основе процесса разработки. Программа Microsoft Operational Security Assurance управляет процедурами облачных операций в Azure DevOps.
Команда Azure DevOps имеет ежегодные требования к обучению для всех инженеров и сотрудников по эксплуатации. Команда также спонсирует неофициальные встречи, размещенные инженерами Майкрософт. После того как команда решает проблему, которая возникает в собрании, она делится уроками, полученными с другими командами.
В следующих методологиях указаны требования к обучению:
- Моделирование угроз во время проектирования службы
- Следующие рекомендации по проектированию и коду
- Проверка безопасности с помощью стандартных средств и тестирования
- Ограничение доступа к операционным и клиентским данным
- Развертывание новых функций путем жесткого процесса утверждения
Облачная служба является безопасной только в качестве платформы узла. Azure DevOps использует PaaS для большей части своей инфраструктуры. PaaS автоматически предоставляет регулярные обновления для известных уязвимостей системы безопасности.
Виртуальные машины, размещенные в Azure, используют инфраструктуру как службу (IaaS), например для размещенной службы сборки. Такие образы получают регулярные обновления, чтобы включить последние исправления безопасности, доступные в Обновл. Windows. То же самое обновление применяется для локальных компьютеров, включая те компьютеры, которые используются для развертывания, мониторинга и создания отчетов.
Команда Azure DevOps проводит регулярное, ориентированное на безопасность тестирование на проникновение Azure DevOps. Тестирование на проникновение пытается использовать динамические рабочие службы и инфраструктуру Azure DevOps, используя те же методы и механизмы, которые используют злоумышленники. Цель заключается в выявлении реальных уязвимостей, конфигураций, ошибок или других пробелов в безопасности в управляемом процессе.
Команда проверяет результаты этих тестов, чтобы определить другие области улучшения и повысить качество систем профилактики и обучения. Результаты последних тестов на проникновение Azure DevOps можно просмотреть на портале управления безопасностью служб Майкрософт.
Безопасность учетных данных
Корпорация Майкрософт стремится обеспечить безопасность и безопасность проектов без исключения. В Azure DevOps проекты получают преимущества от нескольких уровней технологий безопасности и управления, операционных методик и политик соответствия требованиям. Мы применяем конфиденциальность и целостность данных как в состоянии хранения, так и при передаче. Кроме того, мы придерживаемся следующих методик, касающихся учетных данных или секретов, которые хранятся в Azure DevOps. Дополнительные сведения о выборе правильного механизма проверки подлинности см. в руководстве по проверке подлинности.
Внимание
Azure DevOps не поддерживает проверку подлинности альтернативных учетных данных. Если вы по-прежнему используете альтернативные учетные данные, мы настоятельно рекомендуем переключиться на более безопасный метод проверки подлинности.
Личные маркеры доступа (PATs)
- Мы храним хэш ПЭТ.
- Необработанные PATs создают в памяти на стороне сервера. 32 байта случайным образом создаются через RNGCryptoServiceProvider и получают общий доступ к вызывающей строке в виде строки в кодировке base-32. Это значение не хранится.
- Хэш PAT создает в памяти на стороне сервера как HMACSHA256Hash необработанного PAT с помощью 64-байтового симметричного ключа подписи, хранящегося в нашем хранилище ключей.
- Хэш хранится в нашей базе данных.
Ключи безопасной оболочки (SSH)
- Мы храним хэш включаем идентификатор организации и открытый ключ SSH.
- Необработанные открытые ключи предоставляются непосредственно вызывающим по протоколу SSL.
- Хэш SSH создает в памяти на стороне сервера как HMACSHA256Hash идентификатора организации и необработанный открытый ключ с помощью 64-байтового симметричного ключа подписи, хранящегося в нашем хранилище ключей.
- Хэш хранится в нашей базе данных.
Учетные данные OAuth (JWTs)
- Проблемы с учетными данными OAuth в качестве полностью описывающих веб-токены JSON (JWTs) и не хранятся в нашей службе.
- Утверждения в JWTs, выданные и представленные нашей службе, проверяются с помощью сертификата, хранящегося в нашем хранилище ключей.
Создание отчетов об ошибках безопасности
Если вы считаете, что тестирование на проникновение выявило потенциальный недостаток безопасности, связанный со службой Azure DevOps, сообщите об этом корпорации Майкрософт в течение 24 часов. Дополнительные сведения см. на веб-странице Майкрософт для создания отчетов об уязвимости безопасности компьютера.
Внимание
Хотя вам не нужно уведомлять Майкрософт о действиях по тестированию на проникновение, необходимо соблюдать правила тестирования на проникновение Майкрософт.
Программа Bounty
Azure DevOps участвует в программе Microsoft Bug Bounty. Эта программа вознаграждает исследователей безопасности, которые сообщают нам о проблемах, и она поощряет больше людей, чтобы помочь обеспечить безопасность Azure DevOps. Дополнительные сведения см. в статье Microsoft Azure DevOps Bounty Program.
Ограничение доступа
Корпорация Майкрософт поддерживает строгий контроль над доступом к рабочей среде и данным клиентов. Мы предоставляем доступ на уровне минимальных привилегий и только после проверки оправданий пользователя. Если участнику команды требуется доступ к срочной проблеме или развертыванию изменения конфигурации, они должны применяться для JIT-доступа к рабочей службе. Доступ отменяется сразу после устранения ситуации.
Мы отслеживаем и отслеживаем запросы доступа и утверждения в отдельной системе. Все доступ к системе сопоставляется с этими утверждениями. Если мы обнаруживаем неоплаченный доступ, мы оповещаем группу операций для изучения.
Для всех удаленных системных доступа используется двухфакторная проверка подлинности. Если имя пользователя и пароль для одного из наших разработчиков или сотрудников операций украдены, данные остаются защищенными. Прежде чем разрешить доступ к службе, необходимо выполнить дополнительные проверки подлинности с помощью смарт-карты или телефонного звонка с предварительно подготовленным номером.
Для управления и поддержания службы корпорация Майкрософт использует такие секреты, как пароли RDP, SSL-сертификаты и ключи шифрования. Эти секреты управляются, хранятся и передаются безопасно через портал Azure. Для доступа к этим секретам требуется определенное разрешение, которое регистрируется и записывается безопасно. Все секреты поворачиваются на регулярный курс, и мы можем повернуть их по запросу, если есть событие безопасности.
Группа операций Azure DevOps использует защищенные рабочие станции администратора для управления службой. Эти компьютеры выполняют минимальное количество приложений и работают в логически сегментируемой среде.
Участники группы операций должны предоставить определенные учетные данные с двухфакторной проверкой подлинности для доступа к рабочим станциям. Все доступ отслеживается и безопасно регистрируется. Чтобы изолировать службу от внешнего изменения, мы не разрешаем приложениям, таким как Outlook и Office, так как часто они являются мишенью фишинга и других типов атак.
Защита и реагирование на вторжение
Мы шифруем данные через ПРОТОКОЛ HTTPS и SSL, чтобы гарантировать, что он не перехватывается или не изменяется во время передачи между вами и Azure DevOps. Данные, которые мы храним от вашего имени в Azure DevOps, шифруются следующим образом:
Данные, хранящиеся в базах данных SQL Azure, шифруются с помощью прозрачного шифрования данных. Эта функция помогает защитить от вредоносных действий, выполняя шифрование базы данных в режиме реального времени, связанные резервные копии и файлы журнала транзакций.
Хранилище BLOB-объектов Azure подключения шифруются для защиты передаваемых данных. Для неактивных данных, хранящихся в Хранилище BLOB-объектов Azure, Azure DevOps использует шифрование на стороне службы.
Команда Azure DevOps использует инфраструктуру Azure для регистрации и мониторинга ключевых аспектов службы. Ведение журнала и мониторинг помогают гарантировать, что действия в службе являются законными, и они помогают обнаруживать нарушения или попытки нарушения.
Все действия развертывания и администратора безопасно регистрируются, так как это доступ оператора к рабочему хранилищу. Данные журнала автоматически анализируются, а любое потенциально вредоносное или несанкционированное поведение вызывает оповещения в режиме реального времени.
Когда команда Azure DevOps определяет возможное вторжение или уязвимость безопасности с высоким приоритетом, она имеет четкий план реагирования. Этот план описывает ответственных сторон, необходимые шаги для защиты данных клиентов и инструкции по взаимодействию с экспертами по безопасности в Корпорации Майкрософт. Команда также уведомляет любые владелец организации, если данные были раскрыты или повреждены, чтобы они могли предпринять соответствующие меры по устранению ситуации.
Чтобы помочь в борьбе с возникающими угрозами, Azure DevOps использует стратегию нарушения . Высоко специализированная группа экспертов по безопасности в Корпорации Майкрософт принимает роль сложных злоумышленников. Эта команда проверяет обнаружение и реагирование на нарушения, чтобы точно измерить готовность и последствия реальных атак. Эта стратегия укрепляет обнаружение угроз, реагирование и защиту службы. Она также позволяет команде проверять и улучшать эффективность всей программы безопасности.
Защита от атак программ-шантажистов
Azure DevOps использует элементы управления Azure для предотвращения, обнаружения и реагирования на атаку программы-шантажистов. Дополнительные сведения о том, как Azure помогает защитить клиентов от атак программ-шантажистов, см. в статье "Защита от программ-шантажистов" в Azure.
Конфиденциальность данных
Вы должны иметь уверенность в том, что мы обрабатываем ваши данные соответствующим образом и для законных целей. Часть этой гарантии включает тщательное ограничение использования.
Общие правила защиты данных
Общий регламент по защите данных (GDPR) является самым большим изменением законов о защите данных в Европе с момента введения Директивы Ес (ЕС) защиты данных 95/46/EC. Дополнительные сведения о GDPR см. на странице обзора в Центре управления безопасностью Майкрософт.
Резидентность данных и суверенитет
Azure DevOps доступна в следующих восьми географических расположениях по всему миру: США, Канада, Европа, Соединенное Королевство, Индия, Австралия, Азиатско-Тихоокеанский регион и Бразилия. По умолчанию ваша организация назначается вашему ближайшему расположению. Однако при создании организации можно выбрать другое расположение. Если вы измените свое мнение позже, вы можете перенести организацию в другое расположение с помощью поддержки Майкрософт.
Azure DevOps не перемещает или реплицирует данные клиента за пределами выбранного расположения. Вместо этого данные геореплицируются во второй регион в том же расположении. Единственным исключением является Бразилия, которая реплицирует данные в регион южной части США для аварийного восстановления.
Примечание.
Для сборок и выпусков, которые выполняются в агентах macOS, предоставляемых Корпорацией Майкрософт, данные передаются в центр обработки данных GitHub в США.
Дополнительные сведения см. в разделе "Расположения данных" для Azure DevOps.
Доступ к правоохранительным органам
В некоторых случаях сторонние лица, такие как правоохранительные органы, могут обратиться к корпорации Майкрософт, чтобы получить доступ к данным клиентов, хранящимся в Azure DevOps. Мы пытаемся перенаправить запросы на владелец организации для разрешения. Когда судебный приказ заставляет корпорацию Майкрософт раскрывать данные клиентов стороннему лицу, корпорация Майкрософт предпринимает разумные усилия, чтобы заранее уведомить владелец организации, если мы не будем юридически запрещены делать это.
Некоторым клиентам требуется хранилище данных в определенном географическом расположении, чтобы обеспечить определенную юридическую юрисдикцию для любой деятельности правоохранительных органов. Все данные клиента, такие как исходный код, рабочие элементы, результаты тестирования и геоизбыточные зеркала и резервные копии вне сайта, хранятся в одном из ранее упомянутых расположений.
Доступ Майкрософт
Время от времени сотрудники Майкрософт должны получить доступ к данным клиента, хранящимся в Azure DevOps. В качестве меры предосторожности все сотрудники, имеющие (или, возможно, когда-либо) доступ к данным клиента, должны пройти фоновую проверку, включающую предыдущую работу и уголовные приговоры. Мы разрешаем доступ к производственным системам только в том случае, если имеется динамический инцидент сайта или другое утвержденное обслуживание, которое регистрируется и отслеживается.
Так как не все данные в нашей системе обрабатываются одинаково, мы классифицируем данные в следующие типы:
- Данные клиента: то, что вы отправляете в Azure DevOps.
- Данные организации: информация, которую вы отправляете при регистрации или администрировании организации.
- Данные Майкрософт: сведения, необходимые для или собранные через операцию службы.
На основе классификации мы контролируем сценарии использования, требования к географическому расположению, ограничения доступа и требования к хранению.
Использование рекламных материалов Майкрософт
Корпорация Майкрософт иногда хочет связаться с клиентами, чтобы сообщить им о дополнительных функциях и службах, которые могут оказаться полезными. Так как не все клиенты хотят связаться с этими предложениями, вы можете отказаться от маркетинговых сообщений электронной почты.
Корпорация Майкрософт никогда не использует данные клиентов для целевых предложений для конкретных пользователей или организаций. Вместо этого мы используем данные организации и статистические статистические данные об использовании на уровне организации для определения групп, которые должны получать определенные предложения.
Создание уверенности
Вы можете быть уверены в других усилиях, которые корпорация Майкрософт делает от имени Azure DevOps. Эти усилия включают внутренние политики внедрения в Корпорации Майкрософт, уровень прозрачности в состоянии нашей службы и прогресс в получении сертификации наших систем для управления информационной безопасностью.
Внутреннее внедрение
Microsoft teams внедряет Azure DevOps внутри организации. Команда Azure DevOps переехала в организацию в 2014 году и широко использует ее. Мы установили рекомендации, позволяющие реализовать планы внедрения для других команд.
Крупные команды перемещаются более постепенно, чем небольшие, из-за их инвестиций в существующие системы DevOps. Для команд, которые быстро перемещаются, мы установили подход к классификации проектов. Он оценивает отказоустойчивость рисков на основе характеристик проекта, чтобы определить, подходит ли проект для Azure DevOps. Для более крупных команд внедрение обычно происходит на этапах с большим планированием.
Дополнительные требования для внутренних проектов включают связывание организации с идентификатором Microsoft Entra, чтобы обеспечить правильную сложность жизненного цикла удостоверения пользователя и пароля. Для проектов, которые более чувствительны, также требуется двухфакторная проверка подлинности.
Соответствие требованиям сертификаций
Вам может быть интересно понять, как оценить наши процедуры для обеспечения безопасности данных. Azure DevOps достигла следующих сертификатов:
- ISO 27001:2013
- ISO 27018:2019
- ISO 26262:2023
- Акт о передаче и защите данных учреждений здравоохранения (HIPAA)
- Соглашение о бизнес-партнере (BAA)
- Предложения EU Model
- Системные и организационные элементы управления (SOC) 1 тип 2
- SOC 2 Тип 2
- Германия C5
- Стандарт IRAP Австралии
- ENS-Испания
Аудит SOC для Azure DevOps охватывает элементы управления безопасностью данных, доступностью, целостностью обработки и конфиденциальностью. Отчеты SOC для Azure DevOps доступны на портале управления безопасностью служб Майкрософт.
Анкета по оценке консенсуса (CAIQ) помогает организациям оценивать и оценивать методики безопасности и возможности поставщиков облачных служб. В соответствии с нашей приверженностью безопасности и прозрачности мы недавно завершили оценку CAIQ для Azure DevOps. Мы приглашаем вас просмотреть полный отчет на портале управления безопасностью служб Майкрософт.
Действия, которые можно выполнить
Для правильной защиты данных требуется активное участие от вас, администраторов и пользователей. Данные проекта, хранящиеся в Azure DevOps, являются безопасными, как точки доступа пользователей. Соответствует уровню строгости разрешений и детализации для этих организаций с уровнем конфиденциальности проекта.
Классификация данных
Первым шагом является классификация данных. Классифицируйте данные на основе конфиденциальности и горизонта риска, а также повреждения, которые могут возникнуть при компрометации. Многие предприятия имеют существующие методы классификации, которые они могут использовать при перемещении проектов в Azure DevOps. Дополнительные сведения можно скачать классификацию данных для готовности к облаку из Microsoft Trustworthy Computing.
Внедрение идентификатора Microsoft Entra
Используйте идентификатор Microsoft Entra для управления доступом вашей организации к Azure DevOps. Идентификатор Microsoft Entra предоставляет другой способ повышения безопасности учетных данных пользователей.
Идентификатор Microsoft Entra позволяет ИТ-отделу управлять политикой доступа пользователей, сложностью пароля, обновлением пароля и истечением срока действия, когда пользователи покидают организацию. С помощью федерации Active Directory можно напрямую связать идентификатор Microsoft Entra с центральным каталогом организации, поэтому у вас есть только одно расположение для управления этими сведениями для вашего предприятия.
В следующей таблице сравниваются характеристики учетной записи Майкрософт и Microsoft Entra относительно доступа к Azure DevOps:
| Свойство | Учетная запись Майкрософт | Microsoft Entra ID |
|---|---|---|
| Создатель удостоверений | User | Организация |
| Одно имя пользователя и пароль для всех рабочих ресурсов | No | Да |
| Управление временем существования пароля и сложностью | User | Организация |
| Ограничения членства в Azure DevOps | Любая учетная запись Майкрософт | Каталог организации |
| Идентификатор трассировки | No | Да |
| Ответственность за организацию и IP-адрес | Неясный | Организация |
| Регистрация двухфакторной проверки подлинности | User | Организация |
| Условный доступ на основе устройств | No | Организация |
Узнайте больше о настройке этой поддержки для вашей организации.
принудительное использование двухфакторной проверки подлинности;
Вам может потребоваться ограничить доступ к вашей организации, требуя нескольких факторов для входа. Для выполнения нескольких факторов можно использовать идентификатор Microsoft Entra. Например, для всех запросов на проверку подлинности можно требовать проверку подлинности на телефоне, а также имя пользователя и пароль.
Использование BitLocker
Для конфиденциальных проектов можно использовать BitLocker на ноутбуке Windows или настольном компьютере. BitLocker шифрует весь диск, на котором находятся Windows и ваши данные. Если BitLocker включен, он автоматически шифрует любой файл, сохраненный на этом диске. Если компьютер попадает в неправильные руки, BitLocker запрещает несанкционированный доступ к локальным копиям данных из ваших проектов.
Ограничение использования альтернативных учетных данных проверки подлинности
Механизм проверки подлинности по умолчанию для инструментов, связанных с Git, — это альтернативная проверка подлинности (иногда называемая базовой проверкой подлинности). Этот механизм позволяет пользователю настроить альтернативное имя пользователя и пароль для использования во время операций командной строки Git. Пользователь может использовать эту комбинацию имени пользователя и пароля для доступа к любым другим данным, для которых у этого пользователя есть разрешения. По своей природе альтернативные учетные данные проверки подлинности менее безопасны, чем федеративная проверка подлинности по умолчанию.
Вы по-прежнему можете сделать выбор для повышения безопасности. Все обмен данными отправляется по протоколу HTTPS, и существуют требования к сложности паролей. Ваша организация должна продолжать оценивать, требуется ли больше политик для удовлетворения требований к безопасности проектов.
Вы можете отключить альтернативные учетные данные проверки подлинности, если вы решите, что он не соответствует требованиям безопасности вашей организации. Дополнительные сведения см. в разделе "Изменение политик подключения к приложению и безопасности для организации".
Безопасный доступ к организации
Администраторы могут использовать идентификатор Microsoft Entra для управления доступом к ресурсам и приложениям Azure, таким как Azure DevOps. При использовании условного управления доступом идентификатор Microsoft Entra проверяет наличие определенных условий, заданных пользователю для доступа к приложению. После того как пользователь соответствует требованиям к доступу, пользователь проходит проверку подлинности и может получить доступ к приложению.
Azure DevOps поддерживает применение определенных типов политик условного доступа (например, ограждения IP-адресов) для пользовательских механизмов проверки подлинности Azure DevOps. Эти механизмы включают личные маркеры доступа, альтернативную проверку подлинности, OAuth и ключи Secure Shell (SSH). Если пользователи получают доступ к Azure DevOps через стороннего клиента, учитываются только политики на основе IPv4.