Как ограничить доступ для чтения VOB в ClearCase (Windows Server)?

Question

Меня попросили посмотреть, как ограничить доступ на чтение для определенных VOB в ClearCase, по соображениям соответствия (поэтому это должно быть проверяемым, и т. Д., И т. Д.). Пока я нашел решение, которое я опубликую здесь, но у меня все еще есть вопросы, поэтому любая помощь будет оценена. Тем более, что дьявол кроется в деталях, я думаю.

Для простоты аргументации, скажем, у нас есть 3 VOB и 3 группы:

• gA и gB - две специальные группы, все остальные пользователи CC находятся в gC, которая является группой CC по умолчанию
• VOB vA, доступ на чтение / запись к группе gA, доступ к которому предоставляется только другим
• VOB vB, доступ на чтение / запись к группе gB, доступ на чтение к группе gA и доступ ко всем остальным
• VOB vC, доступ для чтения / записи для всех

неотвеченные вопросы:

• Как влияет наличие разных групп доменов для пользователей CC? Когда люди регистрируются, их группа прозрачных списков выбирается пользовательской переменной CLEARCASE_PRIMARY_GROUP. Если они из gA и работают нормально в vA, эта переменная будет установлена ​​в gA, но если им нужно что-то изменить в vC, держу пари, что групповое владение своими файлами / версиями в vC останется gA, если они ничего не поделать. Объекты в vC в конечном итоге будут принадлежать группе gA, gB, gC. Может ли это быть проблемой?

• Я даже не уверен, что можно правильно настроить ACL на vB без фактического создания новой группы gA ', содержащей людей из gA и gB, я прав?

• Мне кажется, что здесь проблема не техническая, а скорее в том, что в процессе предоставления доступа определенным людям к соответствующим группам, и что команда КМ должна держаться подальше от этого (и оставить это, чтобы быть решено Департаментом безопасности и задействованными группами разработчиков). У кого-нибудь есть опыт в этом вопросе?

• Похоже, что можно использовать ClearCase Regions для достижения того же эффекта. Как это будет работать?

С уважением,

Thomas

Answer 1

Как влияет наличие разных групп доменов для пользователей CC?

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

VOB vB, доступ на чтение / запись к группе gB, доступ на чтение к группе gA и только для всех

gB является частью вторичной группы vB, gA - нет (означает, что проверка невозможна).
770 для группы system , включающей gA и gB (имеется в виду доступ для чтения для gA, чтение / запись для gB, отказ для gC)

только для чтения или для чтения / записи подразумевает защиту, установленную с помощью clearcase ("cleartool protect" или "cleartool protectvob"), но "нет доступа" может быть достигнуто только на уровне system (chmod 770) * * тысяча двадцать-один

Регионы ClearCase не имеют ничего общего с ограничением данных, только видимость данных: он позволяет вам видеть только подмножество вобов или представлений, он не мешает вам получить к ним доступ (простой mktag -vob, и вы увидите, что " конфиденциально "vob в любом случае)

Мне кажется, что здесь проблема не техническая, а скорее в том, что в процессе предоставления доступа определенным людям к соответствующим группам, и что команда КМ должна держаться подальше от этого (и оставить это на усмотрение Департамент безопасности и команды разработчиков участвуют).

Вздох ... КМ должен остаться в стороне, но команда КМ не всегда может остаться в стороне;) Эта команда должна по крайней мере инициализировать запрос, чтобы системная команда зарегистрировала пользователя в правильной группе. Один только этот шаг инициализации является довольно сложным, по сравнению с VCS, которая имеет свою собственную систему управления группами. Но ClearCase еще нет.

Answer 2

Пока я нашел этот ответ на форумах IBM developerworks :

(отредактированный)

1. Создать две дополнительные группы доменов для команд

2. Добавьте соответствующую новую группу домена в каждый профиль группы пользователей ClearCase (в дополнение к членству в группе gC, которое у них уже есть). Вам нужно, чтобы учетная запись vobadmin была членом обеих этих новых групп.

3. Измените групповое владение VOB соответственно:
   cleartool protectvob -chgrp group_name <\\..vob.vbs>
   ГА для ВА
   ГБ для ВБ
   gC для всех остальных VOB (это уже должно быть)

4. Удалите разрешения «другие группы» из корневого элемента VA и VB VOB: cleartool protect -chmod 770 <vob-tag-name>
   Вы также можете сделать это с помощью CC Explorer: щелкните правой кнопкой мыши на VOB в любой вид и выберите «Свойства элемента». Там нет необходимости повторно защитить весь VOB ( Примечание: это важно для меня, потому что восстановление всего VOB занимает много времени, и у меня здесь более 200 VOB).

Теперь только члены группы GA будут иметь доступ к VOB VOB.
Только члены группы gB будут иметь доступ к vB VOB.
Все являются членами группы gC, поэтому каждый будет иметь доступ ко всем другие VOB.

Обратите внимание, что вы захотите установить среду CLEARCASE_PRIMARY_GROUP переменная для конкретного пользователя, если вы хотите, чтобы вновь созданные объекты этим пользователь, принадлежащий группе, отличной от основной группы этой учетной записи как это установлено в контроллере домена.