ORM

2025-09-03 02:26
bga68comp: (Default)

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)


bga68comp: (Default)

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

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

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

View (подання)

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

Приклад

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

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


bga68comp: (Default)

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

  • 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


bga68comp: (Default)

Продовжуємо розбирати шаблони рівнів архітектури ІТ-систем. Це доповнення до опису архітектури за посиланнями:
Приклад опису архітектури системи згідно 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)

  1. Preliminary Phase
  2. Phase A: Architecture Vision
  3. Phase B: Business Architecture
  4. Phase C: Information Systems Architectures
  5. Phase D: Technology Architecture
  6. Phase E: Opportunities and Solutions
  7. Phase F: Migration Planning
  8. Phase G: Implementation Governance
  9. Phase H: Architecture Change Management
  10. Requirements Management


bga68comp: (Default)

Скільки середовищ має бути в життєвому циклі ІТ-системи?

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

1. Development (DEV)

Середовище розробки
  • Використовується розробниками для написання та первинного тестування коду.
  • Низький рівень обмежень, можливі нестабільності.

2. Testing (TEST) або QA

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

3. Staging (STG) або Pre-Production

Передпродуктивне середовище
  • Майже повна копія продуктивного середовища: ті ж версії ПЗ, архітектура, налаштування.
  • Використовується для перевірки релізів перед впровадженням у продакшн.

4. Production (PROD)

Продуктивне (робоче) середовище
  • Обробляє реальні користувацькі дані.
  • Високі вимоги до доступу, стабільності, безпеки.

Додатково можуть використовуватись:

5. UAT (User Acceptance Testing)

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

6. Sandbox

Середовище-пісочниця для експериментів, навчання та демонстрацій
  • Безпечне середовище для тестування ідей або навчання без ризику для основної системи.

Підсумкова таблиця:


Назва середовища Призначення
1 DEV (Розробка) Розробка та початкове тестування
2 TEST або QA Функціональне та автоматизоване тестування
3 STG (Передпродакшн) Перевірка перед виходом у продакшн
4 PROD (Продуктивне) Робота з реальними даними
5 UAT Приймальне тестування замовником
6 Sandbox (Пісочниця) Експерименти, PoC, навчання


bga68comp: (Default)
Приклад

Концепція інформаційної безпеки (ІБ) для фінансової установи — це стратегічний документ, що визначає принципи, підходи, і засоби забезпечення захисту інформаційних активів організації. Цей документ має відповідати міжнародним стандартам, таким як ISO 27001:2022, TOGAF 10, а також враховувати чинне законодавство України, зокрема Закон України "Про захист інформації в інформаційно-телекомунікаційних системах", "Про електронні довірчі послуги" та інші нормативно-правові акти.

1. Вступ

1.1. Мета документа
1.2. Сфера застосування
1.3. Визначення термінів та скорочень

2. Загальні положення

2.1. Нормативно-правове регулювання
2.2. Основні принципи інформаційної безпеки
2.3. Основні загрози інформаційній безпеці
2.4. Визначення відповідальності за забезпечення ІБ

3. Мета та завдання інформаційної безпеки

3.1. Захист конфіденційності, цілісності та доступності інформаційних активів
3.2. Вимоги до управління ризиками інформаційної безпеки
3.3. Дотримання нормативних вимог і стандартів

4. Архітектура інформаційної безпеки

4.1. Інтеграція з TOGAF 10 - Використання TOGAF 10 для формування архітектури інформаційної безпеки. - Визначення доменів безпеки в рамках архітектурного підходу.
4.2. Використання ISO 27001:2022 для структурування політик ІБ - Основні етапи впровадження системи управління інформаційною безпекою (СУІБ) за стандартом ISO 27001:2022. - Впровадження контролів, визначених у додатку A стандарту.
4.3. Оцінка ефективності СУІБ (розділ 9.1 ISO 27001:2022) - Процедури моніторингу, вимірювання, аналізу та оцінки ефективності СУІБ.
4.4. Управління фізичними та технічними ресурсами (розділ 8.1 ISO 27001:2022) - Вимоги до захисту приміщень, технічних засобів та засобів комунікації.

5. Захист інформаційних активів

5.1. Визначення та класифікація інформаційних активів
5.2. Розробка та впровадження політик і процедур захисту - Політики захисту даних, управління доступом, шифрування, аудит.
5.3. Управління інцидентами інформаційної безпеки - Вимоги до процесів виявлення, реєстрації та реагування на інциденти.
5.4. Вимоги до забезпечення безперервності бізнесу

6. Організаційна структура управління інформаційною безпекою

6.1. Визначення ролей та відповідальності - Відповідальність керівництва, CISO, команди з ІБ.
6.2. Вимоги до навчання та підвищення обізнаності
6.3. Взаємодія з державними органами та регуляторами

7. Контроль та аудит інформаційної безпеки

7.1. Внутрішні аудити
7.2. Зовнішні перевірки та сертифікація
7.3. Документування та звітність

8. Заключні положення

8.1. Порядок перегляду та оновлення Концепції
8.2. Вимоги до звітності та контролю виконання

Посилання на нормативні документи:

  1. ISO 27001:2022 — Стандарт інформаційної безпеки, що визначає вимоги до СУІБ.
  2. TOGAF 10 — Стандарт архітектурного фреймворку, що визначає підходи до побудови архітектури підприємства, включаючи інформаційну безпеку.
  3. Закон України "Про захист інформації в інформаційно-телекомунікаційних системах" — регулює захист інформації в Україні.
  4. Закон України "Про електронні довірчі послуги" — регулює порядок надання електронних довірчих послуг та захисту даних у цифровому середовищі.

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


bga68comp: (Default)



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

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

4-layers

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


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

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

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


bga68comp: (Default)


The Open Group Architecture Framework (TOGAF) - методология/библиотечный метод описания/подход (framework) для описания архитектуры предприятия, который предлагает подход для проектирования, планирования, внедрения IT-архитектуры предприятия и управления ей. TOGAF разрабатывается с 1995 группой The Open Group на основе фреймворка Министерства обороны США TAFIM.

TOGAF - высокоуровневый подход к проектированию. В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов:
  • Бизнес архитектура (Business) — определяет стратегию предприятия, структуру управления и ключевые бизнес процессы.
  • Архитектура данных (Data) — описывает логическую и физическую структуру данных организации, а также структуру корпоративных ресурсов для управления данными.
  • Архитектура приложений (Application) — служит своеобразной картой всех используемых корпоративных приложений и определяет следующие аспекты:
    • участие каждого из приложений в бизнес процессах компании;
    • взаимодействие приложений друг с другом и внешними сервисами.
  • Технологическая архитектура (Technology) — определяет структуру и логику программного обеспечения и аппаратной среды, необходимых для работы бизнес приложений и доступа к нужным данным. Этот уровень включает всю поддерживающую инфраструктуру: сети, сервера, процессинг и т.п.

TOGAF распространяется свободно и может быть использована бесплатно любой организацией для разработки внутренних проектов.


Read more... )

Profile

bga68comp: (Default)
bga68comp

December 2025

S M T W T F S
  12 3 456
7891011 1213
14151617181920
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated 2026-01-04 03:24
Powered by Dreamwidth Studios