Съдържание table of Contents

Качество и сигурност на програмните продукти и приложенията

Изтегляне 0.74 Mb. страница 23/32 Дата 09.09.2023 Размер 0.74 Mb. #118621

Навигация на страницата:

• Информационна сигурност и интегритет на данните
• Използваемост
• Интернационализация
• Изисквания за използваемост на потребителския интерфейс
• Изисквания за използваемост в случаи на прекъснати бизнес процеси

Не е приложимо. Качество и сигурност на програмните продукти и приложенията Да бъде предвидено спазването на добри практики на софтуерната разработка – покритие на изходния код с тестове – над 60%, документиране на изходния код, използване на среда за непрекъсната интеграция (Continuous Integration), възможност за компилиране и пакетиране на продукта с една команда, възможност за инсталиране на нова версия на сървъра с една команда, система за управление на зависимостите (Dependency Management); Публичните модули, които ще предоставят информация и електронни услуги в Интернет, трябва да отговарят на актуалните уебстандарти за визуализиране на съдържание. Информационна сигурност и интегритет на данните Не се допуска съхранението на пароли на администратори, на вътрешни и външни потребители и на акаунти за достъп на системи (ако такива се използват) в явен вид. Всички пароли трябва да бъдат защитени с подходящи сигурни алгоритми (напр. BCrypt, PBKDF2, scrypt (RFC 7914) за съхранение на пароли и където е възможно, да се използва и прозрачно криптиране на данните в СУБД със сертификати (transparent data-at-rest encryption); Да бъде предвидена система за ежедневно създаване на резервни копия на данните, които да се съхраняват извън инфраструктурата на системата; Не се допуска използването на Self-Signed сертификати за публични услуги; Всички уебстраници (вътрешни и публично достъпни в Интернет) трябва да бъдат достъпни единствено и само през протокол HTTPS. Криптирането трябва да се базира на сигурен сертификат с валидирана идентичност (Verified Identity), позволяващ задължително прилагане на TLS 1.2, който е издаден от удостоверителен орган, разпознаван от най-често използваните браузъри (Microsoft Internet Explorer, Google Chorme, Mozilla Firefox). Ежегодното преиздаване и подновяване на сертификата трябва да бъде включено като разходи и дейности в гаранционната поддръжка за целия срок на поддръжката – не е приложимо; Трябва да бъдат извършени тестове за сигурност на всички уебстраници, като минимум чрез автоматизираните средства на SSL Labs за изпитване на сървърна сигурност (https://www.ssllabs.com/ssltest/). За нуждите на автентикация с КЕП трябва да се предвиди имплементирането на обратен прокси сървър (Reverse Proxy) с балансиране на натоварването, който да препраща клиентските сертификати към вътрешните приложни сървъри с нестандартно поле (дефинирано в процеса на разработка на Системата) в HTTP Header-а. Схемата за проксиране на заявките трябва да бъде защитена от Spoofing – не е приложимо; Като временна мярка за съвместимост настройките на уебсървърите и Reverse Proxy сървърите трябва да бъдат балансирани така, че Системата да позволява използване и на клиентски браузъри, поддържащи по-стария протокол TLS 1.1. Това изключение от общите изисквания за информационна сигурност не се прилага за достъпа на служебни потребители от държавната администрация и доставчици на обществени услуги, които имат служебен достъп до ресурси на Системата – не е приложимо; При разгръщането на всички уебуслуги (Web Services) трябва да се използва единствено протокол HTTPS със задължително прилагане на минимум TLS 1.2 – не е приложимо; Програмният код трябва да включва методи за автоматична санитизация на въвежданите данни и потребителски действия за защита от злонамерени атаки, като минимум SQL инжекции, XSS атаки и други познати методи за атаки, и да отговаря, където е необходимо, на Наредбата за оперативна съвместимост и информационна сигурност – не е приложимо; При проектирането и разработката на компонентите на Системата и при подготовката и разгръщането на средите трябва да се спазват последните актуални препоръки на OWASP (Open Web Application Security Project); Трябва да бъде изграден модул за проследимост на действия и събития в сайта. За всяко действие (добавяне, изтриване, модификация, четене) трябва да съдържа следните атрибути: Уникален номер; Точно време на възникване на събитието; Вид събитие; Данни за информационна система, където е възникнало събитието; Име или идентификатор на компонент в информационната система, регистрирал събитието; Приоритет; Описание на събитието; Данни за събитието. Астрономическото време за удостоверяване настъпването на факти с правно или техническо значение се отчита с точност до година, дата, час, минута, секунда и при технологична необходимост - милисекунда, изписани в съответствие със стандарта БДС ISO 8601:2006; Астрономическото време за удостоверяване настъпването на факти с правно значение и на такива, за които се изисква противопоставимост, трябва да бъде удостоверявано с електронен времеви печат по смисъла на Глава III, Раздел 6 от Регламент ЕС 910/2014. Трябва да бъде реализирана функционалност за получаване на точно астрономическо време, отговарящо на горните условия, и от доставчик на доверителни услуги или от държавен орган, осигуряващ такава услуга, отговаряща на изискванията на RFC 3161; Трябва да бъдат проведени тестове за проникване (penetration tests), с които да се идентифицират и коригират слаби места в сигурността на сайта. Използваемост Общи изисквания за използваемост и достъпност При проектирането и разработката на софтуерните компоненти и потребителските интерфейси трябва да се спазват стандартите за достъпност на потребителския интерфейс за хора с увреждания WCAG 2.0, съответстващ на ISO/IEC 40500:2012; Всички ресурси трябва да са достъпни чрез GET заявка на уникален адрес (URL); Функционалностите на потребителския интерфейс на сайта трябва да бъдат независими от използваните от потребителите интернет браузъри и устройства, при условие че последните са версии в период на поддръжка от съответните производители. Трябва да бъде осигурена възможност за ползване на публичните модули на приложимите услуги през мобилни устройства – таблети и смарт-телефони, чрез оптимизация на потребителските интерфейси за мобилни устройства (Responsive Design); Не се допуска използване на капча (Captcha) като механизъм за ограничаване на достъпа до документи и/или услуги. Алтернативно, сайтът трябва да поддържа "Rate Limiting" и/или "Throttling" съгласно изискванията в т. 7.1.1. от настоящите изисквания. Допуска се използването на Captcha единствено при иденетифицирани много последователни опити от предполагаем „бот“; Трябва да бъде осигурен бърз и лесен достъп до електронните услуги и те да бъдат промотирани с подходящи навигационни елементи на публичната интернет страница – банери, елементи от главното меню и др.; Сайтът трябва да бъде проектиран и оптимизиран за ефективно и бързо индексиране от търсещи машини с цел популяризиране сред потребителите и по-добра откриваемост при търсене по ключови думи и фрази. При разработката на сайта трябва да се използват инструменти за минимизиране и оптимизация на размера на изходния код (HTML, JavaScript и пр.) с оглед намаляване обема на файловете и по-бързо зареждане на страниците; Не се допуска използването на HTML Frames, за да не се пречи на оптимизациите за търсещи машини; При разработката на публични уеббазирани страници трябва да се използват и да се реализира поддръжка на: Стандартните семантични елементи на HTML5 (HTML Semantic Elements); JSON-LD 1.0 (http://www.w3.org/TR/json-ld/); Open Graph Protocol (http://ogp.me) за осигуряване на поддръжка за качествено споделяне на ресурси в социални мрежи и мобилни приложения; В екранните форми на сайта трябва да се използват потребителски бутони с унифициран размер и лесни за разбиране текстове в еднакъв стил – не е приложимо. Всички текстови елементи от потребителския интерфейс трябва да бъдат визуализирани с шрифтове, които са подходящи за изобразяване на екран и които осигуряват максимална съвместимост и еднакво възпроизвеждане под различни клиентски операционни системи и браузъри. Не се допуска използването на серифни шрифтове (Serif). Полета, опции от менюта и командни бутони, които не са разрешени конкретно за ролята на влезлия в сайта потребител, не трябва да са достъпни за този потребител. Това не отменя необходимостта от ограничаване на достъпа чрез декларативен или програмен подход. Всяка екранна форма трябва да има наименование, което да се изписва в горната част на екранната форма. Наименованията трябва да подсказват на потребителя какво е предназначението на формата - не е приложимо. Всички търсения трябва да са нечувствителни към малки и главни букви. Полетата за пароли трябва задължително да различават малки и главни букви- не е приложимо. Полетата за потребителски имена трябва да позволяват използване на имейл адреси като потребителско име, включително да допускат всички символи, регламентирани в RFC 1123, за наименуването на хостове; Главните и малките букви на въвежданите данни се запазват непроменени, не се допуска сайтът да променя капитализацията на данните, въвеждани от потребителите. Сайтът трябва да позволява въвеждане на данни, съдържащи както български, така и символи на официалните езици на ЕС. Наименованията на полетата следва да са достатъчно описателни, като максимално се доближават до характера на съдържащите се в тях данни. Сайтът трябва да поддържа прекъсване на потребителски сесии при липса на активност. Времето трябва да може да се променя от администратора на системата без промяна в изходния код. Настройките за време за прекъсване на неактивни сесии трябва да включват и възможността администраторите да дефинират стилизирана страница с информативно съобщение, към която сайтът да пренасочва автоматично браузърите на потребителите в случай на прекъсната сесия; Дългите списъци с резултати трябва да се разделят на номерирани страници с подходящи навигационни елементи за преминаване към предишна, следваща, първа и последна страница, към конкретна страница. Навигационните елементи трябва да са логически обособени и свързани със съответния списък и да се визуализират в началото и в края на HTML контейнера, съдържащ списъка; За големите йерархически категоризации трябва да се предвиди възможност за навигация по нива или чрез отложено зареждане (lazy load). Интернационализация Сайтът трябва да може да съхранява и едновременно да визуализира данни и съдържание, което е въведено/генерирано на различни езици; Всички софтуерни компоненти на сайта, използваните софтуерни библиотеки и развойни комплекти, приложните сървъри и сървърите за управление на бази данни, елементите от потребителския интерфейс, програмно-приложните интерфейси, уебуслугите и др. трябва да поддържат стандартно и да са конфигурирани изрично за спазване на минимум Unicode 5.2 стандарт при съхранението и обработката на текстови данни, съответно трябва да се използва само UTF-8 кодиране на текстовите данни. Всички публично достъпни потребителски интерфейси следва да поддържат многоезичност – български, английски, френски и немски език. Публичната част на сайта трябва да бъде разработена и да включва набори с текстове на четири езика, а именно български, английски, френски и немски език. Преводите трябва да бъдат осъществени професионално, като се допуска използването на средства за машинен превод с ръчна проверка и корекции от професионални преводачи. Версиите на съдържанието на съответните езици трябва да включват всички текстове, които се визуализират във всички елементи на потребителския интерфейс. Сайтът трябва да позволява превод на всички многоезични текстове с подходящ потребителски интерфейс, достъпен за администратори, без промени в изходния код. Модулът за превод на текстове, използвани в сайта, трябва да поддържа и контекстни референции, които да позволяват на администраторите да тестват и да проверяват бързо и лесно направените преводи и тяхната съгласуваност в реалните екрани, страници и документи; Публичната част на сайта трябва да позволява превключване между работните езици на потребителския интерфейс в реално време от менюто - видим и лесно достъпен навигационен елемент в горната част на всяка страница, който включва не само текст, но и подходяща интернационална икона за съответния език; При визуализация на числа трябва да се използва разделител за хиляди (интервал). При визуализация на дати и точно време в елементи от потребителския интерфейс в генерирани справки или в електронни документи всички формати за дата и час трябва да са съобразени с избрания от потребителя език/локация в настройките на неговия профил: За България стандартният формат е „DD.MM.YYYY HH:MM:SS”, като наличието на време към датата е в зависимост от вида на визуализираната информация и бизнес-смисъла от показването на точно време; Системата трябва да поддържа и всички формати съгласно ISO БДС 8601:2006; Изисквания за използваемост на потребителския интерфейс Електронните форми за подаване на заявления и за обявяване на обстоятелства трябва да бъдат реализирани с AJAX или с аналогична технология, като по този начин се гарантират следните функционалности – не е приложимо: Контекстна валидация на въвежданите данни на ниво "поле" от форма и контекстни съобщения за грешка/невалидни данни в реално време; Възможност за избор на стойности от номенклатури чрез търсене в списък по част от дума (autocomplete) и визуализиране на записи, отговарящи на въведеното до момента, без да е необходимо пълните номенклатури да са заредени в браузъра на клиента и потребителят да скорлира дълги списъци с повече от 10 стойности; В електронните форми трябва да бъде реализирана валидация на въвежданите от потребителите данни на ниво "поле" (in-line validation). Валидацията трябва да се извършва в реално време на сървъра, като при успешна валидация данните от съответното поле следва да бъдат запазени от сървъра - не е приложимо; Системата трябва да гарантира, че въведените, валидираните и запазените от сървъра данни остават достъпни за потребителите дори за процеси, които не са приключили, така че при волно, неволно или автоматично прекъсване на потребителската сесия поради изтичане на периода за допустима липса на активност потребителят да може да продължи съответния процес след повторно влизане в системата, без да загуби въведените до момента данни и прикачените до момента електронни документи - не е приложимо; Трябва да бъде реализирана възможност за добавяне и редактиране от страна на администраторите на сайта, без да са необходими промени в изходния код, на контекстна помощна информация за: Категории; Различни материали (новини, пресрелийзи, снимки, галерии, видеа и др.); Всяко отделно поле за редакция; Трябва да бъде разработена контекстна помощна информация за всички процеси, включително ясни указания за попълване и разяснения за особеностите при попълване на различните групи полета или на отделни полета – за целите на работата на редакторите на сайта; Контекстната помощна информация, указанията към потребителите и информативните текстове за всяка електронна административна услуга не трябва да съдържат акроними, имена и референции към нормативни документи, които са въведени като обикновен текст (plain-text). Всички акроними, референции към нормативни документи, формуляри, изисквания и др. трябва да бъдат разработени като хипервръзки към съответните актуални версии на нормативни документи и/или към съответния речник/списък с акроними и термини – не е приложимо; Достъпът на потребителя до контекстната помощна информация трябва да бъде реализиран по унифициран и консистентен начин чрез подходящи навигационни елементи, като например чрез подходящо разположени микро-бутони с икони, разположени до/пред/след етикета на съответния елемент, за който се отнася контекстната помощ, или чрез обработка на "Mouse Hover/Mouse Over" събития – не е приложимо; При проектирането и реализацията на потребителския интерфейс трябва да се отчете, че той трябва да бъде еднакво използваем и от мобилни устройства (напр. таблети), които не разполагат с мишка, но имат чувствителни на допир екрани. Потребителският интерфейс следва да бъде достъпен за хора с увреждания съгласно изискванията на чл. 48, ал. 5 от ЗОП. Изисквания за използваемост в случаи на прекъснати бизнес процеси Системата трябва да съхранява перманентно всеки започнал процес/процедура по подаване на заявление или обявяване на обстоятелства, текущия му статус и всички въведени данни и прикачени документи дори ако потребителят е прекъснал волно или неволно потребителската си сесия; При вход в системата потребителят трябва да получава прегледна и ясна нотификация, че има започнати, но недовършени/неизпратени/неподписани заявления, и да бъде подканен да отвори модула за преглед на историята на транзакциите; Модулът за преглед на историята на транзакциите трябва да поддържа следните функционалности: Да визуализира списък с историята на подадените заявления, като минимум със следните колони – дата, входящ номер, код на тупа формуляр, подател (име на потребител и имена на физическото лице - подател), статус на заявлението; Да предлага видни и лесни за използване от потребителите контроли/инструменти: за филтриране на списъка (от дата до дата, за предефинирани периоди, като "последния един месец", "последната една година"; сортиране на списъка по всяка от колоните, без това да премахва текущия филтър; свободно търсене по ключови думи по всички колони в списъка и метаданните на прикачените/свързаните документи със заявленията, което да води до динамично филтриране на списъка. Изтегляне 0.74 Mb. Сподели с приятели: