Основы облачной безопасности для небольших компаний: что действительно важно

Что обычно ломается первым

У небольших команд проблемы редко начинаются с игнорирования чек-листа на 200 пунктов. Обычно всё ломается из-за нескольких базовых пробелов, которые месяцами остаются открытыми.

Первой проблемой чаще всего бывает identity. Команда делит один админский логин, потому что так быстрее, а потом никто уже не может понять, кто изменил правило firewall, удалил снимок базы или выключил MFA. Когда кто-то уходит, этот аккаунт нередко остаётся активным дольше, чем принято признавать. Маленькие упрощения превращаются в слепые зоны.

Следующая проблема — сетевой доступ. Для теста, демо или подрядчика открывают порт, а потом никто не закрывает его обратно. Через несколько недель уже никто не помнит, зачем он вообще доступен из интернета. Временные исключения превращаются в обычный риск.

Резервные копии ломаются тише. На дашборде всё выглядит нормально, и все думают, что восстановление сработает. Потом случается реальный инцидент, и команда узнаёт, что сохранила не те данные, не записала пароль или вообще ни разу не проверила восстановление.

С логами всё происходит похоже. Команды собирают много событий, но когда что-то идёт не так, никто быстро не может ответить на простой вопрос: кто вошёл, что изменилось и когда это случилось?

Поэтому основы и важны. Большую часть из них можно проверить за один день, и они обычно снижают риск сильнее, чем длинный документ с политиками.

Определите, что именно нужно защищать

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

Начните с простой инвентаризации. Таблицы в Excel достаточно. Запишите все места, где компания хранит данные, запускает код или оплачивает счета. Обычно это облачный аккаунт, почта, репозиторий кода, базы данных, хранилища файлов, платёжные системы, сервисы поддержки, домены и DNS.

Затем отметьте, что пострадает, если кто-то получит доступ, заблокирует вас или удалит это. Для большинства компаний первая группа очевидна: данные клиентов, исходный код, production-базы, платёжные реквизиты и основной billing-аккаунт. Если злоумышленник получит доступ хотя бы к одному из них, ущерб будет сразу. А вот забытый дизайн-инструмент без клиентских данных может подождать.

Назначьте у каждой системы одного понятного владельца. Используйте реального человека, а не «engineering» или общую почту. Этот человек следит за списком доступов, знает, кому звонить, если что-то сломается, и быстро отвечает на один практичный вопрос: что произойдёт, если эта система упадёт сегодня?

Именно так безопасность перестаёт быть абстрактной. Вы не пытаетесь создать идеальную модель рисков. Вы решаете, что заслуживает внимания в этом месяце.

Хороший первый список часто бывает коротким: рабочая почта компании, один облачный аккаунт, репозиторий кода, база данных клиентов, платёжный процессинг и система поддержки, где лежат сообщения клиентов. Этого достаточно, чтобы закрыть большую часть реальных рисков для многих небольших команд.

Оставьте низкоприоритетные системы на потом. Старые демо-среды, тестовые проекты с фейковыми данными и заброшенные инструменты можно пока поставить в конец списка. Сначала сосредоточьтесь на системах, через которые можно утечь клиентским данным, остановить выручку или лишить команду возможности выпускать продукт.

Начните с identity и доступа

Большинство облачных инцидентов начинается со входа в систему, а не с киношного взлома. Один украденный пароль, один забытый админский аккаунт или один старый API-токен могут дать человеку куда больше доступа, чем ему положено.

Сначала включите MFA на всех админских аккаунтах. То же самое сделайте для billing-аккаунтов. Если кто-то получит доступ к billing, он может изменить настройки оплаты, создать ресурсы или вообще заблокировать команду. Из маленькой ошибки это быстро превращается в очень длинные выходные.

Общие логины — ещё одна частая проблема. Если одним админским аккаунтом пользуются три человека, никто не знает, кто что поменял, и никто не удаляет доступ, когда кто-то уходит. Дайте каждому свой аккаунт. Удаляйте старых пользователей сразу, как только они перестают нуждаться в доступе.

Доступ должен соответствовать тому, чем человек занимается сейчас, а не тому, чем он, возможно, займётся потом. Разработчику может быть нужен один проект и логи только на чтение, но не billing и не секреты production. Подрядчику может быть нужен доступ на две недели, а не навсегда. Даже маленькие ограничения имеют значение.

Быстрая проверка обычно сразу находит самые большие проблемы:

• На всех админских и billing-логинах включён MFA.
• У каждого человека свой аккаунт.
• Бывшие сотрудники и подрядчики больше не имеют доступа.
• Сервисные аккаунты, API-ключи и токены всё ещё имеют реального владельца и понятную цель.

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

Не забудьте про коды восстановления. Команды часто включают MFA, а потом теряют доступ, когда меняют телефон. Храните коды восстановления в менеджере паролей или в другом ограниченном внутреннем хранилище. Убедитесь, что в экстренной ситуации к ним сможет получить доступ больше одного надёжного человека.

Если у вас есть время только на одну задачу на этой неделе, начните отсюда. Работа с identity обычно быстрее всего снижает реальный риск.

