bga68comp: (Default)

Surface Pro 8. Сведения об устройстве и части службы

модели Surface Pro 8

1982 – Surface Pro 8 LTE (Платина)

1983 – Surface Pro 8 WiFi (Платина и Графит)

Размер диска rSSD и серийный номер для Surface Pro 8 находятся под подставкой.

Снимок экрана: нижней стороне Surface Pro 8 с открытой подставкой, где выделена область, в которой расположены серийный номер и размер rSSD.

Внимание

Нотация серийного номера устройства. Серийный номер этого устройства находится на его первоначальной нижней крышке. Очень важно сохранить исходный серийный номер устройства для поддержки в будущем от корпорации Майкрософт. FRU корпуса удаляет исходный серийный номер устройства, и исходный серийный номер устройства не может быть окончательно добавлен в замену части. Чтобы убедиться, что исходный серийный номер сохранен, запишите его, используя водонепроницаемые чернила на этикетке. Прикрепите метку к легкодоступной области на внешней стороне устройства и сохраните серийный номер в безопасном месте. Корпорация Майкрософт предоставила метку для этой цели в упаковке запасных частей. Этикетка, включенная в упаковку части, имеет место, выделенное для исходного серийного номера и идентификатора продукта части.

Подлинные запасные части Майкрософт

  • Подлинные запасные части Майкрософт можно получить непосредственно в корпорации Майкрософт на Microsoft.com.

  • Подлинные запасные части Майкрософт также доступны на сайтах партнеров ниже:

Иллюстрированный список частей службы

Схема Surface Pro 8 разорванных представлений с нумерованными выносками для компонентов kickstand, ssd door, rSSD, TDM, THM и Surflink.

Внимание

Доступность части службы устройств делится на две группы. FrUs — это части, доступные для восстановления через авторизованного поставщика услуг в соответствии с определенным контрактом с корпорацией Майкрософт. CrUs/Spares — это части, доступные для ремонта квалифицированным техническим специалистом.




ЭлементКомпонентFRU/ASP Part No.CRU Часть No.Модель: WiFi 1983Модель: LTE 1982SKU для замены
(1)Подставка
Graphite KickstandDHI-00002I61-00002X EP2-70036
Платиновый kickstandDHI-00001I61-00001X EP2-70035
Платиновый kickstandDHI-00003I61-00003 XEP2-70037
(2)SSD Door
Graphite SSD DoorDCB-00002DCI-00002X EP2-70039
Platinum SSD DoorDCB-00001DCI-00001XXEP2-70038
(3)Съемный Solid-State диск (ПРИМЕЧАНИЕ. Размер rSSD должен быть таким же, как исходный)
rSSD 128 ГБDDB-00001DFB-00001XX
rSSD 256 ГБDDI-00001DFI-00001XX
rSSD 512 ГБDEB-00001DGB-00001XX
rSSD 1TBDEI-00001DGI-00001X
(4)TDM
ProX TDM WWDHB-00001I62-00001XXEP2-70034
(5)THM
THM WiFiDBZ-00001 X
THM LTEDC8-00001 X
(6)Surflink
Surflink WWDBY-00001 XXEP2-69317


bga68comp: (Default)

rSSD (съемный Solid-State диск)

rSSD (Removable Solid-State Drive — съемный твердотельный накопитель) — это тип энергонезависимой памяти, используемой в современных вычислительных устройствах (например, в ноутбуках серии Microsoft Surface), который, в отличие от распаянных на плате SSD, можно легко извлечь и заменить.

https://learn.microsoft.com/ru-ru/surface/service-guides/surface-repair-safety-guidelines#general-safety-precautions


bga68comp: (Default)
PowerPoint та номери слайдів

Інколи виникає питання: як зробити так, щоб можна було змінити номери слайдів презентації і почати, наприклад, не з 2-го, а з 74-го?

