Сканирование секретов

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

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

GitHub Advanced Security для Azure DevOps работает с Azure Repos. Если вы хотите использовать GitHub Advanced Security с репозиториями GitHub, см. статью GitHub Advanced Security.

Сведения о оповещениях проверки секретов

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

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

Вкладка "Расширенная безопасность" в Repos>Advanced Security в Azure DevOps — это концентратор для просмотра оповещений системы безопасности. Перейдите на вкладку "Секреты", чтобы просмотреть оповещения проверки секретов . Вы можете фильтровать по типу состояния и секрета. Вы можете перейти к оповещению для получения дополнительных сведений, включая рекомендации по исправлению. После включения расширенной безопасности проверка запускается для выбранного репозитория, включая все исторические фиксации. Со временем оповещения начнут отображаться при выполнении сканирования.

Влияние на результаты не влияет на переименование ветвей— может потребоваться до 24 часов до отображения нового имени.

Чтобы устранить предоставленные секреты, отмените предоставленные учетные данные и создайте новую в своем месте. После этого созданный секрет следует безопасно хранить таким образом, чтобы он не был напрямую отправлен обратно в код. Например, секрет может храниться в Azure Key Vault. Большинство ресурсов имеют как первичные, так и вторичные учетные данные. Метод для переката первичных учетных данных по сравнению с вторичными учетными данными идентичны, если иное не указано.

Управление оповещениями проверки секретов

Просмотр оповещений для репозитория

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

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

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

Секреты, отличные от поставщика, можно просматривать, выбрав "Другие" в раскрывающемся списке доверия на вкладке "Сканирование секретов".

Сведения об оповещении

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

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

Исправление оповещений сканирования секретов

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

Оповещение о сканировании секретов остается открытым до закрытия. Чтобы проверить, исправлена ли оповещение о проверке секретов:

1. Перейдите к оповещению, которое вы хотите закрыть, и выберите оповещение.
2. Выберите раскрывающийся список "Закрыть оповещение".
3. Если этот параметр еще не выбран, нажмите кнопку "Исправлено".
4. Нажмите кнопку "Закрыть", чтобы отправить и закрыть оповещение.

Отключение оповещений проверки секретов

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

Чтобы закрыть оповещение:

1. Перейдите к оповещению, которое вы хотите закрыть, и выберите оповещение.
2. Выберите раскрывающийся список "Закрыть оповещение".
3. Если этот параметр еще не выбран, выберите "Риск принят " или "Ложный положительный результат " в качестве причины закрытия.
4. Добавьте необязательный комментарий в текстовое поле "Комментарий ".
5. Нажмите кнопку "Закрыть", чтобы отправить и закрыть оповещение.
6. Состояние генерации оповещений изменяется с open to Closed и отображает причину увольнения.

Любое оповещение, ранее отклоненное, можно повторно открыть вручную.

Защита скомпрометированных секретов

После фиксации секрета в репозитории секрет скомпрометирован. Корпорация Майкрософт рекомендует следующие действия для скомпрометированных секретов:

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

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

Защита от отправки секретов

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

Сведения о оповещениях защиты от push-уведомлений

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

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

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

Отправка защиты из командной строки

Защита push-уведомлений встроена изначально в Azure DevOps Git. Если фиксации содержат определенный секрет, появится сообщение об отклонении отправки.

Push-защита от веб-интерфейса

Защита от push-уведомлений также работает из веб-интерфейса. Если секрет определен в фиксации, вы увидите следующий блок ошибок, который останавливает отправку изменений:

Что делать, если ваш push-адрес был заблокирован

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

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

Если секрет был добавлен в вашу немедленную предыдущую фиксацию, измените фиксацию и создайте новую фиксацию:

1. Удалите секрет из кода.
2. Фиксация изменений с помощью git commit --amend
3. Снова выполните отправку изменений.

Если секрет добавлен на более раннем этапе, измените фиксации при помощи интерактивного повторного размещения.

1. Выясните с помощью git log ту фиксацию, где вы впервые зафиксировали секрет.
2. Выполните интерактивную перебазу: git rebase -i [commit ID before credential introduction]~1
3. Определите фиксацию, которую нужно редактировать, изменив pick на edit в первой строке текста, который отображается в редакторе.
4. Удалите секрет из кода.
5. Зафиксируйте изменения с помощью команды git commit --amend.
6. Завершите перебазу, выполнив команду git rebase --continue.

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

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

Если вы считаете, что заблокированный секрет является ложным положительным или безопасным для отправки, вы можете обойти защиту push-уведомлений. Включите строку skip-secret-scanning:true в сообщение фиксации. Даже при обходе защиты push-уведомлений в пользовательском интерфейсе оповещения создается оповещение о секрете после отправки секрета.