Самооценка на ИТ инфраструктурата на общината
Практически технически проверки за сигурност, устойчивост и готовност при инцидент
Ако утре сутринта сървърът не тръгне, деловодната система е криптирана или доставчикът каже „при нас всичко е наред“ — знаем ли какво имаме, как е защитено и можем ли да го възстановим?
Това е основният въпрос на настоящия технически материал. Следват практически проверки, които общинският ИТ екип може да започне самостоятелно: инвентаризация, преглед на публичните услуги, мрежова сегментация, управление на достъпа, резервни копия и реакция при инцидент. Всички процедури са предназначени само за оторизирана вътрешна проверка на собствената инфраструктура.
📌 Важно: Материалът е публикуван първоначално през септември 2026 г. и нормативните сведения отразяват състоянието към 16 септември 2026 г. Преди прилагане на конкретно нормативно изискване проверете актуалната му редакция.
Нормативна рамка (състояние към 16 септември 2026 г.)
Какво е задължение и какво е добра практика
Как да четете статията
⚖️ Нормативно задължение — произтича пряко от закон или наредба; посочен е точният източник
• Добра практика — утвърден стандарт в бранша, но не е законово изискване
⚠️ Препоръчителна техническа мярка — препоръка на „Съвет БГ“ ЕООД въз основа на практиката
През февруари 2026 г. нормативната рамка около общинските ИТ инфраструктури се промени съществено. Затова, преди техническата част, е важно да отделим три неща, които често се смесват: какво е задължение по закон, какво е добра практика и какво препоръчваме ние въз основа на практиката си с административни мрежи.
⚖️ Нормативни промени към септември 2026 г.
Със Закона за изменение и допълнение на Закона за киберсигурност (обн. ДВ, бр. 17 от 13.02.2026 г., в сила от 13.02.2026 г.) в българското законодателство беше въведена Директива (ЕС) 2022/2555 (NIS2). Законът се прилага за административните органи (чл. 4, т. 1 ЗКС), а те са определени като съществени субекти чрез препращането в чл. 4а, ал. 1, т. 4 ЗКС. При общините административен орган е кметът, подпомаган от общинската администрация; затова в този брой използваме по-краткото „общината“ в практически смисъл.
Практическите последици за общината са четири:
1. Отговорността е управленска, а не само техническа. Административният орган одобрява мерките за управление на риска в областта на киберсигурността и следи за прилагането им (чл. 21 ЗКС). За общината това означава отговорност на кмета като административен орган, подпомаган от секретаря, служителя по мрежова и информационна сигурност и ИТ екипа. При нарушение на чл. 21 законът предвижда глоба от 500 до 5000 евро за ръководителя на административния орган (чл. 29, ал. 4 ЗКС).
2. Мерките са определени по групи. Чл. 22 ЗКС изисква подходящи и пропорционални технически, оперативни и организационни мерки. Сред тях са анализът на риска, действията при инцидент, непрекъснатостта на дейността и резервните копия, сигурността на доставките, киберхигиената и обучението, криптографията, контролът на достъпа, управлението на активите и измененията, както и многофакторното удостоверяване, когато е целесъобразно.
3. Сроковете при значителен инцидент са кратки. До секторния екип за реагиране при инциденти с компютърната сигурност (СЕРИКС) се подава ранно предупреждение до 24 часа от установяването на значителния инцидент и уведомление с първоначална оценка до 72 часа. Междинен доклад се подава при поискване, а окончателният — до един месец след 72-часовото уведомление; ако инцидентът още не е овладян, се прилага специалният ред на чл. 23, ал. 5, т. 5 ЗКС.
4. Проверката е реална. Контролът се осъществява от националните компетентни органи по чл. 27е ЗКС и може да включва планови и извънпланови проверки, редовни и целеви одити, както и изискване на документи и доказателства (чл. 27ж ЗКС). Когато целевият одит се извършва от независим орган, разходът по правило е за одитирания субект, освен ако компетентният орган не реши друго в надлежно обоснован случай (чл. 27з ЗКС). За неизпълнение на принудителна административна мярка по чл. 27и, ал. 1, т. 2–7 са предвидени санкции от 2500 до 12 000 евро, а при повторно нарушение — от 5000 до 25 000 евро (чл. 28 ЗКС). Министерството на електронното управление вече не е самостоятелна институция: с ПМС № 104 от 18.08.2026 г. то е влято в Министерството на иновациите и дигиталната трансформация (МИДТ), което е негов правоприемник по отношение на разглежданите тук функции.
Вторият важен документ е Наредбата за минималните изисквания за мрежова и информационна сигурност (НМИМИС, приета с ПМС № 186 от 2019 г., обн. ДВ, бр. 59 от 2019 г., изм. ДВ, бр. 36 и бр. 47 от 2022 г.). Тя се прилага пряко за административните органи и съдържа изненадващо конкретни технически изисквания — точно тези, около които е изграден настоящият брой.
⚠️ Предвидената към септември 2026 г. актуализация на наредбата
Съгласно преходните разпоредби на ЗИД на ЗКС (§ 47, т. 3) Министерският съвет трябва да приведе наредбата по чл. 3, ал. 2 ЗКС в съответствие със закона в осеммесечен срок — до 13 октомври 2026 г. Към 16 септември 2026 г. в „Държавен вестник“ не е обнародвано последващо изменение на НМИМИС и действа редакцията с измененията от 2022 г. Препоръчваме да следите „Държавен вестник“ — новата наредба ще определи минималния обхват на мерките за съществените субекти, включително за общините.
Трети относим акт е Законът за електронното управление. Наред с останалите въпроси той урежда и отчетността на ИТ ресурсите: регистърът на информационните ресурси (чл. 7е ЗЕУ) и годишният план за обновяване на информационните ресурси, който всеки административен орган изготвя в рамките на одобрения си бюджет (чл. 7ж ЗЕУ). Данните там обаче са планови и бюджетни — те не заместват техническия опис на активите, за който става дума в следващия раздел.
1. Стъпка първа
Инвентаризация: какво реално има в инфраструктурата
Няма как да защитите нещо, за което не знаете, че съществува. В почти всеки технически одит на общинска мрежа се откриват устройства, за които никой не носи отговорност: комутатор в шкаф на втория етаж, монтиран от фирма преди осем години; NAS в счетоводството, купен „за архив“; тестов сървър, вдигнат за проект, приключил през 2021 г. и оставен включен и достъпен.
Инвентаризацията не е бюрокрация. Тя е първата и най-евтината мярка за сигурност.
⚖️ Това е нормативно задължение, не препоръка
Чл. 5, ал. 1 НМИМИС изисква субектът да поддържа опис на информационните активи, физическа схема на свързаност, логическа схема на информационните потоци и документация на структурната кабелна система. Документацията се преразглежда и при необходимост се обновява поне веднъж годишно и се одобрява от административния орган (чл. 5, ал. 2).
Чл. 8, ал. 2 НМИМИС определя и минималното съдържание на описа: еднозначна идентификация (инвентарен или сериен номер), основни характеристики, услуги и процеси, в които активът участва, местоположение, година на производство, дата на въвеждане в експлоатация, версия, местонахождение на свързаната документация и отговорно лице.
Какво влиза в обхвата
Практиката показва, че администрациите описват сървърите и работните станции, а пропускат точно устройствата, през които минава най-големият риск. Минималният обхват на един реален регистър:
• Изчислителни ресурси — физически сървъри, среди за виртуализация (Hyper-V, VMware, Proxmox), виртуални машини, контейнери.
• Съхранение — дискови масиви, NAS устройства, външни дискове, лентови устройства, облачни хранилища.
• Мрежа — рутери, защитни стени (firewall), управляеми комутатори, Wi-Fi точки за достъп, контролери, медийни конвертори, VPN устройства.
• Крайни устройства — работни станции, лаптопи, служебни таблети и телефони с достъп до служебна поща.
• Периферия и „тихи“ устройства — мрежови принтери и мултифункционални устройства, IP камери, видеорекордери (NVR), контрол на достъпа, домофони, електронни табла, UPS с мрежова карта, климатици с мрежово управление.
• Услуги извън периметъра — облачни услуги, хостинг на сайта, домейни, служебна поща, електронни услуги през ЕПДЕАУ, системи, поддържани от външни фирми.
• Хора и договори — външни доставчици с достъп до системите, договори за поддръжка, договорени нива на обслужване (SLA) и контактни лица.
⚠️ Най-често пропусканите активи
IP камерите, мрежовите принтери, непрекъсваемите токозахранващи устройства (UPS) с уеб интерфейс и мрежовите видеорекордери (NVR) са класически „слепи петна“. Те работят с фърмуер, който често не е обновяван от датата на монтажа, имат стандартни пароли и почти винаги са в една мрежа с администрацията. Входната точка при инцидент невинаги е сървърът; често по-слабо поддържаното периферно устройство създава по-голям риск.
Минимални колони на регистъра
Освен нормативно изискваните полета, за практическа употреба препоръчваме регистърът да съдържа още пет колони, които превръщат описа от инвентарен документ в инструмент за управление на риска:
• Критичност — какво спира, ако този актив спре. Три нива са напълно достатъчни: критичен, важен, второстепенен.
• Има ли резервно копие — да/не и къде се съхранява то.
• Достъпен ли е от интернет — да/не, по кой порт и защо.
• Поддържа ли се още от производителя — датата на край на поддръжката от производителя.
• Дата на последна актуализация — на операционната система или фърмуера.
✅ Провери сега — 30 минути
Отворете DHCP сървъра и извадете списъка с активни резервации и издадени адреси. Сравнете го с това, което смятате, че имате.
Отворете администраторския панел на комутаторите и вижте кои портове са в състояние „up“. Всеки активен порт е устройство.
Ако разликата между списъка и представата ви е повече от пет устройства, регистърът на активите е първият приоритет, а не следващият.
2. Периметър
Какво се вижда от интернет
Външната повърхност за атака е съвкупността от всички точки, през които някой отвън може да достигне до вашите системи. За една община това обикновено са: публичните IP адреси, публикуваните услуги на тях, сайтът, порталът за електронни услуги, VPN концентраторът и — почти винаги неволно — нещо, което е било публикувано „временно“.
Целта на тази проверка е проста и напълно достижима: да съществува списък на всичко, което се вижда от интернет, и до всяка позиция да има име на човек, който знае защо е така.
Услуги, които заслужават отделен поглед
Порт
Услуга
Защо е важен
TCP 3389
RDP — отдалечен работен плот
Често използвана входна точка при атаки с изнудващ зловреден софтуер (ransomware). Не трябва да е пряко достъпен от интернет.
TCP 445
SMB — споделени папки
Публикуван SMB е сериозен проблем. Файловите споделяния нямат работа в интернет.
TCP 21
FTP
При обикновен FTP данните и паролите се предават без криптиране. Използвайте защитен вариант като SFTP или HTTPS.
TCP 22
SSH
Легитимна услуга, но изисква ключова автентикация, ограничение по източник и наблюдение на неуспешните опити.
TCP 1723
PPTP VPN
Технологично остарял протокол със слаба криптография. Подлежи на подмяна.
TCP 80 / 443
Уеб системи
Легитимни. Проверява се какво точно се публикува на тях — сайт, панел, тестова среда или устройство.
TCP 8080 / 8443
Алтернативни уеб портове
Класическо място за административни панели на камери, NAS и рутери.
⚠️ Важно уточнение
Отворен порт не означава автоматично уязвимост. Означава, че на този адрес има услуга, която трябва да има обосновка, отговорник, актуална версия и контрол на достъпа. Целта на проверката не е да се затвори всичко, а да няма нищо, за което отговорът е „не знам“.
⚖️ Какво изисква наредбата
Чл. 14, ал. 2 НМИМИС: ненужните портове по TCP и UDP трябва да бъдат забранени чрез подходяща конфигурация на устройствата за защита и контрол на трафика. Филтрирането се извършва по предварително разписани и одобрени правила, които се проверяват редовно за нерегламентирани изменения (чл. 14, ал. 1).
Чл. 20 НМИМИС, отнасящ се до достъпа до информационни активи извън контролираната мрежа, изрично изисква използване на най-малко двуфакторна автентикация, канали с висока степен на защита от типа VPN, и посочва, че не се използват FTP и Remote Desktop Connection.
Как се прави проверката
Проверката се извършва в две посоки. Отвън навътре — какво се вижда от публичния интернет към вашите адреси. Отвътре навън — какви правила има конфигурирани на защитната стена и съвпадат ли те с това, което реално е публикувано. Двата списъка се разминават учудващо често, обикновено заради правило, добавено при отстраняване на проблем и забравено.
• Извадете от доставчика или от договора точния диапазон на публичните си IP адреси. Не разчитайте на паметта.
• Извадете пълния списък на NAT и port forwarding правилата от защитната стена и рутера.
• За всяко правило запишете: към кое вътрешно устройство води, кой го е поискал, кога и дали още е нужно.
• Проверете отделно устройствата, които сами си отварят достъп — камери и NAS с включен UPnP или производителски „облачен“ достъп.
• Проверете DNS записите на домейна си — често има поддомейни, сочещи към отдавна изоставени сървъри.
✅ Провери сега — 15 минути
Проверете дали UPnP е включен на рутера или защитната стена и прегледайте автоматично създадените пренасочвания. Ако функцията не е необходима, планирайте изключването ѝ след съгласуване, проверка на зависимостите и подготовка на начин за връщане към предишната конфигурация. Не променяйте настройката директно в работно време без оценка на въздействието.
ℹ️ Техническата процедура е в разширената версия
Разширената версия на този брой съдържа детайлна процедура за оторизирана проверка със стандартния инструмент nmap — откриване на активни хостове, проверка на TCP портове, идентифициране на услуги и версии, запис на резултатите във файл и как се интерпретира изходът, включително разликата между състоянията open, closed и filtered.
3. Вътрешна мрежа
Сегментация: защо плоската мрежа е скъпа
„Плоска мрежа“ означава, че всички устройства са в един адресен диапазон и могат да си говорят свободно. Това е често срещана архитектура в общинските администрации и същевременно основната причина един инцидент да прерасне в криза.
Логиката е проста: ако камерата на входа, лаптопът на стажанта, принтерът на третия етаж и сървърът с деловодната система са в една мрежа, то компрометирането на най-слабото устройство дава достъп до най-важното. А най-слабото устройство почти никога не е сървърът.
Сегментацията не предотвратява инцидента. Тя ограничава колко скъпо ще излезе.
⚖️ Какво изисква наредбата
Чл. 13 НМИМИС изисква информационните и комуникационните системи, изпълняващи различни функции, да бъдат разделени и изолирани помежду си физически и/или логически, както и от системите на трети страни, с цел да се ограничи разпространението на инциденти. Изрично се посочва, че уеб сървърът, сървърът с приложния софтуер и сървърът с базата данни на една информационна система трябва да са на различни машини и в различни мрежи.
Примерна концептуална архитектура
Концептуална схема
Интернет
|
Защитна стена или маршрутизиращ комутатор — контролирано маршрутизиране с правила между сегментите
|
+– VLAN 10 Сървъри AD, файлов сървър, бази данни
+– VLAN 20 Администрация работни станции на служителите
+– VLAN 30 Камери IP камери и мрежов видеорекордер
+– VLAN 40 Телефония телефонна централа и апарати
+– VLAN 50 Wi-Fi за гости посетители, само достъп до интернет
+– VLAN 60 Принтери принтери и мултифункционални устройства
+– VLAN 99 Управление комутатори, UPS и платформи за виртуализация
Принципът на комуникация между сегментите е „забранено по подразбиране, разрешено по изключение“. Не се пише правило „VLAN 20 има достъп до VLAN 10“, а правило „работните станции имат достъп до файловия сървър по конкретни портове“. Всичко останало се отхвърля и се журналира.
• Guest Wi-Fi няма достъп до нито един вътрешен сегмент. Само интернет. Това е и най-лесната за реализация мярка от целия списък.
• Камерите нямат нужда от достъп до интернет, освен ако не се използва производителски облак — в който случай това решение подлежи на отделна оценка.
• Management сегментът е достъпен само от определени работни станции на администраторите, никога от общата мрежа и никога от интернет.
• Принтерите приемат връзки само от работните станции и от сървъра за печат — не обратното.
⚖️ Отделна среда за администриране
Чл. 18 НМИМИС изисква използване на отделна, подходящо защитена среда за администриране на системите, изолирана от останалите системи и от интернет, която не се използва за други цели. Когато това не е технически възможно, потоците трябва да са защитени чрез механизми за удостоверяване и криптиране. На практика това означава: администраторът не проверява поща и не сърфира от машината, от която управлява хипервайзора.
✅ Провери сега — 10 минути
Вземете произволен лаптоп от гишето за административно обслужване и се опитайте да отворите уеб интерфейса на някоя IP камера или на UPS устройството. Ако се отваря — мрежата е плоска и това е основната ви задача за следващото тримесечие.
4. Идентичности
Потребителски и администраторски профили (Active Directory)
Active Directory е централната нервна система на повечето общински мрежи. Той обаче натрупва история: акаунти на служители, напуснали преди години, групи, създадени за отдавна приключил проект, и администраторски права, дадени „временно“.
Проверката на идентичностите е една от малкото области, в които може да се постигне сериозно подобрение за един работен ден и без нито един лев разход.
⚖️ Какво изисква наредбата
Чл. 19 НМИМИС: достъп се дава само когато е строго необходим за изпълнение на служебните задължения; потребителските профили са индивидуални; паролите съдържат малки и главни букви, цифри и специални символи, с дължина не по-малко от 8 символа за потребителски и 12 символа за администраторски профили; потребителските пароли се сменят на период не по-голям от шест месеца.
Чл. 19, т. 4 НМИМИС: преглед на достъпите поне веднъж годишно, при който изрично се установява дали лица, вече напуснали организацията, и представители на трети страни все още имат достъп. Прегледът се документира.
Чл. 17 НМИМИС: администраторските профили са персонални и се използват само за административни цели ; правата им са ограничени до необходимия периметър; поддържа се списък на администраторските профили; прави се годишен преглед ; паролите им се сменят поне веднъж годишно, както и при прекратяване на договорни отношения с лица, на които са били известни.
Какво да проверите
• Акаунти на напуснали служители. Съществува ли писмена процедура, при която отдел „Човешки ресурси“ уведомява ИТ в деня на напускане? В повечето администрации — не.
• Неактивни акаунти. Профили без вписване от повече от 90 дни. Всеки от тях е валиден вход с парола, която никой не следи.
• Споделени акаунти. Профили от типа „каса“, „гише2“, „архив“. При инцидент те правят проследяването невъзможно, а при GDPR проверка — необяснимо.
• Прекалено много Domain Admins. Няма универсален допустим брой; всеки член трябва да е поименно обоснован, а групата да е сведена до необходимия минимум.
• Парола без срок на изтичане (Password Never Expires). Проверете кои профили са с изключено изтичане на паролата и защо. Обикновено това са сервизни акаунти, които никой не смее да пипне.
• Отделни административни акаунти. Един и същ човек трябва да има два профила — обикновен за ежедневна работа и административен за административни задачи.
• Локални администратори по работните станции. Колко потребители са локални администратори на собствената си машина?
• Служебни профили за системни услуги. С какви права работят услугите и приложенията? Има ли сервизен акаунт, който е член на Domain Admins?
• Стари операционни системи. Има ли още работеща Windows 7, Windows Server 2012 R2 или необновяван Linux в мрежата?
• SMBv1. Остарял протокол, който все още се среща заради стар принтер или скенер. Проверете дали е изключен.
• Права върху споделените папки. Има ли ресурси с разрешение за групата Everyone ?
• DNS, DHCP и Group Policy. Кой ги администрира, документирани ли са и има ли резервно копие на конфигурациите им?
⚖️ Забраната за Everyone е изрична
Приложение № 4 към чл. 22, ал. 6 НМИМИС („Изисквания за конфигуриране“) съдържа конкретни точки, сред които: при споделяне на файлове и принтери да не се използва настройка Everyone, а изрично да се указва кои акаунти имат достъп; да се забранят макросите в офис пакетите; User Account Control да е конфигуриран на най-високо ниво.
✅ Провери сега — 20 минути
Отворете Active Directory Users and Computers и разгледайте състава на групата Domain Admins. За всяко име отговорете на един въпрос: работи ли този човек още тук и има ли нужда от тези права днес. Ако отговорът за поне един запис е „не“ или „не съм сигурен“, проверката вече се е изплатила.
ℹ️ В разширената версия
Разширената версия съдържа контролен списък за преглед на Active Directory с 24 проверки и готови PowerShell команди за административен преглед на собствения домейн — извеждане на неактивни и изключени профили, членове на привилегировани групи, профили с непроменяща се парола и сервизни акаунти. Всички команди са само за четене и се изпълняват от администратор на съответния домейн.
5. Отдалечен достъп
VPN и достъп на външни доставчици
Отдалеченият достъп е мястото, където периметърът на общината свършва и започва домашният рутер на служителя, лаптопът на външната фирма и понякога личният компютър на счетоводител, който „само ще види нещо от къщи“.
Протоколите
Протокол
Оценка
Коментар
PPTP
Подлежи на подмяна
Криптографията му се смята за преодоляна от години. Не следва да се използва за служебен достъп.
L2TP/IPsec
Приемлив
Работещо решение при правилна конфигурация и дълъг, уникален предварително споделен ключ или сертификати.
IPsec IKEv2
Добър
Стабилен и поддържан от повечето устройства и клиенти.
OpenVPN
Добър
Зрял, добре документиран, работи със сертификати и лесно се съчетава с втори фактор.
SSL VPN (производителски)
Зависи от поддръжката
Ключово е устройството да е в поддръжка и фърмуерът да е актуален — тези решения са чест обект на атаки.
WireGuard
Добър
Модерен и бърз, с по-малка кодова база. Изисква повече дисциплина при управлението на ключовете.
⚠️ Достъпът не свършва с връзката
Най-честият пропуск не е протоколът, а какво може потребителят, след като се свърже. В много администрации VPN връзката поставя външния консултант директно във вътрешната мрежа с пълна видимост към всичко. Правилният подход е обратният: VPN профилът дава достъп само до конкретните системи, които са необходими за конкретната задача.
Какво да проверите
• Индивидуални профили. Един профил на човек. Никакви споделени пароли за „фирмата за деловодната система“.
• Многофакторно удостоверяване. За достъп до информационни активи извън контролираната мрежа най-малко двуфакторното удостоверяване е изрично изискване на чл. 20 НМИМИС; чл. 22, ал. 2 ЗКС също посочва многофакторното удостоверяване сред мерките, когато е целесъобразно.
• Списък на всички, които имат VPN достъп. Актуален, с дата на предоставяне и основание.
• Достъп на външни фирми. Активен ли е постоянно, или се включва при заявка и се изключва след приключване на работата?
• Журнал на връзките. Кой, кога, от кой адрес и за колко време се е свързвал.
• Права след свързване. До кои сегменти и портове има достъп профилът?
• Разделено маршрутизиране (split tunneling). Взето ли е съзнателно решение дали целият трафик минава през общината, или само служебният?
• Състояние на устройството. В поддръжка ли е VPN концентраторът и кога му е обновяван фърмуерът?
✅ Провери сега — 15 минути
Извадете списъка с активните VPN профили. Отбележете тези, които принадлежат на външни фирми. За всеки от тях проверете кога е бил използван за последно. Профил, неизползван повече от три месеца, трябва да бъде прегледан със собственика на услугата. Ако няма действащо основание, достъпът се деактивира по установения ред; деактивирането е обратимо и запазва следа за профила.
6. Устойчивост
Резервни копия и възстановяване след инцидент
Наличието на резервно копие не означава, че организацията може да се възстанови.
Това е най-важното изречение в целия брой. Резервно копие, което никога не е било възстановявано, е предположение, не защита. В практиката най-честите три сценария на неуспех са: копието се прави, но от седем месеца дава грешка, която никой не чете; копието съществува, но е на същия сървър или на NAS, монтиран като мрежово устройство — тоест криптира се заедно с всичко останало; копието е налично, но възстановяването отнема четири дни, а услугата трябваше да работи до обяд.
Правилото 3-2-1
• 3 копия на данните — оригиналът и две резервни копия.
• 2 различни носителя или технологии — например дисков масив и лента, или локален сървър и облак.
• 1 копие извън обекта — в друга сграда или при доставчик, като за критичната информация едно копие е офлайн; допълнително може да се използва и неизменяемо копие.
⚖️ Наредбата е много конкретна тук
Чл. 32, ал. 2 НМИМИС изисква вътрешните правила за резервиране и архивиране да съдържат най-малко: коя информация се резервира, с каква технология, тип на резервирането, период, брой копия, време за съхранение на всяко копие, място на съхранение, начин на защита от неправомерен достъп, случаите на използване и лицето, което разрешава използването.
Чл. 32, ал. 4 НМИМИС: копията се етикетират еднозначно; копията на чувствителна информация са криптирани или поне защитени с парола; копията се съхраняват на отделна машина и по възможност в друга защитена мрежа; едно от копията на критична за дейността информация се съхранява офлайн и по възможност в друга сграда или на отдалечено място.
Чл. 32, ал. 4, т. 6 НМИМИС: прави се регулярна проверка на годността на резервните копия — дали изпълняват целите, за които са създадени, и постига ли се необходимото време за възстановяване. Тоест тестът за възстановяване не е добра практика, а изискване.
RPO и RTO на разбираем език
Показател
Въпросът, на който отговаря
Пример
Допустима загуба на данни (RPO)
Колко данни можем да си позволим да загубим, измерено във време?
RPO 24 часа означава, че при срив приемаме да загубим до един работен ден работа — тоест архивираме поне веднъж дневно.
Допустимо време за възстановяване (RTO)
За колко време услугата трябва да е отново работеща?
RTO 4 часа означава, че от момента на срива до възстановената услуга трябва да минат не повече от четири часа.
Стойностите на RPO и RTO не се определят от ИТ отдела сам. Те се определят заедно със секретаря и ръководителите на дирекции, защото са управленско решение с цена. По-краткото допустимо време за възстановяване обикновено изисква повече ресурси. Ролята на ИТ специалиста е да покаже какъв е RTO днес — обикновено много по-висок, отколкото ръководството предполага.
Кое се възстановява първо
При сериозен инцидент не се възстановява всичко наведнъж. Необходим е предварително съгласуван приоритетен ред. За типична община той изглежда така:
1. Active Directory, DNS и DHCP — без тях нищо друго не работи и никой не може да се логне.
2. Виртуализационната среда — хипервайзорът и достъпът до хранилището.
3. Деловодната система / АИС — спирането ѝ спира административното обслужване и сроковете по АПК продължават да текат.
4. Местни данъци и такси (МДТ) — пряко засяга приходите и гишетата.
5. Счетоводство и ТРЗ — с приоритет, зависещ от датата в месеца; в дните около заплати приоритетът е много висок.
6. Файловият сървър — работните документи на администрацията.
7. Ключови регистри и специализирани системи — според функциите на конкретната община.
8. Конфигурациите на защитната стена, рутерите и комутаторите — без тях мрежата не се вдига, дори когато сървърите са готови.
⚠️ Архивирайте и конфигурациите, не само данните
Чл. 22, ал. 7 НМИМИС изисква субектът да съхранява офлайн копие от актуалните конфигурационни файлове и/или описание на настройките, с контролиран достъп, като копията се проверяват регулярно относно качество и годност. На практика: конфигурацията на защитната стена, правилата за NAT, VLAN схемата и настройките на комутаторите трябва да се експортират периодично и да се пазят извън мрежата.
Кога за последно реално възстановихте файл, база данни или виртуална машина от резервно копие?
Ако отговорът е „когато имаше проблем“, това не е тест. Тестът е планиран, документиран и с измерено време. Минимумът, който препоръчваме: възстановяване на отделен файл — месечно; възстановяване на база данни в тестова среда — тримесечно; възстановяване на цяла виртуална машина — поне веднъж на шест месеца.
⚖️ И плановете се проиграват
Чл. 34 НМИМИС изисква планове за действие при аварии и бедствия, които се проиграват периодично, но не по-рядко от веднъж годишно, поддържат се актуални и се съхраняват най-малко на две места, едно от които е извън сградата, в която се намират системите.
7
Актуалност
Управление на актуализациите и край на поддръжката
В много администрации „обновяване“ означава Windows Update на работните станции. Това е може би една трета от реалната задача. Устройствата, които рядко се обновяват, са същите, които стоят на границата с интернет. Посочените по-долу срокове са обичайни периоди за проверка; критичните актуализации се оценяват веднага и не се отлагат до следващия планов преглед.
Категория
Какво се обновява
Типична честота на проверка
Операционни системи
Windows Server, Windows, Linux дистрибуции
Месечно
Мрежови устройства
Защитна стена, рутер, управляеми комутатори, точки за достъп
Тримесечно и при публикуван критичен бюлетин
Съхранение
NAS, дискови масиви — фърмуер и операционна система на устройството
Тримесечно
Виртуализация
Хипервайзор, инструменти за гости, управляващ сървър
Тримесечно
Отдалечен достъп
VPN концентратори и клиенти
Месечно — това е приоритетна категория
Уеб системи
CMS (WordPress), теми, плъгини, PHP версия, база данни
Поне седмична проверка за сайта и незабавна оценка при бюлетин за критична уязвимост
Периферия
Принтери, камери, NVR, UPS, контрол на достъп
Два пъти годишно
Край на жизнения цикъл и на поддръжката
Край на поддръжката (End of Support) означава, че производителят вече не издава стандартни актуализации за сигурност. Новооткрита уязвимост може да остане без корекция от производителя, макар понякога да са възможни временни защитни мерки или платена разширена поддръжка. Край на жизнения цикъл (End of Life) означава, че продуктът е изведен от жизнения си цикъл. И в двата случая трябва да има план за подмяна.
⚖️ Тук наредбата е категорична
Чл. 22, ал. 1 НМИМИС: субектът инсталира и поддържа само версии на софтуер и фърмуер, които се поддържат от техните доставчици или производители и са актуални от гледна точка на сигурността. Чл. 22, ал. 5 изисква и вътрешни правила за проследяване на новооткрити уязвимости и на публикуваните от производителите актуализации.
Устройство или версия извън поддръжка е несъответствие с чл. 22, ал. 1 НМИМИС. Ако незабавната подмяна е обективно невъзможна, трябва да има документиран план със срок и бюджет, а до изпълнението му — временни компенсиращи мерки, например изолиране в отделен сегмент и строго ограничен достъп. Тези временни мерки намаляват риска, но не заличават несъответствието.
✅ Провери сега — 25 минути
Направете списък с пет мрежови устройства — защитната стена, рутера, основния комутатор, NAS устройството и VPN концентратора. За всяко от тях запишете текущата версия на фърмуера и потърсете в сайта на производителя каква е последната налична версия и до кога моделът се поддържа. Тази проверка отнема под половин час и почти винаги дава изненада.
8
Видимост
Системни журнали и наблюдение
Ако утре има инцидент, ще можем ли да разберем какво се е случило?
Този въпрос вече не е само технически. При значителен инцидент общината дължи ранно предупреждение до 24 часа и уведомление с първоначална оценка до 72 часа (чл. 23 ЗКС). Оценка се прави от данни. Ако логовете липсват, презаписани са или са само на компрометираната машина, срокът тече, а информация няма.
⚖️ Минимален срок на съхранение
Чл. 29 НМИМИС изисква автоматично регистриране на събитията, свързани най-малко с автентикация на потребителите, управление на профилите, правата за достъп, промени в правилата за сигурност и функционирането на системите — на сървъри, мрежово оборудване, защитни съоръжения и работни места на администратори. Записите се съхраняват за период не по-малък от дванадесет месеца, достъпът до тях е само за четене и за ограничен кръг лица, а всички компоненти поддържат единно време чрез NTP. Субектът трябва да е в състояние да прави корелация между източниците.
Минимално необходимите източници
• Защитна стена — разрешен и отхвърлен трафик, промени в правилата, административни вписвания.
• Системни журнали на Windows (Event Logs) — на контролерите на домейна и на критичните сървъри.
• Неуспешни опити за вписване — особено серии от един източник или срещу един профил.
• Привилегировани вписвания — всяко използване на административен профил.
• VPN — успешни и неуспешни връзки, продължителност, източник.
• Уеб сървър — достъп до административния панел, грешки 4xx и 5xx.
• Active Directory — създаване и изтриване на профили, промени в членството на групи.
• Задачите за резервни копия — успешни и неуспешни изпълнения, включително предупрежденията.
• Антивирусна защита или система за наблюдение и реакция на крайни устройства (EDR) — открития, поставяне под карантина, изключения.
Три различни нива на зрялост
Ниво
Какво означава
За кого е реалистично
1. Логовете съществуват
Всяка система пише записи локално, с достатъчен срок на съхранение и синхронизирано време.
Задължителен минимум за всяка администрация.
2. Централизирано събиране
Записите се изпращат към отделен сървър (syslog или подобен), където се пазят независимо от съдбата на източника.
Постижимо за всяка община с наличен ресурс — и с безплатни инструменти.
3. Система за централизирано наблюдение и анализ (SIEM)
Централизирана система, която корелира събития от различни източници и генерира сигнали по правила.
По-високо ниво на зрялост. Изисква човек, който да работи с него ежедневно.
⚠️ Централизирана система за анализ (SIEM) не е задължителна за всяка община
Внедряването на такава система без човек, който да реагира на сигналите му, произвежда скъпа система, генерираща известия, които никой не чете. Значително по-полезно е първо да се постигне ниво 2 — централизирано събиране с надеждно съхранение — и към него да се добавят няколко ясни правила за известяване: неуспешни вписвания, промени в привилегированите групи, неуспешна задача за резервно копие.
✅ Провери сега — 10 минути
Влезте в защитната стена и вижте докога назад стигат журналите. Ако отговорът е „до вчера“ или „до последното рестартиране“, изпращането им към външен сървър е задача с висок приоритет и може да бъде изпълнено с нисък лицензионен разход, ако има наличен сървърен и човешки ресурс.
9. Публични услуги
Уеб сайт и електронни услуги
Сайтът на общината е най-видимият ѝ ИТ актив и често най-слабо поддържаният. Типичната конфигурация е WordPress, инсталиран преди няколко години от външна фирма, с плъгини, чиито автори отдавна не ги поддържат, и с администраторски панел на стандартния адрес.
• HTTPS и TLS. Сайтът трябва да е достъпен само по HTTPS, със сертификат от доверен доставчик и TLS версия 1.2 или по-нова — това е изрично изискване на чл. 24 НМИМИС.
• HTTP заглавия за сигурност. HSTS, X-Content-Type-Options, X-Frame-Options, Content-Security-Policy и Referrer-Policy са изброени в Приложение № 5 към чл. 24, т. 13 НМИМИС.
• Бисквитки. Флаговете Secure и HttpOnly също са нормативно изискване, а не препоръка.
• Административен панел. Наредбата изисква промяна на стандартното наименование на папката за достъп до администраторския панел при използване на CMS.
• Актуализации. Ядро, тема и плъгини. Неизползваните плъгини и теми се деинсталират, а не само деактивират.
• Резервно копие на сайта. Отделно от копието на хостинга — файлове и база данни, съхранявани при вас.
• Защитна стена за уеб приложения (WAF). Такава защитна стена пред уеб приложението е изискване по чл. 24, т. 4 НМИМИС.
• Тестови поддомейни. Адреси с означения като test., new., staging. („тестова среда“) или old. често остават публични с години. Всеки от тях е самостоятелна входна точка.
• DNS записи. Чл. 25 НМИМИС изисква DNSSEC, забрана на зонови трансфери и наличие на SPF и DMARC записи.
⚠️ Проверете и това, което вече не използвате
Старата версия на сайта, оставена на поддомейн „за справка“, е една от най-честите находки при технически преглед. Тя не се обновява, никой не я наблюдава и обикновено споделя сървър с действащия сайт.
10. Физическа среда
Електрозахранване, климатизация и достъп
Най-скъпите прекъсвания, които сме наблюдавали в общински администрации, нямат нищо общо с хакери. Причините са прегряло сървърно помещение през август, UPS с батерии на осем години, който при първото спиране на тока се изключил моментално, и авария на водопровод един етаж по-горе.
• UPS. Знаете ли колко минути автономност имате реално при текущото натоварване — не по спецификация, а измерено?
• Тест на UPS. Кога за последно е правен предварително планиран и наблюдаван тест под товар? Такъв тест се извършва само след оценка на риска, уведомяване на засегнатите звена и проверка на автоматичното изключване на системите. Батериите остаряват предвидимо: типичният им живот е между три и пет години.
• Правилно изключване. Настроено ли е автоматично коректно спиране на сървърите преди изчерпване на батерията? Внезапното спиране на виртуализационна среда носи риск от повреда на данни.
• Климатизация. Има ли резервен климатик и следи ли се температурата с известяване? Един прост мрежов термометър струва по-малко от един час престой.
• Физически достъп. Кой има ключ за сървърното помещение? Има ли списък и води ли се дневник?
• Пожар. Има ли подходящо пожарогасително средство до помещението и знаят ли служителите къде е?
• Наводнение. Има ли водопроводни или отоплителни тръби над и около помещението? Сървърите на пода ли са?
• Резервно захранване. Има ли генератор и кога е тестван под товар?
• Документация. Маркирани ли са кабелите и има ли схема на шкафа? При авария в 23:00 ч. това е разликата между двадесет минути и пет часа.
⚖️ И това е в наредбата
Чл. 21 НМИМИС изисква осигуряване на климатично-механичните условия, указани от производителя, наблюдение на тези параметри и планирана регулярна техническа профилактика. Чл. 26 изисква защита на информационните активи от неоторизиран физически достъп, както и от пожар, наводнение и химическа и физическа промяна на въздуха, с подходящо наблюдение върху ефикасността на мерките.
✅ Провери сега — 5 минути
Влезте в сървърното помещение и погледнете датата на производство върху батериите на UPS. Ако е отпреди повече от пет години, планирайте подмяна в следващия бюджет — независимо какво показва индикаторът на устройството.
11. Самооценка
25 въпроса, на които трябва да знаете отговора
Отговорете на следващите двадесет и пет въпроса с Да, Не или Не знам. Двата отговора „Не“ и „Не знам“ се броят еднакво — за целите на самооценката „не знам“ е също толкова информативен резултат, колкото и „не“.
Попълването отнема около двадесет минути и е най-полезно, ако се прави от системния администратор и секретаря заедно.
1. Имаме ли актуален регистър на ИТ активите, обновяван през последните 12 месеца? [Да / Не / Не знам]
2. Има ли актуална физическа схема на свързаност и логическа схема на информационните потоци? [Да / Не / Не знам]
3. Знаем ли точно всички публични IP адреси, с които разполага общината? [Да / Не / Не знам]
4. Знаем ли кои услуги са достъпни от интернет и защо всяка от тях е публикувана? [Да / Не / Не знам]
5. Потвърдено ли е, че няма пряко достъпен от интернет RDP (порт 3389)? [Да / Не / Не знам]
6. Потвърдено ли е, че PPTP не се използва за служебен отдалечен достъп? [Да / Не / Не знам]
7. Има ли отделна мрежа за гости, без достъп до вътрешните сегменти? [Да / Не / Не знам]
8. Отделени ли са IP камерите и NVR устройствата от административната мрежа? [Да / Не / Не знам]
9. Има ли отделен сегмент за управление на мрежовото оборудване и хипервайзорите? [Да / Не / Не знам]
10. Деактивират ли се профилите на напусналите служители най-късно при прекратяване на правоотношението? [Да / Не / Не знам]
11. Извършен ли е преглед на достъпите през последните 12 месеца и документиран ли е? [Да / Не / Не знам]
12. Административните акаунти отделни ли са от ежедневните потребителски профили? [Да / Не / Не знам]
13. Знаем ли поименно кои профили са членове на групата Domain Admins? [Да / Не / Не знам]
14. Има ли многофакторно удостоверяване за администраторски и външен отдалечен достъп? [Да / Не / Не знам]
15. Знае ли се поименно кой има VPN достъп и на какво основание? [Да / Не / Не знам]
16. Прекратява ли се достъпът на външни фирми след приключване на конкретната задача? [Да / Не / Не знам]
17. Съхранява ли се поне едно офлайн копие на критичната за дейността информация? [Да / Не / Не знам]
18. Съхранява ли се поне едно копие извън сградата, в която са сървърите? [Да / Не / Не знам]
19. Извършен ли е реален тест за възстановяване през последните 6 месеца и документиран ли е резултатът? [Да / Не / Не знам]
20. Определени ли са допустимата загуба на данни (RPO) и допустимото време за възстановяване (RTO) за критичните системи, съгласувани с ръководството? [Да / Не / Не знам]
21. Архивират ли се конфигурациите на защитната стена, рутерите и комутаторите? [Да / Не / Не знам]
22. Всички устройства и системи поддържат ли се от производителя или имат ли утвърден план за спешна подмяна и временни компенсиращи мерки? [Да / Не / Не знам]
23. Следят ли се фърмуерните актуализации на мрежовите устройства и VPN концентратора? [Да / Не / Не знам]
24. Съхраняват ли се журналите на защитната стена и системите поне 12 месеца? [Да / Не / Не знам]
25. Има ли писмен план за действие при атака с изнудващ зловреден софтуер (ransomware), известен на повече от един човек? [Да / Не / Не знам]
⚠️ Как се броят отговорите
Всички въпроси са формулирани в една посока: „Да“ означава, че контролът е налице, а „Не“ и „Не знам“ се броят като установена празнина.
Ориентировъчна оценка
Отрицателни отговори
Прочит
Какво следва
0 – 5
Сравнително добра базова зрялост
Насочете усилията към документиране и към редовно тестване на възстановяването.
6 – 10
Необходим е план за подобрение
Приоритизирайте по риск и заложете конкретни срокове и отговорници.
11 – 15
Значителни рискове
Необходимо е решение на управленско ниво и целеви ресурс, включително бюджетен.
над 15
Препоръчителен е подробен технически анализ на несъответствията
Състоянието трудно може да бъде овладяно само с вътрешен ресурс.
⚠️ Това не е сертификат за съответствие
Настоящата самооценка е ориентировъчна. Тя не представлява одит, не удостоверява съответствие със Закона за киберсигурност или с НМИМИС и не замества нито вътрешния одит по чл. 35 НМИМИС, нито проверката от съответния национален компетентен орган. Предназначението ѝ е да покаже къде да се насочи вниманието първо.
Абонаментно съдържание
Допълнителни материали в разширената версия на бюлетина
Публикуваният бюлетин разглежда проблемите, обясненията и добрите практики. Разширената версия съдържа същия основен текст без съкращения, а към него — готовите работни документи, с които проверката реално се извършва и се документира:
• Пълен контролен списък за технически анализ на несъответствията, с нива на зрялост
• Приложение 1 — Примерен регистър на ИТ активите с попълнени редове
• Приложение 2 — Процедура за оторизирана проверка на мрежата с nmap и интерпретация на резултатите
• Приложение 3 — контролен списък за преглед на Active Directory: 24 проверки
• Приложение 3 — Безопасни PowerShell команди за административен преглед на собствен домейн
• Приложение 4 — контролен списък за VPN: 18 проверки
• Приложение 5 — Контролен списък за резервните копия: 22 проверки
• Приложение 6 — Образец на протокол за тест на възстановяване (тест за възстановяване)
• Приложение 7 — RPO/RTO регистър с примерни стойности за АИС, МДТ, счетоводство, ТРЗ, AD, файлов сървър и сайт
• Приложение 8 — Регистър за версии, актуализации и край на поддръжката
• Приложение 9 — Таблица за VLAN планиране с матрица на достъпите
• Приложение 10 — Примерна структура на технически доклад за несъответствията в 13 раздела
• Приложение 11 — Контролен списък за техническа проверка на публичния сайт
• Приложение 12 — Контролен списък за физическа и електрическа устойчивост
Всички образци са предвидени за попълване и прилагане към вътрешната документация по чл. 5 НМИМИС.
Проверимост
Използвани източници
• Закон за изменение и допълнение на Закона за киберсигурност, обн. ДВ, бр. 17 от 13.02.2026 г., в сила от 13.02.2026 г.
https://dv.parliament.bg/DVWeb/showMaterialDV.jsp?idMat=241234
• Постановление № 104 на Министерския съвет от 18.08.2026 г., обн. ДВ, бр. 76 от 21.08.2026 г. — МИДТ е правоприемник на МЕУ.
https://dv.parliament.bg/DVWeb/showMaterialDV.jsp?idMat=245429
• НСОРБ. Нови изисквания към общините по Закона за киберсигурност (Директива NIS2): обхват, мерки, контрол и санкции, 13.02.2026 г.
https://www.namrb.org/bg/za-obshtinite/konsultativni-materiali/novi-iziskvaniya-kam-obshtinite-po-zakona-za-kibersigurnost-direktiva-nis2-obhvat-merki-kontrol-i-sanktsii-19433
• Наредба за минималните изисквания за мрежова и информационна сигурност, приета с ПМС № 186 от 2019 г., обн. ДВ, бр. 59 от 2019 г., изм. ДВ, бр. 36 и бр. 47 от 2022 г.
https://dv.parliament.bg/DVWeb/showMaterialDV.jsp?idMat=139834
• Директива (ЕС) 2022/2555 (NIS2) на Европейския парламент и на Съвета от 14 декември 2022 г.
• Закон за електронното управление — чл. 7е и чл. 7ж относно информационните ресурси и годишния план за обновяването им.
Нормативната информация е актуална към 16 септември 2026 г. Наредбата по чл. 3, ал. 2 ЗКС трябва да бъде приведена в съответствие със закона до 13 октомври 2026 г. съгласно § 47, т. 3 от преходните разпоредби на ЗИД на ЗКС — препоръчваме проверка в „Държавен вестник“ преди позоваване.
Нуждаете се от съдействие? Разгледайте услугите ни по системна администрация и ИТ инфраструктура или изпратете запитване.