Git repository titkosítása

 ( nevergone | 2010. november 22., hétfő - 12:52 )

Sziasztok!

Bár az eddigi kutakodásom nem vezetett semmi jóra, de azért felvetem a kérdést, hátha tudtok segíteni.
Adott egy szerver GNU/Linux operációs rendszerrel, a rendszert egy külső, megbízott rendszergazda tartja karban. A szervert nem használnánk másra, mint a munkában használt céges Git repository-kat tartanánk rajta. Az a kérés, hogy ezeket a repository-kat ne tudja elérni a rendszergazda, ne tudjon róluk másolatot készíteni, teljesen védve legyenek tőle. A rendszergazda ismeri a Git-et, tudja, hogy miről van szó, ezek pedig belső használatra szánt programkódok.
Első gondolatom valamilyen file-rendszer titkosítás volt, akár loopback eszközön, de ez nem old meg semmit, hiszen a repository eléréséhez mindenképpen fel kellene mountolni. Valahogy azt kellene megoldani, hogy a Git szerver titkosítsa az anyagot. A szerverhez van távoli ssh elérés (a repository-k eléréséhez is ezt használnánk) és rendelkezem rendszergazdai jogosultsággal.

Van valami ötletetek a megoldásra?

Szerk.: Az kimaradt, hogy a szerver virtualizált, a rendszergazda eléri a mögötte található host-ot is, szóval végső soron azt is meg tudja tenni, hogy "lemásolja" az egész szervert.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem hiszem, hogy ilyet lehetne gittel. Viszont azt esetleg meg lehet csinalni, bar nagyon ronda, hogy:

* Csinalsz egy titkositott loopback filerendszert, amit a szerveren NEM mountolsz fel.
* Ezt a filerendszer filet valami modon megosztod (nfs, vagy sshfs, vagy valami egyeb fuses moka), es felmountolod a ceges rendszeren
* Oda lehet tenni git repokat

Tehat lenne egy gitrepo.fs file az untrusted szerveren, amit lokalis gepen sshfs-el elersz, loopback felmountolod, igy a ti oldalatokon jon letre a kititkositas, nem a szerveren, kovetkezeskeppen az ottani rendszergazda nem latja a titkositatlan dolgokat.

Ez igy bun lassu lesz, de a celnak tulajdonkepp megfelelhet.

Ez a megoldás akár jó is lehet, viszont zárolási gondot okozhat, illetve nem támogatja a jogosultság-kezelést.
Mindenesetre kösz az ötletet! :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

aggass ra meg egy gitosis-t, es a jogosultsag-kezeles kb megoldva. (lokalis szerveren felmount, gitosis oda dolgozik, fejlesztok meg gitosison at commitolnak)

Szerintem azért lehetetlen ezt megcsinálni, mert a git fájlon belül sor szintű öseszehasonlításokat végez, úgy tárolja a diffeket. Ha az állományok titkosítottak lennének, akkor hogy lehetne diffet tárolni?

Hacsak nem lehet egy teljes virtuális gépet titkosítani...

Meg lehet úgy is oldani, hogy a rendszergazda nem kap fizikai hozzáférést, illetve teljes root jogkört. Ezzel "csak" annyi a probléma, hogy akkor várhatóan nem tudja ellátni a feladatát.

Amúgy meg az egész problémakör DRM-re hajaz, amit - mint tudjuk - csipekbe épített védelem nélkül lehetetlen megvalósítani.

Magamnak válaszolva:
(write only vagyok, ez ugyanaz, mint algernon válasza...)
A git szerver oldali repo talán működtethető úgy is, hogy fájl szinten van megosztva, és a userek push-jait az ő lokális gépük oldja meg.

Tehát a szerverre elég egy titkosított fájlrendszert tenni - erre szerintem könnyen található megoldás.

Viszont ebben az esetben kézzel meg kell oldani, hogy a távoli fájlrendszert lokkolja a git felhasználó ameddig műveletet végez rajta. Plusz ez is lassú lesz.

Én inkább bérelnék egy másik szervert, aminek egy belső ember az adminja. Egy gitosis-t adminisztrálni nem nagy erőfeszítés.

Csatlakozom az előttem szólóhoz, dobjatok fel egy lokális szerverre egy GIT-et, és használjátok azt. Mivel belső szerver, ezért a karbantartással nem sokat kell foglalkozni.

