Kto ma dostęp do kodu źródłowego, potoku i środowiska produkcyjnego?
Kontrola dostępu w tworzeniu oprogramowania dotyczy pytania, kto może wykonywać jakie działania na którym elemencie Twojej linii produkcyjnej: kto może czytać kod, kto może modyfikować i scalać kod, kto może uruchomić kompilację i kto może wdrożyć wydanie do produkcji. Jest to bardziej szczegółowe pytanie niż kontrola dostępu dla organizacji w ogóle, ponieważ zespół programistów pracuje jednocześnie z wieloma systemami: repozytorium kodu źródłowego, środowiskiem budowania i testowania, oraz zwykle oddzielnym środowiskiem produkcyjnym, gdzie oprogramowanie faktycznie działa.
Powód, dla którego ten temat pojawia się w formularzach oceny bezpieczeństwa i w wymaganiach dotyczących zarządzania ryzykiem Dyrektywy NIS2, polega na tym, że błąd w dostępie do Twojej linii produkcyjnej bezpośrednio wpływa na wszystkich, którzy używają Twojego oprogramowania. Ktoś, kto niezauważenie może modyfikować kod, który następnie jest wdrażany, nie dotyczy tylko Twojej organizacji, ale również Twoich klientów. Dlatego zarówno nadzorca jak i kontrahent, który sam podlega wymogom zarządzania ryzykiem, pytają, jak to zostało u Ciebie zorganizowane.
Dlaczego dotyczy to konkretnie kodu źródłowego i potoku
Zespół programistów zwykle ma więcej osób z szerszymi uprawnieniami niż ściśle konieczne, po prostu dlatego, że praktycznie to działa: wszyscy mogą wszędzie, nikt nie musi na nic czekać. Z perspektywy wymogów zarządzania ryzykiem to jest dokładnie punkt, na którym się углębia. Nie dlatego, że zaufanie byłoby złe, ale dlatego że wykazalność to coś innego niż zaufanie: nadzorca lub kontrahent chce wiedzieć, czy możesz pokazać, kto ma dostęp, a nie tylko czy ci się to wydaje.
Pytania, które się przy tym pojawiają, zazwyczaj dotyczą trzech warstw. Pierwsza to samo repozytorium kodu źródłowego: kto może czytać, kto może modyfikować, i czy istnieje obowiązkowa kontrola zanim zmiana zostanie scalona z wersją główną. Druga to środowisko budowania i testowania: kto może uruchomić kompilację, i czy to środowisko ma dostęp do danych lub systemów, które nie są przeznaczone do celów testowania. Trzecia to środowisko produkcyjne: kto faktycznie może wdrożyć wydanie, i czy jest to inna grupa ludzi niż ci, którzy piszą kod.
Rozdzielenie między pisaniem a wdrażaniem
Powtarzające się rozróżnienie w formularzach to czy osoba, która pisze kod, jest też tą, która wdraża wydanie do produkcji. Gdy jest to ta sama osoba, bez pośredniego kroku innej osoby, powstaje sytuacja, w której błąd lub złośliwa zmiana trafia do produkcji niezauważona. Wiele organizacji rozwiązuje to poprzez obowiązkową drugą kontrolę zanim kod zostanie scalony, i poprzez oddzielną rolę lub oddzielne uprawnienia do faktycznego wdrożenia. Jak to wygląda w praktyce, różni się znacznie w zależności od zespołu i skali; sama Dyrektywa nie przepisuje konkretnej metody pracy, ale nadzorcy i kontrahenci patrzą na pytanie leżące u podłoża: czy jedna osoba może bez kontroli wprowadzić zmiany, które dotyczą klientów.
Sekrety i klucze oddzielnie od kodu
Drugi punkt, na który formularze regularnie zwracają uwagę, to gdzie przechowywane są hasła, klucze API i inne sekrety. Sekrety, które znajdują się w samym kodzie źródłowym, są widoczne dla każdego mającego dostęp do odczytu tego kodu, co może być znacznie większa grupa niż ci, którzy faktycznie powinni pracować z tym kluczem. Oddzielne magazyn na sekrety, z własnymi uprawnieniami dostępu niezależnie od repozytorium kodu, to powszechny sposób, aby to rozdzielić. Czy i jak to u Ciebie zorganizujesz, to techniczny wybór; istotne dla dossier jest przede wszystkim to, czy możesz wyjaśnić, dlaczego wybrana metoda jest odpowiednia dla skali i ryzyk tego, co budujesz.
Co dokumentujesz, nie tylko co konfigurują
Skonfigurowanie techniczne uprawnień dostępu to jedno; wykazanie tego to drugie, a to drugie w praktyce bywa częściej pomijane. Lista osób mających dostęp do jakich systemów, kiedy ten dostęp przyznano i na jakiej podstawie, to dokładnie dowód, o który pytają ankiety lub organy nadzoru. Bez tej listy musisz każdą odpowiedź opracowywać od nowa; z aktualnym rejestrem obok każdego środka odpowiedź już czeka. przejść objaśnienia dla każdego środka daje obraz tego, jak zarządzanie dostępem odnosi się do pozostałych dziewięciu środków z obowiązku dbałości.
Czy Twoja organizacja sama podlega obowiązkowi dbałości, czy też otrzymujesz to pytanie, ponieważ twoja strona zamawiająca tak ma, można określić za pomocą kilku pytań. Dla osób zastanawiających się, jak surowe są dokładnie wymogi dotyczące zarządzania dostępem, gdy klient prosi o wykazanie tego, co zostało uregulowane, objaśnienie ochrony i bezpieczeństwa danych daje szerszy obraz źródła tego typu wymogów.
Dla własnej sytuacji, na przykład czy konkretna konfiguracja Twojej linii entwicklungslinii spełnia obowiązek dbałości, który spoczywa na Tobie lub na Twojej stronie zamawiającej, właściwym miejscem jest prawnik lub właściwy organ nadzoru; secria.eu przygotowuje dokumentację, ale nie wydaje orzeczeń dotyczących zgodności poszczególnych przypadków.
Chcesz zobaczyć, jak zarządzanie dostępem pasuje do reszty Twojego dossier, czy masz jeszcze pytania dotyczące tego, co dokładnie oznacza ten środek? przeczytaj często zadawane pytania zawiera już krótkie odpowiedzi na wiele z tych punktów, a bezpłatny quick-scan pokazuje w kilka minut, gdzie Twoja organizacja stoi w tym zakresie.