Лимиты хранения и законное удаление видео

Автор: Николай СапуновОбновлено: август 202619 мин чтения
Содержание статьи +

Это инженерное руководство, а не юридический совет. Уточняйте конкретику у квалифицированного юриста.

Кратко

У видеозаписи два предела хранения, а не один: пол, заданный доказательствами и отраслевыми правилами, – сколько вы обязаны хранить, и потолок, заданный законом о приватности, – сколько вам разрешено хранить. Регуляторы читают правило ограничения хранения в General Data Protection Regulation (GDPR) как несколько дней для обычных камер и редко более 30–90 дней без задокументированной причины. «Удалить» запись – не то же, что убрать файл: пока байты не перезаписаны или их ключ шифрования не уничтожен, запись восстановима, а копии в бэкапах и экспортах обычно переживают рутинное удаление. Защитимая система фиксирует окно хранения, даёт рекордеру автоматически перезаписывать старое видео и при этом умеет стереть данные одного человека по запросу в законный срок.

Почему это важно

Если вы строите, покупаете или эксплуатируете систему управления видео – ПО, которое записывает и управляет многими потоками камер, называемое VMS, – хранение это точка, где встречаются хорошая инженерия и закон. Храните слишком мало – провалите запрос на доказательства или нарушите отраслевое правило; храните слишком долго – нарушите закон о приватности и раздуете каждую утечку и каждый запрос субъекта данных. Эта статья для системных интеграторов, продактов и руководителей безопасности в ритейле, умных зданиях и городах, которым нужно выбрать число для хранения и его защитить. Она объясняет два предела, как задать окно, удовлетворяющее обоим, и чего на деле требует «законное удаление» от хранилища под ним. Это приватный потолок поверх операционных решений из статьи сколько хранить запись.

Два предела, а не один: пол и потолок

Большинство статей трактуют хранение как одно число – «храните запись 30 дней». Эта рамка прячет настоящую инженерную задачу, где на один и тот же регулятор давят две противоположные силы.

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

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

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

Рис. 1. У хранения есть пол (сколько обязаны хранить) и потолок (сколько вправе хранить). Законное окно – полоса между ними.

Пол: сколько вы обязаны хранить запись

Пол строится из трёх источников и рассуждать о нём проще, потому что он обычно приходит как конкретное число или конкретное событие.

Отраслевые и юрисдикционные правила. Некоторые отрасли и регионы задают явные минимумы. Закон США New York ATM Safety Act требует от банков хранить записи камер не менее 45 дней. Многие штаты США задают минимумы для камер полиции и госорганов – Иллинойс требует хранить отдельные записи не менее 90 дней (два года, если они помечены), Южная Каролина ставит порог 14 дней, Джорджия требует 180 дней для некоторых нательных камер. У частных компаний в большинстве штатов США нет общего законного минимума вовсе, и это удивляет: пол часто то, что вы выбираете по операционным причинам, а не то, что навязывает закон.

Legal hold (правовое удержание). Это пол, который перебивает всё остальное. В момент, когда судебный спор становится разумно предвидимым – серьёзный инцидент, травма, жалоба HR, формальная претензия, – возникает обязанность сохранить относящуюся запись, и рутинное удаление, уничтожившее её после этого, могут счесть уничтожением доказательств. На практике паттерн такой: держите рутинную запись на коротком цикле, а конкретные клипы, касающиеся инцидента, вынимайте из цикла и держите отдельно до закрытия дела.

Срок исковой давности. Иски не всегда подают быстро. Иск о причинении вреда здоровью могут подать и через два года после события, в зависимости от юрисдикции. Вы не держите всю запись два года ради этого; вы держите помеченные клипы по известному инциденту. Общий буфер и клип инцидента – две разные дорожки хранения, и их смешение – то, как системы начинают держать терабайты, которые должны были удалить.

Итак, пол в основном событийный. За исключением нескольких отраслевых минимумов, вам не нужно долгое рутинное хранение, чтобы его удовлетворить, – нужно короткое рутинное хранение плюс надёжный способ пометить и удержать редкий клип, который важен.

Потолок: сколько закон о приватности позволяет хранить

Потолок задаёт закон о защите данных, и здесь управляющая идея – принцип ограничения хранения. По GDPR, Регламент (ЕС) 2016/679, статья 5(1)(e), персональные данные должны храниться «в форме, позволяющей идентификацию субъектов данных, не дольше, чем необходимо» для цели сбора. Видео опознаваемого человека – это персональные данные, поэтому таймер действует для обычной записи камер, а не только для распознавания лиц. Глубокий разбор того, почему запись считается персональными данными, – в статье GDPR для видеонаблюдения; здесь важен срок, который он создаёт.

