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)



Архітектура будь-якої ІТ-системи зазвичай складається з чотирьох загальних рівнів, які відповідають вимогам 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)


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

ВимогаДе міститься
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Дотримання вимог щодо легітимності електронного документообігуЗакон України "Про електронні довірчі послуги"Вимоги до надання юридичної сили електронним документам; відповідність технічним і правовим стандартам електронних підписів і печаток.

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


bga68comp: (Default)

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

COBIT (Control Objectives for Information and Related Technology) — це фреймворк управління ІТ, розроблений для забезпечення зв’язку між ІТ-цілями та бізнес-цілями. COBIT охоплює безліч аспектів ІТ-управління, включаючи управління ризиками, безпеку, контроль і відповідність вимогам.
Антивірусний захист у контексті COBIT може розглядатися в рамках доменів, пов’язаних з управлінням ризиками та забезпеченням інформаційної безпеки. Ось ключові розділи та процеси COBIT, які стосуються антивірусного захисту:
  1. APO12 - Управління ризиками (Risk Management)
    • У цьому процесі COBIT описується необхідність ідентифікації, оцінки та управління ІТ-ризиками, що включає загрози безпеки, такі як віруси та шкідливе ПЗ. Антивірусний захист розглядається як одна з заходів для зменшення ризиків.
  2. DSS05 - Управління безпекою (Manage Security Services)
    • Цей процес включає забезпечення інформаційної безпеки шляхом реалізації та підтримання заходів захисту, таких як антивірусні рішення, брандмауери та інші механізми захисту.
  3. DSS01 - Управління операційними ІТ-послугами (Manage Operations)
    • Операційні процеси управління ІТ можуть включати моніторинг і управління антивірусним захистом як частину загальних ІТ-послуг.
  4. BAI09 - Управління конфігурацією (Manage Configuration)
    • Антивірусні програми повинні бути правильно сконфігуровані та оновлені, що також стосується управління конфігурацією ІТ-інфраструктури.

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


bga68comp: (Default)
 
COBIT 5 – это всеобъемлющая бизнес-модель по руководству и управлению ИТ на предприятии. Настоящий документ включает описание пяти принципов COBIT 5 и определяет семь факторов влияния, которые вместе формируют основу методологии.
COBIT 5 Russian
COBIT 5 Information Security Russian
COBIT 5 for Assurance Russian
Assessor Guide: Using COBIT 5 Russian
PAM Using COBIT 5 Russian


COBIT 5 представляет собой всеобъемлющую структуру общепринятых принципов, практик, аналитических инструментов и моделей, которые могут помочь любому предприятию эффективно решать важнейшие вопросы бизнеса, связанные с руководством и управлением информацией и технологиями.

1-е издание - 1996 г.
2-е издание - 1998 г.
3-е издание - 2000 г.
4-е издание - 2005 г.
5-е издание - 2012 г.

COBiT 5: История "поглощений"


COBiT 5: 5 доменов, 37 процессов

cobit-5-domains

COBiT5: Внедрение
cobit-5-implementation

Скачать на официальном сайте: http://www.isaca.org/COBIT/Pages/COBIT-5-russian.aspx

bga68comp: (Default)
 
iso27001 logo

Совершенствование процесса управления правами доступа и повышение его эффективности осуществляется за счет следующих активностей:
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... )

bga68comp: (Default)
Основные сертификаты информационной безопасности для ИТ-специалистов и предприятий / Хабрахабр


Даже если просто просматривать заголовки новостей, то этого достаточно, чтобы понимать: в сфере информационной безопасности постоянно появляются новые угрозы и уязвимости. А потому предприятиям крайне важно иметь возможность осуществлять подготовку своих профессионалов в области безопасности в таком объеме, как того требует их стратегия ИТ-управления.

Это означает, что существует только один вопрос: как лучше всего, с одной стороны, специалистам получить адекватное обучение (что сделает их более востребованными на рынке труда), а с другой стороны, предприятиям улучшить свои протоколы и процедуры безопасности (и продемонстрировать своим клиентам чувство безопасности)?
Правильные решения – это сертификаты безопасности, которые допускают сочетания минимальных требований, стандартизированного языка и профессионального кодекса этики.

