1) На текущий момент разработаны специализированные коннекторы к Active Directory и FreeIPA, а также универсальный коннектор, представляющий собой стандартизированный API. В зависимости от конкретной задачи и особенностей структуры интегрируемых систем в среде заказчика, может потребоваться доработка существующих коннекторов.
Срок разработки нового коннектора в составе существующего набора функциональности зависит от особенностей системы, для которой разрабатывается коннектор, и составляет от 3 месяцев.
2) В настоящее время управление правами доступа осуществляется в рамках ИС и АРМ, управление правами на локальном рабочем месте пользователя не предусмотрено.
Есть отдельная интеграция с SCCM, которая позволяет управлять ПК в рамках возможностей SCCM.
3) Предусмотрен автоматизированный аудит, выполняющий выгрузку прав доступа из интегрируемой системы с использованием коннектора и сопоставление с согласованными правами доступа. В результате система предоставляет аудитору отчет с расхождениями, в том числе в случае выдачи прав в обход IDM. В системе предусмотрено несколько видов аудитов, в том числе с автоматическим исправлением выявленных нарушений. По факту формирования результатов аудита реализован механизм оповещения ответственных лиц.
Мы заранее продумали UI и практически не использовали компоненты из Sailfish Silica (использовали в основном стандартный qt quick). Поэтому адаптировать qml-код практически не нужно будет. Только избавиться от компонентов Page и SilicaListView. А про версию мы в курсе, в планах для Android не использовать в принципе Аврора SDK, а использовать чистый Qt. Получается, для сборки будут использоваться два разных SDK: для "Авроры" — "Aurora SDK", для Android — "Qt 6 SDK". Пока это только все в планах, так что точно не можем сказать, какие трудности могут возникнуть.
В данном случае мы использовали версию Qt 5.15.7, т.к. на ней основана Aurora IDE. В дальнейшем будем использовать более новые версии Qt, вероятнее всего 6.5, т.к. планируем выпускать приложение и под Android
Причина, по которой мы создаем `.sql` файл — желание отделить определение схемы БД от логики работы с ней. Этот файл мы складываем в ассеты, просто чтобы использовать его в самом приложении. Альтернативой (на мой взгляд) является прописывание всей структуры БД в виде строки внутри кода, что не совсем удобно лично для меня. Однако если вы считайте этот подход неправильным, то прошу вас поделиться вашим опытом и идеями на эту тему.
Мы стараемся подбирать хранилище данных так, чтобы оно было оптимальным для конкретной задачи. Так уж вышло, что многие приложения, которые мы разрабатываем, рассчитаны на работу в офлайн-режиме с периодической синхронизацией с главной БД. Поэтому приложение зачастую хранит и обрабатывает большое количество записей, что делает использование SQLite удобным. В дальнейшем планируем поработать и с Hive’ом).
Спасибо большое за комментарий! Вы правы. Основная задача нашего решения - именно создание итогового протокола в удобном формате с выделением полезных разделов. Предварительное заполнение протокола существенно облегчает работу секретаря или ответственного, даже если не все выводы и поручения были распознаны автоматически.
Касательно распознавания полного текста совещания - это для нашего продукта исходный материал. В то же время, стенограммы часто востребованы для уточнения деталей, и наличие стенограммы в окне подготовки протокола с возможностью копирования части текста и последующего редактирования выделяется пользователями как одна из полезных фич.
Спасибо за уточнение! Здесь я неосознанно для удобства подменил понятия. Под "криптопровайдером" я имел в виду организацию-провайдера услуг по криптографической защите (по аналогии с Интернет-провайдером как организацией). Так что, конечно же, вы правы, сертификаты выдаются УЦ, но у большинства компаний, предоставляющих услуги криптографии, есть свой собственный аккредитованный УЦ.
Касательно УКЭП я рассматривал не схожесть или различия технологий электронных подписей, а требования к их применению. По моим наблюдениям в России этому уделяют гораздо больше внимания в рассматриваемых в статье процессах.
Ваш комментарий по алгоритмам шифрования тоже справедлив, но в контексте выбора программных продуктов стоит учитывать, что не все из них поддерживают ГОСТ-ы, что может быть важным фактором при выборе конкретного решения для компании.
Мы использовали: 3i VOX, AI Secretary, Microsoft Azure, Nanosemantics, Speech Drive, Tinkoff, Yandex. Возможно, в одной из следующих статей добавим их сравнение :)
Спасибо! На самом деле подобные решения без голосового помощника уже существуют, как среди научных работ (их обзор можно увидеть в разделе 3.1 данной статьи), так и среди готовых продуктов (deepTalk, Otter.ai, Marsview Notes). Проблема в том, что все они направлены на английский язык.
Из основного в свете импортозамещения: Брест есть в реестре.))))) + применение средств защиты Astra Linux Special Edition
А если вдаваться в подробности – то можно надолго уйти в холивар «OpenNebula vs Proxmox vs oVirt vs OpenStack»
Краткая выжимка из холиваров: Proxmox неплох для небольшого количества хостов (хотя хватает тех, кто считает его сырым и глючным), OpenNebula – уже для более серьезного подхода, при этом пряморукие красноглазики нужны и там, и там.
В этой статье обсуждается вопрос подхода к импортозамещению системы виртуализации и на что следует обращать внимание при планировании, а не фундаментальные вопросы, насколько операционные системы из реестра отечественные. Об этом было сказано уже очень много)
Эта статья несет ознакомительный характер для РП и обращает внимание на важность ИБ при проектировании и внедрении любых АС. В данном контексте мы не стали детально расписывать все требования по ИБ, очень обширная тема, а сослались на общую формулировку «законодательством РФ в области ИБ» и расписали частные ситуации из нашей практики.
Для небольшого сайта, наверно, недешево получится. Выше писала «вилку» (лицензия на платформу Sitefinity для домена стоит от 1 до 3,7 млн руб.), но там много вариантов, дополнений, наценок за доп. сайты и проч.
Добрый день!
1) На текущий момент разработаны специализированные коннекторы к Active Directory и FreeIPA, а также универсальный коннектор, представляющий собой стандартизированный API. В зависимости от конкретной задачи и особенностей структуры интегрируемых систем в среде заказчика, может потребоваться доработка существующих коннекторов.
Срок разработки нового коннектора в составе существующего набора функциональности зависит от особенностей системы, для которой разрабатывается коннектор, и составляет от 3 месяцев.
2) В настоящее время управление правами доступа осуществляется в рамках ИС и АРМ, управление правами на локальном рабочем месте пользователя не предусмотрено.
Есть отдельная интеграция с SCCM, которая позволяет управлять ПК в рамках возможностей SCCM.
3) Предусмотрен автоматизированный аудит, выполняющий выгрузку прав доступа из интегрируемой системы с использованием коннектора и сопоставление с согласованными правами доступа. В результате система предоставляет аудитору отчет с расхождениями, в том числе в случае выдачи прав в обход IDM. В системе предусмотрено несколько видов аудитов, в том числе с автоматическим исправлением выявленных нарушений. По факту формирования результатов аудита реализован механизм оповещения ответственных лиц.
Направляю ниже несколько примеров абстрактивной суммаризации.
Стенограмма и сформированное авторезюме по абстрактивному принципу:
Отдельный пример абстрактивной суммаризации:
Да, тут я ошибся. Прошу прощения. Неправильно посмотрел версию Qt в «Авроре». Там сейчас 5.6.3, эту же версию мы использовали
Мы заранее продумали UI и практически не использовали компоненты из Sailfish Silica (использовали в основном стандартный qt quick). Поэтому адаптировать qml-код практически не нужно будет. Только избавиться от компонентов Page и SilicaListView.
А про версию мы в курсе, в планах для Android не использовать в принципе Аврора SDK, а использовать чистый Qt. Получается, для сборки будут использоваться два разных SDK: для "Авроры" — "Aurora SDK", для Android — "Qt 6 SDK". Пока это только все в планах, так что точно не можем сказать, какие трудности могут возникнуть.
В данном случае мы использовали версию Qt 5.15.7, т.к. на ней основана Aurora IDE. В дальнейшем будем использовать более новые версии Qt, вероятнее всего 6.5, т.к. планируем выпускать приложение и под Android
Причина, по которой мы создаем `.sql` файл — желание отделить определение схемы БД от логики работы с ней. Этот файл мы складываем в ассеты, просто чтобы использовать его в самом приложении. Альтернативой (на мой взгляд) является прописывание всей структуры БД в виде строки внутри кода, что не совсем удобно лично для меня. Однако если вы считайте этот подход неправильным, то прошу вас поделиться вашим опытом и идеями на эту тему.
Мы стараемся подбирать хранилище данных так, чтобы оно было оптимальным для конкретной задачи. Так уж вышло, что многие приложения, которые мы разрабатываем, рассчитаны на работу в офлайн-режиме с периодической синхронизацией с главной БД. Поэтому приложение зачастую хранит и обрабатывает большое количество записей, что делает использование SQLite удобным. В дальнейшем планируем поработать и с Hive’ом).
Спасибо большое за комментарий! Вы правы. Основная задача нашего решения - именно создание итогового протокола в удобном формате с выделением полезных разделов. Предварительное заполнение протокола существенно облегчает работу секретаря или ответственного, даже если не все выводы и поручения были распознаны автоматически.
Касательно распознавания полного текста совещания - это для нашего продукта исходный материал. В то же время, стенограммы часто востребованы для уточнения деталей, и наличие стенограммы в окне подготовки протокола с возможностью копирования части текста и последующего редактирования выделяется пользователями как одна из полезных фич.
Спасибо за уточнение! Здесь я неосознанно для удобства подменил понятия. Под "криптопровайдером" я имел в виду организацию-провайдера услуг по криптографической защите (по аналогии с Интернет-провайдером как организацией). Так что, конечно же, вы правы, сертификаты выдаются УЦ, но у большинства компаний, предоставляющих услуги криптографии, есть свой собственный аккредитованный УЦ.
Касательно УКЭП я рассматривал не схожесть или различия технологий электронных подписей, а требования к их применению. По моим наблюдениям в России этому уделяют гораздо больше внимания в рассматриваемых в статье процессах.
Ваш комментарий по алгоритмам шифрования тоже справедлив, но в контексте выбора программных продуктов стоит учитывать, что не все из них поддерживают ГОСТ-ы, что может быть важным фактором при выборе конкретного решения для компании.
И подумать не мог, что случайно попал в мем :) Зато благодаря вашему комментарию узнал о Вавилон-5. Надеюсь, что он не разочарует ;)
Мы умеем работать с Google Cloud Speech, но на данный момент не используем.
Согласен, прошу прощения, у Otter.ai только summary keywords.
Мы использовали: 3i VOX, AI Secretary, Microsoft Azure, Nanosemantics, Speech Drive, Tinkoff, Yandex. Возможно, в одной из следующих статей добавим их сравнение :)
Спасибо! На самом деле подобные решения без голосового помощника уже существуют, как среди научных работ (их обзор можно увидеть в разделе 3.1 данной статьи), так и среди готовых продуктов (deepTalk, Otter.ai, Marsview Notes). Проблема в том, что все они направлены на английский язык.
Веб-сервис с возможностью развертывания как в облаке, так и локально.
Давайте не будем порождать очередной виток холиваров на тему отечественности ОС (да и ПО в целом) из реестра, об этом сказано уже очень много.
(Да и у нас в блоге это уже обсуждалось)
В данной статье мы не рассматриваем, насколько ПО, которое внесено в реестр, отечественное, а на сколько импортное.
И если у вас нет требования переводить вашу инфраструктуру на «отечественное ПО», то и импортозамещаться вам не к чему, статья не о том.
Она о том, на что обратить внимание тем, у кого такое требование есть. И для них, поверьте, вопрос отечественности или импортности – совсем не важен.
Есть реестр ПО – из него они должны использовать.
Из основного в свете импортозамещения: Брест есть в реестре.))))) + применение средств защиты Astra Linux Special Edition
А если вдаваться в подробности – то можно надолго уйти в холивар «OpenNebula vs Proxmox vs oVirt vs OpenStack»
Краткая выжимка из холиваров: Proxmox неплох для небольшого количества хостов (хотя хватает тех, кто считает его сырым и глючным), OpenNebula – уже для более серьезного подхода, при этом пряморукие красноглазики нужны и там, и там.
В этой статье обсуждается вопрос подхода к импортозамещению системы виртуализации и на что следует обращать внимание при планировании, а не фундаментальные вопросы, насколько операционные системы из реестра отечественные. Об этом было сказано уже очень много)