Закон не называет число. Вместо этого guidance регулятора объясняет, что значит «необходимо» на практике. European Data Protection Board (EDPB) – орган, выпускающий официальное толкование GDPR, – в своих Guidelines 3/2019 по видеоустройствам говорит, что с учётом принципов минимизации данных и ограничения хранения запись «должна стираться через несколько дней в большинстве случаев», например когда цель – выявление вандализма. Чем длиннее окно, тем тяжелее обоснование: регуляторы считают, что всё сверх примерно 72 часов требует задокументированной причины, а сверх 30–90 дней – исключение под конкретную цель.

UK Information Commissioner's Office (ICO) формулирует то же для систем видеонаблюдения (CCTV): фиксированного срока нет, вы задаёте его по своей цели и должны уметь его обосновать. Форма правила одинакова в ЕС и Великобритании – короткий дефолт, удлиняемый только причиной, которую вы можете защитить.

Биометрия несёт более строгий и явный потолок. Закон Иллинойса Biometric Information Privacy Act (BIPA), 740 ILCS 14/15(a), требует от любой частной организации, хранящей биометрические идентификаторы – например, шаблон лица, – публиковать письменный график хранения и уничтожать эти данные, когда цель сбора достигнута или в течение трёх лет с последнего взаимодействия человека, смотря что наступит раньше. Это жёсткий законный лимит, а не рекомендация, и Иллинойс позволяет частным лицам подавать иск. Если ваши камеры используют распознавание лиц, правило хранения для шаблонов лиц строже и принудимее, чем для обычного видео, – правовой барьер перед этой возможностью разобран в статье BIPA и биометрические законы США.

США добавляют процедурный потолок даже там, где не ставят лимит времени. California Consumer Privacy Act с поправками California Privacy Rights Act требует от бизнеса раскрыть, как долго он хранит каждую категорию персональных данных, или критерии, по которым он это решает, – и общее «столько, сколько нужно» считается недостаточным (Cal. Civ. Code §1798.100(a)(3)). Число может быть вашим, но вы обязаны его заявить и за ним стоять.

«Локальная заметка: для развёртываний в России базовый каркас формируют 152-ФЗ «О персональных данных» (включая требования к локализации и срокам обработки) и положения о биометрии – их стоит наложить на ту же логику пола и потолка, но первичная регуляторная рамка статьи остаётся GDPR/BIPA.»

Когда пол выше потолка

Иногда два предела сталкиваются: правило о доказательствах или отрасли хочет хранить запись дольше, чем обычно позволяет приватный потолок. Это не неразрешимое противоречие; это задача документирования.

Решение – трактовать случай долгого хранения как именованное исключение, а не как норму. Закон о приватности это предвидит. Статья GDPR о праве на стирание (статья 17) несёт явные оговорки в статье 17(3): вы вправе хранить персональные данные, которые иначе подлежали бы удалению, если хранение необходимо для соблюдения правовой обязанности (17(3)(b)) или для установления, осуществления или защиты правовых требований (17(3)(e)). Legal hold – это ровно второй случай.

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

Как задать окно хранения, которое можно защитить

Соединение пола и потолка даёт метод, а не магическое число. Работайте в таком порядке.

Сначала сформулируйте цель каждой камеры или зоны одной фразой – «выявлять и расследовать кражи на разгрузочной рампе», «следить за вестибюлем на предмет проникновения после закрытия». Цель – то, что делает срок хранения «необходимым» или нет.

Второе, найдите пол для этой цели: любой отраслевой минимум, реалистичное окно, в котором всплыл бы инцидент, и ваш процесс legal hold для исключений.

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

Четвёртое, выберите число внутри полосы и запишите его – по группе камер, с причиной. Разгрузочная рампа с реальной картиной краж может оправдать 30 дней; тихий коридор – 72 часа. Разные зоны могут и должны иметь разные окна.

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

Рис. 2. Как задать защитимое окно: цель задаёт пол и потолок, вы выбираете число между ними, документируете и даёте рекордеру исполнять – с legal hold как именованным исключением.

Законное удаление: что на деле значит «удалить»

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

Когда ПО «удаляет» файл, оно обычно лишь убирает запись каталога – указатель, говорящий, где на диске лежит запись. Сами байты остаются на диске, пока что-то другое не запишет поверх них. Пока эта перезапись не произошла, обычные утилиты восстановления вернут запись. Для видеонаблюдения, где весь смысл удаления в том, что запись исчезла, этот зазор важен.

