ORM (Object-Relational Mapping / Об’єктно-реляційне відображення) — це програмна технологія, яка дозволяє працювати з базою даних не напряму через SQL-запити, а через об’єкти мови програмування.

Простими словами:

Без ORM: ви пишете SELECT * FROM users WHERE id=1;
З ORM: ви пишете User.find(1) і отримуєте об’єкт User, з яким можна працювати у коді.

Де застосовується

ORM є проміжним шаром (layer) між додатком і БД.
Він транслює методи й властивості об’єктів у SQL-запити і назад.
Це робить код простішим, зручнішим у підтримці та менш залежним від конкретної СУБД.

Приклади ORM

Java: Hibernate, EclipseLink
.NET: Entity Framework
Python: SQLAlchemy, Django ORM
Ruby: ActiveRecord
PHP: Doctrine, Eloquent (Laravel)

🪟 На стартову сторінку

У ISO/IEC/IEEE 42010 (Systems and Software Engineering — Architecture Description) є два близькі, але різні поняття:

Viewpoint (точка зору)

Визначення: це "шаблон" або правило, яке пояснює як і для кого треба створювати архітектурне подання.
Він відповідає на питання: які інтереси стейкхолдера ми показуємо, яку інформацію включаємо, якими засобами (діаграми, таблиці, текст) описуємо.
Простими словами: viewpoint — це інструкція або рецепт для створення подання.

View (подання)

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

Приклад

Уявімо, що будуємо архітектуру для хмарної платформи:

Stakeholder (зацікавлена сторона)
- CIO (Chief Information Officer, директор з ІТ)
- Його concern (потреба): чи масштабована система і як забезпечено інтеграцію між додатками?
Viewpoint (точка зору на інтеграцію додатків)
- Назва: Application Communication Viewpoint
- Призначення: показати, як взаємодіють модулі та сервіси
- Мова: UML Component Diagram або ArchiMate Application Collaboration
- Яку інформацію включати: сервіси, API, протоколи, залежності
View (конкретне подання)
- Діаграма з Azure AD, веб-додатком на Ubuntu, RDS MySQL, інтеграцією з O365.
- Тут видно, що користувачі логіняться через Entra ID, доступ йде через API-шлюз, БД інтегрується через ORM-шар.
- Це вже готова картинка, яку CIO може подивитися.

🔹 Отже:

Viewpoint = каже: "покажи архітектуру додатків через компоненти і протоколи"
View = конкретна діаграма з вашим Entra ID, API Gateway і MySQL

🪟 На стартову сторінку

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

TOGAF дає методологію (ADM-фази, артефакти, каталоги, матриці), але іноді в ньому бракує гнучкості у формальному представленні результатів.
ISO/IEC/IEEE 42010 дає рамку опису архітектури: хто стейкхолдери, які їхні потреби (concerns), через які viewpoints ці потреби відображати, і у вигляді яких views це презентувати.
Якщо користуватися лише TOGAF — є ризик, що опис буде “каталог + текст”, але не зовсім зрозумілий різним групам зацікавлених сторін.
Якщо користуватися лише ISO 42010 — буде гарна структура “хто/що/для чого”, але без готових методичних кроків і артефактів (каталогів, матриць).

Комбінація TOGAF і ISO/IEC/IEEE 42010 методично сильніша, ніж використання кожного окремо: TOGAF забезпечує процес і набір артефактів, а ISO 42010 — формалізований спосіб представлення архітектури через стейкхолдерів, concerns і viewpoints. Разом вони дозволяють зробити опис не лише повним, а й зрозумілим для різних аудиторій.

Критерій	TOGAF	ISO/IEC/IEEE 42010	Разом (TOGAF + ISO 42010)
Призначення	Методологія розробки архітектури (ADM, фази, артефакти)	Рамка для опису архітектури (stakeholders, concerns, viewpoints, views)	Повний цикл: розробка + формалізований опис
Сильна сторона	Дає покроковий процес (ADM) і набір артефактів (каталоги, матриці)	Дає чітку структуру для комунікації з різними стейкхолдерами	Виходить і методика роботи, і методика подачі результатів
Слабка сторона	Може вийти занадто “всередину ІТ”, важко донести до нефахівців	Немає власної методики створення артефактів, лише правила їх опису	Компенсують слабкі сторони один одного
Фокус	Що і як робити (Data, Application, Technology, Business Architectures)	Як показати і пояснити (concerns, viewpoints, views)	І процес, і представлення зрозумілі й прозорі
Приклад результату	Каталоги даних, матриці застосунків, моделі потоків	Logical Data View, Security View, паспорти viewpoints	Каталоги + матриці (TOGAF), оформлені у views для різних стейкхолдерів (ISO 42010)

Таким чином, можна сказати так — разом вони дають повну картину:

TOGAF = як і що робити (ADM, каталоги, матриці).

ISO 42010 = як правильно це описати й донести (stakeholders, concerns, viewpoints, views).

Див. також:
⋄ Приклад опису архітектури системи згідно TOGAF → https://bga68comp.dreamwidth.org/787432.html

🪟 На стартову сторінку

Продовжуємо розбирати шаблони рівнів архітектури ІТ-систем. Це доповнення до опису архітектури за посиланнями:
• Приклад опису архітектури системи згідно TOGAF
• Побудова віртуальної інфраструктури на базі Microsoft Azure

✅ Опис інформаційної архітектури компанії
🖼️ Згідно з наданою схемою (RDS, Files, IIS Web Front/Back, AD DC1/DC2, VPN)

🧾 Інформаційна архітектура ІТ-системи компанії

🔹 1. Методологія

TOGAF 9.2, ADM, фаза C (Data Architecture): побудова інформаційного рівня архітектури.
ISO/IEC/IEEE 42010:2011: опис архітектури через зацікавлені сторони, погляди (views), моделі та відповідності.

🔹 2. Архітектурний контекст

Усі серверні ресурси компанії розміщені в тенанті Azure.
Користувачі підключаються до корпоративної мережі через захищені канали (VPN або Azure Bastion).
Робоче середовище реалізоване через RDS-сервер (DevSRV).
Веб-додатки розділені на фронт- (IIS Web Front) та бекенд (IIS Web Back).
Ідентифікація та авторизація забезпечуються двома доменними контролерами (AD DC1, DC2).

🔹 3. Архітектурні погляди (Views)

3.1 📡 Deployment View

