Раньше я думал, что ИБ — во многом история про деньги. Что по-настоящему серьезное внимание информационной безопасности уделяется в крупных организациях, которые могут позволить себе выделить на ИБ бюджет со множеством нулей, нанять дорогих специалистов, купить решения высокого класса, внедрить и администрировать их на экспертном уровне.

Размер бюджета на ИБ, вероятно, действительно напрямую влияет на защищенность компании. У больших компаний с дорогими департаментами ИБ дела с защитой действительно обстоят хорошо: больше персонала, выше квалификация, лучше решения (но это не точно). Однако этот факт никак не доказывает того, что в небольших организациях (условно 150–200 хостов) ситуация с защитой от кибератак должна быть обязательно плачевной. 

Парадокс в том, что даже при полном отсутствии средств на ИБ организация всё равно может — и должна — защищаться. Эта статья — не про идеальную безопасность, а про то, что приемлемую ИБ вполне можно построить с использованием бесплатных и встроенных средств. 

Введение

Да, информационная безопасность может восприниматься как набор дорогостоящих средств защиты: межсетевые экраны, антивирусы, SIEM, SOC, подписки, лицензии. Из-за этого создаётся ощущение, что без большого бюджета защищаться невозможно в принципе. 

На самом деле значительная часть базовых защитных мер не требует финансовых затрат. Сегментация сети, минимизация прав, жёсткие правила доступа, харденинг операционных систем, корректная настройка логирования и резервного копирования — всё это, в первую очередь, инженерные и организационные решения, а не закупочные. Для небольшой компании отсутствие бюджета на ИБ — это устойчивая реальность. В таких организациях нет выделенного ИБ-отдела, а функции защиты лежат на системных администраторах или инженерах. 

Это, безусловно, печально, особенно если сравнивать с крупными компаниями. В этой точке возникает опасная логика: «раз денег нет, значит, всё равно ничего не сделать». Эта статья исходит из противоположного предположения. ИБ — это архитектура и дисциплина — можно прямо так и написать на двери кабинета. 

С другой стороны, у малых и средних компаний и модели угроз совершенно другие: APT-группировки, реальная угроза злонамеренного инсайдера, 0-day-уязвимости — всё это существует, но для подавляющего большинства небольших организаций не является основной угрозой. Целевые атаки требуют ресурсов, времени и мотивации. Они применяются там, где есть значимая выгода: крупные корпорации, государственные структуры, КИИ. Для небольшой компании вероятность стать объектом именно такой атаки ниже, чем вероятность столкнуться с типовыми массовыми угрозами.

Это не означает, что угрозы, связанные с 0-day уязвимостями и сложными атаками, можно игнорировать. Такие сценарии потенциально актуальны для организаций любого масштаба. Однако при проектировании архитектуры информационной безопасности приоритет следует отдавать защите от наиболее вероятных и массовых сценариев атак, постепенно расширяя меры защиты в сторону менее вероятных, но более сложных угроз.

Набросок модели угроз

Что в первую очередь угрожает небольшой организации? Что-то куда более прозаичное, чем APT. Бот из интернета сумел проэксплуатировать уязвимость на сайте, что повлекло за собой дефейс. Сотрудник унес домой флешку с рабочими данными, чтобы поработать на выходных, а когда вернул — нечаянно занес вредоносное ПО. То есть это некие тривиальные ситуации и накладывающиеся на них ошибки: открытые порты, отсутствие сегментации, устаревшие версии CMS на сайте, слабая парольная политика, отсутствие обновлений ПО или невозможность восстановиться из резервных копий. Такие ошибки накапливаются постепенно и долгое время остаются незаметными. В какой-то момент возникает искра — и начинаются серьезные проблемы. 

Исходные данные и допущения

Предположим, что ИТ-инфраструктура компании состоит из 200 рабочих станций, в основном под управлением Windows 11, 20 серверов, преимущественно Linux, используется домен Active Directory, в нем, помимо двух контроллеров, еще CA, WSUS. Это усредненно типовая инфра в МСБ — какой-нибудь автоцентр, логистическая компания или модный сейчас учебный центр. В ней присутствуют базовые сервисы: почтовый сервер, веб-сервер, ряд файловых серверов. Есть как железные серверы, так и виртуализация на паре гипервизоров. Инфраструктура преимущественно новая — компания открылась недавно. Безусловно, это большой плюс как с точки зрения отсутствия легаси как программного обеспечения, так и архитектурных ошибок прошлого. Если в компании присутствует большое количество устаревших систем, не получающих обновлений, или изначально неудачно построена инфра, ситуация усложняется на порядок.

