Konfiguracja chmury i uprawnienia opisane kodem — sprawdzane, zanim powstaną, nie po incydencie.
Ręczna zmiana „na szybko” nadal jest możliwa — ale przestaje być niewidoczna.
Tak wygląda punkt wyjścia w wielu firmach, które dowożą szybko i podlegają regulacjom.
Środowisko w chmurze rozrasta się szybciej, niż ktokolwiek je dokumentuje. Uprawnienia nadaje się „na teraz" i nikt ich nie odbiera. Zasób wystawiony omyłkowo do internetu wygląda w konsoli identycznie jak każdy inny.
Zakres ustalamy po diagnozie — zaczynamy od elementu, który najszybciej obniży Wasze ryzyko.
Zmiana w chmurze przechodzi przez recenzję jak kod.
Zaczynamy od przeglądu tożsamości i uprawnień — łącznie z kontami usług, o których zwykle nikt nie pamięta. Konfigurację środowiska przenosimy do kodu, dzięki czemu każda zmiana ma autora, uzasadnienie i możliwość cofnięcia. Sprawdzanie wpinamy przed uruchomieniem zasobu, więc błędna konfiguracja zatrzymuje się na etapie propozycji, a nie wychodzi przy audycie pół roku później. Do tego pilnujemy odchyleń od stanu zatwierdzonego, bo ręczna zmiana „na szybko" zdarza się w każdej organizacji.
Po każdym etapie zostaje u Was konkretny rezultat, a nie notatka ze spotkania.
Kto i co może zrobić w Waszym środowisku — łącznie z kontami usług.
RezultatMapa tożsamości i uprawnień, łącznie z zapomnianymi kontami usług
Konfiguracja chmury przechodzi przez recenzję jak każda inna zmiana.
RezultatKonfiguracja środowiska w kodzie: każda zmiana ma autora i da się ją cofnąć
Błędna konfiguracja zatrzymuje się na etapie propozycji, nie po wdrożeniu.
RezultatKontrole, które zatrzymują błędną konfigurację przed uruchomieniem
Odchylenie od zatwierdzonej konfiguracji wychodzi automatycznie, nie przy kolejnym audycie.
RezultatAutomatyczny sygnał przy odchyleniu od zatwierdzonego stanu
Wdrożenie kończy się działającą konfiguracją i dowodami, a nie raportem z listą zaleceń. Tak to wygląda na przykładzie.
# zasób nie wyjdzie publicznie, nawet przez pomyłkę
resource "aws_s3_bucket_public_access_block" "raporty" {
bucket = aws_s3_bucket.raporty.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}Ustawienie przechodzi przez recenzję i nie znika przy kolejnej zmianie.
| Tożsamość | Ma | Decyzja |
|---|---|---|
konto usługi ci-legacy | administrator | odebrać |
rola deploy | zapis we wszystkich kontach | zawęzić do jednego |
| były pracownik | aktywny klucz dostępu | wyłączyć |
Uprawnienia przestają się kumulować, bo ktoś regularnie je przegląda.
sg-apiRęczna zmiana wychodzi tego samego dnia, a nie przy audycie.
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.