Безопасность Kablink.

Безопасность Kablink - права доступа и защита данных по https протоколу.

1. Права доступа.

  Администратор Kablink, должен понимать как настраивать права пользователей в рабочих областях и папках. Вопросы безопасности Портала тесно связанны с правами доступа и носят немного запутанный характер, в этой публикации попробуем разобраться в этом вопросе, но прежде договоримся о терминологии сокращений:

 Область -Домашняя рабочая область, Глобальная рабочая область, Персональная рабочая область, Рабочая область коллектива.

 По умолчанию - означает , что все настройки рассматриваются в «коробочном» варианте, все роли и права остаются, как после первой установки Kablink,

 * (наследование снято) — означает, что нет наследования от родителя.

 Роль - набор правил.

 Гость — пользователь с минимальными правами доступа, только просмотр.

Kablink представляет собой иерархию рабочих областей и папок с наследуемыми параметрами контроля доступа от родительских областей и папок. Безопасность Kablink, основана на управления ролями доступа, по умолчанию, существует двенадцать ролей для рабочих областей и папок и пять ролей для записей. Если нужно, чтобы конкретный пользователь имел определенные права, то ему необходимо присвоить соответствующую роль. Например, пользователь с ролью участник-гость в рабочей области или папке, владеет следующими правами: добавлять комментарии и ответы, создавать записи, читать записи.

Рабочие области и папки могут наследовать настройки контроля доступа от своих родительских областей или папок. При изменении прав в корневой области или папке, изменения произойдут и для наследуемых областей и папок. При перемещение рабочей области или папки, наследуются параметры контроля доступа новой родительской области. Если новая родительская рабочая область или папка имеет настройки иные, чем в исходной, параметры контроля доступа перемещаемой области или папки изменится. Надо отметить, что существуют ограничения при наследовании некоторых областей — область члены коллектива не могут наследоваться по умолчанию, но об этом поговорим ниже.

Теперь перейдём к описанию встроенных, по умолчанию, пользователей, групп и ролях, которые связанны с ними.

1.1 Встроенные пользователи.

Kablink, по умолчанию, имеет двух пользователей и роли связанные с ними, помимо них имеются и другие, но они относятся скорее к службам Портала. Отметим, что владелец рабочей области или папки и участники коллектива это как бы одно лицо, но тем ни менее имеется некоторая двойственность, которая позволяет разделять их. Эту парочку мы будем встречать везде т.к парадигма коллектива является сутью работы Kablink.

Таблица №1

Пользователь.

Роль.

Владелец рабочей области или папки. Администратор рабочей области и папки.
Участники коллектива. Участники коллектива.

1.2 Встроенные группы.

Kablink имеет по умолчанию четыре группы пользователей:

Таблица №2

Заголовок группы \ Имя группы

Роль.

Admin \ administrator Администратор рабочей области и папки.
All \ all Все пользователи Портала.
Все внешние Группа "Все внешние пользователи" содержит список всех внешних пользователей.
Все внутренние пользователи \ allusers Группа "Все пользователи" содержит список всех зарегистрированных пользователей, кроме учетной записи "Гость".

1.3 Встроенные Роли для рабочих областей и папок.

В Kablink встроены четыре рабочие области, где можно создавать папки с наследуемыми правами. Корневой областью является Домашняя в неё входит: глобальная, персональная и область коллективов. В таблице указанны все роли которые можно добавлять для управления доступом в областях, * указаны роли, по умолчанию, установленные в Домашней области, которые наследуются всеми областями и папками по умолчанию.

Таблица №3

Роль.

Права.

*Администратор рабочей области и папки Создавать, изменять, удалять рабочие области\папки
Посетитель. Читать ,добавлять комментарии.
Просмотр заголовка средства привязки. Просмотр заголовка средства привязки.
Разрешить общедоступное совместное использование. Разрешить общедоступное совместное использование
Разрешить передачу прав на предоставление совместного доступа. Разрешить передачу прав на предоставление совместного доступа.
Разрешить предоставлять общий доступ к ссылкам на файлы. Совместное использование файловых ссылки
Разрешить совместное использование для внешних пользователей. Разделять рабочие области и папки с внешними пользователями.
Разрешить совместное использование для внутренних пользователей. Разделять рабочие области и папки с внутренними пользователями.
Создатель рабочей области. Добавление рабочих областей.
*Участник коллектива. Добавить комментарии или ответы, загрузить папку как CSV-файл, Изменить, переименовать, удалить собственные записи. Создание отчетов и записей. Управление глобальными тегами. Чтение записей. Элементы управления доступом на уровне записи создает владелец.
Участник-гость. Добавить комментарии или ответы. Создать записи. Чтение записей.
Участник. Добавить комментарии или ответы, загрузить папку как CSV-файл, Изменить, переименовать, удалить собственные записи. Создание отчетов и записей. Управление глобальными тегами. Чтение записей. Элементы управления доступом на уровне записи создает владелец.

