Proces budowania i wdrażania ma dostęp do wszystkiego. Zabezpieczamy go tak, żeby przestał być najkrótszą drogą do Waszej produkcji.
Każde wdrożenie przechodzi te same kontrole — bez wyjątków „na szybko”.
Tak wygląda punkt wyjścia w wielu firmach, które dowożą szybko i podlegają regulacjom.
Pipeline zna klucze do chmury, do repozytoriów i do serwerów produkcyjnych. Zwykle powstawał latami, dorzucany po kawałku, i nikt nie wie już, kto ma do niego dostęp ani co dokładnie robi. Przejęcie go daje więcej niż włamanie do pojedynczej aplikacji.
Zakres ustalamy po diagnozie — zaczynamy od elementu, który najszybciej obniży Wasze ryzyko.
Porządkujemy to, co ma klucze do wszystkiego.
Najpierw ustalamy, kto może uruchomić wdrożenie, kto zatwierdza zmianę i co przechodzi bez akceptacji — zwykle okazuje się, że więcej osób i procesów niż ktokolwiek zakładał. Klucze wpisane na stałe w konfigurację zastępujemy dostępem przyznawanym na czas jednego uruchomienia, więc wyciek pliku przestaje oznaczać wyciek produkcji. Środowisko budowania izolujemy i kontrolujemy, co do niego wchodzi z zewnątrz. Włączamy rejestrowanie tak, żeby po każdym wdrożeniu został ślad: kto, kiedy i na podstawie jakiej zmiany.
Po każdym etapie zostaje u Was konkretny rezultat, a nie notatka ze spotkania.
Kto może uruchomić wdrożenie, kto zatwierdzić zmianę, co dzieje się bez akceptacji.
RezultatMapa uprawnień: kto może wdrożyć, kto zatwierdza, co przechodzi bez akceptacji
Klucze na stałe wpisane w konfigurację zastępujemy dostępem przyznawanym na czas jednego uruchomienia.
RezultatPipeline bez stałych kluczy — dostęp ważny tylko na czas uruchomienia
Izolacja, kontrola zależności zewnętrznych i weryfikacja tego, co wchodzi do procesu.
RezultatIzolowane środowisko budowania z kontrolą tego, co do niego wchodzi
Ślad po każdym wdrożeniu — kto, kiedy, na podstawie jakiej zmiany.
RezultatŚlad po każdym wdrożeniu, gotowy do pokazania audytorowi
Wdrożenie kończy się działającą konfiguracją i dowodami, a nie raportem z listą zaleceń. Tak to wygląda na przykładzie.
permissions:
id-token: write # krótkotrwały token OIDC
contents: read
jobs:
deploy:
environment: produkcja # wymaga akceptacji
runs-on: ubuntu-latest
steps:
- uses: aws-actions/configure-aws-credentials@<SHA>
with:
role-to-assume: arn:aws:iam::123456789012:role/deploy
aws-region: eu-central-1Wyciek pliku konfiguracyjnego nie daje już nikomu dostępu do chmury.
| Kto | Może | Wymaga |
|---|---|---|
| Developer | otworzyć zmianę | recenzji |
| Maintainer | scalić do main | 2 akceptacji |
| Pipeline | wdrożyć na produkcję | akceptacji w środowisku |
| Bot zależności | otworzyć zmianę | recenzji, bez scalania |
Wiadomo, kto co może — także konta techniczne, o których zwykle nikt nie pamięta.
Na pytanie „kto to wdrożył” odpowiedź jest w logu, nie w pamięci zespołu.
Ilustracja. Zakres i narzędzia dobieramy po diagnozie.
Zakres ustalamy po rozmowie i diagnozie. Mniejsze wdrożenia zamykają się w kilku tygodniach, większe dzielimy na etapy, żeby efekt był widoczny po pierwszym.
Zwykle nie do całego. W większości przypadków wystarczy dostęp do konfiguracji procesu budowania i ustawień organizacji. Zakres ustalamy pisemnie przed startem.
Tak, ale nie na pełen etat. Potrzebujemy kontaktu z osobą, która zna system, i przeglądu naszych zmian. Reszta jest po naszej stronie.
Wpinamy się w to, co u Was działa. Wymiana narzędzia to najdroższy i najrzadziej potrzebny sposób poprawy bezpieczeństwa.
Nie. Pracujemy na standardach i narzędziach, które Wasz zespół zna albo szybko pozna — nie na autorskiej metodyce, którą rozumiemy wyłącznie my. Wszystko jest udokumentowane i przekazane.
Tak wpinamy kontrole, żeby działały w tle. Jeśli któraś zaczyna blokować pracę, dostrajamy ją albo zmieniamy jej miejsce w procesie.