Закон Турции № 5651 и логи: централизованное управление журналами

Хранение логов по закону 5651 — это обязанность, вытекающая из регулирования интернет-среды Турции (Закон № 5651): организации, предоставляющие доступ в интернет сотрудникам, гостям или клиентам, должны хранить журналы распределения внутренних IP-адресов и записи доступа с доказуемой целостностью. Это не юридический текст, а руководство для ИТ-руководителя по централизованной архитектуре логов от FortiGate до FortiAnalyzer или syslog, меткам времени, хранению и контролю доступа.

Что такое Закон № 5651 и на кого он распространяется?

Закон № 5651 — турецкий закон о регулировании интернет-среды, полное название которого «О регулировании публикаций в интернете и борьбе с преступлениями, совершаемыми посредством таких публикаций». Он выделяет четырёх участников: поставщиков контента, хостинг-провайдеров, провайдеров доступа и провайдеров коллективного использования, и каждому назначает свои обязанности по ведению записей. Корпоративные офисы обычно относятся к последней категории.

Для корпоративной ИТ-службы важно, что закон оставляет срок хранения данных о трафике для провайдеров доступа (интернет-провайдеров) и хостинг-провайдеров на усмотрение подзаконного регулирования в пределах минимума и максимума, а для провайдеров коллективного использования предусматривает отдельный регламент. Согласно тексту закона, провайдер доступа хранит данные о трафике в течение установленного регламентом срока — не менее шести месяцев и не более двух лет; для хостинг-провайдера диапазон составляет от одного года до двух лет. Проверьте, в каком качестве закон применяется к вашей организации, по актуальному тексту закона на mevzuat.gov.tr.

Провайдер коллективного использования — это сторона, предоставляющая людям возможность пользоваться интернетом в определённом месте в течение определённого времени. По распространённому толкованию сюда относятся компания, открывающая сотрудникам проводной или беспроводной доступ, университет, отель с гостевым Wi-Fi или больница. Коммерческие провайдеры (например, интернет-кафе с платным доступом) несут дополнительные обязанности — разрешительный документ и фильтрация; корпоративный офис в большинстве сценариев рассматривается как некоммерческий провайдер. Это не юридическое заключение: уточните категорию вашей организации у юриста и по актуальному тексту регламента.

Практический вывод для ИТ таков: независимо от категории вы должны уметь сформировать запись о том, какой внутренний IP-адрес, с каким MAC-адресом и в какой интервал времени использовало каждое устройство, выходящее в интернет; хранить эту запись так, чтобы доказать её неизменность; и предъявить её по запросу в разумный срок. Эти три действия (сформировать, доказать, предъявить) — проектные требования к архитектуре логов, и они совпадают с техническими мерами KVKK, турецкого закона о защите персональных данных. Чтобы выполнить обе обязанности на одной платформе, изучите наш чек-лист технических мер KVKK.

Какие логи нужно хранить? Журналы распределения внутренних IP и записи доступа

Журнал распределения внутренних IP-адресов показывает адрес, выданный во внутренней сети, время начала и окончания его использования и MAC-адрес устройства. Определение записей доступа в регламенте дополнительно охватывает IP-адрес и порт назначения, когда один IP разделяется через порты (NAT). На практике эту запись вместе образуют данные DHCP, NAT и сессий идентификации.

Одного журнала DHCP недостаточно. Знание того, что устройство получило внутренний адрес, не показывает, с каким публичным IP и исходным портом оно вышло в интернет; сопоставление внутреннего адреса с внешним миром даёт журнал NAT. В сетях с аутентификацией (802.1X, captive portal) третьим звеном служит запись сессии, привязывающая IP к учётной записи пользователя. Если часы этих трёх источников расходятся, цепочка при аудите рвётся, поэтому синхронизация времени критична.

В корпоративной сети эти записи обычно формируют следующие компоненты:

• DHCP-сервер (встроенный DHCP FortiGate, Windows Server или отдельное устройство): аренда IP, MAC-адрес, время начала и окончания.
• Межсетевой экран (FortiGate): журнал трафика, трансляция NAT, начало и конец сессии, идентичность пользователя, приложение и адресат.
• Беспроводной контроллер и коммутаторы доступа (FortiAP, FortiSwitch): ассоциация клиента, порт и VLAN; в среде, управляемой через FortiLink, эти записи попадают в поток логов FortiGate.
• Сервер аутентификации (RADIUS, Active Directory, FortiAuthenticator): сопоставление имени пользователя с устройством и временем.

