Perché gli sviluppatori hanno bisogno di vere e proprie politiche di controllo degli accessi (non solo teoria)
Se stai spingendo il codice, mantenendo pipelineo la gestione dei registri degli artefatti, è necessario più della teoria. Policy di controllo degli accessi deboli o indefinite favoriscono la manomissione dei repository, CI/CD abuso e perdite di credenzialiDevSecOps richiede un'applicazione concreta, non solo impostazioni di autorizzazione nascoste.
Per gestire efficacemente le policy di controllo degli accessi nei repository di codice, CI/CD pipelinese registri di artefatti, molti team si affidano a strumenti di applicazione automatizzati come Xygeni. Monitorando costantemente ruoli, autorizzazioni e aderenza alle policy, Xygeni aiuta a prevenire deviazioni delle autorizzazioni, accessi non autorizzati e override manuali, trasformando la teoria del controllo obbligatorio degli accessi in azione.
Il controllo degli accessi blocca direttamente il codice sorgente, protegge le build e la produzione pipelineSe gli sviluppatori aggirano i controlli o gli account di servizio dispongono di autorizzazioni estese, si apre la porta a violazioni della sicurezza. Ecco perché è fondamentale comprendere il controllo degli accessi obbligatorio, il controllo degli accessi MAC e altri modelli.
Tipi di policy di controllo degli accessi che gli sviluppatori dovrebbero conoscere
Le politiche di controllo degli accessi rientrano in tre categorie principali, ciascuna delle quali si adatta in modo diverso CI/CD flussi di lavoro. Ecco una rapida analisi comparativa per chiarire:
| Modello | Chi controlla l'accesso? | Utilizzo tipico in CI/CD | Livello di rischio |
|---|---|---|---|
| DAC (controllo di accesso discrezionale) | Proprietario della risorsa (sviluppatore, amministratore) | Condivisione manuale dell'accesso al repository o al registro | Alto (errore umano) |
| RBAC (controllo degli accessi basato sui ruoli) | Il sistema assegna le autorizzazioni in base al ruolo | Protezione del ramo GitHub, accesso al lavoro CI in base ai ruoli utente | Medio (ruoli non configurati correttamente) |
| MAC (controllo di accesso obbligatorio) | Applicato dalla politica di sistema | Stabilisce chi può pubblicare artefatti o distribuire codice | Basso (la policy ignora l'intento dell'utente) |
Chiarire MAC vs. RBAC in CI/CD Contesto
È facile confondere il controllo degli accessi basato sui ruoli (RBAC) con controllo di accesso obbligatorio (controllo di accesso mac), soprattutto in CI/CD ambienti. Mentre CI/CD piattaforme come GitHub e GitLab utilizzano RBAC per gestire ruoli e permessi (ad esempio, chi può unire o distribuire), ma si tratta comunque di un controllo di accesso MAC fondamentalmente basato sui ruoli e non di un vero e proprio controllo di accesso MAC.
RBAC consente di assegnare autorizzazioni in base ai ruoli (sviluppatore, manutentore, ecc.), ma tali autorizzazioni sono comunque controllate dall'utente e modificabili. Errori di configurazione o accessi non autorizzati rappresentano rischi comuni.
Il controllo degli accessi obbligatorio (controllo degli accessi MAC), al contrario, viene applicato a livello di sistema o di infrastruttura. Gli utenti, inclusi gli amministratori, non possono ignorarlo. Si pensi al controllo degli accessi Mac come a policy integrate nella piattaforma: policy IAM nei provider cloud (ad esempio, AWS IAM, GCP IAM) o strumenti di applicazione a livello di sistema operativo come SELinux o AppArmor. In questi casi, l'accesso viene concesso solo se vengono soddisfatte regole predefinite e non aggirabili.
In CI/CDMolti strumenti simulano il comportamento del controllo degli accessi MAC attraverso ruoli IAM con ambito ristretto o autorizzazioni specifiche per risorsa, ma questo non rappresenta un controllo degli accessi obbligatorio completo. L'applicazione effettiva del controllo degli accessi obbligatorio richiede controlli a livello applicativo, a livello di sistema operativo, rete o infrastruttura cloud, dove l'accesso è regolato da policy di controllo degli accessi immutabili, non da configurazioni umane.
Controllo degli accessi basato sul ruolo (RBAC)
RBAC mappa le autorizzazioni a ruoli definiti come "sviluppatore", "manutentore" o "responsabile delle release". Semplifica la gestione in strumenti come GitHub e GitLabInvece di configurare ogni singolo utente, assegnagli un ruolo e lascia che sia il sistema a far rispettare le regole.
Esempio: File GitHub CODEOWNERS
# CODEOWNERS /docs/ @doc-team /scripts/ @devops-team /main.py @maintainers Ciò garantisce che solo i ruoli assegnati possano approvare le modifiche nelle directory critiche.
Impostazioni del ruolo GitLab: configura l'accesso al progetto in Impostazioni > Membri:
- Sviluppatore: Può essere spinto verso i rami delle funzionalità.
- Manutentore: Può fondersi con rami protetti.
- ospite: Accesso di sola lettura.
Esempio di flusso di lavoro RBAC di GitHub Actions:
yaml # .github/workflows/deploy.yml name: Deploy to Production on: push: branches: - main jobs: deploy: if: github.actor == 'release-manager' runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v2 - name: Deploy run: ./scripts/deploy.sh Controllo di accesso obbligatorio (MAC)
Il controllo degli accessi obbligatorio (controllo degli accessi MAC) impone rigide regole a livello di sistema che utenti e amministratori non possono ignorare. Utilizza il controllo degli accessi Mac per controllare rigorosamente chi può leggere, scrivere o eseguire risorse critiche.
Esempio: Criteri del registro degli artefatti di Google (YAML semplificato)
yaml bindings: - role: roles/artifactregistry.writer members: - serviceAccount:ci-deployer@project.iam.gserviceaccount.com Esempio: Policy Amazon ECR (YAML semplificato)
yaml Version: "2008-10-17" Statement: - Effect: Deny Principal: "*" Action: ecr:PutImage Resource: arn:aws:ecr:region:account-id:repository/my-app Condition: StringNotEquals: aws:userid: ci-service-account Rischi dell'override manuale e come MAC li previene
Uno dei rischi più grandi con RBAC e Modelli DAC è il rischio di override manuali intenzionali o accidentali. Ad esempio, un amministratore o uno sviluppatore potrebbe caricare direttamente artefatti in un registro protetto o concedere autorizzazioni eccessive al di fuori delle policy di controllo degli accessi definite. Queste azioni possono introdurre vulnerabilità o causare lacune nella conformità.
Il controllo di accesso obbligatorio (controllo di accesso MAC) impedisce tali override applicando policy a livello di sistema che nessun utente, nemmeno gli amministratori, può aggirare. Accesso decisLe ioni sono regolate da regole immutabili integrate nell'infrastruttura (come le policy IAM del cloud o i moduli di sicurezza a livello di sistema operativo). Ciò significa:
- Un amministratore non può caricare manualmente artefatti in un registro se la policy di controllo degli accessi del Mac li nega.
- Gli utenti non possono aumentare i privilegi o modificare le autorizzazioni al di fuori delle policy di controllo degli accessi definite.
- Automatizzata CI/CD pipelinevengono eseguiti rigorosamente entro i limiti delle autorizzazioni assegnate, impedendo l'espansione del campo di applicazione.
Eliminando gli override manuali, il controllo obbligatorio degli accessi garantisce una sicurezza più solida e affidabile rispetto ai soli RBAC o DAC.
2.4 Controllo di accesso discrezionale (DAC)
Il DAC consente ai proprietari delle risorse di assegnare manualmente i permessi. È flessibile ma rischioso. Una condivisione errata può compromettere un repository. Il DAC funziona in questo modo: "Sei il proprietario, decidi chi può accedervi".
Esempio: L' dev invita un collaboratore esterno e gli concede l'accesso in scrittura al repository. Il collaboratore invia il codice non sicuro direttamente al dev ramo.
In CI/CD, DAC potrebbe sembrare uno sviluppatore che concede manualmente l'accesso alla distribuzione di produzione a un membro temporaneo del team tramite console, al di fuori di qualsiasi politica di controllo degli accessi definita.
Come scegliere una politica di controllo degli accessi che funzioni realmente Pipelines
Controllo degli accessi in Git
Sfrutta RBAC per gestire i ruoli di contributore, manutentore e release. Blocca i diritti di merge sui rami protetti. Richiedi firma commite limitare chi può aggirare le protezioni.
Esempio: regole di protezione dei rami di GitHub
- Richiedere pull request recensioni prima della fusione.
- Licenziare stantio pull request approvazioni quando nuovo commitvengono spinti.
- Richiedi firma commits.
- Salta il DAC per i repository critici per la produzione. Non concedere l'accesso in scrittura con noncuranza.
Pipeline Rinforzo
Mettere in atto un controllo obbligatorio degli accessi per pipelines. Un solido modello di controllo degli accessi Mac limita i lavori CI solo alle autorizzazioni di cui hanno bisogno.
- Separare i segreti in base all'ambiente.
- Utilizzare token univoci per ogni ambiente.
- Impedire che le esecuzioni manuali influiscano sulla produzione.
Esempio: un processo CI riutilizza un token di distribuzione tra staging e produzione, spingendo accidentalmente il codice di test in modalità live.
Aggiungi regole di controllo degli accessi Mac per controllare l'ambito del token:
yaml env: DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN_PROD }} if: github.ref == 'refs/heads/main' && github.actor == 'release-manager' Esempio di ambito dei segreti: utilizzo di token specifici per l'ambiente
La corretta definizione dell'ambito dei segreti in base all'ambiente è fondamentale per impedire l'accesso accidentale o doloso tra ambienti. Ad esempio, un token di distribuzione per l'ambiente di sviluppo non dovrebbe mai essere utilizzabile per la distribuzione in produzione.
Ecco come i controlli basati su policy di controllo degli accessi isolano l'utilizzo dei segreti in GitHub Actions:
yaml env: DEPLOY_TOKEN_DEV: ${{ secrets.DEPLOY_TOKEN_DEV }} DEPLOY_TOKEN_PROD: ${{ secrets.DEPLOY_TOKEN_PROD }} jobs: deploy-dev: if: github.ref == 'refs/heads/dev' && github.actor == 'developer' runs-on: ubuntu-latest steps: - name: Deploy to Dev run: ./deploy.sh env: TOKEN: ${{ env.DEPLOY_TOKEN_DEV }} deploy-prod: if: github.ref == 'refs/heads/main' && github.actor == 'release-manager' runs-on: ubuntu-latest steps: - name: Deploy to Prod run: ./deploy.sh env: TOKEN: ${{ env.DEPLOY_TOKEN_PROD }} Ciò impone che:
- Solo il sviluppatore il ruolo può attivare le distribuzioni utilizzando il token dev su dev ramo.
- Solo il responsabile delle release il ruolo può essere distribuito in produzione utilizzando il token prod su principale ramo.
Tale utilizzo di segreti circoscritti riduce il rischio di perdite di token che si espandono negli ambienti e impone il minimo privilegio in CI/CD pipelines seguendo rigide politiche di controllo degli accessi.
Controlli di accesso agli artefatti
Bloccare i registri degli artefatti utilizzando il controllo di accesso obbligatorio. CI/CD dovrebbero essere i sistemi a gestire la pubblicazione, non i singoli sviluppatori.
Utilizza RBAC per definire quali team possono attingere da registri specifici. Gli sviluppatori potrebbero aver bisogno solo dell'accesso in lettura ai pacchetti di produzione.
json { "rules": [ { "action": "read", "resource": "npm-package:internal/*", "allowed_roles": ["developer", "qa"] }, { "action": "write", "resource": "npm-package:internal/*", "allowed_principals": ["ci-pipeline"] } ] } Errori comuni di controllo degli accessi nei flussi di lavoro di sviluppo
Accesso al repository eccessivamente permissivo
Problema: Concedere a troppi utenti l'accesso in scrittura/amministrazione ai repository.
Come avviene: I membri del team vengono promossi o aggiunti senza che le autorizzazioni siano state esaminate. I ruoli diventano eccessivi.
Exploit dell'attaccante: Gli aggressori prendono di mira questi account utilizzando credenziali rubate o tecniche di ingegneria sociale. Una volta all'interno, possono iniettare codice dannoso, backdoor o rimuovere la cronologia per nascondere le tracce.
Autorizzazioni condivise tra Dev e Prod
Problema: Lasciare che sviluppo e produzione pipelines condividere i permessi.
Come avviene: I team riutilizzano lo stesso token di distribuzione o account del servizio CI in tutti gli ambienti.
Exploit dell'attaccante: Una violazione dell'ambiente di sviluppo fornisce agli aggressori l'accesso alla produzione. Controllo obbligatorio degli accessi è possibile impedirlo vincolando le autorizzazioni ad ambienti specifici.
Caricamenti manuali di artefatti
Problema: Consentire il caricamento manuale degli artefatti nei registri di produzione.
Come avviene: Gli sviluppatori bypassano pipelineper soluzioni rapide o patch urgenti.
Exploit dell'attaccante: Le macchine degli sviluppatori compromesse possono caricare malware direttamente nell'archivio degli artefatti, bypassando tutti CI/CD controlli di sicurezza.
Rischio di abuso della politica del registro: La pubblicazione manuale di artefatti crea una superficie di attacco critica nella supply chain del software. Gli aggressori che sfruttano la vulnerabilità politiche di controllo degli accessi può inserire codice dannoso in pacchetti attendibili o immagini di container, portando a una compromissione diffusa a valle. Recenti incidenti nella supply chain del software hanno dimostrato come i caricamenti non regolamentati di artefatti possano rapidamente trasformarsi in gravi violazioni della sicurezza, colpendo innumerevoli utenti e sistemi.
Esempio: unUn utente interno con accesso completo al registro npm pubblica per errore una versione instabile. Se un aggressore avesse compromesso la macchina di quell'utente interno, avrebbe potuto pubblicare malware.
Misure pratiche per applicare controlli di accesso rigorosi
- Assegnare i ruoli alle autorizzazioni esatte, abbandonare le configurazioni "un ruolo adatto a tutti"
- Automatizza i controlli delle policy di controllo degli accessi nel tuo CI/CD pipelines
- Bloccare i registri con controllo di accesso obbligatorio
- Registrare e monitorare costantemente l'accesso ai sistemi critici
- Tratta le policy di controllo degli accessi come codice. Ogni passo falso può essere sfruttato.
Ruolo di Xygeni: applicazione e monitoraggio delle policy di accesso nei flussi di lavoro DevOps
Xygeni ti aiuta a trasformare il controllo di accesso obbligatorio dalla teoria all'azione risolvendo le sfide quotidiane e reali dell'applicazione delle policy di controllo degli accessi in DevSecOps pipelines.
- Risoluzione dell'accesso Git con permessi eccessivi: Xygeni monitora costantemente i repository Git per individuare violazioni RBAC, come assegnazioni di ruoli non revisionate o protezioni di branch mancanti. Segnala quando le policy di controllo degli accessi si discostano dalle regole definite e applica azioni correttive per evitare unioni accidentali o PR dannose.
- Blocco CI/CD Pipelines: I lavori CI a volte vengono eseguiti con ambiti più ampi del previsto. Xygeni rileva quando CI/CD i lavori richiedono o operano oltre i ruoli assegnati, identificando in tempo reale l'espansione dell'ambito e l'abuso dei privilegi. Ciò aiuta a far rispettare i principi di controllo degli accessi MAC all'interno pipelines legando strettamente l'accesso all'identità e allo scopo del lavoro.
- Applicazione dei controlli di pubblicazione degli artefatti: Se gli sviluppatori continuano a caricare manualmente artefatti o immagini, Xygeni pone fine a questa situazione. Applica un controllo di accesso obbligatorio a livello di registro, in modo che vengano caricati solo i file verificati. pipeline Le identità possono pubblicare artefatti. Niente più caricamenti umani nei registri di produzione.
- Monitoraggio degli accessi e segnalazione delle anomalie: Con Xygeni, ottieni visibilità su chi ha effettuato l'accesso a cosa, quando e come. Traccia costantemente l'utilizzo dei segreti, l'accesso al repository e le interazioni con il registro per rilevare comportamenti insoliti, segnalare configurazioni errate e facilitare l'analisi post-incidente.
Bottom line: Xygeni automatizza e applica le policy di controllo degli accessi, così il tuo ambiente DevOps rimane sicuro senza rallentarti.
Quindi, tratta il controllo degli accessi come Code Security
Chiunque abbia diritti di distribuzione o accesso all'infrastruttura può danneggiare la tua app, accidentalmente o meno. Ecco perché una politica di controllo degli accessi solida come la roccia non è facoltativa. Utilizzare RBAC per delegare correttamente i ruoli. Applicare il controllo di accesso obbligatorio ai sistemi critici. Ignorare completamente il DAC per i percorsi di produzione. Integra le policy di controllo degli accessi nel tuo Le migliori pratiche DevSecOps. Automatizzatele. Monitoratele. Applicatele.
TL; DR: Una politica di controllo degli accessi ben applicata rende automaticamente più sicuri il codice base, gli artefatti e l'infrastruttura.