Навіщо це потрібно? Наприклад, тому, що є вимога надати ТІЛЬКИ частину презентації.

Ось приклад як пронумерувати слайди в PowerPoint у цьому випадку.

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

Як змінити нумерацію слайдів у PowerPoint

Робимо через параметри презентації

  1. Відкрийте вкладку Конструктор (Design)
  2. На стрічці праворуч натисніть:
    Розмір слайда (Slide Size)
  3. Оберіть:
    Спеціальний розмір слайда... (Custom Slide Size)

    658

  4. У вікні «Розмір слайда» знайдіть поле:
    Нумерація слайдів з (Number slides from)

    659

  5. Встановіть, наприклад:
    74
  6. Натисніть OK

    660


Що відбудеться

  • Перший слайд стане №74

    661

  • Далі:
    • 2-й 75

      662

    • 3-й 76
      і так далі

Важливий нюанс (часто про нього забувають)

Якщо номер не відображається або виглядає не так:

Перевірте:

  1. Вкладка Вставлення Текст Колонтитули (Header & Footer)

    664

  2. Поставте галочку:
    Номер слайда (Slide number)

    665

  3. Натисніть:
    Застосувати до всіх

Порада

Якщо ви:
  • вставляєте Slides from PPTX_2 у загальну програму
  • або об’єднуєте кілька презентацій

то це і буде правильний спосіб, щоб:
  • не ламати нумерацію вручну
  • не малювати "74" як текст

З практики

Ручна нумерація слайдів — це як писати пароль на стікері: працює… але всі розуміють, що щось пішло не так.

Якщо вам це підійде, то всім гарного дня!


bga68comp: (Default)

Програми та служби, яким ви надали доступ



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

Посилання — Програми та служби, яким ви надали доступ:
https://account.live.com/consent/Manage


bga68comp: (Default)

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

Screenshot 2025-09-17 025206

Посібник з оцінки впливу ШІ
Ознайомтеся з внутрішнім довідником Майкрософт щодо оцінки впливу ШІ.
Дізнатися більше — https://go.microsoft.com/fwlink/?linkid=2272454&clcid=0x422&culture=uk-ua&country=ua

Шаблон оцінки впливу ШІ
Отримайте шаблон Microsoft для оцінки впливу ШІ.
Дізнайтеся більше — https://go.microsoft.com/fwlink/?linkid=2272455&clcid=0x422&culture=uk-ua&country=ua

Набір інструментів для роботи з ШІ
Використовуйте цей набір інструментів для планування та розробки орієнтованих на людей систем штучного інтелекту.
Дізнайтеся більше — https://go.microsoft.com/fwlink/?linkid=2272805&clcid=0x422&culture=uk-ua&country=ua

Набір інструментів для відповідального ШІ
Ознайомтеся з інтерфейсами та бібліотеками з відкритим кодом, які допомагають розробникам краще розуміти й відстежувати системи штучного інтелекту.
Дізнатися більше — https://go.microsoft.com/fwlink/?linkid=2272456&clcid=0x422&culture=uk-ua&country=ua

Безпека вмісту ШІ Azure
Автоматично виявляйте та блокуйте небезпечний вміст у підказках і результатах генеративного ШІ для вашої програми.
Дізнатися більше — https://azure.microsoft.com/en-us/products/ai-services/ai-content-safety/

Microsoft Purview
Захистіть усі дані й керуйте їх відповідністю для інструментів і систем ШІ.
Дізнатися більше — https://www.microsoft.com/uk-ua/security/business/microsoft-purview


bga68comp: (Default)

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

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


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

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

Огляд ISO/IEC 42001:2023


Read more... )


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)

У травні 2025 року Microsoft припиняє роботу Skype, щоб зосередитися на Microsoft Teams, їх сучасному центрі комунікацій і співпраці. 



Що чекає на користувачів Skype 
Skype — всьо...


Протягом перехідного періоду до 5 травня 2025 року користувачі мають вибір:

1. Перейти на Microsoft Teams безкоштовно. Найближчими днями Microsoft розгорне можливість для користувачів Skype входити в Teams (безкоштовно) на будь-якому підтримуваному пристрої за допомогою своїх облікових даних Skype, починаючи з сьогоднішнього дня — Прим.: опубліковано 28 лютого 2025 р — для тих, хто бере участь як у програмах Teams, так і в програмі Skype Insider. Увійшовши в Teams за допомогою облікового запису Skype, чати та контакти автоматично з’являться в програмі, тож ви зможете швидко продовжити з того місця, де зупинилися.

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

2. Експортувати дані Skype. Якщо ви не бажаєте переходити до Teams, ви можете натомість експортувати свої дані, зокрема чати, контакти та історію викликів.

Skype залишатиметься доступним до 5 травня 2025 року, що дасть користувачам час вивчити Teams і вибрати варіант, який їм найкраще підходить.

Microsoft каже:

Спосіб нашого спілкування за ці роки значно змінився. Від обміну миттєвими повідомленнями до відеодзвінків, технологія постійно змінює наш спосіб спілкування один з одним. 

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

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

Коли ми робимо наступний крок із Teams, ми в захваті від нових можливостей. Ми з нетерпінням чекаємо й надалі підтримувати повсякденні зв’язки людей, починаючи з полегшення входу в Teams за допомогою їхнього облікового запису Skype.



Хто ж у цьому всьому безладі винен?

Jeff Teper, President, Collaborative Apps and Platforms | Джефф Тепер
Президент, програми та платформи для спільної роботи

Original:
The next chapter: Moving from Skype to Microsoft Teams 


bga68comp: (Default)



If you use the M365 Public Roadmap JSON API, it will have a new URL from March 15, 2025. Thereafter, the old URL will no longer work.
Please change any dependencies you have using https://roadmap-api.azurewebsites.net/api/features
to use https://www.microsoft.com/releasecommunications/api/v1/m365

Microsoft 365 Roadmap


Get the latest updates on our best-in-class productivity apps and intelligent cloud services. Rethink productivity, streamline business processes, and protect your business with Microsoft 365.
The Microsoft 365 roadmap provides estimated release dates and descriptions for commercial features. All information is subject to change. As a feature or product becomes generally available, or is cancelled or postponed, information will be removed from this website. If Targeted release is available the Rollout start date will reflect the change beginning to appear in Targeted release followed by Standard release, otherwise the Rollout start date will reflect the change beginning to appear in Standard release.

Якщо ви використовуєте M365 Public Roadmap JSON API, він матиме нову URL-адресу з 15 березня 2025 року. Після цього стара URL-адреса більше не працюватиме.
Змініть будь-які залежності, які ви маєте за допомогою https://roadmap-api.azurewebsites.net/api/features, щоб використовувати https://www.microsoft.com/releasecommunications/api/v1/m365

Дорожня карта Microsoft 365


Отримуйте останні оновлення наших найкращих у своєму класі програм для підвищення продуктивності та інтелектуальних хмарних служб. Переосмисліть продуктивність, спростіть бізнес-процеси та захистіть свій бізнес за допомогою Microsoft 365.
Дорожня карта Microsoft 365 містить приблизні дати випуску та опис комерційних функцій. Вся інформація може бути змінена. Коли функція чи продукт стає загальнодоступним, скасовується чи відкладається, інформація буде видалена з цього веб-сайту. Якщо доступний цільовий випуск, дата початку розгортання відображатиме зміни, які починають з’являтися в цільовому випуску, а потім стандартний випуск, інакше дата початку розгортання відображатиме зміни, які починають з’являтися у стандартному випуску.


bga68comp: (Default)

