Если бы были просто герконы, то дверь смог бы открыть кто угодно и было уведомление о просто доступе, поскольку не каждый будет держать в памяти, что ему необходимо идентифицировать себя приложив карточку к считывателю, а так замок выступает в качестве сдерживания. С БКИ идея была - но отказались, не всем удобно бегать к одной точки и нажимать кнопки, большей части сотрудников удобней локально открывать ту или иную стойку в ряду. Считыватель можно, в целом, использовать и один на стойку, открывая с него оба замка с обеих сторон. Но в нашем случае пошли вот таким путем, точечного доступа.
Да, 12в все же присутствуют в данном случае, но в статье использованы не самые последние фотографии, витая пара в местах трения/изгиба защищена дополнительной изоляцией (спиральной). +Все стойки сведены в единый контур заземления здания. Но и опять же, те же камеры запитанные по POE 48в как-то живут :)
В нашем случае больше отталкивались уже от имеющийся инфраструктуры самого ЦОД, а у нас как раз везде "Болид", это позволяет легко интегрироваться в имеющееся решение.
В данном случае управление происходит непосредственно контроллером и "ключи" хранятся непосредственно в нем. А вот задаются они с сервера Орион ПРО, по этому "лага" нет, если ключ есть в памяти контроллера. Если использовать версию с обращение на сервер, то да, могут быть задержки при работе, но это скорей больше проблема конкретного ПО и линии связи (в данном случае протокол RS 485).
Стойка как бы не в чистом поле стоит, а в ЦОДе. Там есть охрана, видеонаблюдение. Открытие двери контролируется герконом и событие прилетает на охрану. Сложно представить ситуацию, когда такой взлом может увенчаться успехом и остаться незамеченным в стенах ЦОД. В целом задачи тотальной блокировки доступа у нас не стояла, как правильно заметили выше, но будет такое ТЗ - сделаем)
Полноразмерное решение Endpoint стало действительно меньше нагружать систему. Для обычного современного ПК или ноутбука работа Endpoint давным-давно не в напряг, и при проверках его активность не сказывается в худшую сторону на системе. Чтобы не быть голословным, в следующий раз соберу несколько примеров нагрузки на современную систему при проверке.
В статье идет речь о решении для виртуальных сред, где все характеристики, грубо говоря, нужно умножать на два, так как виртуализация дает о себе знать. Поэтому предлагается решение на базе Легкого агента, который часть нагрузки переносит на выделенные машины защиты (SVM).
Endpoint в свою очередь, стал более гибким в настройках, что позволяет экономить ресурсы в зависимости от правил. К примеру, есть параметр: «Уступать ресурсы другим программам». Если он включен, Endpoint будет уступать ресурсы другим программам, запущенным параллельно проверке. Есть другой вариант: «Выполнять проверку при простое компьютера». В таком случае проверка будет выполняться, пока система бездействует. И таких тонкостей в новых решениях от Касперского — много!
Вопросы это всегда хорошо! Задавать их очень даже нужно! Постараемся ответить в следующей части статьи, в которой сравним Легкий агент с Endpoint security. Если есть еще вопросы по этой теме — пишите. Соберем все и напишем подробный ответ.
Скажу лишь, что SVM — это централизованный механизм проверки, и все машины, подключенные к определенной SVM, пополняют свою базу знаний за счет других ВМ, работающих в этой связке :)
Не совсем так. Дело в том, что виртуальная машина защиты (SVM) — это что-то в роде Appliance. Развертывание происходит на саму виртуализацию, используемую для создания VDI. Конечная нагрузка на эту систему будет зависеть от количества подключаемых Легких агентов.
Но даже вариант с перегрузом по количеству Легких агентов предусмотрен. Нагрузка автоматически распределяется между множеством SVM по алгоритмам балансировки в KSC. Можно управлять балансировкой вручную, например, ограничивать определенные SVM и указывать жесткую привязку Легкого агента к одной или нескольким выделенным машинам защиты.
Замечаний по работе такой системы у нас не возникло, в большинстве случаев используем автоматическую балансировку нагрузки на SVM. В дальнейшем планируем еще одну статью по сравнению Легкого агента с Endpoint, которая расставит все точки над Й!)
Легкий агент по компонентам защиты ничем не отличается от «полноразмерного» решения для настольных ПК, ноутбуков и т.д. Исходя из этого, действовать он будет в точности как и kaspersky endpoint security, поскольку в проверке по умолчанию включен пункт «выполнять поиск программ, предназначенных для скрытия следов вредоносной программы в системе (руткитов)». Соответственно, Легкий агент так же следит за запущенными в системе процессами, как и его старший собрат.
Вы верно подметили, для подобных проблем в касперском предусмотрен эвристический метод проверки поведения той или иной сущности. Также есть возможность проверки файлов с использованием облачной среды обмена KSN, в том числе, неизвестными угрозами и их сигнатурами.
На данный момент проблем с актуальностью баз со стороны касперского не наблюдалась и ранее неизвестные угрозы касперский отрабатывал на ура.
Если я вас правильно понимаю и под сессией в данном ответе вы представляете в целом доступность виртуальной машины при обрыве связи. То проблем с доступностью ВМ не наблюдалось. Приватное облако и все ВМ по отдельности остаются доступными. Поправьте, если я вас понял некорректно
В момент потери связи с KSC и соответственно с SVM Легкий агент будет опираться на политику, полученную до потери связи. Легкий агент самодостаточный, чтобы работать без взаимодействия с виртуальной машиной защиты. Она нужна ему для эластичности, чтобы в момент штатных задач не перегружать и без того нагруженную ВМ.
По факту Легкий агент маловероятно сможет потерять связь с SVM. Она является чем то вроде Appliance для среды виртуализации — живет непосредственно на самой виртуализации и контролирует ее.
В контексте статьи я имел в виду запущенную задачу сканирования системы. Чтобы ее не нагружать, подозрительные файлы проверяются на стороне SVM. Легкий агент самодостаточный и может на лету определить вирус при попадании в систему – по имеющейся базе, которую он получает от SVM.
Про динрейку в статье написано, если ее прочитать
Если бы были просто герконы, то дверь смог бы открыть кто угодно и было уведомление о просто доступе, поскольку не каждый будет держать в памяти, что ему необходимо идентифицировать себя приложив карточку к считывателю, а так замок выступает в качестве сдерживания. С БКИ идея была - но отказались, не всем удобно бегать к одной точки и нажимать кнопки, большей части сотрудников удобней локально открывать ту или иную стойку в ряду. Считыватель можно, в целом, использовать и один на стойку, открывая с него оба замка с обеих сторон. Но в нашем случае пошли вот таким путем, точечного доступа.
Да, 12в все же присутствуют в данном случае, но в статье использованы не самые последние фотографии, витая пара в местах трения/изгиба защищена дополнительной изоляцией (спиральной). +Все стойки сведены в единый контур заземления здания. Но и опять же, те же камеры запитанные по POE 48в как-то живут :)
Спасибо и вам за интерес к нашим решениям!)
В нашем случае больше отталкивались уже от имеющийся инфраструктуры самого ЦОД, а у нас как раз везде "Болид", это позволяет легко интегрироваться в имеющееся решение.
В данном случае управление происходит непосредственно контроллером и "ключи" хранятся непосредственно в нем. А вот задаются они с сервера Орион ПРО, по этому "лага" нет, если ключ есть в памяти контроллера. Если использовать версию с обращение на сервер, то да, могут быть задержки при работе, но это скорей больше проблема конкретного ПО и линии связи (в данном случае протокол RS 485).
Стойка как бы не в чистом поле стоит, а в ЦОДе. Там есть охрана, видеонаблюдение.
Открытие двери контролируется герконом и событие прилетает на охрану.
Сложно представить ситуацию, когда такой взлом может увенчаться успехом и остаться незамеченным в стенах ЦОД.
В целом задачи тотальной блокировки доступа у нас не стояла, как правильно заметили выше, но будет такое ТЗ - сделаем)
В статье идет речь о решении для виртуальных сред, где все характеристики, грубо говоря, нужно умножать на два, так как виртуализация дает о себе знать. Поэтому предлагается решение на базе Легкого агента, который часть нагрузки переносит на выделенные машины защиты (SVM).
Endpoint в свою очередь, стал более гибким в настройках, что позволяет экономить ресурсы в зависимости от правил. К примеру, есть параметр: «Уступать ресурсы другим программам». Если он включен, Endpoint будет уступать ресурсы другим программам, запущенным параллельно проверке. Есть другой вариант: «Выполнять проверку при простое компьютера». В таком случае проверка будет выполняться, пока система бездействует. И таких тонкостей в новых решениях от Касперского — много!
Скажу лишь, что SVM — это централизованный механизм проверки, и все машины, подключенные к определенной SVM, пополняют свою базу знаний за счет других ВМ, работающих в этой связке :)
Но даже вариант с перегрузом по количеству Легких агентов предусмотрен. Нагрузка автоматически распределяется между множеством SVM по алгоритмам балансировки в KSC. Можно управлять балансировкой вручную, например, ограничивать определенные SVM и указывать жесткую привязку Легкого агента к одной или нескольким выделенным машинам защиты.
Замечаний по работе такой системы у нас не возникло, в большинстве случаев используем автоматическую балансировку нагрузки на SVM. В дальнейшем планируем еще одну статью по сравнению Легкого агента с Endpoint, которая расставит все точки над Й!)
На данный момент проблем с актуальностью баз со стороны касперского не наблюдалась и ранее неизвестные угрозы касперский отрабатывал на ура.
Если я вас правильно понимаю и под сессией в данном ответе вы представляете в целом доступность виртуальной машины при обрыве связи. То проблем с доступностью ВМ не наблюдалось. Приватное облако и все ВМ по отдельности остаются доступными. Поправьте, если я вас понял некорректно
По факту Легкий агент маловероятно сможет потерять связь с SVM. Она является чем то вроде Appliance для среды виртуализации — живет непосредственно на самой виртуализации и контролирует ее.