DevSRV – RDS сервер для користувачів.
Files – файловий сервер зі спільними каталогами.
IIS Web Srv Front / Back – розподілення логіки веб-додатку.
AD DC1 / DC2 – розподілена автентифікація, DNS, GPO.
Всі ресурси ізольовані через NSG, Firewall, розміщені у VNet з Subnet-сегментацією.
Користувачі підключаються через захищений шлюз (VPN/Bastion).

3.2 🧩 Data Architecture View

Сутність даних	Опис
User Profile	Профілі користувачів, зберігаються в AD та RDS
File Object	Файли користувача на файловому сервері
DNS-записи	Зони та записи, керуються AD DC1/DC2
Web Session	Дані сесій на IIS Front
GPO Configuration	Групові політики, що застосовуються через AD
RDP Logs	Логи входів і дій у RDS

3.3 🔐 Access & Security View

RBAC на основі груп у AD.
GPO-політики: заборона USB, блокування локального диска, перенаправлення папок.
Шифрування: RDP over TLS, SMB over TLS.
Аудит: централізоване логування входів, дій на RDS.
Двофакторна автентифікація (MFA) через Azure AD / Conditional Access.
Firewall + NSG: розмежування Frontend, Backend, Infra.

3.4 🔄 Information Flow View

Звідки → Куди	Протокол	Захист
Користувач → RDS	RDP over TLS	VPN / MFA / GPO
RDS → Files	SMB 3.0	ACL + GPO + TLS
RDS → AD	LDAP/Kerberos	Шифрування, автентифікація
RDS → IIS Front/Back	HTTP/HTTPS	ACL, WAF, сегментація
RDS → DNS	DNS	ACL-захист зони

🔹 4. Зацікавлені сторони (Stakeholders)

Сторона	Інтерес
Користувачі	Стабільний і безпечний доступ до робочого середовища
Системні адміністратори	Централізоване управління політиками та файлами
Відділ ІБ	Впровадження GPO, аудит, захист інформації
Бізнес	Доступність сервісів, віддалена робота

🔹 5. Цільова модель та вдосконалення

Компонент	Поточна реалізація	Рекомендоване покращення
RDS	DevSRV на VM	Перехід до RDS Farm + Load Balancer
Files	Windows FS	Azure Files + Private Endpoint
MFA	Часткове	Універсальне MFA через Azure AD
AD	DC1 + DC2	Гібрид із Azure AD DS
IIS Front/Back	На VM	Azure App Service або контейнеризація

🔹 6. Узгодженість із ISO/IEC/IEEE 42010

Компонент	Відповідність
Stakeholders	Визначено
Architectural Views	Згруповано (Deployment, Security, Data)
Вимоги	Ураховані: доступність, безпека, контроль
Traceability	Показано зв’язок між цілями й рішеннями

✅ На останок:

Інформаційна архітектура побудована згідно з TOGAF ADM (фаза C) та структурована за стандартом ISO 42010.
Враховано як функціональні, так і нефункціональні вимоги: доступність, безпека, масштабованість.
Усі основні компоненти (RDS, Files, AD, IIS) інтегровані через захищені канали й управляються централізовано.

Annex:
🟠 Фази ADM (Architecture Development Method)

Preliminary Phase
Phase A: Architecture Vision
Phase B: Business Architecture
Phase C: Information Systems Architectures
Phase D: Technology Architecture
Phase E: Opportunities and Solutions
Phase F: Migration Planning
Phase G: Implementation Governance
Phase H: Architecture Change Management
Requirements Management

🪟 На стартову сторінку

Requirements and Testing Procedures. Guidelines

Вимоги та процедури тестування		Настанови
Визначені процедури тестування підходу	Визначені вимоги підходу	Мета Переміщення PAN на несанкціоновані носії є поширеним способом отримання цих даних і їх шахрайського використання. Методи, що гарантують, що лише особи з явним авторизованим правом і законною діловою необхідністю можуть копіювати або переміщувати PAN, знижують ризик доступу до PAN сторонніх осіб. Найкраща практика Копіювання та переміщення PAN повинно виконуватися лише на дозволені носії, які дозволені та санкціоновані для використання цією особою. Визначення Віртуальний робочий стіл є прикладом технології віддаленого доступу. Такі технології часто містять інструменти для блокування можливості копіювання та/або переміщення даних. Пристрої для збереження даних включають, але не обмежуються: - локальні жорсткі диски, - віртуальні диски, - знімні електронні носії, - мережеві накопичувачі та хмарне сховище. Додаткова інформація Документація постачальника для технологій віддаленого доступу може містити інформацію про налаштування системи, необхідні для виконання цієї вимоги.
3.4.2 При використанні технологій віддаленого доступу технічні засоби контролю повинні запобігати копіюванню та/або переміщенню PAN для всього персоналу, за винятком тих, хто має документоване, явне авторизоване право і законну, визначену ділову необхідність.	3.4.2.a Перевірити документовані політики та процедури та отримати докази наявності технічних засобів контролю, що запобігають копіюванню та/або переміщенню PAN за допомогою технологій віддаленого доступу на локальні жорсткі диски або знімні електронні носії, щоб підтвердити наступне: Технічні засоби контролю запобігають копіюванню та/або переміщенню PAN усім особам, які не мають спеціально наданого дозволу. Ведеться список персоналу, якому дозволено копіювати та/або переміщувати PAN, разом із документованим, явним дозволом і законною, визначеною діловою необхідністю.
Ціль налаштованого підходу
PAN не може бути скопійований або переміщений неавторизованими особами за допомогою технологій віддаленого доступу.
Примітки щодо застосування	3.4.2.b Перевірити конфігурацію налаштувань для технологій віддаленого доступу, щоб підтвердити наявність технічних засобів контролю, які блокують можливість копіювання та/або переміщення PAN для всього персоналу, крім тих, хто має дозвіл. 3.4.2.c Спостерігати за діями персоналу та перевірити, чи вони відповідають документованим політикам і вимогам, щоб підтвердити, що лише особи з дозволом мають можливість копіювати та/або переміщувати PAN за допомогою технологій віддаленого доступу.
Збереження або переміщення PAN на локальні жорсткі диски, знімні електронні носії та інші пристрої виводить ці пристрої в сферу дії PCI DSS. Ця вимога є найкращою практикою до 31 березня 2025 року, після чого вона стане обов’язковою і повинна бути повністю врахована під час оцінки PCI DSS.

🪟 На стартову сторінку

Вимоги до резервного копіювання та рекомендації щодо його реалізації висвітлено в різних стандартах серії ISO 27001-27099.

