IT-Security Step-by-step

НБУ: Положення про порядок застосування технології хмарних обчислень

2026-02-03T10:02:38Z

ПРАВЛІННЯ НАЦІОНАЛЬНОГО БАНКУ УКРАЇНИ

ПОСТАНОВА

25 серпня 2025 року № 99

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

2. Терміни в цьому Положенні вживаються в такому значенні:

1) ланцюгові хмарні послуги - хмарні послуги, під час виконання яких надавач хмарних послуг залучає іншого надавача хмарних послуг (далі - партнер надавача хмарних послуг);

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

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

Інші терміни, що використовуються в цьому Положенні, уживаються в значеннях, визначених у Законі України “Про хмарні послуги” та інших законах України і нормативно-правових актах Національного банку України (далі - Національний банк).

5. Установа - користувач хмарних послуг за допомогою технології хмарних обчислень має право використовувати такі хмарні послуги:

1) інфраструктура як послуга (IaaS, англійською мовою Infrastructure as a Service);

2) платформа як послуга (PaaS, англійською мовою Platform as a Service);

3) програмне забезпечення як послуга (SaaS, англійською мовою Software as a Service);

4) безпека як послуга (SECaaS, англійською мовою Security as a Service);

5) інші послуги, що відповідають визначенню хмарних послуг.

6. Установа - користувач хмарних послуг має право самостійно обирати надавача хмарних послуг.

7. Установа - користувач хмарних послуг має право використовувати хмарні послуги в такі способи:

1) приватна хмара;

2) колективна хмара;

3) публічна хмара;

4) гібридна хмара.

8. Використання хмарних послуг здійснюється на підставі договору про хмарні послуги, укладеного між установою - користувачем хмарних послуг та надавачем хмарних послуг (далі - Договір). Договір укладається в одній із таких форм:

1) у формі паперового документа з власноручними підписами сторін;

2) у формі електронного документа із кваліфікованими електронними підписами сторін або удосконаленими електронними підписами сторін з кваліфікованими сертифікатами.

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

comments

CSA — Структура можливостей безпеки SaaS (SSCF)

2025-11-10T04:48:38Z

Для кого це:

Команди з управління ризиками третіх сторін
Постачальники SaaS
Команди інженерів безпеки SaaS

Структура можливостей безпеки SaaS (SSCF)

Дата виходу: 23.09.2025

Структура можливостей безпеки SaaS (SSCF) – це нова технічна структура, яка визначає налаштовувані, споживані та орієнтовані на клієнта засоби контролю безпеки, що надаються постачальниками SaaS своїм клієнтам.

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

SSCF надає ключові переваги широкому колу користувачів:

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

Встановлюючи стандартизовані функції безпеки, які мають бути доступні на всіх SaaS-платформах, SSCF дозволяє власникам додатків приймати обґрунтовані рішення та підтримувати послідовний рівень безпеки.

Що входить до цього завантаження:

Документ випуску SSCF версії 1.0: Описує новий стандарт, його контекст, область застосування та домени контролю.
Список елементів керування SSCF версії 1.0: Містить елементи керування SSCF, узгоджені з доменами CCM.
Слайди SSCF версії 1.0: Ознайомлення з передумовою, постановкою проблеми та перевагами SSCF.

Джерело:
→ https://cloudsecurityalliance.org/artifacts/saas-security-capability-framework-sscf

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

comments

CSA — Гібридна хмара та пов'язані з нею ризики

2025-11-10T04:09:36Z

Гібридна хмара та пов'язані з нею ризики

Дата виходу: 13.07.2020

Робоча група: Гібридна хмарна безпека

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

Пов'язані дослідження | Робоча група

Джерело:
→ https://cloudsecurityalliance.org/artifacts/hybrid-clouds-and-its-associated-risks/

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

comments

CSA — Керівні принципи впровадження та аудиту AICM

2025-11-10T03:05:17Z

Керівні принципи (рамки) впровадження та аудиту AICM

Дата виходу: 22.10.2025

Комплект інструкцій щодо впровадження та аудиту Матриці елементів керування штучним інтелектом (AICM) Альянсу безпеки хмарних технологій (Cloud Security Alliance, CSA) надає вичерпні вказівки щодо впровадження та оцінки 243 елементів керування Матриці елементів керування штучним інтелектом.

