Basic Github Information
Struttura di base
La struttura di base dell'ambiente Github di una grande azienda è di possedere un'azienda che possiede diverse organizzazioni e ognuna di esse può contenere diversi repository e diversi team. Le aziende più piccole possono possedere solo un'organizzazione e nessuna azienda.
Dal punto di vista dell'utente, un utente può essere un membro di diverse aziende e organizzazioni. All'interno di esse, l'utente può avere diversi ruoli di azienda, organizzazione e repository.
Inoltre, un utente può far parte di diversi team con ruoli diversi di azienda, organizzazione o repository.
E infine, i repository possono avere meccanismi di protezione speciali.
Privilegi
Ruoli aziendali
Proprietario dell'azienda: Le persone con questo ruolo possono gestire gli amministratori, gestire le organizzazioni all'interno dell'azienda, gestire le impostazioni dell'azienda, imporre una politica in tutte le organizzazioni. Tuttavia, non possono accedere alle impostazioni o ai contenuti dell'organizzazione a meno che non vengano nominati proprietari dell'organizzazione o vengano loro fornito un accesso diretto a un repository di proprietà dell'organizzazione.
Membri dell'azienda: I membri delle organizzazioni di proprietà della tua azienda sono anche automaticamente membri dell'azienda.
Ruoli dell'organizzazione
In un'organizzazione gli utenti possono avere ruoli diversi:
Proprietari dell'organizzazione: I proprietari dell'organizzazione hanno accesso amministrativo completo alla tua organizzazione. Questo ruolo dovrebbe essere limitato, ma non meno di due persone, nella tua organizzazione.
Membri dell'organizzazione: Il ruolo predefinito, non amministrativo, per le persone in un'organizzazione è il membro dell'organizzazione. Per impostazione predefinita, i membri dell'organizzazione hanno una serie di autorizzazioni.
Gestori di fatturazione: I gestori di fatturazione sono utenti che possono gestire le impostazioni di fatturazione per la tua organizzazione, come le informazioni di pagamento.
Gestori della sicurezza: È un ruolo che i proprietari dell'organizzazione possono assegnare a qualsiasi team in un'organizzazione. Quando viene applicato, dà a ogni membro del team le autorizzazioni per gestire gli avvisi e le impostazioni di sicurezza in tutta l'organizzazione, nonché le autorizzazioni di lettura per tutti i repository dell'organizzazione.
Se la tua organizzazione ha un team di sicurezza, puoi utilizzare il ruolo di gestore della sicurezza per dare ai membri del team l'accesso minimo necessario all'organizzazione.
Gestori delle app di Github: Per consentire ad altri utenti di gestire le app di GitHub di proprietà di un'organizzazione, un proprietario può concedere loro le autorizzazioni di gestore dell'app di GitHub.
Collaboratori esterni: Un collaboratore esterno è una persona che ha accesso a uno o più repository dell'organizzazione ma non è esplicitamente un membro dell'organizzazione.
Puoi confrontare le autorizzazioni di questi ruoli in questa tabella: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles
Privilegi dei membri
In https://github.com/organizations/<org_name>/settings/member_privileges puoi vedere le autorizzazioni che gli utenti avranno solo per far parte dell'organizzazione.
Le impostazioni configurate qui indicheranno le seguenti autorizzazioni dei membri dell'organizzazione:
Essere amministratore, scrittore, lettore o senza autorizzazioni su tutti i repository dell'organizzazione.
Se i membri possono creare repository privati, interni o pubblici.
Se è possibile fare il fork dei repository
Se è possibile invitare collaboratori esterni
Se è possibile pubblicare siti pubblici o privati
Le autorizzazioni degli amministratori sui repository
Se i membri possono creare nuovi team
Ruoli del repository
Per impostazione predefinita, vengono creati ruoli di repository:
Lettura: Consigliato per contributori non legati al codice che desiderano visualizzare o discutere del tuo progetto
Triage: Consigliato per contributori che devono gestire attivamente problemi e richieste di pull senza accesso in scrittura
Scrittura: Consigliato per contributori che contribuiscono attivamente al tuo progetto
Manutenzione: Consigliato per responsabili di progetto che devono gestire il repository senza accesso a azioni sensibili o distruttive
Amministrazione: Consigliato per le persone che hanno accesso completo al progetto, comprese azioni sensibili e distruttive come la gestione della sicurezza o l'eliminazione di un repository
Puoi confrontare le autorizzazioni di ogni ruolo in questa tabella https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role
Puoi anche creare i tuoi ruoli in https://github.com/organizations/<org_name>/settings/roles
Team
Puoi elencare i team creati in un'organizzazione in https://github.com/orgs/<org_name>/teams. Nota che per vedere i team che sono figli di altri team è necessario accedere a ciascun team genitore.
Utenti
Gli utenti di un'organizzazione possono essere elencati in https://github.com/orgs/<org_name>/people.
Nelle informazioni di ciascun utente puoi vedere i team di cui l'utente è membro e i repository a cui l'utente ha accesso.
Autenticazione Github
Github offre diversi modi per autenticarsi al proprio account e eseguire azioni per conto proprio.
Accesso Web
Accedendo a github.com puoi effettuare il login utilizzando il tuo nome utente e password (e potenzialmente un 2FA).
Chiavi SSH
Puoi configurare il tuo account con una o più chiavi pubbliche che consentono alla relativa chiave privata di eseguire azioni per conto tuo. https://github.com/settings/keys
Chiavi GPG
Non puoi impersonare l'utente con queste chiavi, ma se non le usi potrebbe essere possibile che venga scoperto l'invio di commit senza firma. Scopri di più sulla modalità vigile qui.
Token di accesso personale
Puoi generare un token di accesso personale per dare a un'applicazione accesso al tuo account. Durante la creazione di un token di accesso personale, l'utente deve specificare le autorizzazioni che il token avrà. https://github.com/settings/tokens
Applicazioni OAuth
Le applicazioni OAuth possono chiederti le autorizzazioni per accedere a parte delle tue informazioni su GitHub o per impersonarti al fine di eseguire determinate azioni. Un esempio comune di questa funzionalità è il pulsante di accesso con GitHub che potresti trovare in alcune piattaforme.
Puoi creare le tue applicazioni OAuth su https://github.com/settings/developers
Puoi vedere tutte le applicazioni OAuth che hanno accesso al tuo account su https://github.com/settings/applications
Puoi vedere gli ambiti che le app OAuth possono richiedere su https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
Puoi vedere l'accesso di terze parti alle applicazioni in un'organizzazione su https://github.com/organizations/<org_name>/settings/oauth_application_policy
Alcune raccomandazioni sulla sicurezza:
Un'app OAuth dovrebbe sempre agire come l'utente autenticato di GitHub in tutto GitHub (ad esempio, quando fornisce notifiche all'utente) e con accesso solo agli ambiti specificati.
Un'app OAuth può essere utilizzata come un provider di identità abilitando un "Accesso con GitHub" per l'utente autenticato.
Non creare un'app OAuth se desideri che la tua applicazione agisca su un singolo repository. Con l'ambito
repo, le app OAuth possono agire su tutti i repository dell'utente autenticato.Non creare un'app OAuth per agire come un'applicazione per il team o l'azienda. Le app OAuth si autenticano come un singolo utente, quindi se una persona crea un'app OAuth per l'uso di un'azienda e poi lascia l'azienda, nessun altro avrà accesso ad essa.
Altro su qui.
Applicazioni GitHub
Le applicazioni GitHub possono richiedere le autorizzazioni per accedere alle tue informazioni su GitHub o impersonarti al fine di eseguire azioni specifiche su risorse specifiche. Nelle app GitHub è necessario specificare i repository a cui l'app avrà accesso.
Per installare un'app GitHub, devi essere un proprietario dell'organizzazione o avere autorizzazioni di amministratore in un repository.
L'app GitHub dovrebbe connettersi a un account personale o a un'organizzazione.
Puoi creare la tua applicazione GitHub su https://github.com/settings/apps
Puoi vedere tutte le app GitHub che hanno accesso al tuo account su https://github.com/settings/apps/authorizations
Questi sono i punti di accesso API per le applicazioni GitHub https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. A seconda delle autorizzazioni dell'app, sarà in grado di accedere a alcuni di essi.
Puoi vedere le app installate in un'organizzazione su https://github.com/organizations/<org_name>/settings/installations
Alcune raccomandazioni sulla sicurezza:
Un'app GitHub dovrebbe prendere azioni indipendenti da un utente (a meno che l'app stia utilizzando un token richiesta da utente a server). Per mantenere più sicuri i token di accesso da utente a server, puoi utilizzare token di accesso che scadono dopo 8 ore e un token di aggiornamento che può essere scambiato con un nuovo token di accesso. Per ulteriori informazioni, consulta "Aggiornamento dei token di accesso da utente a server."
Assicurati che l'app GitHub si integri con repository specifici.
L'app GitHub dovrebbe connettersi a un account personale o a un'organizzazione.
Non aspettarti che l'app GitHub conosca e faccia tutto ciò che può fare un utente.
Non utilizzare un'app GitHub se hai solo bisogno di un servizio "Accesso con GitHub". Ma un'app GitHub può utilizzare un flusso di identificazione dell'utente per accedere agli utenti e fare altre cose.
Non creare un'app GitHub se vuoi solo agire come un utente GitHub e fare tutto ciò che quell'utente può fare.
Se stai utilizzando la tua app con GitHub Actions e desideri modificare i file di flusso di lavoro, devi autenticarti per conto dell'utente con un token OAuth che include l'ambito
workflow. L'utente deve avere autorizzazioni di amministratore o scrittura per il repository che contiene il file di flusso di lavoro. Per ulteriori informazioni, consulta "Comprensione degli ambiti per le app OAuth."Altro su qui.
Azioni GitHub
Questa non è un modo per autenticarsi su GitHub, ma un'Azione GitHub malevola potrebbe ottenere accesso non autorizzato a GitHub e, a seconda dei privilegi concessi all'Azione, potrebbero essere effettuati diversi attacchi. Vedi di seguito per ulteriori informazioni.
Azioni Git
Le azioni Git consentono di automatizzare l'esecuzione del codice quando si verifica un evento. Di solito il codice eseguito è in qualche modo correlato al codice del repository (ad esempio, creare un contenitore Docker o verificare che la richiesta di pull non contenga segreti).
Configurazione
In https://github.com/organizations/<org_name>/settings/actions è possibile verificare la configurazione delle azioni GitHub per l'organizzazione.
È possibile impedire completamente l'uso delle azioni GitHub, consentire tutte le azioni GitHub o consentire solo determinate azioni.
È anche possibile configurare chi ha bisogno di approvazione per eseguire un'azione GitHub e le autorizzazioni del token GITHUB_TOKEN di un'azione GitHub quando viene eseguita.
Segreti Git
Le azioni GitHub di solito hanno bisogno di qualche tipo di segreto per interagire con GitHub o applicazioni di terze parti. Per evitare di inserirli in chiaro nel repository, GitHub consente di inserirli come Segreti.
Questi segreti possono essere configurati per il repository o per tutta l'organizzazione. Quindi, affinché l'Azione possa accedere al segreto, è necessario dichiararlo come:
Esempio usando Bash
I segreti possono essere accessibili solo dalle Github Actions che li hanno dichiarati.
Una volta configurati nel repository o nelle organizzazioni, gli utenti di Github non saranno più in grado di accedervi, ma saranno in grado di modificarli.
Pertanto, l'unico modo per rubare i segreti di Github è essere in grado di accedere alla macchina che sta eseguendo l'azione di Github (in questo scenario sarai in grado di accedere solo ai segreti dichiarati per l'azione).
Ambienti Git
Github consente di creare ambienti in cui è possibile salvare segreti. Successivamente, puoi dare all'azione di Github l'accesso ai segreti all'interno dell'ambiente con qualcosa del genere:
È possibile configurare un ambiente per essere accessibile da tutti i branch (impostazione predefinita), solo dai branch protetti o specificando quali branch possono accedervi. È anche possibile impostare un numero di revisioni richieste prima di eseguire un'azione utilizzando un ambiente o attendere un certo tempo prima di consentire le distribuzioni.
Git Action Runner
Un'azione di Github può essere eseguita all'interno dell'ambiente di Github o può essere eseguita in un'infrastruttura di terze parti configurata dall'utente.
Diverse organizzazioni consentiranno di eseguire le Azioni di Github in un'infrastruttura di terze parti poiché solitamente è più conveniente.
È possibile elencare i runner self-hosted di un'organizzazione su https://github.com/organizations/<org_name>/settings/actions/runners
Il modo per scoprire quali Azioni di Github vengono eseguite in un'infrastruttura non di Github è cercare runs-on: self-hosted nella configurazione yaml dell'azione di Github.
Non è possibile eseguire un'azione di Github di un'organizzazione all'interno di una macchina self-hosted di un'altra organizzazione perché viene generato un token univoco per il Runner quando viene configurato per sapere a quale Runner appartiene.
Se il Runner personalizzato di Github è configurato in una macchina all'interno di AWS o GCP, ad esempio, l'azione potrebbe avere accesso all'endpoint dei metadati e rubare il token dell'account di servizio con cui la macchina sta eseguendo.
Compromissione di Git Action
Se tutte le azioni (o un'azione malevola) sono consentite, un utente potrebbe utilizzare un'azione di Github che è malevola e comprometterà il contenitore in cui viene eseguita.
Un'azione di Github malevola può essere sfruttata dall'attaccante per:
Rubare tutte le credenziali segrete a cui l'azione ha accesso
Muoversi lateralmente se l'azione viene eseguita all'interno di un'infrastruttura di terze parti in cui il token SA utilizzato per eseguire la macchina può essere accessibile (probabilmente tramite il servizio di metadati)
Abusare del token utilizzato dal flusso di lavoro per rubare il codice del repository in cui viene eseguita l'azione o modificarlo addirittura.
Protezioni del Branch
Le protezioni del branch sono progettate per non dare il completo controllo di un repository agli utenti. L'obiettivo è applicare diversi metodi di protezione prima di poter scrivere codice in un determinato branch.
Le protezioni del branch di un repository possono essere trovate su https://github.com/<orgname>/<reponame>/settings/branches
Non è possibile impostare una protezione del branch a livello di organizzazione. Quindi tutte devono essere dichiarate su ogni repository.
Diverse protezioni possono essere applicate a un branch (come a master):
È possibile richiedere una PR prima di effettuare il merge (quindi non è possibile eseguire direttamente il merge del codice sul branch). Se questa opzione è selezionata, possono essere applicate diverse altre protezioni:
Richiedere un numero di approvazioni. È molto comune richiedere l'approvazione di 1 o 2 persone in più per la propria PR, in modo che un singolo utente non sia in grado di eseguire direttamente il merge del codice.
Ignorare le approvazioni quando vengono aggiunti nuovi commit. In caso contrario, un utente potrebbe approvare un codice legittimo e successivamente potrebbe aggiungere codice malevolo e eseguire il merge.
Richiedere revisioni da parte dei proprietari del codice. Almeno un proprietario del codice del repository deve approvare la PR (in modo che gli utenti "casuali" non possano approvarla)
Limitare chi può ignorare le revisioni delle pull request. È possibile specificare le persone o i team autorizzati a ignorare le revisioni delle pull request.
Consentire ad attori specificati di eludere i requisiti delle pull request. Questi utenti saranno in grado di eludere le restrizioni precedenti.
Richiedere il superamento dei controlli di stato prima del merge. Alcuni controlli devono superare prima di poter eseguire il merge del commit (come un'azione di Github che verifica l'assenza di segreti in testo normale).
Richiedere la risoluzione delle conversazioni prima del merge. Tutti i commenti sul codice devono essere risolti prima che la PR possa essere eseguita il merge.
Richiedere commit firmati. I commit devono essere firmati.
Richiedere una cronologia lineare. Impedire l'invio di commit di merge ai branch corrispondenti.
Includere gli amministratori. Se questa opzione non è impostata, gli amministratori possono eludere le restrizioni.
Limitare chi può eseguire il push sui branch corrispondenti. Limitare chi può inviare una PR.
Come puoi vedere, anche se sei riuscito a ottenere le credenziali di un utente, i repository potrebbero essere protetti impedendoti di inviare codice a master, ad esempio, per compromettere il CI/CD pipeline.
Riferimenti
Last updated