Назад | Перейти на главную страницу

Настройка NGINX для соответствия GDPR (= RGPD, DSGVO) с использованием анонимных IP-адресов в старых файлах журнала

Европейский Общие правила защиты данных Закон (GDPR) направлен на защиту конфиденциальности конечных пользователей. Поэтому среди многих других последствий системные администраторы вынуждены настраивать свои системы таким образом, чтобы они не хранили IP-адреса в течение ненужных длительных периодов времени, не без согласия и так далее. Это потому, что IP-адреса считаются личными данными.

Тем не менее, согласно GDRP, есть веские причины для не анонимизация IP-адресов с самого начала. Например, нужны средства для защиты системы от атак (например, для защиты личных данных многих пользователей в базе данных). Например, если ваша система в настоящее время подвергается атаке, и эта атака исходит от одного определенного IP-адреса, вам необходимо иметь возможность заблокировать этот IP-адрес (возможно, только временно). Вы также можете проверить, когда началась атака, то есть когда начались плохие запросы с этого IP-адреса. Более того, вы часто хотите хранить свои файлы журналов в течение более длительного периода времени, чтобы вы могли их анализировать (что совершенно нормально, если они не содержат личных данных).

Итак, это конкурирующие интересы. Одним из простых компромиссов является хранение исходных IP-адресов в файлах журнала только на короткий период времени, анонимизация IP-адресов в старых файлах журнала и, конечно же, информирование ваших пользователей / посетителей об этих фактах (на ваших веб-сайтах. Уведомление о конфиденциальности).

Как я могу настроить NGINX для такой настройки, соответствующей GDPR, которая не анонимизировать все IP-адреса с самого начала? Существуют обсуждения и решения для мгновенной / прямой анонимизации IP-адресов (например, Вот); но как я могу настроить анонимизация только для старых файлов журналов?

Предостережение: IANAL

Такую гибридную настройку можно легко настроить для наличия неанонимных краткосрочных журналов и анонимных долгосрочных журналов. Уловка состоит в том, чтобы позволить logrotate вращать ваши журналы NGINX и анонимизировать их в ходе ротации. Это также переносит (небольшую) бремя анонимизации с загруженного веб-сервера на процесс logrotate.

Прежде всего, вам понадобится скрипт для анонимизации файлов журналов доступа. Один из вариантов anonip.py от Digitale Gesellschaft (ранее Swiss Privacy Foundation). Использование такого специального внешнего инструмента имеет преимущество перед быстрым и грязным самодельным скриптом, с которым он может справиться, например Адреса IPv6 и IPv4 и так далее. Но вы, конечно, можете дополнительно использовать свой собственный сценарий, например, чтобы анонимизировать и другие части в файле журнала (например, параметр URL userId вашего веб-приложения).

Так что скачайте и установите скрипт:

 cd /usr/local/bin
 wget https://raw.githubusercontent.com/DigitaleGesellschaft/Anonip/master/anonip.py
 chmod 755 anonip.py

Затем создайте или отредактируйте свой /etc/logrotate.d/nginx файл примерно так:

/var/log/nginx/*.log {
    weekly
    missingok
    rotate 52
    maxage 365
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    prerotate
        if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
            run-parts /etc/logrotate.d/httpd-prerotate; \
        fi \
    endscript
    postrotate
        /usr/sbin/invoke-rc.d nginx rotate >/dev/null 2>&1 ;
        /usr/local/bin/anonip.py < "$1".1 --output "$1".1.anon ;
        /bin/mv "$1".1.anon "$1".1 ;
    endscript
}

По сути, он ведет неанонимный журнал доступа в течение одной недели. Раз в неделю файл обновляется и анонимизируется. Предполагается, что повернутый файл имеет суффикс .1. Он хранит анонимные данные в течение одного года. Конечно, можно настроить эту настройку, например, суточная ротация и т.д ...