Кто смотрел запись: доступы, журналы действий и регулярная проверка

Почему важно знать, кто открывал записи

Фрагменты видеонаблюдения почти всегда содержат персональные данные — по ним человека можно идентифицировать. Поэтому регуляторы во многих странах (в ЕС по GDPR, в Великобритании по UK GDPR и рекомендациям ICO, в Новой Зеландии по Privacy Act) исходят из того, что доступ к записям должен быть обоснован и прослеживаем. Проблема не в том, кто формально «имеет право», а в том, кто фактически открывал архив, что искал, что выгружал и по какому основанию.

Если таких сведений нет, организация не может ни доказать законность обработки, ни ответить на жалобу или запрос, ни своевременно заметить злоупотребление. Именно поэтому в документах регуляторов повторяется связка: цель съёмки, кто отвечает за систему, кто может смотреть записи, как доступ ограничен и как долго хранится видео. Это общий принцип, а не только требование GDPR.

Практическое следствие: контроль доступа, журналирование и проверка работают как единый контур. Хорошие логи бесполезны, если права выданы слишком широко, а грамотно настроенный доступ не защищает, если логи никто не читает.

• Определите поименно роли, которым реально нужен просмотр: охрана, HR при расследовании, ответственный за систему, обслуживающий персонал.
• Зафиксируйте в политике, что просмотр «из любопытства» или без служебной необходимости запрещён, даже если технически доступ есть.

Доступ: именные учётные записи и минимальные права

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

Каждый человек должен иметь уникальную именную учётную запись с многофакторной аутентификацией там, где она доступна. Общие логины разрушают всю систему доказательств: по журналу невозможно понять, кто именно действовал. Назначать права может только уполномоченный администратор, а сам процесс назначения и изменения прав стоит отражать в отдельном журнале.

Доступ привязывают к жизненному циклу сотрудника: при переводе на другую роль права пересматривают, при увольнении отзывают немедленно, а не в конце месяца. Периодически права переаттестуют — например, раз в квартал или в год руководитель подтверждает, кому и зачем оставлен доступ.

Важный нюанс: ограничения касаются и технических учётных записей. Отдельный доступ у подрядчика по обслуживанию возможен только на время работ и под контролем, как прямо отмечают в своих регламентах крупные операторы систем.

• Права выдают по матрице «камера + функция + время», а не глобальным доступом ко всему VMS.
• У каждой учётной записи есть владелец; сервисные и временные доступы истекают автоматически.

Что должен фиксировать журнал действий

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

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

Журнал нужно защитить от изменения задним числом: права на чтение логов отделяют от прав на администрирование камер, а доступ администраторов системы тоже логируется. Срок хранения журналов задают политикой и законом — например, университетские регламенты нередко хранят журналы доступа и экспорта не менее года.

• Записывайте результат действия: успешный вход, отказ, ошибку при открытии файла.
• Журнал по умолчанию защищён от удаления и правки обычными пользователями и администраторами камер.

Проверка по расписанию: что и как смотреть

Журнал оправдывает себя только при регулярной проверке. Разумная модель — многоуровневая: оперативные проверки на уровне дежурной смены, регулярная выборочная сверка (например, ежемесячно) и сводный ежегодный отчёт для руководства, где суммируются объёмы запросов и экспортов, количество исключений и действия по улучшению. Такая структура встречается в регламентах крупных организаций, и её логику легко перенести на любую систему.

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

Регулярность зависит от риска: в чувствительных зонах (раздевалки исключены по закону, но склады, кассы, входы) проверки чаще, в малолюдных помещениях можно реже. Главное — чтобы проверка была назначенной, документированной и с ответственными лицами, а не «посмотрим, когда случится инцидент».

• Назначьте ответственного за сверку журналов и зафиксируйте периодичность.
• Храните результаты проверок и список выявленных и закрытых аномалий.

Запросы, экспорт и доступ людей к своим записям

Кроме внутреннего контроля есть внешние запросы: полиция, страховые, а также граждане, которые просят записи о себе. В ряде юрисдикций право человека получить записи, где он фигурирует, закреплено законом — например, в Новой Зеландии по принципу 6 Privacy Act такой запрос нельзя игнорировать, а удаление записи после получения запроса может быть правонарушением.

При передаче фрагментов третьим лицам действует правило «минимум и по делу»: сначала приостановите автоматическое перезаписывание фрагмента, проверьте, что в кадре действительно нужный человек, и отредактируйте видео, скрыв других людей (кадрирование, размытие). Отказ только потому, что «в кадре есть посторонние», во многих юрисдикциях считается слишком жёстким и неправомерным.

Каждую внешнюю выдачу фиксируют: кто запросил, на каком основании, что передано, кому, в каком виде и когда. Передача файлов идёт в защищённом виде, а копию или доступ предоставляют только уполномоченному лицу после согласования.

• Получив запрос человека о записях с его участием, сразу приостановите автоудаление фрагмента.
• Ведите отдельный журнал раскрытия и выдачи записей, отличный от журнала внутренних просмотров.

Типичные ошибки и границы контроля

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

Важно понимать границы: контроль доступа не доказывает, что человек «должен был» увидеть кадр, — он лишь показывает, что произошло, и позволяет задать вопрос. Юридические требования различаются по странам, а данная статья носит общий характер и не является правовой консультацией для конкретной юрисдикции.

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

• Проверяйте, что журналирование включено для всех действий, включая смену прав и экспорт.
• Планируйте бюджет на редактирование (размытие) записей при выдаче их третьим лицам.