Тем не менее, будем считать, что нам относительно повезло. Да, бюджет на ИБ отсутствует или стремится к нулю, нет выделенного SOC, нет коммерческих NGFW, функции ИБ выполняет пара-тройка сисадминов/инженеров. И заранее известно, что так будет всегда. Тем не менее, инфраструктура новая, и при отсутствии бюджета мы всё же предполагаем возможность выделить несколько серверов или виртуальных машин под задачи безопасности, доступ к сетевому оборудованию и гипервизорам, время на настройку и поддержку. Важно зафиксировать: если нет даже этих ресурсов, говорить об ИБ в принципе бессмысленно. Но в подавляющем большинстве случаев они всё-таки есть.

Также по условиям задачи запрещено использовать клауд. Это был бы разумный шаг, где значительная часть риска была бы на стороне провайдера, и на западе всё чаще применяются такие модели. Однако у нас отсутствует доверие к облачным моделям развёртывания. Вероятно, бизнес сознательно выбирает on-premise инфраструктуру, считая её более контролируемой. Кроме того, для целей этой статьи on-prem инфраструктура удобнее. Все компоненты находятся под прямым контролем и нет никакой «магии провайдера», на которую можно спихнуть все проблемы.

Уровень безопасности, к которому мы стремимся

Мы не ставим целью:

• защиту от целевых APT-атак;

• соответствие строгим регуляторным требованиям;

• высочайшую операционную надёжность;

• абсолютную стойкость к любым инцидентам.

Цель — минимально достаточный уровень информационной безопасности, который:

• уменьшит поверхность атаки;

• ограничит распространение инцидента;

• позволит обнаружить проблему на ранней стадии;

• обеспечит восстановление после инцидента без катастрофических последствий.

Начало работы — планы и тикеты

Для обеспечения ИБ надо знать свою инфраструктуру. Это нужно, чтобы всегда понимать штатный порядок её работы и обнаруживать подозрительную активность на ранних этапах. Чтобы знать инфру, нужна документация. Её требуется составлять как для отдельных сервисов, так и для всей системы в целом. Кроме того, потребуется внедрение системы тикетов, чтобы отслеживать статус и состояние задач. Не столь важно, что именно использовать — главное, это просто должно быть. Например, можно использовать Redmine. Для непосредственного рисования схем – draw.io. 

Сетевая архитектура

Мне нравится идея о том, что сеть — это нервная система ИТ-инфраструктуры. В большинстве случаев инженер, устраиваясь на работу, работает с уже поднятой сетью. Качество исполнения этой сети может быть разным. Я слышал истории о «плоских» сетях на несколько сотен компьютеров. То есть все устройства находятся в одном L2–L3 сегменте: каждый компьютер может напрямую общаться с каждым, один VLAN, одна подсеть, фильтрации нет. Контроль трафика есть только на выходе в интернет. Это никуда не годится. Не учитывается угроза изнутри и возможность бокового перемещения, внутренняя сеть совершенно безосновательно считается доверенной. В этих условиях компрометация одного хоста грозит мгновенно перерасти в лавину. Плоская сеть — это враг, от которого надо избавиться любой ценой — либо на этапе первичного проектирования, либо меняя ландшафт уже потом, причем вручную.

Поэтому инфраструктуру надо разделить на зоны. Как пример, мы будем делить нашу инфраструктуру на следующие составляющие

1. Инфраструктура (Infra) — AD DC, DNS, CA, WSUS, DHCP. 

2. Пользовательская зона (Users) — основная пользовательская сеть.

3. Серверы компании (Prod) — серверы 1С, файловые серверы, документооборот, CRM и т.д.

4. Гостевой WiFi (Guest) — гостевой вайфай. 

5. Публичные ресурсы (DMZ) — веб-сервер, почтовый шлюз.

6. Безопасность (Security) — выделенная зона для сервисов безопасности.

7. Сетевая инфраструктура (Management) — для доступа к интерфейсам свичей. 

8. Транзитная сеть (Transit) — связь между ядром сети и фаерволом.

Для нашей организации удобно использовать подсеть класса B, к примеру 172.16.0.0/16. Для каждой зоны из этой подсети будет выделено своё адресное пространство и свой VLAN. VLAN ID = третий октет подсети (почти везде). Выглядеть это будет так: 

