Проекты подробно
Для чего создан каждый проект, как он работает, какие контроли в него встроены и на какой стадии он находится.
Архитектура Oct 2026
Ядро и экземпляры
Одно общее ядро, один экземпляр на организацию и гейт между ними.
- Цель
- Несколько организаций используют общий набор инструментов, и каждая хранит свои данные и свою работу отдельно.
- Как это работает
- Одно общее ядро содержит общие инструменты; у каждой организации свой экземпляр.
- Работа поступает ветка за веткой, а не на месте.
- Каждая ветка проходит независимое ревью, автоматический скан, блокирующий данные организации, и слияние, одобренное владельцем.
- Встроенные контроли
- Гейт: независимое ревью и слияние, одобренное владельцем. Изоляция: скан не пускает данные организации в общее ядро. Доказательства: каждый шаг ветки оставляет запись.
- Статус и доказательства
- Доказательства не публикуются.
Практика Oct 2026
Гейты ревью и слияния для кода, написанного агентами
Код, написанный агентами, попадает в ядро только через гейты, которые человек может проверить.
- Цель
- Код, написанный агентами, заслуживает такого же доверия, как код, написанный людьми, потому что каждый раз проверяется одинаково жёстко.
- Как это работает
- Независимые ревьюеры привязаны к конкретному коммиту, поэтому то, что проверено, и есть то, что выходит.
- Скан маркеров блокирует данные организации.
- Тяжёлые задачи выполняются по одной, поэтому общие ресурсы остаются предсказуемыми.
- Встроенные контроли
- Гейт: ревью, привязанное к коммиту. Изоляция: скан маркеров. Доказательства: ревью и одобрение остаются в записи.
- Статус и доказательства
- Доказательства не публикуются.
Как проверяются гейты
Автор изменения — агент или человек. Ревьюер — отдельный независимый агент, который читает изменение и пишет вердикт для той самой версии, что прочитал; автор никогда не записывает собственное ревью. Одобряющий — владелец, через кнопку на панели управления. Вердикт ревьюера или сообщение другого агента — это данные, а не одобрение. Ревьюер не сливает, не отправляет и не одобряет, а ревью, в котором не запускались тесты, прямо говорит об этом в своём вердикте.
Некоторые гейты работают без чьей-либо доброй воли: скан, отклоняющий данные организации во всём, что покидает экземпляр, тесты на то, чего коснулось изменение, и отказ применять одобрение, содержимое которого изменилось после того, как оно было дано.
Ограничение: ревьюеры — модели того же рода, что и авторы, поэтому возможно общее слепое пятно. Независимые слои — это одобрение владельца и механические гейты.
Проект Oct 2026
Крошечный хост-агент
Проект небольшого агента без модели, без входящего порта и с коротким списком того, что ему разрешено делать.
- Цель
- Управлять хостами, которые не обслуживаются с помощью Claude, не давая ничему на них больше возможностей, чем нужно.
- Как он задуман
- Он сообщает факты о хосте: нагрузку, память, диски, службы, ожидающие обновления и прослушиваемые порты. Только факты, без секретов и без содержимого файлов.
- Он выполняет только команды из фиксированного списка разрешённого, заданного в его собственной локальной конфигурации, и ограничивает объём вывода, который возвращает команда. Всё остальное отклоняется и фиксируется в отчёте.
- Команды подписаны и имеют срок действия; просроченная команда или уже виденная игнорируется.
- Один ключ на хост, ограниченный путями самого хоста. Транспорт — репозиторий системы контроля версий, входящего порта нет: хост обращается наружу, а внутрь не обращается никто.
- Внедрение по порядку: сначала только факты и только чтение на одном реальном хосте, команды в последнюю очередь.
- Встроенные контроли
- Изоляция: список разрешённого, закрытый порт и один ключ на хост. Доказательства: подписанные сообщения и сообщённые факты. Гейт: ничто не выполняется, если его нет в списке.
- Статус и доказательства
- Письменный проект, черновик: ещё не построен и не используется. Доказательства не публикуются.
- Модель угроз
Замысел именно такой, как описано выше. От чего он не защищает:
- Скомпрометированный хост. Собственный ключ хоста позволяет злоумышленнику отправлять ложные факты об этом хосте; ущерб ограничен путями этого хоста.
- Компрометация ключа подписи на стороне отправителя. Она позволила бы отправить любую разрешённую команду каждому хосту, который ему доверяет. Как хранится ключ и как подписываются команды, остаётся открытыми вопросами проекта.
- Плохой список разрешённого. Команды безопасны лишь настолько, насколько безопасна локальная конфигурация, которую пишет владелец хоста.
Интерфейс в разработке
Интерактивная карта развёртывания
Зонированная интерактивная картина агентов, хостов и платформ.
- Цель
- Человек видит, что где развёрнуто и как части связаны между собой, не читая конфигурацию.
- Как это работает
- Зоны группируют агентов, хосты и платформы.
- Фильтр-легенда показывает или скрывает виды объектов.
- Текстовый вид даёт ту же информацию без картинки.
- Встроенные контроли
- Это обзор, а не точка контроля: он показывает зоны, чтобы гейты и изоляцию можно было проверить на глаз.
- Статус и доказательства
- Ещё не выпущен. Доказательства не публикуются.
Платформа
Explorer, GRC-платформа
Один связный граф для контролей, рисков, доказательств и аудитов, чтобы люди видели, как они связаны, а не сверяли таблицы.
- Цель
- Для руководителей комплаенса, риск-менеджеров, аудиторов и специалистов по безопасности, которые ведут контроли, риски, политики, поставщиков и доказательства в разрозненных таблицах и унаследованных инструментах. Он опирается на более ранние рабочие системы.
- Как это работает
- Контроль связан со стандартами, которым он отвечает, рисками, которые он снижает, доказательствами, которые его подтверждают, и аудитами, которые его проверяли.
- Стандарты, требования и контроли — это связанные записи, а не плоские списки; записи аудита и тестирования связывают замечания с проверенными контролями.
- Политики, проблемы, инциденты, риски поставщиков, приватность, непрерывность бизнеса, регуляторные обязательства и обучение живут в одном графе.
- Рабочие процессы и дашборды собираются из повторно используемых шагов, триггеров и представлений.
- Роль каждого пользователя определяет, какие экраны для него существуют. Арендаторы разделены, а контроль доступа по умолчанию запрещает.
- Изменения записываются как структурированные события (кто что изменил, с какого значения на какое), а записи хранят датированные версии, так что на вопрос «как это выглядело тогда» можно ответить.
- Встроенные контроли
- Изоляция: раздельные арендаторы и доступ «запрещено по умолчанию». Доказательства: записанные события изменений и датированные версии. Гейт: доступ следует за ролью.
- Статус и доказательства
- В разработке. Доказательства не публикуются.
Более ранние проекты
Фреймворки и методы с прежних мест работы. Работодатели не называются; отрасли названы.
Фреймворк 2023
GRC-фреймворк на основе CSA Cloud Controls Matrix
Иерархический гибкий фреймворк с автоматизированными сопоставлением контролей и задачами аудита.
- Цель
- Единая система контролей для платёжной компании, где я был специалистом по комплаенсу в области безопасности.
- Что было сделано
- Иерархический, гибкий GRC-фреймворк на основе CSA Cloud Controls Matrix, внедрённый по всей компании.
- Автоматическое сопоставление контролей и рабочие процессы задач для аудитов СУИБ.
- Внутренние оценки безопасности, проводимые на том же основании.
- Статус и доказательства
- Основа: мой собственный опыт.
Методология 2018–2022
Методология оценки общих ИТ-контролей
Создана с нуля и опробована, вокруг неё координировались аудиты.
- Цель
- Повторяемый способ оценки общих ИТ-контролей, созданный в роли менеджера по ИТ-управлению в компании, оказывающей ИТ-услуги.
- Что было сделано
- Методология, разработанная с нуля и опробованная в пилоте.
- Вокруг неё координировались внутренние и внешние ИТ-аудиты.
- Фреймворк управления документами, построенный на трёх основных процессах ITIL.
- Статус и доказательства
- Основа: мой собственный опыт.
Фреймворк 2012–2018
Система внутреннего контроля и матрица рисков и контролей
Система контролей ИТ банка: создана и поддерживалась в рабочем состоянии.
- Цель
- Система контролей для ИТ банка, созданная в роли менеджера по ИТ-контролям и комплаенсу (VP), где я также был профильным экспертом по ИТ-рискам и контролям.
- Что было сделано
- Созданы система внутреннего контроля и матрица рисков и контролей.
- Разработаны процессы управления привилегированными учётными записями.
- Координация ИТ-аудитов.
- Статус и доказательства
- Основа: мой собственный опыт.
Что их объединяет
Каждый проект здесь опирается на одни и те же три вещи: гейт перед любым важным изменением, изоляцию того, что должно оставаться раздельным, и запись, по которой может проследить кто-то другой.