Come evitare di spingere il codice Github Enterprise sul mio account Github personale per errore se entrambi sono configurati nel mio computer di lavoro?

3

Impostazione della discutibilità dell'utilizzo di account personali sul posto di lavoro.

Contesto:

La società per cui lavoro è dedita alla creazione di app per altre società. Per questo abbiamo molti clienti diversi e gestiamo molti progetti diversi all'interno dell'organizzazione Github Enterprise della nostra azienda. Sono uno dei responsabili del blog Medium dell'azienda. Dal momento che vorremmo promuovere l'azienda mostrando il tipo di persone che lavorano qui, ritengo fondamentale poter pubblicare articoli utilizzando ciascuno dei nostri account personali. A mio parere, la possibilità di condividere codice di esempio aumenta notevolmente il valore di un articolo. E la possibilità di farlo con i nostri account Github personali servirebbe anche come motivazione per le persone a contribuire al blog. (Soprattutto quelli che hanno molti progetti personali sui loro account Github personali)

Situazione attuale:

  • Tutti gli ingegneri sul posto di lavoro hanno account Github Enterprise. Questi account ci permettono di tirare e spingere dai repository all'interno della nostra organizzazione. Solo gli amministratori possono creare nuovi repository.

  • I nostri account GHE si connettono tramite SSH.

  • Al momento non è consentito utilizzare account Github personali nei nostri computer di lavoro, ma il loro utilizzo è preso in considerazione.

Problema:

I manager temono che se i conti Github personali sono consentiti sui computer della società, i dipendenti potrebbero finire per spingere il codice dei nostri clienti nei loro repository personali DA MISTAKE, il che comporta un enorme rischio di perdita di informazioni involontarie.

Permettetemi di chiarire che, non è un problema di politiche o di fiducia.

La domanda:

Considerando le seguenti azioni ipotetiche intraprese da un dipendente:

  1. Clona un progetto dal repository GHE per lavorarci sopra.
  2. Modifica del codice o aggiunge alcune funzionalità al progetto (ma dimentica di spingere le modifiche)
  3. Cambia account e lavora su alcuni progetti personali dal loro account personale.
  4. Ricorda che deve commettere modifiche. Quindi apre il progetto di lavoro e apporta le modifiche.
  5. Per qualche motivo gli manca il messaggio o l'avviso che sta spingendo o creando un repository con il suo account personale.

C'è un modo per garantire che il codice cliente non venga reso pubblico da un errore come questo? (tramite una sorta di configurazione)

Il caricamento del codice nei propri account personali è possibile per errore, anche considerando che il repository è stato creato su GHE? (Se la mia comprensione è corretta, i repository clonati dal mio account di lavoro sono automaticamente configurati per spingere, unire e tirare da Github Enterprise usando solo l'account di lavoro, quindi anche se avessi cambiato l'account avrei appena ricevuto un errore, ma forse Avrei bisogno di creare un nuovo repository sul mio account? Io non sono davvero un esperto che usa Github ...)

    
posta Pochi 29.08.2018 - 04:57
fonte

3 risposte

9

Git, sul lato client, non associa il metodo di autenticazione con l'indirizzo-repository. Spingere accidentalmente verso i repository personali è quindi NON possibile semplicemente cambiando i tasti ssh.

La clonazione di un repository da Github richiede due elementi indipendenti:

  1. un metodo di autorizzazione che ti identifica sul lato server (nel tuo caso ssh) e
  2. l'URL del repository.

Durante la clonazione da un repository GHE il tuo URL sarà simile a questo:

[email protected]/<organization-name>/<repo-name>

Per inviare questo codice a un repository personale nuovo o vuoto, l'utente dovrà modificare il push-url predefinito o specificare manualmente un nuovo URL al momento della pressione. Per ottenere ciò richiede (nella maggior parte degli strumenti di cui sono a conoscenza) un'azione esplicita. Lo chiamerei intenzionalmente e non accidentalmente .