Рулить трафиком может как выделенная L3-железка уровня ядра, так и межсетевой экран на периметре. Предположим, что межсетевого экрана нет, и функции ядра сети выполняет L3-коммутатор. В этом случае схема сети будет выглядеть примерно так: 

DHCP-сервер, расположенный в зоне Infra, обслуживает зоны Guest и Users через DHCP-Relay, поднятый на Core. Во всех остальных зонах адреса статические. Взаимодействие между сетевыми зонами должно строиться по принципу минимально необходимых привилегий и быть ограничено на уровне L3-коммутации. Ниже приведены базовые правила сегментации и межзонного доступа, нарушение которых приводит к неконтролируемому распространению инцидентов внутри сети.

Это означает, что:

• не допускается существование универсальных правил вида «разрешить всё на все порты»;

• доступ предоставляется не по принципу «сеть → сеть», а строго «конкретный сервис → конкретный сервис»;

• каждое разрешающее правило должно быть осмысленным и иметь понятное назначение, а не добавляться временно «чтобы заработало».

Зона Guest изолируется от внутренних сегментов. Для неё не должно существовать никаких разрешающих правил в Users, Prod, Infra, Management, Security и т. п. Единственный допустимый сценарий — доступ в интернет через периметровый межсетевой экран.

Правила вида Users → Infra any-any недопустимы. Клиентским машинам нужно общаться с DC? Для этого надо разрешить только необходимый диапазон: DNS, Kerberos, LDAP/S, SMB, NTP, RPC.

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

В идеале, каждое правило должно быть задокументировано. На практике такое бывает нечасто, поэтому можно ограничиться правильным названием и/или комментарием, который дает представление о сути правила. Названия по типу Allow rule, test, Fix, Needed_for_work, Rule 41 — плохие. В случае, если правило временное, целесообразно пользоваться шедулерами. Без шедулера про «временность» правила забывают в 90 случаях из 100, и оно становится постоянным :) 

Сетевой периметр

Периметр важен, потому что он отделяет сеть организации от интернета, и позволяет считать внутреннюю сеть более-менее «своей». Периметровый межсетевой экран должен быть единственной точкой, через которую внутренняя инфраструктура контактирует с интернетом. Как строчка в бюджете межсетевой экран может попасть как в блок ИТ, так и в ИБ. Если не повезло, и денег не предвидится, можно взять сервер и накатить на него OPNsense, pfSense или ipfire. Все они реализуют полноценный stateful firewall: система отслеживает состояние соединений и понимает, что есть инициатор, а что ответ. 

Под это дело можно свистнуть железный сервак на нужды ИБ (по условиям мы можем так сделать), скачать с сайта ISO-образ OPNsense (как пример), загрузиться и проинсталлировать. По системным требованиям все достаточно лояльно, в рассматриваемом сценарии понадобится 3 сетевых интерфейса (WAN, LAN, DMZ), процессор с 4+ ядрами и 8+ Гб RAM. Модель OPNsense строится на бесплатном «Community Edition» с возможностью приобретения дополнительных коммерческих продуктов и услуг для тех, кому они нужны. Для использования на периметре в инфраструктуре описанного размера бесплатного Community Edition более чем достаточно. 

Снаружи через NAT должны быть доступны только опубликованные в интернет сервисы: веб-сайт, почта, VPN (если будет). Чтобы проводить инспекцию пакетов, в OPNsense есть IDS/IPS Suricata. 

Active Directory

Домен уже сам по себе даёт огромный набор защитных инструментов, особенно в сочетании со свежими версиями Windows. Многие вещи включены по умолчанию, например, SMB3 с подписью. Тема большая, не стоит даже пытаться описать здесь весь пул защитных мер, которые можно реализовать через AD. Если советовать что-то конкретное, на ум приходит: 

• У пользователей нет прав администратора. Руководствуйтесь принципом минимальных привилегий.

• У администраторов две доменные УЗ: обычная и привилегированная. Для ежедневных операций используется обычная УЗ, привилегированная используется только там, где нужна — при установке программ, просмотре журналов и так далее.

• Политики AD ограничивают попытки пользователей войти в систему (Политика блокировки учетных записей).

• Парольная политика требует от пользователей использование сложного пароля со сроком действия.

• Настроен LAPS, учетной записи локального администратора на каждом хосте присвоен уникальный случайно сгенерированный пароль.

• Настроена работа Windows Defender, в том числе исключения. 

