Introduction
Предотвращение инцидентов с безопасностью менее затратно и менее разрушительно, чем реагирование на них. Проактивно укрепляя вашу среду GitHub, вы снижаете риски с такими рисками, как использованные учетные данные, несанкционированный доступ и атаки на цепочку поставок.
Это руководство в первую очередь посвящено мерам защиты, которые вы можете применять в организациях, являющихся частью бизнеса GitHub Enterprise Cloud. Для судебного GitHub Enterprise Cloudразбирательства см. АВТОТИТР.
Многие из GitHubупомянутых здесь функций безопасности, такие как конфигурации безопасности, наборы правил веток и системы контроля доступа, могут быть настроены как на уровне организации, так и на корпоративном уровне.
Немедленные действия
Это высокоэффективные действия, которые вы можете предпринять уже сейчас, чтобы установить базовый уровень безопасности по всей организации.
- Установить систему безопасности
- Ужесточение контроля
- Пересмотр и ограничение доступа
- Проведите секретную оценку рисков
Установить систему безопасности
Убедитесь, что GitHubинструменты GitHub Advanced Security работы активны во всех репозиториях. Вместо того чтобы запускать инструменты по одному, вы можете создать и применить конфигурацию безопасности — это набор настроек безопасности, которые можно применить к репозиториям вашей организации или предприятия одним действием.
Сильная конфигурация может включать:
Secret scanning
** и **push protection** , чтобы обнаружить секреты, которые уже зафиксированы в вашей кодовой базе, и предотвратить появление новых секретов. Утечка учетных данных — одна из самых распространённых причин нарушений безопасности.
Code scanning
** чтобы выявлять уязвимости и ошибки в коде в исходном коде до их попадания в производство.
Dependabot alerts
** а **Dependabot security updates** также уведомлять вас о известных уязвимостях и вредоносном ПО в ваших зависимостях, а также автоматически открывать pull requests для обновления уязвимых зависимостей.
См. раздел [AUTOTITLE (организации) и Создание настраиваемой конфигурации безопасности](/enterprise-cloud@latest/code-security/how-tos/secure-at-scale/configure-enterprise-security/establish-complete-coverage/creating-a-custom-security-configuration-for-your-enterprise) (предприятия).
Ужесточение контроля
GitHub Даёт вам ряд контролей, которые регулируют, что может происходить в ваших репозиториях и организации. Обеспечение правильной настройки этих контролей крайне важно для снижения рисков.
Защищайте критические ветви с помощью правил
Наборы правил позволяют определять правила защиты для ветвей и тегов в одном или нескольких репозиториях. Используйте их для обеспечения соблюдения требований, таких как проверки pull request и проверка статуса (например, автоматические проверки безопасности). Это помогает предотвратить попадание несанкционированных изменений в производственный код, включая изменения с скомпрометированных аккаунтов.
См. раздел [AUTOTITLE (организации) и Создание наборов правил для репозиториев в организации](/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-code-governance) (предприятия).
Контролируйте, кто может обойти защиту от пуша
Когда вы включаете защиту от пуша, участники, пытающиеся прокачать обнаруженный секрет, блокируются, но по умолчанию у них есть возможность обойти блокировку. Делегированный обход требует, чтобы запросы на обход проходили цикл проверки и одобрения, поэтому обход не может произойти без явного аудированного решения.
Обеспечение проверки зависимостей для pull request
Действие проверки зависимостей позволяет выявлять уязвимые связи до их слияния, выявляя известные уязвимости в изменениях зависимостей pull request. Как и защита от секретов, она действует скорее как ворота, чем как предупреждение после событий. Вы можете навязать проверку зависимостей для pull requests по всей вашей организации.
См. раздел [AUTOTITLE и Сведения о проверке зависимостей](/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/enforcing-dependency-review-across-an-organization).
Пересмотр и ограничение доступа
Доступ, который был уместен в момент предоставления, возможно, больше не нужен. Регулярный пересмотр, кто и что имеет доступ к организации, снижает риск несанкционированных действий.
Аудит доступа членов и соблюдение принципа наименьшей привилегии
Убедитесь, что у членов организаций есть только тот доступ, который им необходим. Удалить членов, которым больше не нужен доступ, понизить статус ролей там, где более широкие разрешения не оправданы, и проверить доступ внешних коллаборационистов. Чрезмерно разрешённый доступ увеличивает радиус взрыва любого скомпрометированного аккаунта.
Если стандартные роли более разрешительны, чем требует организация, вы можете создать индивидуальные роли , которые предоставляют только те конкретные права, которые нужны каждой команде. Это особенно важно для организаций, внедряющих модель безопасности с нулевым доверием.
Проверьте разрешённые заявки
OAuth apps и GitHub Apps те, что установлены в организации, могут получать доступ к данным. Проверьте список авторизованных заявок и удалите те, которые больше не нужны или не пользуются доверием. Устаревшие интеграции представляют собой часто упускаемую из виду поверхность атаки.
См. раздел [AUTOTITLE и Обзор и изменение установленных приложений GitHub](/enterprise-cloud@latest/organizations/managing-oauth-access-to-your-organizations-data/about-oauth-app-access-restrictions).
Ограничить доступ к сети списками разрешений IP-адресов
Для организаций на GitHub Enterprise Cloud, если ваша организация работает из известных сетевых диапазонов, настройте список разрешений IP, чтобы ограничивать доступ к GitHub ресурсам только из этих диапазонов. Это добавляет уровень защиты от использования скомпрометированных учетных данных из неожиданных мест.
См. раздел [AUTOTITLE и Управление разрешенными IP-адресами для организации](/enterprise-cloud@latest/admin/configuring-settings/hardening-security-for-your-enterprise/restricting-network-traffic-to-your-enterprise-with-an-ip-allow-list).
Проведите секретную оценку рисков
Запустите бесплатное сканирование по запросу репозиториев организации, которое даст вам точное представление о общем объёме текущих секретов в вашей организации.
Краткосрочные действия
Эти действия также важны для вашей защитной позиции, но могут потребовать дополнительной подготовки и координации, прежде чем вы сможете их реализовать.
- Усилить аутентификацию
- Ужесточьте свои GitHub Actions рабочие процессы
- Подготовьтесь к инциденту с безопасностью
Укрепление проверки подлинности
Слабая или скомпрометированная аутентификация — одна из самых распространённых причин захвата аккаунта. Требование строгой аутентификации в вашей организации значительно снижает этот риск.
Требовать двухфакторную аутентификацию (2FA) для всех участников, что гарантирует, что одного скомпрометированного пароля недостаточно для доступа к аккаунту. Перед тем как применять требование, свяжитесь с вашей организацией, чтобы у членов было время настроить 2FA.
Организации могут GitHub Enterprise Cloud пойти дальше, внедрив единый вход (SSO), который централизует аутентификацию через вашего провайдера идентификации.
См. раздел [AUTOTITLE и Обязательная двухфакторная проверка подлинности в вашей организации](/enterprise-cloud@latest/organizations/managing-saml-single-sign-on-for-your-organization/about-identity-and-access-management-with-saml-single-sign-on).
Ужесточьте свои GitHub Actions рабочие процессы
GitHub Actions Рабочие процессы часто имеют доступ к секретам, учетным данным развертывания и правам на запись в ваш репозиторий. Без тщательной настройки скомпрометированное или вредоносное действие может вывести данные или внедрить вредоносный код.
Явно объявить права на рабочий процесс
По умолчанию рабочие процессы могут получать широкие права через GITHUB_TOKEN. Чётко указывайте минимальные права, необходимые каждому рабочему процессу, используя ключ permissions в ваших файлах рабочего процесса. Это ограничивает ущерб, который может нанести скомпрометированный шаг в рабочем процессе.
Фиксируйте действия третьих лиц для совершения SHA
Когда вы ссылаетесь на действие третьей стороны по тегу (например, v1), тег можно переместить так, чтобы он указывал на другой код. Закрепление действий на полный коммит SHA гарантирует, что вы всегда запускаете тот самый код, который вы проверили и одобрили. Это защищает от атак в цепочке поставок, когда метка захватывается.
Ограничить, какие действия могут выполняться
Настройте политики на уровне организации или предприятия, чтобы контролировать, какие действия разрешены выполняться. Вы можете ограничить действия теми, что созданы GitHub, действиями проверенных авторов или конкретным списком разрешений.
Для получения дополнительной информации обо всех этих практиках, а также о дополнительных безопасных практиках использования именно GitHub Actions для Справочник по безопасному использованию.
Текущие практики безопасности
Эти практики должны стать частью вашего обычного рабочего ритма.
- Следите за своим состоянием безопасности с помощью обзора безопасности
- Проводите регулярные кампании по обеспечению безопасности для снижения долгов по обеспечению
- Продолжайте аудит доступа и разрешений
- Поддерживайте зависимости в актуальном состоянии
- Ротация секретов и обеспечение истечения срока действия
Следите за своим состоянием безопасности с помощью обзора безопасности
Обзор безопасности даёт централизованный обзор ландшафта безопасности организации и предприятия. Используйте его для отслеживания, в каких репозиториях включены функции безопасности, и чтобы выявлять репозитории с открытыми оповещениями, чтобы возникающие риски не оставались незамеченными.
Проводите регулярные кампании по обеспечению безопасности для снижения долгов по обеспечению
Со временем оповещения о безопасности могут накапливаться. Кампании по безопасности позволяют организовать и расставлять приоритеты в устранении, назначать группы оповещений разработчикам (с помощью Copilotисправлений), или назначать оповещения напрямую на Copilot.
Кампании безопасности доступны организациям на включённой GitHub Team или GitHub Enterprise Cloud с GitHub Secret Protection or GitHub Code Security включёнными функциями. См . раздел AUTOTITLE.
Продолжайте аудит доступа и разрешений
По мере того как люди присоединяются и уходят из организации, а также по мере развития проектов, требования к доступу меняются. Планируйте периодические обзоры:
- Членство в организации и роли.
- Доступ к внешним сотрудникам.
- Разрешения на уровне репозитория и назначения команд.
- Авторизовано OAuth и GitHub Apps.
Это гарантирует, что доступ остаётся в соответствии с принципом наименьшей привилегии, даже когда ваша организация меняется.
Поддерживайте зависимости в актуальном состоянии
Уязвимые зависимости — распространённая точка входа для злоумышленников. Dependabot Могут автоматически открывать pull requests для обновления зависимостей с известными уязвимостями, но эти pull requests всё равно нужно оперативно проверять и объединять.
Создайте процесс сортировки и объединения Dependabot pull-запросов, чтобы обновления безопасности не зависали.
См. раздел [AUTOTITLE и Сведения о правилах автообработки Dependabot](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/managing-pull-requests-for-dependency-updates).
Ротация секретов и обеспечение истечения срока действия
Чем дольше существует удостоверение, тем выше вероятность его раскрытия или кражи. Где возможно:
- Установите даты истечения срока действия на personal access tokens.
- Регулярно меняйте секреты.
Для информации об управлении токенами см. Управление личными маркерами доступа и Истечение срока действия и отзыв маркера.
Дальнейшие действия
- Даже при сильном превентивном контроле возможны инциденты с безопасностью. Существует несколько ключевых инструментов и процессов реагирования, которые следует заранее настроить. См . раздел AUTOTITLE.