Comments 15
Тогда уж проще по Честертону (патер Браун) прятать деревья в лесу. Создавать миллиарды фейковых копий нужной информации.
Такой метод работает без шифрования, просто используя внимание атакующего как детектор атаки.
Скажите адрес вашего сервера и я одним редиректом сделаю так, чтобы вы забанили сами себя.
Если спрятать секрет внутри безобидного файла — можно обойтись без шифрования.
Никто же не будет заниматься стеганоанализом просто так или по наводке, да?
Например, лог-файл можно читать только на конкретном сервере, с определённой ОС, с заданной архитектурой.
Реализовано в проекте с air-gapped инфраструктурой: файл конфигурации бесполезен вне нужной машины.
Чтобы закомментировать пару строчек в нём нужен IQ >= 0.
В проде это использовалось для защищённого логирования в CI/CD пайплайне: никто не может подделать результат сборки, даже имея доступ к файлам.
У вас приватный ключ лежит в скрипте, имея доступ к файлам его легко получить.
по требованиям регулятора: данные должны быть "в открытом виде"
Даже если файл попал наружу — он бесполезен без "контекста доступа"
Если данные в открытом виде попали наружу, то бесполезен уже ваш "контекст доступа".
Я не уверен что все примеры являются альтернативой шифрованию, и решаемых им задач. Больше похоже на некие наброски в духе "шифрование не прячет данные, а вот стегонаграфия это делает". Круто конечно, но безопасности обмена данными между серверами это не особо добавляет, да и как правило там не стоит задача прям ныкать этот трафик.
Я когда-то в мохнатые годы делал полиморфный js для отображения капчи - 15-20кб минифицированного одноразового кода, который на лету создается сервером каждый раз с чуть разной формулой, а предрасчитаный результат лежит в сессии. Сама капча рендерилась из квадратиков 8х8 пикселей... Все школо-спамилки сходу отвалились, ибо для спама такого форума нужно было цеплять селениум вместе с браузером как минимум (иначе капчу не отрендерить), что в те времена было затратно по ресурсам и медленно.
Звучит довольно интересно, хотя отказ от шифрования кажется все еще не очень безопасным.
А что насчет использования в таких кейсах контроля через поведенческую аналитику( UBA/UEBA )? Как я помню, там логика строится на baseline активности и анализе аномалий.
Условный пример:
"Этот пользователь обычно работает с 9 до 18, не делает скачивания более 50MB, и никогда не лез в прод-серверы. Почему он в 3:40 ночи качает dump из MongoDB?"
Потому что он запланировал создание бэкапа на период низкой нагрузки.
Хороший поинт к условному примеру) Конечно, кто в здравом уме не запускает ручной бэкап Mongo в 3:40 ночи, нарушая все корпоративные регламенты, с нетипичного хоста, под новым агентом, без предварительного уведомления? Прям классика DevOps'псины)
Собственно, для такого поведенческая аналитика и существует — не чтобы кидаться на каждый ночной скрипт, а чтобы отличать "нормальную автоматизацию" от "что-то здесь не так, сэр".
Она не бьёт по рукам за работу вне графика — она говорит: "А это вообще он? И почему он теперь качает больше, чем обычно, и с другого IP, и не тем скриптом?"
Так что если это действительно бэкап — отлично. Пусть сработает сигнал, система проверит контекст, и ничего не заблокирует. А вот если это слив клиентской БД через curl в tmp-папку — лучше узнать об этом сразу, чем в пресс-релизе через неделю.
Ну вот меня в Альфа-банке сейчас так неделю мурыжили. Обычно ведь я ничего не делаю, а тут вдруг начал движения денег - наверняка мошенникам их перевести хочу.
Вы, вместо того, чтобы придумывать условия на ходу, подумайте лучше над прозрачностью. Коли уж у вас там всплыли регламенты, то там должно быть прописано, кто и когда может делать бэкапы, а кто - нет. И это должно быть всем понятно заранее, а не в момент, когда ты пытаешься справиться с факапом, но система посчитала твои действия подозрительными.
Сойдет только для прода, куда без регламента не лезут. Для разработки ооочень спорно и требует ручного контроля эвристик со стороны СБ... Я вот, например, часто работаю вечером. потому что там пик активности - и коммиты в час ночи не новость.
Считаю это вредными советами. Все эти методы работают только против совсем не опытных "исследователей", и у кого-то могут создать ложное чуство защищенности...
Слушайте, объясните мне, пожалуйста, каким образом успешное открытие файла на чтение скриптом служит маркёром того, что кто-то в него полез? В упор не пойму, что этот скрипт, собственно, проверяет. Если бы проверялось то, не создал ли кто-то эти файлы, я бы понял, это подобным образом проверить можно. Но почему успешное открытие на чтение говорит о том, что кто-то файл прочитал?
Все предложенное, кроме ловушек и проверки среды, шифрование в том или ином виде.
Всё предложенное, кроме Вами упомянутого — аутентификация и… аутентификация (читайте: подписи и их проверка).
Стега тоже шифрованием не является (но может — и часто используется — в связке).
Погадать на таро онлайн: 5 проверенных сервисов с консультацией профессионального таролога