Igen, mi is gitosis-t tervezünk használni, viszont azt elérhetővé kell tenni külső hozzáféréshez is. Természetesen ha ez a védelem nem megoldható, akkor hagyjuk a fenébe, viszont ha sikerülne ezt a titkosítást megoldani, azzal eléggé előbbre lennénk. :)
Egyelőre még én is ötletelek.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

És ezzel hogyan? Mert a leírás alapján nem tiszta nekem. Tudnál egy példát mutatni?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

It turns out that you can write your own filters for doing substitutions in files on commit/checkout. These are the “clean” and “smudge” filters. In the .gitattributes file, you can set a filter for particular paths and then set up scripts that will process files just before they’re checked out (“smudge”, see Figure 7-2) and just before they’re committed (“clean”, see Figure 7-3).

nem pont erre találták ki, de akár itt is jó lehet. a lényeg, hogy lokálban lehet matatni checkout/commit előtt. csak szépen át kell nyomni valami titkosításos dolgon a forrásokat ennek a segítségével. egy próbát szerintem megér.

példát nem tudok, mert még sosem csináltam, bocs. csak beugrott, hogy olvastam ilyenről.

Köszi, egy lehetséges megoldásnak tűnik, nem is rossz, igyekszem tesztelni és leírni a tapasztalatokat! :)
A hatékonyság-romlás annyira nem gond, mert relatíve kevés fejlesztőről lenne szó.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Szerintem ezt nem lehet megoldani jelentős biztonsági és (vagy?) használhatóságot érintő hátrányok nélkül.
De most nem érek rá kifejteni, hogy miért (;

Pedig érdekelne, megvárom. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

kivéve esetleg az algernon-féle titkosított-exportált loopback-et.

első blikkre nekem ez a smudge filter megoldásnak tűnik a konkrét problémára. és a hazsnálhatóságot sem csökkenti, mert automatikusan működik ;)

Igen, első körben ez nekem is bejön, bár nyilvánosak lesznek a címkékhez írt megjegyzések, és minden más, ami nem fájl. De eddig ez tűnik a legjobb alternatívának.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

A commit messaget is lehet pgp-vel titkositani. Igy max a branchek meg tagek lesznek "publikusak". Es bar azokat is lehet kodolni, az azert erosen csokkenti a hasznalhatosagot.

Szvsz, az altalam javasolt megoldas a legkenyelmesebb. Picit talan lassu, de nem bassza szet a repot.

Az a megoldás is eléggé favágós, különösen ha arra aggatunk lokálisan egy gitosis-t, szóval nem tudom még elsőre, hogy melyik a rosszabb. Szerencsére annyira rohanni nem kell, mindegyiket igyekszem kipróbálni.
Köszönöm a segítséged, elsőre ez sem elvetendőbb ötlet.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Amennyire en latom, a ket megoldas osszehasonlitva kb igy nez ki:

exported encrypted fs:
======================
+ nem tul nehez osszeloni
+ a git repo teljesen ugy nez ki, mintha egy trusted rendszeren lenne, nem kell mindenfele trukkokkel rejtegetni, mert az fs megteszi azt
+ gitosis elintezi a jogosultsagokat
- relative lassu
- picit gany

A lassusagon lehet segiteni, ha csinaltok egy olyat, hogy van egy lokalis (avagy cegen beluli, nem az egyes fejlesztok clonejaira gondolok itt) repo, amibe mindenki pushol, es valamilyen modon (cronbol, post-commit hookbol, akarmi) ez pusholodik fel az encrypted fs-es repoba. Igy a belso fejlesztesnel nincs gond lockinggal, a sebesseg is teljesen jo, es a tavoli szerverre mar titkositva er el.

Nagy elonye a masik megoldassal szemben, hogy maga a repo nem titkositott, igy cloneozasnal nem kell azzal szivni, hogy visszafejtsd, az egyes fejlesztoknek ezzel nincs semmi dolga, az fs megteszi helyettuk.

smudge:
=======
+ ezt sem tul nehez osszeloni
+ gyors
+ gitosis ugyanugy tudja intezni a jogosultsagokat
- a repo maga gany lesz
- a smudge filtert minden fejlesztonek be kell allitania

