Полностью переехали в облако: с чего начать аудит безопасности облачной инфраструктуры?

Первым делом проверьте права на облачные хранилища (бакеты). У многих провайдеров они закрыты по дефолту, но при миграции для удобства часто открывают публичный доступ на чтение. Заодно гляньте порты управления виртуалок (особенно SSH и RDP) — они не должны торчать во внешний интернет, ограничьте их строго статическим IP вашего офиса.

У нас финансово-брокерская компания примерно такого же масштаба. В прошлом году пришел аналогичный опросник от контрагента, и мы наняли независимого безопасника. Четырехдневный аудит конфигураций обошелся в 2 200 GBP. Нашли 8 критических уязвимостей, из которых шесть оказались просто криво настроенными правами пользователей. Если наведете базовый порядок сами до прихода аудиторов, ценник выйдет заметно ниже.

скажите своему админу пусть прямо щас накатит на все админки обязательный вход по u2f-ключам или через приложение-аутентификатор. смски уже прошлый век и нигде не котируются. ну в клиентских аудитах mfa вообще первое на что смотрят.

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

Вот что нужно закрыть в первый же день внутреннего аудита: 1) Включить обязательную двухфакторную аутентификацию для всех учеток сотрудников. 2) Отозвать старые неиспользуемые API-ключи и сервисные аккаунты, созданные во время миграции. 3) Открыть встроенную панель оповещений безопасности у вашего облачного провайдера и по очереди устранить риски с высоким приоритетом. 4) Убедиться, что бэкапы хранятся изолированно в другом регионе.

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

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

Самое быстрое, что вы можете сделать завтра с утра — это зайти во встроенный центр безопасности и комплаенса в панели вашего облака. Провайдеры обычно бесплатно дают оценку безопасности (security score) и список недочетов. Даже если вы просто закроете там красные алерты и наделаете скриншотов, этого уже хватит чтобы показать клиенту что работа пошла.

Буду рад, если напишете о результате. При принятии решений записывайте и худший сценарий, а не только лучший.

На этом всё, извините, если затянул.

Позвольте подвести итог сказанному выше. Чем сложнее отменить решение, тем медленнее его принимайте.

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

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

Если не зафиксировать это письменно с самого начала потом возникнут споры. Конечно, если ваша ситуация отличается всё меняется.

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

Мне тоже интересно. Первые три месяца все идет хорошо проблемы всплывают на четвертом.

Это мое мнение не утверждаю что оно единственно верное.

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

Проверено опытом.

На это стоит обратить внимание. Если делаете впервые, начните с малого, масштабирование потом.

Пишите, если есть вопросы, отвечу по мере возможности.

Здесь есть ловушка, не могу промолчать. Главное не цифра, а то, на основе чего она получена.

Удачи.

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

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

А как вы решили этот вопрос? честно прежде чем принимать решение, посмотрите какие данные у вас есть.

Я бы пошел этим путем.