Microsoft твердо перебуває в ері Copilot, і це означає, що цього року в Windows відбудеться неминуче оновлення, орієнтоване на штучний інтелект. Наступна версія ОС, Windows 12, імовірно під кодовою назвою «Hudson Valley», очікується в другій половині 2024 року (можливо, вже в червні, хоча цей термін не підтверджений).

Найбільшою відмінністю Windows 12 буде те, наскільки глибоко вона включає штучний інтелект, спираючись на можливості Copilot, які були представлені як попередній перегляд у Windows 11 23H2 минулої осені. Фактично, Microsoft вказала на початку року, що всі пристрої Windows 12 (і нові пристрої Windows 11) матимуть спеціальну кнопку Copilot, що ознаменувало «першу значну зміну в клавіатурі ПК з Windows майже за три десятиліття».

Анонс кнопки Copilot також натякає на цілі Microsoft щодо майбутніх версій Windows, починаючи з 12: «Ми продовжуватимемо створювати Windows, щоб стати місцем для отримання найкращих можливостей штучного інтелекту», — йшлося в оголошенні. «Для цього знадобиться операційна система, яка стирає межі між локальною та хмарною обробкою». [ПОВЕРНУТИСЯ ДО СПИСКУ ПРОДУКТІВ]



bga68comp: (Default)

Дорожня карта продуктів Microsoft до 2024 року

Усе, що потрібно знати партнерам Microsoft і ІТ-фахівцям про основні етапи розробки продуктів Microsoft цього року, включаючи наступний великий випуск Windows, Microsoft Copilot, Windows Server 2025, Teams тощо.


ОНОВЛЕНО: Visual Studio 2022, .NET 9, Windows Server 2025, Windows 11, Copilot



Windows 11 24H2 (UPDATED: 10/1)
Released
.NET 9 / .NET MAUI (UPDATED: 11/12)
Released
Visual Studio 2022 Updates (UPDATED: 11/13)
Expected: Ongoing
Semantic Kernel (AI SDK) Updates (UPDATED: 5/29)
Expected: Ongoing
SharePoint Premium
Expected: First Half of 2024
SharePoint Embedded (UPDATED: 5/21)
Released
SharePoint Server Subscription Edition Updates
Expected: Spring and Fall 2024
Fluid Framework 2.0
Expected: Summer 2024
Windows Server 2025 (UPDATED: 11/4)
Released
Planner (UPDATED: 4/30)
Released
Copilot Capabilities (UPDATED: 10/2)
Expected: Ongoing
Viva Updates
Expected: First Half of 2024
Mesh (UPDATED: 1/24)
Released
Teams Capabilities (UPDATED: 8/29)
Expected: Ongoing
Dynamics 365 (UPDATED: 8/29)
Expected: April & October 2024
Fabric Capabilities (UPDATED: 9/27)
Expected: First Half of 2024
Outlook Updates (UPDATED: 7/11)
Expected: Ongoing
Microsoft 365 Backup (UPDATED: 8/1)
Released
Microsoft 365 Archive
Expected: TBA
2024 Microsoft Product Deprecations



MFA

2024-11-18 16:45
bga68comp: (Default)

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

Это содержимое поможет вам с рабочей или учебной учетной записью, которая является учетной записью, предоставленной вам вашей организацией (например, dritan@contoso.com). Если у вас возникли проблемы с двухфакторной проверкой подлинности в личной учетной записи Майкрософт, см. статью Устранение неполадок с кодом проверки.

У меня нет мобильного устройства со мной

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

  1. Войдите в свою учетную запись, но щелкните ссылку Войти другим способом на странице Двухфакторной проверки подлинности.Изменение метода проверки входа
  2. Если вы не видите ссылку Войти другим способом, это означает, что вы не настроили другие методы проверки. Вам потребуется обратиться к администратору, чтобы получить помощь в входе в вашу учетную запись.
  3. Выберите альтернативный метод проверки и перейдите к двухфакторной проверке подлинности.
Read more... )
bga68comp: (Default)

Нерекомендуция устаревшего продукта Microsoft LAPS🙂



