Zasada najmniejszych uprawnień, egzekwowana w diffie.
CC6.1 to jedno z kryteriów Trust Services Criteria, które zwykły pull request może cicho osłabić, ponieważ dotyczy logicznego dostępu, a ten często znajduje się w kodzie i konfiguracji. Kryterium wymaga, aby dostęp do systemów i danych był ograniczony do użytkowników i procesów, które są uprawnione do jego posiadania. W praktyce oznacza to zasadę najmniejszych uprawnień: rola może uzyskać dostęp do tego, czego potrzebuje do wykonywania swoich zadań, i nic więcej.
The shapes the same control failure takes.
CC6.1 rzadko ulega złamaniu przez wiersz, który mówi „przyznaj wszystkim uprawnienia administratora”. Zazwyczaj dzieje się to w zwykłych, wyglądających na rozsądne zmianach. To formy, które powtarzają się najczęściej.
Zasady dostępu są poszerzane
Rola IAM, grupa zabezpieczeń lub uprawnienie zyskuje szersze działania lub symbol wieloznaczny, dzięki czemu komponent może teraz robić więcej, niż wymaga jego zadanie.
Sprawdzenie autoryzacji zostaje usunięte
Trasa traci sprawdzenie roli lub własności, albo middleware autoryzacyjny przestaje być stosowany do nowego punktu końcowego, więc żądanie, które powinno zostać odrzucone, teraz się powiedzie.
Uprawnienia do danych zostają rozszerzone
Rola bazy danych zyskuje dostęp do tabel lub wierszy, do których wcześniej nie miała dostępu, zabezpieczenia na poziomie wiersza są poluzowane, albo konto usługi jest skierowane do bazy danych, do której nie miało powodu dotrzeć.
Domyślne ustawienie zmienia się na zezwolenie
Dostęp zmienia się z domyślnego odrzucenia na domyślne zezwolenie: nowy zasób jest udostępniany do odczytu dla wszystkich, albo sprawdzenie uprawnień domyślnie zwraca true dla nieznanego przypadku.
Otwiera się ścieżka eskalacji uprawnień
Aktor o niższych uprawnieniach zyskuje sposób działania jako ten o wyższych uprawnieniach: wewnętrzna flaga, która omija sprawdzenie roli, albo token wygenerowany z większym zakresem, niż posiada wywołujący.
Refaktoryzacja, która usuwa sprawdzenie autoryzacji.
Trasa jest porządkowana. Sprawdzenie roli w środku wydaje się zbędne obok middleware autoryzacyjnego, więc zostaje usunięte. Punkt końcowy nadal wymaga zalogowanego użytkownika, ale nie wymaga już odpowiedniego: teraz każdy uwierzytelniony użytkownik może usunąć dowolny projekt.
- router.delete("/projects/:id", requireRole("admin"),- loadProject, deleteProject)+ router.delete("/projects/:id", loadProject, deleteProject)Usunięcie sprawdzenia roli z destrukcyjnego punktu końcowego. Middleware autoryzacyjny potwierdza, że wywołujący jest zalogowany, ale CC6.1 dotyczy tego, czy jest on uprawniony do tej akcji, a usuwanie dowolnego projektu nie jest czymś, co każdy użytkownik powinien móc robić. Przywróć sprawdzenie autoryzacji (sprawdzenie roli lub własności projektu) przed handlerem.
CC6.1 jest sprawdzane na podstawie próbek, a nie jedynie deklarowane.
W badaniu SOC 2 kryterium CC6.1 nie jest spełnione jedynie przez dokument polityki stwierdzający, że stosujesz zasadę najmniejszych uprawnień. Audytor sprawdza rzeczywisty dostęp: kto i co może dotrzeć do danego systemu, czy te uprawnienia odpowiadają udokumentowanym rolom oraz czy cokolwiek jest szersze, niż wymaga to jego cel. Rola z symbolami wieloznacznymi, punkt końcowy bez sprawdzenia autoryzacji lub konto usługi z ciągłym dostępem, którego nigdy nie używa, to dokładnie rodzaj wyjątków, które stają się ustaleniami, i zwykle trafiły do systemu w jednym pull request kilka miesięcy wcześniej. Wychwycenie zmiany w diffie pomaga utrzymać te wyjątki dostępu poza próbką.
Przegląd, a nie potwierdzenie.
heygrc sygnalizuje zmiany, które dotyczą CC6.1, i cytuje kryterium, aby naprawa nastąpiła w pull request. Nie przeprowadza audytu ani nie wydaje opinii. Wychwytuje zmianę dostępu na wczesnym etapie, aby badanie miało mniej wyjątków do wyjaśnienia.