Если мы, как специалисты и руководители предприятий решили взять курс в управлении ИТ-безопасностью, то рекомендуется выбирать сертификаты ведущих международных и независимых организаций. С учетом этого, в данной статье мы приводим некоторые из доступных наиболее серьезных сертификационных программ:

CISA / CISM
CISA и CISM– это две основные аккредитации, выдаваемые ассоциацией ISACA (Information Systems Audit and Control Association) – международной ассоциации, которая занимается сертификацией и методологией с 1967 года и насчитывает в своих рядах свыше 95 000 членов.
CISM (Certified Information Systems Manager) появилась позже, чем CISA, и предлагает аккредитацию в знании и опыте управления IT-безопасностью.
CISM предлагает основные стандарты компетенции и профессионального развития, которыми должен обладать директор по IT-безопасности, чтобы разработать и управлять программой IT-безопасности.

CISSP
Сертификат Certified Information Systems Security Professional (CISSP), выдаваемый ISC, — это один из самых ценных сертификатов в отрасли. Такие организации, как АНБ или Министерство обороны США используют его в качестве эталона.
Сертификат также известен как «в милю шириной и дюйм глубиной», т.е. указывает на ширину знаний (в милю), которые проверяются в рамках экзамена, а также на то, что многие вопросы не затрагивают изощренных подробностей концепций (только в дюйм глубиной).

COBIT
COBIT 5 (последняя протестированная версия) определяется как отправная точка, используемая правительственными учреждениями и предприятиями для IT-управления. Управляется ассоциацией ISACA совместно с IT Governance Institute.
COBIT разработан таким образом, чтобы адаптироваться для предприятий любого размера с различными бизнес-моделями и корпоративной культурой. Его стандарты применяются в таких сферах, как информационная безопасность, управление рисками или принятие решений относительно облачных вычислений.

ITIL
ITIL (IT Infrastructure Library) можно описать как пример надлежащей практики и рекомендаций для администрирования IT-сервисами с фокусом на администрировании процессами. Управляет этим сертификатом OGC (Office of Government Commerce) в Великобритании.
В то время как COBITS работает в вопросах управления и стандартизации предприятия, ITIL сконцентрирован на процессах, т.е. COBIT определяет «ЧТО», а ITIL – «КАК».

ISO / IEC 27000
Стандарт, опубликованный международной организацией по сертификации ISO и международной электротехнической комиссией IEC, выступает в качестве отправной точки для группы стандартов, обеспечивающих основы управления IT-безопасностью, которые могут использоваться любым типом организаций (некоммерческие, государственные, частные, большие или маленькие).

В отличие от других сертификатов, которые предназначены для физических лиц, этот сертификат в первую очередь рассчитан для предприятий.

Источник:
https://habrahabr.ru/company/panda/blog/268453/

bga68comp: (Default)
ITIL. Официальный перевод глоссария ITIL v.3

Глоссарий Терминов и Определений. ITIL® V3 Glossary, v0.92, 30 April 2009:

http://itsmforum.ru/ZAM-test/ITILV3_Glossary_Russian_v092_2009.pdf

titul page

Примеры

ITIL

ITIL

A set of Best Practice guidance for IT Service Management. ITIL is owned by the OGC and consists of a series of publications giving guidance on the provision of Quality IT Services, and on the Processes and facilities needed to support them. See http://www.itil.co.uk/ for more information.

Набор рекомендаций по Лучшим практикам в Управлении ИТуслугами (ITSM). ITIL принадлежит OGC и представляет собой набор публикаций, содержащих рекомендации по организации предоставления Качественных ИТ-услуг, а также Процессов и компонентов, необходимых для их поддержки. Дополнительно смотри http://www.itil.co.uk/.

COBIT

COBIT

(Continual Service Improvement)

Control Objectives for Information and related Technology (COBIT) provides guidance and Best Practice for the management of IT Processes. COBIT is published by the IT Governance Institute. See http://www.isaca.org/ for more information.

(Постоянное улучшение услуг)

Control Objectives for Information and related Technology (COBIT) является руководством и Лучшей практикой по управлению ИТпроцессами. COBIT опубликован IT Governance Institute. Более подробно смотри также http://www.isaca.org/
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-03 21:08
Powered by Dreamwidth Studios