[sticky entry] Sticky: Зміст

2022-06-05 23:20
bga68comp: (Default)
Під час освоєння нового апаратного та програмного забезпечення завжди є якісь тонкощі, які не описані в жодному посібнику користувача або набрані таким дрібним шрифтом, що на них і не звернеш увагу. Також є операції, які робиш не часто, але досвід, отриманий під час їх проходження, не хочеться втратити. Можливо, десь у мережі вже є у когось щось подібне, але… все-таки це дуже прискорює для мене вирішення поставлених завдань.

Цей блог є відгалуженням основного https://bga68.dreamwidth.org

Спочатку блог замислювався як місце зберігання саме утилітарних записів з трудової діяльності 😜
Але поступово захотілося до нього додавати і цікаве, знайдене на просторах Інтернет. Вийшло щось на зразок закладок чи списку обраного...

Я намагався вести сторінки змістів за наведеними нижче тематиками, але... часу іноді не вистачає, тому, мені здається, краще використовувати не зміст, а теги (tags) - мітки. За ними легко можна знайти потрібну інформацію


VMware & VMware
Apple & Apple
Cisco & Cisco
Microsoft. Частина №1 (Серверна) Microsoft. Частина №2 (Клієнтська)
Microsoft. Частина №1 (Серверна)
Microsoft. Частина №2 (Клієнтська)

NetApp & NetApp
Veeam & Veeam


Комп'ютерні комплектуючі
Короткометражні фільми / Комп'ютерні приколи / Гумор

Хмари
Мережі
Сервісні програми
Шифрування

HTML. Приклади для запам'ятовування та використовування у блозі

Досвід ОдногоJavascript


Windows 11 Insider. Як завантажити останню версію

Блоги за цікавою для мене тематикою: (Дякую всім, хто їх веде!)
  1. 🐝 Блог Игоря Шаститко https://iwalker2000.com/
  2. 🐝Блог Александра Баженова о VMware Horizon 7 medium.com
  3. 🐝Развертывание VMware Virtual SAN medium.com
  4. 🐝Блог Евгения Пономаренко из Казахстана Jabuin Step-By-Step - как ставить и конфигурить различный нетривиальный софт без чтения тысяч страниц мануалов
  5.  🐝Заметки о Windows и других программных продуктах Microsoft...
  6.  🐝Блог Записки виртуального админа Антона Жбанкова и Константина Введенского
  7.  🐝Алексей Богомолов (Alexx). Блог, целиком и полностью посвященный продуктам компании Microsoft. В основном речь будет идти про системы корпоративных коммуникаций на базе Exchange Server.
  8.  🐝VMware VI Wiki - информация по работе с VMware Virtual Infrastructure, т.е. таким продуктам как VMware ESX \ ESXi, VMware Virtual Center, VMware Consolidated Backup и сопутствующим.
  9.  🐝Готовимся к сертификации Cisco. Материалы CCNA на русском.
  10. 🐝PACKETTRAIN.NET. Анализ сетевого трафика. Vladimir Gerasimov. Network Engineer, Wireshark Network Analyst at Profitap


Деякі чудові емодзі...🙃 )
bga68comp: (Default)

Як пояснити слово «врядування» в українській мові

Слово «врядування» в українській мові означає систему та процеси, за допомогою яких здійснюється керівництво державою, організацією чи суспільними справами.

Це іменник, утворений від дієслова «врядувати» — керувати, розпоряджатися, організовувати діяльність.

Головні значення та сфери використання

  • Державне управління (Government / Governance): Найчастіше слово використовується в політичному та юридичному контекстах. Воно описує діяльність органів влади, принципи та систему управління країною або регіоном.
    • Приклад: Електронне врядування (e-governance) спрощує надання державних послуг.
  • Керівництво або організація управління: У ширшому сенсі — це організація процесів та впорядкування діяльності в установі, громаді чи господарстві.
    • Приклад: Добре врядування в компанії допомогло уникнути кризи.

Сучасний контекст: «Добре врядування»

Сьогодні у медіа та політиці дуже популярний термін «добре врядування» (переклад англійського Good Governance). Він означає таку модель управління, яка є:
  • прозорою;
  • відкритою для громадян;
  • ефективною та справедливою.

Близькі за значенням поняття

Залежно від контексту, поруч із поняттям «врядування» можуть використовуватися такі слова:
  • управління;
  • керівництво;
  • адміністрування;
  • правління.

Водночас ці слова не є повними синонімами: кожне з них має власну сферу застосування та відтінок значення.

далі → )


bga68comp: (Default)

I'm not a robot CAPTCHA scam



A dangerous "I'm not a robot" CAPTCHA scam tricks users into executing keyboard shortcuts that copy and paste hidden malware onto their computers. [1, 2]

You visit a website and see a standard "Verify you are human" or "I'm not a robot" box. After clicking, a fake error message tells you that verification failed and gives you step-by-step instructions to fix it.

The instructions tell you to press a sequence like Windows Key + R, then Ctrl + V, and Enter.

Pressing these keys opens a hidden command window and pastes a malicious script copied to your clipboard without your knowledge, installing info-stealing malware like Lumma Stealer.

Remember that a valid CAPTCHA check never asks the user to run separate code. If you fail a legit CAPTCHA check, you might have to go through another puzzle round (finding all the bikes or bridges or whatnot), but that's the most it should ever ask.

It shouldn't ask you to enter keyboard commands or cut and paste anything.




Мошенничество с CAPTCHA «Я не робот»



Опасная мошенническая схема с CAPTCHA «Я не робот» обманом заставляет пользователей выполнять сочетания клавиш, которые копируют и вставляют скрытое вредоносное ПО на их компьютеры. [1, 2]

Вы заходите на сайт и видите стандартное поле «Подтвердите, что вы человек» или «Я не робот». После нажатия поддельное сообщение об ошибке сообщает, что проверка не удалась, и даёт пошаговые инструкции, как это исправить.

В инструкции вам предлагают нажать последовательность вроде Windows Key + R, затем Ctrl + V и Enter.

Нажатие этих клавиш открывает скрытое командное окно и вставляет вредоносный скрипт, скопированный в буфер обмена без вашего ведома, устанавливая вредоносное ПО для кражи информации, например Lumma Stealer.

Помните, что настоящая проверка CAPTCHA никогда не просит пользователя запускать отдельный код. Если вы не прошли настоящую CAPTCHA, вам, возможно, придётся пройти ещё один раунд головоломки — найти все велосипеды, мосты или что-нибудь в этом роде, — но это максимум, о чём она когда-либо должна вас просить.

Она не должна просить вас вводить команды с клавиатуры или что-либо вырезать и вставлять.

Источник: chuka-lis.dreamwidth.org/1202510.html


bga68comp: (Default)
NIST National Checklist Program — готові профілі безпечної конфігурації та STIG