Стандарти:

ISO/IEC 27001 – визначає загальні вимоги до резервного копіювання (обов’язковий елемент СУІБ).
ISO/IEC 27002 – деталізує, як ці вимоги мають бути реалізовані.
ISO/IEC 27035 та 27040 – розкривають специфічні аспекти резервного копіювання в контексті управління інцидентами та безпеки зберігання.

Основними вимогами є такі:

1. ISO/IEC 27001:2022

Розділ:

A.8.10 (Резервне копіювання) – встановлює обов'язкові вимоги до організації резервного копіювання критичних даних та їх регулярного тестування.
Основні вимоги:
Ідентифікація інформації, що підлягає резервному копіюванню.
Встановлення регулярності створення резервних копій.
Захист резервних копій від несанкціонованого доступу.
Тестування можливості відновлення інформації.
Дотримання строків зберігання резервних копій відповідно до політик.

( Read more... )

🪟 На стартову сторінку

Скористайтеся наведеними нижче швидкими посиланнями для встановлення останньої версії .Net Framework. Щоб переглянути системні вимоги для .Net Framework перед встановленням, див. Системні вимоги (System Requirements). Довідку щодо усунення несправностей див. у розділі Усунення несправностей (Troubleshooting).

.NET Framework version	Installer (Developer Pack and Runtime)	Platform support
4.8.1	.NET Framework 4.8.1	Included in: Visual Studio 2022 (version 17.3) You can install on: Windows 11 Windows 10 version 21H2 Windows 10 version 21H1 Windows 10 version 20H2 Windows Server 2022 (for a full list, see system requirements)

🪟 На стартову сторінку

Щоб впроваджувати безпечні, надійні та ефективні хмарні сервіси, а також управляти ними відповідно до міжнародних вимог та кращих практик, нижче наведений перелік основних стандартів ISO/IEC:

1. ISO/IEC 17788:2014 — Інформаційні технології – Хмарні обчислення – Огляд та словник

Цей стандарт надає визначення ключових понять хмарних обчислень, таких як моделі надання послуг (SaaS, PaaS, IaaS) та моделі розгортання (публічна, приватна, гібридна хмара). Він забезпечує єдину термінологію для розробників і користувачів хмарних рішень.

2. ISO/IEC 17789:2014 — Архітектура хмарних обчислень

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

3. ISO/IEC 27017:2015 — Інформаційні технології – Методи забезпечення безпеки – Керівництво з безпеки для хмарних обчислень

Цей стандарт надає рекомендації щодо захисту інформації у хмарних середовищах, зокрема щодо конфіденційності, доступу до даних та управління ризиками.

4. ISO/IEC 27018:2019 — Захист персональних даних у хмарних обчисленнях

Він доповнює ISO/IEC 27001 та 27002, фокусуючись на захисті персональних даних в умовах хмарних обчислень. Стандарт описує заходи для забезпечення конфіденційності та відповідності вимогам до персональних даних.

5. ISO/IEC 19086 — Угоди про рівень надання послуг (SLA) для хмарних обчислень

Частина 1: Загальні концепції та структура — визначає загальні принципи створення та управління SLA.
Частина 2: Метрики рівня обслуговування — надає інструкції щодо метрик, які використовуються для оцінки якості хмарних сервісів.
Частина 3: Основні вимоги до SLA — описує основні вимоги, яким повинні відповідати SLA.
Частина 4: Метрики безпеки — описує метрики, що пов'язані із забезпеченням безпеки в угодах SLA.

6. ISO/IEC 27001 — Система управління інформаційною безпекою (ISMS)

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

7. ISO/IEC 38500 — Корпоративне управління ІТ

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

🪟 На стартову сторінку

Архітектура будь-якої ІТ-системи зазвичай складається з чотирьох загальних рівнів, які відповідають вимогам TOGAF (The Open Group Architecture Framework) та ISO 27001 (система управління інформаційною безпекою). Ці рівні також узгоджуються з життєвим циклом ІТ-систем. Вони включають:

Бізнес-архітектура:
- Описує бізнес-процеси, функції, організаційну структуру та ключові бізнес-стратегії.
- У рамках TOGAF цей рівень визначає, як ІТ-система підтримує бізнес-цілі.
- Відповідно до ISO 27001, бізнес-архітектура враховує вимоги щодо безпеки, що необхідні для досягнення бізнес-цілей.
Інформаційна архітектура:
- Охоплює структуру даних та управління інформацією, включаючи моделі даних, потоки інформації та логіку бізнес-процесів.
- TOGAF забезпечує інтеграцію інформаційної архітектури з бізнес-архітектурою.
- ISO 27001 зосереджує увагу на захисті інформаційних активів на цьому рівні.
Архітектура додатків:
- Визначає програмні компоненти, інтерфейси, інтеграцію систем та взаємодію між різними додатками.
- TOGAF акцентує увагу на сумісності та масштабованості додатків.
- ISO 27001 включає вимоги до безпеки додатків, наприклад, контроль доступу та захист від загроз.
Технологічна архітектура:
- Включає технічну інфраструктуру, включаючи сервери, мережеве обладнання, системи зберігання даних, та забезпечення їхньої надійності та безпеки.
- TOGAF пропонує розробку технологічної архітектури для підтримки попередніх рівнів.
- ISO 27001 забезпечує впровадження технічних засобів безпеки, таких як шифрування, контроль доступу та моніторинг безпеки.

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

Таблиця, яка відображає чотири рівні архітектури ІТ-системи з більш детальними вимогами відповідно до TOGAF та ISO 27001:

Рівень архітектури	Опис	Вимоги TOGAF	Вимоги ISO 27001
Бізнес-архітектура	Описує бізнес-процеси, функції, організаційну структуру та ключові бізнес-стратегії.	- Визначення бізнес-процесів та функцій. - Вирівнювання ІТ-стратегії з бізнес-цілями. - Моделювання бізнес-процесів. - Визначення ключових показників ефективності (KPI).	- Визначення вимог до інформаційної безпеки з боку бізнесу. - Аналіз ризиків для бізнес-процесів. - Інтеграція вимог безпеки в бізнес-процеси. - Встановлення ролей та відповідальності.
Інформаційна архітектура	Охоплює структуру даних та управління інформацією, включаючи моделі даних, потоки інформації та логіку бізнес-процесів.	- Моделювання інформаційних потоків. - Визначення інформаційних об'єктів та їх відносин. - Підтримка цілісності та доступності даних. - Забезпечення інтеграції інформації між бізнес-процесами.	- Захист конфіденційності, цілісності та доступності інформації. - Управління класифікацією інформації. - Впровадження політик захисту інформації. - Оцінка та управління ризиками для інформаційних активів.
Архітектура додатків	Визначає програмні компоненти, інтерфейси, інтеграцію систем та взаємодію між різними додатками.	- Проектування архітектури додатків з урахуванням бізнес-архітектури. - Забезпечення масштабованості та сумісності. - Визначення інтерфейсів та протоколів. - Моделювання життєвого циклу додатків.	- Контроль доступу до додатків. - Забезпечення захисту від загроз і вразливостей. - Впровадження криптографічних заходів. - Ведення аудиту та моніторинг безпеки додатків.
Технологічна архітектура	Включає технічну інфраструктуру, включаючи сервери, мережеве обладнання, системи зберігання даних, та забезпечення їхньої надійності та безпеки.	- Визначення технічних стандартів та платформ. - Підтримка сумісності між компонентами. - Проектування інфраструктури для забезпечення високої доступності та відмовостійкості. - Підтримка масштабованості інфраструктури.	- Впровадження засобів шифрування. - Забезпечення фізичної та технічної безпеки. - Моніторинг та реагування на інциденти. - Використання технологій захисту мережі (брандмауери, VPN, IDS/IPS).

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

💻 На головну сторінку

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

№	Вимога	Де міститься
1	Забезпечення захисту електронних банківських документів	Постанова НБУ №95 "Про затвердження Правил організації захисту електронних банківських документів у банках України"
2	Вимоги до зберігання, обробки та передачі електронних документів	Постанова НБУ №95 "Про затвердження Правил організації захисту електронних банківських документів у банках України"
3	Вимоги до електронної взаємодії банків	Постанова НБУ №75 "Про затвердження Правил електронної взаємодії банків у банківській системі України"
4	Впровадження системи управління інформаційною безпекою (ISMS)	ISO/IEC 27001
5	Застосування конкретних заходів інформаційної безпеки	ISO/IEC 27002
6	Використання електронних підписів та електронних печаток	Закон України "Про електронні довірчі послуги"
7	Забезпечення комплексного підходу до захисту інформації	ISO/IEC 27001
8	Управління ІТ-процесами для забезпечення інформаційної безпеки	COBIT
9	Вимоги до інформаційної безпеки банківської системи	Постанова НБУ №43 "Про затвердження Положення про інформаційну безпеку в банківській системі України"
10	Методичні рекомендації щодо управління інформаційною безпекою	Методичні рекомендації НБУ щодо управління інформаційною безпекою
11	Дотримання вимог щодо легітимності електронного документообігу	Закон України "Про електронні довірчі послуги"

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

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

1. Накази та рішення НБУ

Постанова НБУ №95 "Про затвердження Правил організації захисту електронних банківських документів у банках України" (затверджена 18 березня 2019 р.): Ця постанова визначає основні вимоги до захисту електронних банківських документів, включаючи вимоги до зберігання, обробки та передачі таких документів.
Постанова НБУ №75 "Про затвердження Правил електронної взаємодії банків у банківській системі України" (затверджена 12 квітня 2021 р.): Ця постанова встановлює вимоги до електронної взаємодії банків, включаючи питання захисту інформації та електронних документів.
Постанова НБУ №43 "Про затвердження Положення про інформаційну безпеку в банківській системі України": Документ містить вимоги до забезпечення інформаційної безпеки в банківській системі, які необхідно враховувати під час впровадження електронного документообігу.

2. Стандарти інформаційної безпеки

ISO/IEC 27001: Стандарт, що встановлює вимоги до системи управління інформаційною безпекою (ISMS). Впровадження цього стандарту допомагає забезпечити комплексний підхід до захисту інформації, що є критично важливим при впровадженні електронного документообігу.
ISO/IEC 27002: Кодекс практик з управління інформаційною безпекою, який є доповненням до ISO/IEC 27001 і містить конкретні заходи безпеки, що можуть бути застосовані в процесі захисту електронних документів.
COBIT (Control Objectives for Information and Related Technologies): Це фреймворк для управління IT і інформаційною безпекою, який надає кращі практики для управління та контролю над ІТ-процесами, включаючи електронний документообіг.

3. Інші нормативні акти та рекомендації

Закон України "Про електронні довірчі послуги": Регулює питання використання електронних підписів, електронних печаток та інших електронних довірчих послуг, що є основою для легітимності електронного документообігу.
Методичні рекомендації НБУ щодо управління інформаційною безпекою: Ці рекомендації надають конкретні вказівки щодо впровадження системи інформаційної безпеки в банківській системі України.

Дотримання вищезазначених нормативних актів та стандартів є важливим для забезпечення надійного та безпечного електронного документообігу в банківських установах.

Детальні вимоги за кожною із загальних категорій:

№	Вимога	Де міститься	Деталі вимоги
1	Забезпечення захисту електронних банківських документів	Постанова НБУ №95 "Про затвердження Правил організації захисту електронних банківських документів у банках України"	Встановлення вимог до конфіденційності, цілісності та доступності даних; використання криптографічного захисту.
2	Вимоги до зберігання, обробки та передачі електронних документів	Постанова НБУ №95	Визначення процедур шифрування даних, резервного копіювання, обмеження доступу, журналювання дій з документами.
3	Вимоги до електронної взаємодії банків	Постанова НБУ №75	Використання захищених каналів зв’язку; автентифікація сторін; захист від несанкціонованого доступу та модифікації даних.
4	Впровадження системи управління інформаційною безпекою (ISMS)	ISO/IEC 27001	Визначення політики інформаційної безпеки; оцінка ризиків; управління інцидентами; аудит та моніторинг системи безпеки.
5	Застосування конкретних заходів інформаційної безпеки	ISO/IEC 27002	Використання заходів контролю доступу; управління активами; шифрування; безпека людських ресурсів; фізична безпека.
6	Використання електронних підписів та електронних печаток	Закон України "Про електронні довірчі послуги"	Використання кваліфікованих електронних підписів та печаток; забезпечення їх юридичної сили та достовірності.
7	Забезпечення комплексного підходу до захисту інформації	ISO/IEC 27001	Включення всіх аспектів управління інформацією: фізична, логічна, організаційна та технічна безпека.
8	Управління ІТ-процесами для забезпечення інформаційної безпеки	COBIT	Визначення ключових показників ефективності (KPI) для ІТ-безпеки; інтеграція управління ризиками в ІТ-процеси.
9	Вимоги до інформаційної безпеки банківської системи	Постанова НБУ №43	Визначення обов’язкових процедур і політик для захисту банківської інформації; регулярний перегляд і оновлення безпекових заходів.
10	Методичні рекомендації щодо управління інформаційною безпекою	Методичні рекомендації НБУ щодо управління інформаційною безпекою	Рекомендації щодо оцінки ризиків, управління інцидентами, організації безперервного моніторингу та аудиту інформаційної безпеки.
11	Дотримання вимог щодо легітимності електронного документообігу	Закон України "Про електронні довірчі послуги"	Вимоги до надання юридичної сили електронним документам; відповідність технічним і правовим стандартам електронних підписів і печаток.

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

