Безопасный логгинг

Уж казалось бы, насколько логирование распространенная и очевидная практика, но сколько в ней нерешенных и нерешаемых вопросов! Один из сложнейших – безопасность. А точнее угроза конфиденциальности через утечки чувствительных данных в лог. В чем сложности?

Первая – что считать конфиденциальным. Ну, логин/пароль или данные банковских карт – само собой. Но ведь бывают ситуации, что адрес какой-то структуры/функции тоже становится конфиденциальным, если используется ASLR защита (как, например, в недавнем случае с Samsung).

Вторая – как не допустить утечки. Из подходов на уровне кода есть паттерн типа read-once/read-twice/read-X-times, когда для объекта вы контролируете счетчик чтений и ставите такой максимум, чтобы «лишние» чтения (в том числе в лог) не состоялись. Другой вариант — использовать отдельное хранилище для секретов, чтобы в памяти процесса plain-ом чувствительные данные в принципе не фигурировали. Также подходы уровня кода можно разнообразить расширением процессов — например, более строгие процессы code review, или CI с сервисами, проверяющими на типичные секреты, типа snyk.io.

Третья – как проверить. Для полноценных проверок нужна высокая степень покрытия (юнитами и фаззингом), приправленная прогоном утилит, которые бы искали уже утекшие секреты в логе (DLP-alike). Однако системы, оперирующие сенситивными данными, не должны писать в лог; а если уж писать, то очень боязливо. Хотя лучше никому в лог не писать вообще, потому что неясно, какие данные сенситивные. Но здесь security сталкивается с debugability, удобством отладки. А к debugability прилегает скорость расследования инцидента, которая тоже про безопасность.

В общем, логи нужны, логи важны, но не забывайте правильно их обезопасить.

#digest