bga68comp | Entries tagged with архітектура

Скільки середовищ має бути в життєвому циклі ІТ-системи?

У життєвому циклі ІТ-системи зазвичай виділяють від 3 до 6 середовищ, залежно від рівня зрілості процесів та вимог до безпеки. Найбільш поширена структура включає:

1. Development (DEV)

Середовище розробки

Використовується розробниками для написання та первинного тестування коду.
Низький рівень обмежень, можливі нестабільності.

2. Testing (TEST) або QA

Середовище тестування функціональності / контролю якості

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

3. Staging (STG) або Pre-Production

Передпродуктивне середовище

Майже повна копія продуктивного середовища: ті ж версії ПЗ, архітектура, налаштування.
Використовується для перевірки релізів перед впровадженням у продакшн.

4. Production (PROD)

Продуктивне (робоче) середовище

Обробляє реальні користувацькі дані.
Високі вимоги до доступу, стабільності, безпеки.

Додатково можуть використовуватись:

5. UAT (User Acceptance Testing)

Середовище приймального тестування

Замовники або бізнес-користувачі перевіряють, чи відповідає рішення їхнім очікуванням.

6. Sandbox

Середовище-пісочниця для експериментів, навчання та демонстрацій

Безпечне середовище для тестування ідей або навчання без ризику для основної системи.

Підсумкова таблиця:

№	Назва середовища	Призначення
1	DEV (Розробка)	Розробка та початкове тестування
2	TEST або QA	Функціональне та автоматизоване тестування
3	STG (Передпродакшн)	Перевірка перед виходом у продакшн
4	PROD (Продуктивне)	Робота з реальними даними
5	UAT	Приймальне тестування замовником
6	Sandbox (Пісочниця)	Експерименти, PoC, навчання

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

Коли архітектура — мистецтво

Бувало таке: треба швиденько накидати архітектуру в AWS — типу “ось тут база, ось тут бекенд, а тут якийсь сервіс, який іноді працює” — ти відкриваєш Microsoft Visio або Draw.io, а воно тобі у відповідь: «Ну… я старався…». І ти дивишся на цю схему і думаєш: "Показувати "оце це" замовнику? Може, краще ні?.."

Але вихід завжди є!😎

👉 https://aws.amazon.com/architecture/icons

Що всередині:

AWS підготував офіційні піктограми, шаблони і навіть рекомендації, щоб діаграми виглядали як у людей. Красиво. Зрозуміло. І без сорому.
Тут ви знайдете набір офіційних піктограм Amazon Web Services, які можна використовувати у своїх проектах:

– піктограми для кожного сервісу AWS (навіть для тих, які ще не встиг придумати архітектор),
– шаблони для Visio, PowerPoint, Lucidchart,
– приклади схем, щоб надихнутись.

З цим набором схема архітектури більше не виглядатиме як план втечі з Excel — вона буде, як мінімум, претендувати на “AWS Diagram of the Year 2025”❤️

Це не реклама, бо я не працюю в AWS 😉

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

Вимоги, що підсилюють захист 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:

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

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

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

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

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

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

Архітектура будь-якої ІТ-системи зазвичай складається з чотирьох загальних рівнів, які відповідають вимогам TOGAF (The Open Group Architecture Framework) та ISO 27001 (система управління інформаційною безпекою). Ці рівні також узгоджуються з життєвим циклом ІТ-систем. Вони включають:

Бізнес-архітектура:
- Описує бізнес-процеси, функції, організаційну структуру та ключові бізнес-стратегії.
- У рамках TOGAF цей рівень визначає, як ІТ-система підтримує бізнес-цілі.
- Відповідно до ISO 27001, бізнес-архітектура враховує вимоги щодо безпеки, що необхідні для досягнення бізнес-цілей.
Інформаційна архітектура:
- Охоплює структуру даних та управління інформацією, включаючи моделі даних, потоки інформації та логіку бізнес-процесів.
- TOGAF забезпечує інтеграцію інформаційної архітектури з бізнес-архітектурою.
- ISO 27001 зосереджує увагу на захисті інформаційних активів на цьому рівні.
Архітектура додатків:
- Визначає програмні компоненти, інтерфейси, інтеграцію систем та взаємодію між різними додатками.
- TOGAF акцентує увагу на сумісності та масштабованості додатків.
- ISO 27001 включає вимоги до безпеки додатків, наприклад, контроль доступу та захист від загроз.
Технологічна архітектура:
- Включає технічну інфраструктуру, включаючи сервери, мережеве обладнання, системи зберігання даних, та забезпечення їхньої надійності та безпеки.
- TOGAF пропонує розробку технологічної архітектури для підтримки попередніх рівнів.
- ISO 27001 забезпечує впровадження технічних засобів безпеки, таких як шифрування, контроль доступу та моніторинг безпеки.

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

Таблиця, яка відображає чотири рівні архітектури ІТ-системи з більш детальними вимогами відповідно до TOGAF та ISO 27001:

Рівень архітектури	Опис	Вимоги TOGAF	Вимоги ISO 27001
Бізнес-архітектура	Описує бізнес-процеси, функції, організаційну структуру та ключові бізнес-стратегії.	- Визначення бізнес-процесів та функцій. - Вирівнювання ІТ-стратегії з бізнес-цілями. - Моделювання бізнес-процесів. - Визначення ключових показників ефективності (KPI).	- Визначення вимог до інформаційної безпеки з боку бізнесу. - Аналіз ризиків для бізнес-процесів. - Інтеграція вимог безпеки в бізнес-процеси. - Встановлення ролей та відповідальності.
Інформаційна архітектура	Охоплює структуру даних та управління інформацією, включаючи моделі даних, потоки інформації та логіку бізнес-процесів.	- Моделювання інформаційних потоків. - Визначення інформаційних об'єктів та їх відносин. - Підтримка цілісності та доступності даних. - Забезпечення інтеграції інформації між бізнес-процесами.	- Захист конфіденційності, цілісності та доступності інформації. - Управління класифікацією інформації. - Впровадження політик захисту інформації. - Оцінка та управління ризиками для інформаційних активів.
Архітектура додатків	Визначає програмні компоненти, інтерфейси, інтеграцію систем та взаємодію між різними додатками.	- Проектування архітектури додатків з урахуванням бізнес-архітектури. - Забезпечення масштабованості та сумісності. - Визначення інтерфейсів та протоколів. - Моделювання життєвого циклу додатків.	- Контроль доступу до додатків. - Забезпечення захисту від загроз і вразливостей. - Впровадження криптографічних заходів. - Ведення аудиту та моніторинг безпеки додатків.
Технологічна архітектура	Включає технічну інфраструктуру, включаючи сервери, мережеве обладнання, системи зберігання даних, та забезпечення їхньої надійності та безпеки.	- Визначення технічних стандартів та платформ. - Підтримка сумісності між компонентами. - Проектування інфраструктури для забезпечення високої доступності та відмовостійкості. - Підтримка масштабованості інфраструктури.	- Впровадження засобів шифрування. - Забезпечення фізичної та технічної безпеки. - Моніторинг та реагування на інциденти. - Використання технологій захисту мережі (брандмауери, VPN, IDS/IPS).

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

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

Мал. 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

Архітектура мережі Microsoft Purview та рекомендації
→ https://learn.microsoft.com/ru-ru/purview/concept-best-practices-network

Вариант 1. Использование общедоступных конечных точек
→ https://learn.microsoft.com/ru-ru/purview/concept-best-practices-network#option-1-use-public-endpoints

( Read more... )

Архітектура - це, перш за все, малюнок, який чітко і зрозуміло (однозначно) пояснює схему рішення на всіх рівнях ІТ-інфраструктури та взаємодію всіх компонентів.

Декілька прикладів опису архітектури для Microsoft Defender for Endpoint:

Архітектура	опис
Хмарна архітектура	Ми рекомендуємо використовувати Microsoft Intune для підключення, налаштування та виправлення кінцевих точок із хмари для підприємств, які не мають локального рішення для керування конфігурацією або хочуть скоротити свою локальну інфраструктуру.
Співуправління	Організаціям, які розміщують як локальні, так і хмарні робочі навантаження, ми рекомендуємо використовувати ConfigMgr і Intune від Microsoft для потреб керування. Ці інструменти надають комплексний набір функцій керування на базі хмарних технологій, а також унікальні параметри спільного керування для надання, розгортання, керування та захисту кінцевих точок і додатків у всій організації.
Локальне середовище	Підприємствам, які хочуть скористатися перевагами хмарних можливостей Microsoft Defender for Endpoint, а також максимально збільшити свої інвестиції в Configuration Manager або Active Directory Domain Services, ми рекомендуємо цю архітектуру.
Оцінка та підключення вручну	Ми рекомендуємо цю архітектуру для SOC (центрів безпеки), які хочуть оцінити або запустити пілотний пакет Microsoft Defender for Endpoint, але не мають інструментів керування чи розгортання. Цю архітектуру також можна використовувати для підключення пристроїв у невеликих середовищах без інфраструктури керування, наприклад у DMZ (демілітаризованій зоні).

Як виглядає архітектура рішення залежно від різних засобів та методів підключення пристроїв до ІТ-інфраструктури.

Малюнок 1. Хмарна архітектура

Малюнок 2. Архітектура співуправління

Малюнок 3. Архітектура локального середовища

Малюнок 4. Оцінка та підключення вручну

Джерело:
https://learn.microsoft.com/uk-ua/microsoft-365/security/defender-endpoint/deployment-strategy?view=o365-worldwide#step-1-identify-your-architecture

Працюючи в одній із компаній, я зіткнувся з терміном "пілотний проект".

При цьому в жодній документації (стандартах чи політиках) не було цього поняття. Та й ніхто до ладу роз'яснити його не міг. Менеджери з продажу партнерів чи дистриб'юторів активно пропонували провести пілот їхніх рішень "за безкоштовно".

Тільки як проводити те, чого немає у документації? Воно поза правилами і навіщо ті правила свідомо порушувати?

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

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

При цьому залишається питання: обмежена кількість користувачів або пристроїв - це скільки? 10 - це багато чи мало? А 50? Це багато чи ще мало? Результати, які будуть отримані на такій кількості, будуть адекватними для цього конкретного виробничого середовища підприємства?

Для того, щоб не було таких слизьких моментів, потрібно вчитися, вчитися і ще раз вчитися. А краще насамперед читати документацію передових вендорів 🙂

Компанія Microsoft, наприклад, ділить проекти в ІТ-інфраструктурі на кола розгортання.

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

Для продукту Microsoft Defender це виглядає так:

Коло розгортання	Опис
Оцінка	Коло 1. Визначте 50 пристроїв для підключення до служби для тестування.
Пілотний проект	Коло 2. Визначення та підключення наступних 50–100 кінцевих точок у робочому середовищі. Microsoft Defender для кінцевої точки підтримує різні кінцеві точки, які можна підключити до служби. Для отримання додаткових відомостей див. у розділі Вибір способу розгортання.
Повне розгортання	Коло 3. Розгортання служби в іншому середовищі з великим кроком. Для отримання додаткових відомостей див. у статті Початок роботи з розгортанням Microsoft Defender для кінцевої точки.

Джерело:
https://learn.microsoft.com/ru-ru/microsoft-365/security/defender-endpoint/onboarding?view=o365-worldwide#deploy-using-a-ring-based-approach

Іншими словами, оцінка – це тестовий проект.
Повне розгортання - це рішення, яке працює у робочому виробничому середовищі.
Отже, приходимо і до наступного:

Пілотний проект / пілот – це можливість використання 50-100 одиниць обладнання у виробничому середовищі підприємства.

Користуємося!

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

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

Источник:

https://www.vmware.com/ru/products/magna.html

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

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

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

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

Microsoft Intune предлагает функции:

управления мобильными устройствами (MDM) и
управления мобильными приложениями (MAM).

Решения MDM и MAM предназначены для выполнения следующих ключевых задач:

Поддержка разнообразных мобильных сред и безопасное управление устройствами с iOS, Android, Windows и macOS.
Обеспечение соответствия устройств и приложений требованиям безопасности в организации.
Создание политик для защиты данных организации на корпоративных и личных устройствах.
Использование единого мобильного решения для применения этих политик и управление устройствами, приложениями, пользователями и группами.

Intune входит в состав Microsoft 365, а также интегрируется с Azure Active Directory (Azure AD). Azure AD помогает контролировать лиц, имеющих права доступа, а также ресурсы, к которым они обращаются.

Высокоуровневая эталонная архитектура показывает варианты интеграции Microsoft Intune в среде Azure с использованием Azure Active Directory:

Источник:
https://docs.microsoft.com/ru-ru/intune/high-level-architecture

The Open Group Architecture Framework (TOGAF) - методология/библиотечный метод описания/подход (framework) для описания архитектуры предприятия, который предлагает подход для проектирования, планирования, внедрения IT-архитектуры предприятия и управления ей. TOGAF разрабатывается с 1995 группой The Open Group на основе фреймворка Министерства обороны США TAFIM.

TOGAF - высокоуровневый подход к проектированию. В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов:

Бизнес архитектура (Business) — определяет стратегию предприятия, структуру управления и ключевые бизнес процессы.
Архитектура данных (Data) — описывает логическую и физическую структуру данных организации, а также структуру корпоративных ресурсов для управления данными.
Архитектура приложений (Application) — служит своеобразной картой всех используемых корпоративных приложений и определяет следующие аспекты:

участие каждого из приложений в бизнес процессах компании;
взаимодействие приложений друг с другом и внешними сервисами.

Технологическая архитектура (Technology) — определяет структуру и логику программного обеспечения и аппаратной среды, необходимых для работы бизнес приложений и доступа к нужным данным. Этот уровень включает всю поддерживающую инфраструктуру: сети, сервера, процессинг и т.п.

TOGAF распространяется свободно и может быть использована бесплатно любой организацией для разработки внутренних проектов.

Содержание

( Read more... )

Архитектура управления правами Azure

https://docs.microsoft.com/ru-ru/azure/information-protection/what-is-azure-rms

Перейти на стартовую страницу https://bga68.livejournal.com

http://blog.vmpress.org/2017/09/vdi-1.html

vmlogo

Немного о дизайне VDI

Что включает в себя дизайн VDI - в диаграмма в виде MindMap

Оригинал и PDF версия по ссылке.

Часть 1. Введение

Первая глава "Введение" содержит общую информацию, описание основных преимуществ и недостатков VDI, а также перечень основных игроков рынка VDI.

Часть 2. Постановка задачи

Во второй главе "Постановка задачи" я перейду к рассмотрению вопроса формирования требований, которые являются основой для дальнейшего проектирования VDI.

Часть 3. Верхнеуровневая архитектура

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

Часть 4. Подсистема VMware Horizon

Четвертая глава "Подсистема VMware Horizon" содержит информацию о VMware Horizon, описание основных технологий, типов виртуальных рабочих мест и методов их создания и назначения пользователям.

Часть 5. Подсистема виртуализации

Пятая глава "Подсистема виртуализации" будет посвящена теме серверной виртуализации VMware vSphere. Здесь будут рассмотрены вопросы проектирования vCenter Server, Platform Services Controller, кластеров ESXi.

Часть 6. Лицензирование VDI

В шестой главе "Лицензирование VDI" будет затронута тема лицензирования программного обеспечения, необходимого для построения VDI.

Часть 7. Виртуальные машины

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

Часть 8. Подсистема хранения

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

Часть 9. Сетевая подсистема

В девятой главе "Сетевая подсистема" приводится информация о проектировании виртуальной сетевой подсистемы, а также кратко описаны основные функциональные возможности VMware NSX.

Часть 10. Организация подключения и безопасность