Ez a megoldas gyorsabb mukodest eredmenyez (de mint fentebb irtam, orvosolhato az encrypted fs sebessege is), viszont mig abban az esetben egyszer, egy helyen kell beloni a titkositast mindket iranyba, addig smudge eseten minden fejlesztonel ezt meg kell csinalni. (felteve, hogy jol olvastam a doksit)

Az en olvasatomban szimpatikusabb az fs, mert lehet, hogy picit tobb melo osszeloni ugy, hogy megfelelo sebessegu legyen, szerintem sokkal kevesbe gany (es megbizhatobb is, szvsz. Azert egy titkosito smudgeot osszehozni annyira nem trivialis imo)

fixme (utoljára fél éve regéltek a balabitesek az árakról), de mintha nem egy itthoni kisvállalkozásra lenne belőve az scb.

Bar az SCB egy jo dolog, nem igazan latom, hogy itt hogy segithetne (azon kivul, hogy lehet vele monitorozni az untrusted rendszergazdat, ami nem sokat er, ha az a cel, hogy ne lassa a git repot). Meg ha lenne is benne git proxy, sajnos az sem lenne megoldas ebben az esetben.

Ennek ellenere melegen ajanlanam az SCB-t, mert mas celra kifejezetten hasznos tud lenni, foleg ha az ember picit sem bizik a masik rendszergazdaban ;)

Nem értem, a problémát. Adott egy szerver, amely egyetlen szolgáltatást nyújt és ehhez adott egy rendszergazda, akinek az a feladata, hogy üzemeltesse a szervert, biztosítsa a szolgáltatást - de magukhoz az adatokhoz ne férjen hozzá, azokról másolatot ne készíthessen.
Egyfelől az üzemeltetésnek része a biztonsági mentés készítése - ha sikerül elérni, hogy a rendszergazda ne érje el az adatokat, akkor sikerült meghiúsítani ezt a lépést. Ok, ez speciális eset, ha minden kötél szakad, akkor a repo helyre állítható a másolatokból - de azért nem ez legyen az alapelv egy biztonsági másolat készítésénél.
Másfelől: az Unix filozófia szerint a rendszergazda mindenható, mindent lát, mindent elérhet. Bár nem lehetetlen ennek valamilyen módon, a megfelelő titkosítással keresztbe tenni - viszont ez garantáltan és jelentősen bonyolultabbá fogja tenni az eredeti feladatot, jó eséllyel a titkosítás miatt erőforrás igényesebbé is.

Ilyen esetben lehet, érdemes lenne más irányban gondolkodni, pl. lecserélhető-e a rendszergazda olyanra, akiben meg is bízunk?

Ebben a játékban a rendszergazda személye adott: Vagy teljesen más megoldást keresünk, vagy megpróbálkozunk itt valamelyik megoldással rendszergazdástól, mindenestül.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Erted te a problemat :)

Azt a reszet viszont nem vetted figyelembe, hogy nem csak a megbizott rendszergazdanak van root joga a gepre. Teljesen siman elkepzelheto, hogy a megbizott rendszergazdanak az a feladata, hogy karban tartsa a gepet, feltegye a biztonsagi frissiteseket, piszkalja a tuzesfalat, es a tobbi. A git repo adminisztralasa mar nem az o hataskore, semmi koze hozza, es nem kene belelatnia.

Az, hogy a rendszergazda mindent lathat es elerhet alapbol, az tok jo meg minden, de amiota letezik titkositas, ez mar nem all fenn. Hiaba vagyok en rendszergazda akarhol, ha a usereim gpg-vel titkositva leveleznek, azt biza el nem olvasom, akarmennyire is ostoroz az nbh vagy akarmi. Ez ez Jol Van Igy(tm).

Szamomra teljesen ertheto, hogy a gep napi teendoit kulsos rendszergazdara bizzak, mert az ugy olcsobb es/vagy kenyelmesebb. Ezesetben viszont meg kene oldani, hogy ne ferjen hozza olyan dolgokhoz, amihez nem kene neki. Ez is logikus.

Eszembe jutott meg egy otlet, bar ez talan meg az eddigieknel is nagyobb hack bizonyos szempontbol:

