Да, это уже отдельный и достаточно большой вопрос, который остался за рамками статьи. В материале рассматривалась архитектура защиты частного облака и взаимодействие между двумя ЦОД, а не организация пользовательского доступа.
Если говорить о сценарии с распределёнными пользователями и дистанционными работниками, то перенос всех пользовательских АРМ в защищённый контур за сертифицированным МЭ далеко не всегда является оптимальным или единственно возможным решением.
В таких случаях обычно строится отдельная архитектура защищённого удалённого доступа: используются VPN, средства доверенной среды, VDI или иные механизмы, предусмотренные принятой моделью безопасности и требованиями регулятора. При этом пользователь получает прозрачный доступ к информационной системе, а выполнение требований по защите обеспечивается архитектурой доступа, а не физическим размещением АРМ внутри защищённого сегмента.
Поэтому ответ зависит от конкретной модели эксплуатации ИСПДн, категории пользователей и выбранной архитектуры удалённого доступа.
Добрый день, в статье сознательно не раскрывался конкретный уровень защищённости, поскольку целью было показать архитектурные подходы. Для рассматриваемого контура требования регулятора предполагали использование сертифицированных средств защиты.
Если говорить в общих чертах, то для информационных систем, подпадающих под требования регулятора, АРМ администраторов и технологического управления также должны размещаться в защищённом контуре за сертифицированным межсетевым экраном. Для остальных информационных систем АРМ управления могли располагаться в сегментах корпоративной сети передачи данных (КСПД).
Межсистемные взаимодействия строились по тем же принципам: трафик, относящийся к нормативному контуру, проходил через сертифицированный МЭ, тогда как остальные взаимодействия осуществлялись через высокопроизводительный NGFW в соответствии с принятой моделью сегментации и контроля трафика.
Также делимся записью выступления Артёма Чуйкова о сегментировании сетей — ссылка на Рутуб. Возможно, материал будет полезен для более глубокого погружения в тему.
Добрый день! Между телефоном и ноутбуком должен быть настроен МСЭ уровня хоста, в самой ОС. В статье же речь идёт о МСЭ уровня сети. Его назначение — отделить потенциально небезопасный АРМ от защищаемого сегмента и осложнить перемещение злоумышленника в инфраструктуре. Воздушный зазор подразумевает отсутствие любых взаимодействий изолированного АРМ с внешними сетями. Подключение через телефон к сети Интернет нарушает эту изоляцию и формирует потенциальную точку входа. С помощью методов социальной инженерии оператор АРМ может быть убеждён запустить вредоносный файл. Со скомпрометированного АРМ атака может развиваться дальше, могут быть попытки получить доступ и к МСЭ, и к каким-либо хостам в одном с данным АРМ широковещательном домене. Для защиты МСЭ — харденинг, для защиты хостов за МСЭ уровня сети — сегментирование.
Благодарим за интерес к теме. Рады, что статья вам понравилась.
Ответ автора: К сожалению, присутствие подрядчика по ИБ далеко не всегда означает, что заказчик “дозрел”. Есть три пути понимания и принятия ИБ .
Оценка рисков, вывод, что ИБ необходимо и дешевле, чем реализация потенциальных угроз. В таком случае заказчик готов сотрудничать, но это не говорит о том, что все сотрудники заказчика разделяют его точку зрения. Но, по крайней мере административный ресурс на стороне подрядчика. 2. Давление регулятора. Заказчику некуда деваться, он вынужден внедрять средства обеспечения ИБ и выстраивать процессы. В таком случае приходится преодолевать сопротивление, объяснять, уговаривать. 3. Отрицание угрозы. Инициатива по внедрению средств ИБ исходит снизу, от человека, продавившего руководство на внедрение всей системы обеспечения ИБ или ее части, пусть даже нашелся бюджет, но это никому, кроме человека, инициировавшего процесс, не интересно и не надо.
Вывод: Внедрение средств ИБ ограничивает “свободу” сотрудника, делает неудобным то, что раньше делалось легко и непринужденно. Появляются какие-то пароли, которые надо менять, уже нельзя посмотреть котиков в интернете, нельзя просто взять и послать файл по почте. Как бы организация не была готова к внедрению ИБ, само внедрение всегда сталкивается с сопротивлением, что делать, преодолеваем.
Про LLM as a judge — да, ровно к этому же и пришли в команде. LLM как первая линия слишком дорога и слепа в ряде кейсов, поэтому каскад — по сути единственный рабочий вариант. Интересно, что Anthropic недавно в CC++ показали ту же логику, но пошли ещё глубже: быстрый слой у них теперь вообще не по тексту, а по внутренним активациям модели (linear probes), а генеративный классификатор включается только в спорных случаях. По сути, та же архитектура, просто смещённая ближе к inference.
Спасибо за дополнение по векторам атак. Echo Chamber и Memory Poisoning сейчас особенно больны для агентных систем с persistent state.
Классно, что используете entropy логитов и attention. По ощущениям, именно такие low-level сигналы и будут основной защитой дальше: дёшево по latency и сложно обходятся обычными джейлбрейками.
Ещё раз спасибо — отличный практический апдейт к статье.
Да, как и отметили в предыдущем комментарии, проблемы случались, как правило, в этом интервале и тесты проводились по несколько раз. В будущем увеличим длительность тестов и добавим тест с включенной SSL-инспекцией.
В Trex есть параметр tcps_sndctrl, но он считает общее количество "control (SYN|FIN|RST) packets sent". В результатах тестов общее кол-во дропов (tcps_conndrops) было <0.105 %, поэтому считаем тесты успешными.
Добрый день. Используем OpenAI, совместимые API, в целом можем работать с разными reasoning LLM. На текущий момент неплохо справляется с задачами квантизованная Qwen3.
Добрый вечер. На возможность работы с ipv6 пока не проверяли, но планируем внедрить в ближайших релизах. Поделимся опытом позже. Для более детального ознакомления с интерфейсом и возможностями продукта, напишите, пожалуйста, нам на почту Yuliya.Maksimenko@innostage-group.ru
Здравствуйте! Спасибо за Ваш вопрос! Мы не делаем соединение (JOIN) показателей между собой по какому-либо полю, мы делаем объединение их значений (UNION). JOIN используется только для получения связанных с показателем «измерений». Таким образом, с бека возвращаются записи показателей последовательно. Далее, при необходимости вывода записей в сводном представлении отрабатывает компонент на фронте, который располагает полученные данные в соответствии с настройками представления.
Добрый день! Спасибо за комментарий! Вы правы, нам было недостаточно того, что есть на рынке на сегодняшний день. И на текущий момент мы еще не столкнулись с нерешаемыми бизнес-задачами в части работы с показателями.
Спасибо за развернутый комментарий! Стратегия может меняться 3 месяца. Мы живем в такое время, когда ежедневно происходят изменения и мы должны быть чуткими к этим изменениям. И в этом состоит суть нашего видения. KPI – адаптируемый под требования бизнеса, ПО – максимально гибкое, позволяющее быстро перестроить систему показателей без особых затрат.
По самим показателям – да, многие могут приводить к фальсификациям, но здесь есть два момента, на которые хотелось бы обратить внимание:
Из двух зол выбираем меньшее – либо вообще никак не оцениваем (либо оценка очень субъективна на совести руководства) либо оценка, под которую подстраиваются сотрудники (что не всегда плохо).
Необходимо отслеживание таких фальсификаций, если показатель сотрудников идет вверх, а целевой на уровне отдела\компании никак не меняется, то налицо злоупотребления. И здесь мы должны принять ответные меры – провестим анализ, скорректировать показатели, изменить расчеты, причем быстро и дешево.
Мы много работаем в госорганах, и там цели и показатели достаточно четко выстроены. Но мы так же работаем и в бизнесе. На самом деле, суть везде одинакова – нет принципиальных различий между процессами построения системы KPI в бизнесе и госсекторе.
Спасибо за ваше мнение. В принципе, вы абсолютно правы в том, что такие технологии не принесут успеха без решения множества вопросов: корректировки бизнес-процессов, организационных вопросов, целеполагания и проч. На это мы и указываем. И конечно, на наш взгляд, не на последнем месте управленческий учет как таковой вкупе с программным обеспечением, позволяющим подстраиваться под нужды бизнеса и приносить пользу при этом не являясь чем-то монстроидальным и неповоротливым.
Да, это уже отдельный и достаточно большой вопрос, который остался за рамками статьи. В материале рассматривалась архитектура защиты частного облака и взаимодействие между двумя ЦОД, а не организация пользовательского доступа.
Если говорить о сценарии с распределёнными пользователями и дистанционными работниками, то перенос всех пользовательских АРМ в защищённый контур за сертифицированным МЭ далеко не всегда является оптимальным или единственно возможным решением.
В таких случаях обычно строится отдельная архитектура защищённого удалённого доступа: используются VPN, средства доверенной среды, VDI или иные механизмы, предусмотренные принятой моделью безопасности и требованиями регулятора. При этом пользователь получает прозрачный доступ к информационной системе, а выполнение требований по защите обеспечивается архитектурой доступа, а не физическим размещением АРМ внутри защищённого сегмента.
Поэтому ответ зависит от конкретной модели эксплуатации ИСПДн, категории пользователей и выбранной архитектуры удалённого доступа.
Добрый день, в статье сознательно не раскрывался конкретный уровень защищённости, поскольку целью было показать архитектурные подходы. Для рассматриваемого контура требования регулятора предполагали использование сертифицированных средств защиты.
Если говорить в общих чертах, то для информационных систем, подпадающих под требования регулятора, АРМ администраторов и технологического управления также должны размещаться в защищённом контуре за сертифицированным межсетевым экраном. Для остальных информационных систем АРМ управления могли располагаться в сегментах корпоративной сети передачи данных (КСПД).
Межсистемные взаимодействия строились по тем же принципам: трафик, относящийся к нормативному контуру, проходил через сертифицированный МЭ, тогда как остальные взаимодействия осуществлялись через высокопроизводительный NGFW в соответствии с принятой моделью сегментации и контроля трафика.
Также делимся записью выступления Артёма Чуйкова о сегментировании сетей — ссылка на Рутуб. Возможно, материал будет полезен для более глубокого погружения в тему.
Добрый день! Между телефоном и ноутбуком должен быть настроен МСЭ уровня хоста, в самой ОС. В статье же речь идёт о МСЭ уровня сети. Его назначение — отделить потенциально небезопасный АРМ от защищаемого сегмента и осложнить перемещение злоумышленника в инфраструктуре. Воздушный зазор подразумевает отсутствие любых взаимодействий изолированного АРМ с внешними сетями. Подключение через телефон к сети Интернет нарушает эту изоляцию и формирует потенциальную точку входа. С помощью методов социальной инженерии оператор АРМ может быть убеждён запустить вредоносный файл. Со скомпрометированного АРМ атака может развиваться дальше, могут быть попытки получить доступ и к МСЭ, и к каким-либо хостам в одном с данным АРМ широковещательном домене. Для защиты МСЭ — харденинг, для защиты хостов за МСЭ уровня сети — сегментирование.
Благодарим за интерес к теме. Рады, что статья вам понравилась.
Ответ автора: К сожалению, присутствие подрядчика по ИБ далеко не всегда означает, что заказчик “дозрел”. Есть три пути понимания и принятия ИБ .
Оценка рисков, вывод, что ИБ необходимо и дешевле, чем реализация потенциальных угроз. В таком случае заказчик готов сотрудничать, но это не говорит о том, что все сотрудники заказчика разделяют его точку зрения. Но, по крайней мере административный ресурс на стороне подрядчика. 2. Давление регулятора. Заказчику некуда деваться, он вынужден внедрять средства обеспечения ИБ и выстраивать процессы. В таком случае приходится преодолевать сопротивление, объяснять, уговаривать. 3. Отрицание угрозы. Инициатива по внедрению средств ИБ исходит снизу, от человека, продавившего руководство на внедрение всей системы обеспечения ИБ или ее части, пусть даже нашелся бюджет, но это никому, кроме человека, инициировавшего процесс, не интересно и не надо.
Вывод: Внедрение средств ИБ ограничивает “свободу” сотрудника, делает неудобным то, что раньше делалось легко и непринужденно. Появляются какие-то пароли, которые надо менять, уже нельзя посмотреть котиков в интернете, нельзя просто взять и послать файл по почте. Как бы организация не была готова к внедрению ИБ, само внедрение всегда сталкивается с сопротивлением, что делать, преодолеваем.
Про LLM as a judge — да, ровно к этому же и пришли в команде. LLM как первая линия слишком дорога и слепа в ряде кейсов, поэтому каскад — по сути единственный рабочий вариант. Интересно, что Anthropic недавно в CC++ показали ту же логику, но пошли ещё глубже: быстрый слой у них теперь вообще не по тексту, а по внутренним активациям модели (linear probes), а генеративный классификатор включается только в спорных случаях. По сути, та же архитектура, просто смещённая ближе к inference.
Спасибо за дополнение по векторам атак. Echo Chamber и Memory Poisoning сейчас особенно больны для агентных систем с persistent state.
Классно, что используете entropy логитов и attention. По ощущениям, именно такие low-level сигналы и будут основной защитой дальше: дёшево по latency и сложно обходятся обычными джейлбрейками.
Ещё раз спасибо — отличный практический апдейт к статье.
Рады, что статья вам понравилась. Спасибо за обратную связь.
Да, как и отметили в предыдущем комментарии, проблемы случались, как правило, в этом интервале и тесты проводились по несколько раз. В будущем увеличим длительность тестов и добавим тест с включенной SSL-инспекцией.
Спасибо! Да, такие планы есть
Проблемы в тестах (когда они возникали) случались в этом интервале, более длительный тест обычно даёт тот же результат.
В Trex есть параметр tcps_sndctrl, но он считает общее количество "control (SYN|FIN|RST) packets sent". В результатах тестов общее кол-во дропов (tcps_conndrops) было <0.105 %, поэтому считаем тесты успешными.
Нет, к сожалению, NGFW Континент 4 пока не поддерживает IPv6
Корректировка: Используем OpenAI совместные API
Добрый день. Используем OpenAI, совместимые API, в целом можем работать с разными reasoning LLM. На текущий момент неплохо справляется с задачами квантизованная Qwen3.
Добрый вечер. На возможность работы с ipv6 пока не проверяли, но планируем внедрить в ближайших релизах. Поделимся опытом позже. Для более детального ознакомления с интерфейсом и возможностями продукта, напишите, пожалуйста, нам на почту Yuliya.Maksimenko@innostage-group.ru
Здравствуйте! Спасибо за Ваш вопрос!
Мы не делаем соединение (JOIN) показателей между собой по какому-либо полю, мы делаем объединение их значений (UNION). JOIN используется только для получения связанных с показателем «измерений». Таким образом, с бека возвращаются записи показателей последовательно. Далее, при необходимости вывода записей в сводном представлении отрабатывает компонент на фронте, который располагает полученные данные в соответствии с настройками представления.
Добрый день! Спасибо за комментарий!
Вы правы, нам было недостаточно того, что есть на рынке на сегодняшний день.
И на текущий момент мы еще не столкнулись с нерешаемыми бизнес-задачами в части работы с показателями.
Здравствуйте!
Спасибо за ваше мнение )
Спасибо за развернутый комментарий!
Стратегия может меняться 3 месяца. Мы живем в такое время, когда ежедневно происходят изменения и мы должны быть чуткими к этим изменениям. И в этом состоит суть нашего видения. KPI – адаптируемый под требования бизнеса, ПО – максимально гибкое, позволяющее быстро перестроить систему показателей без особых затрат.
По самим показателям – да, многие могут приводить к фальсификациям, но здесь есть два момента, на которые хотелось бы обратить внимание:
Из двух зол выбираем меньшее – либо вообще никак не оцениваем (либо оценка очень субъективна на совести руководства) либо оценка, под которую подстраиваются сотрудники (что не всегда плохо).
Необходимо отслеживание таких фальсификаций, если показатель сотрудников идет вверх, а целевой на уровне отдела\компании никак не меняется, то налицо злоупотребления. И здесь мы должны принять ответные меры – провестим анализ, скорректировать показатели, изменить расчеты, причем быстро и дешево.
Мы много работаем в госорганах, и там цели и показатели достаточно четко выстроены. Но мы так же работаем и в бизнесе. На самом деле, суть везде одинакова – нет принципиальных различий между процессами построения системы KPI в бизнесе и госсекторе.
Спасибо за ваше мнение. В принципе, вы абсолютно правы в том, что такие технологии не принесут успеха без решения множества вопросов: корректировки бизнес-процессов, организационных вопросов, целеполагания и проч. На это мы и указываем. И конечно, на наш взгляд, не на последнем месте управленческий учет как таковой вкупе с программным обеспечением, позволяющим подстраиваться под нужды бизнеса и приносить пользу при этом не являясь чем-то монстроидальным и неповоротливым.