Jakiej polityki kontroli dostępu potrzebujesz?

Dlaczego programiści potrzebują prawdziwych zasad kontroli dostępu (a nie tylko teorii)

Jeśli wprowadzasz kod, utrzymujesz pipelines, czy zarządzanie rejestrami artefaktów, potrzebujesz czegoś więcej niż teorii. Słabe lub niezdefiniowane zasady kontroli dostępu sprzyjają manipulacjom w repozytoriach. CI/CD nadużycie i wycieki danych uwierzytelniającychDevSecOps wymaga rzeczywistego egzekwowania zasad, a nie tylko ukrytych ustawień uprawnień.

Aby skutecznie zarządzać zasadami kontroli dostępu w repozytoriach kodu, CI/CD pipelinesi rejestrów artefaktów, wiele zespołów korzysta z narzędzi automatycznego egzekwowania, takich jak Xygeni. Poprzez ciągłe monitorowanie ról, uprawnień i przestrzegania zasad, Xygeni pomaga zapobiegać dryfowaniu uprawnień, nieautoryzowanemu dostępowi i ręcznym obejściu, przekształcając teorię obowiązkowej kontroli dostępu w praktykę.

Kontrola dostępu bezpośrednio blokuje kod źródłowy, zabezpiecza kompilacje i chroni produkcję pipelineJeśli programiści omijają mechanizmy kontroli lub konta usług mają szerokie uprawnienia, otwierasz drzwi do naruszeń bezpieczeństwa. Dlatego zrozumienie obowiązkowej kontroli dostępu, kontroli dostępu MAC i innych modeli jest kluczowe.

Rodzaje zasad kontroli dostępu, które powinni znać programiści

Zasady kontroli dostępu dzielą się na trzy główne kategorie, z których każda ma inne zastosowanie CI/CD przepływy pracy. Oto krótkie zestawienie, które to wyjaśnia:

Model	Kto kontroluje dostęp?	Typowe zastosowanie w CI/CD	Poziom ryzyka
DAC (Kontrola dostępu dyskrecjonalnego)	Właściciel zasobu (programista, administrator)	Ręczne udostępnianie repozytorium lub dostępu do rejestru	Wysoki (błąd ludzki)
RBAC (kontrola dostępu oparta na rolach)	System przypisuje uprawnienia według roli	Ochrona gałęzi GitHub, dostęp do zadań CI na podstawie ról użytkownika	Średni (błędnie skonfigurowane role)
MAC (obowiązkowa kontrola dostępu)	Wymuszone przez politykę systemową	Egzekwuje, kto może publikować artefakty lub wdrażać kod	Niski (zasady mają pierwszeństwo przed intencjami użytkownika)

Wyjaśnienie MAC vs. RBAC w CI/CD Kontekst

Łatwo pomylić kontrolę dostępu opartą na rolach (RBAC) z obowiązkową kontrolą dostępu (kontrola dostępu MAC), szczególnie w CI/CD środowiska. Chwila CI/CD Platformy takie jak GitHub i GitLab używają RBAC do zarządzania rolami i uprawnieniami (np. kto może scalać lub wdrażać), jednak jest to nadal mechanizm oparty na rolach, a nie prawdziwa kontrola dostępu MAC.

Kontrola dostępu na podstawie ról (RBAC) pozwala na przypisywanie uprawnień na podstawie ról (programista, konserwator itp.), ale uprawnienia te nadal są kontrolowane przez użytkownika i można je modyfikować. Błędy w konfiguracji lub rozrost uprawnień to częste zagrożenia.

Obowiązkowa kontrola dostępu (kontrola dostępu MAC) jest natomiast egzekwowana na poziomie systemu lub infrastruktury. Użytkownicy, w tym administratorzy, nie mogą jej obejść. Kontrolę dostępu do komputerów Mac można porównać do zasad wbudowanych w platformę: zasad IAM u dostawców chmury (np. AWS IAM, GCP IAM) lub narzędzi wymuszających na poziomie systemu operacyjnego, takich jak SELinux czy AppArmor. W takich przypadkach dostęp jest przyznawany tylko wtedy, gdy spełnione są predefiniowane, niemożliwe do obejścia reguły.

In CI/CDWiele narzędzi symuluje zachowanie kontroli dostępu MAC poprzez ściśle określone role IAM lub uprawnienia specyficzne dla zasobów, ale nie jest to pełna, obowiązkowa kontrola dostępu. Prawdziwe, obowiązkowe egzekwowanie kontroli dostępu wymaga kontroli poniżej warstwy aplikacji, na poziomie systemu operacyjnego, sieci lub infrastruktury chmurowej, gdzie dostęp jest regulowany przez niezmienne zasady kontroli dostępu, a nie przez konfigurację użytkownika.