Arrol szolna az elkepzeles, hogy a tavoli szerverre felhuztok egy virtualis gepet, arra lesz rahuzva a git repo, egy encrypted fs-re. A virtualis gepen belul az untrusted rendszergazdanak nincsen semmi joga, igy nem lat bele az encrypted fs-be. Ezutan csinal az ember egy VPN-t a virtualis gepre, es problem solved.

Ennek ugyan megvan az a hatranya, hogy ha nagyon erolkodik a rendszergazda, akkor valoszinuleg el tudna olvasni a git repot, de ahhoz nagyon erolkodnie kell, es azt mar lehet figyelni, es seggberugni ha probalkozik, meg azelott, hogy sikerrel jarna.

Igazából ha rendesen nekifekszik az ember, akkor szerintem ez a megoldás sem kevésbé biztonságos, sőt. Az tény, hogy több nehézséget rejthet a kidolgozása, különösen hogy a jelenlegi szerver is virtualizált, de mindenesetre ez egy nagyon jó ötlet, köszi! :)

Ui.:Itt akkor nincs gond az sshfs-sel, ami pl. probléma lehet a Windows-userek esetén (sicc!) és teljesítmény szempontjából, de a repót sem kell széthekkelni.
Most ez tűnik a leghasználhatóbb ötletnek, a teljesítmény annyira nem vészes, mert mást nem terveztünk a szerverre és nincs túl sok felhasználó sem.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

"de ahhoz nagyon erolkodnie kell"

... marmint ahhoz, hogy elfelejtse, hogy kb. minden virtualizacios rendszeren jol ismert, dokumentalt, es a gyarto altal tamogatott modszer van arra, hogy a hostbol debuggert csatlakoztassunk a guestekre, amivel teljesen felhasznalobarat modon irhato-olvashato a kernel memoria oda-vissza. Ez pedig egy kozepes kepessegu peknek is eleg, hogy 10 perc alatt szenne rootkitezze a gepet.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Gondolom ez a megfelelő módon letiltható, adhatsz tippeket.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Persze, de ha ezt megteszi, pillanatokon belul lebukik, es mielott barmi komolyabbat tehetne, mar megy a kis fekete helikopter. (Foleg, ha kozben okos modon nagyerokkel auditalodik amit a rendszergazda csinal, es esetleg meg alert is megy, ha valami nem teljesen kerek)

Ha egy picit erolkodik, akkor barmelyik eddig felsorolt megoldast egy oran belul meg lehet fektetni. A kulonbseg abban rejlik, hogy ez mennyire feltuno, es mennyire terulne meg neki :P

"Persze, de ha ezt megteszi, pillanatokon belul lebukik"

Meselj. :)

"Ha egy picit erolkodik, akkor barmelyik eddig felsorolt megoldast egy oran belul meg lehet fektetni."

Pl. ezt? Meselj. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Igazából attól tartok, hogy ez a megoldás teljesítménybeli problémát okoz, ront a hordozhatóságon (várhatóak Windows-os fejlesztők is), illetve a klienseknek nehéz összelőni a kapcsolódást (felmountolni a távoli fájlrendszert, arról felmountolni a titkosított image-t) és nem megoldható a zárolás.
Viszont tény, hogy izomból biztonságos. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Probald ki azt a felallast, hogy egy lokalis szervert neveztek ki masternek, a fejlesztok oda commitolnak, a tavoli szerveren levo reporol nem is kell tudniuk. Igy ez gyors, nincs vele tobb problema, mint amennyi a gittel magaval eleve lehetne.

Es cronbol, vagy valami mas modszerrel automatikusan pusholodna ez a lokalis master a tavoli szerverre (illetve hat az onnan felmountolt titkositott fs-re).

Ilyenkor lesz könnyes az ember szeme, ha arra gondolok, hogy "és ezt pár embernek el kellene érnie kintről is"... :S

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Azok VPN-en bejonnek hozzatok, es elerik azt >:]

Lebukast elosegitheti a process accounting, es a gyakori jelentes emailben. Ha kikapcsolja barmelyiket, az gyanus, es rogton lehet menni ugralni hogy barmit csinal, hagyja abba. Ha meg folyamatosan megy, akkor kiderul a reportbol, ha valami disznosagra keszul.

