Gdy traktujesz compliance jako coś, co żyje w kodzie, pojawia się pytanie: które zmiany naprawdę łamią kontrolę? Nie w teorii, ale w diffie. Nie mamy jeszcze telemetrii produkcyjnej, aby na to odpowiedzieć, więc to nie jest wykres tego, co widzieliśmy w praktyce. To taksonomia, którą zbudowaliśmy heygrc, aby złapać: pięć wzorców pull request, które z konstrukcji najbardziej bezpośrednio łamią kontrolę.
Co je łączy, jest niewygodne. Żaden nie wygląda jak zmiana compliance. Każdy to rozsądna edycja, sprzątanie, odblokowanie, wygoda, która przypadkiem usuwa rzecz, od której zależał framework. Oto one.
1. Tajemnica w konfiguracji
Najszybszy sposób na uruchomienie integracji to umieszczenie klucza tam, gdzie kod może go odczytać bezpośrednio. Działa za pierwszym razem, ale zapisuje aktywny poświadczenie w repozytorium, jego historii oraz w każdym klonie i pamięci podręcznej CI, które je kiedykolwiek pobierze. Po zatwierdzeniu tajemnica staje się narażona, a jedyną bezpieczną reakcją jest jej rotacja.
- const key = process.env.PAYMENTS_SECRET_KEY+ const key = "<the live key, pasted inline>"const client = new Payments(key)Poświadczenie znajduje się teraz w kontroli wersji i jest dostępne dla każdego, kto ma dostęp do repozytorium, teraz lub w przyszłości. Odczytaj je z zarządzanego magazynu tajemnic i zrotuj to, które zostało zatwierdzone.
2. Poluzowane uwierzytelnianie
Sprawdzenie autoryzacji blokuje zmianę, więc jest usuwane lub rozszerzane do symbolu wieloznacznego, aby odblokować wywołującego. Funkcja działa potem dla wszystkich, w tym dla osób, których sprawdzenie miało wykluczać.
export async function getReport(user, id) {- if (!user.can("reports:read")) return forbidden() return reports.find(id)}Usunięcie sprawdzenia pozwala dowolnemu uwierzytelnionemu wywołującemu odczytać dowolny raport, a nie tylko te, do których ma uprawnienia. Przywróć sprawdzenie autoryzacji zamiast omijać je.
3. Wyłączona rejestracja
Linia dziennika jest hałaśliwa, więc trafiła do czyszczenia. System nadal działa; po prostu przestaje rejestrować zdarzenie bezpieczeństwa, które audytor później sprawdzi, a które chciałbyś mieć po incydencie.
async function onLogin(userId, ip) {- await audit.log("auth.login", { userId, ip }) return startSession(userId)}Zdarzenie logowania nie jest już rejestrowane, więc nie może być monitorowane ani odtwarzane później. Zachowaj dziennik; jeśli jest zbyt hałaśliwy, zmień jego poziom lub miejsce docelowe zamiast go usuwać.
4. Poszerzone reguły sieciowe
Usługa nie może połączyć się z bazą danych, więc otwierana jest reguła grupy zabezpieczeń, aby połączenie działało. Działa, a teraz działają także wszystkie inne połączenia w zasięgu, w tym te pochodzące z otwartego internetu.
ingress { from_port = 5432- cidr_blocks = ["10.0.0.0/16"]+ cidr_blocks = ["0.0.0.0/0"]}Otwarcie reguły na 0.0.0.0/0 naraża port bazy danych na cały internet, a nie tylko na usługę, która go potrzebuje. Ogranicz regułę do źródła, które wymaga dostępu.
5. Dropped encryption
Szyfrowanie nie działa w środowisku staging, więc najszybszym rozwiązaniem jest zaprzestanie jego weryfikacji, a zmiana zostaje wdrożona. Dane, które powinny być przesyłane uwierzytelnione i zaszyfrowane, teraz są przesyłane w sposób, który może zostać odczytany lub zmieniony podczas transmisji.
const agent = new https.Agent({+ rejectUnauthorized: false,})Wyłączenie weryfikacji certyfikatu oznacza, że połączenie nie jest już uwierzytelnione, więc może zostać przechwycone przez atak man in the middle. Zachowaj weryfikację i napraw certyfikat w środowisku staging zamiast tego.
Dlaczego te pięć
Wzór dla wszystkich pięciu jest taki sam: zmiana, która poprawia jedną rzecz, działająca integracja, odblokowany wywołujący, czystsze wyjście, dostępna baza danych, zielony test na stagingu, cicho usuwa zabezpieczenie, od którego zależy framework. Uszkodzenie zgodności jest efektem ubocznym rozsądnego celu, dlatego ani autor, ani zwykła recenzja tego nie wychwytuje. Nikt nie zamierzał osłabić kontroli.
Dlatego warto przeglądać diff w odniesieniu do kontroli w momencie wprowadzania zmiany. Zaczynamy od tych pięciu, ponieważ są najbardziej bezpośrednie: każda z nich wyraźnie odpowiada klauzuli, a każda jest widoczna w samej zmianie. Prawdziwy rozkład poznamy, gdy heygrc będzie działał na prawdziwych pull requestach. Do tego czasu to mapa, a nie terytorium, i wolelibyśmy to przyznać.