Уменьшите публичную сетевую экспозицию

Один из самых быстрых выигрышей в безопасности прост: выставляйте в интернет меньше сервисов. Небольшие команды часто оставляют старые порты открытыми, потому что во время настройки кому-то был нужен быстрый доступ, а потом никто не вернулся их закрыть. Через месяцы база данных, админ-панель или SSH-порт всё ещё видны извне.

Это важнее длинных документов с политиками. Если атакующий не может добраться до сервиса, он не сможет его брутфорсить, сканировать или использовать старую уязвимость.

Начните с обычной инвентаризации. Проверьте все публичные IP, load balancer и правила firewall. Затем посмотрите, какие порты отвечают из интернета. Обычно всплывают знакомые варианты: SSH на 22, remote desktop на 3389, порты баз данных, старые staging-приложения и панели, которые вообще-то были нужны только внутри.

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

Публичные приложения и приватные системы не должны жить в одной корзине. Ваш сайт или API могут принимать трафик из интернета. База данных, внутренние админские инструменты, CI-runner и панели мониторинга — обычно нет. Спрячьте их за VPN или проверкой доступа, которая блокирует соединение ещё до того, как оно дойдёт до сервиса.

Небольшая SaaS-команда может держать публичное приложение, Postgres-базу и админскую панель в одном cloud-аккаунте. Приложение должно быть доступно пользователям. База данных должна принимать трафик только от приложения. Панель должна оставаться за приватным доступом. Одна такая перемена сильно снижает риск.

Что проверять каждую неделю

• Публичные IP и домены, которые всё ещё существуют
• Входящие порты, открытые на каждом сервере или сервисе
• Изменения firewall за последние 7 дней
• Админские инструменты, которые всё ещё доступны напрямую из интернета
• Старые staging- или тестовые системы, у которых уже нет владельца

Еженедельная проверка кажется повторяющейся, но она работает. Облачные настройки меняются быстро. Появляются новые тестовые серверы, временные правила живут вечно, и одно поспешное исключение может перечеркнуть аккуратную работу.

Настройте резервные копии, которые можно восстановить

Резервная копия имеет смысл только тогда, когда её можно восстановить в плохой день. Небольшие команды часто месяцами платят за хранение бэкапов, а потом слишком поздно выясняют, что сохранили не те данные, забыли пароль или вообще не записали шаги восстановления.

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

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

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

Один ежемесячный тест восстановления лучше идеального плана, который вы ни разу не запускали. Каждый месяц выбирайте одну систему и восстанавливайте её в безопасную тестовую среду. Проверьте, что приложение действительно читает восстановленные данные, а не просто видит файлы.

Запишите, сколько на самом деле занимает восстановление. Отметьте время, которое ушло на поиск бэкапа, восстановление и проверку работы системы. Этот показатель важнее догадок. Либо вы успеваете восстановиться вовремя, либо нет.

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

Включите логи, которыми вы будете пользоваться

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

Соберите эти логи в одном месте, которое команда и так уже открывает. Это может быть cloud-дашборд, общий logging-инструмент или простая внутренняя страница, которая собирает нужные события вместе. Один экран лучше пяти вкладок. Если только один инженер знает, где лежат записи, процесс слабый.

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

Короткий список проверок работает лучше, чем огромный набор правил:

• повторяющиеся неудачные входы в один аккаунт
• новый админ или пользователь с повышенными правами
• изменения расписания или срока хранения бэкапов
• включение публичного доступа к хранилищу или сервисам
• отключение логирования в любой production-системе

Сохраняйте привычку простой. Выберите одно время в неделю, откройте дашборд, просмотрите уведомления и запишите всё странное. Для многих небольших компаний достаточно 15 минут.

Это помогает и тогда, когда что-то ломается. Если задание на резервное копирование перестаёт выполняться во вторник, а никто не замечает этого до пятницы, восстановление становится сложнее, а стресс быстро растёт. Небольшой команде не нужны сотни уведомлений. Ей нужен короткий список, одно место для просмотра и еженедельная проверка, которая не срывается даже в загруженный месяц.

План на 30 дней

Небольшая компания может добиться реального прогресса за четыре недели, если один человек отвечает за работу, а команда не размывает объём. Не тратьте месяц на длинный документ с политиками. Сначала исправьте очевидные риски.

Используйте первую неделю, чтобы перечислить все системы, куда люди входят или которыми управляют. Обычно это почта, облачный хостинг, файловое хранилище, репозитории кода, payroll и любые админские панели, связанные с production. Сразу включите MFA для каждого админского аккаунта. Если команда запускает приложения в AWS или использует self-hosted GitLab, добавьте и их.

Неделя 1: составьте простой список систем, назначьте владельца каждой из них и включите MFA для всех админов.

Неделя 2: удалите старые аккаунты, сократите админские права, которые никому не нужны, и закройте публичные порты, которым не место в интернете.

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

Неделя 4: включите логи для входов, изменений админов и задач резервного копирования. Добавьте несколько уведомлений и запланируйте короткую еженедельную проверку.