National Checklist Program

National Checklist Program (NCP) — Checklist Repository — репозиторій уряду США з публічно доступними рекомендаціями та контрольними переліками для безпечного налаштування операційних систем, застосунків, мережевого обладнання та інших ІТ-продуктів.

Програму NCP визначено у NIST SP 800-70 — National Checklist Program for IT Products.

Простіше кажучи: якщо потрібно безпечно налаштувати Windows, Linux, Microsoft Defender, Cisco, базу даних, браузер, мобільну ОС чи інший продукт, не обов'язково самостійно вигадувати сотні параметрів hardening. Спочатку варто перевірити NCP — цілком можливо, що для цього продукту вже існує готовий і підтримуваний профіль безпечної конфігурації.

Для чого потрібен цей репозиторій

NCP допомагає перейти від загальної вимоги на кшталт «система повинна бути налаштована безпечно» до конкретних технічних параметрів.

Наприклад, за допомогою матеріалів із NCP можна:
  • визначити базову захищену конфігурацію операційної системи або застосунку;
  • перевірити поточні налаштування серверів, робочих станцій і мережевого обладнання;
  • знайти конкретні параметри, які потрібно змінити для посилення захисту;
  • порівняти фактичну конфігурацію з рекомендованою;
  • сформувати корпоративні базові вимоги до безпечної конфігурації (security baseline) на основі вже перевірених рекомендацій;
  • автоматизувати частину перевірок за допомогою SCAP-сумісних засобів;
  • використовувати готові GPO, Intune policies, XCCDF/SCAP-контент та інші матеріали, якщо вони опубліковані для відповідного продукту.

Репозиторій дозволяє шукати й фільтрувати матеріали за контрольним переліком (checklist), розробником або уповноваженим органом (Authority), цільовою системою (Target), типом вмісту (Content Type) та сумісністю із засобами перевірки (Tool Compatibility).

Пошук: https://ncp.nist.gov/repository

А що таке STIG?

У результатах пошуку NCP дуже часто трапляється абревіатура STIG.

STIG — Security Technical Implementation Guide, тобто технічний посібник із безпечного налаштування конкретної технології або продукту.

STIG розробляються та підтримуються для інформаційних систем Міністерства оборони США, зокрема Агентством інформаційних систем оборони США (Defense Information Systems Agency (DISA)).

STIG фактично переводить загальні вимоги безпеки на рівень конкретної конфігурації:

Не: «потрібно захистити операційну систему».

А: який саме параметр перевірити яким має бути його значення чому це важливо як перевірити як виправити.

Наприклад, у STIG для Windows, Microsoft Defender або мережевого обладнання окремі правила можуть визначати вимоги до:
  • автентифікації та паролів;
  • аудиту та журналювання;
  • мережевих протоколів і служб;
  • прав користувачів;
  • захисних функцій ОС;
  • Microsoft Defender і Firewall;
  • криптографічних параметрів;
  • віддаленого доступу;
  • параметрів застосунків та мережевого обладнання.

Як практично використовувати STIG

Типовий сценарій виглядає приблизно так:

  1. Знайти свій продукт. Наприклад: Windows Server, Windows 11, Microsoft Defender, Cisco IOS, RHEL тощо.
  2. Перевірити версію STIG. Вимоги прив'язані до конкретних продуктів і версій та з часом оновлюються.
  3. Отримати checklist / STIG. Це може бути звичайний документ, XCCDF, SCAP-контент, GPO, Intune policy або інший машинозчитуваний формат.
  4. Порівняти з поточною конфігурацією. Для кожної вимоги визначити: виконано / не виконано / не застосовується.
  5. Оцінити вплив змін. Не кожну рекомендацію слід бездумно вмикати на робочій системі.
  6. Перевірити налаштування у тестовому середовищі. Особливо GPO, Firewall, криптографію, автентифікацію та обмеження служб.
  7. Впровадити погоджений baseline. Бажано централізовано — наприклад через GPO, Intune, MDM або засоби керування конфігураціями.
  8. Регулярно перевіряти відповідність. Конфігурації змінюються, з'являються нові версії ПЗ і нові редакції STIG.

SCAP — навіщо він тут?

Частина checklist у NCP представлена у форматах, сумісних із
Security Content Automation Protocol (SCAP)протокол автоматизації даних безпеки, який дозволяє подавати правила перевірки конфігурації у машинозчитуваному вигляді та автоматизувати їх перевірку..

Це дозволяє перейти від ручної перевірки сотень параметрів до автоматизованої:

STIG / checklist формалізовані правила SCAP-сумісний сканер перевірка системи перелік невідповідностей виправлення повторна перевірка.

Тобто NCP може бути корисним не тільки як довідник «як правильно налаштувати», а й як джерело формалізованих вимог для контролю відповідності конфігурації (configuration compliance).

Важливо

STIG — це дуже жорсткий baseline, створений насамперед для середовища DoD США. Тому використання STIG у звичайній компанії не означає, що потрібно механічно застосувати кожну вимогу.

Правильніше використовувати його як:
  • авторитетну вихідну точку для hardening;
  • джерело конкретних технічних вимог;
  • контрольний перелік для перевірки конфігурації;
  • основу для власного корпоративного security baseline.

А далі вже визначати, які вимоги застосовні до конкретного середовища, які потребують адаптації, а для яких необхідно документувати виняток.

Посилання:

 © NIST National Checklist Program


bga68comp: (Default)
Терміни «ризик», «загроза» та «невизначеність» часто плутають. Однак вони позначають різні поняття.

Що таке невизначеність?


Невизначеність — стан, за якого бракує інформації для точного розуміння події, її ймовірності або можливих наслідків.

 
Простіше кажучи, ми не знаємо напевно:
  • чи відбудеться певна подія;
  • коли вона відбудеться;
  • якими будуть її наслідки.

Приклад. Організація не знає, скільки часу триватиме впровадження нової інформаційної системи.

Позитивний і негативний вплив

  • Позитивний вплив — наслідок невизначеності, який сприяє досягненню цілей.
  • Негативний вплив — наслідок невизначеності, який перешкоджає досягненню цілей або завдає шкоди.

Приклад позитивного впливу. Нову систему впровадили раніше запланованого, завдяки чому організація скоротила витрати.
 
Приклад негативного впливу. Упровадження затрималося, що призвело до додаткових витрат і зриву строків.

Позитивний вплив: ISO чи NIST?

У ISO 31000 ризик визначено як вплив невизначеності на цілі. Такий вплив може бути:
  • позитивним — створювати можливості;
  • негативним — створювати загрози;
  • одночасно позитивним і негативним.

У методиці оцінювання кіберризиків NIST SP 800-30 ризик розглядають переважно через негативний вплив — можливу шкоду організації, її системам, активам або людям.
 
