Конфиденциальность в протоколе SIP

В протоколе установления сеанса SIP, под конфиденциальными данными следует понимать идентификационные данные пользователя (и связанные с ним персональные данные), циркулирующие в сообщениях установления сеанса связи с одной или более сторон.

В SIP, идентичность пользователя наиболее широко раскрывается в форме SIP URI и имени пользователя, которое носит опциональный характер. SIP AOR (adress-of-record) визуально представляет собой типичный адрес e-mail, лексически-обогащенный синтаксисом протокола. Например, это может выглядеть следующим образом: «` sip:[email protected]«`. В качестве дополнения с этими данными может передаваться имя, идентифицирующее данного пользователя. Например: «`B. Oleg Vladimirovich«`. Как правило, данные этого рода  передаются в заголовках сообщения To и From. К слову, подобных этой, учетных записей(identites) пользователь может иметь несколько, используя их в тех или иных рабочих контекстах.

Так же существуют и иные места в сообщениях SIP, в которых персональные данные пользователя могут быть расскрыты. Например, в заголове Contact присутствует SIP URI, который зачастую идентичен упомянутому ранее address-of-record заголовка From. В некоторых заголовках, пользовательский агент может скрывать индентификационные данные пользователя, на основании тех или иных политик безопасности, без какого-либо ущерба в прохождении сигнализации протокола и связанных с ней операций обработки сообщений. Так или иначе, ключевые базовые заголовки диалога используются в последующей маршрутизации сообщений и поэтому должны быть заполнены служебными данными.

Прокси-сервера и различные посредники на уровне сети усложняют вопрос конфиденциальности тем, что самостоятельно внося дополнительные заголовки, как, например, Record-Route или заголовок Via, ненароком способствуют раскрытию информации об инициаторе того или иного sip-сообщения. Например, заголовок Via может раскрыть провайдера связи, услугами которого пользователь отправил свой запрос, что в свою очередь может сильно намекнуть на личность пользователя некоторым получателям. Поэтому, различные посредники, прокси-сервера и т.д. занимают не менее ключевую роль в данном вопросе.

В дизайне протокола заложены два существенных принципа, напрямую относящихся к конфиденциальности, это:
1) Во время создания сообщений запроса, пользователи уполномочены скрывать свою личность и сопутствующую персональную информацию.
2) Но посредники сети и логические получатели данных запросов уполномочены отказывать в обработке сообщений, создатели которых не смогли быть опознаны.

Виды конфиденциальности

В SIP пользователь может иметь несколько идентичностей, используя их в различных контекстах. В основном, под идентичностью понимают adress-of-record, который привязан к конкретному регистратору (управляемому администратором домена), с помощью которого user-agent sip-пользователя получает регистрацию. Оператором такого домена может выступить работодатель, или оператор связи, или сам пользователь.
После того как пользователь добровольно раскрывает свои идентификационные данные (идентичность) в сообщении запроса, они начинают транслировать готовность получать и обрабатывать запросы в направлении данной идентичности данного домена. Строго говоря, эти данные несут с собой ограничение в отношении пользователя и связанных с ним персональных данных, от любых далее потенциально-возможных получателей сообщений ответа.

В частности, существуют сценарии, в которых сторона желая анонимности может:
• отправить сообщение и отбросить идентификационные данные оконечного устройства или устройств, продолжая диалог с одним или более сетевых посредников (в духе анонимайзера).
• отправить сообщение скрыв свои идентификационные данные от какого-либо или всех дальнейших посредников сети, вместе с тем продолжая end-to-end диалог с оконечным устройством или группой устройств.
• отбросить идентификационные данные и от оконечных устройств и от посредников.

Результатом отброса идентификационных данных будет являться то, что та или иная сторона в будущем будет не в состоянии инициировать новый диалог со стороной, которая предпочла остаться анонимной. Так или иначе, сторона выбирающая анонимность должна осуществлять поддержку в вопросе получения ответов и запросов в пределах диалога, участником которого она является.

Так же, в некоторых вариантах может понадобиться осуществить контроль конфиденциальных данных не только в сообщениях запроса, но и в сообщениях ответа. Первоначально, это могло бы показаться нелепым, в разрезе того, что сторона инициирующая запрос ЗНАЕТ кому он предназначен, в следствии чего данная информация вряд ли может назваться конфиденциальной. Однако, как мы видим, это может быть не так прозрачно, и здесь нужно отнестись внимательнее. В частности, в сообщениях ответа тема конфиденциальности может затронуть контактный адрес получателя запроса, под которым он в настоящее время зарегистрирован.

Когда конфиденциальность необходима?

