Кой има достъп до изходния код, конвейера и производствената среда?
Контролът на достъпа при разработка на софтуер се отнася до въпроса кой има право да извърши кои действия върху кои части на вашия конвейер на разработка: кой може да чете код, кой може да променя и слива код, кой може да стартира компилиране и кой може да издаде версия в производство. Това е по-специфичен въпрос от контролът на достъпа за организация като цяло, защото екип по разработка работи едновременно с няколко системи: хранилище на изходния код, среда за компилиране и тестване, и обикновено отделна производствена среда, където софтуерът наистина работи.
Причината този предмет да се появява в списъците с въпроси за киберсигурност и в мерките за управление на рисковете на Директива (EU) 2022/2555, е че грешка в достъпа до вашия конвейер на разработка директно засяга всички хора, които използват вашия софтуер. Всеки, който може незабелязано да променя код, който впоследствие се разпределя, засяга не само вашата собствена организация, но и вашите клиенти. Затова както надзорният орган, така и купувач, който сам попада под задължението да управлява рисковете, пита как сте организирали това.
Защо именно изходния код и конвейера
Екип по разработка обикновено има повече хора с по-широки права, отколкото е строго необходимо, просто защото това работи на практика: всеки може да има достъп навсякъде, никой не трябва да чака. От гледна точка на управлението на рисковете това е точно точката, където се задават уточняващи въпроси. Не защото доверието би било погрешно, а защото документираемостта е нещо различно от доверието: надзорният орган или купувач иска да знае дали можете да докажете кой има достъп, не само дали вие на това вярвате.
Въпросите, които се появяват обикновено, засягат три нива. Първото е самото хранилище на изходния код: кой може да чете, кой може да променя, и има ли задължителна проверка преди промяна да бъде слята с главната версия. Второто е средата за компилиране и тестване: кой може да стартира компилиране и има ли тази среда достъп до данни или системи, които не са предназначени за целите на тестване. Третото е производствената среда: кой наистина може да издаде версия, и е ли това различна група хора от тези, които пишат кода.
Разделяне на писане и издаване
Повтарящо се разграничение в списъците с въпроси е дали човекът, който пише кода, е също този, който издава версията в производство. Когато това е един и същ човек, без междинна стъпка от някой друг, възниква ситуация, в която грешка или злонамерена промяна попада в производство без да бъде видяна. Много организации решават това със задължителна втора преглед преди кода да бъде слят, и с отделна роля или отделни права за действителното издаване на версия. Как това се проявява на практика, варира значително между екипи и по отношение на размер; самата Директива (EU) 2022/2555 не предписва специфичен начин на работа, но надзорните органи и купувачи се вглеждат в основния въпрос: може ли един човек неконтролирано да въведе промени, които засягат клиенти.
Тайни и ключове отделени от кода
Второ место, където списъците с въпроси редовно задават уточняващи въпроси, е където се съхраняват пароли, API-ключове и други тайни. Тайни, които са в самия изходен код, са видими за всеки със достъп до четене на този код, което може да бъде много по-голяма група от тези, които действително имат право да работят с този ключ. Отделно хранилище за тайни, със собствени права на достъп независимо от хранилището на кода, е обичайния начин да се осъществи това разделяне. Как и дали реализирате това е технически избор; значимо за досието е най-вече дали можете да обясните защо избраният подход е подходящ спрямо размера и рисковете на това, което разработвате.
Какво документирате, не само какво инсталирате
Техническото конфигуриране на достъпните права е едно нещо; доказването им е второ, и това второ се забравя по-често на практика. Списък на това кой има достъп до кой системен ресурс, кога е был предоставен достъпът и на какво основание, е точно документът, който попит списък или надзорен орган ще поиска. Без такъв списък трябва да разберете отново при всеки въпрос; с живо регистър до всяка мярка отговорът вече е готов. преминете през обясненията към всяка мярка дава представа как управлението на достъпа се отнася към другите девет мерки от задължението за грижа.
Дали вашата организация самата попада под задължението за грижа, или че получавате този въпрос защото вашият поръчател е така, може да се определи с няколко въпроса. За тези, които се питат колко строги са точно изискванията за управление на достъпа, когато клиент поиска доказателство за това, което е уредено, дава обясненията относно защитата на данните и безопасността по-широка представа откъде идват такива изисквания.
За вашата конкретна ситуация, например дали конкретно оформление на вашия разработчически процес е достатъчно за задължението за грижа, което лежи на вас или на вашия поръчател, юрист или компетентният надзорен орган са подходящото място; secria.eu подготвя регистрирането, но не издава становище по отношение на отделната съответствост.
Желаете ли да видите как управлението на достъпа се вписва в останалата част на вашия досие, или имате ли повече въпроси относно точното значение на тази мярка? прочетете често задаваните въпроси дава кратък отговор на много от тези точки, и безплатният бърз преглед показва в няколко минути как вашата организация стои по отношение на този предмет.