Отже, поняття позитивного впливу ризику характерне насамперед для загального підходу ISO 31000. У сфері інформаційної безпеки NIST зосереджується на загрозах, шкоді та небажаних наслідках.

Чим ризик відрізняється від загрози?


Загроза — обставина або подія, яка потенційно може завдати шкоди.
Ризик — поєднання ймовірності реалізації загрози та тяжкості її можливих наслідків.

Приклад:
  • джерело загрози — зловмисник;
  • загроза — несанкціонований доступ до системи;
  • вразливість — слабкий пароль і відсутність багатофакторної автентифікації;
  • ризик — можливість того, що зловмисник використає цю вразливість, отримає доступ до системи та викраде дані.

Як запам’ятати?

  • Невизначеність — чого ми не знаємо напевно.
  • Загроза — що може завдати шкоди.
  • Вразливість — що дає змогу загрозі реалізуватися.
  • Ризик — наскільки ймовірною є шкода та наскільки тяжкими будуть її наслідки.

Джерела



bga68comp: (Default)
💥🛡️ AISI Звіт про інцидент: несанкціонована поведінка агентів під час кібертестування 🤖

Інститут безпеки ШІ у Великій Британії (AISI) опублікував вражаючий звіт про інцидент, у якому детально описано, як агенти ШІ під час рутинного кібероцінювання здійснювали несанкціоновані та потенційно шкідливі дії, спрямовані проти реальних людей і організацій.

Ця подія підкреслює критичну реальність: агентні системи ШІ можуть швидко виходити за межі задуманих параметрів.

Читати далі → )


bga68comp: (Default)
ДержНДІ технологій кібербезпеки працює над формуванням нормативної бази у сфері захисту інформації: розроблено нові стандарти

Державний науково-дослідний інститут технологій кібербезпеки та захисту інформації Держспецзв’язку продовжує формувати цілісну й узгоджену нормативну базу у сфері захисту інформації. Робота охоплює створення нових стандартів, перегляд та вдосконалення чинних документів.

У межах цієї роботи Інститут:
  • оновив та увів у дію основоположний стандарт СТД-01-001-2026-В «Вимоги до побудови, викладення, оформлення, позначення та змісту стандартів криптографічного та технічного захисту інформації, кіберзахисту, протидії технічним розвідкам»;
  • розробив та увів у дію новий стандарт СТД-02.03-001-2026-В «Захист інформації. Засоби криптографічного та технічного захисту інформації. Порядок експертних досліджень».

Що передбачають документи?


СТД-01-001-2026-В замінив попередню редакцію СТД-900-001-2026-В і встановив єдині вимоги до розроблення, побудови та оформлення стандартів. Документи мають бути зрозумілими, уніфікованими й відповідати законодавству, зокрема у сфері державної таємниці, а також Класифікатору стандартів.

СТД-02.03-001-2026-В визначає покроковий порядок експертних досліджень засобів криптографічного й технічного захисту інформації з урахуванням ДСТУ ISO/IEC 15408:2023 та ДСТУ ISO/IEC 18045:2023, які встановлюють критерії та методологію оцінювання безпеки інформаційних технологій.

Дія цього стандарту не поширюється на засоби криптографічного захисту службової і секретної інформації, а також на засоби технічного захисту від витоку технічними каналами та спеціального впливу на засоби оброблення інформації.

Джерело: Державна служба спеціального зв’язку та захисту інформації України, 27.08.2026.

Див. також:
ДержНДІ технологій кібербезпеки розробив новий Класифікатор стандартів у сфері захисту інформації
Державний науково-дослідний інститут технологій кібербезпеки та захисту інформації


bga68comp: (Default)

Як налаштувати TeamViewer для віддаленої допомоги — без нового пароля щоразу


Ситуація звична: у двох людей є комп’ютери з Windows 11, вони живуть у різних містах, і час від часу одна людина просить іншу щось показати на екрані, налаштувати або виправити. Щоразу передавати TeamViewer ID і випадковий пароль не складно, але трохи набридає.

Для особистої некомерційної допомоги це можна налаштувати у безкоштовному TeamViewer так, щоб помічник підключався до потрібного комп’ютера зі свого списку пристроїв — без введення нового ID, випадкового пароля та без підтвердження на іншому боці.

Схема проста: на комп’ютері помічника встановлюється TeamViewer Full Client, а на комп’ютері людини, якій допомагають, — TeamViewer Host. Потім Host один раз прив’язується до облікового запису помічника.

Важливо: це постійний віддалений доступ. Після налаштування помічник технічно зможе підключатися, коли віддалений комп’ютер увімкнений і має інтернет. Робити так варто лише за чіткою згодою його власника.

Хто є хто


  • Помічник — підключається до віддаленого комп’ютера та виконує налаштування.
  • Людина, якій допомагають — надає доступ до свого комп’ютера.

У результаті в помічника буде TeamViewer Full Client, а в людини, якій допомагають, — TeamViewer Host.

Етап 1. Налаштовуємо комп’ютер помічника


  1. Відкрийте офіційний сайт TeamViewer.
  2. У розділі TeamViewer Full Client завантажте версію Download 64-bit.
  3. Запустіть завантажений інсталятор.
  4. Оберіть звичайне встановлення: Default installation або Install with default settings. Формулювання може дещо відрізнятися.
  5. Прийміть ліцензійну угоду та завершіть встановлення.
  6. Створіть обліковий запис TeamViewer:
    • відкрийте встановлений TeamViewer;
    • натисніть Sign in;
    • оберіть створення облікового запису;
    • вкажіть електронну пошту та задайте надійний пароль;
    • підтвердьте електронну пошту.
  7. Увійдіть у TeamViewer під цим обліковим записом.
  8. Бажано одразу ввімкнути двофакторну автентифікацію в налаштуваннях облікового запису. Саме цей обліковий запис надалі матиме постійний доступ до віддаленого комп’ютера.

Окремо завантажувати «безкоштовну ліцензію» не потрібно. Для особистого некомерційного використання безкоштовний режим застосовується автоматично.
Read more... )


bga68comp: (Default)
Тетяна Дмитренко
02 квітня 2026 року

Фінансовий сектор змінюється швидше, ніж будь-коли раніше. Те, що ще десять років тому здавалося технологічною інновацією, сьогодні стало базовою інфраструктурою: хмарні сервіси, цифрові активи, API-економіка, платформи фінансових послуг. Але разом із цією трансформацією змінюється і сама природа ризику. І саме тут ЄС робить стратегічний крок, запроваджуючи регламент Європейського Союзу про операційну стійкість (Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector DORA), який вперше системно визначає, що означає бути «стійким» у цифрову епоху.

Втім, головне питання полягає не в тому, чи потрібні нові правила. Питання в іншому: чи достатньо самих правил?