💻 На головну сторінку

функціональні вимоги до системи DLP (Data Loss Prevention):

Контроль і моніторинг всіх каналів передачі даних:
- Система повинна підтримувати різні канали передачі даних, такі як електронна пошта, веб-браузери, месенджери, знімні носії, принтери, хмарні сервіси та мобільні пристрої.
- Необхідно забезпечити контроль даних як у спокої (в системах зберігання), так і в русі (під час передачі через мережу або перенесення на зовнішні пристрої).
Аналіз вмісту і контексту:
- Система повинна вміти аналізувати вміст файлів, повідомлень і даних на предмет конфіденційної інформації, такої як особисті дані (PII), фінансові дані та інтелектуальна власність.
- Контекстний аналіз має враховувати інформацію про те, хто, коли і як взаємодіє з даними, включаючи місце розташування та пристрій.
Класифікація і маркування даних:
- Дані повинні класифікуватися як автоматично, так і вручну на основі їх вмісту, контексту та політик.
- Необхідна інтеграція з системами класифікації та маркування даних, такими як Microsoft Information Protection.
Створення і управління політиками безпеки:
- Можливість створювати гнучкі політики безпеки для різних категорій даних і користувачів.
- Підтримка шаблонів політик і управління ними через централізовану консоль, включаючи автоматичне застосування змін у реальному часі.
Ідентифікація і блокування витоків даних:
- Система повинна виявляти спроби витоку даних і мати можливість автоматичної блокування або обмеження доступу.
- Реакція на інциденти може включати сповіщення адміністратора, попередження користувача, ведення журналу подій, тимчасове або постійне блокування операції.
Журналювання і звітність:
- Ведення журналів усіх подій, пов'язаних із доступом, передачею та зміною даних.
- Створення звітів по інцидентах, дотриманню політик та активності користувачів.
- Можливість налаштування звітів під конкретні вимоги організації або нормативів.
Інтеграція з іншими системами безпеки:
- Підтримка інтеграції з SIEM-системами, антивірусами, рішеннями по управлінню правами доступу (IAM), системами виявлення загроз та іншими інструментами безпеки.
- Можливість взаємодії з існуючими системами управління інцидентами та реагування на них.
Аналіз поведінки користувачів (UBA):
- Аналіз поведінки користувачів і виявлення аномалій, які можуть свідчити про потенційні загрози (наприклад, незвичайні обсяги переданих даних або нетипові дії користувача).
- Інтеграція з системами машинного навчання для прогнозування і запобігання загрозам на основі історичних даних.
Управління доступом і авторизація:
- Підтримка багатофакторної автентифікації і ролей на основі прав доступу для управління тим, хто і як може взаємодіяти з системою DLP та захищеними даними.
- Гнучкість налаштування рівнів доступу залежно від ролі користувача і контексту.
Підтримка роботи з зашифрованими даними:
- Можливість аналізу і контролю даних, зашифрованих з використанням різних алгоритмів і протоколів.
- Інтеграція з системами управління ключами для дешифрування і аналізу даних.
Оновлення і адаптація до нових загроз:
- Регулярні оновлення системи для захисту від нових типів загроз і уразливостей.
- Можливість додавання і оновлення політик, шаблонів і правил у відповідь на зміни в нормативних вимогах і бізнес-середовищі.
Управління інцидентами і реагування:
- Наявність інструментів для управління інцидентами, включаючи створення інцидентних карт, автоматичне сповіщення і можливість швидкого реагування.
- Інтеграція з системами реагування на інциденти для координації і автоматизації дій по усуненню загроз.

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

💻 На головну сторінку

Документи, які потрібно розглянути та прийняти організації перед впровадженням системи DLP з юридичної точки зору, відповідно до стандарту ISO 27001 і законів України:

1. Документи, пов'язані з законодавством України

1.1. Положення про захист персональних даних

Зміст: Документ, що описує, як організація збирає, обробляє, зберігає та захищає персональні дані, включаючи права суб'єктів даних та обов'язки організації.
Законодавство: Закон України "Про захист персональних даних".

1.2. Політика інформаційної безпеки

Зміст: Документ, що визначає загальні підходи та заходи для захисту інформації в організації, включаючи вимоги до системи DLP.
Законодавство: Закон України "Про основи забезпечення кібербезпеки України".

1.3. Регламент обробки персональних даних

Зміст: Документ, що деталізує процеси обробки персональних даних відповідно до національного законодавства.
Законодавство: Закон України "Про захист персональних даних".

1.4. Політика конфіденційності

Зміст: Документ, що інформує суб'єктів даних про те, як їх персональні дані збираються, використовуються та захищаються, а також про права суб'єктів даних.
Законодавство: Закон України "Про захист персональних даних".

1.5. Угода про конфіденційність (NDA)

Зміст: Документ, що встановлює зобов'язання співробітників та контрагентів щодо нерозголошення конфіденційної інформації та персональних даних.
Законодавство: Закон України "Про захист персональних даних", Закон України "Про комерційну таємницю".

1.6. Порядок реагування на інциденти безпеки

Зміст: Документ, що регламентує дії співробітників і керівництва при виявленні інцидентів інформаційної безпеки, включаючи витоки даних.
Законодавство: Закон України "Про основи забезпечення кібербезпеки України".

2. Документи, пов'язані з ISO 27001

2.1. Політика інформаційної безпеки (Information Security Policy)

Зміст: Основоположний документ, що описує зобов'язання керівництва щодо забезпечення інформаційної безпеки, цілі безпеки, обсяги застосування та основні принципи захисту інформації.
Стандарти: Пункт 5.2 "Політика інформаційної безпеки".

2.2. Оцінка ризиків (Risk Assessment)