Що входить до цього завантаження:

Керівні принципи впровадження: Визначає практичні рекомендації на основі ролей щодо застосування елементів керування AICM до систем штучного інтелекту, що працюють у хмарних середовищах. Кожен елемент керування містить детальні інструкції з впровадження, адаптовані до основних учасників екосистеми штучного інтелекту: постачальників моделей (MP), постачальників додатків (AP), постачальників оркестрованих послуг (OSP), клієнтів штучного інтелекту (AIC) та постачальників хмарних послуг (CSP).
Керівні принципи аудиту: Надає структуровані кроки аудиту для внутрішніх або зовнішніх аудиторів, які оцінюють організації, що впроваджують AICM. Підкреслює відповідальність за конкретні ролі в усьому ланцюжку постачання штучного інтелекту, забезпечуючи послідовну оцінку, чіткі очікування та відстеження в усіх видах діяльності з впровадження та забезпечення якості.

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

Завантажте повну Матрицю контролю штучного інтелекту (AICM) тут .

Джерело:
→ https://cloudsecurityalliance.org/artifacts/aicm-implementation-auditing-guidelines-frameworks

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

comments

CSA — Стан хмарних технологій та безпеки ші у 2025 році

2025-11-09T21:05:23Z

Для кого це:

Керівники інформаційної безпеки (CISO)
Архітектори хмарної безпеки
Менеджери з ІТ та безпеки
Фахівці з IAM
Спеціалісти з управління ризиками та дотримання вимог

Стан хмарних технологій та безпеки штучного інтелекту у 2025 році

Дата виходу: 09/09/2025

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

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

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

Ключові висновки:

Понад половина організацій (63%) повідомляють, що використовують більше одного хмарного провайдера. Ще більше (82%) підтримують певний вид гібридної інфраструктури.
Багато організацій (59%) визначили незахищені ідентифікаційні дані та ризиковані дозволи як головний ризик безпеки для своєї хмарної інфраструктури. Однак багатьом із цих самих організацій бракує структури або робочих процесів для вирішення цих проблем у великих масштабах.
Брак досвіду є головною проблемою для забезпечення безпеки хмарної інфраструктури.
Найчастіше відстежуваним KPI хмарної безпеки є частота та серйозність інцидентів безпеки. В IAM головним показником є рівень впровадження MFA/SSO. Організації, як і раніше, зосереджені на поверхневих показниках, а не на перспективних показниках ефективності.
Більше третини організацій із робочими навантаженнями, пов’язаними зі штучним інтелектом (34%), вже зіткнулися з порушенням, пов’язаним зі штучним інтелектом.
Лише 20% організацій надають пріоритет єдиній оцінці ризиків, і лише 13% зосереджуються на консолідації інструментів.

Джерело:
→ https://cloudsecurityalliance.org/artifacts/the-state-of-cloud-and-ai-security-2025

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

comments

Пропозиції Microsoft щодо відповідності вимогам

2025-09-16T20:50:43Z

У Майкрософт є цікавий ресурс для тих, хто займається побудовою процесів інформаційної безпеки.
Він знаходиться за адресою:
Microsoft compliance offerings:

Пропозиції Microsoft щодо відповідності вимогам

( Read more... )
Наприклад, можна офіційно і без обмежень багато інформації про ШІ отримати тут:

https://learn.microsoft.com/uk-ua/compliance/regulatory/offering-iso-42001

Огляд ISO/IEC 42001:2023

( Read more... )

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

comments

ORM

2025-09-02T23:28:52Z

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)

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

comments

ISO/IEC/IEEE 42010: Viewpoint & View

2025-09-02T23:13:18Z

У 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

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

comments

TOGAF vs ISO 42010 vs Разом

2025-09-02T22:57:14Z

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

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

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

comments

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

2025-06-26T18:06:09Z

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

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

comments

Вимоги до хмарних сервісів у стандартах ІБ

2024-10-08T15:30:17Z