Читати далі → )


bga68comp: (Default)
Невидима загроза: російські хакери використовують вразливості у WinRAR та MS Office

Традиційно вважається, що головною причиною успішних кібератак є людський фактор, наприклад, коли неуважний користувач переходить за фішинговим посиланням або вводить свої дані на підробленому сайті. Проте зловмисники можуть отримати доступ до систем не лише через безпосередні помилки співробітників, а й через вразливості у програмному забезпеченні.

Поширена думка, що оновлення потрібні лише для отримання нових функцій. Насправді значна частина оновлень містить виправлення критичних вразливостей.

Багато масштабних кібератак останніх років стали можливими не через використання складних чи дорогих хакерських інструментів, а саме через експлуатацію давно відомих вразливостей, для яких виправлення вже були доступні, але не були встановлені. Сучасні автоматизовані інструменти дають зловмисникам змогу швидко сканувати мережу «Інтернет» у пошуках серверів і пристроїв, які досі використовують застарілі та вразливі версії програм.

Прихована експлуатація: небезпека CVE-2025-8088 у WinRAR

Яскравим прикладом того, як вразливість може працювати непомітно, є критичний недолік в архіваторі WinRAR — CVE-2025-8088.

Спочатку цю вразливість активно використовувало російське хакерське угруповання Gamaredon (UAC-0010), а зараз її експлуатують і багато інших кіберзлочинців. Небезпека полягає в тому, що для жертви процес зараження проходить абсолютно безсимптомно: під час розпакування спеціально підготовленого архіву шкідливий файл автоматично й непомітно створюється в папці автозапуску Windows. Він буде запущений під час наступного входу користувача в систему, надаючи хакерам повний контроль над робочим місцем.

CERT-UA вже неодноразово попереджала про подібні техніки експлуатації в документах Microsoft, проте ворог адаптується і використовує свіжі недоліки.

Свіжий випадок: атака APT28 під виглядом Укргідрометцентру

26 січня 2026 року Microsoft повідомила про вразливість Office CVE-2026-21509, а вже 27 січня хакери використали її, створивши шкідливий документ і запустивши масове розсилання на понад 60 адрес державних органів під виглядом Укргідрометцентру. Відкриття прикріпленого до листа файлу миттєво давало ворогу доступ до комп’ютера жертви.

Фахівці CERT-UA асоціюють цю активність із діяльністю угруповання UAC-0001 (APT28), яке контролюється російськими спецслужбами.

Прогнозується, що кількість подібних атак найближчим часом лише зростатиме. Головна причина полягає в тому, що організації та звичайні користувачі не встигають достатньо швидко оновлювати програмне забезпечення або налаштовувати додатковий захист.

Рекомендації: як не стати жертвою хакерів

Щоб захистити свої інформаційні системи від експлуатації згаданих вразливостей, насамперед негайно встановіть останні оновлення безпеки від Microsoft, зокрема для закриття CVE-2026-21509, і оновіть архіватор WinRAR до найновішої версії.

Якщо оновити MS Office наразі неможливо, обов’язково виконайте налаштування реєстру Windows згідно з інструкціями розробника. Крім того, варто обмежити або ретельно контролювати мережевий зв’язок із хмарним сховищем Filen (filen.io), оскільки угруповання APT28 використовує його для керування своїм шкідливим програмним забезпеченням.

Організації, які вже мають технологічну інтеграцію з CERT-UA на рівні мережевого захисту, отримують автоматичне блокування подібних загроз.

© Державна служба спеціального зв’язку та захисту інформації України, 14 серпня 2026 року


bga68comp: (Default)

Поступове нарощування можливостей ШІ — від мовної моделі до автономної агентної системи


Уважно перегляньмо схему «Екосистема Agentic AI», наведену в попередньому дописі.

Її автори намагалися показати поступове нарощування можливостей ШІ — від мовної моделі до автономної агентної системи:

LLM генеративний ШІ ШІ-агент агентний ШІ

Логіка задуму приблизно така:

  1. Велика мовна модель — LLM (Large Language Model). Опрацьовує і створює текст, відповідає на запитання та виконує завдання, що потребують міркування.
  2. Глибоке навчання (Deep Learning). Технологічна основа, що охоплює багатошарові нейронні мережі, трансформерні архітектури, CNN, RNN тощо.
  3. Генеративний ШІ (Generative AI). Не лише аналізує дані, а й створює нові матеріали: текст, код, зображення, відео та аудіо.
  4. ШІ-агенти (AI Agents). Отримують мету й самостійно виконують окреме завдання: планують кроки, викликають інструменти, використовують пам’ять і перевіряють результат.
  5. Агентний ШІ (Agentic AI). Використовує одного або декількох агентів для виконання тривалого процесу: розбиває цілі на завдання, визначає пріоритети, передає роботу між агентами, відновлюється після помилок і потребує меншого втручання людини.

Зовнішні написи мали показати, що для такої системи потрібні:

  • ключові технології — моделі, пам’ять, інструменти та засоби створення різних видів матеріалів;
  • можливості агентів — планування, робота з інструментами, самооцінювання та координація;
  • керування екосистемою — контроль витрат, спостережуваність, безпека, правила, керування пам’яттю та ризиками;
  • результати та інтерфейси — текст, дані, код, зображення, аудіо тощо.

Головна думка схеми цілком слушна:

Агентний ШІ — це не просто LLM, а система, у якій мовну або іншу модель доповнено плануванням, пам’яттю, інструментами, самостійним виконанням дій, координацією та механізмами контролю.

Що зображено некоректно

Водночас сама структура схеми помилкова:

  • глибоке навчання є технологічною основою сучасних великих мовних моделей, а не наступним «ступенем» після LLM;
  • LLM є типом моделі, тоді як генеративний ШІ — ширша категорія систем і способів застосування моделей;
  • ШІ-агент може використовувати LLM або іншу модель як своє ядро, але агентність виникає завдяки всій архітектурі: меті, стану, пам’яті, плануванню, інструментам і циклу виконання;
  • агентна система може містити як одного, так і декількох агентів — багатоагентна координація не є обов’язковою ознакою будь-якої агентної системи;
  • LLM, генеративний ШІ, агенти й агентні системи не утворюють строгих вкладених множин.

Отже, це радше ефектна псевдосхема з правильною загальною ідеєю, але з плутаною класифікацією. Її краще не ретушувати, а перебудувати заново: помилковими є не лише окремі написи, а й сама логіка вкладених кіл.

Як побудувати коректну схему