Типичная ошибка — вести только «журнал выхода в интернет» и забывать об уровнях DHCP и идентификации. Поскольку аудитор спрашивает «кто выходил с этого адреса в это время?», каждое звено цепочки должно собираться в одном центре. Удаление неиспользуемых правил напрямую снижает объём логов; пошагово мы описали это в статье об очистке правил межсетевого экрана и аудите политик.

Срок хранения и метка времени: как доказать целостность?

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

Метка времени, определённая в рамках турецкого Закона об электронной подписи № 5070, — это услуга, доказывающая, что электронные данные существовали в определённый момент и с тех пор не изменялись. Механизм прост: вычисляется криптографический хеш суточного файла логов, он отправляется поставщику услуг электронных сертификатов, уполномоченному BTK, и возвращается подписанным с официальным временем. При аудите хеш файла пересчитывается и сравнивается с меткой; если изменился хотя бы один байт, хеш не совпадёт. Поскольку отправляется только хеш, персональные данные не покидают организацию.

На сайте BTK размещена программа IP Log İmzalayıcı (подписыватель IP-логов), подготовленная при прежнем регламенте 2007 года; сообщается, что регламент 2017 года исключил требование использовать конкретное ПО, поэтому уточните актуальное положение. В корпоративном масштабе заверение обычно выполняет центральная платформа логов или отдельный сервис подписи. Важны два момента: заверение должно быть ежедневным и автоматическим (ручной процесс забывают, а забытый день остаётся без доказательств), и заверенный файл должен побайтно совпадать с архивным (если сжатие выполняется после заверения, хеш не совпадёт).

Планируя хранение, определите три отдельных срока: аналитический (сколько логи остаются в базе с возможностью запросов, обычно 30–90 дней), архивный (сколько сырые логи хранятся в сжатом и заверенном виде, то есть срок, требуемый законодательством) и момент уничтожения. Принцип KVKK «не хранить дольше необходимого» здесь встречается с обязанностью хранения по 5651: архивный срок устанавливается равным нормативному, затем следует автоматическое уничтожение. Поскольку вторичные источники называют разные сроки, опирайтесь только на текст норм.

Сравнение архитектур: локальный диск, syslog, FortiAnalyzer и SIEM

Централизованное управление логами строится по одной из четырёх архитектур: собственный диск межсетевого экрана, универсальный syslog-сервер, FortiAnalyzer и SIEM. В небольшом офисе локального диска хватает на короткий срок; когда нужны двухлетний заверенный архив, несколько устройств и отчёты для аудита, FortiAnalyzer или syslog со слоем подписи становятся практической необходимостью. SIEM нужен организациям с потребностью в корреляции и SOC.

Привлекательность локального диска в том, что не нужно дополнительное оборудование; слабость — при отказе или замене устройства логи уходят вместе с ним. Варианты с SSD, такие как FG-61F (128 ГБ) и FG-71G (64 ГБ), дают ограниченное место для локального логирования; мы используем его лишь как временный буфер, а постоянный архив держим централизованно.

Syslog-сервер (rsyslog, syslog-ng) — самый гибкий вариант в мультивендорной среде, но передача по UDP незаметно теряет пакеты, а ротацию и подпись приходится строить вручную. На FortiGate передача syslog настраивается тремя способами: UDP, устаревший надёжный режим на основе TCP и надёжный режим TCP с кадрированием по RFC 6587. Для потока, который должен давать доказательства для аудита, выбирайте надёжный режим и убедитесь, что приёмник понимает это кадрирование. Подробности настройки — в нашей статье о логировании FortiGate, мониторинге и интеграции с FortiAnalyzer.

