В нашей компании принято начинать с предварительного концептуального проектирования. Заказчик хочет максимальной защиты, чтобы избежать повторения инцидента, и этот максимум в реалиях ландшафта заказчика возможен. Далее начинается оценка работ, объем изменений, стоимость лицензий, и, как правило, концепция худеет раза в 2 по инициативам.
Теперь по вопросам: В качестве примера, как воспринимает ИБ риски. Если опубликовать веб-сервер без защиты на час, это низкий риск, поскольку время открытия является митигантом. Однако неделя открытой доступности – это уже недопустимо, и требуются дополнительные меры безопасности. В случае с почтой такие меры защиты как баннер, порты, обезличивание НДР и заголовков сессии с технической точки зрения не очень эффективны, но с точки зрения ИБ они снижают вероятность атак. Если удастся отбить хотя бы несколько примитивных попыток взлома, это уже оправдано. Со сканерами портов то же самое. Часто злоумышленники проверяют типовые порты сервисов, поэтому модификация может оказаться эффективным средством защиты. Например, порт 3389 быстро обнаружат, а 41781 может долго оставаться незамеченным. Однако, если мы говорим о целенаправленных атаках «квалифицированными специалистами», то эти меры не помогут. Потенциал у внешних DDoS-фильтров, таких как Qrator и CloudFlare, обычно выше. Они имеют большие вычислительные ресурсы, обрабатывают большое количество соединений и имеют более широкие каналы связи, чем внутренние шлюзы типа ASA. Про Start TLS: тут компромисс между безопасностью и совместимостью. Outlook.com использует Start TLS – это индустриальный стандарт. К сожалению, иногда приходится жертвовать уровнем защиты ради удобства пользователей. Шифрование БД зависит от уровня рисков, но в большинстве случаев оно излишне. Можно шифровать данные на уровне дисковой подсистемы средствами СХД или ОС, что защищает от физического доступа к серверам в дата-центрах. Шифрование на уровне приложения обеспечивает дополнительную защиту, даже если база данных «уйдет» . Однако реализовать такое шифрование сложно, и не всегда возможно сделать это штатными методами. Потоковое шифрование конечно требует значительных ресурсов и применяется лишь для критически важных данных, обычно можно выделить БД с чувствительными почтовыми ящиками под это. Если вы рассматриваете такие риски, значит, стоимость защищаемых активов высока, и у вас есть ресурсы для обеспечения этой защиты.
Сервер, принимающий почту из внешнего мира (порты 25\465\587), неизбежно будет «торчать». Даже при использовании KDP другого варианта нет, иначе это будет почтовый сервер закрытого периметра.
В случае с клиентским интерфейсом в ПЯ (порты 443\143\993\6005+ и т.д.) имеется доступ к данным ПЯ, адресной книге, календарям и прочим секретам. Эшелонированная защита, которая безусловно включает в себя VPN, пусть даже без 2FA, является хорошей мерой для снижения рисков.
По вашему вопросу: действительно, имеет смысл повесить на отдельные публичные адреса VPN и порт 25. Все запросы, которые не соответствуют фильтрам и требованиям коннектора, должны блокироваться.
Публикация интерфейсов для пользовательских подключений вовне – это всегда плохо, и нужно этого избегать по возможности. Лучше использовать туннелирование трафика, а еще лучше терминировать сессию мобильного или web-клиента на каком-нибудь HAproxy в DMZ сегменте. Идеально было бы использовать MDM решение с капсулой почтового клиента на мобильном устройстве, хотя это дороже)
А что касается SMTP – тут выбор зависит от того, кто ваши контрагенты. Если вы принимаете почту из всего интернета, то пути блэклистинга, даже автоматизированного, не так широки. Хорошая практика – установить антиспам и антивирус на вход и настроить через его интерфейс уровень фильтрации и доверия, паттерны проверки и т.д.
Всегда рад подискутировать :)
В нашей компании принято начинать с предварительного концептуального проектирования. Заказчик хочет максимальной защиты, чтобы избежать повторения инцидента, и этот максимум в реалиях ландшафта заказчика возможен. Далее начинается оценка работ, объем изменений, стоимость лицензий, и, как правило, концепция худеет раза в 2 по инициативам.
Теперь по вопросам:
В качестве примера, как воспринимает ИБ риски. Если опубликовать веб-сервер без защиты на час, это низкий риск, поскольку время открытия является митигантом. Однако неделя открытой доступности – это уже недопустимо, и требуются дополнительные меры безопасности.
В случае с почтой такие меры защиты как баннер, порты, обезличивание НДР и заголовков сессии с технической точки зрения не очень эффективны, но с точки зрения ИБ они снижают вероятность атак. Если удастся отбить хотя бы несколько примитивных попыток взлома, это уже оправдано.
Со сканерами портов то же самое. Часто злоумышленники проверяют типовые порты сервисов, поэтому модификация может оказаться эффективным средством защиты. Например, порт 3389 быстро обнаружат, а 41781 может долго оставаться незамеченным. Однако, если мы говорим о целенаправленных атаках «квалифицированными специалистами», то эти меры не помогут.
Потенциал у внешних DDoS-фильтров, таких как Qrator и CloudFlare, обычно выше. Они имеют большие вычислительные ресурсы, обрабатывают большое количество соединений и имеют более широкие каналы связи, чем внутренние шлюзы типа ASA.
Про Start TLS: тут компромисс между безопасностью и совместимостью. Outlook.com использует Start TLS – это индустриальный стандарт. К сожалению, иногда приходится жертвовать уровнем защиты ради удобства пользователей.
Шифрование БД зависит от уровня рисков, но в большинстве случаев оно излишне. Можно шифровать данные на уровне дисковой подсистемы средствами СХД или ОС, что защищает от физического доступа к серверам в дата-центрах. Шифрование на уровне приложения обеспечивает дополнительную защиту, даже если база данных «уйдет» . Однако реализовать такое шифрование сложно, и не всегда возможно сделать это штатными методами. Потоковое шифрование конечно требует значительных ресурсов и применяется лишь для критически важных данных, обычно можно выделить БД с чувствительными почтовыми ящиками под это. Если вы рассматриваете такие риски, значит, стоимость защищаемых активов высока, и у вас есть ресурсы для обеспечения этой защиты.
Попробую уточнить.
Сервер, принимающий почту из внешнего мира (порты 25\465\587), неизбежно будет «торчать». Даже при использовании KDP другого варианта нет, иначе это будет почтовый сервер закрытого периметра.
В случае с клиентским интерфейсом в ПЯ (порты 443\143\993\6005+ и т.д.) имеется доступ к данным ПЯ, адресной книге, календарям и прочим секретам. Эшелонированная защита, которая безусловно включает в себя VPN, пусть даже без 2FA, является хорошей мерой для снижения рисков.
По вашему вопросу: действительно, имеет смысл повесить на отдельные публичные адреса VPN и порт 25. Все запросы, которые не соответствуют фильтрам и требованиям коннектора, должны блокироваться.
Публикация интерфейсов для пользовательских подключений вовне – это всегда плохо, и нужно этого избегать по возможности. Лучше использовать туннелирование трафика, а еще лучше терминировать сессию мобильного или web-клиента на каком-нибудь HAproxy в DMZ сегменте. Идеально было бы использовать MDM решение с капсулой почтового клиента на мобильном устройстве, хотя это дороже)
А что касается SMTP – тут выбор зависит от того, кто ваши контрагенты. Если вы принимаете почту из всего интернета, то пути блэклистинга, даже автоматизированного, не так широки. Хорошая практика – установить антиспам и антивирус на вход и настроить через его интерфейс уровень фильтрации и доверия, паттерны проверки и т.д.