bga68comp: (Default)





Join Mark Russinovich, CTO and Technical Fellow of Microsoft Azure. Mark will take you on a tour of the latest innovations in Azure architecture and explain how Azure enables intelligent, modern, and innovative applications at scale in the cloud, on-premises, and on the edge.
00:00-01:24 Opening 01:14-03:25 Datacenter tour 03:25-06:42 Microfluidics cooling 06:42-15:37 Azure Boost, Boost enabled Bare Metal GPU Instances, cross region RDMA 15:37-24:40 Direct Virtualization (Live migration, Azure container instance, Manifold) 24:40-30:41 Disaggregated SDN 30:41-33:59 Scaled storage 33:59-41:17 Confidential computing, Azure Integrated HSM 41:17-44:59 Optical computing


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)

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

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

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

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


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

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

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

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

Див.також:
Вимога до інтеграції програмного забезпечення. OAuth 2.0
bga68comp: (Default)
Azure VMware Solution - Lightning Lab (HOL-2494-91-ISM)

https://labs.hol.vmware.com/HOL/catalog/lab/14620

Get a quick overview of Azure VMware Solution, which combines VMware compute, networking, and storage running on top of dedicated, bare-metal hosts in Microsoft Azure.

Сведения о практической работе
In this lab, we will introduce Azure VMware Solution concepts and provide a tour of the administrative console.

Lab Modules
Module 1 - Azure VMware Solution Concepts (15 minutes) Basic
Сводка по практической работе
Продукты
Azure Cloud


Связанные практические работы
Azure VMware Solution Planning and Deployment (HOL-2494-04-ISM) - https://labs.hol.vmware.com/HOL/catalog/lab/14619
0d 1h 30m
Развернуто по требованию
Step though a complete deployment of an Azure VMware Solution private cloud.
bga68comp: (Default)
 
Безперервність бізнес-процесів та аварійне відновлення для Рішення Azure VMware
Безперервність бізнес-процесів та аварійне відновлення (BCDR)

Незалежно від того, чи є у вас локальне середовище або рішення Azure VMware, слід враховувати різні фактори BCDR для підготовки до аварії. Надійний план BCDR спрямований на захист компанії від втрати даних, фінансової втрати та простою у разі руйнівних подій. Наступне дерево прийняття рішень показує різні варіанти BCDR, доступні для Рішення Azure VMware.



Див. повну версію:
Безперервність бізнес-процесів та аварійне відновлення для Рішення Azure VMware 27.04.2023
 
bga68comp: (Default)
 



Мал. 1. Традиційна топологія мережі Azure

Рекомендації щодо проектування.

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

• Віртуальні мережі не можуть виходити за межі передплати, але ви можете забезпечити можливість підключення між віртуальними мережами в різних підписках за допомогою пірінгу між віртуальними мережами, каналу ExpressRoute або VPN-шлюзів.

• Для підключення віртуальних мереж в Azure кращим способом є пірінг між віртуальними мережами. Піринг між віртуальними мережами можна використовувати для підключення віртуальних мереж в одному регіоні, між різними регіонами Azure та різними клієнтами Microsoft Entra.

• Як піринг між віртуальними мережами, і глобальний піринг між віртуальними мережами є транзитивними. Щоб увімкнути транзитну мережу, потрібні маршрути (UDR) і віртуальні (модуль) мережі (NVA), що визначаються користувачем. Щоб отримати додаткові відомості, див. Зіркоподібна мережа топології в Azure.

• Ви можете надати спільний доступ до плану захисту від атак DDoS Azure у всіх віртуальних мережах в одному клієнті Microsoft Entra для захисту ресурсів із загальнодоступними IP-адресами. Щоб отримати додаткові відомості, див. Захист від атак DDoS Azure.

 ◌ Плани захисту від атак DDoS Azure охоплюють лише ресурси із загальнодоступними IP-адресами.

 ◌ Вартість плану захисту від атак DDoS Azure включає 100 загальнодоступних IP-адрес у всіх захищених віртуальних мережах, пов'язаних із планом захисту від атак DDoS. Захист додаткових ресурсів доступний за окремою ціною. Додаткові відомості про ціни на план захисту від атак DDoS Azure див. на сторінці цін на захист від атак DDoS Azure або на запитання, що часто ставляться .

 ◌ Перегляньте підтримувані ресурси планів захисту від атак DDoS Azure.

• Канали ExpressRoute можна використовувати для підключення між віртуальними мережами в межах одного регіону або за допомогою надбудови рівня "Преміум" для підключення між регіонами. Пам'ятайте наступне:

 ◌ Мережевий трафік може зіткнутися з більшою затримкою, оскільки трафік має прикріпитись до маршрутизаторів Microsoft Enterprise Edge (MSEE).

 ◌ Номер SKU шлюзу ExpressRoute обмежує пропускну здатність.

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