Kontrola dostępu oparta na rolach (RBAC)

Kontrola dostępu na podstawie ról (RBAC) mapuje uprawnienia na zdefiniowane role, takie jak „programista”, „opiekun” czy „menedżer wydań”. Ułatwia to zarządzanie w narzędziach takich jak GitHub i GitLabZamiast konfigurować ustawienia dla każdego użytkownika z osobna, przypisz mu rolę i pozwól systemowi egzekwować reguły.

Przykład: Plik CODEOWNERS GitHub

				
					# CODEOWNERS
/docs/ @doc-team
/scripts/ @devops-team
/main.py @maintainers

Dzięki temu mamy pewność, że zmiany w kluczowych katalogach będą mogły być zatwierdzane wyłącznie przez osoby posiadające przypisane role.

Ustawienia roli GitLab: Skonfiguruj dostęp do projektu w Ustawieniach > Członkowie:

Deweloper: Można wypchnąć do gałęzi wyróżnionych.
Opiekun: Można łączyć z gałęziami chronionymi.
Gość: Dostęp tylko do odczytu.

Przykład przepływu pracy RBAC w 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

Obowiązkowa kontrola dostępu (MAC)

Obowiązkowa kontrola dostępu (kontrola dostępu MAC) wymusza ścisłe reguły na poziomie systemu, których użytkownicy i administratorzy nie mogą ignorować. Użyj kontroli dostępu Mac aby ściśle kontrolować, kto może odczytywać, zapisywać i wykonywać krytyczne zasoby.

Przykład: Zasady rejestru artefaktów Google (uproszczony plik YAML)

				
					yaml
bindings:
  - role: roles/artifactregistry.writer
    members:
      - serviceAccount:ci-deployer@project.iam.gserviceaccount.com

Ta polityka przyznaje uprawnienia do zapisu wyłącznie kontu usługi ci-deployer, zapewniając, że tylko zadania CI z tą tożsamością będą mogły przesyłać artefakty.

Przykład: Zasady Amazon ECR (uproszczony plik YAML)

				
					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

Ta polityka zabrania wykonywania jakichkolwiek działań PutImage w repozytorium ECR, chyba że zostaną one wykonane przez konto usługi ci-service. Ogranicza ona przesyłanie obrazów wyłącznie do tego konta usługi.

Ryzyko związane z ręcznym nadpisywaniem i jak MAC mu zapobiega

Jednym z największych ryzyk związanych z RBAC i Modele DAC Istnieje ryzyko celowego lub przypadkowego ręcznego obejścia zabezpieczeń. Na przykład administrator lub programista może bezpośrednio przesłać artefakty do chronionego rejestru lub przyznać nadmierne uprawnienia poza zdefiniowanymi zasadami kontroli dostępu. Działania te mogą prowadzić do luk w zabezpieczeniach lub powodować luki w zgodności.

Obowiązkowa kontrola dostępu (kontrola dostępu MAC) zapobiega takim obejściu, wymuszając zasady na poziomie systemu, których żaden użytkownik, nawet administrator, nie może ominąć.cisJony są regulowane przez niezmienne reguły wbudowane w infrastrukturę (takie jak zasady IAM w chmurze lub moduły bezpieczeństwa na poziomie systemu operacyjnego). Oznacza to:

Administrator nie może ręcznie przesłać artefaktów do rejestru, jeśli zasady kontroli dostępu Mac je blokują.
Użytkownicy nie mogą rozszerzać uprawnień ani zmieniać uprawnień poza zakresem zdefiniowanych zasad kontroli dostępu.
zautomatyzowane CI/CD pipelinedziałają ściśle w ramach przypisanych im uprawnień, zapobiegając rozrostowi zakresu.

Eliminując konieczność ręcznego obejścia kontroli dostępu, obowiązkowa kontrola dostępu zapewnia silniejsze i bardziej niezawodne zabezpieczenia niż w przypadku stosowania wyłącznie RBAC lub DAC.

2.4 Dyskrecjonalna kontrola dostępu (DAC)

DAC pozwala właścicielom zasobów ręcznie przypisywać uprawnienia. Jest elastyczny, ale ryzykowny. Jeden niewłaściwy udział może zagrozić repozytorium. DAC działa na zasadzie: „Ty jesteś właścicielem, ty decydujesz, kto ma do niego dostęp”.

Przykład: Dev zaprasza zewnętrznego współpracownika i przyznaje mu uprawnienia do zapisu w repozytorium. Współpracownik przesyła niezabezpieczony kod bezpośrednio do dev gałąź.

