Принимая второе требование первым, для обеспечения защиты целостности необходимо либо подписать сообщения журнала, либо сгенерировать HMAC сообщений.Это, в свою очередь, требует, чтобы приложение имело доступ либо к закрытому ключу для подписи, либо к симметричному ключу для генерации кодов аутентификации.
Что, в свою очередь, означает, что вам необходимо ограничить доступ кваше приложение, чтобы ключ не мог быть извлечен из него.Это означает, что вы перешли от доверия к управлению доступом в файле журнала к доверию управления доступом в вашем приложении.Компромиссный доступ к приложению по-прежнему позволяет третьим сторонам модифицировать ваш файл журнала «поддерживаемым» способом.
Возможно, в зависимости от структуры вашего приложения и того, как оно развернуто, использовать принудительные средства управления доступом в журналефайл, чтобы сделать его доступным только для пользователей приложения, чтобы уменьшить возможность фальсификации или удаления существующих сообщений.Вы также можете периодически создавать резервные копии файла журнала и сравнивать содержимое, чтобы убедиться, что ничего не было изменено или удалено между резервными копиями.Это предполагает, что доступ к вашим резервным копиям также контролируется - третье лицо, которое может вмешиваться в ваши резервные копии, может изменять ваши файлы журналов необнаружимым образом.
Вы не упомянули, находится ли приложение на сервере,настольный компьютер или смартфон, поэтому особенности такого контроля доступа не входят в сферу применения этого ответа.
Что касается обеспечения успешного написания сообщения перед продолжением работы приложения, в log4j Apache содержатся приложения, которые поддерживаютэто МО (только не оборачивайте их в AsyncAppender…)