• VPN-шлюзи з протоколом BGP є транзитивними в Azure та локальних мережах, але за промовчанням не надають транзитивний доступ до мереж, підключених через ExpressRoute. Якщо вам потрібний транзитивний доступ до мереж, підключених через ExpressRoute, розгляньте сервер маршрутизації Azure.

• При підключенні кількох каналів ExpressRoute до однієї віртуальної мережі використовуйте ваги підключень та методи BGP, щоб забезпечити оптимальний шлях для трафіку між локальними мережами та Azure. Щоб отримати додаткові відомості, див. Оптимізація маршрутизації ExpressRoute.

• Використання метрик BGP, щоб вплинути на маршрутизацію ExpressRoute – це зміна конфігурації, виконана за межами платформи Azure. Ваша організація або постачальник послуг з'єднання повинні належним чином настроїти локальні маршрутизатори.

• Канали ExpressRoute із надбудовами рівня "Преміум" забезпечують глобальний зв'язок.

• ExpressRoute має певні обмеження; Існує максимальна кількість підключень ExpressRoute на шлюз ExpressRoute, а приватний піринг ExpressRoute може визначити максимальну кількість маршрутів з Azure до локального середовища. Додаткові відомості про обмеження ExpressRoute див. у розділі "Обмеження ExpressRoute".

• Максимальна сумарна пропускна здатність VPN-шлюзу становить 10 гігабіт на секунду. VPN-шлюз підтримує до 100 тунелів типу "мережа-мережа" або "мережа-мережа".

• Якщо NVA є частиною архітектури, розгляньте azure Route Server, щоб спростити динамічну маршрутизацію між віртуальною мережею (модуль) (NVA) та віртуальною мережею. Сервер маршрутизації Azure дозволяє обмінюватися даними про маршрутизацію безпосередньо через протокол маршрутизації BGP (BGP) між будь-яким NVA, що підтримує протокол маршрутизації BGP та програмно-визначувану мережу Azure (SDN) у віртуальній мережі Azure без необхідності вручну налаштовувати або підтримувати таблиці маршрутів.

Рекомендації щодо проектування.

• Розглянемо архітектуру мережі на основі традиційної зіркоподібної топології мережі для наступних сценаріїв:

 ◌ Мережева архітектура, розгорнута в одному регіоні Azure.

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

 ◌ Мережева архітектура, яка охоплює кілька регіонів Azure та пірінг глобальних віртуальних мереж, які можуть підключати віртуальні мережі між регіонами Azure.

 ◌ Немає потреби у можливості транзитивного підключення між підключеннями VPN та ExpressRoute.

 ◌ Основним методом гібридного підключення є ExpressRoute, а кількість VPN-підключень менше 100 на VPN-шлюз.

 ◌ Існує залежність від централізованих мережевих віртуальних модулів та детальної маршрутизації.

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

 ◌ Крос-локальне підключення через ExpressRoute.

 ◌ VPN для підключення гілки.

 ◌ Підключення між периферійними мережами за допомогою NVAs та визначених користувачем користувачів.

 ◌ Захист від вихідного трафіку через Інтернет через Брандмауер Azure або іншу сторонню NVA.

Див.:
Традиційна топологія мережі Azure. 28.03.2023
 
bga68comp: (Default)
XP: 1000

Захист локальної інфраструктури від аварій за допомогою Azure Site Recovery

Дізнайтеся, як забезпечити аварійне відновлення для локальної інфраструктури за допомогою Azure Site Recovery для керування та оркестрації реплік. Використовуйте Site Recovery для відпрацювання відмови та відновлення розміщення віртуальних машин VMware, віртуальних машин Hyper-V та фізичних серверів.

Цілі навчання

У цьому модулі:

  • Знайомство з функціями та можливостями захисту, які надає Azure Site Recovery для локальної інфраструктури.
  • Виявлення вимог щодо включення захисту локальної інфраструктури.
Продовжити >

Попередні вимоги

  • Базове уявлення про віртуальні машини Azure
  • Базове уявлення про віртуальні мережі Azure
  • Базове уявлення про основні поняття аварійного відновлення
   
bga68comp: (Default)
BCDR — план безперервності бізнес-процесів та аварійного відновлення (Business Continuity Disaster Recovery)

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

Кожен збій оцінюється окремо.


Приклад
План BCDR набуває чинності, коли весь центр обробки даних відключається від джерела електроживлення.


