СОРМ-3 и авторизация по opt82

[Macil]

Вопрос к юристам, а также всем неравнодушным. Является ли аутентификация абонента на основе его местоположения в топологии сети: opt82, паре VLAN, ALLOC_ID/GEM и их производных, основанием для внесения записи о сеансе связи в ИС БД ОРМ (проект приказа Минсвязи)?

 

С моей точки зрения — нет. Топология сети изменчива.

 

Я вижу следующие варианты: а) выдаём оборудование по акту приёма-передачи, в договоре прописываем что MAC-адрес или серийный номер являются идентификатором (одним из факторов идентификации) абонента; б) выдаём абоненту логин-пароль и т.д.; в) ведём подробную документацию об изменении структуры сети с сохранением необходимых данных в журнал авторизации.

 

ИМХО, это одна из подлинных проблем «новых реалий».

[YuryD]

Вопрос к юристам, а также всем неравнодушным. Является ли аутентификация абонента на основе его местоположения в топологии сети: opt82, паре VLAN, ALLOC_ID/GEM и их производных, основанием для внесения записи о сеансе связи в ИС БД ОРМ (проект приказа Минсвязи)?

 

С моей точки зрения — нет. Топология сети изменчива.

 

Я вижу следующие варианты: а) выдаём оборудование по акту приёма-передачи, в договоре прописываем что MAC-адрес или серийный номер являются идентификатором (одним из факторов идентификации) абонента; б) выдаём абоненту логин-пароль и т.д.; в) ведём подробную документацию об изменении структуры сети с сохранением необходимых данных в журнал авторизации.

 

ИМХО, это одна из подлинных проблем «новых реалий».

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

[NikAlexAn]

Пока требования к ИС не утвердили можно только теоретизировать.

А вообще - зависит от биллинга и что и как вы учитываете при авторизации абонента.

В основном то нужна история назначения IP адресов.

[Связной (С)]

...Однако уже требуется сообщать место и адрес при вызове в 112.

[Macil]

Пока требования к ИС не утвердили можно только теоретизировать.

Да, согдасен. Но я не думаю, что будут внесены серьёзные изменения.

В основном то нужна история назначения IP адресов.

Вот в этом-то как раз и проблема! Назначение на основании *чего*? Мне было бы очень некомфортно осознавать что пара Curcuit ID="12" Remote ID= "345" являются основанием для выделения IP-адреса.

[nemo_lynx]

Разве что в случае, если ваш ДХЦП лезет в биллинг через RADIUS. И то под вопросом.

Сейчас основной интерес в СОРМ-3 для Товарищей Офицеров составляет вопрос однозначной идентификации абонента по IP и MAC из трафика в конкретный момент времени. Ну и все персональные данные на требуемого фигуранта. Чтобы у следователя по нажатию кнопки получилась картинка: такой-то гражданин (ФИО, адрес, серия/номера/дата документа, дата рождения) в рамках договора с таким-то номером потреблял такую-то услугу у такого-то оператора, оплатил эту услугу тогда-то через такой-то банк по такому-то адресу в такой-то сумме таким-то способом, такого-то числа во столько-то времени по такому-то адресу местонахождения (gps-координаты в случае подвижной связи) выполнял доступ с такого-то устройства с таким-то IP и с таким-то MAC (и прочие возможные идентификаторы CPE) на такой-то нехороший ресурс и передавал такой-то трафик экстремисткого/терористического/порнографического (выбрать необходимое) содержания в таком-то размере посредством такого-то протокола передачи данных.

В этом смысл СОРМ-3. Что послужило основанием для предоставления абоненту IP-адреса, Конторе интересно лишь в том случае, если используется авторизация на основе уникального для абонента логина/пароля. То есть, когда в трафике есть пакеты с логином/паролем, однозначно подтверждающие что именно этот фигурант начал/закончил сеанс связи. ДХЦП (как скорее всего и любой другой подобный броадкаст/мультикаст) в этом плане им не очень интересно. А вот RADIUS они напротив, очень любят.

[YuryD]

В этом смысл СОРМ-3. Что послужило основанием для предоставления абоненту IP-адреса, Конторе интересно лишь в том случае, если используется авторизация на основе уникального для абонента логина/пароля. То есть, когда в трафике есть пакеты с логином/паролем, однозначно подтверждающие что именно этот фигурант начал/закончил сеанс связи. ДХЦП (как скорее всего и любой другой подобный броадкаст/мультикаст) в этом плане им не очень интересно. А вот RADIUS они напротив, очень любят.

 

У нас сроду днхсп не было, и не будет почти. Клиенту выдаётся либо серый однозначный адрес в впн, либо рельник - в биллинге, всё есть. Так что клиент обнаружен однозначно Радиус - они вполне декодируют. Почему у у меня нету дхнсп - и в биллинге адреса не дублруются - всё просто, я устал отвечать на древние запросы правохранителей. А так - протухший клиент - но данные сохранены в биллинге.

[pas-cross]

Является ли аутентификация абонента на основе его местоположения в топологии сети: opt82, паре VLAN, ALLOC_ID/GEM и их производных, основанием для внесения записи о сеансе связи в ИС БД ОРМ (проект приказа Минсвязи)?

 

С моей точки зрения — нет. Топология сети изменчива.

 

На мой взгляд очевидно да, т.к.:

Список использованных сокращений и терминов:

Сессия (сеанс связи) - Любое авторизованное подключение к сети связи, в рамках которого пользователь получает услуги связи

[YuryD]

На мой взгляд очевидно да, т.к.:

Список использованных сокращений и терминов:

Сессия (сеанс связи) - Любое авторизованное подключение к сети связи, в рамках которого пользователь получает услуги связи

 

Прямое толкование AAA, аутентификация юзера и авторизация на сервисы. А аккаунтинг - это к яровой. Они чего-то начинают понимать.