Come limitare l'accesso in lettura VOB in ClearCase (Windows Server)?

Question

Mi è stato chiesto di guardare a come limitare l'accesso in lettura su alcuni VOB in ClearCase, per motivi di conformità (quindi questo deve essere verificabile, ecc, ecc ...). Ho trovato una soluzione fino ad ora, che posterò qui, ma ho ancora domande, in modo che qualsiasi aiuto sarebbe apprezzato. Tanto più che il diavolo è nei dettagli, credo.

Per facilitare la discussione, diciamo abbiamo 3 VOB, e 3 gruppi:

• GA e GB sono due gruppo speciale, tutti gli altri utenti CC sono in gC, che è il gruppo predefinito CC
• VOB vA, è l'accesso in lettura / scrittura al gruppo Ga, e limitato a tutti gli altri
• VOB BB, è l'accesso in lettura / scrittura al gruppo gB, l'accesso in lettura al gruppo Ga, e limitato a tutti gli altri
• VOB vC, è di lettura / scrittura di accesso a tutti

domande Unaswered:

• Qual è l'impatto di avere diversi gruppi di dominio per gli utenti CC? Quando la gente log, il loro gruppo ClearCase è raccolto-up dalla CLEARCASE_PRIMARY_GROUP variabile utente. Se sono da GA e stanno lavorando normalmente in vA, questa variabile sarà impostata fino a NY, ma se hanno bisogno di cambiare qualcosa in VC, scommetto che il gruppo proprietario dei loro file / versioni in VC rimarrà gA se don 't fare nulla al riguardo. Oggetti in VC finiranno avente un gruppo-facente gA, gB, gC. Può che essere un problema?

• Non sono nemmeno sicuro che sia possibile impostare ACL correttamente su BB, senza in realtà creare un nuovo gruppo, Ga' contenente la gente sia da GA e GB, ho ragione?

• Mi sembra la difficoltà qui non è tecnico, ma piuttosto che nel processo per dare accesso a certe persone ai gruppi corretti, e che la squadra CM dovrebbe stare lontano da questo (e lasciare che per essere deciso dal Dipartimento di Sicurezza e il team di sviluppo coinvolti). Qualcuno ha qualche esperienza in questa materia?

• Sembra che sia possibile utilizzare ClearCase Regioni per ottenere lo stesso effetto. Come funzionerebbe?

Con i migliori saluti,

Thomas

Answer 1

Finora, ho trovato questa risposta da IBM Forum developerWorks :

(a cura)

  

  

1. Creare due gruppi di dominio aggiuntivo per le squadre

  

2. Aggiungere il nuovo gruppo Domain appropriato per gruppi di ogni utente ClearCase profilo (oltre alla appartenenza di gruppo GC che già hanno).   Vorrete l'account vobadmin di essere un membro di entrambi questi nuovi gruppi.

  

3. Cambia il gruppo proprietario dei file VOB di conseguenza:
     cleartool protectvob -chgrp group_name <\\..vob.vbs>
     GA per vA
     gB per VB
     gC per tutti gli altri file VOB (dovrebbe già essere il caso)

  

4. Rimuovi gli "altri gruppi" autorizzazioni dall'elemento radice di   VA e VB VOB:   cleartool protect -chmod 770 <vob-tag-name>
     È anche possibile farlo utilizzando CC Explorer: tasto destro del mouse sul VOB in   qualsiasi vista e selezionare "Proprietà di Element". Non c'è alcuna necessità di   ri-proteggere l'intero VOB ( Nota: Questo è importante per me, perché reprotecting tutta VOB richiede molto tempo, e ho più di 200 VOBs qui).

  

     

Ora, solo i membri del gruppo gA avranno accesso al vA VOB.
  Solo i membri del gruppo gB avranno accesso al BB VOB.
  Ognuno è un membro del gruppo GC in modo che tutti avranno accesso a tutti   altro VOB.

     

Si noti che si desidera impostare l'ambiente CLEARCASE_PRIMARY_GROUP   variabile per un particolare utente, se si desidera che gli oggetti di recente costituzione a che   all'utente di essere di proprietà di un gruppo diverso da quello di account utente gruppo primario   in quanto si trova nel controller di dominio.

Answer 2

  

Qual è l'impatto di avere diversi gruppi di dominio per gli utenti CC?

Nessuno tranne il costo di gestione (la registrazione tutti gli utenti a molti gruppo può essere ingombrante).
Il fatto di avere vari elemento con diversi gruppi non è un problema in sé.

  

VOB BB, è l'accesso in lettura / scrittura al gruppo gB, l'accesso in lettura al gruppo Ga, e limitata a tutti gli altri

GB è parte del gruppo secondario di BB, GA non è (mezzi possibili senza cassa).
770 per un Sistema di gruppo tra cui GA e GB (Accesso Significato leggere per abb, lettura / scrittura per gB, negato per GC)

sola lettura o lettura / scrittura implica protezioni fissati dal ClearCase ( "cleartool protect" o "cleartool protectvob"), ma "nessun accesso" può essere raggiunto solo sul sistema di livello (chmod 770)

regioni ClearCase non hanno nulla a che fare con la limitazione dei dati, solo la visibilità dei dati: permette di vedere solo un sottoinsieme di VOB o di punti di vista, non impedisce di accedervi (un semplice mktag -vob e si vedrebbe che "confidenziale" Vob in ogni caso)

  

Mi sembra la difficoltà qui non è tecnico, ma piuttosto che nel processo per dare accesso a certe persone ai gruppi corretti, e che la squadra CM dovrebbe stare lontano da questo (e lasciare che per essere deciso dal Dipartimento di Sicurezza e il team di sviluppo coinvolti).

Sigh ... CM dovrebbe stare lontano, ma la squadra CM non può sempre stare lontano;) Che squadra deve almeno inizializzare la richiesta, per la squadra del sistema di registrare l'utente nel gruppo corretto. Quel passo di inizializzazione solo è abbastanza resistenza, rispetto ad un VCS che ha il suo proprio sistema di gestione dei gruppi. Ma ClearCase non c'è ancora.