Зміст: Документ, що описує процес ідентифікації, аналізу та оцінки ризиків для інформаційної безпеки, включаючи ризики, пов'язані з витоками даних.
Стандарти: Пункти 6.1.2 "Оцінка ризиків в області інформаційної безпеки" та 6.1.3 "Обробка ризиків в області інформаційної безпеки".

2.3. Методика управління ризиками (Risk Treatment Plan)

Зміст: Документ, що визначає заходи щодо зниження, передачі, уникнення або прийняття ризиків, пов'язаних з інформаційною безпекою, і описує, як система DLP може допомогти в управлінні цими ризиками.
Стандарти: Пункт 6.1.3 "Обробка ризиків в області інформаційної безпеки".

2.4. Декларація застосовності (Statement of Applicability, SoA)

Зміст: Документ, що підтверджує, які з рекомендованих контролів інформаційної безпеки ISO 27001 організація впровадила і чому.
Стандарти: Пункт 6.1.3 "Обробка ризиків в області інформаційної безпеки".

2.5. План неперервності бізнесу (Business Continuity Plan)

Зміст: Документ, що описує процедури для забезпечення неперервності бізнес-процесів у випадку інцидентів, включаючи витоки даних.
Стандарти: Пункт 17 "Аспекти інформаційної безпеки в управлінні неперервністю бізнесу".

2.6. Політика управління доступом (Access Control Policy)

Зміст: Документ, що описує правила та процедури для управління доступом до інформаційних активів, включаючи налаштування та управління доступом у системі DLP.
Стандарти: Пункт 9.4 "Управління доступом".

2.7. Журнали та контрольні журнали (Logging and Monitoring)

Зміст: Документ, що описує процедури ведення та аналізу журналів, а також моніторингу подій інформаційної безпеки, включаючи використання системи DLP для відстеження витоків даних.
Стандарти: Пункт 12.4 "Логування та моніторинг".

3. Документи, пов'язані з внутрішніми процесами та регламентами

3.1. Інструкції по роботі з системою DLP

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

3.2. Технічні політики та процедури

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

3.3. Положення про захист комерційної таємниці

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

4. Додаткові документи

4.1. Угоди з підрядниками та партнерами

Зміст: Угоди, що містять положення про захист даних, зобов'язання щодо використання системи DLP та відповідальність за витік даних.

4.2. Документовані докази відповідності

Зміст: Журнали аудитів, результати оцінки ризиків та інші документи, що підтверджують, що організація дотримується вимог законодавства та стандарту ISO 27001.

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

💻 На головну сторінку

Якщо розглядати Політику антивірусного захисту з урахуванням COBIT, то маємо на увазі наступне:

COBIT (Control Objectives for Information and Related Technology) — це фреймворк управління ІТ, розроблений для забезпечення зв’язку між ІТ-цілями та бізнес-цілями. COBIT охоплює безліч аспектів ІТ-управління, включаючи управління ризиками, безпеку, контроль і відповідність вимогам.
Антивірусний захист у контексті COBIT може розглядатися в рамках доменів, пов’язаних з управлінням ризиками та забезпеченням інформаційної безпеки. Ось ключові розділи та процеси COBIT, які стосуються антивірусного захисту:

APO12 - Управління ризиками (Risk Management)
- У цьому процесі COBIT описується необхідність ідентифікації, оцінки та управління ІТ-ризиками, що включає загрози безпеки, такі як віруси та шкідливе ПЗ. Антивірусний захист розглядається як одна з заходів для зменшення ризиків.
DSS05 - Управління безпекою (Manage Security Services)
- Цей процес включає забезпечення інформаційної безпеки шляхом реалізації та підтримання заходів захисту, таких як антивірусні рішення, брандмауери та інші механізми захисту.
DSS01 - Управління операційними ІТ-послугами (Manage Operations)
- Операційні процеси управління ІТ можуть включати моніторинг і управління антивірусним захистом як частину загальних ІТ-послуг.
BAI09 - Управління конфігурацією (Manage Configuration)
- Антивірусні програми повинні бути правильно сконфігуровані та оновлені, що також стосується управління конфігурацією ІТ-інфраструктури.

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

💻 На головну сторінку

Які накази і рішення НБУ стосуються дотримання вимог в контексті захисту платіжних систем та фінансових даних?

Національний банк України (НБУ) видав ряд нормативних актів, які регулюють питання захисту платіжних систем і фінансових даних. Ці акти встановлюють вимоги до інформаційної безпеки, включаючи дотримання міжнародних стандартів, таких як PCI DSS. Нижче наведено основні накази і рішення НБУ, що стосуються цього питання:

1. Постанова НБУ №95 "Про затвердження Положення про здійснення захисту інформації та кібербезпеки в банківській системі України"

Дата прийняття: 28 вересня 2022 року
Опис: Ця постанова встановлює вимоги до забезпечення інформаційної безпеки та кібербезпеки в банківській системі України. Вона регулює порядок захисту інформації, яка обробляється в банках і фінансових установах, включаючи захист платіжних даних. Постанова зобов'язує банки впроваджувати системи управління інформаційною безпекою, відповідати міжнародним стандартам (включаючи PCI DSS), а також забезпечувати кіберзахист своїх інформаційних систем.

2. Постанова НБУ №75 "Про затвердження Положення про захист інформації та кібербезпеки в платіжних системах"

Дата прийняття: 21 червня 2019 року
Опис: Ця постанова регламентує вимоги до захисту інформації в платіжних системах, а також визначає правила захисту фінансових даних, які обробляються в цих системах. Положення зобов’язує операторів платіжних систем, платіжних інфраструктурних сервісів, а також їхніх учасників дотримуватися вимог до безпеки даних, включаючи стандарти PCI DSS.

3. Постанова НБУ №56 "Про організацію захисту інформації в банках України"

Дата прийняття: 14 липня 2006 року (з подальшими змінами)
Опис: Постанова регулює загальні питання організації захисту інформації в банках України. Вона включає вимоги до створення систем захисту інформації, управління ризиками, моніторингу та аудиту безпеки, а також захисту фінансових даних, що обробляються банками.

4. Постанова НБУ №391 "Про затвердження Положення про здійснення нагляду (оверсайта) за платіжними системами"

Дата прийняття: 30 жовтня 2018 року
Опис: Цей документ регламентує порядок нагляду за платіжними системами та їхніми учасниками з боку НБУ. Постанова встановлює вимоги до дотримання стандартів безпеки, зокрема щодо захисту інформації та забезпечення кібербезпеки в платіжних системах.