1.4 Встроенные Роли для записей.

Под записью в Kablink будем понимать — всякого рода публикации, контент, фото, видео, файлы прикреплений, в общем всё, что может находится в папке:

Таблица №4

Роль

Права

Записать Добавить комментарии или ответы, изменять и переименовывать записи, Создание отчетов, Управление глобальными тегами,Чтение записей
Изменить права доступа Добавить комментарии или ответы, Изменение записей, Изменение прав доступа, Переименовать записи, Создание отчетов, Удаление записей, Управление глобальными тегами, Чтение записей.
Прочитать и ответить Добавить комментарии или ответы, Чтение записей.
Прочитать Чтение записей.
Удалить. Добавить комментарии или ответы, изменять и переименовывать записи, Создание отчетов, Удаление записей, Управление глобальными тегами, Чтение записей.

2.Домашняя рабочая область (корень).

Выше упоминалась, что Домашняя рабочая область - корень для областей и папок. Установленные в ней, по умолчанию, роли и права наследуются без исключения всеми областями и папками Портала.

Таблица №5

Пользователь\Группа

Роль.

Владелец рабочей области или папки. Администратор рабочей области и папки.
Участники коллектива. Участники коллектива.
Группа admin (administrator) Администратор рабочей области и папки.
Группа Все внутренние пользователи (allusers) Посетитель, Участник.
Гость. (по умолчанию выключен) Посетитель.

2.1 Персональные рабочие области.

Когда создаётся новый пользователь, для него отводится персональное пространство(область) с папками. Внутри области наследование снято * и это правильно т.к он, пользователь, является администратор рабочей области и папок и сам в праве управлять своей областью.

Таблица №6

Имя пользователя. Роль.
Владелец рабочей области или папки Разрешить совместное использование для внутренних пользователей, Разрешить совместное использование для внешних пользователей, Разрешить передачу прав на предоставление совместного доступа, Разрешить общедоступное совместное использование, Разрешить предоставлять общий доступ к ссылкам на файлы, Посетитель, Участник, Участник коллектива, Администратор рабочей области и папки
Участники коллектива. Посетитель, Участник, Участник коллектива, Администратор рабочей области и папки

2.Защита Kablink по https протоколу.

Установка сертификата.

Рассмотрим последовательность действий, для включения дополнительной защиты по HTTPS протоколу, если это требуется политикой предприятия, отметим при этом, что ключи сертификата подлинности бывают: самоподписанными, подписанный центром сертификации (СA) вашей организации, подписанный коммерческим центром (СА) на определённый срок и за определённую плату.

Администратор Портала должен выполнить:

- создать (генерировать) сертификат подлинности

- на основе созданного сертификата подлинности, создать и отправит запрос в виде .csr файла в СА центр

- после получения ответа из СА, импортировать полученные ключи в созданный ранние сертификат подлинности

- импортировать подписанный сертификат подлинности в хранилище Портала

- перегрузит Портал

В java сертификат подлинности называется .keystore, точка указывает на скрытый характер этого файла, хранится он в каталоге /opt/novell/teaming/apache-tomcat/conf, путь для хранения файла .keystore и пароль доступа к нему при операции импорта, указан в /opt/novell/teaming/apache-tomca/con/server.xml файле,значения можно менять, но лучше этого не делать.

Наша задача состоит в том, что бы полученный тем или иным способом файл сертификата подлинности, импортировать в хранилище и сделать это надо аккуратно и правильно иначе порт 8443 просто не «заведётся».

По умолчанию, при первой установке, создаётся сертификат с непонятным сроком действия и сомнительной подписью, этот сертификат необходимо заменить на постоянный и доверенный, к примеру с годовым сроком доверия подлинности.

Для этого можно использовать:

- сертификат выданный коммерческим центром сертификации СА, при этом браузеры пользователей будут автоматически принимать их при некоторой задержке в ожидании подтверждения от СА

- сертификат подписанный СА вашего предприятия и собственный

- самоподписанный, пользователи будут получать предупреждения при первом соединении с требованием «ручного» подтверждения подлинности при открытии ssl соединения c Порталом в браузере.

Для создания сертификата и его импорта в хранилище существует утилита keytool,располагается она, по умолчанию, в установленном комплекте jdk вкаталогеbin.

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

2.1.Подготовка:

Добавляем временную переменную пути к keytool:

export PATH=$PATH:/usr/java/jdk1.8.0_xx/bin/

Создаём временный каталог:

mkdir /home/mms/sert

cd /home/sert

1.1 Создаём ключ в каталоге /home/sert:

Действие Пояснения
keytool -genkey -alias tomcat -keyalg RSA -keystore .keystore Запускаем сценарий создания ключа сертификата, срок не определён
Enter keystore password: changeit Пароль по умолчанию
Re-enter new password: changeit Подтверждение пароля
What is your first and last name? Имя домена
[ Unknown]: moyportal.ru   
What is the name of your organizational unit? Имя подразделения организации
[Unknown]: smal  
What is the name of your organization? Имя организации
[Unknown]: big  
What is the name of your City or Locality? Город
[Unknown]: Moscow  
What is the two-letter country code for this unit? Страна
Unknown]: RU  
Is CN=moyportal.ru, OU=smal, O=big, L=Moscow, ST=Moscow, C=RU correct Проверить данные
[no]: yes Если правильно\неправильно
Enter key password for <tomcat> Пароль для контейнера tomcat
(RETURN if same as keystore password): changeit  
Re-enter new password: changeit Подтвердить пароль

2. Генерация запроса на подпись CSR - текстовый файл, содержащий в закодированном виде информацию о Портале, вложенный в открытый ключ:

keytool -certreq -alias tomcat -keyalg RSA -file certreq.csr -keystore .keystore  //в /home/sert должен находиться созданный ключ .keystore

3.Импорт полученного отпечатка подписииз центра CA, псевдоним root,в .keystore

keytool -import -alias root -trustcacerts -keyalg RSA -keystore .keystore -file CertificateAuthorityCert.der

3.1 Импорт полученного отпечатка подписи из центра CA,псевдоним tomcat, в .keystore

keytool -import -alias tomcat -keyalg RSA -keystore .keystore -file certificate_name.cer

4. Импорт подписанного центром СА сертификат подлинности в хранилище Kablink

4.1 mv /opt/novell/teaming/apache-tomcat/conf/.keystore keystorebk        //переименовываем старый ключ

4.2 cp /home/sert/.keystore /opt/novell/teaming/apache-tomcat/conf/        //копируем новый ключ

4.3 ls -al /opt/novell/teaming/apache-tomcat/conf/                                       // проверяем

4.4 .keystore 750                                                                                                  //права

4.5 /etc/init.d/teaming restart                                                                        // перегружаем Портал

4.6 https://moyportal.ru:8443                                             //проверка

Использования СА ALT Linux.

5. Открываем ЦУС >[Система]>[Удостоверяющий центр УЦ].

5.1 Выполняем действия пункта 1и2, переходим в УЦ, выполняем:
[Система]>[Удостоверяющий Центр]>[Загрузить запрос]>[Подписать] на выходе отгружается файл output.pem
[
Система]>[Удостоверяющий Центр]>[Управление УЦ] отгружаем корневой сертификат ca-root.pem
СПРАВКА
: расширение pem - Privacy Enhanced Mail Certificate

Теперь можно импортировать отпечатки созданные УЦ ЦУС в сертификат подлинности .keystore:

keytool -import -alias root -keyalg RSA -keystore .keystore -file ca-root.pem //псевдоним root
keytool -import -alias tomcat -keyalg RSA -keystore .keystore -file output.pem //
псевдоним tomcat
выполняем пункты 3 и 3.1

ВАЖНО:
УЦ Alt Linux должен быть встроен в цепочку СА вашей организации.

Использование СА Microsoft Active Directory.

6. Выполняем действия пункта 1 и 2, нам надо получить сертификат для экспорта в хранилище AD, это можно сделать используя браузер например IE. В адресной строке вводим название Портала, https://moyportal.ru, читаем и игнорируем предупреждение, производим импорт ключа в хранилище сертификатов рабочей станции Windows.

6.1 В браузере IE открываем: Сервис>[Свойство обозревателя]>[Содержание]>[Сертификаты]> производим импорт ключа Портала в файл с расширением, portal.der или portal.p7b

6.2 Отправляем сертификат Портала, portal.der/portal.p7b, в контейнер корневого центра сертификации предприятия, находится на DC Active Directory, в папки «Промежуточный центр сертификации» и «Доверенные корневые центры сертификации».

Через некоторое время у пользователей в хранилищах сертификатов рабочих станций, появятся сертификаты Портала распространяемые по групповой политике AD - ручная команда для обновления групповой политики GPUpdate.exe.

ВАЖНО: URL Портала должен быть определён в политике доверенных адресов корневого центра сертификации AD.

Более подробную информацию можно получить на Kablink Документы.