Беспрепятственные коллаборации в модели GitHub создают головную боль, связанную с безопасностью. Следуйте этим семи принципам, чтобы улучшить ситуацию.
На прошлой неделе компания Okta объявила об инциденте безопасности, в результате которого злоумышленник получил доступ к исходному коду компании, размещенному на GitHub. Это лишь последний пример в длинной череде атак с получением доступа к исходному коду компании на GitHub. Dropbox, Gentoo Linux, и Microsoft уже подвергались атакам на свои аккаунты на GitHub.
GitHub, насчитывающий 90 миллионов активных пользователей, является самым популярным инструментом управления исходным кодом как для открытых, так и для частных корпоративных хранилищ кода. Это важный элемент фундаментальной инфраструктуры и хранитель некоторых из самых конфиденциальных активов и данных в мире.
Неудивительно, что злоумышленники все чаще охотятся за исходным кодом. В некоторых случаях, как в случае с Okta, они могут пытаться получить доступ к исходному коду. Чаще всего злоумышленники ищут конфиденциальную информацию, чтобы использовать ее в последующей атаке.
Злоумышленник, получивший доступ к закрытому исходному коду, может изучить его на предмет уязвимостей, а затем использовать эти уязвимости в последующих атаках. Злоумышленники также могут собирать закодированные ключи, пароли и другие учетные данные, которые могут храниться в GitHub, чтобы получить доступ к облачным сервисам и базам данных, размещенным в AWS, Azure или GCP. Один украденный репозиторий может дать интеллектуальную собственность, действительные учетные данные и хороший список уязвимостей в производственном программном обеспечении, готовых к эксплуатации.
Shiny Hunters, группа хакеров, известная тем, что атакует частные репозитории GitHub, взломала десятки компаний, используя эту технику, и продала их данные на различных торговых площадках DarkNet.
Обеспечение безопасности среды GitHub организации.
Несомненно, GitHub является важной частью инфраструктуры организации, но его блокировка представляет собой сложную и трудную проблему. Прелесть модели GitHub в том, что он позволяет беспрепятственно работать совместно, но это также создает одну из самых больших головных болей в современной ИТ-безопасности.
Только подумайте об этом: любой человек, занимающийся техническими вопросами в 2022 году, имеет учетную запись на GitHub. И вы можете использовать свой аккаунт GitHub для всего. Мы можем использовать эти учетные записи для личных проектов, вклада в открытый исходный код, а также для работы в публичных и частных хранилищах кода, которые в конечном итоге принадлежат нашим работодателям. Это очень много для одной учетной записи!
Вы также можете использовать функцию «Войти с GitHub», чтобы использовать свою учетную запись GitHub на других сайтах и сервисах, помимо самого GitHub. И это еще не все: GitHub уникален тем, что вы не просто входите на его сайт, вы также извлекаете и клонируете код с серверов GitHub на вашу локальную машину с помощью операций git по HTTPS и SSH, которые сами по себе требуют вашей идентификации GitHub.
Очевидно, что GitHub осознал эти последствия для безопасности, когда в прошлом году объявил об отказе от использования имен пользователей и паролей для операций git - это шаг в правильном направлении.
7 советов по обеспечению безопасности GitHub.
Хотя GitHub предоставляет инструменты для блокировки среды, организации должны знать, как их использовать. К сожалению, некоторые из наиболее важных возможностей обеспечения безопасности требуют наличия GitHub Enterprise. Тем не менее - вот семь принципов для повышения безопасности GitHub.
- Не разрешайте использовать личные аккаунты для работы. Мы понимаем, что у вашей компании есть несколько публичных репозиториев, и вы можете укрепить свой авторитет, продемонстрировав несколько публичных вкладов на следующем собеседовании. Ваш личный аккаунт на GitHub - это часть вашего бренда. К сожалению, это также одна из самых больших дыр в организациях, использующих GitHub сегодня: Они не строго регламентируют использование личных аккаунтов в рабочих целях. Как бы это ни было заманчиво, личные аккаунты не должны использоваться для работы. Нет способа контролировать, кто имеет доступ к личному адресу Gmail, который вы использовали для создания личного аккаунта GitHub.
- Требуйте аутентификации через SSO компании. К сожалению, GitHub занимает видное место на «Стене позора SSO». Все верно - за интеграцию SSO нужно платить дополнительно. После приобретения GitHub Enterprise вы можете подключить GitHub к SSO вашей компании - например, Okta, Azure AD или Google Workspace - и разрешить аутентификацию только через SSO.
- Требуйте 2FA для всех учетных записей. Даже если вы применяете двухфакторную аутентификацию (2FA, она же MFA) через SSO, а также требуете аутентификацию через SSO, самым безопасным вариантом будет применение 2FA для всех пользователей GitHub в вашей организации. Группы исключений и исключения из политики в провайдере SSO могут сделать SSO MFA уязвимой.
- Используйте SSH-ключи для операций с git. Хотя GitHub ввел тонкий контроль разрешений с помощью персональных маркеров доступа (PAT), они по-прежнему подвержены фишингу, поскольку эти маркеры часто копируются в открытом виде. Используя ключи SSH для аутентификации в операциях git, ваша организация может использовать продуманную PKI для управления предоставлением ключей SSH, а также связать это с управлением устройствами вашей компании и собственным центром сертификации.
- Ограничьте привилегии членов репозитория с помощью ролей. GitHub предлагает несколько различных ролей репозитория, которые могут быть назначены на основе принципа наименьших привилегий. Базовые разрешения можно контролировать на уровне организации. Всегда старайтесь назначать наименее привилегированную роль, которая необходима пользователю для продуктивной работы. Не делайте всех администраторами.
- Не допускайте привлечения сторонних сотрудников. Работа с подрядчиками - нормальная часть управления крупными программными проектами. Однако управление, окружающее внешних партнеров в GitHub, недостаточно для обеспечения безопасности вашей организации. Вместо этого заставьте внешних работников проходить аутентификацию через SSO вашей компании и не позволяйте администраторам репозиториев приглашать их непосредственно в репозитории вашей организации.
- Аудит, анализ и еще раз аудит. Ни одна организация не является идеальной; даже при наличии самых лучших политик учетные записи проскальзывают сквозь трещины и совершаются ошибки. Еще до блокировки организации GitHub уделите время внедрению регулярного процесса аудита для поиска неактивных учетных записей, которые не используют свой доступ, и ограничения количества привилегированных ролей в ваших репозиториях. После блокировки среды следите за нарушениями политики, например, за пользователями, которые каким-то образом продолжают аутентифицироваться вне SSO или не используют 2FA.
Взлом репозитория GitHub компании Okta является ярким примером того, насколько сложно защитить идентификационные данные на предприятиях, но это не единственный пример. Каждый день мы видим, что происходит, когда сотрудники и подрядчики сталкиваются с захватом учетных записей. Мы видим последствия слабой аутентификации, небрежной политики в отношении личных учетных записей электронной почты и постоянно расширяющейся поверхности атаки на идентификационные данные.
К сожалению, этот последний инцидент - лишь одна из составляющих растущей тенденции нарушения идентификационных данных, которую следует ожидать в 2023 году.
Источник: https://www.darkreading.com/
