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

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

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

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

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

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

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

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

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

С наилучшими пожеланиями,

Томас


security acl clearcase
person Thomas Corriol    schedule 08.06.2009    source источник
comment
Кстати, это тот вопрос, который я не был уверен, лучше спросить здесь или на сервере...   -  person Thomas Corriol    schedule 09.06.2009

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

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

person VonC    schedule 08.06.2009
comment
Спасибо VonC. Я буду обсуждать значение инициализации запроса с командами здесь. Я, конечно, не хочу этого делать, потому что нам никогда не сообщают, когда люди меняют команду или покидают компанию, поэтому я не в состоянии управлять этими группами. - person Thomas Corriol; 09.06.2009

arrow_upward
0
arrow_downward

На данный момент я нашел этот ответ на форумах IBM developerworks< /а>:

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

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

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

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

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

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

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

person Thomas Corriol    schedule 08.06.2009