У рамках плану BCDR для додатків чи компонентів систем розглядають
• цільовий час відновлення (RTO) і
• цільову точку відновлення (RPO).


An illustration showing the duration, in hours, of the recovery point objective and recovery time objective from the time of the disaster / Ілюстрація, що показує тривалість у годинах цільової точки відновлення та цільового часу відновлення з моменту катастрофи.

Цільовий час відновлення

RTO — це значення максимального часу, протягом якого ваш бізнес може протриматися після аварії доти, доки не буде відновлено нормальне обслуговування, щоб уникнути неприпустимих наслідків, пов'язаних із перериванням бізнес-процесів.

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


Цільова точка відновлення

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

Наприклад, якщо
резервне копіювання виконувалося кожні 24 години, опівночі, а аварія сталася о 9:00, будуть втрачені дані за дев'ять годин. Якщо цільова точка відновлення компанії становила 12 годин, нічого страшного, адже минуло лише дев'ять годин. Однак, якщо цільова точка відновлення становила чотири години, це може стати проблемою і завдати шкоди..


Огляд Azure Site Recovery. Безперервність бізнес-процесів та аварійне відновлення
 
bga68comp: (Default)
Использование управления привилегиями конечных точек с Microsoft Intune

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

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

  • Windows 11 версии 22H2 (22621.1344 или более поздней) с KB5022913
  • Windows 11 версии 21H2 (22000.1761 или более поздней) с KB5023774
  • Windows 10 версии 22H2 (19045.2788 или более поздней) с KB5023773
  • Windows 10 версии 21H2 (19044.2788 или более поздней) с KB5023773
  • Windows 10 версии 20H2 (19042.2788 или более поздней) с KB5023773
bga68comp: (Default)
Безкоштовні ресурси/симуляції Azure Lab

Якщо ви хочете отримати знання про технології Microsoft або вивчити нові інструменти, перегляньте наведені нижче симуляції:

1. Створіть нового користувача в Azure AD
https://lnkd.in/gm2Qfr5A

2. Керуйте ідентифікаторами Azure AD
https://lnkd.in/gGKN-7eX

3. Увімкніть SSPR в Azure AD
https://lnkd.in/ggKKt5NZ

4. Створіть політику умовного доступу
https://lnkd.in/gZigbcdQ

5. Дослідіть рейтинг безпеки Microsoft
https://lnkd.in/gxaarvqK

6. Використовуйте оцінку безпеки в Microsoft Defender, щоб покращити стан безпеки
https://lnkd.in/gFKnSFX5

7. Захисник Microsoft 365 для хмарних програм
https://lnkd.in/gJjFwmpa

8. Ознайомтеся з порталом довіри до послуг
https://lnkd.in/g-ReCYKw

9. Дослідіть портал відповідності Microsoft Purview
https://lnkd.in/gP_-RSck

10. Ознайомтеся з менеджером відповідності
https://lnkd.in/gUd6BYaK

11. Керуйте підписками та RBAC
https://lnkd.in/g4Jmzu9q

12. Керуйте керуванням за допомогою політики Azure
https://lnkd.in/gSF6vJPt

13. Керуйте ресурсами Azure за допомогою порталу Azure
https://lnkd.in/gFAzwgPd

14. Керуйте ресурсами Azure за допомогою шаблонів ARM
https://lnkd.in/g-Xf7Crj

15. Керуйте ресурсами Azure за допомогою Azure PowerShell
https://lnkd.in/gPyDt2zW

16. Керуйте ресурсами Azure за допомогою Azure CLI
https://lnkd.in/gqXTn9fN

17. Впровадити віртуальну мережу
https://lnkd.in/gRb8cbei

18. Впровадити зв'язок між сайтами
https://lnkd.in/gU9Zt7Dc

19. Впровадити управління трафіком
https://lnkd.in/geThBtbA

20. Керуйте сховищем Azure
https://lnkd.in/gdYd7u-4

21. Керуйте віртуальними машинами
https://lnkd.in/gisq2g2e

22. Впровадження веб-програм Azure
https://lnkd.in/gFs7vJQy

23. Впровадження екземплярів контейнерів Azure
https://lnkd.in/ghvPHPx9

24. Впровадити службу Azure Kubernetes
https://lnkd.in/gXMa847F

25. Резервне копіювання віртуальних машин
https://lnkd.in/gJTVUnw8

26. Здійснити моніторинг
https://lnkd.in/gcd3hytY
bga68comp: (Default)


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

  • Office 365, 

  • Windows 10, 

  • Azure Active Directory, 

  • Microsoft Intune, 

  • Microsoft Dynamics 365, 

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




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 12:51
Powered by Dreamwidth Studios