Vagy, amit egyik kollega emlitett: SCB. Ezt bevagni a szerver ele, maris lehet auditalni, amit a rendszergazda csinal. Bar kisse koltseges ha csak arra van, hogy egy embert kordaban tartson, de ez is egy opcio.

A sajat otletem is torheto, bar picit maskepp, emlitette is itt valaki: patchelt ssh, patchelt shell, es maris rengeteg informacio van az untrusted root kezeben, amivel lenyegesen leegyszerusodik (ha nem valik rogton trivialissa) a tores.

Szerintem ez nem teszi törhetővé a te megoldásod, hiszen a szervert csak arra használnánk, hogy a titkosított fájlrendszert tároljuk rajta, az üzembe helyezése már nem a szerveren történne.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

"Ha kikapcsolja barmelyiket, az gyanus"

Miert kapcsolna ki, ha hamisithatja is?

"Vagy, amit egyik kollega emlitett: SCB. Ezt bevagni a szerver ele, maris lehet auditalni, amit a rendszergazda csinal."

Ez ugyanugy (nem) mukodik akkor is, ha a hoston futkarozik a git, mintha becsomagolod egy vm-be.
Plusz ennel mar egyszerubb, ha hagyod az egeszet a rakba, es sajat kezuleg adminolod a szervert. :)

"A sajat otletem is torheto, bar picit maskepp"

Akkor felreertettem az otletedet. Nem arrol volt szo, hogy a szerveren csak tarolod a cuccot, a logika meg fusson mashol?

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Idézet:
Nem arrol volt szo, hogy a szerveren csak tarolod a cuccot, a logika meg fusson mashol?

Én is így értelmeztem eddig.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

ha tavolrol shellen keresztul piszkalnatok a cuccot, akkor mi akadalyozna meg a gonosz rendszergazdat, hogy kicserelje/megpatkolja a shelleteket, vagy egyeb modon(nem akarok otleteket adni) bealljon man-in-the-middle -lel a kliens es a szerver koze?
maximum azt tudnam elkepzelni, amit mar elottem is irtak, hogy magat a particiot csak valami raw device-nak hasznalnatok, azt tavolrol felmountoljatok, a repot es a titkositast ezen a trusted gepen uzemeltetve, de akkor mar egyszerubb, ha valamelyik devel gepet kinevezitek master-nek, es valamilyen uton modon kiajanljatok a tobbi fejlesztonek, git eleg sok protokollt tamogat.

Tyrael

Nyilván ez is egy olyan kérdés, amire még nem gondoltam, köszi! :)
A virtualizált ötletről mit gondolsz?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Lehet sz*r az ötlet, de ha mondjuk a mostani VAS-at ketté szedjük két virtuális gépre, akkor Xen-ben gondolkozva lesz egy Dom0(gazda), Dom1(git-srv), Dom2(összes többi szolgáltatás). A rendszergazda menedzseli a Dom2-t (kvázi bezárjuk abba a virtuális gépbe), tehát neki köze nem lesz a Dom0-hoz és Dom1-hez, persze ez felvet még egy kérdést, hogy ki menedzseli a Dom0-t? :) De, ha mondjuk a Dom0-n tényleg nem fut semmi más csak a két virtuális gép akkor ez akár egy jó megoldás is lehet.

+1

Kicsit tivabb gondolva: huzzatok fel egy OpenVPN -t. Ezen keresztul kintrol, bentrol alulrol es felulrol is elerhetitek az irodaban mukodo GIT szervert tetszolegesen valaszott protokollal. A problema csak az, hogy a szervernek a kulso rendszergazda kezei kozott levo vitualis gepen kell lennie, de igy lementheti a VPN forgalmat. Persze ha a VPN felett SSH -n eritek el a GIT szervert, akkor mar eleg nehez dolga lesz. Igy persze a biztonsagi mentest hazon belul kell megoldani.

VPN -nel semmi hack, tisztabb, szarazabb erzes, en biztos ezt valasztanam. :)

Már majdnem elfelejtettem, de az utókornak elmesélem a végeredményt.
Szóval alaposan utánaolvasva és felmérve a lehetőségeket és előnyöket/hátrányokat úgy döntöttünk, hogy a Git repository-kat egy külön erre a célra fenntartott gép fogja kezelni, amelyik kapott RAID-et és egyéb hasznos dolgokat a hardver-alapú hibák kivédése érdekében. Erre a gépre más szolgáltatás nem került, és mivel pontosan szabályozható, hogy kinek milyen hozzáférésre lehet szüksége, ezért a gépet nem bíztuk a rendszergazdára.

