Dove mantenere il repository di sorgenti centrale?

Qual è la migliore pratica del settore per quanto riguarda la protezione dell'accesso al codice sorgente? Sto pensando che solo le connessioni SSL consentite tramite apache al nostro server su una porta oscura che non sia in conflitto con nient'altro. La cosa che mi preoccupa è l'archiviazione del codice sorgente su un server pubblico, cioè non accessibile solo tramite una LAN. Inoltre, questo server ha diversi usi. Apache sta già servendo alcuni altri siti Web interni dell'azienda. Vorrei che tutti potessero accedere al codice sorgente da qualsiasi luogo (casa, aeroporto, qualunque cosa) purché abbiano le credenziali corrette. Suggerimenti?

Se sei preoccupato che si trovi su un server pubblico ma desideri accedere da qualsiasi luogo, dovresti prendere in considerazione la possibilità per i tuoi sviluppatori di utilizzare una VPN basata su client per accedere alla rete in remoto per accedere a un server di controllo del codice sorgente interno.

Non sono troppo sicuro del motivo per cui le persone pensano che l'approccio VPN sia il migliore. Non è necessariamente più sicuro e offre solo un vantaggio che mi viene in mente.

Ad esempio, è noto che PPTP ha una sicurezza tutt'altro che ideale, anche se credo che sia leggermente migliorato dalla prima introduzione ... quindi fai attenzione a quale soluzione VPN usi. Andrei con OpenVPN o IPSEC.

Tuttavia, non puoi battere la comodità di SSL / TLS senza la VPN (leggi di seguito). E per renderlo ancora più sicuro, puoi renderlo solo certificato.

Tuttavia, se ritieni di poter offrire altri servizi oltre al controllo del codice sorgente, prendi in considerazione una soluzione VPN perché eseguirai il tunneling di altri servizi su di essa.

Lo svantaggio dell'uso di una VPN è che il tuo PC diventa effettivamente parte della rete a cui si sta connettendo. Anche questo può essere un vantaggio. Ma, se sei a un milione di miglia da casa e la connessione di rete alla base di casa non è troppo veloce, ogni volta che vuoi fare un codice diff o check in o out potresti ritrovarti a connetterti e disconnetterti dalla VPN.

Posso parlare per esperienza personale qui perché sono uno sviluppatore ed è stato un vero dolore nel fare questo !!! Idealmente, entrambe le opzioni sono preferite.

Quindi se stai navigando sul web ecc., Allora potrebbe rallentare la lettura delle notizie ecc. Ma almeno hai accesso sicuro alla posta elettronica. Quindi considera come lo userai prima ... Se fossi in te prenderei in considerazione l'implementazione di entrambi.

In realtà, mi piace il tuo suggerimento. Se rendi il tuo repository di codice sorgente accessibile SOLO tramite SSL / TLS e ti assicuri che i tuoi sviluppatori non utilizzino passphrase di forza bruta (o meglio ancora, usano i certificati), allora dovrebbe essere sicuro come qualsiasi altra cosa .

Potresti, invece, nascondere il tuo server all'interno della tua LAN e forzare gli sviluppatori a utilizzare una VPN per ottenere l'accesso, ma ciò significa solo che i tuoi sviluppatori devono inserire il loro nome utente / password (e / o certificato) in una casella di accesso diversa. Consiglio di non creare un punto di accesso alla rete le cui implicazioni sulla sicurezza potrebbero non essere sempre ovvie, solo per consentire l'accesso a un singolo servizio. Se hai già configurato e protetto VPN per altri usi, allora sicuramente è un gioco da ragazzi, vai avanti e usalo. Altrimenti, potrebbe essere più semplice, e quindi più sicuro, rendere il servizio stesso direttamente disponibile tramite SSL / TLS.

Lo standard industriale probabilmente dipende da quale settore (o dei tuoi clienti) è :-)

Praticamente devi considerare a chi vuoi dare accesso e cosa possono gestire. Alcune persone a cui potresti desiderare / cui accedere non saranno in grado di gestire molto più di un nome utente / password. Altri potrebbero essere in grado di aggirare ssh e una chiave privata, a condizione che tu possa ottenere in modo sicuro la chiave per loro, non è male. Il client TortoiseSVN può gestire ssh + svn e supporta le chiavi private con un po 'di torsione del braccio. È stato abbastanza buono per i miei scopi.

Anche un tunnel VPN è un buon suggerimento, anche se in molti posti saresti felice di dare alle persone esterne l'accesso solo al tuo controllo del codice sorgente, ma non all'intera rete!

Come altri, preferisco una VPN. Un'alternativa sarebbe un tunnel SSH, che suppongo in termini pratici sia comunque una specie di VPN.

Rendilo solo interno e implementa una soluzione VPN per utenti remoti. / Doh- duplicato.

Se si desidera accedere da qualsiasi luogo, è necessario un server pubblico - questo è chiaro.

Su quel server, vuoi esporre il meno possibile , preferibilmente solo Mercurial / Subversion e nient'altro. Questo per evitare che una violazione della sicurezza si diffonda dal controllo del codice sorgente al resto dell'azienda. Per questo motivo, concordo con Matt quando afferma che una VPN può essere pericolosa: offre un accesso molto più ampio del necessario.

Per Mercurial, puoi bloccare strettamente le cose usando hg-sshper limitare i comandi disponibili ai client che si connettono tramite SSH. Utilizzando SSH, è possibile richiedere facilmente ai client di utilizzare l'autenticazione con chiave pubblica anziché le password. Questo protegge il tuo server dagli attacchi di login a forza bruta.

Anche se una chiave SSH è compromessa (forse aveva una passphrase debole e il laptop che la memorizzava è stato rubato), il danno peggiore che un utente malintenzionato può fare è aggiungere la cronologia dei rifiuti in Mercurial. Il protocollo utilizzato è intrinsecamente di sola aggiunta, quindi non è possibile eliminare nulla hg push.

Per HTTPS, l' autenticazione viene eseguita dal server Web front-end . Ciò significa che è possibile richiedere i certificati del sito client se lo si desidera e quindi ottenere la sicurezza come l'autenticazione della chiave pubblica SSH sopra.