Пользователь могут хотеть остаться со своей стороны в тени, по всевозможным причинам, например:
• Пользователи могут хотеть связаться с другой стороной без расскрытия своей идентичности для передачи информации, с которой они не хотели бы быть связанны.
• Пользователи могут бояться расскрыть свою идентичность или персональные данные в отношении некоторых сетей или мест назначения по причине, что это может сделать их мишенью для навязчивой рекламы, уголовного преследования или каких-либо других нежелательных последствий.
• Пользователи могут хотеть оставаться в неведении относительно идентификационных данных противоположной стороны, чтобы вывести за скобки механизмы биллинга или какого-либо бухгалтерского учета.

Когда юзер-агент пользователя решает отправить сообщение запроса через прокси-сервер, либо какого-либо посредника сети, это может создать сложности инициатору данного запроса в вопросе понимания — каким образом его сообщение в конечном счете будет доставлено. По этой причине пользователям рекомендуется воздерживаться от того, чтобы оперировать своими политиками конфиденциальности на основании того, кому они отправляют сообщение. Например, отправляя запрос на телефонный номер, пользователь может подразумевать, что оконечное устройство функционирует в телефонной сети общего назначения (ТфОП) и поэтому к заголовку Contact можно отнестись спустя рукава, поскольку исходя из предположения данный заголовок все равно не сможет быть распознан. На деле же этот запрос может быть вполне успешно перенаправлен к такому же как он сам sip-устройству, которое вполне естественным для себя образом распознает данную информацию.

В следующей статье будут рассмотрены степени конфиденциальности диалогов SIP. Сейчас же лишь обнозначим, что она может быть разделена на три смысловых уровня. Первый уровень отнесен к пользователю(user-provided privacy), два других к сети передачи данных(network-provided privacy). На стороне сети существует дополнительное различие, между конфиденциальностью заголовков и конфеденциальностью сессии.

Каково она — мера этой самой конфиденциальности, которой пользователю было бы достаточно в любой из возможных сессий связи? Обычно, если пользователь заинтересован в данном вопросе, то он берет все что видит, сколько может унести. Однако, если пользователь не использует каких-либо специальных сервисов предоставляющих услуги дополнительной конфиденциальности, он будет довольствоваться лишь её малой степенью.

Вместе с тем, даже если пользователь знает сервисы анонимизации, которые способны предоставить услуги по конфиденциальности в отношении sip-сигнализации, но неспособны, допустим, обеспечить шифрование трафика упреждая какое-либо подслушивание со стороны, он может воздерживаться от подобных услуг, расценивая их как зло. И в данном варианте его выбор user-provided privacy и только, может выглядеть вполне разумно.

В конце концов пользователь может брать в расчет особенности и возможности архитектуры той сети, из которой осуществляется работа его user-agent’a, что сделает его выбор более осознанным и личным, устраняющим лишь те лики данного вопроса, которые ему необходимо устранить.

К слову, в некоторых архитектурах, конфиденциальность может исполняться без какого-либо участия со стороны пользователя. Человеческое участие в вопросе формирования конфиденциальности нередко бывает опущено, поскольку пользователю не всегда имеется возможность понять, когда и на каком этапе она эта самая конфиденциальность может понадобиться. Таким образом, отправляя запрос через какого-либо посредника сети, предоставляющего услуги конфиденциальности, пользователь априори дает согласие с любым из механизмов нацеленных на конфиденциальность, которые могут включиться по ходу пьессы в случае необходимости.

Так же важно, чтобы пользователи понимали, что посредники сети могут оказаться неспособны выполнить те или иные механизмы обеспечения конфиденциальности, которые были у них запрошены. Запросы о конфиденциальности могут быть проигнорированы в следствии наложения каких-либо юридических ограничений, нереализованных или неверно сконфигурированных механизмов обеспечения конфиденциальности, либо в силу каких-либо других обстоятельств.

Здесь стоит обратить внимание на следующее: как у пользователя есть право скрывать свою идентичность — точно так же у прокси-серверов, посредников сети, либо оконечных устройств есть право отвергать сообщения, создателей которых они не могут идентифицировать. Невозможность установить личность пользователя инициирующего запрос будет частым предлогом для уклонения от обработки его. Конфиденциальность должна использоваться (запрашиваться) лишь в тех случаях, когда она действительно необходима.

Сокрытие какой-либо информации в сигнализации может быть даже избыточной в отношении некоторых пользователей. Например, юзер-агент пользователя получает имя своей машины (hostname) и айпи-адрес динамическим образом, и эта информация может не говорить о пользователи ничего вообще…