Нерекомендуция??? Ну, пусть будет нерекомендуция 😁
Джерело:
https://learn.microsoft.com/ru-ru/windows...


bga68comp: (Default)

1. Сначала ставим необходимые модули через PowerShell с административными правами

1.1 Cтавим оснастку:

Install-WindowsFeature -Name RSAT-AD-PowerShell

1.2 Установите модуль Azure Directory для Windows PowerShell
Чтобы установить общедоступную версию модуля, выполните следующую команду:

Install-Module AzureAD

или

Install-Module -Name AzureAD

1.3 Для политики выполнения сценариев PowerShell должно быть установлено значение remote signed или less restrictive. Используйте Get-ExecutionPolicy для определения текущей политики выполнения.

Командная строка: Чтобы установить политику выполнения, запустите:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

1.4 Установка Microsoft Graph PowerShell

The following prerequisites are required to use the Microsoft Graph PowerShell SDK with Windows PowerShell.

• Upgrade to PowerShell 5.1 or later
• Install .NET Framework 4.7.2 or later - Install .NET Framework for developers
• Update PowerShellGet to the latest version using Install-Module PowerShellGet

Командная строка:

Install-Module Microsoft.Graph -Scope AllUsers

1.5 Проверка установки Microsoft Graph PowerShell

После завершения установки вы можете проверить установленную версию с помощью следующей команды:

Get-InstalledModule Microsoft.Graph

1.6 Чтобы проверить установленные подмодули и их версии, запустите:

Get-InstalledModule

Способ 1: Проверка установленных модулей через

Get-InstalledModule

Способ 2: Проверка доступных модулей через

Get-Module -ListAvailable

Этот командлет покажет все доступные модули, которые установлены и могут быть загружены в сеанс PowerShell.

2. Встановлюємо ОЗ:

Install-ADServiceAccount -Identity gmsa1


3. Тестуємо ОЗ:

Test-ADServiceAccount gmsa1

4. Якщо потрібно змінити тих, хто може сервісний ОЗ використовувати:

Set-ADServiceAccount -Identity gMSA-учётка -PrincipalsAllowedToRetrieveManagedPassword СЕРВЕР$


Див.також:
Как отключить использование GMSA на локальной машине та видалення GMSA


bga68comp: (Default)

Чтобы отключить GMSA (Group Managed Service Account) от конкретного сервера в Windows, можно использовать следующую команду в PowerShell.

Uninstall-ADServiceAccount

Этот процесс удаляет использование GMSA на локальной машине.

Пример команды:

Uninstall-ADServiceAccount -Identity <GMSA_Account_Name>

Где <GMSA_Account_Name> — это имя вашей учётной записи GMSA.
Порядок действий:
  1. Откройте PowerShell с правами администратора на сервере, от которого необходимо отключить GMSA.
  2. Выполните команду выше, заменив <GMSA_Account_Name> на реальное имя вашей GMSA.
  3. После выполнения команды сервер больше не будет использовать указанную GMSA.

Если потребуется также удалить саму учётную запись из Active Directory, это можно сделать с помощью команды:

Remove-ADServiceAccount -Identity <GMSA_Account_Name>

Эта команда удалит GMSA из AD полностью.

Див.також:
Установить GMSA на локальный компьютер


bga68comp: (Default)

Вимоги, що підсилюють захист DMZ у разі використання хмарних рішень, зокрема при роботі з персональними даними та інфраструктурою як послугою (IaaS).