5. Рішення НБУ щодо підвищення стандартів кібербезпеки в банківській системі України

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

6. Листи та роз'яснення НБУ щодо дотримання стандартів інформаційної безпеки

Опис: НБУ періодично надсилає листи та роз'яснення щодо необхідності дотримання стандартів інформаційної безпеки, включаючи PCI DSS. Ці документи можуть містити рекомендації щодо кращих практик у сфері захисту платіжних даних та кібербезпеки.

Ці нормативні акти та рішення регламентують захист платіжних систем і фінансових даних, забезпечуючи безпеку та надійність банківської системи України. Банки та фінансові установи зобов'язані дотримуватися цих вимог і забезпечувати відповідність міжнародним стандартам, включаючи PCI DSS.

Також дивись:
→ Про PCI DSS 4.0

Які накази і рішення НБУ стосуються дотримання вимог в контексті захисту платіжних систем та фінансових даних?

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

1. Постанова Правління НБУ № 243 від 4 липня 2007 року (зі змінами та доповненнями)

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

2. Постанова Правління НБУ № 351 від 28 вересня 2021 року

Назва: "Про затвердження Положення про порядок організації захисту інформації та кіберзахисту в банківській системі України".
Опис: Ця постанова регулює питання організації інформаційної безпеки та кіберзахисту в банках України, включаючи вимоги до систем захисту платіжних даних, управління ризиками та дотримання міжнародних стандартів, таких як PCI DSS.

3. Постанова Правління НБУ № 95 від 3 грудня 2018 року

Назва: "Про затвердження Положення про захист інформації в платіжних системах і розрахункових операціях".
Опис: Ця постанова встановлює вимоги до захисту інформації в платіжних системах, включаючи вимоги щодо безпеки обробки, зберігання та передачі платіжних даних.

4. Постанова Правління НБУ № 518 від 28 вересня 2020 року

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

5. Рішення НБУ про захист даних під час дистанційного банківського обслуговування

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

6. Методичні рекомендації НБУ

Назва: "Методичні рекомендації щодо забезпечення захисту інформації в банківських установах України".
Опис: Ці рекомендації надають банкам керівництво щодо впровадження заходів інформаційної безпеки та дотримання вимог міжнародних стандартів, таких як PCI DSS.

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

Також дивись:
→ Про PCI DSS 4.0

Як сформувати вимогу до інтеграції програмного забезпечення з якимось глобальним каталогом, наприклад, з Active Directory чи Microsoft Entra ID?

© Керування обліковими записами користувачів має відповідати вимогам платформи ідентифікації Microsoft v2.0 (Microsoft Identity Platform v2.0) за допомогою стандартних протоколів автентифікації (OpenID Connect, SAML) і авторизації (OAuth 2.0).

Дивись також:
→ Вимога до інтеграції ПЗ з Active Directory

Як сформувати вимоги до інтеграції програмного забезпечення з якимось глобальним каталогом, наприклад, з Active Directory чи Microsoft Entra ID?

Вимоги до інтеграції програмного забезпечення з глобальним каталогом, таким як Active Directory (AD) або Microsoft Entra ID (раніше Azure Active Directory), зазвичай включають декілька аспектів, які можуть відрізнятися залежно від конкретних вимог системи, середовища та організаційних політик. Ось приклад формулювання такої вимоги:

Вимога до інтеграції з Active Directory (AD) або Microsoft Entra ID

Аутентифікація та авторизація користувачів:
- Програмне забезпечення повинно підтримувати аутентифікацію користувачів через Active Directory або Microsoft Entra ID, використовуючи стандартні протоколи (наприклад, LDAP, Kerberos, OAuth 2.0, OpenID Connect).
- Програмне забезпечення повинно забезпечувати авторизацію доступу користувачів на основі груп та ролей, визначених у Active Directory або Microsoft Entra ID.
Єдиний вхід (Single Sign-On, SSO):
- Програмне забезпечення повинно забезпечувати підтримку єдиного входу (SSO) з використанням Active Directory Federation Services (ADFS) або Microsoft Entra ID, щоб користувачі могли входити в систему без необхідності повторного введення облікових даних.
Синхронізація користувачів і груп:
- Програмне забезпечення повинно мати можливість автоматичної синхронізації користувачів, груп та інших атрибутів з Active Directory або Microsoft Entra ID для забезпечення актуальності даних користувачів.
Управління правами доступу:
- Програмне забезпечення повинно дозволяти керувати доступом до ресурсів на основі атрибутів користувачів, отриманих з Active Directory або Microsoft Entra ID.
- Механізми управління доступом повинні бути гнучкими, дозволяючи адміністратору визначати правила доступу, які відповідають політикам безпеки організації.
Журнали та моніторинг:
- Програмне забезпечення повинно мати функції журналювання подій, пов'язаних з аутентифікацією та авторизацією користувачів через Active Directory або Microsoft Entra ID.
- Всі дії користувачів, пов'язані з доступом до ресурсів програмного забезпечення, повинні бути зареєстровані та доступні для моніторингу та аудиту.
Відмовостійкість та безпека:
- Інтеграція повинна бути налаштована так, щоб забезпечити відмовостійкість та безперервність доступу користувачів до системи, навіть у випадку проблем з підключенням до Active Directory або Microsoft Entra ID.
- Програмне забезпечення повинно підтримувати шифрування даних під час обміну з Active Directory або Microsoft Entra ID для забезпечення безпеки інформації.

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

Див.також:
→ Вимога до інтеграції програмного забезпечення. OAuth 2.0

Использование управления привилегиями конечных точек с Microsoft Intune

Источник:
learn.microsoft.com/ru-ru/mem/intune/protect/epm-overview

Требования клиента Windows
Endpoint Privilege Management имеет следующие требования к операционной системе:

Windows 11 версии 22H2 (22621.1344 или более поздней) с KB5022913
Windows 11 версии 21H2 (22000.1761 или более поздней) с KB5023774
Windows 10 версии 22H2 (19045.2788 или более поздней) с KB5023773
Windows 10 версии 21H2 (19044.2788 или более поздней) с KB5023773
Windows 10 версии 20H2 (19042.2788 или более поздней) с KB5023773

https://docs.microsoft.com/en-us/lifecycle/system-requirements

Правила составления Software requirements specification

Перепечатка.

Все мы прекрасно знаем о том, как разрабатывается ПО. ~~Подумали 10 минут и сразу пошли кодить~~. Цикл создания программного обеспечения состоит из многих ключевых моментов. Это такие моменты как планирование, создания архитектуры, создание SRS, создание дизайна и тд и тп.