È nella natura di Git che ogni database git può essere clonato e spinto ovunque a cui si ha accesso. Non puoi disabilitare questa funzione con Git. Puoi aggiungere ganci per aggiungere controlli che impediscano la spinta "accidentale" ad altri repository rispetto a quella originale, ma non è un errore che un utente non può ignorare.

La modifica della ssh-private-key dell'utente per ottenere l'accesso ad altri account o organizzazioni github non cambierà implicitamente l'URL del repository. Sarà semplicemente negato un git-push standard senza modificare l'URL.

    
risposta data 29.08.2018 - 11:00
fonte
1

Ho partecipato a ambienti di lavoro in cui tutto era aperto. Potrei navigare ovunque volessi, installare qualsiasi cosa volessi sul mio computer di lavoro, utilizzare un account Github privato e accedere a account di posta elettronica privati e di Facebook. Non c'erano regole, se non l'accordo sul fatto che ciò che accade in azienda risiede nell'azienda e ciò che la società possiede (compresa la loro proprietà intellettuale) è esclusivamente la loro. Ho ripagato questa fiducia non facendo mai e poi mai nulla che possa comprometterlo.

Ho anche partecipato a ambienti in cui tutto era bloccato in una determinata politica di "rifiuto implicito". Ogni utilizzo di internet è stato monitorato e registrato. Navigare ha richiesto di passare attraverso una casella Prevenzione perdita di dati. La metà dei siti web a cui sono andato non ha funzionato affatto. Molti di loro furono banditi; se non lo sapessero, non potevi accedervi, e se avevi bisogno di accedere, dovevi dimostrare una necessità legata al lavoro. Le unità del pollice erano un'impossibilità; se dovessi spostare i dati da un computer a un altro, dovevi farlo usando un CD o un DVD che era finalizzato.

In quale ambiente preferiresti lavorare? Quale ambiente supponi attiri i migliori talenti degli sviluppatori?

In ogni caso, penso che probabilmente non stai pensando a tutto il film. Mentre stai discutendo di bloccare gli account Github per prevenire la perdita di codice, qualcuno nella tua organizzazione potrebbe facilmente uscire dai tuoi locali con l'intera base di codice scritta su un DVD.

Potrei suggerire che sarebbe più semplice (e molto più efficace) assumere semplicemente persone di cui ti puoi fidare, oltre a implementare precauzioni di sicurezza ragionevoli e ragionevoli?

    
risposta data 29.08.2018 - 05:55
fonte
0

Ci sono centinaia di possibili scenari in cui un dipendente può accidentalmente inviare informazioni segrete fuori dalla compagnia.

  1. Invia email alla persona sbagliata
  2. Chiavi USB lasciate sui treni
  3. Computer portatili rubati
  4. Crea un repository pubblico piuttosto che privato
  5. Lascia il nome utente / passoff o predefinito su un server ftp
  6. Condividi un'unità cloud
  7. Lascia la sicurezza fuori da un bucket s3

etc

Devi aggiungere ciascuno a una "Mappa del rischio" valutando ciascuno per probabilità ed effetto.

Quando si tratta di valutare la probabilità di caricamento nel repository sbagliato, è necessario passare attraverso gli strumenti reali che si utilizzano e annotare i passaggi effettivi necessari.

Ricordati di includere anche tutti gli scenari che limitano l'accesso al github personale non .

Una volta valutato il rischio, puoi vedere quanta preoccupazione è correlata ad altri rischi che forse già accetti.

Se è ancora considerato troppo rischioso, puoi quindi considerare l'effetto di varie strategie di mitigazione come limitare l'accesso al github personale. Rimuoveranno completamente il rischio o solo una parte di esso. Quali sono i costi? Quali sono le opportunità perse ecc ecc

Se ti avvicini ad ogni rischio percepito come quello che fai, allora finisci col mettere al bando tutto ciò che è anche un rischio minuscolo e manca cose che sono un grosso rischio.

    
risposta data 29.08.2018 - 11:44
fonte

Leggi altre domande sui tag