Uwierzytelnianie wielopoziomowe, często określane jako MFA, to druga kontrola uzupełniająca hasło: kod z aplikacji, wiadomość SMS lub klucz fizyczny. Pytanie, czy jest to obowiązkowe dla przedsiębiorstwa zajmującego się oprogramowaniem, nie ma jednoznacznej odpowiedzi tak lub nie, ponieważ dyrektywa NIS2 nie przewiduje konkretnej techniki. Artykuł 21 zobowiązuje organizacje podlegające obowiązkowi ochrony do podjęcia odpowiednich środków w celu kontroli dostępu i uwierzytelniania wielopoziomowego, a organy nadzoru zwracają uwagę na miejsca, w których ryzyko jest największe.
W praktyce przedsiębiorstwa zajmującego się oprogramowaniem dotychą to dwa zupełnie różne miejsca: infrastruktura deweloperska, w której pracujecie sami, i oprogramowanie dostarczane klientom. Obie sytuacje wymagają oddzielnej oceny, a ta ocena nie wszędzie jest równie rygorystyczna.
Dwa miejsca, w których uwierzytelnianie wielopoziomowe ma znaczenie
Pierwsze miejsce to sfera wewnętrzna: środowisko, w którym pracują deweloperzy. Kod źródłowy, infrastruktura deweloperska, konsole chmury i systemy, za pomocą których wdrażacie do środowiska produkcyjnego. Drugie miejsce znajduje się w samym produkcie: jeśli oprogramowanie, które budujecie lub dostarczacie, ma ekran logowania, uwierzytelnianie wielopoziomowe jest również tematem tam, zarówno dla waszych użytkowników, jak i dla użytkowników końcowych klientów. Lista kontrolna bezpieczeństwa od zleceniodawcy prawie zawsze pyta o oba aspekty, często w osobnych pytaniach, które są sformułowane nieco inaczej niż byście oczekiwali.
W odniesieniu do dostępu do infrastruktury deweloperskiej
Oczekiwania są tu najwyższe. Osoby mające dostęp do kodu źródłowego, osoby mogące wdrażać do środowiska produkcyjnego i osoby posiadające prawa administratora w środowisku chmury stanowią największe ryzyko, jeśli hasło zostanie wykradzione lub ponownie użyte. Dla tych kont uwierzytelnianie wielopoziomowe w niemal każdym ramach bezpieczeństwa uważane jest za środek podstawowy, i jest to również to, czego organy nadzoru i klienci oczekują w pierwszej kolejności. Kontrola wersji, sama infrastruktura deweloperska, a zwłaszcza każde konto uprawniające do wdrażania kodu do produkcji, powinno być w praktyce bez wyjątku chronione drugą sprawdzianą.
Należy do tego również spojrzenie na to, kto faktycznie jeszcze potrzebuje tego dostępu. Dossier, w którym na każdy system widać, kto ma dostęp i dlaczego, ułatwia udzielenie konkretnej odpowiedzi na to pytanie w ankiecie zamiast odpowiedzi hipotetycznej. jak kontrola dostępu i uwierzytelnianie wielopoziomowe są wyjaśniane dla każdego zagadnienia stanowi dobry punkt wyjścia.
W odniesieniu do dostarczanego oprogramowania
Druga płaszczyzna to samo oprogramowanie. Jeśli wasz produkt ma funkcję logowania, pytanie, czy oferujecie uwierzytelnianie wielopoziomowe, pojawia się prawie zawsze w liście kontrolnej bezpieczeństwa, a czasem nawet jako wymóg umowy. To inna ocena niż w przypadku waszej własnej infrastruktury deweloperskiej: tutaj chodzi nie o to, co sami używacie, ale o to, co dostarczacie klientowi. Zleceniodawca, który sam podlega obowiązkowi ochrony, musi zgodnie z artykułem 21 również ocenić swoją łańcuch dostaw, a pytanie, czy wasz produkt obsługuje silne uwierzytelnianie, należy do tej oceny.
Odpowiedź nie musi być taka, że obowiązkowe jest wszędzie włączone. Często wystarczy wykazać, że taka możliwość istnieje, że użytkownicy są do niej zachęcani, i że macie plan rozszerzenia tam, gdzie ryzyko to uzasadnia.
Gdzie jest mniej oczywiste
Nie każde konto czy środowisko wymaga tej samej wagi. Środowisko testowe bez rzeczywistych danych klientów, wewnętrzny system dokumentacji z prawami tylko do odczytu lub narzędzie wspomagające używane incydentalnie przez jednego dewelopera są inne niż konto z dostępem do produkcji. Obowiązek staranności wymaga środków dostosowanych do ryzyka, a nie jednakowego, ciężkiego poziomu wszędzie. Organy nadzoru oceniają to na podstawie proporcjonalności, co oznacza, że uzasadniony wybór, aby nie wdrażać weryfikacji wieloetapowej w danym miejscu, jest równie ważną częścią dokumentacji co miejsca, gdzie jest ona wdrażana.
Uzasadnienie jest tu najważniejszym słowem. Wybór bez wyjaśnienia w kwestionariuszu szybko wygląda jak pominięcie, podczas gdy ten sam wybór z krótkim uzasadnieniem jest często dokładnie odpowiedzią, której szuka zamawiający.
Co to oznacza dla rozmowy z zamawiającym
Zamawiający, który wysyła kwestionariusz, zwykle chce wiedzieć nie tyle, czy spełniają Państwo każdy wymóg, ale czy wiedzą Państwo, gdzie leżą Państwa ryzyka i czy podejmują Państwo świadome decyzje w ich związku. W przypadku weryfikacji wieloetapowej oznacza to: być w stanie pokazać, co znajduje się na linii deweloperskiej, co znajduje się w produkcie i dlaczego reszta jest skonfigurowana inaczej. Kto to dla każdego systemu dokumentuje ze statusem i właścicielem, nie musi ponownie szukać odpowiedzi na to pytanie przy następnym kwestionariuszu.
To, czy i jak dokładnie to wygląda dla Państwa organizacji, zależy od Państwa roli w łańcuchu dostaw i tego, co konkretnie pytają Państwa klienci; w razie wątpliwości zapoznajcie się z samą treścią dyrektywy lub skonsultujcie się z doradcą. Jeśli chcecie najpierw wiedzieć, gdzie stojecie, to bezpłatna weryfikacja w kilka pytań daje pierwsze wskazanie, oraz wyjaśnienie, skąd pochodzą informacje pokazuje, jak powstaje to wskazanie.
Jeśli chcecie szerzej czytać, jak ten temat wiąże się z innymi środkami obowiązku staranności, znajdziecie to w przeglądzie tematów dla każdej sytuacji. Szybkie skanowanie i baza wiedzy są dostępne bezpłatnie, bez potrzeby tworzenia konta.