Что такое SRS ?

SRS — Software Requirement Specification — специальная документация для ПО которая содержит в себе информацию о том, как должна себя вести система, какие функции должна выполнять, какую нагрузку должна выдерживать и тд.

Зачем оно надо ?

Все предельно просто. Вы используете ТЗ (велосипед), я использую SRS (машину). Надеюсь аналогия получилась ясная? :)

Структура SRS

Ниже приведена структура на англ языке в raw виде. Чуть ниже в статье мы рассмотрим каждый пункт более подробно

Introduction
- Purpose
- Document conventions
- Intended Audience and Reading Suggestions
- Project scope
- References

Overall Description
- Product perspective
- Product features
- User classes and characteristics
- Operating environment
- Design and implementation constraints
- User documentation
- Assumptions and dependencies

System features
- System feature X (таких блоков может быть несколько)
  - Description and priority
  - Stimulus/Response sequences
  - Functional requirements

External interface requirements
- User interfaces
- Software interfaces
- Hardware interfaces
- Communication interfaces

Non functional requirements
- Performance requirements
- Safety requirements
- Software quality attributes
- Security requirements

( Read more... )

Profile

bga68comp

March 2026

S	M	T	W	T	F	S
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

Syndicate

Page Summary

ORM
ISO/IEC/IEEE 42010: Viewpoint & View
TOGAF vs ISO 42010 vs Разом
Інформаційна архітектура ІТ-системи компанії. Приклад
PCI DSS. Вимоги до DLP
Вимоги до резервного копіювання
Install .NET Framework for developers
Вимоги до хмарних сервісів у стандартах ІБ
З яких рівнів складається архітектура кожної ІТ-системи
Впровадження електронного документообігу в фін.установах України
Функціональні вимоги до системи DLP
Перед впровадженням системи DLP
COBIT про антивірусний захист
НБУ про дотримання вимог для фін.установ. Варіант 2
НБУ про дотримання вимог для фін.установ
Вимога до інтеграції програмного забезпечення. OAuth 2.0
Вимога до інтеграції ПЗ з Active Directory
Использование управления привилегиями конечных точек с Microsoft Intune
Microsoft System Requirements - Microsoft Lifecycle | Microsoft Docs
SRS. Software requirements specification

Style Credit

Style: Neutral Good for Practicality by timeasmymeasure

Expand Cut Tags

No cut tags

Page generated 2026-04-13 04:22

Entries tagged with requirements

Простими словами:

Де застосовується

Приклади ORM

Viewpoint (точка зору)

View (подання)

Приклад

🧾 Інформаційна архітектура ІТ-системи компанії

🔹 1. Методологія

🔹 2. Архітектурний контекст

🔹 3. Архітектурні погляди (Views)

3.1 📡 Deployment View

3.2 🧩 Data Architecture View

3.3 🔐 Access & Security View

3.4 🔄 Information Flow View

🔹 4. Зацікавлені сторони (Stakeholders)

🔹 5. Цільова модель та вдосконалення

🔹 6. Узгодженість із ISO/IEC/IEEE 42010

✅ На останок:

Стандарти:

1. ISO/IEC 27001:2022

1. ISO/IEC 17788:2014 — Інформаційні технології – Хмарні обчислення – Огляд та словник

2. ISO/IEC 17789:2014 — Архітектура хмарних обчислень

3. ISO/IEC 27017:2015 — Інформаційні технології – Методи забезпечення безпеки – Керівництво з безпеки для хмарних обчислень

4. ISO/IEC 27018:2019 — Захист персональних даних у хмарних обчисленнях

5. ISO/IEC 19086 — Угоди про рівень надання послуг (SLA) для хмарних обчислень

6. ISO/IEC 27001 — Система управління інформаційною безпекою (ISMS)

7. ISO/IEC 38500 — Корпоративне управління ІТ

1. Накази та рішення НБУ

2. Стандарти інформаційної безпеки

3. Інші нормативні акти та рекомендації

1. Документи, пов'язані з законодавством України

1.1. Положення про захист персональних даних

1.2. Політика інформаційної безпеки

1.3. Регламент обробки персональних даних

1.4. Політика конфіденційності

1.5. Угода про конфіденційність (NDA)

1.6. Порядок реагування на інциденти безпеки

2. Документи, пов'язані з ISO 27001

2.1. Політика інформаційної безпеки (Information Security Policy)

2.2. Оцінка ризиків (Risk Assessment)

2.3. Методика управління ризиками (Risk Treatment Plan)

2.4. Декларація застосовності (Statement of Applicability, SoA)

2.5. План неперервності бізнесу (Business Continuity Plan)

2.6. Політика управління доступом (Access Control Policy)

2.7. Журнали та контрольні журнали (Logging and Monitoring)

3. Документи, пов'язані з внутрішніми процесами та регламентами

3.1. Інструкції по роботі з системою DLP

3.2. Технічні політики та процедури

3.3. Положення про захист комерційної таємниці

4. Додаткові документи

4.1. Угоди з підрядниками та партнерами

4.2. Документовані докази відповідності

1. Постанова НБУ №95 "Про затвердження Положення про здійснення захисту інформації та кібербезпеки в банківській системі України"

2. Постанова НБУ №75 "Про затвердження Положення про захист інформації та кібербезпеки в платіжних системах"

3. Постанова НБУ №56 "Про організацію захисту інформації в банках України"

4. Постанова НБУ №391 "Про затвердження Положення про здійснення нагляду (оверсайта) за платіжними системами"

5. Рішення НБУ щодо підвищення стандартів кібербезпеки в банківській системі України

6. Листи та роз'яснення НБУ щодо дотримання стандартів інформаційної безпеки

1. Постанова Правління НБУ № 243 від 4 липня 2007 року (зі змінами та доповненнями)

2. Постанова Правління НБУ № 351 від 28 вересня 2021 року

3. Постанова Правління НБУ № 95 від 3 грудня 2018 року

4. Постанова Правління НБУ № 518 від 28 вересня 2020 року

5. Рішення НБУ про захист даних під час дистанційного банківського обслуговування

6. Методичні рекомендації НБУ

Вимога до інтеграції з Active Directory (AD) або Microsoft Entra ID

Правила составления Software requirements specification

Что такое SRS ?

Зачем оно надо ?

Структура SRS

Syndicate

Page Summary

Style Credit

Expand Cut Tags