Проблема с конечным узлом
Проблема конечного узла возникает, когда отдельные компьютеры используются для конфиденциальной работы и/или временно становятся частью доверенной, хорошо управляемой сети/облака, а затем используются для более рискованных действий и/или присоединяются к ненадежным сетям. (Отдельные компьютеры на периферии сетей/облаков называются конечными узлами.) Конечные узлы часто не управляются в соответствии с высокими стандартами компьютерной безопасности доверенной сети . [1] Конечные узлы часто имеют слабое/устаревшее программное обеспечение, слабые инструменты безопасности, чрезмерные разрешения, неправильные настройки, сомнительный контент и приложения, а также скрытые эксплуатации. [2] Проблемой становится перекрестное заражение и несанкционированный выпуск данных из компьютерной системы.
В рамках обширной киберэкосистемы эти конечные узлы часто временно подключаются к одному или нескольким облакам/сетям, некоторые из которых заслуживают доверия, а другие нет. Несколько примеров: корпоративный настольный компьютер, просматривающий Интернет, корпоративный ноутбук, проверяющий веб-почту компании через открытую точку доступа Wi-Fi в кафе , персональный компьютер, используемый для удаленной работы днем и игр ночью, или приложение на смартфоне/планшете ( или любую из предыдущих комбинаций использования/устройства). Даже если они полностью обновлены и жестко заблокированы, эти узлы могут переносить вредоносное ПО из одной сети (например, поврежденную веб-страницу или зараженное сообщение электронной почты) в другую, конфиденциальную сеть. Аналогичным образом, конечные узлы могут удалять конфиденциальные данные (например, записи нажатий клавиш или снимки экрана ). Предполагая, что устройство полностью заслуживает доверия, конечный узел должен предоставить средства для правильной аутентификации пользователя. Другие узлы могут выдавать себя за доверенные компьютеры, что требует аутентификации устройства . Устройству и пользователю можно доверять, но в ненадежной среде (что определяется по показаниям внутренних датчиков). В совокупности эти риски называются проблемой конечного узла. Существует несколько способов решения проблемы, но все они требуют установления доверия к конечному узлу и передачи этого доверия в сеть/облако.
Самое слабое звено облака
[ редактировать ]Облачные вычисления можно охарактеризовать как обширный, казалось бы, бесконечный массив обработки и хранения данных, который можно арендовать со своего компьютера. Недавнее внимание СМИ [ когда? ] сосредоточил свое внимание на безопасности в облаке. [3] Многие считают, что реальный риск заключается не в хорошо контролируемом, круглосуточно управляемом и полностью резервированном облачном хосте, а в множестве сомнительных компьютеров, имеющих доступ к облаку. [4] [5] Многие такие облака сертифицированы FISMA , тогда как конечные узлы, подключающиеся к ним, редко настраиваются в соответствии с каким-либо стандартом. [ нужна ссылка ]
Постоянно растущий риск
[ редактировать ]С 2005 по 2009 год самые большие и растущие угрозы личным и корпоративным данным исходили от эксплойтов персональных компьютеров пользователей. Организованные киберпреступники сочли более выгодным использовать многочисленные слабые личные и рабочие компьютеры изнутри, чем атаковать через сильно укрепленный периметр. [6] Одним из распространенных примеров является кража доступа к счету онлайн-банкинга малого бизнеса. [7]
Решения
[ редактировать ]Чтобы устранить проблему с конечным узлом, разрешайте подключаться к вашей сети/облаку только прошедшим проверку подлинности пользователям на доверенных удаленных компьютерах в безопасных средах. Существует много способов добиться этого с помощью существующих технологий, каждый из которых имеет разные уровни доверия.
Многие компании выпускают типичные ноутбуки и разрешают удаленное подключение только к этим конкретным компьютерам. Например, Министерство обороны США разрешает своим удаленным компьютерам подключаться к своей сети только через VPN (без прямого просмотра Интернета) и использует двухфакторную аутентификацию . [8] Некоторые организации используют серверные инструменты для сканирования и/или проверки компьютера конечного узла. [ нужна ссылка ] узла , например взаимодействие с доверенным платформенным модулем (TPM) .
Гораздо более высокий уровень доверия можно получить, выпустив неизменяемый, защищенный от несанкционированного доступа клиент. [ постоянная мертвая ссылка ] без локального хранилища, что позволяет ему подключаться только после аутентификации устройства и пользователя, удаленно предоставлять ОС и программное обеспечение (через PXE или Etherboot ), а затем предоставлять только удаленный доступ к рабочему столу или через браузер к конфиденциальным данным.
Менее затратный подход — доверять любому оборудованию (корпоративному, государственному, личному или общедоступному), но предоставлять известное ядро и программное обеспечение и требовать строгой аутентификации пользователя. Например, Министерства обороны США по защите программного обеспечения. Инициатива [9] предлагает Lightweight Portable Security , LiveCD , который загружается только в ОЗУ, создавая чистый, непостоянный конечный узел при использовании программного обеспечения Common Access Card для аутентификации в сетях Министерства обороны.
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Тим Фишер (12 декабря 2018 г.). «Что такое узел в компьютерной сети: ваш компьютер и принтер являются сетевыми узлами» . Проверено 24 декабря 2018 г.
- ^ Наталья Хшановская (23 марта 2017 г.). «Зачем использовать Node.js: плюсы и минусы выбора Node.js для серверной разработки» . Проверено 24 декабря 2018 г.
- ^ «Насколько безопасны облачные вычисления?» .
- ^ «Архитектура сверху вниз» . Архивировано из оригинала 13 августа 2021 г. Проверено 7 января 2014 г.
- ^ «Пользователи VPN: слабое звено в сетевой безопасности?» . Архивировано из оригинала 11 мая 2009 г. Проверено 6 февраля 2010 г.
- ^ «Бизнес-аналитика и ресурсы» (PDF) .
- ^ «Кибертворы грабят большой процент малого бизнеса» . США сегодня . 9 марта 2010 г.
- ^ «Политика виртуальной частной сети (VPN) Форт-Силл» . Архивировано из оригинала 17 июня 2011 г. Проверено 6 февраля 2010 г.
- ^ Инициатива по защите программного обеспечения Министерства обороны США. Архивировано 13 мая 2010 г. на Wayback Machine.