A rendszer azóta is működik, a géppel és a rendszerrel nem merült fel probléma, illetve a rendszergazda szolgáltatásairól sem kellett lemondanunk.

Köszönöm mindenki segítségét, nagyon hasznos dolgokat tudtam meg és olyan problémákat gondolhattam végig, amelyek előtte fel sem merültek bennem.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

github.com fizetős verzió miért nem ok?

Ugyanaz a probléma, csak nem a külsős, megbízott rendszergazda nézhetne bele a repo tartalmába, hanem a github üzemeltetői.

atomrakéta program? sztem leszarják ám ezeket, kérdés h fuse sshfs fölött csatolt fuse titkosított fájlrendszeren működik-e a dolog

Igen. Ellenben lassu, es windowsos fejlesztoknek enyhen szolva is problemat jelent (lasd a hasonlo otleteket fentebb).

ha atomrakéta, akkor miért kérdezed egyátalán? virtualbox és linux vagy cygwin ha megy a fuse ott, btw. atomrakétához a win nem ok

En nem kerdezek semmit. VB+lin vagy cygwin meg meg egy adag extra lassusag. Kosz nem kell.

De mindez mar meg lett beszelve fentebb, keretik visszaolvasni.

whatever, btw +1 jevgenyij

Több projectnél is előfordul, hogy hónapokig nem kerül bele kód, viszont a repóját nem kellene archiválni, mert hivatkoznak rá vagy csak meg szeretnék tekinteni az abban található forráskódot.
Így viszont ez alapján: https://github.com/plans a "Silver"-ig minden csomag kiesik, mert 20 privát repó van benne, aminek kétharmadát már most meg lehetne tölteni pl. a submodule miatt.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

A legegyszerűbb megoldás ha kirúgjátok a rendszergazdát és felvesztek helyette egy olyat, akiben meg is bíztok.

szerintem nem ez a jo hozzaallas.
egyreszt mi alapjan valasztod ki, hogy ki a megbizhato ember?
masreszt meg lehet hogy ma megbizhato, holnap elbukja a hazat kartyan, es penze teszi a bizalmas informaciokat.
szerintem inkabb abba az iranyba erdemes elmenni, hogy minel atlathatobb legyenek az IT folyamatok:
http://en.wikipedia.org/wiki/Separation_of_duties
legyen legalabb 2 rendszergazda, a kritikus muveletekhez kelljen legalabb 2 ember reszvetele.

ps: http://thebloodyxxx.deviantart.com/art/Who-Watches-the-Watchmen-115122880

Tyrael

Ezek a kérdések a fejlesztőkkel szemben is felmerülhetnek. Nekik pedig mindenképpen hozzáféréssel kell rendelkezniük.
Egyes hadseregekben az a módszer, hogy a tüzérek őrzik a vadászrepülőket, a deszantosok a tankokat, mindenki azt amihez nem ért. Himmler meg úgy oldotta meg a titkos V rakéták gyártását, hogy egy hegy gyomrában volt a gyár, rabok dolgoztak, akik csak hullaként hagyhatták el a föld alatti gyár területét. Ez is egy módszer. Egy normális világban szükség van alapvető bizalomra.
EncFs és remote mount, hogy írjak gyakorlati tanácsot is. Bár ilyen erővel lehetne egy fejlesztő gépén is a git repo.

persze, fejlesztokkel kapcsolatban is para, ha 1 ember kezebene van a teljes jogkor a kodbazis folott.
de ott ha van N fejlesztod, es van normalis code review folyamatod, akkor megelozheto, hogy 1 ember szandekosan szabotaljon valamit a kodban.

ha elolvasod a szalat, akkor tobben is felvetettek amit te irsz: mind a remote mountot, mind azt hogy kapjon egy kulon gepet, sot igazabol ha elolvasod a szalat, akkor kiderul, hogy a vegen ez lett a megoldas.

Tyrael

Segíteni akartam, de nem olvastam el az összeset, ahhoz nem lenne türelmem. :) Egy két hetes még aktív témába szerintem belefér ennyi redundancia.