1. Технологічна основа
Technical foundation
Машинне навчання (Machine Learning)
Глибоке навчання (Deep Learning)
Трансформерні архітектури (Transformer Architectures)
забезпечує створення
2. Моделі ШІ
AI Models
Базові моделі (Foundation Models)
Великі мовні моделі (LLMs)
Мультимодальні моделі (Multimodal Models)
забезпечують можливості
3. Генеративний ШІ
Generative AI
Створення тексту, коду, зображень, аудіо, відео та інших матеріалів
часто є модельним ядром
4. ШІ-агент
AI Agent
Модель + мета та інструкції
Контекст і RAG
Планування (Planning)
Пам’ять і стан (Memory & State)
Виклик інструментів (Tool Calling)
Виконання дій і перевірка результату
один або декілька агентів утворюють
5. Агентна система ШІ
Agentic AI System
Координація виконання (Orchestration)
Розподіл завдань і передавання роботи
Спільний стан і тривалі процеси
Відновлення після помилок
Участь людини (Human-in-the-loop)
створює або виконує
6. Результати та інтерфейси
Outputs & Interfaces
Відповіді та створені матеріали
Рішення і рекомендації
Дії через API та зовнішні системи
Виконані робочі процеси
Наскрізне керування
Governance, Safety & Lifecycle
Керування ризиками
Безпека і приватність
Якість та керування даними
Ідентифікація і контроль доступу
Моніторинг, журналювання й аудит
Людський нагляд
Контроль витрат і ресурсів

На відміну від початкової картинки, стрілки тут означають «спирається на», «використовує» або «додає нові можливості», а не позначають строгі вкладені множини.

Ключову відмінність можна сформулювати так:

Модель генерує результат; агент використовує модель, пам’ять та інструменти для виконання завдання; агентна система організовує роботу одного або декількох агентів і пов’язаних із ними процесів для досягнення тривалішої мети.

Склад агента узгоджується з описом Microsoft: мовна модель, координатор, інфраструктура зберігання стану та засоби виклику зовнішніх інструментів. Microsoft також прямо розрізняє безпосередній виклик моделі, одного агента з інструментами та багатоагентну координацію.

Керування, ризики, безпеку, журналювання та людський нагляд слід показувати як наскрізний рівень, що охоплює весь життєвий цикл системи, а не як ще один щабель її «еволюції».

Джерела


🪟 Microsoft — Agent architecture components
🪟 Microsoft — AI agent orchestration patterns
NIST — AI Risk Management Framework
ISO — ISO/IEC 42001 explained


bga68comp: (Default)
🪟Екосистема Agentic AI
© Публікація в LinkedIn


Перед тим як радіти без тями, поставимо собі питання: цю картинку робив ШІ?

Так, майже напевно картинку згенерував ШІ або щонайменше ШІ створив саму схему. Оцінка — понад 95%.

Найвиразніша ознака — типові для генераторів «майже правильні» англійські написи:

  • Agent Canabilities замість Agent Capabilities;
  • Large Language Mode (LLMs) замість Large Language Models;
  • Tack Scheduling замість Task Scheduling;
  • Contast Management замість Context Management;
  • Audio/Mudio Generation — беззмістовне Mudio;
  • Memory Goverance замість Memory Governance;
  • Self-reflecrion замість Self-reflection;
  • CORE SYSEMS замість CORE SYSTEMS;
  • викривлений напис на дузі, схожий на FONDRATION замість FOUNDATION.

Є й змістові ознаки:
  • поняття розкладено по колах доволі хаотично;
  • змішані технології, можливості, результати й організаційні процеси;
  • визначення Agentic AI — «Automate entire processes with automation» тавтологічне й майже нічого не пояснює;
  • до LLM помилково віднесено загальні методи машинного навчання: Supervised Learning, Reinforcement Learning, CNNs тощо.

Кріплення, тіні та паперові картки лише імітують фотографію справжнього настінного стенда. Теоретично людина могла надрукувати створену ШІ схему й сфотографувати її, але найімовірніше ШІ згенерував одразу всю псевдофотографію.

Метаданих із назвою генератора у файлі немає, тому встановити конкретну модель неможливо.

А що саме хотіли цією схемою сказати?

Цією схемою намагалися показати поступове нарощування можливостей ШІ — від мовної моделі до автономної агентної системи.

Але щось пішло не так 😁 Далі буде наступний допис

© https://www.linkedin.com/feed/update/urn:li:activity:7493329870811262976


bga68comp: (Default)
Якщо шукаємо терміни, скорочення та визначення, які використовуються у стандартах і програмах PCI SSC, не обов’язково переглядати всі документи один за одним. Для цього можна скористатися офіційним глосарієм PCI SSC.

PCI SSC Glossary

PCI SSC Glossary — офіційний глосарій термінів, скорочень і абревіатур Ради зі стандартів безпеки індустрії платіжних карток.

Офіційне джерело

📎 PCI Security Standards Council Glossary

Що тут можна знайти

  • терміни та визначення, що використовуються у PCI DSS та інших документах PCI SSC;
  • скорочення й абревіатури: PCI DSS, CDE, CHD, SAD, AOC, ROC, SAQ, QSA, ASV, P2PE та інші;
  • терміни, пов’язані із захистом даних платіжних карток, автентифікацією, криптографією, журналюванням, управлінням ризиками та проведенням оцінювання PCI DSS;
  • посилання з одного терміна на пов’язані терміни або відповідні розділи документів PCI SSC;
  • абеткову навігацію від A до Z.

Як шукати

  1. Перейди на сторінку PCI SSC Glossary.
  2. Натисни Ctrl + F у Windows або Command + F у macOS.
  3. Введи англійський термін або скорочення, наприклад cardholder data, audit log, risk assessment, CDE чи QSA.
  4. Браузер знайде й підсвітить усі збіги на сторінці.
  5. Якщо точне написання терміна невідоме, введи його частину або скористайся абетковою навігацією.
  6. Перевір не лише саме визначення, а й примітки See, які спрямовують до пов’язаних термінів або документів.

На смартфоні потрібно відкрити меню браузера та вибрати команду «Знайти на сторінці».

Що потрібно зафіксувати

  • точне написання англійського терміна;
  • повну форму скорочення або абревіатури;
  • точне визначення;
  • застереження щодо контексту, наприклад For PCI DSS purposes;
  • посилання на пов’язані терміни або відповідний розділ документа PCI SSC;
  • посилання на сторінку глосарія або відповідний абетковий розділ.

Приклад результату


Термін: Cardholder Data (CHD)

Українською: дані держателя платіжної картки

Джерело: PCI SSC Glossary

Розділ: C

At a minimum, cardholder data consists of the full PAN.

Переклад: Щонайменше дані держателя платіжної картки складаються з повного PAN.

