Многоетапната проверка, често наричана MFA, е втора проверка над парола: код от приложение, SMS или физически ключ. Вопросът дали това е задължително за софтуерна компания не може да се отговори с едно да или не, тъй като NIS2 не предписва конкретна техника. Член 21 задължава организациите, попадащи под защитното задължение, да вземат подходящи мерки за достъпна безопасност и силна аутентификация, а надзорните органи при това гледат къде е рискът най-голям.
За софтуерна компания това на практика са два много различни места: разработваната линия, с която работите вие, и софтуерът, който доставляте на клиентите. И двете се нуждаят от собствена преценка, и тази преценка не е еднакво строга навсякъде.
Два места, където многоетапната проверка играе роля
Първото място е вътрешно: средата, в която работят вашите разработчици. Изходен код, разработвателската линия, облачни конзоли и системите, с които развеждате в производство. Второто място е в самия продукт: ако софтуерът, който разработвате или доставляте, има екран за вход, многоетапната проверка е и там тема, както за вашите собствени потребители, така и за крайните потребители на вашия клиент. Списък със защитни въпроси на поръчител почти винаги задава за двете, често в отделни въпроси, които са формулирани различно от очаквания ви.
При достъпа до вашата разработвателска линия
Тук очакването е най-силно. Кой може да има достъп до изходния код, кой може да развежда в производство и кой има администраторски права в облачната среда, представляват най-голямия риск, ако парола е само украдена или преиспользвана. За тези сметки многоетапната проверка в почти всеки защитен рамков се счита за базова мярка, и то е също това, което надзорните органи и клиентите очаква първо. Управление на версии, самата разработвателска линия, и особено всеки сметка с права да доведе код в производство, в практиката принципно не трябва да имат друго решение.
Това включва и поглед към това кой всъщност още има нужда от този достъп. Досие, при което по система е отбелязано кой може да има достъп и защо, облекчава отговарянето на този въпрос в списък с конкретен отговор вместо с предположение. как достъпното управление и многоетапната проверка за всеки предмет са обяснени там дава начало.
При софтуерът, който доставляте
Вторият слой е самият софтуер. Ако вашия продукт има функция за вход, въпросът дали предлагате многоетапна проверка почти винаги се появява в списък със защитни въпроси, а понякога дори като договорно изискване. Това е другачна преценка, отколкото при вашата собствена разработвателска линия: тук не е въпрос за това, което вие сами използвате, а за това, което доставляте на вашия клиент. Поръчител, който самият попада под защитното задължение, трябва според член 21 да преценява и своята верига, и въпросът дали вашия продукт поддържа силна аутентификация попада там.
Отговорът не трябва да бъде, че е задължително активирано навсякъде. Често е достатъчно да се покажe, че възможността съществува, че потребителите се насърчават да я използват, и че имате план да я разширите където рискът го оправдава.
Където е по-малко очевидно
Не всеки акаунт или среда изисква еднаква строгост. Тестова среда без реални данни на клиенти, вътрешна система за документация само с права за четене или отделен инструмент, който един разработчик използва от време на време, имат различни вкусове от акаунт с достъп до производство. Задължението за управление на рисковете изисква мерки, които съответстват на рисковете, а не еднакъв строг слой навсякъде. Органите по надзор оценяват това въз основа на пропорционалност, което означава, че обоснована решение да не прилагате многофакторна верификация някъде може да е точно толкова част от досието, колкото местата, където е приложена.
Обоснованието е най-важното слово тук. Решение без пояснение в списък от въпроси бързо изглежда като пропуск, докато същото решение с кратко обяснение често е точно отговорът, който ищете възложителя.
Какво означава това за разговора с възложител
Възложител, който изпраща списък от въпроси, обикновено не иска да знае дали отговаряте на всяка дума, а дали знаете къде са вашите рискове и се справяте с тях съзнателно. За многофакторна верификация това означава: да можете да покажете какво е на разработчишкия път, какво е в продукта и защо останалото е организирано по-различно. Който е записал това по система с състояние и отговорник, не трябва да търси отново отговора всеки път, когато пристигне следващия списък от въпроси.
Как точно това се развива за вашата организация зависи от вашата роля в веригата и от това, което вашите клиенти конкретно питат; при съмнения консултирайте самия текст на директивата или съветник. Ако първо искате да знаете къде стойте, то безплатната проверка в няколко въпроса дава първа индикация, и обяснение откъде идва информацията показва как се образува тази индикация.
Ако искате да прочетете по-широко как тази тема е свързана с другите мерки от задължението за управление на рисковете, ще намерите това в преглед на темите по ситуация. Бързата проверка и базата от знания са свободно достъпни без да трябва да създавате акаунт.