На второй неделе обычно всплывают самые грязные проблемы. У бывших подрядчиков всё ещё есть доступ. Тестовые серверы открыты всему миру. Общий root-аккаунт до сих пор используется, потому что так проще. Наведите порядок, пока список систем ещё свежий.

Третья неделя важна, потому что бэкапы имеют значение только если их можно восстановить. Возьмите одну базу данных или одну общую папку и восстановите её в безопасное место. Засеките время. Если восстановление занимает шесть часов, а команда ожидала тридцать минут, вы нашли реальный пробел.

К четвёртой неделе вам уже не нужны идеальные логи. Вам нужны полезные логи. Отслеживайте неудачные входы, новых админов, изменения firewall, удалённые резервные копии и необычные всплески ошибок. Потом поставьте в календарь 15-минутную проверку. Такой ритуал ловит больше проблем, чем огромный список контролей, к которому никто не притрагивается.

Простой пример из небольшой команды

У команды из пяти человек была обычная для молодой компании схема: одно приложение, одна база данных и один cloud-аккаунт. Они были заняты выпуском продукта, поэтому до безопасности доходили руки только тогда, когда что-то казалось срочным. Это нормально — и именно здесь базовые меры приносят больше всего пользы.

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

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

После этого занялись резервными копиями. Команда настроила ежедневные бэкапы базы данных и хранила их отдельно от рабочей системы. Потом они провели один тест восстановления в безопасной среде. Этот тест оказался важнее галочки в разделе backup, потому что доказал: данные можно использовать, а шаги восстановления понятны.

Последним изменением стало логирование, и они не стали усложнять. События входа и действия админов отправлялись на один дашборд вместо того, чтобы быть разбросанными по cloud-экранам и настройкам приложения. Каждую пятницу один человек тратил 15 минут на проверку неудачных входов, новых админских действий и странного времени доступа.

В этом примере нет ничего сложного. В этом и смысл. Небольшой команде не нужны недели бумажной работы, чтобы исправить очевидные пробелы.

Ошибки, которые только отнимают время

Небольшие компании теряют время, когда относятся к безопасности как к бумажному проекту. Первая неделя должна уйти на устранение реальных рисков, а не на написание 20-страничной политики, которую никто не читает. Если всё ещё существует один общий админский аккаунт или доступ есть у трёх бывших подрядчиков, документ ничего не изменит.

Ещё одна частая трата времени — купить security-инструмент до того, как за него кто-то отвечает. Дашборд может выглядеть успокаивающе, но очень быстро превращается в shelware. Если никто не смотрит уведомления, не обновляет правила и не закрывает найденные проблемы, инструмент становится просто ещё одним ежемесячным платежом и ещё одной открытой вкладкой в браузере.

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

Простой набор правил помогает:

• удаляйте бывших сотрудников и подрядчиков в день ухода
• перестаньте делиться админскими аккаунтами
• включите MFA для каждого админа
• держите число full admin как можно меньше

Резервные копии тоже обманывают. Команды видят зелёный статус и думают, что вопрос закрыт. Потом реальный сбой вскрывает разрыв: бэкап неполный, шаги восстановления отсутствуют или у нужных людей нет доступа, чтобы быстро всё вернуть.

Решение менее эффектное, чем многим хотелось бы. Проверьте восстановление. Запишите шаги. Убедитесь, что это может сделать больше одного человека.

Быстрая проверка и следующие шаги

Быстрая проверка реальности лучше ещё одной таблицы. Если вы сейчас не можете ответить на несколько базовых вопросов, в настройках всё ещё есть пробелы.

Можете ли вы назвать каждого человека с админским доступом, каждое место, где лежат бэкапы, и каждый публичный endpoint, который компания открывает в интернет? Если ответ «не совсем», начните с этого.

Задайте ещё один прямой вопрос: может ли один человек восстановить базу данных сегодня без догадок? У него должны быть письменные шаги, правильные права и достаточно контекста, чтобы закончить работу, не дожидаясь коллеги, который «обычно этим занимается». Если нет, процесс резервного копирования ещё не готов.

С уведомлениями нужна такая же честность. Если сбои бэкапов, странные входы или резкие всплески трафика происходят в рабочее время, попадёт ли уведомление реальному человеку и будет ли он знать, что делать дальше? Многие команды включают логирование, а потом забывают связать его с реальной реакцией.

Короткий чек-лист помогает:

• выгрузите список админов и удалите старые или ненужные аккаунты
• запишите все места хранения бэкапов, кто ими владеет и когда вы в последний раз проверяли восстановление
• проверьте публичные IP, открытые порты и старые демо-системы, которые всё ещё висят в сети
• отправьте одно тестовое уведомление и убедитесь, что его кто-то получил
• выберите один пробел и исправьте его на этой неделе

Именно последний шаг важнее всего. Небольшие команды теряют время, когда пытаются навести порядок сразу во всём. Одна закрытая дыра на этой неделе полезнее, чем длинный план, который так и остаётся в документе.

Если вам нужен второй взгляд, Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями как Fractional CTO и advisor. Короткая проверка доступа, открытости, резервных копий и логов может выявить слабые места, которые легко пропустить, когда команда занята выпуском продукта.