Это от меня :)
Ссылку на чат на своём канале опубликовал

Вот это было жёстко! :)

Это же шутка, ну кто после спланка перелезет на mp siem😬

Вот это было жёстко! :)

Тут согласен😁

Ага, увидел. Интересное распределение числа подключившихся по чатикам

Ну вообще-то СБ я так понял по умолчанию хранит свои события в файлах в своей директории, а опционально может в базе. Вот только почему-то PT считает что хранение в базе это способ основной, соответственно, описано только подключение через базу.

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

так что тут я согласен с PT что основной и правильный способ это именно хранение на SQL сервере.

почему-то разработчики D-Lock так не думают, раз опция хранения в файлах является дефолтной :)

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

Честно говоря, никогда не ставил без БД, но в руководстве есть буквально следующее:
Наличие системы управления базами данных позволит:
-сохранять данные аудита Сервера безопасности, Windows клиентов и Linux
клиентов во внешней базе данных (по запросу АИБ, по расписанию, с
периодом);
-выполнять необходимую выборку данных в соответствии с имеющимся
функционалом фильтрации записей.

То есть вроде бы как без БД это не получится.

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

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

Хотя, конечно, полноценный журнал с фильтрацией на файлах работать будет невесело

ну так вот и казалось бы - Dallas Lock разработка российская, в качестве дополнительной опции предлагается установка лишней сущности (сторонней БД), да ещё и иностранной (MSSQL).

у меня проблема именно в этом. заказчик мне говорит, почему я должен прикручивать сбоку БД к Серверу Безопасности Dallas Lock, если в установке по умолчанию этого СЗИ такая инсталляция не обязательна.

а без БД события не забрать, такая вот история

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

чтобы не потерять ничего при упавшем коллекторе?

ну вот я копаю в эту сторону со стороны поддержки Dallas Lock, потому что какая-то настройка syslog, судя по документации, там имеется, только вот ничего не шлет. мне больше интересно была ли эта возможность рассмотрена при написании профилей для Dallas Lock на стороне PT