Хорошая новость в том, что грамотно собранный VMS уже удаляет рутинную запись правильно – через механизм, называемый кольцевой записью (ring buffer). Рекордер обращается с хранилищем как с лентой-петлёй фиксированной длины: когда запись достигает конца окна хранения – или когда диск заполняется – старейшая запись перезаписывается новейшей. Удаление не отдельное действие, которое кто-то помнит запустить; это естественный результат того, что новое видео ложится поверх старого. Задайте петлю под своё окно хранения, и система исполняет потолок за вас, перезаписывая по ходу.

Для случаев, когда нужно доказать, что запись невосстановима – вывод диска из эксплуатации, исполнение запроса на стирание, отключение облачного бакета, – эталонный стандарт это US National Institute of Standards and Technology (NIST) Special Publication 800-88, Guidelines for Media Sanitization. Он определяет три уровня. Clear перезаписывает данные новыми значениями, что побеждает обычное восстановление и достаточно для повторного использования. Purge применяет более сильные методы – прошивочный block-erase или криптостирание, – побеждающие даже лабораторное восстановление. Destroy физически уничтожает или размагничивает носитель, чтобы его нельзя было прочесть.

Рис. 3. У «удаления» есть уровни. Снятие записи индекса оставляет восстановимые байты; перезапись (Clear), crypto-erase (Purge) и физическое уничтожение (Destroy) реально санируют. Бэкапы, экспорты и реплики – копии, которые рутинное удаление пропускает.

Криптографическое стирание (crypto-shredding) заслуживает отдельного упоминания, потому что так удаление работает на современной флеш-памяти и в облаке, где нельзя надёжно перезаписать конкретное физическое место. Вы шифруете запись на хранении, и чтобы «удалить» её, уничтожаете ключ шифрования. Без ключа зашифрованные байты – шум. Это быстро и надёжно, и это практичный способ стереть данные, разбросанные по твердотельным дискам и реплицированным облачным объектам.

Самая трудная часть настоящего удаления – копии. Запись, которую вы хотите убрать, может также лежать в ночном бэкапе, в реплике аварийного восстановления в другом регионе, в клипе, который оператор выгрузил на USB для расследования, и в кадре, прикреплённом к письму тревоги. «Удаление», очистившее основной рекордер, но оставившее эти копии, не стёрло данные ни в каком смысле, который признаёт закон. Законное удаление означает отслеживать каждое место, куда может попасть запись, и либо вводить эти копии в тот же таймер хранения, либо иметь задокументированный график, который их тоже истекает.

Право на стирание: удаление одного человека по запросу

Рутинное истечение закрывает общий случай. Другую обязанность закрывает конкретный: человек, просящий удалить его данные. По GDPR статья 17 человек может запросить стирание касающихся его персональных данных, и контролёр обязан исполнить без необоснованной задержки, если применимо одно из перечисленных оснований – чаще всего то, что данные больше не нужны для своей цели. Калифорния даёт эквивалентное право на удаление по Civil Code §1798.105, которое с 2026 года также требует передать инструкцию об удалении сервис-провайдерам и третьим лицам, получившим данные.

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

Два практических ограничения формируют ответ. Первое – срок: GDPR статья 12(3) требует ответить в течение одного месяца с момента запроса, продляемого ещё на два месяца только для действительно сложных случаев и только если вы сообщите человеку в первый месяц. «Ответить» означает сообщить исход – сделано или отказано с причинами, – а не просто подтвердить получение. Второе – исключения, уже упомянутые: статья 17(3) позволяет отказать в стирании, когда данные нужны для правового требования или правовой обязанности. Если клип на legal hold, вы вправе отказать в стирании, но обязаны сказать об этом и сказать почему.

Рис. 4. Запрос на стирание должен дойти до каждой копии – активная запись, экспорты, шаблоны аналитики и бэкапы – и решиться за месяц, если не сработало исключение по правовым требованиям.

Урок проектирования в том, что стирание выполнимо, только если вы знаете, где приземляются персональные данные. Система, позволяющая операторам свободно выгружать клипы без записи о том, куда они ушли, не может исполнить запрос на стирание этих клипов – она не знает, что они существуют. Минимизация того, что вы производите и храните, и журналирование того, что вы экспортируете, – то, что делает право на стирание работоспособным. Приёмы редактирования, позволяющие выдавать или хранить запись, защищая посторонних, разобраны в статье маскирование лиц, редактирование и приватная аналитика.

