bga68comp | Entries tagged with cloud

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

Для кого це:

Команди з управління ризиками третіх сторін
Постачальники 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

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

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

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

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

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

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

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

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

Керівні принципи (рамки) впровадження та аудиту 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

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

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

Для кого це:

Керівники інформаційної безпеки (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

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

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

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

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

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

Огляд ISO/IEC 42001:2023

( Read more... )

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

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

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

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

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

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

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

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

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

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

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

Без объявления войны...
Замечательный бесплатный сервис — MediaFire — для хранения файлов.
Очень удобно на нем хранить картинки для публикации в ЖЖ.
Но!
В какой-то момент картинки перестали отображаться.
ЖЖ поломался.
Первое, что пришло в голову — сервис бесплатный, значит, лег и произошла банальная утеря файлов. Ведь никто не обещал ~~кормить на пути к Коммунизму~~ хранить вечно.
Второй трезвый взгляд натолкнул на мысль: другие бесплатные хранилки нормально отдают файлы для просмотра. Значит, проблема не в ЖЖ.
MediaFire просто изменил протокол доступа к разделяемым ресурсам.
Почему именно виноват MediaFire?
Потому, что после каждой картинки в HTML тегах нужно прописывать теперь параметр "?size_id=n", где n - 1, 2, 3 и... судя по всему до 8.
Этот параметр обозначает размер картинки, передаваемой в ЖЖ.
Жаль, что каждый раз этот размер может быть индивидуальный...

Плакаты и средства архитектуры, которые содержат информацию об облачных службах Майкрософт, таких как

Office 365,

Windows 10,

Azure Active Directory,

Microsoft Intune,

Microsoft Dynamics 365,

а также гибридных и облачных решениях:

Серия "Облако Майкрософт для корпоративных архитекторов"

Идентификация в облаке Майкрософт для корпоративных архитекторов

Обеспечение безопасности в облаке Майкрософт для корпоративных архитекторов

Организация сети в облаке Майкрософт для корпоративных архитекторов

Гибридное облако Майкрософт для корпоративных архитекторов

Распространенные атаки и средства Майкрософт для защиты вашей организации

Базовая инфраструктура Microsoft 365 корпоративный

Подходы в отношении архитектуры для переходов между клиентами в облаке Майкрософт

Серия "Корпоративные решения для Microsoft 365"

Microsoft Teams и связанные службы повышения производительности в Microsoft 365 для ИТ-архитекторов

Группы в Microsoft 365 для ИТ-архитекторов

Безопасность и защита информации для межрегиональных организаций

Защита идентификации и устройств в Office 365

Решения для защиты файлов в Office 365

Защита информации в Office 365 в соответствии с GDPR

Руководство по безопасности (Майкрософт) для политических кампаний, некоммерческих и других динамических организаций

Решения Майкрософт для телефонии

Блог VMware для конечных пользователей

https://blogs.vmware.com/euc/2020/03/most-important-piece-business-continuity-people-experiences.html

https://blogs.vmware.com/euc/2020/03/what-to-do-if-you-suddenly-have-to-support-80-of-users-working-remotely.html

https://techzone.vmware.com/blog/leveraging-horizon-cloud-microsoft-azure-business-continuity

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

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

Картинка с русскими заголовками (кликабельно):

Английский вариант в виде картинки:
Gartner Top 10 Trends Impacting Infrastructure and Operations for 2020

Бизнес есть бизнес.
Я помню эту фишку с момента когда пришел в недоумение от того, что один ИТ-гигант купил у своего прямого конкурента производственный конвейер.
Как так?!!
Разве можно "кормить своего врага"?!!
Можно.
И нужно.
Бизнес есть бизнес.
Там - дешевле!

Слово "войны" мне почему-то не нравится. Мне нравится больше - "здоровая конкуренция".
Хотя почему она "здоровая", если все равно выматывает и заставляет балансировать на грани успеха каждую секунду?

Но, положительные моменты в этом во всем все-таки есть.
Итак.

Май 2017. Случилось невероятное: VMware и Microsoft предложили совместную услугу VMware Horizon Cloud on Microsoft Azure (подробности тут)

Пятница, 01 Декабря, 2017. Война брендов окончена. VMware и Microsoft объявили о совместном продукте

( Read more... )

11.06.2019 Copmuterworld. Альянс Microsoft и Oracle нацелен против Amazon

( Read more... )

18.09.2019. Copmuterworld. В Oracle пошли на сотрудничество с очередным конкурентом. Теперь с VMware

( Read more... )

11 ноябрь, 2019. Компьютерное обозрение. Линейка VMware Tanzu поможет ускорить внедрение решений на Kubernetes

( Read more... )

11 ноября 2019 I.T.PRO. VMware анонсировала обновление линейки продуктов

( Read more... )

Решения VMware в Azure

( Read more... )

Переносите или расширяйте локальные среды VMware в Azure
Без проблем переносите рабочие нагрузки на базе VMware из своего центра обработки данных в Azure и интегрируйте используемую среду VMware с Azure. Продолжайте управлять существующими средами с помощью уже знакомых вам средств VMware, модернизируя приложения с использованием собственных служб Azure. Решения VMware в Azure поставляются корпорацией Майкрософт, проверяются компанией VMware и работают в инфраструктуре Azure.

Совместные решения Azure VMware

( Read more... )

Profile

bga68comp

December 2025

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

CSA — Структура можливостей безпеки SaaS (SSCF)
CSA — Гібридна хмара та пов'язані з нею ризики
CSA — Керівні принципи впровадження та аудиту AICM
CSA — Стан хмарних технологій та безпеки ші у 2025 році
Пропозиції Microsoft щодо відповідності вимогам
ORM
ISO/IEC/IEEE 42010: Viewpoint & View
TOGAF vs ISO 42010 vs Разом
Інформаційна архітектура ІТ-системи компанії. Приклад
Вимоги до хмарних сервісів у стандартах ІБ
CASB (Cloud Access Security Broker)
Блог зламався
DNS from Cloudflare
MediaFire... ё маё...
Ресурсы для администраторов, посвященные архитектуре Microsoft Cloud
Самая важная часть непрерывности бизнеса: ваши люди и их опыт | Блог VMware
Что делать, если вам вдруг придется поддерживать 80% пользователей, работающих удаленно
Использование Horizon Cloud в Microsoft Azure для обеспечения непрерывности бизнеса | VMware
Gartner. Топ-10 тенденций, влияющих на инфраструктуру и эксплуатацию в 2020 году
Говорят, что войны гигантов закончились

Style Credit

Style: Neutral Good for Practicality by timeasmymeasure

Expand Cut Tags

No cut tags

Page generated 2025-12-24 08:25