Защита серверов и данных: Zero Trust и 20 фич для вашей кибербезопасности
Серверы — штука надёжная. Особенно в опытных руках. На аппаратном уровне многие системы и комплектующие продублированы, частичное обслуживание возможно на ходу без остановки работы, а при виртуализации и кластеризации даже полное обслуживание с живой миграцией виртуалок и полной остановкой отдельных узлов. Резервируют и сетевые каналы на магистральном уровне, а иногда и целые кластеры, реализуя «heartbeat» — регулярные сигналы между системами в разных дата-центрах, чтобы убедиться, что они работают и синхронизированы.
Но потом на ваш прекрасный отказоустойчивый сервер приходит обновление от CrowdStrike (инструмент защиты от кибератак), которая вроде как должна бороться со всем плохим, а не примыкать к нему. И ещё 8,500,000 серверов и ПК по всему миру присоединяются к вечеринке, после которой банки, аэропорты (да и авиация в целом), больницы, службы безопасности и другие блага цивилизации отсыпаются где-то в ванной.
Миллиардные убытки, колоссальный репутационный ущерб. И даже кибератак не было по официальным данным — сами себе в ногу стрельнули.
В этой статье я расскажу о полезных практиках, которые защитят ваши серверы и данные — от своих и чужих. А в конце уже по классике опрос. И помните, лучший способ стать просветлённым — указать на ошибки автора и вступить в спор с случайным комментатором на Хабре:)
ВАЖНО! Некоторые советы из статьи не очень удобны (или очень неудобны) для пользователей и админов. Самая безопасная система — выключенная система, и в реальности надо балансировать между удобством сотрудников, клиентов и безопасностью. Часты случаи, когда безопасность настолько закошмарена, что сотрудники просто уходят из компании. Отдельно скажу, что иногда бизнес вкладывает большие деньги в безопасность из операционной прибыли, а потом балансирует на грани банкротства. Да, кибербезопасность (КБ) стоит дорого, включая расходы на персонал (придётся расширять штат, так как некоторые процессы замедлятся). Поэтому важно отличать здоровую паранойю от нездоровой, оценивать риски и стоимость (включая косвенные расходы) их митигации. Другой важный нюанс! Первое и самое главное, что нужно сделать — резервное копирование. Без него никуда. С учениями по восстановлению, а то окажется, что бэкапы нерабочие. И желательно хранить их так, чтоб их не пошифровали, иначе толку 0. Как вариант — оффлайн-бэкапы, изолированные хранилища или облачные решения с защитой. |
Кибербезопасность — если долго смотреть в логи, то логи начнут смотреть в тебя
Кибербезопасность обычно ассоциируется с защитой от внешних угроз, но пример с CrowdStrike из введения показывает, что изнутри можно наворотить дел больше, хуже и одновременно проще, чем извне.
Внедрение правильных процедур тестирования и отката обновлений — важная часть внутреннего кибербеза. Человеческий фактор тоже никто не отменял: от слабых паролей, вроде «qwerty1234», до «ой, я случайно удалил архив для налоговой», «запустил вложенный файл от лжеруководителя и всё сломалось». Сюда же нелицензионное ПО с вирусами-шифровальщиками, вроде «Бесплатный VPN для просмотра ютюбчика без замедления».
Ещё бочка дёгтя в ложке мёда — низкая квалификация или недостаток опыта у админов: неправильные настройки систем оставляют уязвимости, которые могут (а значит будут) использовать злоумышленники. Не свои всё сломают, так чужие рано или поздно.
Внутренние системы безопасности должны постоянно контролировать состояние IT-инфраструктуры, выявлять аномалии, включая те, что вызваны внутренними сбоями, и автоматически реагировать на них. При грамотной реализации можно избежать эскалации проблем, вроде технического сбоя в СДЭК после кибератаки, который по некоторым оценкам привёл к ущербу от 300 мл. до 1 млрд рублей. Грамотная ИБ/КБ и бэкапы обошлись бы дешевле.
Zero Trust: админ, который не доверяет никому (даже себе) — хороший админ
Пришло время поговорить о концепции Zero Trust («нулевое доверие») — это модель кибербезопасности, основанная на принципе «никому не доверяй». И всех проверяй : D
При Zero Trust ты как бы исходишь из того, что система уже скомпрометирована всеми сразу. Основное отличие от традиционных моделей безопасности — каждый пользователь должен подтверждать свои данные, каждый запрос на доступ к ресурсам должен быть проверен, аутентифицирован и ограничен по необходимости. Внутренняя сеть или внешний контур — неважно.
Первый шаг при внедрении модели Zero Trust — это аудит и инвентаризация всех ресурсов и данных, которые необходимо защитить. Данные в первую очередь. Это могут быть базы данных, файлы, облачные хранилища (включая сервисы), приложения, архивы и любые другие элементы, доступ к которым нужно строго контролировать.
Что делать:
Проведите полную инвентаризацию всех IT-активов компании, включая владельцев активов — кто отвечает за него, и за что, собственно, отвечает актив (логика следующая: этот сервер для 1С, этот для сайта, они завязаны на бизнес-процессы такие-то и такие-то; и если эти процессы критичны для бизнеса, очевидно, что такие серверы нужно усиленно защищать).
Определите критические данные и ресурсы, доступ к которым требует особого контроля.
Оцените текущие методы защиты и выявите потенциальные уязвимости.
Политики доступа (если у вас по наитию не получился Zero Trust) нужно пересмотреть и переделать под новую концепцию защиты. Доступ должен предоставляться на основе принципа минимальных (достаточных для работы) привилегий, и каждое действие пользователя должно быть ограничено его прямыми обязанностями.
Что делать:
Внедрите подход RBAC (Role Based Access Control, управление доступом на основе ролей), где доступ к ресурсам предоставляется на основе должности и роли сотрудника.
Настройте политики и системы IAM (Identity and Access Management, управление идентификацией и доступом), обеспечивающие строгий контроль над правами пользователей.
Реализуйте MFA (Multi-Factor Authentication, многофакторную аутентификацию) для всех пользователей, особенно для доступа к критическим ресурсам (если доступ снаружи — must have).
Сегментация сети — это основа Zero Trust, которая помогает изолировать различные части инфраструктуры друг от друга. Это не только усложняет распространение атак, но и упрощает управление доступом и мониторинг.
В рамках Zero Trust мониторинг не должен ограничиваться проверкой входа в систему. Важно постоянно отслеживать поведение пользователей и устройств, анализировать аномалии и оперативно реагировать на потенциальные угрозы.
Что делать:
Внедрите решение для мониторинга класса SIEM (Security Information and Event Management): Это система, которая помогает собирать и анализировать логи в реальном времени. Хотя SIEM сам по себе не отвечает за реагирование на инциденты, он предоставляет данные и контекст для оперативной работы команд SOC (Security Operations Center) и EDR/XDR систем.
Рассмотрите внедрение SOC (Security Operations Center) и систем EDR/XDR: SOC свой (или как сервис) обеспечивает постоянный мониторинг и реагирование на инциденты, а EDR (Endpoint Detection and Response) и XDR (Extended Detection and Response) помогают оперативно реагировать на угрозы, обеспечивая глубокую видимость и защиту конечных точек (например, при обнаружении подозрительной активности может автоматически блокироваться устройство).
Используйте решения UEBA (User and Entity Behavior Analytics): Эти инструменты поведенческой аналитики выявляют отклонения в поведении пользователей и устройств, указывающие на возможные угрозы. В русскоязычной литературе иногда используют аббревиатуру UBA, но безопасник не может быть нежным! UEBA позволяет обнаруживать подозрительную активность, которая может оставаться незамеченной традиционными методами, используя в том числе ИИ.
Настройте механизмы SOAR (Security Orchestration, Automation, and Response): Эти системы помогают определять, расставлять приоритеты и управлять стандартизированными действиями по реагированию на инциденты безопасности, автоматизируя процесс и уменьшая время реакции.
В модели Zero Trust каждое устройство, которое запрашивает доступ к вашей сети, становится потенциальной угрозой. Поэтому важно строго контролировать все устройства, обеспечивать их безопасность и проверять их статус перед предоставлением доступа.
Что делать:
Используйте систему MDM (Mobile Device Management, управление мобильными устройствами) и систему EMM (Enterprise Mobility Management, управление мобильностью предприятия) для контроля всех корпоративных устройств.
Если вы практикуете BYOD (Bring Your Own Device, просто работай со своего устройства — когда люди работают с личных ПК), то создайте регламент и политики с чёткими требованиями к безопасности устройств сотрудников. Неплохой вариант — отдельно изолировать такие устройства в отдельный сетевой сегмент с существенными ограничениями. Ибо дыр в безопасности там может быть гора и выше.
Настройте автоматическую проверку состояния безопасности устройства перед подключением к сети (например, проверка наличия последних обновлений и антивирусного ПО). Для этого используйте инструменты, которые реализуют подход NAC (Network Access Control, управление сетевым доступом), вроде Cisco Identity Services Engine и FortiNAC. Есть и Open Source варианты, например PacketFence.
А теперь о реальных практиках для внутренней защиты серверов и данных. Это лишь некоторые примеры, опытные безопасники могут рассказать больше:
1. Ловушки для мониторинга активности сотрудников
Суть: создайте ловушки, используя фальшивые файлы или директории с важными названиями, например,»finance_reports_2024.xlsx» или »passwords.txt» . Настройте оповещения, которые будут срабатывать при любом доступе к этим файлам.
Практика: используйте демон Auditd на Linux для отслеживания попыток доступа к этим файлам. Это позволит выявить подозрительную активность со стороны внутренних пользователей, включая привилегированных администраторов. Хорошо если это праздное любопытство, но может быть как злонамеренность, так и учётная запись, попавшая не в те руки.
2. Раздельные журналы для мониторинга действий с привилегиями
Суть: настройте отдельные журналы для записи действий, выполняемых с административными правами. Разделение журналов на общие и привилегированные позволяет сократить количество данных, подлежащих анализу, и фокусироваться на тех событиях, которые представляют наибольшую угрозу. Особенно полезно, если у вас сотни контроллеров доменов, а также десятки тысяч пользователей.
Практика: используйте syslog, rsyslog, journalctl или другие аналогичные инструменты для настройки раздельного хранения логов. Например, в Linux можно настроить отдельный файл журнала для действий, выполняемых через sudo, su или других команд, требующих повышения привилегий.
Для централизованного сбора и анализа логов используйте решения вроде ELK (Elasticsearch, Logstash, Kibana), Splunk или Graylog. Настройте оповещения и дашборды для мониторинга подозрительной активности, связанной с административными действиями.
3. Ограничение времени действия привилегий (Just-In-Time Access)
Суть: давайте пользователям временные привилегии только тогда, когда они действительно нужны, чтобы минимизировать время, в течение которого они могут потенциально злоупотреблять своими правами.
Практика: внедрите решения класса PAM (Privileged Access Management), вроде CyberArk, BeyondTrust или аналогичные системы управления привилегиями, которые позволяют выдавать временные права администратора или другие привилегии по мере необходимости и на ограниченное время. Да и даже в обычной Active Directory можно выдавать временное членство в группе. Настройте процессы, которые требуют обязательного одобрения от других администраторов или руководителей перед выдачей временных прав, чтобы добавить дополнительный уровень контроля. В худшем случае, введите за правило регулярно проводить аудит прав сотрудников, уже одно это может уменьшить риск успешной атаки.
Ремарка: рядом бродит JEA (Just Enough Administration) — это концепция, которая предоставляет минимально необходимые административные права для выполнения конкретных задач. Например, перезагрузить сервер — и всё. Этот подход снижает риски из-за избыточных привилегий. Поможет как от кривых рук, так и от злоумышленника, взломавшего аккаунт.
4. Ротация ключей доступа и паролей на регулярной основе
Как было раньше: часто меняйте пароли и ключи доступа, особенно для привилегированных аккаунтов и сторонних сервисов, чтобы снизить риск компрометации. Это важная практика для защиты чувствительных данных и систем, особенно в случае, если утечка информации была обнаружена не сразу. В идеале внедрить регламент, чтобы не забывать, а ещё лучше — менять автоматом.
Как это выглядит сейчас (пример): частая смена паролей для пользователей приводит к тому, что они выбирают простые и предсказуемые пароли, что снижает общую безопасность. Лучше создайте длинные, несловарные пароли (набор бессмысленных символов), которые отсутствуют в базах утечек, и обязательно используйте многофакторную аутентификацию (MFA). Регулярная ротация всё ещё актуальна для автоматизированных систем и сервисов, но вот с пользователями аккуратно — запоминать новый сложный пароль каждый месяц никто не станет. Неплохим вариантом будет и вовсе отказаться от паролей, например в пользу FIDO-токенов. Если это позволяет инфраструктура.
Практика: используйте автоматизированные системы управления паролями (например, HashiCorp Vault, CyberArk или AWS Secrets Manager), чтобы регулярно обновлять и распределять ключи доступа. Это снижает риск злоупотребления старыми или скомпрометированных данными.
Можете использовать сервис, вроде Have I Been Pwned, чтобы узнать, скомпрометирован ли ваш адрес и/или пароль, а также решения, вроде Lithnet Password Protection.
Всегда создавайте сложные пароли: минимальная длина — 12–16 символов, включая буквы, цифры и специальные символы, но без общих правил, чтобы не создать шаблон, который «прочтёт» хакер. Следует понимать, что пароль gjregfqntdcthdthvjkk более взломостоек, чем P@ssW0rd, а запоминается проще. Если вы понимаете о чём я :)
5. Использование «серых» зон безопасности (Greylisting)
Суть: примените концепцию «серых» зон для привилегированных пользователей, где их действия проходят дополнительные проверки и согласования. Например, глобальный апдейт CrowdStrike: D
Практика: настройте многофакторную аутентификацию (MFA) и дополнительные проверки (например, подтверждение со стороны коллег или руководителя) для выполнения критических операций, таких как удаление данных или изменение конфигураций.
6. Логирование и отслеживание команд, выполненных через терминал
Суть: записывайте все команды, вводимые в терминале, для последующего анализа и выявления подозрительных действий.
Практика: инструменты вроде Snoopy, auditd или tlog на Linux позволяют записывать и логировать команды, выполненные через терминал, с привязкой ко времени и пользователю. Крайне полезно при анализе действий администраторов.
7. Моделирование внутреннего нарушителя
Суть: периодически проводите внутренние тесты безопасности, моделируя действия злоумышленника, который имеет доступ к системам, чтобы проверить готовность инфраструктуры к внутренним угрозам.
Практика: создайте «красные команды» (Red Team) для проведения регулярных тестов на проникновение и выявления слабых мест в системах, моделируя действия потенциального внутреннего нарушителя. Используйте системы вроде OSSEC для моделирования атак изнутри, чтобы проверить готовность вашей системы к внутренним угрозам. Проводите учения и симуляции, включающие реальные сценарии атак, чтобы убедиться, что ваши процедуры реагирования на инциденты эффективны.
8. Изоляция и мониторинг привилегированных сессий
Суть: все сессии привилегированных пользователей должны быть изолированы и контролируемы в реальном времени.
Практика: используйте Duo Security, Centrify или другие из уже упомянутого класса решений PAM, вроде опенсорсных GoTeleport и JumpServer, для изоляции привилегированных сессий и регистрации всех действий в реальном времени. Настройте уведомления и автоматические меры реагирования (например, блокировку сессии), если выявлена подозрительная активность в ходе привилегированной сессии. Внедрите практики, требующие одобрения со стороны второго администратора или старшего сотрудника для выполнения определенных критических операций в реальном времени.
9. Контроль за использованием средств удаленного управления
Суть: ограничьте и контролируйте использование утилит удаленного управления, таких как SSH или RDP, чтобы предотвратить несанкционированные действия.
Практика: внедрите двухфакторную аутентификацию (2FA) для доступа к удаленным системам через SSH, RDP и другие протоколы (а лучше используйте их через PAM). Это добавляет дополнительный уровень безопасности. Ограничьте доступ по IP-адресам, чтобы только доверенные сети могли подключаться к удаленным системам. Используйте VPN или выделенные сети для управления доступом. Настройте автоматическое отключение сессий при длительном бездействии или обнаружении подозрительной активности.
10. Использование техники «разделяй и властвуй» для данных
Суть: разделяйте данные на мелкие, менее значимые части, чтобы усложнить злоумышленнику задачу получения полной информации.
Практика: применяйте шифрование данных на уровне файлов, баз данных и коммуникаций. Используйте различные ключи шифрования для разных частей данных, что усложняет задачу злоумышленнику, даже если он получит доступ к части информации.
Если систему нельзя взломать, то её просто выключили
Шутка смешная, а ситуация грустная. Если есть доступ к сети, то любое устройство уязвимо. Любая атакующая технологии рано или поздно побеждает защитную. Внешняя кибербезопасность — это не только о защите от попыток взлома, но и о построении такой архитектуры, которая минимизирует риски при неизбежных атаках.
10 полезных практик для улучшения внешней киберзащиты:
1. Использование хостов-приманок aka ханипотов (Honeypots)
Суть: установите в сети сервер-ловушку, который выглядит как реальный, но предназначен для отслеживания и анализа атак. Это помогает выявлять злоумышленников, изучать их методы и настраивать защиту для настоящих серверов.
Практика: используйте Open Source-решения, такие как Cowrie или Dionaea, чтобы развернуть ханипот, который будет привлекать атаки, регистрировать их и предупреждать администраторов.
2. Уведомления о ключевых событиях
Суть: хотя многие используют email для оповещений, критически важные события (например, неудачные попытки входа или изменение конфигурации) могут потребовать немедленного вмешательства.
Практика: настройте уведомления по SMS и\или через мессенджеры (например, Telegram) с помощью инструментов, таких как Zabbix или Nagios, чтобы не пропустить важные инциденты. Для особо критичных можно использовать даже звонки в качестве уведомлений.
3. Пусть хакер увязнет в медовых паролях
Суть: создание «медовых паролей» — намеренно слабых паролей для учётных записей, которые выглядят важными, но на самом деле не имеют доступа к критическим ресурсам. Не панацея, но пусть будет.
Практика: эти учётные записи можно отслеживать, и если они будут использованы, вы сразу узнаете о попытке взлома. Это можно сделать через логирование попыток авторизации и автоматическое оповещение при использовании таких учёток.
4. Использование «родных» утилит для анализа файловых систем
Суть: многим системным администраторам нравится пользоваться встроенными в операционные системы инструментами для управления и анализа файловых систем, такими как lsof (LiSt of Open Files).
Практика: с помощью утилиты lsof можно отслеживать, какие процессы используют определённые файлы или порты. Это удобно для обнаружения подозрительных активностей или попыток несанкционированного доступа к данным.
5. Принудительная настройка задержек на SSH-логины
Суть: замедление процесса аутентификации SSH для предотвращения брутфорс-атак (метод «грубой силы», полный перебор паролей).
Практика: используйте параметры MaxAuthTries и LoginGraceTime в конфигурации sshd_config для ограничения попыток входа и задержки между ними. Это усложнит работу злоумышленникам, пытающимся подобрать пароли полным перебором.
6. «Невидимая» настройка брандмауэра
Идея: создание правил в брандмауэре, которые позволяют соединяться только с «невидимыми» IP-адресами, известными только администратору.
Практика: используйте Linux-утилиты iptables или firewalld для настройки правил доступа, ограничивающих подключение только с определённых IP-адресов, не указанных в публичных документах или конфигурациях.
7. Автоматическое удаление учётных записей без активности
Суть: автоматическое удаление или блокировка учетных записей, которые не были использованы в течение определённого времени, чтобы уменьшить риск взлома через устаревшие или забытые учётные записи.
Практика: настройте скрипты, которые регулярно проверяют дату последнего входа и отключают или удаляют учётные записи, если они неактивны в течение определённого времени.
Вот пример PowerShell-скрипта, который отключает учетные записи пользователей, неактивные в течение последних 90 дней:
# Определяем количество дней неактивности $daysInactive = 90 # Определяем дату, до которой учетная запись считается активной $cutoffDate = (Get-Date).AddDays (-$daysInactive) # Получаем все учетные записи пользователей, которые не являются системными и не заблокированы $users = Get-ADUser -Filter * -Property LastLogonDate, Enabled | Where-Object { $_.Enabled -eq $true -and $_.LastLogonDate -lt $cutoffDate } # Отключаем учетные записи, которые неактивны foreach ($user in $users) { Disable-ADAccount -Identity $user.SamAccountName Write-Output «Account $($user.SamAccountName) has been disabled due to inactivity.» } |
На системах Linux можно использовать скрипты Bash для автоматического управления учетными записями. Скрипты могут проверять файл /var/log/lastlog или использовать команду lastlog, чтобы определить дату последнего входа пользователя и деактивировать учётные записи, неактивные в течение определенного времени.
#!/bin/bash # Определяем количество дней неактивности INACTIVE_DAYS=90 # Получаем текущую дату в секундах с начала эпохи Unix CURRENT_DATE=$(date +%s) # Проверяем учетные записи пользователей for user in $(lastlog -b $INACTIVE_DAYS | grep -v «Never» | tail -n +2 | awk '{print $1}'); do sudo usermod -L $user echo «Account $user has been locked due to inactivity.» done |
8. Использование self-healing систем
Ремарка: этот подход направлен на повышение доступности и устойчивости инфраструктуры, напрямую кибербезопасность не улучшает, но смягчает последствия после атак и других проблем.
Суть: внедрение автоматических механизмов восстановления сервисов и конфигураций в случае сбоев. На этом принципе построен Kubernetes, если нода отказала, поды просто переезжают на работающие узлы кластера. Под — это контейнер или группа контейнеров, которые работают вместе на одном сервере и разделяют некоторые ресурсы, такие как сеть и хранилище.
Практика: используйте инструменты, такие как Consul + оркестратор Nomad от HashiCorp, которые позволяют автоматически восстанавливать сбои или перезапускать сервисы при обнаружении неполадок, уменьшая время простоя и минимизируя ручное вмешательство.
9. Обфускация имен хостов и сервисов (символьная)
Суть: обфускация (от английского obfuscate — делать неочевидным, запутанным, сбивать с толку). Усложнение для злоумышленников понимания назначения сервера путём использования нетривиальных имён хостов и сервисов. Обфускация — это одна из возможных практик в рамках принципа Security through obscurity (иногда используется в ироничном ключе) — подхода, который основывается на скрытии ключевых деталей для защиты.
Практика: вместо того, чтобы давать серверам очевидные названия вроде webserver01, используйте случайные или тематические имена, чтобы усложнить их идентификацию при сканировании. Всякие Zephyr-XR2, Astral-Q5R, Delta-Sigma-42 и Krypton-5Z1. Главное следующему админу инструкцию не забудьте передать :)
10. Ловушки для сканеров портов
Суть: создаёте фальшивые порты и службы которые имитируют открытые порты и выглядят как настоящие. Эти службы не выполняют никакой реальной работы, но отвлекают и сбивают с толку хакеров.
Практика: Используя такие утилиты, как Portspoof, можно настроить систему так, чтобы при сканировании портов злоумышленник видел большое количество «открытых» портов и служб, которых на деле не существуют. Примерно как рисунок туннеля на бетонной стене. Так вы создадите ложное представление о структуре и уязвимостях вашей сети. Хакер, обнаружив ложные порты и службы, может убить много времени на исследование фальшивых целей. Как минимум это отвлечет его от реальных, потенциально уязвимых служб. А если хакер попытается взаимодействовать с ловушками, можно зафиксировать его действия и определить, что систему сканировали и что-то начинают делать. Тут главное совсем на скрипт-кидди и ботов не отвлекаться :)
Можно использовать Kippo (вдохновленный Kojoney)— это SSH-honeypot для захвата действий злоумышленников, которые пытаются получить несанкционированный доступ через SSH. Есть более современный Cowrie, который может взаимодействовать с атакующими для получения дополнительных сведений о методах их работы.
Учение свет, неучение — упавшие серверы
Не баян, а классика.
Обучение и повышения осведомленности сотрудников о киберугрозах и методах противодействия — то, что должно быть на постоянке.
Реальный случай: первые учения по фишингу — 50% попалось; через год (после обязательных курсов) —13%; ещё через полгода (когда объяснили что не надо по ссылке переходить, даже если очень хочется и любопытно «что там хакеры придумали») — 0%.
Вот как это можно интегрировать в рутину:
Регулярно проводить тренинги и семинары для сотрудников, чтобы повышать их квалификацию в вопросах кибербезопасности. Основы защиты информации, актуальные угрозы, распознавание фишинга и других социальных атак, а также методы противодействия. Для всех, включая бухгалтеров, и завхоза.
Объясните, что такое фишинг, вредоносное ПО (Malware) они же малвари, вымогательское ПО (Ransomware), DDoS-атаки, атаки через уязвимости нулевого дня (к важности обновлять ПО), социальная инженерия. Научите методам противодействия: антивирусы с актуальными базами, актуальное ПО в целом, базовая проверка личности собеседника, спам-фильтры, фильтрация трафика, определение фишинговых писем и ссылок и т.п. Здесь уже бухгалтера и эникея нужно разделять.
Регулярно проводите учения, моделирующие реальные кибератаки, фишинг или социальную инженерию, чтобы сотрудники могли отработать учёбу в боевых условиях.
Проводите разбор полётов и ошибок, определяйте слабые звенья. Старайтесь объективно оценивать результаты учений — не с первого раза всё получится, но если работать над этим, то будет результат.
Вкладывайтесь в сотрудников, однажды здоровая кибер-гигиена может спасти ваш бизнес.
Вместо выводов
Внедрение мер кибербезопасности, особенно нацеленных на внутренние угрозы, может превратить работу сотрудников в ад. Поэтому важно подходить к этим мерам с осторожностью, оценивая, не приведёт ли митигация одних рисков к созданию других, более значительных проблем.
Учитывая, как выглядит мир в 2024 году, вы обязаны работать над кибербезопасностью своей IT-инфраструктуры. То, что я затронул в статье — это лишь снег на верхушке айсберга. Тема чудовищно большая, но начинать с чего-то нужно.
Разумеется, если бюджет позволяет, а задача того требует, нужно работать над актуальностью ПО по концепции непрерывной интеграции (Continuous Integration, CI) и непрерывной поставки (Continuous Delivery, CD), разворачивать резервные серверы или целые ЦОДы, создавать геораспредлённые кластеры, интегрировать DevSecOps, развивать и реализовывать внутренние меры защиты (даже СКУД про это, политика чистого рабочего стола и мониторы, развёрнутые от прохода).
Скажу проще — область динамичная, требует постоянного обучения и повышения квалификации. Следите за новыми угрозами и адаптируйте свою стратегию защиты под текущие тренды.
