(no subject)
Некоторые мысли по теме сетевой секьюрити:
Как всем известно, за последние годы большинство аппликаций, которыми пользуется обычный юзер, стали вебными, а из всех программ важнейшей для нас является браузер. Это положение вещей меняет также и привычные для системщиков подходы к безопасности сетей - и я хотел бы изложить свой взгляд, как именно. Если нижеизложенное тривиально - извините.
Вот, например,
VPN:
Когда-то идея виртуальной шифрованной сети поверх Интернета мне очень нравилась и пленяла воображение - теперь, заслышав про VPN, я скорее вздрагиваю. При всех своих достоинствах, недостатков у этой технологии очень много: один из главнейших в том, что она меняет топологию сети - прописывает новые интерфейсы, добавляет записи в routing table, меняет DNS-сервера, и так далее. Наложение сабнетов, например, становится частой проблемой - если мой комп сидит в локальной сетке со стандартным адресом типа 192.168.0.0/24, и я подключаюсь куда-то по випиэну, то есть очень хороший шанс, что на другом конце туннеля уже окажется такой сабнет, или же VPN-гейт попытается дать мне IP из этого диапазона. Причём один VPN - это ещё куда бы не шло, но нередка также ситуация, когда юзеру требуется одновременно работать с двумя и больше, а это уже превращает админскую жизнь в адский ад.
(Возможно, переход на IPv6 несколько облегчит эти траблы. Если у каждого хоста есть уникальный адрес, то отпадает необходимость присваивать новые IP концам туннеля, энкапсулировать VPN-адреса внутрь пакетов, и так далее - внутри туннеля можно использовать те же адреса, что и вне).
С точки зрения security проигрышей тоже, на мой взгляд, больше чем выигрышей. В самом деле: каждый туннель в сетку - это дыра, через которую лезут пакеты из других сетей, причём неизвестно каких. Давать юзеру VPN означает соединять свою сеть с чёрт знает кем. Прибавим к тому, что и комп, за которым юзер сидит, зачастую не его. Мы послали юзера работать из офиса компании-клиента, дали ему VPN, он подсоединился с компа заказчика - опаньки. Наша безопасность зависит от доброй воли чужой компании.
Наконец, логика безопасности велит сокращать пространство для атак, давая доступ лишь к необходимому - а использование VPN сплошь и рядом ведёт к противоположному. Живой пример. Мне нужен доступ к серверу Exchange некой конторы. Я иду к их айтишникам, они говорят: пожалуйста, вот тебе VPN. Я говорю: слушайте, а нельзя ли без - нет ли у вас RPC/HTTPS-прокси? Ещё чего, отвечают, что за ересь, щас мы будем наш драгоценный Exchange в Интернет выставлять. Иди подключайся по туннелю, и не греши.
Понятно? По их мысли, их сервер надёжно запрятан в глубинах сети, отгородившись от Интернета эшелоном файерволлов, доступ же к нему даётся лишь проверенным юзерам. По моей мысли, это идиотизм: мне-то нужен доступ к одному-единственному порту, меня же заставляют подключаться к огромному интранету с великим множеством открытых сервисов и портов. Безопасность интранета от этого не вырастает никак: attack surface растёт колоссально, если у меня на компе сидит вирус, ему только что дали где разгуляться. Безопасность моего компа тоже вовсе не улучшается от того, что окромя Интернета, ему приходится подключаться к ещё одной нехилых размеров сети, где чёрт знает что может бродить.
Гораздо умнее было бы опубликовать веб-аппликацию - в данном случае, OWA или RPC/HTTPS-proxy - в Интернет. Те же функции, которые сейчас реально выполняет VPN - аутентификацию и шифрование траффика - с ровно таким же успехом выполнял бы прокси по SSL.
Итак, это я к чему: поскольку все аппликации становятся вебными, то становится проще высунуть корпоративные сайты в Интернет, чем городить сложные туннели и топологии. В ближайшие годы VPN-ы будут увядать, а структура сетей становиться более “плоской”.
Firewalls:
Традиционные пакетные фильтры значение стремительно теряют. Если подавляющее количество траффика прёт через HTTP / HTTPS, то что тут особенно отфильтруешь? То есть они по прежнему будут, конечно же, но главная логика секьюрити будет сидеть не в них.
Кроме того, фильтрация доступа к сервисам, опубликованным в Интернете, по IP-адресам теряет всякое значение - адрес клиента может быть любым. Определяющим же становится не IP, а личность клиента - то есть основой для фильтров становится аутентификация.
Поэтому требуются экраны более высокого уровня, которые будут уметь:
• Прятать за собой большой набор веб-приложений, служа для них единой точкой доступа и аутентификации. Чем раньше юзера опознать - тем лучше, все неопознанные запросы дальше экрана просто не идут. Передавать же запросы придётся аппликациям очень разношёрстным, поэтому экрану надо быть не тупым reverse proxy, а уметь много специфичных гитик - AJP, скажем.
• Уметь передавать информацию об опознанном юзере аппликациям за ним - чтобы не было проблемы двойной аутентификации.
• Раскрывать HTTPS-траффик и анализировать его, отсекая нелегальные запросы. Что сложно, поскольку у каждого вебсервиса язык запросов свой.
Вот мне, например, сейчас очень бы пригодился такой фильтр, умеющий прятать за собой кучу сайтов на PHP и умеющий перед тем, как перекидывать к ним траффик, опознавать юзеров по сертификатам / oAuth / SAML / WS-Security. Кто-нибудь знает? :-)
Identity management:
Управление юзерскими credentials сейчас в 99% случаев вообще не из того места растёт. Как выглядит типичный сценарий? Айтишник создал юзеру аккаунт в своей системе и дал ему какие-то права. Потом он передаёт юзеру пароль или криптоключ. Потом юзер пользуется.
Что тут плохого?
• Ну во-первых, пароли и ключи надо передавать. Что само по себе скверно.
• Во-вторых, у айтишника остаётся копия.
• Ну и в третьих, безопасность этих паролей и ключей айтишника волнует, а вот юзера не очень.
Разумеется, на самом деле всё должно (и будет) работать наоборот. Функции аутентификации и авторизации должны быть самым жёстким образом разведены. Защита юзерской identity должна быть головной болью юзера. Права в системе должны быть головной болью системщика.
К счастью, именно в сфере веб-приложений за последние годы именно по этой части идёт значительный прогресс. Я имею в виду, конечно же, технологии так называемой federated identity: OpenID, oAuth, SAML, LiveID, ADFS, Facebook Connect и так далее.
Идея в двух словах: если у нас есть веб-платформа, ей не надо вести собственную базу юзеров с отдельными паролями или ключами - она может просто положиться на другой веб-сервис, что он опознает юзера как своего. Например, мы в ЖЖ, как известно, может оставлять комментарии под аккаунтом Гугла: в этом случае ЖЖ полагается на Гугл, что тот проверит credentials комментатора.
Поскольку сейчас практически у любого есть уже какая-то сетевая личность (в Google, Yahoo, LJ, LinkedIn, и т.д.), то необходимость заведовать аутентификацией юзера у системщиков компаний отпадёт. Юзеру нужен доступ к Sharepoint? Нет проблем, скажи нам свой адрес на gmail.com, или свой LiveID, или твиттер. Передавать секретные пароли или ключи необходимости нет.
Кроме того, государства также начнут обеспечивать гражданам подобный сервис - этакий электронный паспорт. Есть, скажем, Вася Пупкин. Ему надо пользоваться сайтом банка, или больничной кассы, или магазина, или министерства. Достаточно, чтобы он доказал свою личность ровно одному вебсервису (который держит, скажем, МВД), по паролю, криптоключу, хоть по сетчатке глаза - а все остальные сайты будут получать от этого вебсервиса удостоверение: сие есть гражданин Василий Пупкин, номер личности такой-то.
(Американцы, как самые продвинутые, уже начали копать в этом направлении - см. “National Strategy for Trusted Identities in Cyberspace”. Кстати, если тут вы напряглись на тему privacy, то вы правильно напряглись - такой аспект безусловно есть. Если куча сайтов пользуется тем же самым identity provider’ом, то у провайвера есть отменная возможность смотреть, куда человечек ходит.)
Соответственно, и компаниям своим работникам нет надобности аккаунты заводить - достаточно на такой сервис положиться. И вот тогда защита identity будет беспокоить в первую очередь юзера, а не админа. Потому как завязано на эту identity будет очень многое.
Вот пока в таком аксепте.
Как всем известно, за последние годы большинство аппликаций, которыми пользуется обычный юзер, стали вебными, а из всех программ важнейшей для нас является браузер. Это положение вещей меняет также и привычные для системщиков подходы к безопасности сетей - и я хотел бы изложить свой взгляд, как именно. Если нижеизложенное тривиально - извините.
Вот, например,
VPN:
Когда-то идея виртуальной шифрованной сети поверх Интернета мне очень нравилась и пленяла воображение - теперь, заслышав про VPN, я скорее вздрагиваю. При всех своих достоинствах, недостатков у этой технологии очень много: один из главнейших в том, что она меняет топологию сети - прописывает новые интерфейсы, добавляет записи в routing table, меняет DNS-сервера, и так далее. Наложение сабнетов, например, становится частой проблемой - если мой комп сидит в локальной сетке со стандартным адресом типа 192.168.0.0/24, и я подключаюсь куда-то по випиэну, то есть очень хороший шанс, что на другом конце туннеля уже окажется такой сабнет, или же VPN-гейт попытается дать мне IP из этого диапазона. Причём один VPN - это ещё куда бы не шло, но нередка также ситуация, когда юзеру требуется одновременно работать с двумя и больше, а это уже превращает админскую жизнь в адский ад.
(Возможно, переход на IPv6 несколько облегчит эти траблы. Если у каждого хоста есть уникальный адрес, то отпадает необходимость присваивать новые IP концам туннеля, энкапсулировать VPN-адреса внутрь пакетов, и так далее - внутри туннеля можно использовать те же адреса, что и вне).
С точки зрения security проигрышей тоже, на мой взгляд, больше чем выигрышей. В самом деле: каждый туннель в сетку - это дыра, через которую лезут пакеты из других сетей, причём неизвестно каких. Давать юзеру VPN означает соединять свою сеть с чёрт знает кем. Прибавим к тому, что и комп, за которым юзер сидит, зачастую не его. Мы послали юзера работать из офиса компании-клиента, дали ему VPN, он подсоединился с компа заказчика - опаньки. Наша безопасность зависит от доброй воли чужой компании.
Наконец, логика безопасности велит сокращать пространство для атак, давая доступ лишь к необходимому - а использование VPN сплошь и рядом ведёт к противоположному. Живой пример. Мне нужен доступ к серверу Exchange некой конторы. Я иду к их айтишникам, они говорят: пожалуйста, вот тебе VPN. Я говорю: слушайте, а нельзя ли без - нет ли у вас RPC/HTTPS-прокси? Ещё чего, отвечают, что за ересь, щас мы будем наш драгоценный Exchange в Интернет выставлять. Иди подключайся по туннелю, и не греши.
Понятно? По их мысли, их сервер надёжно запрятан в глубинах сети, отгородившись от Интернета эшелоном файерволлов, доступ же к нему даётся лишь проверенным юзерам. По моей мысли, это идиотизм: мне-то нужен доступ к одному-единственному порту, меня же заставляют подключаться к огромному интранету с великим множеством открытых сервисов и портов. Безопасность интранета от этого не вырастает никак: attack surface растёт колоссально, если у меня на компе сидит вирус, ему только что дали где разгуляться. Безопасность моего компа тоже вовсе не улучшается от того, что окромя Интернета, ему приходится подключаться к ещё одной нехилых размеров сети, где чёрт знает что может бродить.
Гораздо умнее было бы опубликовать веб-аппликацию - в данном случае, OWA или RPC/HTTPS-proxy - в Интернет. Те же функции, которые сейчас реально выполняет VPN - аутентификацию и шифрование траффика - с ровно таким же успехом выполнял бы прокси по SSL.
Итак, это я к чему: поскольку все аппликации становятся вебными, то становится проще высунуть корпоративные сайты в Интернет, чем городить сложные туннели и топологии. В ближайшие годы VPN-ы будут увядать, а структура сетей становиться более “плоской”.
Firewalls:
Традиционные пакетные фильтры значение стремительно теряют. Если подавляющее количество траффика прёт через HTTP / HTTPS, то что тут особенно отфильтруешь? То есть они по прежнему будут, конечно же, но главная логика секьюрити будет сидеть не в них.
Кроме того, фильтрация доступа к сервисам, опубликованным в Интернете, по IP-адресам теряет всякое значение - адрес клиента может быть любым. Определяющим же становится не IP, а личность клиента - то есть основой для фильтров становится аутентификация.
Поэтому требуются экраны более высокого уровня, которые будут уметь:
• Прятать за собой большой набор веб-приложений, служа для них единой точкой доступа и аутентификации. Чем раньше юзера опознать - тем лучше, все неопознанные запросы дальше экрана просто не идут. Передавать же запросы придётся аппликациям очень разношёрстным, поэтому экрану надо быть не тупым reverse proxy, а уметь много специфичных гитик - AJP, скажем.
• Уметь передавать информацию об опознанном юзере аппликациям за ним - чтобы не было проблемы двойной аутентификации.
• Раскрывать HTTPS-траффик и анализировать его, отсекая нелегальные запросы. Что сложно, поскольку у каждого вебсервиса язык запросов свой.
Вот мне, например, сейчас очень бы пригодился такой фильтр, умеющий прятать за собой кучу сайтов на PHP и умеющий перед тем, как перекидывать к ним траффик, опознавать юзеров по сертификатам / oAuth / SAML / WS-Security. Кто-нибудь знает? :-)
Identity management:
Управление юзерскими credentials сейчас в 99% случаев вообще не из того места растёт. Как выглядит типичный сценарий? Айтишник создал юзеру аккаунт в своей системе и дал ему какие-то права. Потом он передаёт юзеру пароль или криптоключ. Потом юзер пользуется.
Что тут плохого?
• Ну во-первых, пароли и ключи надо передавать. Что само по себе скверно.
• Во-вторых, у айтишника остаётся копия.
• Ну и в третьих, безопасность этих паролей и ключей айтишника волнует, а вот юзера не очень.
Разумеется, на самом деле всё должно (и будет) работать наоборот. Функции аутентификации и авторизации должны быть самым жёстким образом разведены. Защита юзерской identity должна быть головной болью юзера. Права в системе должны быть головной болью системщика.
К счастью, именно в сфере веб-приложений за последние годы именно по этой части идёт значительный прогресс. Я имею в виду, конечно же, технологии так называемой federated identity: OpenID, oAuth, SAML, LiveID, ADFS, Facebook Connect и так далее.
Идея в двух словах: если у нас есть веб-платформа, ей не надо вести собственную базу юзеров с отдельными паролями или ключами - она может просто положиться на другой веб-сервис, что он опознает юзера как своего. Например, мы в ЖЖ, как известно, может оставлять комментарии под аккаунтом Гугла: в этом случае ЖЖ полагается на Гугл, что тот проверит credentials комментатора.
Поскольку сейчас практически у любого есть уже какая-то сетевая личность (в Google, Yahoo, LJ, LinkedIn, и т.д.), то необходимость заведовать аутентификацией юзера у системщиков компаний отпадёт. Юзеру нужен доступ к Sharepoint? Нет проблем, скажи нам свой адрес на gmail.com, или свой LiveID, или твиттер. Передавать секретные пароли или ключи необходимости нет.
Кроме того, государства также начнут обеспечивать гражданам подобный сервис - этакий электронный паспорт. Есть, скажем, Вася Пупкин. Ему надо пользоваться сайтом банка, или больничной кассы, или магазина, или министерства. Достаточно, чтобы он доказал свою личность ровно одному вебсервису (который держит, скажем, МВД), по паролю, криптоключу, хоть по сетчатке глаза - а все остальные сайты будут получать от этого вебсервиса удостоверение: сие есть гражданин Василий Пупкин, номер личности такой-то.
(Американцы, как самые продвинутые, уже начали копать в этом направлении - см. “National Strategy for Trusted Identities in Cyberspace”. Кстати, если тут вы напряглись на тему privacy, то вы правильно напряглись - такой аспект безусловно есть. Если куча сайтов пользуется тем же самым identity provider’ом, то у провайвера есть отменная возможность смотреть, куда человечек ходит.)
Соответственно, и компаниям своим работникам нет надобности аккаунты заводить - достаточно на такой сервис положиться. И вот тогда защита identity будет беспокоить в первую очередь юзера, а не админа. Потому как завязано на эту identity будет очень многое.
Вот пока в таком аксепте.