Локальные журналы подтверждают меры SOC 2 CC7

Локальные журналы выполнения с контролем целостности могут подкрепить доказательства SOC 2 CC7, но не закрывают CC7.1 или CC7.2 в одиночку. Они показывают, какой локальный процесс агента открыл сеанс, какие вызовы с учетными данными он пытался выполнить, чем они закончились и менялась ли сохраненная история. Они не доказывают, что мониторинг уязвимостей охватывал каждую систему в области аудита, а сотрудники исследовали аномалии по графику.

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

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

CC7.1 и CC7.2 отвечают на разные вопросы

CC7.1 требует процедур обнаружения и мониторинга, которые выявляют изменения конфигурации, создающие новые уязвимости, и подверженность недавно обнаруженным уязвимостям. CC7.2 требует следить за компонентами и их работой, находить аномалии, связанные со злонамеренными действиями, стихийными бедствиями или ошибками, а затем определять, относятся ли они к событиям безопасности. Запись действия агента через API или SSH помогает по обоим критериям, но по-разному.

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

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

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

Trust Services Criteria AICPA содержат направления проверки, а не единый список инструментов. Компания может настроить контроль под свои риски, однако универсального срока хранения и обязательной категории продукта нет. Значимость локальных данных зависит от описания системы, оценки рисков, формулировки меры и реальной процедуры.

Узкая и проверяемая формулировка может звучать так: «В каждый рабочий день служба безопасности проверяет производственные действия агентов, включая отклоненные и неудачные вызовы, новые адресаты и привилегированные команды SSH; проверяющий фиксирует результат и передает подозрительные события по процедуре реагирования». Здесь указаны совокупность данных, сигналы, частота, ответственный и дальнейшие действия. Фраза «Мы храним защищенные от незаметного изменения журналы» описывает только свойство хранилища.

Идентификатор сеанса описывает процесс, а не человека

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

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

Та же осторожность нужна для связи процессов. Оболочка может запустить агента, агент вспомогательную программу, а она запросит действие SSH. Запишите наблюдаемую цепочку, но определите процесс, к которому относится контроль. Иначе одна команда сгруппирует данные по основному агенту, другая по помощнику, и совокупность изменится посреди аудита.

Компактный объект сеанса явно задает состав доказательства:

{"session_id":"ses_01JX...","host_id":"mac-042","started_at":"2026-07-21T14:03:18Z","ended_at":"2026-07-21T14:48:02Z","executable":"/usr/local/bin/agent","signing_authority":"Developer ID Application: Example","parent_pid":8821,"local_account":"builder","authorization":{"decision":"approved","method":"local_user_action","at":"2026-07-21T14:03:22Z"},"revoked_at":null}

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

В Sallyport журнал Sessions записывает запуски агентов, а карточка одобрения первого вызова сначала показывает центр подписи процесса и разрешает работу до его завершения. Это хорошее локальное подтверждение сеанса, но для утверждений о конкретном сотруднике, управляемом устройстве, одобренном изменении или корпоративном входе нужны внешние записи.

Результат вызова должен позволять принять решение

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

Термины результата должны быть строгими. «Отклонено» означает, что средство контроля остановило выполнение до внешнего действия. «Ошибка» означает, что выполнение началось, но вернуло ошибку, истекло по времени или потеряло соединение. «Успешно» означает, что удаленный интерфейс сообщил об успехе по описанному правилу. «Неизвестно» покрывает случай, когда клиент отправил действие, но не получил подтверждение. Объединение отклонений и ошибок уничтожает доказательство работы предупредительного контроля.

Статус HTTP редко рассказывает всю историю. Ответ 200 может содержать ошибку приложения. 202 может означать только постановку в очередь. Нулевой код SSH говорит об успешном ответе удаленной оболочки, но не доказывает изменение ожидаемого состояния. Задайте нормализацию для каждого типа действий и храните исходный статус рядом с нормализованным.

Практическая запись может выглядеть так:

{"call_id":"call_01JX...","session_id":"ses_01JX...","occurred_at":"2026-07-21T14:17:09Z","channel":"ssh","destination":"prod-web-03","action":"systemctl restart api","credential_ref":"ssh-prod-ops","approval":{"required":true,"decision":"approved","method":"touch_id"},"execution":{"started":true,"result":"failed","exit_code":1,"error_class":"remote_command_error","duration_ms":842},"ticket_ref":"CHG-1842"}

Не записывайте bearer token, закрытый ключ, полный заголовок авторизации или необработанный ответ ради видимой полноты. Журнал, который раскрывает секреты, создает новый сбой контроля. Используйте стабильную ссылку на учетные данные и фиксируйте способ подстановки, не передавая секрет агенту и в экспорт.

Для CC7.1 проверяющие сопоставят вызовы, способные менять конфигурацию, с дрейфом, развертываниями и найденными уязвимостями. Для CC7.2 они выберут отклоненные, ошибочные, неизвестные, необычные или рискованные действия. Запись поддерживает эти процедуры, только если организация может перечислить полную совокупность. Снимок пяти интересных событий доказывает существование пяти событий, а не проверку всех нужных.

Проверка целостности доказывает согласованность, а не истину

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

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

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

$ sp audit verify /evidence/agent-audit-2026-07.splog
verified: 18432 records
first: 2026-07-01T00:01:44Z
last: 2026-07-31T23:58:10Z
chain: valid

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

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

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

NIST Special Publication 800-92 рекомендует защищать целостность архивов и проверять переданные журналы, обычно сравнением хешей. Совет по-прежнему полезен, но хеш или цепочка не заменяют контроль охвата источников. Применяйте их для выявления сбоев передачи и хранения, затем проверяйте отчетность всех источников в области аудита.