И так далее. В качестве основного инструмента оценки параметров безопасности, задаваемых через AD, можно порекомендовать Microsoft Security Compliance Toolkit. Если за пределы Хабра выходить лень, по теме повышения защищенности AD в этом блоге уже выходило две (один, два) статьи. 

Защита на конечных точках

Как уже говорилось выше, раз денег нет, вопросы защиты надлежит закрывать в первую очередь харденингом и корректным управлением правами пользователей. 

Выше уже упоминалась важность отсутствия у пользователей прав локального админа. Это важно, потому что пользователь, работающий под учётной записью с минимальными привилегиями, не может изменить системные настройки или запустить вредоносный сценарий с повышенными правами. 90% пользовательских атак (фишинг, вредоносные вложения) рассчитывают на то, что код запустится в контексте текущего пользователя. Отсутствие административных прав существенно усложняет задачу атакующим. Также важно контролировать политику запуска PowerShell скриптов и кто имеет право входа по RDP.

Как чек-листы с настройками используем Security Baselines из Security Compliance Toolkit, а как средство антивирусной защиты — Windows Defender. В контексте рассматриваемой задачи он будет применяться как средство антивирусной защиты на всех эндпоинтах Windows, как рабочих станциях пользователей, так и серверах. Вроде бы он перестал быть «бесплатным позором» из эпохи Windows XP и вполне годится за отсутствием лучшего. Если управлять Defender через GPO и собирать его события в SIEM, то получается какая-то минимальная антивирусная платформа. 

В Microsoft Learn есть вот такая статья с описанием параметров настройки Defender. Судя по ней, в политике можно включить как минимум: 

• Real-time protection

  • Turn on behavior monitoring

  • Turn on real-time monitoring of processes

  • Turn on process scanning whenever real-time protection

• MAPS

  • Join Microsoft MAPS - Basic

• Security intelligence updates

  • Define the order of sources for Microsoft Defender Antivirus security intelligence updates - InternalDefinitionUpdateServer (для обновления через WSUS)

Логи Дефендер пишет в Event Log, журнал называется Microsoft-Windows — Защитник Windows/Operational. Оттуда можно забирать события в SIEM. Прямо вот супер реалтайма не получится, но в целом оперативное информирование о происходящем на конечных точках будет. 

Для Linux-серверов подход к защите конечных точек отличается от Windows. Здесь ключевое значение имеет корректная настройка механизмов аутентификации и управления доступом, в первую очередь — PAM (Pluggable Authentication Modules), а также харденинг и регулярный аудит конфигураций.

Через PAM на Linux-системах реализуются:

• контроль аутентификации;

• ограничение времени и условий входа;

• политики блокировки учётных записей;

• требования к сложности и сроку действия паролей.

Корректно настроенный PAM в сочетании с харденингом по рекомендациям CIS Benchmarks и периодическим аудитом системы (например, с использованием Lynis) позволяет существенно снизить риск компрометации сервера и ограничить последствия успешной атаки даже при утечке учётных данных.

Антивирусная защита на Linux-серверах носит вспомогательный характер и не может рассматриваться как основной механизм обеспечения безопасности. В качестве бесплатного средства антивирусной защиты может использоваться ClamAV. Даже с учетом блокировки обновлений получится неплохо — обновляться можно через VPN или поискать в интернете зеркала.

Надо помнить, что настройки следует тестировать перед внедрением и нельзя накатывать одни и те же параметры на системы с разным уровнем критичности. В зоне Infra и в зоне Users настройки на машинах будут различаться, поскольку цена компрометации рядовой рабочей станции и, к примеру, AD CS разные.

Публичные сервисы

В компании среднего размера будут как минимум два публичных сервиса — почта и сайт. Их необходимо размещать в ДМЗ, чтобы при компрометации сервера затруднить доступ во внутреннюю сеть. Это база, но этого решительно недостаточно, поэтому необходимо принять еще ряд защитных мер.

Почта — один из главных векторов атак для получения первичного доступа. Остановить атаку безопаснее всего здесь, пока злоумышленники не получили первоначальный доступ в инфраструктуру. Для этого необходимо:

1. Настроить сервер с нашим MTA (Mail Transfer Agent), который отвечает за прием писем из интернета. Если коротко: ClamAV для защиты от вредоносных вложений (отлично интегрируется с Exim и Postfix, к примеру). DNSBL для защиты от спама — почтовый сервер обращается к DNSBL и проверяет в нем наличие IP-адреса, с которого он принимает сообщение. Если адрес находится в этом списке, то сервер не принимает сообщение, фильтруя отправителей с плохой репутацией. Небольшая заметка при работе с DNSBL — таких списков много, и не стоит включать сразу все. Достаточно одного или двух. Одним из наиболее популярных является Барракуда.

