Trzymanie testów z dala od produkcji.
ISO 27001:2022 A.8.31 (oddzielenie środowisk developerskich, testowych i produkcyjnych) wymaga, aby te środowiska były od siebie izolowane, tak aby prace w developerskim lub testowym nie mogły dotrzeć, zmienić ani narazić środowiska produkcyjnego. Wiele z tych granic jest zdefiniowanych w konfiguracji: łańcuchy połączeń, zmienne środowiskowe, skrypty seed i fixture oraz potoki CI. Oznacza to, że pojedyncza zmiana w pliku konfiguracyjnym może cicho naruszyć tę granicę.
The shapes the same control failure takes.
A.8.31 słabnie, gdy ścieżka nietestowa zyskuje dostęp do produkcji lub gdy dane i poświadczenia produkcyjne wyciekają do niższych środowisk. Powtarzające się schematy:
Konfiguracja testowa wskazuje na produkcję
URL bazy danych, endpoint lub konfiguracja testowa lub CI jest ustawiona na zasób produkcyjny, więc uruchomienie testów odczytuje lub zapisuje prawdziwe dane.
Sekrety produkcyjne trafiają do niższych środowisk
Konfiguracja stagingowa lub developerska otrzymuje poświadczenia, klucze lub endpointy produkcyjne, co powoduje załamanie granicy w momencie, gdy to środowisko jest mniej chronione.
Usunięta ochrona przed dostępem międzyśrodowiskowym
Sprawdzenie środowiska, które uniemożliwiało uruchomienie operacji niszczących, seed lub reset poza dedykowanym środowiskiem, zostaje usunięte, więc teraz może zostać uruchomione przeciwko produkcji.
Fixtury lub dane seed uzyskują dostęp do produkcji
Skrypt seed, fixture lub migracji, który odtwarza lub usuwa dane, zyskuje dostęp do bazy produkcyjnej zamiast do izolowanej.
Środowiska dzielą wspólne miejsce przechowywania
Cache, bucket lub kolejka są podłączone tak, że developerskie lub testowe i produkcyjne odczytują i zapisują do tego samego miejsca, więc aktywność nietestowa może wpływać na dane produkcyjne.
Zestaw testów end-to-end skierowany na bazę produkcyjną.
Zestaw testów end-to-end wymaga bazy danych do uruchomienia. Dedykowana baza testowa jest pusta, a testy ciągle kończą się niepowodzeniem z powodu brakujących danych, więc konfiguracja zostaje skierowana na łańcuch połączeń produkcyjnych, aby testować na prawdziwych danych. Zestaw przycina i ponowie wypełnia tabele przy każdym uruchomieniu, a teraz robi to na produkcji.
- const TEST_DB = process.env.TEST_DATABASE_URL+ const TEST_DB = process.env.DATABASE_URL // prod, to test against real dataawait db.connect(TEST_DB)await resetAndSeed(db) // truncates tables before each runTo kieruje zestaw testów end-to-end, który przycina i ponowie wypełnia tabele w bazie produkcyjnej, więc uruchomienie testów może usunąć i nadpisać dane produkcyjne. A.8.31 wymaga, aby środowiska developerskie, testowe i produkcyjne były od siebie oddzielone, tak aby aktywność nietestowa nie mogła dotrzeć do produkcji. Przywróć dedykowaną bazę testową i załadowaj tam brakujące fixtury zamiast korzystać z produkcji, oraz zachowaj granicę, aby uruchomienie testów nigdy nie mogło zapisywać do danych produkcyjnych.
Separacja jest sprawdzana na granicy, a nie tylko deklarowana.
Auditor szuka dowodów na to, że środowiska są faktycznie oddzielone: że testowe i developerskie nie mogą dotrzeć do danych lub poświadczeń produkcyjnych, a produkcja jest modyfikowana jedynie poprzez kontrolowaną ścieżkę. Konfiguracja testowa podłączona do zasobu produkcyjnego lub niższe środowisko posiadające poświadczenia produkcyjne to rodzaj luki, która przeczy oddzieleniu opisanemu w polityce, i zwykle pojawia się w pojedynczej zmianie w pliku konfiguracyjnym lub setup. To w diffie dochodzi do naruszenia granicy, a najtańsze miejsce, aby to złapać, to właśnie tam.
Przegląd, a nie topologia środowisk.
heygrc sygnalizuje zmiany, które dotyczą A.8.31, i cytuje kontrolę, aby naprawa nastąpiła w pull request. Nie konfiguruje środowisk ani nie przechowuje sekretów. Wychwytuje moment, w którym ścieżka testowa lub developerska dociera do produkcji, w diffie.