Комментарии 23
И кстати, что если разработчик попробует запушить коммит, содержащий (возможно, в сжатом виде) этот же файл через клиент git для командной строки?
Это даже покруче чем отправка документов на серверы Касперского.
Вопросы:
- А если Ms Sql имеет пароль в 10 символов, то сколько символов надо добавить в Device Lock?
- Считается ли ключ скомпрометирован, если известны пара десятков символов?
- Как проверятся, что в Device Lock сохранилась только часть ключа/пароля, а не весь?
Получается ужас: если раньше пароль от SQL сервера был известен паре админов, то с Device Lock он растечется по всем компьютерам с клиентами Device Lock (в том числе — на комп бухгалтера и т.д.)
не растечется ничто никуда ибо DeviceLock DLP ничего не знает о ваших ключах и паролях.
Вот же в статье расписано:
Добавим файл ключа в базу цифровых отпечатков DeviceLock DLP, чтобы продукт «знал» наш ключ «в лицо» и мог позже его однозначно идентифицировать (и не спутать, например, с тестовыми ключами, которые вполне могут загружаться на GitHub).
Как раз-таки знает. И совет продавцов/маркетологов Device Lock — загружать целый ключ (как мы видим из статьи).
Пока выглядит как красивый маркетинг, который скрывает дыру в безопасности.
Задача: запретить распротранение пароля от Ms Sql и RSA ключа.
Если админ делает всё по советам из этой статьи, то что конкретно хранит Device Lock?
- на сервере:
- в настройках
- в логах
- на клиентских машинах:
- в настройках/оперативной памяти
- в логах
Варианты: он хранит весь пароль, он хранит хеш (например, SHA* или сапописный) и т.д.?
Хэш пароля
Вот, так и надо писать — хеш данных. А какой хеш? Какой алгоритм? Я надеюсь вы использовали что-то лучше чем "не имеющее аналогов проприетарное решение"?
Далее — если вы ищете пароль как подстроку в тексте, то как вы это делаете? Какой алгоритм хеширования вы использовали, который позволяет эффективно искать подстроку? Ведь не хеширование Рабина-Карпа? Насколько стойкий этот хеш с точки зрения криптографии? Он подсоленный или доступен для взлома с помощью радужных таблиц?
Вы поймите, с точки зрения маркетинга всё выглядит классно. А на деле все пароли скидываются в общее хранилище, а потом бесконтрольно раздаются по сети. В итоге малейшая ошибка в ваших закрытых алгоритмах — и скомпрометировано вообще всё.
Давайте считать это халатностью.
Не знаю, как принято сейчас, но раньше фирмы ставили DLP, в основном, для защиты коммерческих данных — списка клиентов, внутренней документации, etc. На безопасность бизнесу обычно насрать — пока не случится факап и не пойдут репутационные потери, а то и штрафы. Нет, формально все заявляют, что безопасность их очень заботит, но на практике бюджет и время на обеспечение этой безопасности большинство компаний выделять не торопится, все ресурсы уходят на максимально быстрое развитие функционала продукта.
Так что является ли халатностью инженера заливание ключей от AWS на гитхаб, или это халатность начальства, которое не то, что не выделило ресурсы на то, чтобы у инженера вообще было время задуматься о последствиях своих действий для безопасности, но и не озаботилось тем, чтобы доступ к этим ключам в принципе был всего у пары человек, которые понимают, как нужно с ними обращаться — это вопрос.
Я понимаю, что Ваше дело рекламировать свой продукт, но на практике толк от этой фичи вряд ли будет: если в компании понимают, как обращаться с такими данными, то на гитхаб они не попадут просто потому, что правильно поставленные процессы этого не допустят (люди, у которых есть эти ключи, сами такую глупость не сделают, а у остальных доступа к ключам просто не будет). Ваш же подход подразумевает, с одной стороны, достаточно хорошо налаженный процесс, чтобы все такие данные своевременно добавлялись в базу DLP, а с другой бардак, при котором доступ к таким данным имеют разработчики, не понимающие, что такое на гитхаб не заливают. На мой взгляд — это достаточно редкий кейс, а в остальных реальной пользы от фичи нет.
Так я про реальный и писал. В реальном мире единственное, что изменится — кто-то победно отчитается о добавлении жутко полезной фичи в DLP, кто-то победно отчитается о покупке и установке нового DLP который "ничего не пропустит!!!!111", а когда случится ровно тот же факап (а он обязательно случится, потому что процессы остались теми же, а сама по себе установка DLP магически проблему не решает) инженер заливший ключ скажет на голубом глазу "а я был уверен, что этот ключ заливать можно — иначе его бы DLP не пропустил", и в результате слонов выдадут не только ему, но и тому, кто отвечает за DLP.
Для начала то что вы показали это обычный RSA ключ, а "ключ AWS" это пара secret key + access key
Как DeviceLock DLP предотвращает утечки конфиденциальных данных на GitHub