С каждым годом компании тратят огромные суммы на защиты ИТ-инфраструктур. Вы можете последовать их примеру, а можете вспомнить о базовых, но не менее важных действий по защите ИТ-инфраструктуры.
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
За дополнительной консультацией обращайтесь к нашим специалистам.