Щоб впроваджувати безпечні, надійні та ефективні хмарні сервіси, а також управляти ними відповідно до міжнародних вимог та кращих практик, нижче наведений перелік основних стандартів 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 — Корпоративне управління ІТ

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

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

comments

CASB (Cloud Access Security Broker)

2024-08-28T15:25:25Z

CASB (Cloud Access Security Broker) — это программное решение, которое обеспечивает безопасность данных и управляет доступом к облачным сервисам. CASB помогает организациям контролировать и защищать данные, которые находятся в облаке, обеспечивая видимость использования облачных сервисов, управление политиками безопасности и защиту от угроз. Это особенно важно в условиях увеличения использования облачных приложений и сервисов.

Примеры CASB

Эти инструменты помогают организациям контролировать использование облачных сервисов, обеспечивать защиту данных и предотвращать угрозы. Некоторые популярные решения CASB включают:

Microsoft Defender for Cloud – Инструмент безопасности для облачных ресурсов с функциями CASB.
McAfee MVISION Cloud – Платформа для защиты данных и управления безопасностью облачных сервисов.
Palo Alto Networks Prisma Cloud – Обеспечивает защиту облачных приложений и данных.
Netskope – Предлагает решения для защиты данных и управления доступом к облачным ресурсам.
Symantec CloudSOC – Платформа для обеспечения безопасности облачных приложений и данных.

Квадрант Гартнера по CASB

Квадрант Гартнера (Gartner Magic Quadrant) — это популярный инструмент для оценки и сравнения различных технологий и поставщиков решений на рынке. Для CASB (Cloud Access Security Broker) Гартнер также создает свой квадрант, в котором делит компании на четыре категории:

Лидеры (Leaders): Компании с сильной способностью к выполнению и полнотой видения. Они предоставляют полный спектр функций и решений, широко признаны на рынке и имеют сильную клиентскую базу.
Челленджеры (Challengers): Компании с сильной способностью к выполнению, но с ограниченным видением. Обычно это крупные и стабильные компании, которые могут предложить надежные решения, но с ограниченным инновационным подходом.
Визионеры (Visionaries): Компании с хорошей полнотой видения, но с ограниченной способностью к выполнению. Эти компании предлагают инновационные и перспективные решения, но могут иметь ограничения в ресурсе для полной реализации своих планов.
Ниши (Niche Players): Компании с ограниченными возможностями как в видении, так и в выполнении. Обычно они фокусируются на узком сегменте рынка и могут предложить специализированные решения.

Последний Квадрант Гартнера, связанный с CASB (“Gartner Magic Quadrant CASB 2024”), теперь интегрирован в более широкий рынок Security Service Edge (SSE), который включает функции CASB, Secure Web Gateway (SWG) и Zero Trust Network Access (ZTNA). В отчете 2024 года лидерами SSE признаны такие компании, как Netskope, Zscaler и Palo Alto Networks. Эти компании предлагают комплексные решения для защиты доступа к облачным сервисам и данным.

2023

2019

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

comments

Блог зламався

2024-08-08T23:22:45Z

Отакої...
Блог зламався — малюнки стали тепер недоступні без VPN.
Попередній раз MediaFire підкузьмив, а тепер знову якась халепа.
Треба щось вигадувати знову... — новий спосіб, як це обійти...

Чекайте, скоро вийде серіал: «Як вижити в блогінгу та не втратити глузд».

comments

DNS from Cloudflare

2023-12-07T22:01:20Z

https://one.one.one.one/uk-UA
( Set up 1.1.1.1 for router )

comments

Стратегии информ.безопасности будущего или настоящего?

2022-06-12T13:24:11Z

Эпиграф
А я все чаще замечаю,
Что меня как-будто кто-то подменил...

Концепция компьютерного рабочего места за последние 10-15 лет приобрела вид закоренелой идиомы:
компьютер - это:
1. стационарная рабочая станция,
2. которая установлена в определенной комнате,
3. подключенная к сети ethernet-кабелем,
4. за ней работает один работник, которого мы знаем "от и до" и
5. ни-ког-да эти параметры не изменяются!

Другими словами основная стратегия все ещё остается на уровне пользователя, который сидит в офисе, за рабочим столом, через проводное соединение и не проявляет никакой мобильности.

