Вся информация, кроме документов, хранится в одной базе данных. Документы хранятся в специальной папке на сервере приложения (C:\SL_Files\Doc_Files). Для обеспечения безопасного доступа рекомендуется создать пользователя в Active Directory, от имени которого будет запускаться пул IIS, и который будет иметь доступ к папке с документами.
Сервер приложения обращается к серверу базы данных, используя специально выделенную Администратором учетную запись на SQL сервере.
Сервер приложения осуществляет проверку прав доступа согласно заданным установкам, прежде чем вернуть данные в ответ на запрос пользователя.
Для входа в Систему пользователь должен указать логин и пароль, который был указан в процессе регистрации в Системе. Логин и пароль для пользователей не должны назначаться сторонними лицами.
Пароль, выбранный пользователем при регистрации, в Системе нигде не хранится (ни в базе данных, ни в файловой системе), а хранится только образ пароля, который используется для аутентификации пользователей.
Алгоритм, создающий образ пароля, не является реверсивным, таким образом, никто не может получить и использовать данные чужой учетной записи.
Администратор может задать срок действия учетных записей пользователей. Это имеет смысл делать для сотрудников, доступ к Системе которым выдается временно на определенный период. Например, только на срок выполнения проекта.
Для пользователей можно настроить срок действия пароля. По истечении этого срока пользователи получат сообщение о необходимости сменить пароль.
Также настраивается число попыток ввода пароля, при превышении которого пользователь будет заблокирован. Список заблокированных пользователей находится в разделе Администрирование → Управление безопасностью → Безопасность.
Рекомендуется формировать в Системе две учетные записи для Администратора:
Для управления доступом пользователям в Системе рекомендуется выделить отдельную пользовательскую учетную запись, которая не будет иметь все права администратора (доступно с версии Системы 3.24 и позднее). Как правило, это важно для крупных компаний, так как часто задачи управления доступом пользователей выполняет сотрудник, который не должен иметь полных прав ко всем данным системы и к изменениям настроек.
Рекомендуется использовать учетную запись с типом «Администратор», только для настройки системы или реализации интеграций, так как для пользователей с таким типом учетной записи отключены проверки на наличие прав доступа и могут нарушаться требования по обеспечению консистентности данных. Также при просмотре данных через интерфейс или при формировании отчетов у пользователя с типом учемной записи «Администратор» отключается проверка прав на объекты иерархического дерева и справочники, что с одной стороны может давать ускорение в получении данных, но с другой - может нарушать соблюдение требований настроенных процессов при изменении данных.
Не рекомендуется работать в системе от имени Администратора при выполнении обычным пользователем процессов организации, не связанных с настройкой параметров системы ADVANTA.
Для предотвращения перехвата информации при ее передаче по сетям общего пользования (например, Интернет) необходимо использовать протокол HTTPS с длиной ключа не менее 128 бит.
В целях безопасности все остальные порты можно блокировать.
Система ADVANTA рассылает уведомления по электронной почте тем пользователям, у которых стоит флаг о разрешении отправки уведомлений. Для предотвращения перехвата информации, содержащейся в уведомлениях, рекомендуется использовать e-mail через SSL и предпринимать меры по защите информации локально на компьютерах пользователей.
Сервер Системы ADVANTA может быть установлен внутри сети компании (например, в локальной сети офиса). При этом пользователи удаленных сетей (локальные сети в офисах других городов) могут совершенно прозрачно обращаться к серверу через VPN (Virtual Private Network) по адресу (IP или имени), указанному Администратором.
Все существующие типы событий по действиям пользователей в конкретном экземпляре Системы расположены на странице https://адрес_приложения/api/businessevents.
Список событий может быть выгружен в json-файл.
Системный протокол - важная часть безопасности Системы.
В системном протоколе отражаются события, которые:
Список отображаемых действий пользователей:
Список можно отфильтровать:
Системный протокол располагается в Системе по следующему пути: Администрирование → Управление безопасностью → Системный протокол.
События системного протокола можно выгрузить в *.xls.
Подробнее — по ссылке.
Лог авторизаций в Системе доступен по следующему пути: Администрирование → Управление безопасностью → Безопасность, портлет «Лог авторизаций».
В этот лог записываются следующие данные:
Также в Системе записываются неудачные попытки авторизации.
Вы можете посмотреть, к каким объектам Системы у конкретного пользователя есть доступ.
Отчет доступен только Администратору.
Отчет можно выгрузить в MS Excel.
Права пользователя располагаются в Системе по следующему пути: зайдите на карточку пользователя → меню три точки → «Права пользователя».
Подробнее - по ссылке.
Вы можете увидеть, у каких пользователей какие права есть по конкретным объектам Системы, в отчете по правам объекта.
Отчет возможно просмотреть в разрезе операций прав доступа для проектных и системных ролей и отдельно в разрезе каждой роли получить список пользователей в привязке к иерархической структуре проекта.
Отчет по правам конкретного объекта располагается в Системе по следующему пути: зайдите в объект, доступ к которому вы хотите проверить → меню “три точки” → «Права доступа» → в портлете «Роли безопасности проекта» → «отчёт по правам».
Подробнее - по ссылке.
В Системе можно просматривать события электронной почты в разделе Администрирование → Управление безопасностью → Электронная почта. В этом разделе возможно посмотреть системные сообщения электронной почты.
Доступно следующее отображение сообщений:
Также доступная фильтрация сообщений по количеству отображаемых сообщений и выбор временного периода и количества для отображения сообщений на странице.
В портлете «Ошибки при отправке сообщений» также доступна фильтрация по временному периоду и пользователям. Фильтрация становится доступна при появлении соответствующих событий.
В части управления бэкапами необходимо настроить регулярные автоматические бэкапы Системы. Кроме того, необходимо с определенной частотой дублировать бэкапы на другом физическом носителе (сервере).
Для того чтобы сделать резервную копию Системы на определенный момент времени, нужно создать резервные копии:
streamline (подробнее см. справка Microsoft, подраздел «Как создать резервную копию базы данных (среда SQL Server Management Studio)», ссылка на статью).<constructor>, имя параметра documentsFolder, в файле client.config, расположенном в папке веб-контента Системы).C:\Inetpub\wwwroot\streamline, например, на внешний носитель и или сетевой каталог для хранения резервных копий).В части управления обновлениями и настройками рекомендуется иметь тестовый контур, на котором будет производиться проверка предполагаемых изменений настроек, а также делать внутреннее тестирование получаемых обновлений. Это актуально для систем с большим числом пользователей, сложными настройками, а также в случаях, если остановка Системы даже на короткий период имеет критическое значение.