З кожним роком компанії витрачають величезні суми на захист ІТ-інфраструктур. Ви можете наслідувати їхній приклад, а можете згадати про базові, але не менш важливі дії для захисту ІТ-інфраструктури.
1. Перевіряйте актуальність оновлень безпеки
Причина: Згадаймо такий яскравий приклад уразливості як Heartbleed (CVE-2014-0160) в OpenSSL. З її допомогою хакери отримували корпоративні ключі сервера та розшифровували трафік. На момент, коли весь світ дізнався про цю проблему в 2014 році, 500 тисяч сайтів вже були уразливими. Після випуску патча від розробників Google, кількість таких сайтів знизилося до 200 тисяч.
Рішення: Ця кількість сайтів могло б значно знизитися, якщо всі встановили оновлення. Ви самостійно можете налаштувати автоматичне оновлення безпеки для операційної системи. Або ж поцікавитися у вендорів з приводу інструментів автоустановки патчів. Для Debian – це утиліт Unattended Upgrades; для CentOS – yum-cron; для Red Hat – це AutoUpdates.
Важливо пам’ятати, що автоматичне оновлення не є універсальною панацеєю, тому бувають випадки, коли ця дія може призвести до збою або навіть падіння системи. Щоб такого не сталося, додатково тестуйте програмне забезпечення в «пісочниці».
2. Включайте розширення безпеки
Причина: Серед поширених ситуацій можна згадати помилку конфігурації. DNS-сервери копіюють інформацію між собою під час передачі зон. У цей момент зловмисники можуть використовувати ситуацію, щоб відправляти серверам помилкову інформацію запитів на DNS-сервера.
Рішення: Щоб не зіткнутися з такою проблемою можна скористатися моделлю Unix, яка, коли справа заходить до прав доступу і управління, пропонує три альтернативи: група користувачів, один користувач і всі інші. На додаток, щоб адміністраторам було простіше працювати, розробники ввели захисні розширення, побудоване на моделі примусового контролю доступу. Таким чином ви зможете ввести точну політику безпеки для існуючих процесів.
Також, розроблені спеціальні захисні програми: AppArmor, GrSecurity і SELinux. Останній з них вважається найбільш сильним і ефективним. SELinux пропонує наступні моделі для регулювання доступу:
- Type Enforcement (TE): До всіх суб’єктів і об’єктів додаються ідентифікатори, щоб пізніше можна було призначати політику та правила.
- Role-Based Access Control (RBAC): до кожної системі прив’язуються ролі, які пов’язані з певними доменними типами.
- Multi-Level Security (MLS): У всіх об’єктів є чіткий рівень доступу, який ставить рамки на їх можливості. Тобто, на своєму рівні об’єкти зможуть писати та читати інформацію, рівнем вище об’єкти зможуть тільки писати інформацію, а рівнем нижче – тільки читати її.
Якщо ми говоримо про систему Windows, то тут ви теж можете налаштувати права доступу усім вашим користувачам і/або групам в Azure Active Directory. Серед доступних ролей:
- Власник – користувач, який створив обліковий запис через записи Microsoft, а не Azure Active Directory. Має повний доступ.
- Менеджер – має повний доступ до свого облікового запису, крім як можливості змінювати параметри виплат і податків.
- Розробник – відправляє настройки, пакети та програми, може дивитися відомості телеметрії.
- Фінансист – переглядає звіти про придбання, виплати та іншу фінансову інформацію.
- Бізнес-учасник – переглядає звіти про використання та працездатність.
- Маркетолог – відповідає на відгуки споживачів і переглядає аналітичні звіти, не пов’язані з фінансами.
3. Відрегулюйте права доступу та введіть парольну політику
Причина: При всій очевидності цього правила багато людей повністю або частково його ігнорують. Більш того, за статистикою 60% фахівців, які пов’язані з ІТ-індустрією, діляться логінами і паролями з колегами. Підключення до сервера від імені адміністратора (root) так само несе певну небезпеку. Адже, якщо хакер зможе підключитися до сервера через адміністратора, то у нього буде повна влада над вашою системою.
Рішення: Для початку нагадуйте своїм співробітникам, що чим більш складний пароль вони придумають, тим менше ймовірність того, що ваша ІТ-інфраструктура буде заражена або пошкоджена. Джефф Етвуд, співзасновник платформ Stack Exchange і Stack Overflow, стверджує, що 10-символьний пароль з використанням великих літер, цифр та інших символів може зменшити ймовірність опинитися в списку злитих аккаунтів. Ці паролі не повинні піддаватися логічному підбору. Тобто, якщо ваш співробітник використовує P@ssw0rds$ в якості пароля, він підходить під умови Джеффа Етвуда. Але якщо ваш співробітник замінить його на b@$sVV0Rt$4, це буде більш надійний пароль, який важко підібрати.
Плюс, не забувайте регулярно нагадувати, щоб співробітники міняли паролі. Для необхідності зміни пароля існують дві головні парадигми:
- за сигналом, що можлива компрометація пароля;
- після закінчення певного періоду часу (місяць, квартал, рік).
Якщо ж ми говоримо про root доступ, то тут краще відразу створити нового користувача для співробітника, дати чіткі правила та права та вказати, що вхід в систему буде відбуватися тільки через цей аккаунт. Таким чином ви ускладните завдання для зловмисника, якому доведеться витратити час, щоб дізнатися ім’я користувача. Якщо ж необхідно ввести нового користувача з роллю адміністратора, то потрібно ще відключити стандартний обліковий запис root, або ж можна налаштувати права доступу в Windows, якщо у вас сервера не під *nix-системами.
4. Відрегулюйте правила та винятки для файрволів
Причина: В системі systemd була знайдена уразливість, яка пропускала DDoS-атаки. В результаті, коли ослаблена система відправляла DNS-запит до DNS-сервера, воно повертало запит, який міг викликати 100% навантаження CPU і ввести систему в нескінченний цикл.
Рішення: В якості захисту ви можете налаштувати файрвол так, щоб він блокував всі шкідливі пакети з ресурсними записами з 4 секції 4034. Якщо ви відкриєте доступ лише кільком сервісам, ви зменшите вірогідність атаки на вашу систему. Крім цього, спробуйте дотримуватися наступних правил:
- Якщо ви налаштовуйте нові правила, видаляйте старі.
- Перед тим, як ви почнете відкривати доступ у зовнішню мережу, встановіть параметр DROP для аналізу вхідного трафіку.
- Обмежте трафік IPv6.
- ICMP (Internet Control Message Protocol) використовується для передачі важливих даних про доступність серверів. Тому якщо навіть ви і збираєтеся обмежувати цей трафік, то уважно вивчіть ІТ-інфраструктуру своєї компанії.
5. Створіть захищене підключення через SSH
Причина: Тут проблема та ж, що і в третьому пункті. При відсутності додаткового захисту, зловмисники зможуть швидше проникнути в систему.
Рішення: Щоб уповільнити цей процес, створіть надійний SSH-ключ. Потім введіть парольну фразу, яка буде корисна в разі, якщо ключ буде скомпрометований. Щоб ви могли організувати цей процес, скористайтеся набором інструментів OpenSSH, який пропонує надійну і класичну конфігурацію.
Ще одним рівнем захисту для входу по SSH можуть стати пара криптографічних ключів. Якщо перший ключ можуть скомпрометувати, то другий набагато ускладнює цю задачу. Сам SSH-ключ може мати довжину до 2048 біт.
Альтернативним рішенням для захисту ІТ-інфраструктури може стати двофакторна автентифікація.
6. Впровадьте криптографію
Причина: Якщо ви зберігаєте ваші паролі в приватному репозиторії GitHub, це не означає, що ваші дані захищені. GitHub може бути скомпрометований, як це траплялося раніше, та ваші облікові та персональні дані будуть під загрозою.
Рішення: Зашифруйте ваші дані за допомогою криптографії. Перед вибором бібліотеки або інструменту для кріптошифрування, пам’ятайте такі правила:
- Впровадьте останні симетричні шифри типу Salsa20 і AES (NaCl).
- Використовуйте message authentication code (MAC) для регулювання цілісності й автентифікації ресурсу даних (Poly1305 або HMAC-SHA-512).
- Використовуйте перевірені рандомайзери для створення тимчасових кодів і ключів.
- Інструмент, який працює з вашими парольними фрази, повинен використовувати KDF.
7. Організовуйте та перевіряйте бекапи на регулярній основі
Причина: В GitLab був прецедент, коли системний адміністратор з Нідерландів видалив частину даних щодо запитів на зміну коду та документації проектів користувачів. Жодна з впроваджених систем бекапов не повернула дані.
Рішення: Намагайтеся не просто створювати бекапи, але і перевіряти їх готовність. Чим частіше ви будете це робити, тим краще. Є компанії, які організовують і перевіряють бекапи кожен день. Це вважається стандартною практикою. Також постарайтеся обмежити доступ до корпоративних серверів з резервної копії.
Також важливо географічне місце зберігання резервних копій. Варто створити кілька копій важливих даних, розподілити їх на різні носії та в різних географічних місцях розташування. Іншими словами, одна копія буде знаходитися в офісі, інша – в дата-центрі, а третя – в хмарі в Німеччині або в іншій країні.
Якщо ви не знаєте або не маєте можливості самостійно створювати резервні копії та забезпечувати бекап-інфраструктуру, команда TechExpert допоможе вам з цим рішенням на основі професійних продуктів. Зв’яжіться з нами, щоб ви дізналися більш детально про резервне копіювання та зберігання бекапов.
Висновок
На сьогоднішній день важливо розуміти для чого потрібен базовий захист ІТ-інфраструктури. Чим сильніше вона буде, тим спокійніше ви будете працювати. Ніякої розробник або програма не можуть вам гарантувати 100% захисту, але ви можете ускладнити завдання для хакера завдяки цим 7 базовим порадам щодо захисту ІТ-інфраструктури.
Якщо ви бажаєте підвищити рівень захисту вашої ІТ-інфраструктури, команда TechExpert пропонує наступні послуги і рішення:
- Забезпечення кібербезпеки на базі Fortinet
- Захист і шифрування даних на базі Shielded VM
- Впровадження DLP-систем
- Безпека периметра мережі на базі CheckPoint
За додатковою консультацією звертайтеся до наших фахівців.
