Комментарии 4
Спасибо за подробный технический разбор, но если уж упомянуты безопасники, то было бы неплохо осветить и процессную часть процедуры (идеально в призме ГОСТ Р 56939/РБПО, опять я со всоими бумажками :)
Кто имеет право чистить
Как доказать, что очистка прошла успешно
Где хранятся ключи/логи очистки (это уже техника, но понадобится для легализации данной процедуры, а не просто узкое решение конкретной технической задачи)
Подходы к этим вопросам разнятся от компании к компании настолько, что позитивный опыт одной может оказаться вредным для другой. Попробую ответить лишь субъективно и вне призмы ГОСТ Р 56939/РБПО, так как я с ним не знаком.
Кто имеет право чистить
В моём понимании это должен быть кто-то из инженеров по эксплуатации, т.е. тот, кто максимально близок к боевому приложению, но при этом достаточно далёк от разработки, чтобы не иметь необходимых знаний и навыков для извлечения конфиденциальных данных из дампа в корыстных целях.
Как доказать, что очистка прошла успешно
Теми же самыми OQL-запросами, которыми изначально проверялось наличие важных данных в дампе (см. первый раздел статьи). Понятно, что набор этих запросов может быть большим, а их составление - трудоёмким, но такова цена за уверенность. Возможно, есть и более простые/дешёвые способы, опирающиеся на специфику конкретного приложения.
Где хранятся ключи/логи очистки
Либо у того, кто осуществлял очистку (см. ответ на п.1), либо среди логов pipeline’а, в который была встроена очистка. Во втором случае эти логи не являются предметом особой защиты, так как ни один из описанных инструментов не логирует сами очищаемые данные, а лишь фиксирует шаги/этапы очистки.
На мой взгляд, ответ на первый вопрос - робот.
Должна быть кнопка снять дамп. Дамп снимается и тут же обфусцируется. Если особо упороться, то это можно сделать потоково. Прямо во время снятия дампа.
И уже обфусцированный дамп передаётся дальше. На хранение и анализ.
И тогда точки утечки просто не появляется.
Анализируем heap‑дампы с прода, не привлекая внимания безопасников