2. Включить greylisting. Он искусственно замедляет незнакомых отправителей: при первой попытке доставки сервер отвечает «попробуй ещё раз». Легитимные почтовые системы повторяют отправку, а массовые спам-боты обычно нет. Для защиты фишинга от имени вашей компании и проблем с доставкой необходимо настроить SPF, DKIM и DMARC.

3. Fail2ban! Обязательно. Даже если почтовый шлюз хорошо настроен и отфильтровывает спам, он всё равно постоянно находится под атакой. Его как минимум будут брутфорсить и пытаться подбирать пароли, если только вы не сделаете доступ к почте для сотрудников только через VPN. Fail2ban читает логи сервисов (в нашем случае почты) и в случае подозрительной активности блокирует источник — помещает в jail на настроенное время. То есть — кто-то сто раз подряд пытается авторизоваться? Блок. Это снижает нагрузку на сервер, уменьшает вероятность подбора пароля и стоит ноль рублей — следовательно, это нам надо.

4. Также не стоит забывать о регулярных обновлениях ПО на почтовом сервере. Обновления важны везде, но особенно – на публичных ресурсах, где боты имеют возможность сканить и пытаться эксплуатировать уязвимости со стороны интернета. Обновления здесь лучше автоматизировать. У Linux есть штатные механизмы: unattended-upgrades в Debian/Ubuntu и dnf-automatic в RHEL-семействе.

Веб-сервер с сайтом. Сайт будет на какой-то CMS — Wordpress, Битрикс или что-то подобное. В любом случае, доступ к управляющему соединению (SSH сервера и доступ к /wp-admin) должен быть только с определённых адресов администраторов. Дисциплина обновлений здесь на первом месте — пакеты сервера (PHP и так далее), ядро и плагины CMS должны обновляться. У меня была статья про уязвимости в Wordpress, и основная проблема там заключается в «забивании» на обновления плагинов. В плагине находят уязвимость, мейнтейнер выкатывает исправление, но админ не обновляет его, и, поскольку сайт выставлен в интернет, рано или поздно уязвимость эксплуатируют. 

Темы и плагины из подозрительных источников не должны применяться. И вообще, лучше обходиться минимумом необходимых плагинов. 

Следующий уровень защиты — Web Application Firewall (WAF). Можно использовать либо WAF на веб-сервере (например, ModSecurity), либо плагины типа Wordfence.

Мониторинг, обнаружение и реагирование

Даже если SOC нет, надо обеспечивать себе представление о том, что происходит во вверенной инфраструктуре в конкретный момент времени. Сделать это можно с помощью SIEM/XDR Wazuh. Она:

• бесплатна;

• стабильна;

• нормально документирована;

• хорошо работает с Windows и Linux;

• дружит с Microsoft Defender;

• масштабируется под нашу размерность.

Потребуется всего один выделенный или виртуальный сервер и немного времени на раскатку агентов. Мы сможем «загнать» в SIEM логи со всех рабочих станций и серверов Windows, серверов Linux, файрвола OPNsense и сетевых устройств, поддерживающих syslog. Внутри нам доступна корреляция и маппинг событий по MITRE ATT&CK, контроль изменений файлов. В результате мы получаем видимость и централизованный контроль над инфраструктурой организации. 

Поскольку это опенсорс, в процессе будут встречаться шероховатости и недоделки. Но в целом — забесплатно лучшего желать нельзя. 

Управление паролями

С паролями в любых организациях есть две большие проблемы. 

Первая — пользователи хранят их где угодно: в блокнотах под клавиатурой, Excel-файлах на общем диске, на рабочем столе. Вторая — есть ряд сервисов, к которым не прикручена доменная авторизация, и пароли от них тоже надо где-то хранить. Нужен менеджер паролей.

С этим вполне может помочь KeePass. Вероятно, этот выбор давно уже стал стандартом для админов. Это не веб-сервис и не облако, а обычное офлайн-приложение. Есть база паролей, есть мастер-пароль или ключевой файл — без них никто не откроет хранилище. KeePass — это не «корпоративный сейф для всех», а именно инструмент личного или командного хранения паролей. То есть пользователь не лезет на какую-то веб-морду, не смотрит «общую базу компании» и, тем более, не видит чужие пароли. Он открывает свою базу *.kdbx, введя свой мастер-пароль, и в ней лежат его доступы — всё, точка.