И пусть такие брэнды, как Cisco или VMware, мечтают о беспроводных сетях, о регламентированном доступе с любой точки Земного шара и о строгой определенности и дозированности конфиденциальности. 🙂🙃 Это - все фантастика.

Усугубляется все тем, что пользователи невольно очень чутко реагируют на то, насколько удобно то ИТ-окружение, в которое их поместили для работы.
Если ИТ-служба не предоставляет удобного решения для пользователей, то они без ведома ИТ-службы начинают использовать стороннее решение (например, DropBox, Яндекс-Диск, Google Drive, Microsoft SkyDrive, Asus WebStorage, Ubuntu One, Apple iStore и др.). Если не предоставлено удобное средство для общения, пользователи самостоятельно заводят «закрытые» группы общения в Viber, FaceBook, OverNote, Вацап.

Если это всё запретить внутри сети, то пользователи спокойно используют мобильный интернет на своих мобильных устройствах.

И приходится признать, что реалии сегодняшнего ИТ-окружения таковы, что:
1. Невозможно отслеживать и контролировать информационные активы и обеспечивать их безопасность;
2. ИТ-отделы не способны запретить доступ, который не был предоставлен ИТ-отделом;
3. Приложения легко приобретаются и устанавливаются через различные облака без помощи ИТ-отдела;
4. Пользователи используют постоянное подключение через 3G, 4G, общедоступные и частные сети Wi-Fi;
5. Пользователи используют личные устройства и альтернативные операционные системы (не Windows – Apple Mac OS, Андроид);
6. Пользователи работают с любой точки земного шара (в ком-ке, в поезде, на отдыхе, в офисе).

Т.е. другими словами ИТ-отделом не контролируются:
1. физические рабочие места сотрудников;
2. программное обеспечение, которое используют в своей работе пользователи;
3. каналы связи.
Итого: полный крах на всех фронтах с точки зрения информ. безопасности.

Фактически мы не понимаем с какого устройства и к какой именно информации пользователь получил доступ…

Не люблю сослагательного наклонения, но, если опустимся на Землю.
В действительности все абсолютно не так, как кажется на первый взгляд или как хотелось бы, чтобы было.
Уже даже в селах дети используют "мобильный Интернет". Пусть этот Интернет еще далек от скоростей 3G и 4G, но он есть!
Количество проданных ноутбуков и различного рода мобильных гаджетов уже давно превысило количество продаваемых стационарных компьютеров, которые состоят из системных блоков, мониторов, клавиатур и мышек. Резонно: зачем покупать тяжелую много места занимающую технику, если с тем же Microsoft Surface Pro 3 можно и в игры поиграть, требующие производительной видеокарты, и реализовать самые смелые производственные задачи.

Согласно отчетов Gartner* рабочие станции «пропадут» из офисов к 2020 году и все будут работать на своих личных устройствах.
(журнал CIO, декабрь 2012: статья «Консьюмеризация наступает», стр.6)

Я не говорю даже о том, что многие фирмы/предприятия/корпорации "раскинули" свои офисы не по одной стране мира.
"Проблемы роста" как в менеджменте, так и в технологиях намного глубже, чем кажутся на первый взгляд. Была маленькая фирма, где собственник был, прежде всего, другом своим работникам. Были свои семейные законы коммерческой тайны. Но вот фирма слишком быстро разрослась. И законы менеджмента вынуждены меняться. Уже не может быть друзей-управленцев и родственников. Иначе управленческие решения будут приниматься не вовремя и неадекватно производственной ситуации. Точно также и ИТ-инфраструктуре нужны новые методы управления. Нужны новые точки отсчета и классификации информации. Новые методики обеспечения информационной безопасности разросшихся бизнес-процессов.

