Від стартапу до оборонного підприємства: коли DefenseTech час будувати enterprise IT

💡 Усі статті, обговорення, новини про оборонні технології — в одному місці. Приєднуйтесь до DefTech спільноти!

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

Але є проблема, яка закономірно виникає під час такого зростання: корпоративне IT не завжди масштабується разом із бізнесом.

Компанія може розробляти складні системи computer vision, автономної навігації чи зв’язку, але при цьому облік обладнання вести в Google Sheets, доступи надавати вручну, використовувати спільні акаунти, передавати файли через месенджери, а встановлення програмного забезпечення виконувати руками системних адміністраторів.

На етапі 20–30 людей це може бути цілком раціонально.

На етапі 500 — це вже технічний борг.

На етапі 2000 — операційний ризик.

Google Workspace — не проблема

Одразу варто провести важливу межу.

Google Workspace, Microsoft 365, Slack, Jira чи будь-який інший окремий продукт сам по собі не визначає зрілість IT.

Проблема виникає тоді, коли немає системи управління IT-середовищем.

Умовна компанія може мати:

• Google Workspace;
• сотні Windows/macOS/Linux endpoint’ів;
• декілька виробничих майданчиків;
• Telegram або Slack;
• десятки SaaS-сервісів;
• локальні сервери;
• хмарні ресурси;
• виробниче обладнання.

Ключове питання не в тому, які саме продукти вона використовує. Ключове питання:

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

Якщо відповідь отримати складно — проблема вже існує.

IT має масштабувати бізнес, а не створювати бюрократію

Enterprise IT часто асоціюється з великою кількістю процедур, approvals, change requests та корпоративною бюрократією — Це погана реалізація enterprise IT.

Мета правильно побудованої IT-інфраструктури — протилежна: зробити контрольоване середовище максимально непомітним для користувача.

Новий інженер отримує ноутбук — Він входить корпоративним обліковим записом — Пристрій автоматично реєструється — Застосовуються security policies — Встановлюється необхідне програмне забезпечення — Надаються доступи відповідно до ролі — Asset потрапляє до inventory — EDR починає передавати telemetry — Користувач може працювати.

IT при цьому не виконав двадцять ручних операцій — Саме automation, а не кількість процедур, є однією з головних ознак зрілої IT-функції.

Identity має стати новим периметром

Класичний корпоративний IT десятиліттями будувався навколо мережевого периметра. Сьогодні для розподіленої компанії значно важливішим стає identity — людина може працювати з офісу, виробничого майданчика, лабораторії або віддалено, тому фундаментом архітектури стає відповідь на три питання:

Хто ти? З якого контрольованого пристрою ти працюєш? До якого ресурсу тобі дозволено отримати доступ?

Звідси вже виникають IAM, MFA, Conditional Access, RBAC, Privileged Access Management та автоматизований identity lifecycle.

Особливо важливим стає joiner-mover-leaver process.

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

HR-подія повинна запускати керований lifecycle identity.

Другий фундамент — endpoint management

Якщо компанія не може швидко відповісти на питання:

Скільки у нас зараз Windows-пристроїв, які версії ОС вони використовують і на яких із них відсутнє критичне оновлення?

— значить endpoint environment ще не є повністю контрольованим.

На масштабі сотень і тисяч пристроїв ручне адміністрування перестає працювати.

Потрібні централізовані:

• inventory;
• configuration management;
• patch management;
• software deployment;
• vulnerability management;
• encryption;
• EDR;
• compliance policies;
• remote support.

Причому це не обов’язково означає один конкретний продукт. Це може бути Microsoft Intune, Configuration Manager, Jamf, Ansible або інший набір технологій. Архітектура важливіша за бренд продукту. Одна із моїх улюблених аналогій — конструктор лего — хтось будує вежі у висоту, а хтось із тих же деталей будує повнофункціональні моделі.

IT Asset Management: Excel перестає бути CMDB

На початковому етапі таблиця з ноутбуками може чудово виконувати свою функцію. Проблема починається, коли з’являються тисячі assets: ноутбуки, сервери, телефони, мережеве обладнання, ліцензії, SaaS subscriptions, virtual machines, cloud resources.

У цей момент потрібно знати не просто серійний номер ноутбука, потрібно бачити зв’язок:

User → Device → Software → Configuration → Access → Business Service.