FortiAnalyzer — централизованная платформа логов, созданная для устройств Fortinet. Она хранит логи на двух уровнях — аналитическом (SQL-база с запросами) и архивном (сырые, сжатые) — с отдельными квотами и сроками; при ротации архивного файла его контрольная сумма записывается в журнал событий и позже проверяется командой проверки целостности. Согласно руководствам Fortinet по администрированию и лучшим практикам FortiAnalyzer, средняя аналитическая запись занимает 600 байт, архивная — 80 байт, а через семь дней аналитические записи сжимаются в среднем до 150 байт; по этим значениям мы рассчитываем размер платформы. Квалифицированная метка времени при этом не встроена в продукт: проектируется отдельный шаг подписи, отправляющий хеш каждого суточного архивного файла поставщику услуг сертификации.

SIEM предназначен для корреляции и управления инцидентами; сама обязанность по 5651 его не требует. Если SIEM уже работает, роль FortiAnalyzer как уровня сбора и архива, а SIEM как уровня анализа держит объём архива под контролем.

Как построить поток логов от FortiGate к FortiAnalyzer?

Для потока логов FortiGate порядок такой: сначала источник времени (NTP) и решение по часовому поясу, затем определение политик, генерирующих логи, после этого назначение FortiAnalyzer или syslog с надёжной зашифрованной передачей и, наконец, политика квот, хранения и заверения. Если нарушить порядок, исправление задним числом означает потерю логов.

1. Источник времени. FortiGate, FortiAnalyzer, DHCP-сервер и сервер идентификации используют один источник NTP. Путаница с часовыми поясами — самая частая проблема аудита; выберите один стандарт (мы храним UTC централизованно и переводим в местное время в отчётах) и задокументируйте его.
2. Политика логирования. Для каждого правила межсетевого экрана отдельно решается, логировать ли начало и конец сессии. Для 5651 весь трафик в интернет должен логироваться; для трафика между внутренними сегментами соблюдается баланс объёма и пользы. Без предварительной очистки правил квоту расходуют и неиспользуемые правила.
3. Назначение. FortiAnalyzer общается с FortiGate по зашифрованному фирменному протоколу; при обрыве связи устройство буферизует логи и досылает их. Если используется syslog, предпочтителен надёжный режим TCP и по возможности TLS. Приложение Fortinet Log Integrity and Secure Log Transfer описывает защищённую передачу и проверку контрольных сумм архива.
4. Группировка устройств. В FortiAnalyzer ADOM (административные домены) разделяют филиалы, дочерние компании или группы клиентов, у каждого своя квота и срок. Это же граница контроля доступа: ИТ филиала видит только свой ADOM.
5. Квота и хранение. Аналитическая квота рассчитывается как число логов в сутки × дни аналитики × 600 байт (первая неделя) и 150 байт (далее); архивная — как число логов в сутки × дни хранения × 80 байт. При заполнении квоты удаляются самые старые записи, поэтому мы задаём архивную квоту с запасом сверх нормативного срока и порогом оповещения.
6. Заверение. Когда суточный архивный файл закрывается, его хеш отправляется в сервис меток времени; метка хранится столько же, сколько архив. Шаг автоматизирован и при сбое выдаёт оповещение.
7. Тест и учения. После внедрения учения подтверждают, что на вопрос «кто использовал этот внутренний IP в это время в прошлом месяце?» можно ответить за минуты.

Согласно спецификации Fortinet FortiAnalyzer, аппаратное семейство масштабируется от 100 ГБ/сутки (FAZ-300G) до 8300 ГБ/сутки (FAZ-3750G) логов и от 180 до 10 000 устройств/VDOM; для небольших сред есть виртуальные машины и FortiAnalyzer Cloud. Модель мы выбираем, измерив суточный объём логов минимум за неделю; по нашему опыту, платформы, рассчитанные «на глаз», рано начинают выдавать предупреждения о квоте.

Контроль доступа, политика хранения и доказательства для аудита

Контроль доступа к логам — ролевая модель, разделяющая, кто может просматривать, экспортировать и удалять записи. Поскольку записи по 5651 содержат персональные данные, по KVKK действует принцип минимальных привилегий; журнал администрирования самой платформы тоже нужно хранить, ведь аудитор спросит и «кто обращался к логам?».

На практике достаточно трёх ролей: аналитик только для чтения (запросы без экспорта), оператор (квоты, устройства, шаблоны отчётов; без удаления) и администратор (политика хранения и удаление с подтверждением по принципу четырёх глаз). Учётные записи должны быть персональными, без общей учётной записи «admin»; централизованная и многофакторная аутентификация должны быть обязательны и для платформы логов.