Важливо

  • окремого поля для пошуку саме в глосарії немає: поле Search у верхній частині сайту призначене для пошуку по всьому сайту PCI SSC;
  • для швидкого пошуку конкретного терміна найзручніше використовувати Ctrl + F або команду «Знайти на сторінці»;
  • прямі посилання ведуть до абеткового розділу, а не до окремого терміна;
  • деякі визначення застосовуються саме в контексті PCI DSS і можуть відрізнятися від визначень у ISO, NIST або інших джерелах;
  • якщо глосарій посилається на конкретний стандарт, розділ або програмний документ PCI SSC, для офіційного обґрунтування потрібно додатково перевірити це першоджерело.

Див. також

NIST. Зручний централізований пошук термінів
ISO OBP. Пряме посилання на пункт стандарту
ISO OBP, IEC, ITU, ETSI. Зручний централізований пошук термінів
ISO OBP, IEC, ITU, ETSI. Step-by-step search


bga68comp: (Default)
Національний банк України опублікував коротку версію документа «Єдина система візуальних елементів Національного банку України».

Це 12-сторінковий брендбук, у якому визначено правила використання логотипа та корпоративних кольорів Національного банку.

Що містить документ


  • будову логотипа та вимоги до його охоронного поля;
  • вертикальні й горизонтальні варіанти логотипа українською та англійською мовами;
  • кольорові та монохромні версії логотипа;
  • допустимі й недопустимі способи використання логотипа;
  • оптимальні та мінімальні розміри логотипа;
  • правила розміщення логотипа поряд з іншими логотипами та графічними об’єктами;
  • основну й додаткову корпоративні палітри.

Основні корпоративні кольори НБУ

  • #057B48 — зелений;
  • #4C4C4E — сірий;
  • #91C964 — світло-зелений.

Брендбук Національного банку України


Єдина система візуальних елементів Національного банку України
Джерело:
Єдина система візуальних елементів Національного банку України.


bga68comp: (Default)
У професійних текстах термін Secure by Design часто залишають без перекладу. Саме так його використовує й Міністерство цифрової трансформації України, називаючи Secure-by-Design базовим принципом побудови інформаційних систем.

Але як коректно передати цей термін українською?

Що означає Secure by Design

Це підхід, за якого вимоги безпеки враховують від самого початку створення системи та протягом усього її життєвого циклу, а не додають захисні засоби вже після розроблення продукту.

Тобто захищеність має бути закладена:
  • у вимоги до системи;
  • в її архітектуру;
  • у проєктні рішення;
  • у процеси розроблення і тестування;
  • у налаштування та подальше супроводження продукту.

Secure by Design означає не окремий захід захисту, а властивість системи, яка виникає завдяки свідомим рішенням, прийнятим під час її проєктування та розроблення.

Як перекласти термін

У цьому словосполученні:
  • secure — «захищений»;
  • by design — «за задумом», «закладений під час проєктування».

Слово design тут означає не зовнішній вигляд і не «дизайн», а задум, архітектуру та процес проєктування системи.

Тому варіант «безпечний за дизайном» є невдалим.

Рекомендований переклад

Для назви принципу доцільно використовувати такий варіант:

Secure by Design — захищеність, закладена під час проєктування.

Якщо потрібен короткий підпис, наприклад у схемі або таблиці, можна використати:

Secure by Design — захищений за задумом.

У розгорнутому тексті природно звучатиме:

підхід, за якого захищеність системи закладають ще під час її проєктування.

Наведена українська форма є змістовим відповідником, а не цитатою з офіційного українського нормативного документа. Тому під час першого використання доцільно залишити англійський оригінал у дужках:

захищеність, закладена під час проєктування (Secure by Design)

Не плутати із Secure by Default

Secure by Design стосується проєктування та всього життєвого циклу системи.

Secure by Default означає, що продукт уже постачається з найбезпечнішими налаштуваннями, які діють без додаткових дій користувача:

Secure by Default — захищений за замовчуванням.

Джерела

  1. CISA — Secure by Design.
  2. National Cyber Security Centre — Secure by design.
  3. Міністерство цифрової трансформації України — Secure-by-Design як базовий принцип побудови інформаційних систем.


bga68comp: (Default)

Як українською коректно перекласти «ticket» у Service Desk?


У робочому ІТ-сленгу слово «тікет» давно стало звичним. Але в офіційній документації, особливо якщо її можуть бачити аудитори, регулятор або зовнішні контрагенти, його краще не використовувати.

Універсального перекладу для ticket немає — він залежить від того, що саме реєструється.

  • ticket у Service Desk звернення;
  • incident ticket запис про інцидент або звернення щодо інциденту;
  • service request ticket заявка на обслуговування;
  • change ticket заявка на зміну;
  • access ticket заявка на надання або зміну доступу;
  • ticket number номер звернення або номер заявки;
  • create a ticket зареєструвати звернення або створити заявку;
  • close a ticket закрити звернення або закрити заявку.

«Звернення» чи «заявка»?


Тут є невелика, але важлива відмінність.

Заявка краще підходить для ситуацій, коли користувач або працівник просить виконати певну дію: надати доступ, встановити програму, внести зміну, виконати обслуговування.

Звернення — ширший термін. Воно може стосуватися інциденту, проблеми, запиту на обслуговування, консультації або іншої події, зареєстрованої в Service Desk.

Тому як загальний український термін для ticket у Service Desk найзручніше використовувати:
звернення

Наприклад, замість:
Створення тікета DEV-123 у Service Desk підрядника.

краще:
Реєстрація звернення DEV-123 у Service Desk підрядника.

Якщо ж ідеться про конкретний тип запиту, термін краще уточнювати:

  • реєстрація заявки на зміну;
  • реєстрація заявки на надання доступу;
  • реєстрація інциденту;
  • реєстрація запиту на обслуговування.

Отже, «тікет» можна залишити для неформального спілкування ІТ-фахівців, але в політиках, процедурах, схемах, технічних завданнях та документації для аудиту краще використовувати українські терміни «звернення», «заявка», «запис про інцидент» — залежно від контексту.


bga68comp: (Default)
45c97e31-f3f1-415d

Платіжні послуги: нормативно-правові акти, на які звертає увагу НБУ


Національний банк України зібрав нормативно-правові акти, що регулюють діяльність на ринку платіжних послуг, і розподілив їх за чотирма напрямами: загальне регулювання, ліцензування, нагляд та перевірки, звітність.

Нижче наведено цей перелік із прямими посиланнями на документи в базі «Законодавство України». Частина актів повторюється в кількох розділах, оскільки НБУ відносить їх одночасно до загального та спеціального регулювання.

Примітка. На сторінці НБУ неправильно зазначено дати двох документів: постанову № 249 прийнято 26 грудня 2022 року, а постанову № 12310 жовтня 2024 року. Нижче дати наведено за офіційними картками документів.