В этой связи я бы попробовал сделать следующим образом. На конечных устройствах пользователей мы по дефолту устанавливаем KeePass, через почтовую рассылку рассказываем, что это такое. Дальше они уже сами задают мастер-пароль и записывают в хранилище то, что считают нужным.

У администраторов есть свой KeePass, где файл *.kdbx лежит на сетевой шаре и содержит админские аутентификационные данные для доступа в сервисы без доменной аутентификации. Доступ к этой шаре строго ограничен, сама она включена во все возможные бэкапы. 

Резервное копирование как последняя линия обороны

Многие механизмы, описанные выше, уменьшают вероятность инцидента, ограничивают его масштаб и повышают наблюдаемость. Но если организация попадает под успешную ransomware-атаку, единственный способ вернуться к нормальной работе — это валидные, проверенные, изолированные резервные копии. 

Сегментация сети, харденинг и антивирус не гарантируют 100% защиты от шифровальщиков. А вот грамотная стратегия бэкапов — гарантирует возможность выжить.

Как водится, ленточных библиотек не подвезли, надо придумать что-то бесплатное. Пока думаем, можно набросать список ресурсов, которые должны быть в бэкапах: админский KeePass, база 1С / CRM / документооборот, файловые серверы (документы, договоры, архивы), почта, конфигурации сетевого оборудования, AD (System state DC и данные CA). 

Логика резервного копирования для МСБ вполне может выглядеть так: есть основная копия, которая делается каждый день на отдельный сервер / NAS в локальной сети; и есть вторая копия, которая живет не в той же сети. Это может быть самый обыкновенный внешний жёсткий диск, который администратор подключает, запускает копирование, дожидается окончания — и отключает. Уносит в шкаф, кладёт в сейф, относит в другую комнату — это уже детали. Главное — он не должен быть постоянно онлайн. Подключили → скопировали → отключили — звучит по-стариковски, но я не смог придумать более надёжного и реалистичного варианта для небольших компаний.

Заключение

Многие компании озвучивают отсутствие бюджета на ИБ. Но, вероятно, значительная часть ИБы — это не про деньги, а про архитектуру и дисциплину. Сегментация сети вместо «плоской анархии», периметр, аккуратная Active Directory, базовый харденинг, защита публичных сервисов, видимость инфраструктуры через Wazuh и нормальная работа с паролями — всё это не требует миллионов. Неуязвимой такая организация не станет, но хорошая защищенность будет присутствовать. Более того, значительная часть описанных в статье мер — это нормальные инженерные вещи, которые в идеале должны внедрять вообще все организации, вне зависимости от количества денег. 

Есть другая проблема. Я никогда не видел организаций с действительно нулевым бюджетом на защитные решения. Я несколько раз видел pfsense/opnsense на периметре, много раз видел Wazuh, почти везде в каком-то виде есть KeePass, и все признают важность сетевой сегментации и в целом грамотного архитектурного подхода. Но я никогда не видел описанного в статье комбо «всё за ноль рублей». И я очень надеюсь, что такая компания — лишь плод моего воображения. Попытаться построить ИБ условно забесплатно можно, и шансы на успех будут велики. Но если компания не может выделить бюджет на какие-то отдельные базовые вещи, как она будет относиться к людям, которые это внедряют и админят? 

Будут ли специалисты по информационной безопасности получать достаточную поддержку и признание в организациях с формально нулевым бюджетом на защиту — вопрос открытый. Даже при использовании бесплатных решений работы по ИБ требуют значительных временных и квалификационных затрат. Работа с опенсорсными инструментами вообще не похожа на plug-and-play и предполагает сотни часов квалифицированного труда.

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

Именно поэтому описанный в статье подход не следует воспринимать как рекомендацию строить безопасность исключительно без бюджета. Он демонстрирует, что хороший уровень ИБ достижим без крупных затрат на лицензии и продукты, но при этом требует осознанного отношения со стороны бизнеса — в том числе к ресурсам, времени и людям, отвечающим за защиту инфраструктуры. В этом смысле материал может служить аргументом в пользу разумных инвестиций в базовую информационную безопасность, а не их полного отсутствия.

НЛО прилетело и оставило здесь промокод для читателей нашего блога:
— 15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.