Как проверить хранение записей в Asterisk

Нет, одной команды в Asterisk недостаточно, чтобы объявить систему готовой к проверке по 152-ФЗ. Я проверяю всю цепочку: законное основание обработки, работу MixMonitor, место хранения, доступ к файлам, резервные копии и журналирование. Ниже — технический чек-лист, который помогает найти сбой, а не заменить юридическую оценку.

1. Сначала определите правила обработки

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

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

• Зафиксировать цель и состав записи
• Определить доступ и срок хранения
• Сверить информирование и основание обработки
• Назначить ответственных за удаление

2. Найдите фактическое место записи

В Asterisk запись через диалплан обычно запускают приложением MixMonitor. У него есть аргумент filename; относительный путь используется относительно настроенной директории мониторинга, а абсолютный задаёт путь явно. Путь хранения нельзя угадывать по статье из интернета: он зависит от конфигурации и способа вызова приложения. В стандартной структуре Asterisk spool-каталог задаётся через asterisk.conf; документация указывает, что там размещаются подкаталоги, в том числе monitor и recording. Проверьте именно установленную систему и её конфиги. В экспертной базе подтверждено использование MixMonitor для записи, а также то, что asterisk.conf задаёт каталоги Asterisk. Этих сведений достаточно, чтобы наметить проверку, но не чтобы объявить один путь правильным для всех сборок. Версия, пакет и надстройка PBX могут менять расположение и управление настройками.

Для проверки найдите вызовы MixMonitor и выясните, где формируется имя файла. Осторожно с данными звонящего в имени: документация предупреждает не передавать непроверенные строки вроде Caller ID в параметры приложения — это может привести к выполнению команд. В имени лучше использовать контролируемый идентификатор и безопасный формат. Если используется FreePBX, выясните, какой механизм генерирует диалплан и где проектом предусмотрены пользовательские настройки. Не правьте генерируемый файл вслепую: применение конфигурации может затереть изменение. Запишите фактический маршрут до файла, владельца процесса и права родительских каталогов. Затем сравните результат с выбранным сроком хранения, ёмкостью диска и правилами резервирования. Конкретная настройка записи — функция MixMonitor с именем файла; отдельный глобальный параметр recording=yes в asterisk.conf для этого не подтверждён и в чек-лист не входит.

• Найти MixMonitor в диалплане
• Установить фактический путь записи
• Проверить права на каталог и свободное место
• Исключить непроверенные данные из имени файла

3. Проверьте, что файл действительно создаётся

На тестовом вызове проверьте полный путь от входящего или исходящего маршрута до MixMonitor. Убедитесь, что нужный канал проходит эту ветку, приложение запускается после готовности канала к записи, а у пользователя процесса есть доступ к каталогу. Само наличие строки MixMonitor в одном контексте ничего не говорит о других маршрутах. В Asterisk приложение не отвечает на вызов автоматически; в документации указано, что перед ним должно быть приложение вроде Answer или Progress. Значит, порядок выполнения имеет значение. Выберите безопасный тестовый сценарий и заранее предупредите участников теста в соответствии с правилами организации. Не проверяйте на реальном разговоре с клиентом, если для такого теста нет установленного основания и понятного порядка хранения тестового файла.

После теста проверьте файл: появился ли он, открывается ли, слышны ли обе стороны, соответствует ли имя ожидаемому вызову. Когда диалплан должен обработать файл до завершения записи, используйте StopMixMonitor: документация прямо указывает, что он нужен, чтобы гарантировать доступность аудио для дальнейшей обработки во время выполнения диалплана. Не полагайтесь только на строку в консоли — прослушайте контрольный файл и сопоставьте его с тестовым вызовом. При сбое проверьте права процесса и фактический путь, а не меняйте chmod наугад. Если файл пустой или в нём слышна только одна сторона, разберите конкретный маршрут и аудиопоток; не объявляйте это исправленным по одному факту появления файла. Зафиксируйте результат, удалите тестовые данные по установленной процедуре и проверьте, что удаление действительно выполнено.