In CI/CDDAC może wyglądać tak, jakby deweloper ręcznie przyznał tymczasowemu członkowi zespołu dostęp do wdrożenia produkcyjnego za pośrednictwem konsoli, poza jakąkolwiek zdefiniowaną polityką kontroli dostępu.

Jak wybrać politykę kontroli dostępu, która sprawdzi się w praktyce Pipelines

Kontrola dostępu w Git

Wykorzystaj RBAC do zarządzania rolami współtwórcy, opiekuna i wydania. Zablokuj prawa scalania do chronionych gałęzi. Wymagaj podpisu. commiti ograniczyć, kto może ominąć zabezpieczenia.

Przykład: Zasady ochrony gałęzi GitHub

Wymagać pull request recenzje przed połączeniem.
Odrzuć nieaktualne pull request zatwierdzenia, gdy nowe commits są popychane.
Wymagaj podpisu commits.
Pomiń DAC w przypadku repozytoriów krytycznych dla produkcji. Nie udzielaj uprawnień do zapisu pochopnie.

Pipeline Egzekwowanie

Wprowadź obowiązkową kontrolę dostępu dla pipelines. Solidny model kontroli dostępu na komputerach Mac ogranicza zadania CI wyłącznie do niezbędnych uprawnień.

Sekrety należy oddzielić ze względu na środowisko.
Użyj unikalnych tokenów dla każdego środowiska.
Zapobiegaj wpływowi operacji ręcznych na produkcję.

Przykład: Zadanie CI ponownie wykorzystuje token wdrożenia w środowisku przejściowym i produkcyjnym, co powoduje przypadkowe przesłanie kodu testowego do środowiska produkcyjnego.

Dodaj reguły kontroli dostępu Mac do zakresu tokena sterującego:

				
					yaml
env:
  DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN_PROD }}
if: github.ref == 'refs/heads/main' && github.actor == 'release-manager'

Przykład zakresu sekretów: użycie tokenów specyficzne dla środowiska

Prawidłowe określenie zakresu sekretów według środowiska ma kluczowe znaczenie zapobiegać przypadkowemu lub złośliwemu dostępowi między środowiskami. Na przykład token wdrożenia dla środowiska programistycznego nigdy nie powinien nadawać się do wdrożenia w środowisku produkcyjnym.

Oto w jaki sposób kontrole oparte na zasadach kontroli dostępu izolują użycie tajnych informacji w akcjach GitHub:

				
					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 }}

To wymusza, że:

Tylko wywoływacz rola może wyzwalać wdrożenia za pomocą tokena deweloperskiego na dev gałąź.
Tylko menedżer wydań rolę można wdrożyć do produkcji, używając tokena prod na główny gałąź.

Takie ograniczone wykorzystanie tajnych informacji zmniejsza ryzyko eskalacji wycieków tokenów w różnych środowiskach i egzekwuje najmniejsze uprawnienia w CI/CD pipelines przestrzegając rygorystycznych zasad kontroli dostępu.

Kontrola dostępu do artefaktów

Zablokuj rejestry artefaktów, stosując obowiązkową kontrolę dostępu. CI/CD Publikowaniem powinny zajmować się systemy, a nie poszczególni programiści.

Użyj RBAC, aby zdefiniować, które zespoły pobierają dane z konkretnych rejestrów. Deweloperzy mogą potrzebować jedynie dostępu do odczytu pakietów produkcyjnych.

				
					json
{
  "rules": [
    {
      "action": "read",
      "resource": "npm-package:internal/*",
      "allowed_roles": ["developer", "qa"]
    },
    {
      "action": "write",
      "resource": "npm-package:internal/*",
      "allowed_principals": ["ci-pipeline"]
    }
  ]
}

Typowe błędy kontroli dostępu w procesach pracy programistów

Zbyt dozwolony dostęp do repozytorium

Problem: Udzielanie zbyt wielu użytkownikom uprawnień zapisu/administrowania do repozytoriów.
Jak to się dzieje: Członkowie zespołu są awansowani lub dodawani bez weryfikacji uprawnień. Role stają się rozdęte.
Wykorzystanie luk przez atakującego: Atakujący atakują te konta, wykorzystując skradzione dane uwierzytelniające lub socjotechnikę. Po włamaniu mogą wstrzyknąć złośliwy kod, wprowadzić tylne furtki lub usunąć historię, aby ukryć ślady.

Wspólne uprawnienia między środowiskiem deweloperskim i produkcyjnym

Problem: Umożliwienie rozwoju i produkcji pipelines udostępnia uprawnienia.
Jak to się dzieje: Zespoły wykorzystują ten sam token wdrażania lub konto usługi CI w różnych środowiskach.
Wykorzystanie luk przez atakującego: Naruszenie środowiska programistycznego umożliwia atakującym dostęp do środowiska produkcyjnego. Obowiązkowa kontrola dostępu można temu zapobiec poprzez powiązanie uprawnień z konkretnymi środowiskami.

