Новые предложения для шифрования и обеспечения безопасности личной информации
в социальных сетях могут помочь защитить пользователей, но они также являются
головной болью для ИТ и менеджеров по безопасности.
На прошлой неделе Twitter присоединился к Facebook и другим социальным сетям
в использовании по умолчанию HTTPS-протокола, чтобы помочь обеспечить
неприкосновенность частной жизни пользователей сайта. Многие считают, что нужно
благодарить автора
FireSheep
во включении поддержки HTTPS в список приоритетов социальными сетями.
С новыми настройками HTTPS, миллионы людей теперь могут защитить свои личные
- и не очень - публикации от любопытных глаз в самолетах, в кафе или в
каких-либо иных местах, где они могут заходить на свои любимые сайты социальных
сетей. Сообщество безопасности одобрило
действия Facebook по
совершению важного шага в защите сессий и информации пользователей.
ИТ-организации, с другой стороны, не настолько уверены в новых мерах
безопасности. Их первый вопрос: как контролировать входящую и исходящую
информацию корпорации, если весь механизм передачи данных зашифрован?
Опасности социальных сетей исследовались и освещались много раз.
Действительная ситуация заключается в том, что любой способ перемещения
информации из организации в социальную сеть - будь то посредством физической
среды, либо личного сообщения, является потенциальной возможностью для утечки
информации. Когда эти "возможности" становятся зашифрованными, сотрудники,
отвечающие за безопасность, теряют возможность контролировать данные сессии и
понимать, что же происходит "за дверью". По существу, повышенная безопасность
клиентов на данных веб-сайтах снижает возможности предприятия защитить
корпоративную информацию.
Итак, что же делать одинокой фирме, если она хочет защитить корпоративную
информацию, но HTTPS-сессии препятствуют ее видимости? Время применить некоторые
программы, обеспечивающие видимость.
Если в организации имеется модный коммерческий продукт,
предотвращающий утечку
информации (DLP), тогда проверьте его способность обеспечивать защиту
конечных точек или интеграцию с веб-прокси. Некоторые DLP продукты дают
возможность перехватывать все вызовы браузера в конечной точке и изучать каждую
транзакцию. Любая операция будет регулироваться в соответствии с набором правил
DLP. К сожалению, все, что хранится в конечной точке, может быть подделано
конечным пользователем, злоумышленником или вредоносной программой.
Интеграция с веб-прокси обеспечивает менее навязчивую альтернативу и не
полагается на конечную машину, но здесь могут возникнуть проблемы с
совместимостью и охватом. Если конечная точка находится за пределами
организации, тогда она может не охватываться прокси до тех пор, пока организация
не подключит весь удаленный трафик через систему.
Если твоя организация не имеет коммерческого DLP решения, которое может
исследовать HTTPS трафик, или какого-то иного способа, все равно
существует дополнительная
возможность. Применение открытого прокси, такого как Squid, может обеспечить
изучение HTTPS трафика – даже если ты не блокируешь запросы в стандартной
системе фильтров.
Squid является популярным открытым прокси. Он может быть использован как
обратный прокси для входящих соединений или в более традиционной конфигурации
для проксирования исходящих соединений. Реализация варьирует в зависимости от
сетевой среды, но Squid может находиться в сетевом потоке в целях контроля всего
трафика и его захвата через ICAP, или же может быть использован как сетевой
анализатор. Не имеет значения, каким образом он реализован, прокси может быть
использована для контроля HTTPS-трафика при помощи sslbump.
Использовать sslbump внутри Squid довольно просто, для этого необходимо лишь
несколько опций в конфигурации. Для начала http_port должен быть сконфигурирован
для использования sslBump, как в следующем примере:
http_port 3128 sslBump cert=/usr/local/squid3/etc/CA-priv+pub.pem
Затем, так как Squid требует обратного прокси, мы должны активировать
директиву always_direct.
always_direct allow all
Так как существуют некоторые запросы, которые мы не хотим декодировать при
помощи Squid-а – когда пользователи, например, заходят в свои банковские
аккаунты, совершают коммерческие операции, заходят на сайты с важной информацией
или на те, что не обрабатываются sslbump надлежащим образом – мы можем
использовать команды ssl_bump и acl в целях предотвращения распространения
подобного процесса на другие сайты.
acl broken_sites dstdomain .example.com ssl_bump deny broken_sites
ssl_bump allow all
В самом простом виде эти команды помогают системе создать список broken_sites,
который не обрабатывается надлежащим образом sslbump. Если сайт не входит в
список broken_sites, тогда система разрешит обработку ssl_bump.
Теперь у тебя должен быть полностью готовый к использованию Squid, который
сможет обрабатывать HTTPS-запросы. Используй открытые плагины - такие как
SquidGuard и ClamAV - для контроля трафика.
HTTPS представляет огромный шаг вперед для пользователей веб-сайтов, а также
их безопасности, но это также может быть огромной проблемой для команд,
отвечающих за безопасность, предпринимающих попытки по предотвращению утечки
информации через социальные сети. Существует множество путей для решения этой
проблемы. Оцени инфраструктуру, определи потребности и выбери то, что в
наибольшее степени подходит твоей сети.
