В последнее время стало много новостей про случайные утечки различных конфиденциальных данных из веб-сервиса для хостинга IT-проектов и их совместной разработки GitHub.
Подчеркну, что речь пойдет именно о случайных утечках, т.е. произошедших по неосторожности и без злого умысла со стороны виновников инцидентов. Списать такие утечки на неопытность сотрудников в вопросах IT не получится, т.к. пользователи GitHub -это в подавляющем своем числе разработчики, т.е. вполне квалифицированные и грамотные кадры. К сожалению, даже очень хорошие специалисты порой допускают банальные ошибки, особенно если дело касается вопросов безопасности. Давайте считать это халатностью.
Приведу несколько очень известных примеров, связанных с GitHub:
- 2014 год — компания Uber допустила утечку персональных данных 50 тысяч своих водителей. Причиной было то, что в публичный репозиторий GitHub разработчики Uber сохранили ключи доступа к облаку Amazon (AWS), на котором, в свою очередь, хранились те самые утерянные данные.
- 2017 год — выяснилось, что разработчики производителя квадрокоптеров DJI сохранили в публичном репозитории GitHub закрытый ключ SSL-сертификата компании и AES-ключи для шифрования прошивок. Кроме того, там же хранились учетные данные для Amazon Web Services, в котором, в свою очередь, находились журналы полетов, данные паспортов и водительских удостоверений клиентов DJI.
- 2017 год – инженер крупного американского IT-аутсорсера DXC Technologies загрузил ключи доступа к AWS в публичный репозиторий GitHub.
- 2017 год — в публичном репозитории GitHub обнаружились исходные коды, отчёты и планы разработки нескольких крупных финансовых организаций Канады, США и Японии, которые поместили туда сотрудники индийской аутсорсинговой компании Tata Consultancy Service, чьими заказчиками были пострадавшие финансовые учреждения.
Очевидно, что все эти случаи непреднамеренных утечек легко можно было бы предотвратить посредством контроля загружаемых на GitHub данных. Никто не говорит о тотальном запрете доступа к GitHub, это бессмысленная и даже вредная идея (если есть запрет, но сервис нужен, то разработчики этот запрет обойдут). Необходимо решение, предотвращающее утечки информации и обладающее анализатором контента в реальном времени, не дающее загрузить в GitHub только те данные, которых там быть не должно по соображениям безопасности (например, ключи доступа к облаку Amazon).
Покажу, как можно решить данную конкретную задачу, на примере DeviceLock DLP. Исходные данные у нас такие:
- Аккаунт на GitHub,
- Ключ AWS,
- DeviceLock DLP версии 8.3.
Для начала определим, что защищаемыми данными является ключ AWS и его попадание на GitHub необходимо предотвратить.
Поскольку ключ представляет собой набор байт без каких-либо выраженных сигнатур (да, я знаю о тексте “BEGIN/END PRIVATE KEY” в начале и в конце, но это очень слабая сигнатура и лучше на нее не опираться), то мы будем использовать идентификацию по цифровым отпечаткам.
Добавим файл ключа в базу цифровых отпечатков DeviceLock DLP, чтобы продукт «знал» наш ключ «в лицо» и мог позже его однозначно идентифицировать (и не спутать, например, с тестовыми ключами, которые вполне могут загружаться на GitHub).
Теперь создадим в DeviceLock DLP правило контентной фильтрации для файловых хранилищ (GitHub попадает под нашу классификацию «файловые хранилища», в рамках которой помимо GitHub поддерживается еще более 15 различных сервисов файлового обмена и синхронизации).
Согласно этому правилу, любым пользователям запрещена загрузка данных с цифровыми отпечатками, совпадающими с заданными выше, а при обнаружении запрещенных данных в журналы централизованного архива должны записываться соответствующие события (записи об инциденте) и теневые копии, помимо собственно исполнения действия с запретом загрузки данных на GitHub.
Давайте теперь попробуем загрузить ключ AWS в репозиторий GitHub.
Как видно, процесс загрузки «почему-то» не удался, а DeviceLock DLP предупредил нас, что данная операция была им заблокирована (разумеется, сообщение настраиваемое и отключаемое).
При этом, если посмотреть в журнал теневого копирования DeviceLock DLP, там можно обнаружить тот самый ключ.
Таким образом, на данном примере было показано, как с помощью DeviceLock DLP решить частную задачу предотвращения утечки любых конфиденциальных данных (цифровые отпечатки можно снимать практически с любых файлов) в облачные хранилища.
Конечно, помимо предотвращения утечки данных на GitHub, можно еще проводить периодическую инвентаризацию репозиториев и выявлять в них информацию, которой там быть не должно. Для целей сканирования репозиториев GitHub созданы бесплатные утилиты Gittyleaks, Git Secrets, Git Hound, Truffle Hog и многие другие.