Как уровни хранения должны чтить таймер хранения

Хранение – не только настройка рекордера; оно должно пережить путь, который проходит запись по хранилищу. Старея, записи переезжают из быстрого дорогого «горячего» хранилища в более дешёвые «тёплый», «холодный» и «архивный» уровни – их экономика разобрана в статье уровни хранения: горячий, холодный и архив. Правило хранения обязано ехать с данными через каждый из этих переездов.

Режим отказа – архив, который никогда не забывает. Запись переезжает в дешёвое холодное хранилище или облачный архивный бакет «ради экономии», правило жизненного цикла, которое должно её удалить, так и не прикрепляется, и годы спустя вы обнаруживаете, что держите запись далеко за пределами и вашей политики, и приватного потолка – теперь она лежит в наименее контролируемой и наименее защищённой части вашего хозяйства. Каждый уровень, включая архив, обязан нести исходную дату удаления, и правило жизненного цикла, переносящее данные между уровнями, обязано быть тем же, что их истекает. Клип, который должен был удалиться в день 30, удаляется в день 30, горячий он, холодный или архивный.

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

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

Разобранный пример: окно и арифметика

Возьмём ритейл-объект на 40 камер. Пусть анализ цели – расследование краж и исков о падениях, что обычно всплывают за три-четыре недели, – задаёт рутинное окно в 30 дней, удобно внутри защитимого потолка и над практическим полом. Каждая камера пишет H.265 примерно на 4 Мбит/с.

Суточное хранилище на камеру – это битрейт × секунд в сутки:

4 Мбит/с ÷ 8 = 0,5 МБ/с
0,5 МБ/с × 86 400 с/сутки = 43 200 МБ/сутки ≈ 43,2 ГБ/сутки на камеру

На 40 камер за окно 30 дней:

43,2 ГБ/сутки × 40 камер × 30 дней ≈ 51 840 ГБ ≈ 51,8 ТБ

Эти ~52 ТБ – стационарный объём, и кольцевая запись держит его ровным: в день 31 запись дня 1 перезаписывается записью дня 31, так что хранилище не растёт за окно. Полный вывод по полосе и хранилищу – в статье хранение и расчёт ретенции; здесь суть в том, что число хранения – крупнейший рычаг на эти 52 ТБ. Удвоение окна до 60 дней «для надёжности» удваивает хранилище до ~104 ТБ и удваивает приватный риск ради записи, в которую вы почти никогда не заглянете. Дисциплинированный ход обратный: держите рутинное окно на 30 днях, а когда одному клипу о падении нужно прожить дольше, поднимайте этот единственный клип на legal hold. Вы платите за один клип, а не за лишние недели всех 40 камер.

Частые ошибки, создающие риск

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

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

Где здесь Фора Софт

Фора Софт строит видеосистемы – видеонаблюдение, стриминг, конференции, компьютерное зрение – с 2005 года, на 250+ проектах, и хранение – одно из первых архитектурных решений на сборке наблюдения, а не настройка, прикрученная в конце. На практике мы проектируем окно хранения в слой записи и хранилища, чтобы истечение было автоматическим и доказуемым: кольцевая запись на основном уровне, правила жизненного цикла, удаляющие или крипто-уничтожающие запись по мере старения на каждом уровне, включая архив и бэкапы, отдельная дорожка legal hold для клипов, которым нужно прожить дольше, и инструменты стирания, способные найти производные данные субъекта в законный срок. Рамка, которой мы держимся, – точность против производительности: удаление, которое вы не можете доказать, не удаление, а число хранения, которое вы не можете защитить, – это риск, переодетый в функцию. Мы строим систему так, чтобы честный ответ на вопрос «оно правда исчезло, и можете показать?» был «да».

Главное

  • У хранения два предела: пол (обязаны хранить, для доказательств) и потолок (вправе хранить, по закону о приватности).
  • Закон о приватности – за короткое хранение: несколько дней до недель для обычной записи; всё дольше обоснуйте.
  • BIPA ограничивает биометрию достижением цели или тремя годами с последнего контакта, смотря что раньше.
  • Рутинное удаление снимает лишь указатель; санируют перезапись, crypto-erase или физическое уничтожение.
  • Законное удаление должно дойти до каждой копии – бэкапы, реплики и экспорты, а не только основной рекордер.
  • Право на стирание работает в течение месяца; клипы на legal hold – задокументированное исключение по ст. 17(3).

Что почитать дальше

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.