ВимогаОписПосилання на стандарт або нормативний акт
1. Сегментація мережіМережеві сегменти повинні бути чітко відокремлені, з обмеженим доступом між внутрішньою мережею, DMZ-зоною та Інтернетом.ISO 27001:2022, A.13.1.3; PCI DSS v4.0, п. 1.2.1; НБУ Постанова №75
2. Контроль доступу до ресурсівВпровадження суворих правил контролю доступу до серверів у DMZ на основі ролей, мінімізації прав доступу.ISO 27002:2022, 9.4.3; PCI DSS v4.0, п. 7.2; Закон України "Про захист персональних даних"
3. Аутентифікація та авторизаціяВикористання двофакторної аутентифікації для адміністраторів та всіх, хто має доступ до критичних ресурсів у DMZ.ISO 27002:2022, 9.4.2; PCI DSS v4.0, п. 8.3; НБУ Постанова №43
4. Логування і моніторингВсі події у DMZ повинні бути автоматично записані в журнали, зберігатися і періодично перевірятися.ISO 27001:2022, A.12.4.1; PCI DSS v4.0, п. 10.1; НБУ Постанова №217
5. Оцінка ризиківПроводити регулярну оцінку ризиків для визначення загроз у DMZ, включаючи вразливості нових технологій.ISO 27005:2022, п. 5.4; ISO 31000:2018, п. 6.3; COBIT 2019, EDM03
6. Захист від шкідливого ПЗУстановити системи захисту від шкідливого ПЗ на всіх серверах і мережевих пристроях у DMZ.ISO 27001:2022, A.12.2.1; PCI DSS v4.0, п. 5.1; НБУ Постанова №95
7. Регулярні оновлення і патчіОновлення програмного забезпечення та систем безпеки в DMZ повинні проводитися регулярно для захисту від нових загроз.ISO 27002:2022, 12.5.1; PCI DSS v4.0, п. 6.2; Кращі практики Cisco, Microsoft
8. Процедури аварійного відновленняВпровадження та тестування планів аварійного відновлення для серверів і пристроїв у DMZ.ISO 27001:2022, A.17.1.2; PCI DSS v4.0, п. 11.1; НБУ Постанова №243
9. Оцінка ефективності заходів безпекиРегулярно проводити аудит безпеки та тестування заходів захисту DMZ для забезпечення їх ефективності.ISO 27001:2022, A.18.2.3; PCI DSS v4.0, п. 12.11; ТОGAF 10, ADM
10. Виявлення і реагування на інцидентиНеобхідно впровадити системи для автоматичного виявлення і швидкого реагування на інциденти безпеки в DMZ.ISO 27002:2022, 16.1.1; PCI DSS v4.0, п. 12.5; НБУ Постанова №65
11. Безпека в хмарних середовищахПри розгортанні DMZ у хмарі необхідно враховувати відповідальність між хмарним провайдером та клієнтом за захист інфраструктури. Важливо чітко розмежувати зони відповідальності.ISO/IEC 27017:2015, п. 5.1
12. Контроль доступу до хмарних ресурсівВсі адміністратори і користувачі з доступом до хмарних ресурсів, пов'язаних з DMZ, повинні мати відповідні ролі і права, з акцентом на мінімізацію прав доступу.ISO/IEC 27017:2015, п. 9.4
13. Захист персональних даних у хмаріЯкщо DMZ обробляє персональні дані, необхідно застосовувати додаткові заходи для захисту таких даних, зокрема шифрування та контроль доступу.ISO/IEC 27018:2019, п. 4.1; Закон України "Про захист персональних даних"
14. Шифрування даних у хмаріВсі дані, які передаються через DMZ в хмарних середовищах, повинні бути зашифровані на рівні мережевих передач та зберігання.ISO/IEC 27018:2019, п. 5.2.1
15. Виявлення та реагування на інциденти у хмаріНеобхідно забезпечити наявність інструментів для виявлення інцидентів безпеки в хмарному середовищі, зокрема в зоні DMZ, та швидке реагування на них.ISO/IEC 27017:2015, п. 16.1
16. Моніторинг та аудит хмарних середовищРегулярний моніторинг подій у DMZ та хмарі має проводитися для оцінки ефективності заходів безпеки, зокрема в межах процесу аудиту.ISO/IEC 27017:2015, п. 12.4
17. Інформування про інциденти з персональними данимиУ разі виявлення інцидентів, пов'язаних з персональними даними у DMZ, необхідно мати механізми для швидкого інформування про це відповідальних осіб.ISO/IEC 27018:2019, п. 9.1

