Незаменимые практики безопасности, о которых вы, возможно, забыли.
Вопрос защиты данных на GitHub всё чаще обсуждается разработчиками. Только в этом году платформа неоднократно попадала в новости из-за инцидентов с вредоносным ПО, уязвимостей высокой степени опасности и случаев удаления данных, которые представляют риск для пользовательских данных.
Как разработчики могут защитить свою среду GitHub?
Широко рекомендуемые практики включают:
— контроль доступа по принципу наименьших привилегий;
— регулярное тестирование;
— аутентификацию API;
— частую ротацию токенов доступа;
— использование SSH-ключей.
Тем не менее, особое внимание следует уделить резервному копированию. Создание надёжной системы резервного копирования GitHub является важнейшим элементом эффективной защиты данных.
Почему необходимо создавать резервные копии учётной записи GitHub?
Согласно отчёту о состоянии угроз DevOps от GitProtect.io, количество инцидентов, затронувших пользователей GitHub в 2023 году, выросло более чем на 21%. Около 13.94% произошедших событий оказали существенное влияние на работу сервиса.
При анализе первого и второго кварталов 2024 года видно, что уже произошло более 70 инцидентов, повлиявших на пользователей GitHub различными способами. Стоит отметить, что в 2023 году произошло более 160 различных инцидентов, начиная от серьёзных воздействий и заканчивая техническим обслуживанием.
Важность резервного копирования среды GitHub
Может произойти что угодно, поэтому всегда разумно готовиться к наихудшим сценариям. В таких случаях наличие резервной копии может помочь следующим образом:
- Защитить репозитории GitHub и метаданные от сбоев и других непредсказуемых угроз, позволяя восстановить копию в другом месте и обеспечить непрерывность рабочего процесса и бизнеса;
- Защитить от человеческих ошибок, таких как случайное удаление файлов;
- Обеспечить восстановление данных в случае атаки программ-вымогателей, поскольку резервное копирование является последней линией защиты;
- Выполнить требования модели общей ответственности, которая определяет роли и обязанности GitHub и его пользователей;
- Соответствовать требованиям безопасности и хранения данных, поскольку большинство протоколов безопасности и нормативных требований требуют от организаций более длительных сроков хранения, резервного копирования и гарантий аварийного восстановления.
Топ-10 советов для обеспечения эффективности плана резервного копирования GitHub
Учитывая все возможные киберугрозы, эффективный план резервного копирования должен помочь предвидеть любой сценарий катастрофы и гарантировать сохранность всех данных учётной записи GitHub.
Совет 1. Полный охват данных
Эффективное резервное копирование должно включать все репозитории и метаданные, такие как задачи, запросы на слияние, комментарии к задачам, веб-хуки, вики, метки, ключи развёртывания, проекты, конвейеры и Git LFS. Это поможет обеспечить полную целостность репозитория и всестороннюю защиту данных.
Совет 2. Автоматизация резервного копирования
Важно иметь возможность автоматизировать процессы резервного копирования путём планирования политик в наиболее подходящее время и с нужной частотой. Например, настроить план резервного копирования, запускающий создание копии каждые 4 часа.
Совет 3. Различные схемы выполнения резервного копирования
Чтобы не перегружать хранилище, должна быть возможность определять различные схемы ротации и выполнения для каждой настраиваемой резервной копии. Это могут быть полные, инкрементные или дифференциальные резервные копии.
Совет 4. Согласованность множественных хранилищ
Наличие нескольких копий в различных местах хранения позволяет исключить любой риск катастрофы и соответствовать правилу резервного копирования 3-2-1, которое требует иметь как минимум 3 резервные копии в 2 или более местах хранения, причём 1 должна быть удалённой.
Более того, когда речь идёт о местах хранения, должна быть возможность создавать резервные копии репозитория и связанных данных как в локальных, так и в облачных хранилищах.
Совет 5. Репликация резервных копий
Недостаточно просто иметь несколько копий в разных местах. Необходимо обеспечить возможность репликации между местами хранения резервных копий. В этом случае все копии будут согласованы, и при сбое данные можно будет восстановить из любого хранилища, если одно из них перестанет работать.
Совет 6. Длительное хранение
Срок хранения тесно связан с соответствием требованиям и восстановлением данных из любой точки в прошлом. По умолчанию GitHub хранит журналы сборки в течение 90 дней. Однако этого может быть недостаточно для организаций, работающих в регулируемых отраслях или требующих гораздо более длительных сроков хранения.
Решение для резервного копирования должно помочь решить эту проблему, обеспечивая длительное или даже неограниченное хранение. Таким образом, организация сможет восстановить свои данные из любой точки во времени, например, из периода 3 или 5 лет назад.
Совет 7. Прозрачное управление и мониторинг
Не все члены команды должны иметь одинаковый доступ к резервным копиям. Следовательно, программное обеспечение для резервного копирования должно позволять устанавливать различные роли и назначать разные обязанности членам команды.
Например, могут быть те, кто отвечает за настройку резервных копий GitHub, запуск восстановления в случае сбоя, только просмотр производительности резервного копирования, или системные администраторы, которые могут работать без ограничений.
Более того, всегда должны приходить уведомления о выполнении резервного копирования или восстановления с подробностями и статусами. Могут быть различные способы уведомления – электронная почта, Slack, веб-хуки, а также специальная консоль со всей информацией на основе данных, задачами, SLA и отчётами о соответствии требованиям.
Совет 8. Шифрование при передаче и в состоянии покоя
Репозиторий GitHub и метаданные должны быть защищены на каждом этапе – при передаче и в состоянии покоя. Более того, в качестве дополнительной меры безопасности должна быть возможность установить персональный ключ шифрования.
Также устройство не должно хранить информацию о ключе шифрования, оно должно получать его только во время выполнения резервного копирования, чтобы соответствовать подходу нулевого шифрования.
Совет 9. Защита от программ-вымогателей
Поскольку резервное копирование является последней линией защиты, оно должно быть защищено от программ-вымогателей. Неизменяемое хранилище, которое помогает хранить данные в неисполняемом формате, готовое к любому сценарию атаки. Аварийное восстановление и шифрование должны быть организованы и работать как часы для обеспечения защиты и восстанавливаемости данных GitHub. Более того, программы для резервного копирования должны гарантировать безопасную авторизацию доступа, например, через протоколы SAML SSO.
Совет 10. Аварийное восстановление
Наличие согласованной резервной копии GitHub должно означать возможность экстренно восстановить данные при любом сбое — атаке программ-вымогателей, отказе сервиса, простое инфраструктуры и т.д. Решение для резервного копирования должно позволять восстанавливать данные полностью или выборочно – только выбранные метаданные или репозитории.
Защитное решение также должно иметь возможность восстанавливать данные GitHub в ту же или новую учётную запись GitHub, на локальный компьютер или выполнять кросс-восстановление на другую платформу размещения Git, такую как GitLab, Bitbucket или Azure DevOps.
Более того, во время процесса восстановления не следует перезаписывать существующие данные, а иметь возможность восстановить их как новый файл.
Эффективно ли моё резервное копирование GitHub?
Чтобы быть уверенным в эффективности процессов резервного копирования, для начала стоит убедиться, что они соответствуют всем вышеупомянутым советам.
Однако вопрос о том, как построить стратегию резервного копирования для среды GitHub, следует решать с учётом требований безопасности и соответствия нормативам, размера экосистемы GitHub, оценки рисков потери данных и других факторов.
Можно использовать опцию архивированного скачивания для файлов и папок, а также скрипты резервного копирования, однако они не обеспечат автоматизацию, надлежащую защиту от программ-вымогателей и возможность восстановления. В этом случае вся ответственность за защиту данных GitHub лежит на стороне пользователя.
В качестве альтернативы можно использовать специализированное программное обеспечение для резервного копирования, которое поможет как распределить обязанности по защите данных GitHub, так и обеспечить доступность и восстанавливаемость данных в любом сценарии катастрофы.
С запланированными автоматизированными процедурами резервного копирования, полным охватом данных, выбором места хранения данных, защитой от программ-вымогателей и расширенными мерами аварийного восстановления, вы точно можете быть уверены в том, что каждая строка исходного кода защищена.