Когда руководство компании экстренно требует перевести всех сотрудников на удаленный доступ, вопросы безопасности зачастую отходят на второй план. Как результат – злоумышленники получают отличное поле для деятельности.
Так что же нужно и что нельзя делать при организации безопасного удаленного доступа к корпоративным ресурсам? Подробно об этом расскажем под катом.
Безопасная публикация ресурсов
Публикуйте веб-ресурсы через Web Application Firewall (в простонародье – WAF). Для быстрого развертывания и базовой защиты достаточно будет использовать стандартные профили защиты по OWASP Top 10. В первое время придется много подкручивать гайки в части отлова false positive событий. Если прямо сейчас у вас нет WAF – не отчаивайтесь! Если у вас стоит на тестировании какая-то триальная версия WAF, попробуйте задействовать ее для решения этой задачи, либо установите open-source решение Nginx + ModSecurity.
Если воспользоваться WAF не удалось, то спешно (по возможности) переводите приклад на HTTPS, проверяйте все пароли (пользовательские, админские) для публикуемого приложения на соответствие установленной в компании парольной политике. Не забудьте проверить операционные системы и CMS на свежесть, а также присутствие всех необходимых патчей, словом – санитизируйте все участки будущего общедоступного сервиса. Разверните Kali Linux и воспользуйтесь встроенным набором утилит для сканирования уязвимостей, если времени на это нет – воспользуйтесь одним из публичных сканеров уязвимостей (Detectify, ImmuniWeb и др.).
Чего делать не надо? Не стоит выставлять на показ в Интернет ваш замечательный самописный приклад на HTTP, в котором могут быть тысячи уязвимостей. Не надо выставлять и доступ по SSH к серверу или сетевому оборудованию, если не хотите, чтобы на вас полился брутфорс, а также не нужно напрямую публиковать RDP до целевых станций (привет, esteemaudit). Если есть сомнения в конкретном приложении, до которого нужно обеспечить доступ, разместите его за VPN.
VPN
С публикацией ресурсов разобрались, перейдем к сервисам, доступ до которых опубликовать не удалось. Для этого нам понадобится организовать VPN.
Что следует учесть при организации VPN?
В первую очередь оцените, сможете ли вы быстро развернуть клиентское ПО VPN на рабочих местах, или лучше воспользоваться Clientless подходом. Есть ли у вас VPN-шлюз или межсетевой экран с возможностью организовать удаленный доступ?
Если, например, в вашей сети стоит межсетевой экран Fortinet или Check Point с любым бандлом (NGFW/NGTP/NGTX), поздравляю, поддержка функционала IPsec VPN идет «из коробки», и ничего дополнительного покупать и устанавливать вам не нужно. Останется только поставить клиенты на рабочие места и настроить межсетевой экран.
Если прямо сейчас у вас нет VPN-шлюза или межсетевого экрана, посмотрите в сторону open-source решений (OpenVPN, SoftEther VPN и т.п.), которые можно довольно быстро развернуть на любом сервере, благо, step-by-step гайдов в Интернете предостаточно.
Кроме того, желательно, чтобы ваш VPN-шлюз интегрировался с AD/RADIUS для централизованного управления учетными записями. Также не забудьте проверить парольную политику и настройте защиту от брутфорса.
Если вы решили идти по пути установки клиента удаленного доступа на рабочие места пользователей, нужно будет определиться, какой режим VPN использовать: Full Tunnel или Split Tunnel. Если доступ для отдельной группы пользователей предполагает работу с конфиденциальной или высококритичной информацией, то я бы порекомендовал использовать Full Tunnel режим. Таким образом весь трафик будет заруливаться в туннель, выход в Интернет для пользователей можно будет организовать через прокси, при желании трафик можно будет слушать еще и через DLP. В иных случаях можно ограничиться обычным Split Tunnel режимом, при котором трафик заруливается в туннель только до внутренних сетей компании.
После успешной аутентификации пользователей вам следует определиться с авторизацией: куда давать пользователям доступ, как и где это делать. Есть несколько вариантов.
- Прямой доступ. Пользователь получил IP-адрес из своего VPN-пула и может идти напрямую к необходимым ресурсам (читай – через межсетевой экран). Здесь следует отметить, что если у вас стоит простой L4 межсетевой экран, на котором уже были настроены политики доступа (и их много!), то быстро адаптировать их к новым пулам IP-адресов может не получиться. Даже если у вас стоит NGFW с политиками по пользователям или группам пользователей, лог-оны в AD не будут зафиксированы (если только у вас не стоит специальный клиент на каждом рабочем месте), и политики тоже не будут работать. В таком случае политики придется создавать непосредственно на VPN-шлюзе либо использовать RADIUS при аутентификации и интегрировать его с клиентом межсетевого экрана для трекинга лог-онов пользователей.
- Терминальный доступ. Если у вас есть NGFW с политиками по пользователям и терминальный сервер, то можно сделать так. При реализации терминального доступа (например, с помощью MS RDS) пользователь, получивший удаленный доступ, логинится на терминальный сервер. Поставьте на него специальный агент от производителя межсетевых экранов (например, FSSO TS). Этот агент будет сообщать межсетевому экрану IP-адрес залогинившегося пользователя, в результате чего написанные политики безопасности по пользователям или группам пользователей останутся без изменений, и не придется спешно менять политики на NGFW.
Рабочие места пользователей – защищены?
Перейдем к безопасности рабочих мест.
Оцените безопасность рабочих мест удаленных пользователей: вы даете им рабочие станции с установленным золотым образом со всеми необходимыми фичами безопасности (antivirus, host-based IPS/Sandbox и т.п.), или они сидят со своих домашних ноутбуков с неизвестно каким софтом? Если ответ на этот вопрос – домашние устройства, то лучше бы после предоставления удаленного доступа зарулить трафик на NGFW с IDS/IPS, а в идеале еще и на сетевую «песочницу».
Одним из хороших вариантов также будет публикация на VDI конкретного приложения для работы (браузера, почтового клиента и т.п.). Это позволит разрешить доступ только к конкретным используемым приложениям.
Если у вас в компании запрещено подключение съемных носителей, то в случае удаленного доступа об этом также не стоит забывать, ограничив такую возможность для свежевыданных корпоративных ноутбуков.
Как обычно, убедитесь, что отключены небезопасные протоколы и службы, нелишним будет включить шифрование диска (вдруг ваш пользователь пойдет поработать в коворкинг, и его корпоративный ноутбук украдут?), не забудьте отобрать права привилегированного доступа (если ноутбук корпоративный).
Аутентификация
Используйте централизованное управление учетными записями при удаленном доступе (AD/RADIUS), а также не забудьте продумать сценарии, при которых ваш Identity Store будет недоступен (например, создайте дополнительно локальные учетные записи).
Хорошей практикой будет использование клиентских сертификатов, самоподписные сертификаты можно выпустить и на Microsoft CA.
Предположим, что в связи с непредвиденными обстоятельствами у ваших удаленных пользователей все-таки увели учетные данные. Двухфакторная аутентификация поможет справиться и с этой напастью (OTP-пуши на мобильных устройствах, SMS). А вот двухфакторную аутентификацию через корпоративный email я бы не рекомендовал (зачастую для аутентификации при удаленном доступе используются такие же учетные записи, как и в электронной почте, и, стало быть, ваш второй фактор легко будет вытащить). Если нужно быстро организовать двухфакторную аутентификацию, можно посмотреть в сторону публичных сервисов – например, Google Authenticator.
Эксплуатация
Продумайте, как ваш ИТ-департамент будет эксплуатировать удаленные рабочие места и помогать пользователям в решении повседневных проблем. Явно потребуется удаленный доступ сотрудников техподдержки к удаленным рабочим местам пользователей.
Желательно, чтобы рабочие станции «разливались» из золотого образа, и вам не пришлось пытаться восстанавливать работоспособность домашних компьютеров сотрудников из-за того, что они поставили что-то не то, или, чего доброго, поймали какой-то ransomware. Лучше выдайте корпоративные ноутбуки с заранее известными мощностями и составом установленного ПО, чтобы не получить головную боль с домашними ПК сотрудников, ведь ими могут пользоваться дети, на них может дико тормозить система или может не быть необходимых средств защиты.
Нелишним будет напомнить пользователям перед переходом на удаленную работу существующие в компании политики безопасности: мало ли как захочется рядовому пользователю расслабиться в обеденный перерыв дома.
Чек-лист: проверьте, что вы ничего не забыли, чтобы сделать удаленный доступ безопасным
- Публикуйте необходимые веб-ресурсы безопасно и с умом (используйте WAF, проверьте пароли, проверьте свежесть ОС, CMS).
- Проведите сканирование на предмет уязвимостей (собственными сканерами уязвимостей или публичными сканерами).
- Предоставляйте доступ к внутренним ресурсам через VPN (не выставляйте наружу RDP/SSH или приложения, с которыми обмен данными внутри сети не защищен).
- Публикуйте конкретные приложения через VDI (Citrix, VMware).
- Настройте двухфакторную аутентификацию (OTP-пуши на мобильных устройствах, SMS).
- Не забудьте учесть существующие настроенные политики безопасности на межсетевых экранах (адаптируйте их под пользователей удаленного доступа либо воспользуйтесь преимуществами связки NGFW с ID FW политиками и терминальным сервером).
- Выдайте пользователям корпоративные ноутбуки для использования вместо домашних ПК (убедитесь, что все необходимые средства защиты установлены и обновлены, права у пользователей отобраны, парольная политика соблюдается, ОС актуальна и пропатчена).
Автор: Constantly
