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

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

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

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

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

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

1
задан 27 August 2019 в 16:46
1 ответ

Такую гибридную установку можно легко настроить для наличия неанонимных краткосрочных журналов и анонимных долгосрочных журналов. Хитрость заключается в том, чтобы позволить 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 . Он хранит анонимные данные в течение одного года. Конечно, можно настроить эту настройку, например, суточная ротация и т.д ...

0
ответ дан 4 December 2019 в 02:43

Теги

Похожие вопросы