Саме тут inventory поступово перетворюється на ITAM та CMDB і це вже дозволяє відповідати на значно цікавіші питання.

Наприклад:

Які бізнес-сервіси постраждають, якщо цей сервер стане недоступним?

або:

На яких пристроях встановлена ця версія програмного забезпечення?

або:

Скільки реально використовується придбаних ліцензій?

IT починає працювати з даними, а не з припущеннями.

Security без централізації дуже швидко стає дорогою

DefenseTech має очевидно вищу цінність як ціль для атак, ніж звичайний SMB, але security неможливо побудувати лише закупівлею security products — можна придбати чудовий EDR, SIEM або PAM але якщо при цьому компанія не має якісного inventory, identity management та configuration management, значна частина ефективності цих систем втрачається — не можна захистити те, про існування чого ти не знаєш.

Тому security architecture починається не із SOC — вона починається з контрольованого середовища.

З якого моменту потрібно переходити до enterprise IT?

Я не думаю, що існує магічне число співробітників — 50 людей у software startup і 50 людей у компанії з R&D, виробництвом та кількома майданчиками — абсолютно різні середовища. Я б дивився на інші сигнали:

IT-команда перестає точно знати всі пристрої; Onboarding потребує великої кількості ручної роботи; Offboarding викликає питання: «А де ще в нього був доступ?» ; одні й ті самі дані ведуться у декількох таблицях; з’являються shared accounts; кількість SaaS-сервісів ніхто точно не знає; patch compliance неможливо отримати натисканням декількох кнопок; IT knowledge концентрується в головах кількох людей.

Якщо ви бачите вищенаведені ознаки, то це означає що ваш ризик вже зростає — у цей момент компанія вже платить за відсутність системної IT-архітектури, під «платить» мається наувазі як фактичне збільшення штату через нецентразілованість та ручні процеси, так і зростання критичних ризиків, тобто відкладений платіж на вирішення операційних втрат.

Просто цей рахунок ще може бути непомітним.

Не треба будувати корпорацію раніше, ніж вона потрібна

Є й протилежна помилка — компанії зі 100 співробітниками не потрібна IT-архітектура, скопійована з банку на 30 000 користувачів. Enterprise practices потрібно адаптувати до масштабу бізнесу. Я б сформулював принцип так:

Minimum bureaucracy, maximum control, automation by default.

Політика потрібна там, де вона зменшує ризик. Процес потрібен там, де він забезпечує повторюваність. Інструмент потрібен там, де він прибирає ручну операцію або створює visibility. Якщо процес існує тільки тому, що «так роблять великі корпорації», можливо, він не потрібен.

Якою може бути цільова модель

Для DefenseTech-компанії, яка переходить від startup до enterprise scale, я б розглядав декілька базових capabilities:

Identity & Access Management

Єдина identity, MFA, RBAC, privileged access, automated lifecycle.

Endpoint Management

Centralized configuration, patching, software deployment, encryption, EDR та compliance.

IT Asset Management

Єдиний inventory hardware, software, licenses та ownership.

IT Service Management

Incident, request, change та knowledge management без перетворення ITIL на бюрократію.

Observability

Централізовані logs, metrics, alerts та dashboards.

Security

Zero Trust principles, EDR/XDR, SIEM, vulnerability management, DLP та PAM відповідно до ризиків компанії.

Business platforms

ERP/MRP/MES/CRM/BI там, де ручні процеси вже перестають масштабуватися.

Automation

Інтеграція всього цього в єдині workflows.

І останній пункт, на мою думку, найважливіший.

Enterprise IT — це не набір enterprise-продуктів

Можна витратити мільйони на Microsoft, SAP, ServiceNow, Palo Alto або CrowdStrike — і все одно отримати погано керовану інфраструктуру. А можна побудувати досить просту систему, яка буде контрольованою, автоматизованою і добре масштабуватиметься.

Зрілість IT визначається не вартістю software stack, вона визначається тим, наскільки добре компанія контролює свої identity, devices, data, applications, infrastructure та processes.

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

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

Саме тут якісно побудоване IT перестає бути support function (ще з 2014 року терпіти не міг це формулювання міжнародних аудиторів що до визначення ролі ІТ) — воно стає частиною виробничої спроможності бізнесу.

Підписуйтеся на WhatsApp-канал DefTech спільноти!