Срок хранения начинается с периода и расследования

SOC 2 не задает единого числа дней для доказательств CC7.1 или CC7.2. Определите срок по периоду аудита, договорным и правовым обязанностям, расследованиям, задержке обнаружения, чувствительности и времени подготовки выборки. Политика должна перечислять классы событий, место, ответственного, ограничения доступа, удаление и исключения.

При проверке Type 2 аудитор изучает работу за период. Если команда хранит только недавнюю локальную историю, она не подтвердит ранние выборки и непрерывность. Покройте весь период, подготовку, полевые работы и разумный запас для уточнений. Более долгие обязательства должен определить юрист или специалист по соответствию, а не чужой отчет.

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

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

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

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

Контроль работает, когда назначенный сотрудник проверяет определенную совокупность с заявленной частотой, применяет письменные критерии и фиксирует решение. Фраза «Журналы регулярно проверяются» не позволяет надежно выбрать образцы. Ежедневная проверка может подходить для производства, одобрение каждого вызова для нескольких мощных ключей, еженедельный анализ для менее рискованной разработки. Оценка риска должна объяснять выбор.

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

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

Храните нулевые результаты. В спокойный день сохраненный запрос, окно, время, имя проверяющего и нулевое число доказывают запуск процедуры. Месяц только с положительными заявками заставляет сомневаться в днях без заявок. Аудитор выбирает работу контроля, а не только интересные случаи.

Доказательство проверки включает:

• Запрос совокупности или критерии экспорта и их версию.
• Начало, окончание, часовой пояс и число записей.
• Имя проверяющего, время завершения и объяснение задержек.
• Каждую выбранную аномалию, решение и обоснование.
• Ссылки на инцидент, изменение или проблему при передаче.

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

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

CC7.2 требует определить, относится ли аномалия к событию безопасности. Закрытие заявки как «ложное срабатывание» без причины не доказывает анализ. Запись должна описать событие, влияние на цели, подтверждающие данные, автора решения и последующие изменения детектора или процедуры.

Соберите пакет вокруг утверждений и выборок

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

Используйте это сопоставление как индекс:

Для каждой меры держите одностраничное определение с формулировкой, владельцем, частотой, совокупностями, процедурой, артефактами, местом и исключениями. Добавьте словарь полей. Аудитор не должен гадать, значит ли actor сотрудника, учетную запись, процесс или центр подписи.

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

Сверяйте суммы на каждой передаче. Число в Sessions должно совпадать с экспортом при описанных фильтрах. Число вызовов до и после передачи должно совпасть. Входы проверки должны раскладываться на выбранные, исключенные и открытые. Объясняйте тестовые среды, согласованные исключения, повторы и данные вне окна.

Отчет Type 1 оценивает устройство на одну дату. Type 2 также оценивает работу за период. Текущий снимок, свежая проверка или новая процедура помогут Type 1, но не восстановят месяцы отсутствующей работы для Type 2. Если истории нет, раскройте пробел и измените сроки готовности, а не создавайте подписи задним числом.

До полевых работ спросите, как аудитор хочет получить зашифрованные или чувствительные данные, какие атрибуты нужны и что он будет выбирать: даты, сеансы, вызовы или оповещения. Разговор меняет упаковку, а не контроль. Контроль должен уже работать последовательно.

Данные об охвате и реакции берите из других систем

Локальные журналы видят только действия, прошедшие локальным путем. Они не доказывают, что так выполняются все производственные изменения. Администраторы могут использовать облачную консоль, прямой SSH, учетные данные CI/CD, поддержку поставщика, аварийные учетные записи, задания или другую станцию. Перечислите пути и включите их в контроль либо собирайте журналы отдельно.

Для CC7.1 также нужны:

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

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

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

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

Собирайте данные управления. Оценка риска объясняет роль действий агентов для CC7.1 и CC7.2. Политики распределяют ответственность за журналы, уязвимости, мониторинг, проверку, инциденты и хранение. Обучение охватывает одобряющих и проверяющих. Проверка доступа показывает, кто может читать, экспортировать, администрировать или удалять доказательства и менять логику обнаружения.

NIST Special Publication 800-92 рассматривает управление журналами как создание, передачу, хранение, анализ и удаление. Этот цикл хорошо проверяет слишком локальное решение. Если оно охватывает создание и хранение, но пропускает передачу, анализ и удаление, работа не закончена даже при надежной криптографии.

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

Используйте журналы как узкий проверяемый компонент

Локальные защищенные журналы полезны, когда формулировка меры совпадает с наблюдениями. Они дают подробные данные сеансов и вызовов, сохраняют отклоненные попытки, которых нет в удаленной системе, и обнаруживают последующие изменения. Это особенно полезно для ИИ-агентов: удаленный API часто видит общую служебную учетную запись и теряет контекст процесса.

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

До применения проведите сквозной тест с заданным событием. Запустите узнаваемый тестовый сеанс, попробуйте одобренное и отклоненное действие, подтвердите результаты, экспортируйте период, проверьте цепочку, запустите правило выбора, запишите решение и сверьте удаленное событие. Затем повторите извлечение для старого периода. Каждый разрыв означает настоящий пробел.

Передайте аудитору результат цепочки, а также реестр источников, правило выбора, доказательство проверки, исключения и внешние подтверждения. Такой пакет поддерживает обоснованный контроль CC7.1 или CC7.2. Одна цепочка поддерживает только скромное утверждение: предоставленная локальная история сохранила структуру, которую ожидал проверяющий инструмент.