Не поверю, что при росте компьютерного парка от 200 единиц и выше в таких фирмах реально не существует, мягко говоря, трудностей:
- собственнику не выгодно закупать под каждого нового сотрудника новую технику;
- при перемещении компьютеров между офисами пользователю необходимо предоставить равноценные корпоративные сервисы такие, как элементарный и прозрачный доступ в сеть, доступ к корпоративным приложениям и т.д.;
- при постоянном изменении конфигурации сети (а каждый новый компьютер может существенно изменить состояние безопасности сети) элементарно посчитать свои компьютеры становится все сложнее - их количество может меняться каждый день, час, минуту и нужно понимать, что среди них нет "прикинувшегося своим" чужака;
- быстро меняющийся персонал с низкой зарплатой не особенно ответственно относится к компьютерной технике. Не единичны ситуации, когда технику обиженные сотрудники не возвращают в ИТ-службу и есть необходимость обнулить служебные данные на "уехавшем" из корпоративной сети устройстве;
- кроме этого компьютерная техника (ноутбуки, планшеты, мобильные гаджеты) имеют свойство теряться, быть украденными, как случайными субъектами, так и (внимание!) конкурентами. К сожалению, ещё распространено мнение, что конкуренции, как таковой, нет и быть не может и промышленный шпионаж на территории стран бывшего СССР не развит, что в действительности является всё той же "розовой иллюзией" некоторых собственников бизнеса, которые живут по принципу: не произошло, значит, такого нет.

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

В связи с ухудшением геополитической ситуации на территории стран бывшего СССР вполне логичным и оправданным становится пытаться контролировать работу своих сотрудников на служебной компьютерной технике с помощью спецтехнологий. Но опять же развитые средства контроля привязываются к конкретному устройству. Все та же концепция 10-летней давности:
компьютер - это:
1. стационарная рабочая станция,
2. которая установлена в определенной комнате и т.д. по пунктам.

Системы предотвращения (англ. Data Leak Prevention, DLP) как и системы обнаружения (англ. Data Leak Detection, DLD) утечек конфиденциальной информации в большинстве стран противоречат Законодательству или требуют выстраивания серьезных взвешенных и документированных взаимоотношений работодатель-работник.

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

Сегодня концепция предоставления доступа к информации неожиданно изменилась от "железки" в сторону пользователя, который стоит за этой "железкой".
Даже такие зависимые от "железок" элементы ИТ - сети уже не привязываются к конкретным аппаратным решениям и протоколам. (Cisco программно-определяемые сети, VMware NSX - платформа виртуализации сетей для программных ЦОДов). Даже слоганы поменялись.

Cisco:
Сети должны адаптироваться со скоростью бизнеса.
Высококачественная технология совместной работы для всех – это не то, что было бы «неплохо иметь», а то, что «необходимо иметь».

VMware:
Одно облако, одно приложение на любом устройстве.
Мы помогаем организациям внедрять инновации и развиваться за счет оптимизации ИТ-процессов.

Эти технологии есть. Их можно использовать. Они пропагандируют другую концепцию. Концепцию независимую от устройства.
Сейчас важен пользователь. Именно его идентификация, а не только его авторизация. Нам нужно знать, что именно ЭТОТ человек на любом устройстве вошел в сеть и получил в зависимости от возможностей устройства доступ к рабочей информации. Повышается производительность работника. Улучшается эргономика принятия им решений, т.к. он не зависит от устаревших устройств, выданных ему работодателем. И работодатель доволен: не нужно тратиться на "железку". Не нужно платить аренду офиса на 1000 человек. Эти 1000 человек могут продуктивно и слаженно работать в любой точке мира. При этом никакие секреты и ноу-хау компании не могут "утечь" к конкурентам.

Соответственно должны и меняться системы предоставления сервисов. Компьютер не важен. Важно, что пользователь получит корпоративное приложение на свое личное устройство, выполнит работу и при этом никаких служебных рабочих данных у него не останется на личном устройстве.

Но пользователь может иметь не одно устройство, а множество. И каждое из них должно идентифицировать пользователя. В этом случае мы ведем учет не "железок", а неких свойств одного пользователя. И, исходя из этих свойств, предоставляем удобные инструменты для работы такого важного для нас работника, что мы ему разрешаем работать на нас везде и всегда.

Но, если мы перестаем привязываться к конкретному устройству и концентрируемся на пользователе, то и средства предоставления доступа, центры обработки данных не могут оставаться обычными серверными, местонахождение которых знает весь производственный персонал. Тут не лишне напомнить, что по статистике 70% пользователей так или иначе невольно или с умыслом бывают инсайдерами. (Как защищаться от инсайдеров?):