Ręczne przesyłanie artefaktów

Problem: Zezwalanie na ręczne przesyłanie artefaktów do rejestrów produkcyjnych.
Jak to się dzieje: Deweloperzy omijają pipelines dla szybkich poprawek lub gorących łatek.
Wykorzystanie luk przez atakującego: Zainfekowane komputery programistów mogą przesyłać złośliwe oprogramowanie bezpośrednio do magazynu artefaktów, omijając wszelkie CI/CD kontrole bezpieczeństwa.

Ryzyko nadużycia zasad rejestru: Ręczne publikowanie artefaktów tworzy krytyczną powierzchnię ataku w łańcuchu dostaw oprogramowania. Atakujący wykorzystujący luźną zasady kontroli dostępu mogą wstawiać złośliwy kod do zaufanych pakietów lub obrazów kontenerów, prowadząc do powszechnego naruszenia bezpieczeństwa w dół łańcucha dostaw. Niedawne incydenty w łańcuchu dostaw oprogramowania pokazały, jak nieuregulowane przesyłanie artefaktów może szybko przerodzić się w poważne naruszenia bezpieczeństwa, dotykające niezliczonej liczby użytkowników i systemów.

Przykład: aStażysta z pełnym dostępem do rejestru npm przez pomyłkę publikuje niestabilną wersję. Gdyby atakujący włamał się na komputer tego stażysty, mógłby opublikować złośliwe oprogramowanie.

Praktyczne kroki w celu egzekwowania silnych kontroli dostępu

Przypisz role do dokładnych uprawnień, zrezygnuj z konfiguracji „jedna rola dla wszystkich”
Zautomatyzuj sprawdzanie zasad kontroli dostępu w swoim CI/CD pipelines
Zablokuj rejestry, wprowadzając obowiązkową kontrolę dostępu
Ciągłe rejestrowanie i monitorowanie dostępu do systemów krytycznych
Traktuj zasady kontroli dostępu jak kod. Każdy błąd może zostać wykorzystany.

Rola Xygeni: egzekwowanie i monitorowanie zasad dostępu w przepływach pracy DevOps

Xygeni pomaga przekształcić obowiązkową kontrolę dostępu z teorii w praktykę, rozwiązując rzeczywiste, codzienne problemy związane z egzekwowaniem zasad kontroli dostępu w DevSecOps pipelines.

Rozwiązywanie problemu nadmiernego dostępu do Gita: Xygeni stale monitoruje repozytoria Git pod kątem naruszeń RBAC, takich jak nieprzejrzane przypisania ról czy brakujące zabezpieczenia gałęzi. Wysyła alerty, gdy zasady kontroli dostępu odbiegają od zdefiniowanych reguł i egzekwuje działania korygujące, aby uniknąć przypadkowych fuzji lub złośliwych żądań dostępu.
Blokowanie CI/CD Pipelines: Zadania CI czasami działają w szerszym zakresie niż zamierzony. Xygeni wykrywa, kiedy CI/CD Zlecają zadania lub działają poza przypisanymi im rolami, identyfikując w czasie rzeczywistym rozrost zakresu zadań i nadużycia uprawnień. Pomaga to egzekwować zasady kontroli dostępu MAC w pipelinepoprzez ścisłe powiązanie dostępu z tożsamością i celem danego zadania.
Egzekwowanie kontroli publikacji artefaktów: Jeśli programiści nadal będą ręcznie przesyłać artefakty lub obrazy, Xygeni położy temu kres. Stosuje obowiązkową kontrolę dostępu na poziomie rejestru, aby tylko zweryfikowane pipeline Tożsamości mogą publikować artefakty. Koniec z przesyłaniem danych przez ludzi do rejestrów produkcyjnych.
Monitorowanie dostępu i sygnalizowanie anomalii: Dzięki Xygeni zyskujesz wgląd w to, kto, kiedy i jak uzyskał dostęp do czego. System stale śledzi wykorzystanie sekretów, dostęp do repozytoriów i interakcje z rejestrem, aby wykrywać nietypowe zachowania, sygnalizować błędy konfiguracji i pomagać w analizie poincydentów.

Podsumowując: Xygeni automatyzuje i egzekwowanie zasad kontroli dostępu, dzięki czemu środowisko DevOps pozostaje bezpieczne, nie spowalniając go.

Jakiej polityki kontroli dostępu potrzebujesz? Wyjaśnijmy to.

Posty, które musisz przeczytać