В десятой главе "Организация подключения и безопасность" рассматриваются вопросы организации доступа к VDI, сравниваются различные типы клиентских устройств, а также способы балансирования нагрузки. Также в главе рассматриваются вопросы обеспечения антивирусной защиты виртуальных рабочих мест.

Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление

Одиннадцатая глава "Доступность, резервное копирование и аварийное восстановление" включает в себя описание механизмов повышения доступности компонентов VDI инфраструктуры, описание способов резервного копирования и обеспечения аварийного восстановления VDI.

Часть 12. Дополнительные сервисы

В последней, двенадцатой главе "Дополнительные сервисы" описывается проектирование дополнительных компонентов VDI – средств доставки приложений, мониторинг, управление профилями, данными и настройками пользователей.

Компоненты инфраструктуры VMware Horizon View

Автор: Andrey Konovalov

Microsoft Cybersecurity Reference Architecture

Материалы для специалистов по информационным технологиям > Галерея > безопасность > Microsoft Cybersecurity Reference Architecture

https://gallery.technet.microsoft.com/Cybersecurity-Reference-883fb54c

Эталонная архитектура кибербезопасности Майкрософт (MCRA) является частью Microsoft Security Adoption Framework (SAF). Она описывает возможности и технологии кибербезопасности Майкрософт и их интеграцию с платформами Майкрософт и сторонними платформами, такими как Microsoft 365, Microsoft Azure, Amazon Web Services (AWS) и Google Cloud Platform (GCP).

MCRA включает в себя ключевые сведения о следующих параметрах:

Антипаттерны (распространенные ошибки) и рекомендации
Наборы правил для конечной архитектуры
Тенденции угроз и шаблоны атак
Сопоставление возможностей Майкрософт с ролями организации
Сопоставление возможностей Майкрософт с стандартами нулевого доверия
Обеспечение безопасности привилегированного доступа
Справочные планы в SAF (включая пример модернизации исправлений)
Приоритет использования прибыли злоумышленника на инвестиции (ROI)

Эта архитектура помогает архитекторам и техническим специалистам определить возможности по применению интеграции с возможностями корпорации Майкрософт и другими существующими возможностями.

Если вам нужно больше информации, вы можете найти её .

https://learn.microsoft.com/uk-ua/security/adoption/mcra

© Cisco Systems, Inc, 2009

https://www.cisco.com/c/dam/global/ru_ru/downloads/broch/Cisco_Security_Architecture.pdf

https://www.cisco.com/c/dam/en/us/products/security/SecurityRefArch_slide_vs_3_0_Non_Animated_and_Animated.pdf

https://www.cisco.com/c/dam/en/us/products/security/Security_Reference_Architecture_Poster_vs_3_0.pdf

Дополнительная информация:

● Новости Cisco по ИБ . Для подписки на новости по информационной безопасности Cisco на русском языке достаточно написать запрос в свободной форме на адрес security-request@cisco.com
● Security Policy Builder (http://www.ciscowebtools.com/designer/). Web-помощник, автоматизирующий создание типовой политики информационной безопасности.
● Security Solution Designer (http://www.ciscowebtools.com/designer/). Web-помощник, автоматизирующий создание защищенного сетевого дизайна для небольших предприятий.
● PCI Advisor (http://www.pcicomplianceadvisor.com). Web-помощник по стандарту PCI DSS и решениям Cisco, помогающим соответствовать требованиям данного стандарта.
● Secure Business Advisor (http://www.securitybusinessadvisor.com). Web-помощник, автоматизирующий подбор решений Cisco по информационной безопасности, исходя из уже внедренных решений и бизнес-потребностей.
● Cisco Security Center (http://www.cisco.com/security). Единая точка входа на все ресурсы Cisco по информационной безопасности

VMware AirWatch Recommended Architecture Guide

https://resources.air-watch.com/view/24s6gmlmccckn4nwzdyz

( Read more... )

Cisco. Иерархическая структура сети для ЦОД

В иерархическом представлении сеть Cisco формирует уровни ядра, агрегации и доступа.

http://www.cisco.com/web/RU/downloads/broch/white_paper_c11-722425.pdf

Рис. 1. Иерархическая структура сети