Jump to content

Recommended Posts

Posted

Задача: проверять зашифрованные (https) соединения, но не все.

Основной список исключений (условно говоря, “госуслуги” -- банки, правительственные сайты) должен предоставляться централизованно KSC; этого можно добиться, если в KSC определить этот список и включить галку замка “Encrypted connections scan”.

Проблема: бывает нужно добавить свои исключения на рабочих станциях (например, какие-то сайты могут требовать mutual TLS, где касперский-как-человек-посередине, разумеется, не в тему, особенно у разработчиков).

Вопрос: как этого добиться? Если снять замок с политики, то рабочие станции могут добавлять что хотят, но с сервера “список по умолчанию” не приходит (даже если он на сервере заполнен).

Posted

От ручной настройки на рабочих местах всегда лучше уходить и делать централизованно.

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

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

Про профили читать тут: https://support.kaspersky.com/KSC/12/ru-RU/92434.htm

Если есть Active Directory, то идеально нацеливать активацию профиля на группу AD с устройствами (ПК разработчиков).

P.S. На всякий случай упомяну, что некоторое время назад ГосУслуги и остальные популярные сайты с проблемами работы из-за инспекции SSL были внесены ЛК в Глобальный список исключений. Ранее про эти сайты писали в FAQ, теперь они не очень актуальны.

 

Posted

Очевидно, существуют и не-российские аналоги госуслуг. Это был пример для понимания россиянами.

> объединение списка исключений невозможно
Печаль :(

 

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

Posted

@aehrlich , можете ради интереса озвучить проблему почему не хотите делать единый список? Если какая-то задача не работает с инспекцией SSL, то что такого исключить её для всех пользователей? 

Posted

В принципе возможно создать единый список, но поддерживать его -- тот еще административный геморрой. Вот одному разработчику нужен mutual TLS к “его установке” какого-нибудь сервера (ну, скажем, EJBCA). С самоподписанными сертификатами. Какому-то другому внезапно нужен какой-нибудь другой сервер. У компании третьих -- партнерский внутренний (== самоподписанный) сертификат где-то еще это “еще” постоянно меняет URL и/или IP. У четвертого “не подключается, надо понять, виноват ли Касперский”. И все эти исключения будут сыпаться на мой рабочий стол вместо того, чтобы люди занимались самообслуживанием?!

Posted

День добрый.

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

В итоге если им нужно будет проверить “виноватость Каспера” проверят без Вас, если на 1 час исключение добавить - добавят без Вас, если нужно внести в общий список обратятся к Вам.

Главное чтобы временно не стало постоянным.

Posted

Согласен с @tyazhelnikov , тоже подходящий вариант. Разрешения в “Защита паролем” тоже удобно предоставлять через пользовательскую группу Active Directory. Однако в таком варианте сотрудники смогут полностью управлять всем антивирусом на своём ПК, не только блоком инспекции SSL.

 

Ещё по мотивам моего предыдущего поста немного друга реализация:

в основной политике раскрываете замок на блоке назначения настроек “Проверка защищенных соединений”, так на всех ПК изменение параметров инспекции SSL станет доступным для самостоятельного изменения. Далее делаете профиль политики в котором задаются параметры проверки SSL соединений на всех, применяете его на все устройства, кроме устройств разработчиков. 

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

 

  • Solution
Posted

@Demiad 
> Ещё по мотивам моего предыдущего поста немного друга реализация
> профиль политики в котором задаются параметры проверки SSL соединений на всех, применяете его на все устройства, кроме устройств разработчиков
Но разработчиков-то (которых у меня больше половины) тоже хотелось бы от “дикого интернета” защитить.

В общем, я понял, не судьба, да.

Guest
This topic is now closed to further replies.


×
×
  • Create New...