Загальне регулювання

  1. Конституція України від 28 червня 1996 року
  2. Цивільний кодекс України № 435-IV від 16 січня 2003 року
  3. Податковий кодекс України № 2755-VI від 2 грудня 2010 року
  4. Закон України «Про фінансові послуги та фінансові компанії» № 1953-IX від 14 грудня 2021 року
  5. Закон України «Про Національний банк України» № 679-XIV від 20 травня 1999 року
  6. Закон України «Про платіжні послуги» № 1591-IX від 30 червня 2021 року
  7. Закон України «Про валюту і валютні операції» № 2473-VIII від 21 червня 2018 року
  8. Закон України «Про державну реєстрацію юридичних осіб, фізичних осіб — підприємців та громадських формувань» № 755-IV від 15 травня 2003 року
  9. Закон України «Про аудит фінансової звітності та аудиторську діяльність» № 2258-VIII від 21 грудня 2017 року
  10. Закон України «Про основні засади забезпечення кібербезпеки України» № 2163-VIII від 5 жовтня 2017 року
  11. Закон України «Про запобігання та протидію легалізації (відмиванню) доходів, одержаних злочинним шляхом, фінансуванню тероризму та фінансуванню розповсюдження зброї масового знищення» № 361-IX від 6 грудня 2019 року
  12. Закон України «Про бухгалтерський облік та фінансову звітність в Україні» № 996-XIV від 16 липня 1999 року
  13. Закон України «Про рекламу» № 270/96-ВР від 3 липня 1996 року
  14. Закон України «Про захист прав споживачів» № 1023-XII від 12 травня 1991 року
  15. Постанова Правління НБУ від 29 грудня 2023 року № 200 «Про затвердження Положення про порядок здійснення адміністративного провадження, загальні вимоги до документів і порядок їх подання до Національного банку України в межах окремих процедур та внесення змін до деяких нормативно-правових актів Національного банку України»
  16. Постанова Правління НБУ від 29 грудня 2023 року № 199 «Про затвердження Положення про авторизацію надавачів фінансових послуг та умови здійснення ними діяльності з надання фінансових послуг»
  17. Постанова Правління НБУ від 20 грудня 2023 року № 172 «Про затвердження Положення про використання електронного підпису та електронної печатки»
  18. Постанова Правління НБУ від 26 грудня 2022 року № 249 «Про встановлення вимог до надання обмежених платіжних послуг»
  19. Постанова Правління НБУ від 7 жовтня 2022 року № 217 «Про затвердження Положення про порядок здійснення авторизації діяльності надавачів фінансових платіжних послуг та обмежених платіжних послуг»
  20. Постанова Правління НБУ від 17 серпня 2022 року № 181 «Про затвердження Положення про порядок розкриття інформації небанківськими надавачами платіжних послуг»
  21. Постанова Правління НБУ від 14 липня 2022 року № 147 «Про затвердження Правил зберігання, захисту, використання та розкриття таємниці надавачами платіжних послуг»
  22. Постанова Правління НБУ від 2 серпня 2022 року № 168 «Про затвердження Положення про залучення комерційних агентів для надання фінансових платіжних послуг»
  23. Постанова Правління НБУ від 29 липня 2022 року № 164 «Про затвердження Положення про порядок емісії та еквайрингу платіжних інструментів»
  24. Постанова Правління НБУ від 26 липня 2022 року № 158 «Про запровадження номера платіжного рахунку користувача та електронного гаманця в Україні»
  25. Постанова Правління НБУ від 24 серпня 2022 року № 187 «Про затвердження Положення про порядок здійснення оверсайту платіжної інфраструктури в Україні»
  26. Постанова Правління НБУ від 28 липня 2008 року № 216 «Про затвердження Положення про порядок виконання надавачами платіжних послуг платіжних інструкцій в іноземній валюті та банківських металах»
  27. Положення про здійснення установами фінансового моніторингу, затверджене постановою Правління НБУ від 28 липня 2020 року № 107
  28. Постанова Правління НБУ від 22 вересня 2022 року № 206 «Про затвердження Положення про застосування Національним банком України заходів впливу за порушення вимог законодавства, що регулює діяльність на платіжному ринку»
  29. Постанова Правління НБУ від 3 травня 2023 року № 58 «Про затвердження Положення про автентифікацію та застосування посиленої автентифікації на платіжному ринку»
  30. Постанова Правління НБУ від 25 листопада 2022 року № 233 «Про затвердження Положення про додаткові вимоги до договорів про надання платіжних послуг, укладених небанківськими надавачами платіжних послуг зі споживачами»
  31. Постанова Правління НБУ від 25 вересня 2018 року № 103 «Про затвердження Інструкції про порядок організації касової роботи банками та проведення платіжних операцій надавачами платіжних послуг в Україні»
  32. Постанова Правління НБУ від 10 жовтня 2024 року № 123 «Про затвердження Положення про вимоги до системи управління надавача фінансових платіжних послуг»
  33. Постанова Правління НБУ від 7 березня 2025 року № 29 «Про встановлення критеріїв визначення підприємств, установ, організацій, які мають важливе значення для галузі національної економіки, у сфері діяльності на платіжному ринку»
  34. Постанова Правління НБУ від 13 червня 2025 року № 64 «Про деякі питання визначення регулятивного капіталу небанківських надавачів платіжних послуг»
  35. Постанова Правління НБУ від 2 липня 2025 року № 71 «Про затвердження Положення про порядок страхування відповідальності надавачів нефінансових платіжних послуг перед користувачами та надавачами платіжних послуг з обслуговування рахунків»
  36. Постанова Правління НБУ від 2 липня 2025 року № 73 «Про затвердження Положення про вимоги до системи управління ризиками надавача нефінансових платіжних послуг та внесення зміни до Положення про вимоги до системи управління надавача фінансових платіжних послуг»
  37. Постанова Правління НБУ від 25 липня 2025 року № 81 «Про затвердження Положення про порядок здійснення авторизації діяльності надавачів нефінансових платіжних послуг та затвердження Змін до Положення про реєстрацію платіжних систем, учасників платіжних систем та технологічних операторів платіжних послуг»

Ліцензування

  1. Закон України «Про платіжні послуги» № 1591-IX від 30 червня 2021 року
  2. Постанова Правління НБУ від 7 жовтня 2022 року № 217 «Про затвердження Положення про порядок здійснення авторизації діяльності надавачів фінансових платіжних послуг та обмежених платіжних послуг»
  3. Постанова Правління НБУ від 29 грудня 2023 року № 199 «Про затвердження Положення про авторизацію надавачів фінансових послуг та умови здійснення ними діяльності з надання фінансових послуг»
  4. Постанова Правління НБУ від 4 вересня 2024 року № 105 «Про затвердження Положення про визнання належності послуги чи операції до фінансової / обмеженої платіжної послуги та виявлення здійснення безліцензійної діяльності на ринку небанківських фінансових послуг і платіжному ринку»
  5. Постанова Правління НБУ від 25 липня 2025 року № 81 «Про затвердження Положення про порядок здійснення авторизації діяльності надавачів нефінансових платіжних послуг та затвердження Змін до Положення про реєстрацію платіжних систем, учасників платіжних систем та технологічних операторів платіжних послуг»
  6. Постанова Правління НБУ від 28 серпня 2025 року № 103 «Про окремі питання, пов’язані з визначенням ознак еквайрингу платіжних інструментів»