Чем больших успехов достигает человечество в борьбе с внешними киберугрозами, тем решительнее на первый план выходят угрозы внутренние, с которыми по статистике связано более 70% процентов всех инцидентов безопасности.
Александр Астахов, CISA, 2007

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

Правда, эти ресурсы стоят не дешево, но!

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

То, наверное, не так уж и дорого. Если:
- энергопотребление компьютерного парка за счет отсутствия огромного количества кондиционеров и резервных блоков питания серверов упало в десятки раз;
- не нужно платить за огромные офисные помещения, т.к. пользователи работают из любой точки мира был бы Интернет;
- риски по отказоустойчивости данных берет на себя провайдер облачных услуг;
- риски по устареванию техники берет опять же на себя провайдер облачных услуг;
- масштабируемость корпоративных приложений и данных имеет молниеносную статистику и может как увеличиваться, так и уменьшаться в случае необходимости (например, запустили акцию, отработали ее и свернули проект);
- не нужно пытаться удержать дорогостоящих ИТ-специалистов, которые обладают уникальными корпоративными знаниями о построенных бизнес-процессах и знающих 99,9% всех паролей на любой системе;
- скорость предоставления сервиса выдачи нового рабочего места пользователя сокращается от недели (закупка компьютера, настройка операционной системы и приложений таких как Microsoft Office, а также настройка сетевых дисков, прав доступа к папкам и т.д.) до пары минут, когда руководитель отдела запускает всего одну кнопочку на корпоративном портале сервисов;
- каждый бизнес точно знает свои расходы на ИТ-технику и эта головная боль снята с ИТ-директора;
- каждый пользователь посчитан и идентифицирован - если он уволен, то все его доступы автоматически заблокированы;
- можно расширять штат на краткий период - акции, презентации, внедрения и тому подобные движения души - и при этом не выходить за плановый бюджет;
- официальные органы с целью "наезда" на бизнес пытаются вынести сервера компании, а сервера где-то в "облаках";
- повысить надежность бизнеса в глазах зарубежных партнеров потому, что каждый бизнес-процесс становится "прозрачным" и имеет сертификацию либо по ISO 9001 либо по ISO 27001;
- перестать просыпаться в холодном поту ночью и пытаться расследовать инциденты информационной безопасности, которые могут уничтожить бизнес и лишить работы много обычных ответственных людей;
- нанимать счастливых людей и ставить вместе с ними нереальные, но достижимые цели.

Но для обеспечения такого современного уровня информационной безопасности необходимо идти в ногу с современными технологиями. И не бояться тратить деньги не на OEM-версии программных продуктов, а на облачные сервисы, технологии виртуализации и идентификации, а, самое главное, на средства мониторинга действий пользователей в сети и эвристического анализа этих действий.

Например, современные системы предотвращения утечек информации должны уметь регистрироваться в социальных сетях и идентифицировать контрагента, участвующего в инциденте.
Уметь строить графы взаимосвязей не только пользователей, но их активов (фирм, недвижимости, движимого имущества). Дружеских связей - как, например, это делают Facebook и LinkedIn.
Уметь подгружать в онлайне языки для автоматического перевода сообщений пользователя на иностранных языках и выявлять устойчивые лингвистические обороты, которые однозначно бы позволили идентифицировать утечку информации.

Кажется все фантастикой. Но уже сейчас многие могут смело использовать такие технологии как публичные облака для повышения вычислительной мощности своих серверов и ускорения бизнес-процессов обработки информации. А ведь всего год назад... это было невозможно.

* Gartner — исследовательская и консалтинговая компания, специализирующаяся на рынках информационных технологий. Наиболее известна введением в употребление таких терминов, как: ERP, магический квадрант, цикл зрелости технологий, а также регулярными исследованиями рынков информационных технологий и аппаратного обеспечения. Исследованиям Gartner регулярно посвящаются статьи в таких изданиях, как Financial Times, The Wall Street Journal, The New York Times, Der Spiegel, The Register, ZDNet

Перейти к Оглавлению

comments