Политика хранения должна быть оформлена письменно и описывать: собираемые источники логов, сроки аналитики и архива, сервис и частоту заверения, способ проверки уничтожения, место хранения резервной копии и порядок восстановления архива после аварии. Руководство по безопасности персональных данных (технические и организационные меры), опубликованное Советом KVKK, относит регулярное ведение журналов и хранение журналов доступа к техническим мерам; архив по 5651 одновременно даёт значительную часть этих доказательств.

Доказательство для аудита состоит из трёх элементов: отчёта с сопоставлением пользователя/устройства для даты и внутреннего IP, вывода проверки о совпадении хеша архивного файла за этот день с меткой времени и записи о доступе лица, сформировавшего отчёт. Если вы не хотите вести эту работу собственной командой, контроль квот, проверку заверения и ежемесячный отчёт о соответствии можно включить в услугу управляемого межсетевого экрана; в наших проектах мы объединяем эти три задачи в едином графике обслуживания.

Часто задаваемые вопросы

Обязана ли обычная компания, дающая сотрудникам интернет, вести логи по Закону № 5651?

По распространённому толкованию — да: организация, предоставляющая пользование интернетом в определённом месте и в определённое время, является провайдером коллективного использования и должна вести журналы распределения внутренних IP. У коммерческих провайдеров есть дополнительные обязанности. Уточните категорию по регламенту и у юриста.

Сколько нужно хранить логи по 5651?

Регламент о провайдерах коллективного использования интернета предусматривает хранение записей доступа в течение двух лет; для провайдеров доступа и хостинг-провайдеров закон задаёт иные диапазоны. Вторичные источники называют разные сроки, поэтому опирайтесь на текст норм и указывайте статью в политике хранения.

Действителен ли лог без метки времени?

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

Достаточно ли собственного диска FortiGate для 5651?

В офисе с одним устройством и низким трафиком краткосрочное локальное логирование работает, но при отказе устройства логи теряются, двухлетний архив не помещается на диск, а заверение требует экспорта. Постоянный архив мы рекомендуем держать на FortiAnalyzer, FortiAnalyzer Cloud или syslog-сервере с надёжной передачей.

Ставит ли FortiAnalyzer метку времени?

FortiAnalyzer сохраняет контрольную сумму при ротации архивного файла и предлагает команду проверки целостности, но официальная метка времени от поставщика, уполномоченного BTK, не встроена в продукт. Рядом проектируется отдельный автоматический шаг, заверяющий хеш каждого суточного архива.

Чем рискованна передача syslog по UDP?

UDP не сообщает о потерянных пакетах; записи, пропавшие в пиковые моменты, при аудите выглядят как пробелы. FortiGate поддерживает надёжный режим TCP с кадрированием по RFC 6587; убедитесь, что приёмник его понимает, и по возможности шифруйте поток с помощью TLS.

Как защищать логи с точки зрения KVKK?

IP- и MAC-адреса, имена пользователей — персональные данные. Доступ должен быть ролевым по принципу минимальных привилегий, журнал администрирования платформы — храниться, а уничтожение по истечении срока — быть автоматическим и проверяемым. Выполняйте меры KVKK и требования 5651 на одной платформе.

Заключение

Турецкий Закон № 5651 и регламент к нему ожидают от вашей организации трёх вещей: формировать журналы распределения внутренних IP, хранить их с доказуемой целостностью в течение нормативного срока и предъявлять по запросу. Это вопрос архитектуры: единый источник времени, цепочка DHCP–NAT–идентификация в одном месте, надёжная передача, раздельно спланированные квоты аналитики и архива, ежедневная автоматическая метка времени и ролевой доступ. Когда речь идёт о двухлетнем заверенном архиве, FortiAnalyzer или надёжный syslog со слоем подписи становятся практической необходимостью. Юридические детали, такие как сроки и круг обязанных лиц, всегда сверяйте с актуальным текстом законодательства.

Если вы хотите вместе спроектировать измерение объёма логов, расчёт FortiAnalyzer, политику хранения и процесс заверения для вашей среды FortiGate, запишитесь на бесплатную ознакомительную встречу; мы выслушаем ваши требования и подготовим предложение только по действительно нужным компонентам.