• Сделать контрольный вызов
• Проверить запуск приложения и канал
• Проверить файл и обе стороны разговора
• Проверить StopMixMonitor для дальнейшей обработки

4. Ограничьте доступ к записям и конфигам

Сначала установите, от какого пользователя и с какими группами реально работает Asterisk. systemctl status показывает состояние службы, но не всегда даёт достаточно контекста о правах на каждый каталог; уточните unit-файл и свойства процесса средствами своей ОС. Затем проверьте владельца и разрешения на каталог записей, родительские каталоги, конфиги и резервные копии. В Linux право доступа определяется всей цепочкой каталогов, поэтому строгие права только на конечный файл не спасут, если пройти к нему может лишний пользователь. Составьте список ролей: служба, администратор, оператор, специалист по разбору обращений и резервное копирование. Для каждой роли укажите нужное действие и проверьте доступ отдельной учётной записью. Общий доступ «для всех сотрудников» не объясняет, кому действительно нужны аудиофайлы.

Не существует универсальной команды chown, безопасной для любой установки. Владельцы и группы зависят от пакета, дистрибутива, FreePBX и локальных изменений. Перед массовой сменой прав сохраните текущие значения, выясните штатную модель владельцев и проверьте, что после правки служба продолжит читать конфиги и создавать записи. Режимы вроде 640 для конфигурации или 750 для каталога могут быть разумной отправной точкой, но это не сертификат соответствия и не предписание закона. Не применяйте chmod -R или права 777 как средство диагностики. Сначала получите текущую картину, затем внесите минимальную правку на одном тестовом каталоге и проверьте работу записи, чтения, ротации и бэкапа. Зафиксируйте, кто имеет право выгружать записи наружу, и удалите неиспользуемые доступы.

• Проверить пользователя процесса
• Проверить права всех родительских каталогов
• Сверить владельцев со штатной моделью установки
• Проверить чтение конфигов и создание новых файлов

5. Разделите журналы и доказательства работы

Файл logger.conf управляет направлениями и уровнями журналов Asterisk: это подтверждает официальная документация и экспертная база. Но директива вида recording=yes не является универсальным переключателем записи в asterisk.conf, а отдельная строка logger.conf не превращает журнал в реестр всех записанных разговоров. Журналирование Asterisk предназначено для сообщений системы; CDR и CEL — отдельные механизмы учёта событий вызовов. Выберите подходящий источник для своей задачи и проверьте, какие именно поля он фиксирует в вашей конфигурации. Для каждой проверки заранее определите ожидаемую запись в журнале и срок, в течение которого она нужна. Не смешивайте системную диагностику с подтверждением доступа конкретного сотрудника к файлу: это разные задачи и нередко разные источники событий.

Не включайте debug и подробный verbose постоянно «на всякий случай»: документация предупреждает, что отладочные сообщения быстро раздувают журналы. Определите, что требуется расследовать, включайте нужный уровень на ограниченное время, затем выключайте и проверьте ротацию, место на диске и доступ к логам. Если нужен след действий пользователя с аудиофайлами — прослушивания, выгрузки, удаления — штатный общий лог Asterisk может этого не покрыть. Такой аудит проектируют отдельно, с учётом интерфейса, хранилища и прав операторов. Не придумывайте logfile recording.log и не ожидайте, что туда автоматически попадут события MixMonitor: формат и источник событий нужно подтвердить для вашей системы. Базовая проверка начинается с logger show channels в CLI и чтения настроенных каналов.

• Проверить logger.conf и действующие каналы
• Различать системные логи, CDR и CEL
• Не оставлять debug включённым без причины
• Отдельно спроектировать учёт доступа к аудиофайлам

6. Проверьте восстановление и удаление

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

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

• Описать состав и доступ к резервным копиям
• Провести тестовое восстановление
• Проверить удаление по всем местам хранения
• Фиксировать результат без лишних персональных данных

Частые вопросы