Примітки:

  • ISO/IEC 27017:2015 надає додаткові рекомендації щодо безпеки в хмарних середовищах, зокрема для забезпечення безпеки DMZ в хмарі.
  • ISO/IEC 27018:2019 фокусується на захисті персональних даних, що є критичним при обробці таких даних у хмарних інфраструктурах.

Примітки:

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


Кращі практики Cisco:

  1. Cisco Safe Architecture:
    • Розподіл мережевих зон: Рекомендується чітко відокремлювати критичні ресурси (внутрішня мережа) від зовнішніх (Інтернет) за допомогою DMZ. Роль DMZ — забезпечити захищений шлюз для публічно доступних ресурсів.
      • Джерело: Cisco SAFE Design Guide.
  2. Cisco Next-Generation Firewalls (NGFW):
    • Додаткові механізми захисту: Використання систем глибокого аналізу трафіку, виявлення вторгнень (IDS/IPS) та фільтрації шкідливого ПЗ у трафіку через DMZ.
      • Джерело: Cisco Firepower NGFW Best Practices.
  3. Сегментація за допомогою ACL (Access Control Lists):
    • Контроль доступу між зонами: Використання ACL для точного контролю доступу між різними мережевими зонами, такими як внутрішня мережа, DMZ та Інтернет.
      • Джерело: Cisco ASA Firewall Configuration Guide.

Кращі практики Fortinet:

  1. Fortinet Security Fabric:
    • Інтегрований моніторинг та видимість: Використання платформи для централізованого управління та моніторингу мережевих пристроїв у різних зонах, включаючи DMZ, для швидкого виявлення та реагування на загрози.
      • Джерело: Fortinet Security Fabric Best Practices.
  2. FortiGate Firewall:
    • Застосування політик безпеки: Використання гнучких політик безпеки для контролю трафіку в DMZ з акцентом на мінімізацію доступу до внутрішньої мережі та використання зон захисту для різних рівнів сегментації.
      • Джерело: FortiGate NGFW Best Practices.
  3. Захист від DDoS-атак:
    • Фільтрація та захист DMZ від DDoS-атак: Використання технологій Fortinet для виявлення та блокування атак на рівні DMZ, щоб запобігти перевантаженню серверів і доступних з Інтернету ресурсів.
      • Джерело: Fortinet DDoS Protection Best Practices.

Кращі практики Microsoft:

  1. Azure Security Center:
    • Моніторинг та реагування в хмарних середовищах: У разі розгортання ресурсів у хмарі Microsoft рекомендує інтеграцію DMZ з Azure Security Center для проактивного виявлення загроз та управління вразливостями.
      • Джерело: Microsoft Azure Security Center Best Practices.
  2. Active Directory (AD) та Azure AD:
    • Управління доступом через AD: Використання ролей та груп доступу для чіткого контролю, хто має права на доступ до ресурсів у DMZ. Рекомендується використовувати двофакторну аутентифікацію (MFA) для додаткового захисту.
      • Джерело: Microsoft AD Security Best Practices.
  3. Windows Defender Advanced Threat Protection (ATP):
    • Виявлення загроз і захист від шкідливого ПЗ: Впровадження Windows Defender ATP на серверах у DMZ для виявлення та блокування потенційних загроз на основі поведінкових аналізів і захисту в реальному часі.
      • Джерело: Microsoft Windows Defender ATP Best Practices.



Profile

bga68comp: (Default)
bga68comp

June 2026

S M T W T F S
 1234 56
78910111213
14151617181920
21222324252627
282930    

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated 2026-06-06 04:55
Powered by Dreamwidth Studios