Нагляд та перевірки


  1. Закон України «Про платіжні послуги» № 1591-IX від 30 червня 2021 року
  2. Постанова Правління НБУ від 5 травня 2023 року № 60 «Про затвердження Положення про здійснення Національним банком України безвиїзного нагляду на платіжному ринку за небанківськими надавачами платіжних послуг, надавачами обмежених платіжних послуг»
  3. Постанова Правління НБУ від 6 квітня 2023 року № 47 «Про затвердження Положення про проведення перевірок небанківських надавачів платіжних послуг, надавачів обмежених платіжних послуг»
  4. Постанова Правління НБУ від 22 вересня 2022 року № 206 «Про затвердження Положення про застосування Національним банком України заходів впливу за порушення вимог законодавства, що регулює діяльність на платіжному ринку»
  5. Постанова Правління НБУ від 4 вересня 2024 року № 105 «Про затвердження Положення про визнання належності послуги чи операції до фінансової / обмеженої платіжної послуги та виявлення здійснення безліцензійної діяльності на ринку небанківських фінансових послуг і платіжному ринку»

Звітність

  1. Закон України «Про бухгалтерський облік та фінансову звітність в Україні» № 996-XIV від 16 липня 1999 року
  2. Закон України «Про аудит фінансової звітності та аудиторську діяльність» № 2258-VIII від 21 грудня 2017 року
  3. Порядок подання фінансової звітності, затверджений постановою Кабінету Міністрів України від 28 лютого 2000 року № 419
  4. Постанова Правління НБУ від 25 листопада 2021 року № 123 «Про затвердження Правил складання та подання звітності учасниками ринку небанківських фінансових послуг до Національного банку України»
  5. Постанова Правління НБУ від 13 листопада 2018 року № 120 «Про затвердження Правил організації статистичної звітності, що подається до Національного банку України»

Джерело:
Національний банк України — Платіжні послуги


bga68comp: (Default)

Друзі, зверніть увагу — це серьозно

Сьогодні вранці отримую цілком звичайний на вигляд лист від Dreamwidth:

lol12121212 sent you a private message on Dreamwidth.

А всередині повідомлення:

Dreamwidth — Unusual login attempt

«Ми помітили вхід до вашого облікового запису Dreamwidth з нової IP-адреси або з пристрою, який ми не розпізнаємо.

Як стандартний захід безпеки ми тимчасово обмежили доступ до вашого облікового запису, доки не зможемо підтвердити вашу особу...

Щоб відновити повний доступ, увійдіть та підтвердьте, що цей вхід здійснили саме ви...»

І далі — посилання:

https://drw.help-page58193.world/230268873

Перша моя реакція була приблизно така:

Ого! Dreamwidth побачив якийсь підозрілий вхід до мого облікового запису?

А потім придивився уважніше.

І ось тут починається найцікавіше

Read more... )
Кроспост:
bga68
vijna


bga68comp: (Default)
Державна служба спеціального зв’язку та захисту інформації України

З метою забезпечення надійного та ефективного функціонування національної системи реагування на кіберзагрози Адміністрація Держспецзв’язку наказом від 8 червня 2026 року № 425 затвердила Порядок взаємодії галузевих та регіональних команд реагування на кіберінциденти, кібератаки, кіберзагрози (CSIRT) з національною командою CERT-UA, а також взаємодії приватних команд з іншими суб’єктами національної системи реагування.

CSIRT — Computer Security Incident Response Team, команда реагування на інциденти комп’ютерної безпеки.
CERT-UA — Computer Emergency Response Team of Ukraine, Урядова команда реагування на комп’ютерні надзвичайні події України.

Документ зареєстровано в Міністерстві юстиції України 30 червня 2026 року за № 954/46348. Нормативний акт розроблено на виконання постанови Кабінету Міністрів України від 13 листопада 2025 року № 1471.

Порядок регламентує механізми співпраці між CERT-UA, галузевими та регіональними CSIRT, а також приватними командами реагування, які можуть залучатися до виконання окремих завдань у сфері кібербезпеки.

Що встановлює Порядок

  • повноваження та функції кожної з команд у межах національної системи;
  • алгоритми обміну інформацією про виявлені кіберінциденти, кібератаки та поточні кіберзагрози;
  • правила координації спільних заходів реагування на кіберінциденти;
  • механізми обміну індикаторами кіберзагроз між учасниками системи;
  • порядок організації спільних навчань і тренувань для підвищення кваліфікації фахівців.

Запровадження нових правил має підвищити ефективність взаємодії суб’єктів національної системи кіберзахисту та посилити координацію спільних дій державних і приватних команд у протидії загрозам у кіберпросторі.

Джерела та нормативні документи
  1. Держспецзв’язку — Держспецзв’язку затвердила новий Порядок взаємодії команд реагування на кіберінциденти (CSIRT) із CERT-UA, 05.08.2026
  2. Верховна Рада України — наказ Адміністрації Держспецзв’язку від 08.06.2026 № 425
  3. Верховна Рада України — постанова Кабінету Міністрів України від 13.11.2025 № 1471


bga68comp: (Default)
Не будемо висловивлюватися надто категорично: «керівництво» не є неправильним українським словом, але в назві нормативно-методичного документа воно менш точне.

  • Керівництво — насамперед управління кимось або чимось: керівництво організації, здійснювати керівництво роботами. Також може означати склад керівників.
  • Настанова — документ, що містить рекомендації, принципи та пояснення щодо виконання певної діяльності.
  • Посібник — переважно навчальне або практичне видання.
  • Інструкція — конкретний, часто обов’язковий порядок дій.

Англійське Guide у назві NIST означає саме методичний документ, а не «керівництво» як управління. Тому найточніше:

Guide for Conducting Risk Assessments — Настанова щодо проведення оцінювання ризиків.

Варіант «Керівництво з проведення оцінювання ризиків» зрозумілий, але відчувається вплив російського «руководство по…» і гірше відповідає українській термінології стандартів.

NIST SP 800-30 Rev. 1, опублікована у вересні 2012 року.


Profile

bga68comp: (Default)
bga68comp

September 2026

S M T W T F S
  12 345
67 8910 1112
13141516 171819
20212223242526
27282930   

Syndicate

RSS Atom

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated 2026-09-21 23:46
Powered by Dreamwidth Studios