Lan биллинг что это
Наверное, хотя бы один раз в жизни каждому из нас приходилось покупать Интернет по Dial-Up. А раз так, то каждый из нас сталкивался с биллинговой системой: подсчетом количества времени, трафика (мегабайт) и денег.
В сумме весь данный комплекс программ и называется биллинговой системой. Но биллинговые системы используются не только у интернет-сервис-провайдеров (Internet Service Provider).
Если на вашей АТС поминутная оплата переговоров по коммутируемой линии, то на этой АТС также обязательно должна работать биллинговая система.
Если вы пользуетесь мобильным телефоном, то у компании-провайдера телефонных услуг также существует огромный комплекс биллинговых программ.
В нашем контексте (для ИСП) «биллинговая система» имеет смысл как комплекс программ для учета количества секунд и байт, затраченных пользователем в Интернете. Вы можете спросить, почему же именно секунд и байт? Очень просто – это базовые единицы измерения. Ведь именно из секунд мы можем получить остальные значения: минуты, часы, сутки и так далее; из байт – килобайты, мегабайты и т. д. «А деньги?» – возразите вы. Да, все правильно, но исходя из секунд и байт, вы сможете, установив тариф, получить деньги.
Биллинговые системы бывают разные, их можно примерно разделить по нескольким признакам:
- под какую операционную систему написан данный биллинг (Windows, UNIX, Linux, OS/2 и т. д.);
- по какому принципу данный комплекс работает (принцип «счетчика», принцип «снифера», принцип «анализа log-файлов» и т. д.);
- как именно написан комплекс программ в самой системе биллинга (бинарные файлы, скриптовые файлы и т. д.).
Вы вправе не согласиться с такой классификацией и выделить еще несколько признаков. Например, такой: вид вывода информации. Но автор намеренно решил не относить данный признак к так называемым «основным», так как нет единого стандарта на вывод информации. Новичкам нагляднее будет рабочая программа под управлением MS Windows, для опытных системных администраторов предпочтительнее будет увидеть консольную программу под управлением UNIX – но в итоге можно спорить сколько угодно и не прийти к единому мнению. Единственной альтернативой будет использование платформы Web и, как следствие, использование программы apache web server, а в самой программе – генерация html-страниц для показа через Сеть.
Анализ биллинговых систем на рынке софта
Если вы решили приобрести уже готовый биллинг, для начала определитесь: что именно вам нужно.
Для некоторых провайдеров может быть выгоднее купить уже готовый комплекс биллинговых программ, нежели писать их самим, для этого сделаем небольшой анализ рынка биллинговых систем.
На нашем рынке программного обеспечения вы можете найти практически любые биллинги, их разрабатывают многие компании, но очень мало кто может позволить себе купить данные программные продукты в силу их огромной стоимости. Например, биллинговые системы для телефонных компаний стоят начиная от $500000. А это уже совершенно другой уровень, нежели компании интернет-провайдера, тут биллинг можно приобрести и за $200. Но все упирается в то, что именно будет делать данный биллинг! В среднем цена достаточно хорошего биллинга колеблется от $500 до $5000 для компаний ИСП.
И как вы понимаете, за разные суммы создаются и разные биллинги. Биллинги также могут либо работать с определенным оборудованием, либо нет. Например, если вы приобрели себе оборудование модемного пула Cisco – это уже дополнительное оборудование к обычному компьютеру, и, как следствие, возрастает цена минимального биллинга с $200 до $500.
Так же имеются нюансы юридического плана. Если вы покупаете биллинговую систему у компании с гарантией или ответственностью компании перед вами, то в зависимости от договора цена может возрасти от двух до десятков раз.
Если же вы заказываете создание биллинга у программиста или группы программистов (для ускорения написание системы), то зачастую вы получаете готовую систему, но если что-то пойдет не так, вы будете отвечать перед вашими клиентами сами.
Есть еще нюанс. Компании всегда предоставляют уже готовую систему, с одной стороны, это очень удобно, к вам приедут знающие специалисты и создадут всю систему «под ключ» буквально за несколько дней, но есть и обратная сторона медали: биллинговая система будет у вас не уникальная, а это в свою очередь значит, что вас смогут «взломать». Так как опытные хакеры могут найти одну «дыру» в системе и, соответственно, могут взломать и все подобные системы. В данном случае даже самая простая, но уникальная система будет в огромном выигрыше, т.к. ни у кого больше такой нет.
Итак, несколько замечаний по поводу выбора программ биллинга в зависимости от того, что именно вам надо подсчитывать и каким именно оборудованием вы можете располагать. Но нельзя считать взгляд автора единственным и непогрешимым, тем более в области информационных технологий можно одно и то же сделать многими способами.
Если вам надо подсчитывать время пребывания пользователя на модемном пуле по коммутируемой линии, то вам легче всего будет заказать биллинг у программиста. Это дешево (около $200); система будет формировать свои выводы в виде html-страниц как единственного универсального средства отображения информации. Причем за $200 вы получите готовый уникальный биллинг.
Если же вы хотите организовать биллинг на принципе анализа log-файлов, то данный комплекс программ будет еще дешевле – около $100-150.
Данные биллинги будут работать практически на любом оборудовании, все зависит от того, что именно вы поставите как модемный пул. Для маленькой компании интернет-сервис-провайдера автор советует приобрести расширитель COM-портов, так как на один компьютер архитектуры PC можно поставить не более 2 портов. Компьютер класса более чем 486DX/16 Мб RAM/1.2 Гб HDD – это для биллинг-сервера, но при этом вам придется поставить отдельно веб-сервер на другом компьютере, либо увеличить производительность данного компьютера.
Создание биллинг-комплекса с использованием дополнительного оборудования, например, модемного пула Cisco, сразу увеличит ваши затраты, но, с другой стороны, если у вас есть деньги на такую дорогую аппаратуру, то вам уже не страшно будет услышать цены на данные комплексы. По данным сети IRC только модуль снятия статистики с аппаратуры Cisco будет стоить от $200 до $1000, не учитывая саму биллинг-статистику. Данный вид биллинга автор советует заказывать уже не программисту-одиночке, а команде программистов. Это будет более дешевый выход.
В зависимости от принципа снятия статистики очень варьируется стоимость разработки системы.
- Использование принципа скриптов – один из самых «дешевых» принципов. Но он имеет массу недостатков, а главное – он не может показать статистику в режиме реального времени. Его цена колеблется от $200 до $500.
- Принцип «снифера» заключается в создании программы, которая будет анализировать и считать все пакеты на данном компьютере. Для этого уже нужна более высокая производительность компьютера, нежели на принципе «скриптов»: около (P-MMX-166/64 RAM/4Gb HDD). Так как в режиме реального времени некая программа-демон будет работать на уровне ядра или на уровне пользовательских программ по терминологии операционной системы Linux. А при большом трафике, около 40 Мбит в секунду и выше, понадобится еще большая производительная мощность компьютеров.
Данная статья не претендует на полное описание всех возможных биллингов, все их описать в одной статье невозможно. Темой данной статьи является создание простейшего биллинга для маленького новоиспеченного интернет-сервис-провайдера.
Создание простейшей биллинговой системы
Стадия 1: анализ
Для примера рассмотрим создание простейшей биллинговой системы, построенной по принципу скриптов-счетчиков для снятия трафика и подсчета времени, затраченного пользователем в Интернете. Данная статистика больше будет приемлема для провайдера, использующего модемный пул. Мы будем создавать биллинговую систему, ориентируясь на операционную систему Linux, так как она открыта, ее можно свободно купить или загрузить из Интернета. Исходя из выбранного дистрибутива Linux, мы выберем компьютер и приступим к написанию.
Дистрибутивов Linux существует огромное количество. Есть дистрибутивы, которые больше ориентированы на серверы; есть те, которые больше ориентированы на графику; есть такие, которые пытаются потягаться с MS Windows на поприще рабочих станций, и это у них очень хорошо получается.
В нашем же случае необходимо выбрать сервер. Хотя из любого дистрибутива Linux можно сделать самому руками и сервер, и рабочую станцию, и мультимедийную станцию, но все-таки лучше выбирать изначально сервер-ориентированный дистрибутив. Таким, на взгляд автора, является дистрибутив RedHat – самый распространенный дистрибутив по части серверных операционных систем. Многим он может не понравиться, или не нравится уже сейчас, – вы вправе выбрать любой другой дистрибутив и, автор думает, у вас все получится без изменения исходных кодов, приведенных в данной статье.
Многие могут высказаться за операционную систему FreeBSD, но у нее есть небольшой недостаток – новичку в ней очень тяжело разобраться. А данная статья рассчитана на новичков в этом деле.
Итак, мы выбрали ветвь RedHat-дистрибутивов. Теперь надо определиться с версией. Автор предлагает брать последнюю (на момент написания статьи) – 7.3 – стабильная последняя версия.
Для данного дистрибутива нужен достаточно мощный компьютер, а так как мы рассчитываем на довольно слабый компьютер, то лучше взять клон дистрибутива RedHat украинской команды BlackCat Linux Team. Они ввели дополнительный компонент, повышающий безопасность дистрибутива. Он разрабатывался, когда еще не было таких мощных машин, и будет себя прекрасно чувствовать на слабом компьютере.
Плату расширения COM-портов можете выбрать самостоятельно: тут не возникнет проблем. Для всех них существуют драйверы под RedHat 6.2.
Наш выбор: BlackCat Linux 6.2 на P-MMX-166/32 RAM/2 Гб HDD.
Стадия 2: реализация
Для реализации задуманного нам потребуются знания операционной системы Linux, немного программирования на языке Perl и Bash. Bash на самом деле не язык программирования, а язык написания скриптов, как и Perl. Если кто-то захочет, то сможет это все реализовать на любом другом языке программирования.
Итак, для того чтобы начинать писать, нам надо знать как это все работает в операционной системе. Схема довольно-таки простая.
Начнем по порядку. Пользователь звонит на сервер. Модем поднимает трубку и происходит установка связи двух модемов. Когда связь установлена, процесс входа пользователем в Сеть переходит во вторую фазу – фазу авторизации. Затем, после авторизации, наступает фаза поднятия TCP/IP-протокола. Вот так происходит вход пользователя в Сеть в Linux. Выход происходит в обратном порядке. Сначала опускается TCP/IP-протокол, затем выход-авторизация, затем разрыв связи. Иногда бывает, что происходит разрыв связи не по воле пользователя. Тогда немного меняется схема: сначала происходит разрыв связи, затем уже снятие TCP/IP-протокола, и последнее – выход-авторизация.
Мы внесем некоторые изменения в данную схему, а именно: добавим дополнительный блок. После установки соединения и полной авторизации будет выполняться наша маленькая программа, которая будет сохранять имя пользователя, время его входа и любые другие данные, которые могут потребоваться в вашей системе.
Так же добавим дополнительное звено и в выходную цепочку, поставив дополнительное звено после выход-авторизации.
На практике это произойдет путем редактирования двух файлов auth-up и auth-down, находящихся в директории [/etc/ppp]. Добавим в конец обоих файлов по строке:
соответственно. Данные строчки после авторизации или выход-авторизации запустят наши программы биллинговой системы. Через пробел в наши скрипты мы добавляем любые переменные, которые захотим передать в программу. Переменная имеет значение имени пользователя или, точнее сказать, его логина. О том, как сделать полную авторизацию с паролем через собственную систему биллинга, будет отдельная статья. Так как нам необходимо было передать в биллинговую систему не только имя пользователя, но и время его входа – мы воспользуемся языком программирования Perl и вызовем функцию системного времени.
6.print(FL, “$username “, localtime, “ ”);
Строка 01 – обязательная, она сообщает, что это Perl-программа. Строка 04 – мы переприсваиваем имя пользователя из массива в переменную, этого можно и не делать, – это сделано для наглядности. Строка 05 – открываем файл для записи, в данном файле будет храниться строка: что за пользователь зашел и во сколько (в формате UTC). Строка 06 – собственно, запись имени пользователя и времени его входа в систему.
9.@user = split(/ /,$temp);
12.$timeonline = $logouttime — $logintime;
14.print(FL, “User: $username, LogIn: $logintime, LogOut: $logouttime, OnLineTime: $timeonline”);
Первые строки программы такие же, как и в предыдущей программе. Строка 04 – переприсваивание имени пользователя. Строки 05-07 – открытие файла, чтение из него строки, закрытие файла, или, точнее, освобождение дескриптора файла. Строка 08 – это обрезание лишних пробелов и символа перевода каретки. Строка 09 – разбиение строки на массив переменных. Переприсваиваем в строке 10 время входа пользователя для наглядности. Узнаем время выхода пользователя в строке 11. В строке 12 узнаем, сколько времени пробыл пользователь на линии, данное число представляет собой количество секунд. В строке 13 открываем файл для добавления записи о пользователе. Строка 14, собственно, сама запись: фиксируем имя пользователя, время входа, время выхода и время, проведенное пользователем на линии.
Данная система биллинга очень простая: она считает только лишь время, проведенное пользователем на линии. Для того чтобы считать количество байт, которые пользователь загрузил или выгрузил из Интернета, нужно усложнить наши программы. В каждом конкретном случае надо подходить отдельно.
Для той операционной системы, которую мы выбрали для написания биллинга, свойственно ядро (kernel) версии 2.2.х. В данном ядре была реализована система контроля за IP-пакетами – на уровне IP-цепочек (ipchains). Для версии ядра 2.4.х уже реализована система Netfilter, с управлением через IP-таблицы (iptables). Она более гибкая и более совершенная, нежели цепочки. Но в выбранной операционной системе применены цепочки, вы можете сами пересобрать ядро более высокой версии, но это уже отдельная тема.
Существует очень много способов подсчета трафика, автор приводит для примера один из них: принцип счетчика.
Чтобы подсчитать количество байт, загруженных или выгруженных пользователем, необходимо создать правило цепочек для конкретного IP, так как Linux использует для идентификации IP-пакетов IP-адреса. И каждому пользователю, подключенному по модему, всегда выдается IP-адрес, причем реально выдается два IP-адреса: один – на модем со стороны сервера, второй – на модем пользователя. Конечно же, IP-адреса выдаются не на физически работающий модем, а на компьютер. Для создания правила цепочки необходимо знать IP-адрес, который выдался пользователю. Для этого существует специальный параметр в скриптах auth-up и auth-down, данный параметр называется . Его надо передать в программу, которая будет создавать правило. А так же в программу, которая будет снимать показания счетчика и удалять после выхода пользователя счетчик.
Данные программы будут count-up и count-down, их вызов надо будет проставить из скриптов auth-up и auth-down соответственно:
Именем цепочки будет служить имя пользователя, вернее, его логин.
Создание новой цепочки с именем пользователя.
Удаление всех правил в цепочке.
Удаление пустой цепочки.
Извлечение статистики по цепочке в полном формате, не сокращая количество байт.
ipchains –A input –s /32 –d 0/0 –j
Добавление правила в цепочку input, которое будет срабатывать при появлении пакета с исходным адресом нашего пользователя /32 и адресом назначения любым (0/0), причем будет происходить переход в цепочку с именем нашего пользователя .
ipchains –A output –d /32 –s 0/0 –j
Добавление правила в цепочку output, которое будет срабатывать при появлении пакета с адресом назначения нашего пользователя /32, а исходный адрес может быть любым (0/0), причем переход будет происходить в цепочку с именем .
ipchains –D input –s /32 –d 0/0 –j
Удаление правила из цепочки input.
ipchains –D output –d /32 –s 0/0 –j
Удаление правила из цепочки output.
Из этих команд вы сами можете создать какую хотите систему счетчиков по образу и подобию программ, приведенных выше.
Стадия 3: ограничения на тестирование
До начала тестирования системы надо сразу узнать количество ограничений, присущих данной, крайне простой, системе биллинга.
Во-первых, имя пользователя может быть только лишь цифробуквенным и не более 8 символов.
Во-вторых, данная система не будет работать, если пользователи будут заходить одновременно с разных модемов, так как это будет уже коммерческим биллингом. Для реализации этого пункта нужно не так уж много сил, но автор специально не приводит в статье эти изменения. Вы их всегда можете узнать или получить в Сети IRC, бесплатно или нет, – это уже все зависит от вас.
Остальное не столь существенно как первые три пункта.
Ну вот и все. Если у кого-нибудь возникли вопросы по данной теме, изменения или дополнения к статье, автор будет рад вам ответить.
Сертифицированная биллинговая система для тарификации интернета, телефонии, телевидения и прочих услуг
АСР LANBilling подойдёт организациям, которые хотят автоматизировать свои процессы
- Вести базу абонентов и учитывать взаимоотношения с ними
- Предоставлять абонентам доступ в личный кабинет
- Тарифицировать услуги связи и дополнительные услуги
- Принимать платежи от абонентов и вести межоператорские взаиморасчёты
- Контролировать доступ к сети и услугам
- Формировать отчёты
Приём платежей через внешние системы: Assist, Cloudpayments, QIWI, Сбербанк, Тинькофф Оплата, ЮKassa и другие
Хранилище данных об активном сетевом оборудовании: о том, которое использует оператор, и том, что выдано абонентам
Остались вопросы? Напишите нам
О нас
Мы разрабатываем ПО в области телекоммуникаций с 2001 года.
Компания «Сетевые решения» — это решения, проверенные временем.
Контакты
Режим работы
Понедельник – пятница,
с 9:00 до 18:00
Политика в отношении обработки
персональных данных
Владислав Пинженин, генеральный директор ООО «Сетевые решения» (LANBilling)
Рассуждать на тему выбора системы расчетов, даже производя одну из них, как оказалось, весьма сложно ввиду того, что, прежде всего, нужно поставить себя на место потребителя (читай - перейти на другую сторону баррикад). Даже имея опыт оказания телекоммуникационных услуг в компаниях операторах это не всегда просто, ибо рынок меняется, мягко говоря, очень динамично, и для адекватного суждения требуется «вариться» в телекоме постоянно отслеживая состояние рынка с точки зрения оператора. С другой стороны, рассуждать о выборе АСР производителю оной гораздо проще по сравнению с начинающим оператором т.к. именно к производителю (если он успел набрать достаточное количество пользователей своей системы), если можно так выразиться, стекаются все запросы в отношении востребованных функций систем расчетов на текущий момент от реально работающих операторов.
В этом тексте я постараюсь обратить внимание на важные аспекты выбора биллинговой системы, не принимать во внимание которые, просто безрассудно, принимая решение об использовании такого критически важного для бизнеса инструмента, как автоматизированная система расчетов. Читать весь материал
7. Трансграничная передача персональных данных
7.1. Оператор до начала осуществления трансграничной передачи персональных данных обязан убедиться в том, что иностранным государством, на территорию которого предполагается осуществлять передачу персональных данных, обеспечивается надежная защита прав субъектов персональных данных.
7.2. Трансграничная передача персональных данных на территории иностранных государств, не отвечающих вышеуказанным требованиям, может осуществляться только в случае наличия согласия в письменной форме субъекта персональных данных на трансграничную передачу его персональных данных и/или исполнения договора, стороной которого является субъект персональных данных.
Андрей Ефремов, заместитель директора по маркетингу компании CBOSS
Первый и наиболее значимый фактор, на который необходимо обратить внимание при выборе биллинга – конвергентность программного решения. От него напрямую зависят возможности оператора по развитию бизнеса и величина общей стоимости владения решением (TCO).
С точки зрения бизнеса, TCO – это количество средств, которые оператору придется реально потратить на выполнение стоящих перед ним задач. TCO включает в себя первоначальные инвестиции на приобретение, настройку и запуск решения, а также расходы на поддержку, сопровождение и развитие решения в дальнейшем.
Практика показывает прямую зависимость: чем полнее конвергентность реализована в решении, тем более низкий у него показатель TCO при прочих равных условиях. Читать весь материал.
5. Правовые основания обработки персональных данных
5.2. Оператор обрабатывает обезличенные данные о Пользователе в случае, если это разрешено в настройках браузера Пользователя (включено сохранение файлов «cookie» и использование технологии JavaScript).
Михаил Савицкий, руководитель бизнес-направления BSS и CRM-систем компании «Микротест»
Прежде чем приступить к выбору биллинговой системы, компания – оператор связи должна четко понимать, для чего ему нужен биллинг. Причем необходимо смотреть не только на текущие потребности бизнеса компании, но и планировать будущие задачи хотя бы на 3 года вперед. Естественно, все это должно быть правильно отражено в техническом задании, RFP и т.п. документах. Вратце можно выделить несколько наиболее значимых критериев выбора биллинговой системы. Читать весь материал.
3. Оператор может обрабатывать следующие персональные данные Пользователя
3.1.Фамилия, имя, отчество;
3.4. Также на сайте происходит сбор и обработка обезличенных данных о посетителях (в т.ч. файлов «cookie») с помощью сервисов интернет-статистики (Яндекс Метрика и Гугл Аналитика и других).
3.5. Вышеперечисленные данные далее по тексту Политики объединены общим понятием Персональные данные.
8. Заключительные положения
8.2. В данном документе будут отражены любые изменения политики обработки персональных данных Оператором. Политика действует бессрочно до замены ее новой версией.
2. Основные понятия, используемые в Политике
2.1. Автоматизированная обработка персональных данных – обработка персональных данных с помощью средств вычислительной техники;
2.2. Блокирование персональных данных – временное прекращение обработки персональных данных (за исключением случаев, если обработка необходима для уточнения персональных данных);
2.4. Информационная система персональных данных — совокупность содержащихся в базах данных персональных данных, и обеспечивающих их обработку информационных технологий и технических средств;
2.5. Обезличивание персональных данных — действия, в результате которых невозможно определить без использования дополнительной информации принадлежность персональных данных конкретному Пользователю или иному субъекту персональных данных;
2.6. Обработка персональных данных – любое действие (операция) или совокупность действий (операций), совершаемых с использованием средств автоматизации или без использования таких средств с персональными данными, включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передачу (распространение, предоставление, доступ), обезличивание, блокирование, удаление, уничтожение персональных данных;
2.7. Оператор – государственный орган, муниципальный орган, юридическое или физическое лицо, самостоятельно или совместно с другими лицами организующие и (или) осуществляющие обработку персональных данных, а также определяющие цели обработки персональных данных, состав персональных данных, подлежащих обработке, действия (операции), совершаемые с персональными данными;
2.10. Предоставление персональных данных – действия, направленные на раскрытие персональных данных определенному лицу или определенному кругу лиц;
2.11. Распространение персональных данных – любые действия, направленные на раскрытие персональных данных неопределенному кругу лиц (передача персональных данных) или на ознакомление с персональными данными неограниченного круга лиц, в том числе обнародование персональных данных в средствах массовой информации, размещение в информационно-телекоммуникационных сетях или предоставление доступа к персональным данным каким-либо иным способом;
2.12. Трансграничная передача персональных данных – передача персональных данных на территорию иностранного государства органу власти иностранного государства, иностранному физическому или иностранному юридическому лицу;
2.13. Уничтожение персональных данных – любые действия, в результате которых персональные данные уничтожаются безвозвратно с невозможностью дальнейшего восстановления содержания персональных данных в информационной системе персональных данных и (или) уничтожаются материальные носители персональных данных.
2. Основные понятия, используемые в Политике
2.1. Автоматизированная обработка персональных данных – обработка персональных данных с помощью средств вычислительной техники;
2.2. Блокирование персональных данных – временное прекращение обработки персональных данных (за исключением случаев, если обработка необходима для уточнения персональных данных);
2.4. Информационная система персональных данных — совокупность содержащихся в базах данных персональных данных, и обеспечивающих их обработку информационных технологий и технических средств;
2.5. Обезличивание персональных данных — действия, в результате которых невозможно определить без использования дополнительной информации принадлежность персональных данных конкретному Пользователю или иному субъекту персональных данных;
2.6. Обработка персональных данных – любое действие (операция) или совокупность действий (операций), совершаемых с использованием средств автоматизации или без использования таких средств с персональными данными, включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передачу (распространение, предоставление, доступ), обезличивание, блокирование, удаление, уничтожение персональных данных;
2.7. Оператор – государственный орган, муниципальный орган, юридическое или физическое лицо, самостоятельно или совместно с другими лицами организующие и (или) осуществляющие обработку персональных данных, а также определяющие цели обработки персональных данных, состав персональных данных, подлежащих обработке, действия (операции), совершаемые с персональными данными;
2.10. Предоставление персональных данных – действия, направленные на раскрытие персональных данных определенному лицу или определенному кругу лиц;
2.11. Распространение персональных данных – любые действия, направленные на раскрытие персональных данных неопределенному кругу лиц (передача персональных данных) или на ознакомление с персональными данными неограниченного круга лиц, в том числе обнародование персональных данных в средствах массовой информации, размещение в информационно-телекоммуникационных сетях или предоставление доступа к персональным данным каким-либо иным способом;
2.12. Трансграничная передача персональных данных – передача персональных данных на территорию иностранного государства органу власти иностранного государства, иностранному физическому или иностранному юридическому лицу;
2.13. Уничтожение персональных данных – любые действия, в результате которых персональные данные уничтожаются безвозвратно с невозможностью дальнейшего восстановления содержания персональных данных в информационной системе персональных данных и (или) уничтожаются материальные носители персональных данных.
Артем Зиновьев, директор по развитию департамента телекоммуникационных систем компании «Рексофт»
При выборе биллинговой системы я бы постарался удостовериться в том, что она отвечает всем задачам, стоящим перед компанией, обладает потенциалом для дальнейшего расширения и ее можно успешно интегрировать с другими элементами сети. Наличие открытых интерфейсов, упрощающих поддержку и настройку системы – это также большое достоинство. Обязательно наличие местной службы поддержки и разумная цена на нее, иначе при возникновении каких-либо проблем с биллинговой системой компания рискует столкнуться со значительными непредвиденными расходами. Кроме того, многие разработчики биллинговых систем предлагают в качество бонуса дополнительную функциональность, на которую тоже стоит обратить внимание.
7. Трансграничная передача персональных данных
7.1. Оператор до начала осуществления трансграничной передачи персональных данных обязан убедиться в том, что иностранным государством, на территорию которого предполагается осуществлять передачу персональных данных, обеспечивается надежная защита прав субъектов персональных данных.
7.2. Трансграничная передача персональных данных на территории иностранных государств, не отвечающих вышеуказанным требованиям, может осуществляться только в случае наличия согласия в письменной форме субъекта персональных данных на трансграничную передачу его персональных данных и/или исполнения договора, стороной которого является субъект персональных данных.
6. Порядок сбора, хранения, передачи и других видов обработки персональных данных
Безопасность персональных данных, которые обрабатываются Оператором, обеспечивается путем реализации правовых, организационных и технических мер, необходимых для выполнения в полном объеме требований действующего законодательства в области защиты персональных данных.
6.1. Оператор обеспечивает сохранность персональных данных и принимает все возможные меры, исключающие доступ к персональным данным неуполномоченных лиц.
6.2. Персональные данные Пользователя никогда, ни при каких условиях не будут переданы третьим лицам, за исключением случаев, связанных с исполнением действующего законодательства.
1. Общие положения
Настоящая политика обработки персональных данных составлена в соответствии с требованиями Федерального закона от 27.07.2006. №152-ФЗ «О персональных данных» и определяет порядок обработки персональных данных и меры по обеспечению безопасности персональных данных, предпринимаемые ООО "Сетевые решения" (далее – Оператор).
1.1. Оператор ставит своей важнейшей целью и условием осуществления своей деятельности соблюдение прав и свобод человека и гражданина при обработке его персональных данных, в том числе защиты прав на неприкосновенность частной жизни, личную и семейную тайну.
Ритварс Криевс, технический директор «TELE2 Россия»
Невозможно говорить о критериях выбора системы биллинга в отрыве от стратегии использующей ее компании-оператора. Приоритеты и критерии эффективности будут неодинаковы даже у операторов, близко конкурирующих на одном и том же рынке. Биллинговая система должна представлять собой конвергентное решение, способное поддерживать не только все услуги, предоставляемые компанией в настоящее время, но и перспективные технологии и бизнес-модели, быть легко и безболезненно масштабируемой для обслуживания быстрого роста абонентской базы и объемов потребляемых услуг, быть функционально гибкой и адаптируемой, с тем, чтобы обеспечить кратчайшие сроки вывода на рынок новых продуктов, а также иметь низкую стоимость владения.
Александр Емельянов, руководитель отдела информационных систем Санкт-Петербургского филиала ЗАО «ВЕСТ КОЛЛ ЛТД»
При взаимодействии с операторами связи система операторских расчетов за услуги пропуска трафика сильно отличается от системы расчетов с клиентами (и корпоративными, и физическими лицами) . После введения в 2006 году новых правил взаимодействия между операторами появились такие понятия, как местное и зоновое инициирование вызова, местное и зоновое завершение вызова, а также разделение услуг по пропуску трафика в зависимости от количества транзитных узлов на сети оператора. Эти изменения потребовали в свое время существенной доработки биллинга. Таким образом, главным аргументом при выборе биллинговой системы должна является ее гибкость, то есть возможность тарификации по разным параметрам, масштабируемость (возможность адаптации при расширении спектра предоставляемых услуг), а также легкость и простота взаимодействия с уже имеющимися системами различных производителей. Кроме того, в условиях либерализации рынка дальней связи биллинговая система должна предусматривать возможность выставления счетов от имени разных операторов дальней связи, а также формировать всю необходимую для них отчетность. Наименьшим значением при выборе биллинга в компании является платформа, на которой существует система (ОС и СУБД). Во-первых, большинство платформ равнозначны, а во-вторых, IT-специалисты должны уметь работать с разными платформами.
Политика в отношении обработки
персональных данных
1. Общие положения
Настоящая политика обработки персональных данных составлена в соответствии с требованиями Федерального закона от 27.07.2006. №152-ФЗ «О персональных данных» и определяет порядок обработки персональных данных и меры по обеспечению безопасности персональных данных, предпринимаемые ООО "Сетевые решения" (далее – Оператор).
1.1. Оператор ставит своей важнейшей целью и условием осуществления своей деятельности соблюдение прав и свобод человека и гражданина при обработке его персональных данных, в том числе защиты прав на неприкосновенность частной жизни, личную и семейную тайну.
5. Правовые основания обработки персональных данных
5.2. Оператор обрабатывает обезличенные данные о Пользователе в случае, если это разрешено в настройках браузера Пользователя (включено сохранение файлов «cookie» и использование технологии JavaScript).
3. Оператор может обрабатывать следующие персональные данные Пользователя
3.1.Фамилия, имя, отчество;
3.4. Также на сайте происходит сбор и обработка обезличенных данных о посетителях (в т.ч. файлов «cookie») с помощью сервисов интернет-статистики (Яндекс Метрика и Гугл Аналитика и других).
3.5. Вышеперечисленные данные далее по тексту Политики объединены общим понятием Персональные данные.
6. Порядок сбора, хранения, передачи и других видов обработки персональных данных
Безопасность персональных данных, которые обрабатываются Оператором, обеспечивается путем реализации правовых, организационных и технических мер, необходимых для выполнения в полном объеме требований действующего законодательства в области защиты персональных данных.
6.1. Оператор обеспечивает сохранность персональных данных и принимает все возможные меры, исключающие доступ к персональным данным неуполномоченных лиц.
6.2. Персональные данные Пользователя никогда, ни при каких условиях не будут переданы третьим лицам, за исключением случаев, связанных с исполнением действующего законодательства.
4. Цели обработки персональных данных
4.1. Цель обработки персональных данных Пользователя —информирование Пользователя посредством отправки электронных писем; предоставление доступа Пользователю к сервисам, информации и/или материалам, содержащимся на веб-сайте; информирование Пользователя посредством телефонного звонка.
4.3. Обезличенные данные Пользователей, собираемые с помощью сервисов интернет-статистики, служат для сбора информации о действиях Пользователей на сайте, улучшения качества сайта и его содержания.
8. Заключительные положения
8.2. В данном документе будут отражены любые изменения политики обработки персональных данных Оператором. Политика действует бессрочно до замены ее новой версией.
Программа MRTG (The Multi Router Traffic Grapher) предназначена для мониторинга загрузки канала за сутки, неделю, месяц и год. Программа MRTG умеет рисовать красивые картинки в формате PNG, которые отображают состояние канала за определенный период времени. Программа предоставляет очень удобные средства для подсчета трафика: подсчет для всей сети и для отдельного узла, генерирование отчетов и диаграмм в формате HTML и многое другое.
Для работы mrtg нам потребуется маршрутизатор, поддерживающий протокол SNMP. В этой статье будет рассмотрен пример, позволяющий обойтись без маршрутизатора и вообще не использовать протокол SNMP.
Перед установкой программы убедитесь в наличии следующих библиотек:
Если вы используете операционную систему RedHat версии 7 или выше, программа MRTG, скорее всего, будет уже у вас установлена. Мы не будем скачивать исходные тексты программы, а сразу воспользуемся уже собранным пакетом rpm. Установим mrtg командой:
После установки нужно подготовить программу к первому запуску, то есть указать, откуда получать сведения о трафике.
Программа MRTG состоит из трех частей:
- cfgmaker – утилита для создания конфигурационного файла;
- indexmaker – утилита для создания файла index.html – страницы краткого обзора, дающая вам общее представление о всех целях, которые вы контролируете. О целях мы поговорим немного позже;
- mrtg – сам mrtg.
Первый конфигурационный файл удобно создать с помощью программы cfgmaker, а потом добавить в него дополнительные параметры. Введите команду:
cfgmaker --global "WorkDir: /var/www/html/mrtg" --global "Options[_]: bits,growright" --output /var/www/html/mrtg/mrtg.cfg community@router
Теперь разберемся, что все это означает. Прежде всего, напомню, что означает наклонная черта: это просто перенос строки. Когда вы будете вводить команду, вместо наклонной черты используйте пробел как разделитель параметров.
Кроме параметра WorkDir имеются также параметры HtmlDir и ImageDir. В эти каталоги будут помещены html-файлы и картинки. При определении этих параметров нужно учитывать, что параметр WorkDir имеет приоритет над параметрами HtmlDir и ImageDir и поэтому, если указан параметр WorkDir, mrtg поместит отчеты и картинки именно в этот каталог, а значения параметров HtmlDir и ImageDir будут проигнорированы.
Группа глобальных параметров Options управляет построением изображения. Параметр bits означает, что мы измеряем трафик в битах, поэтому все числа нужно умножить на 8. Второй параметр, growright, указывает направление оси времени. Позже мы рассмотрим все параметры подробнее.
Параметр output программы cfgmaker задает имя конфигурационного файла, который будет создан.
Нужно отметить, что параметры WorkDir и Options являются параметрами программы mrtg, а параметры global и output – параметрами программы cfgmaker.
Параметр community@router указывает имя сообщества SNMP-устройства. В нашем случае – это наш SNMP-маршрутизатор. Обычно используется имя сообщества public. Параметр community@router как раз и является целью, которую мы будем контролировать.
После выполнения этой команды будет сгенерирован такой файл mrtg.cfg.
Имя цели (r1) пишется в квадратных скобках. Для разных целей можно задавать разные параметры, например:
Title[r1]: Traffic Analysis for first interface
Title[r2]: Traffic Analysis for second interface
Параметр MaxBytes определяет максимальное число байт для цели. Значения, превышающие MaxBytes, будут игнорироваться.
Параметр Title определяет заголовок страницы, которая будет содержать информацию о цели, а параметр PageTop – текст, который будет помещен в верхней части этой страницы.
Числа 1 и 2 перед именем сообщества – это номера интерфейсов во внутренней таблице SNMP-устройства. После имени (или IP-адреса) SNMP-устройства можно указать порт SNMP. По умолчанию используется стандартный порт 161.
В качестве цели может быть использована программа, которая выводит на стандартный вывод четыре строки:
- Количество принятых байт.
- Количество отправленных байт.
- Время работы объекта после включения.
- Имя объекта.
Программу нужно записать в обратных кавычках, например:
Очень полезными параметрами являются Refresh и Interval. Первый определяет частоту обновления страниц с отчетами в браузере, а второй – предполагаемый интервал запуска программы MRTG. По умолчанию значения обоих параметров равны 300 секундам. Опции perminute и perhour позволяют измерять трафик в единицах за минуту и час соответственно. Опция noinfo подавляет вывод информации об устройстве и времени его работы. Пример:
Options[_]: bits, perminute, noinfo
Скорее всего, у вас не будет SNMP-маршрутизатора, поскольку в небольших сетях маршрутизатором является сама Linux-машина, а выделение средств на приобретение аппаратного маршрутизатора в ближайшие несколько лет не предвидится. Да и намного интереснее считать трафик своего компьютера, а не какого-то маршрутизатора, которого вы даже и не видели.
Я предлагаю довольно простое решение, настройка которого не займет у вас много времени. Основывается оно вот на чем: как я уже отмечал, вместо цели можно указать программу, которая бы выводила информацию на стандартный вывод в таком формате:
Строка 1 – это входящие байты (принятые), Строка 2 – исходящие байты (отправленные), Строка 3 – время, на протяжении которого работает устройство, Строка 4 – имя цели. Где же взять эту программу? Написать самому! Не буду обременять вас лишними подробностями, которые не относятся к самой MRTG, а больше к программированию сценариев, поэтому рассмотрим готовый листинг программы count.
Листинг 1. Программа count
UPTIME=`/usr/bin/uptime | /bin/awk -F " " "< print $3 >"`
Использовать программу нужно так:
Запустив программу, вы должны увидеть примерно следующие строки:
Во второй строке программы происходит следующее: находится нужная нам запись с именем интерфейса, который мы указали в первом параметре при вызове программы ($1). Затем интерпретатор awk выводит значения первого и девятого полей, содержащие количество принятых и переданных байт.
В третьей строке программы вычисляется время uptime.
Последние две строки выводят время uptime и название интерфейса. Предположим, что у вас имеется два интерфейса: локальный eth0 и выделенная линия (ppp0), идущая к провайдеру.
Теперь узел MRTG сам является маршрутизатором и самостоятельно считает свой трафик. Файл конфигурации mrtg будет выглядеть так, как это показано в листинге 2.
Листинг 2. Файл /var/www/html/mrtg/mrtg.cfg
Target[eth0]: `/usr/bin/count eth0`
Title[eth0]: eth0 Traffic
LegendO[eth0]: eth0 Traffic :
LegendI[eth0]: eth0 Traffic :
Legend1[eth0]: eth1 Traffic in bytes
Target[ppp0]: `/usr/bin/count ppp0`
Title[ppp0]: ppp0 Leased Line
PageTop[ppp0]:ppp0 Leased Line
LegendO[ppp0]: ppp0 Traffic :
LegendI[ppp0]: ppp0 Traffic :
Legend1[ppp0]: ppp0 Traffic in bytes
5,10,15,20,25,30,35,40,45,50,55,59 * * * * root /usr/bin/mrtg /var/www/html/mrtg/mrtg.cfg
0-59/5 * * * * root /usr/bin/mrtg /var/www/html/mrtg/mrtg.cfg
После этого желательно перезапустить демон crond:
Программу mrtg можно запускать в режиме демона (не через crond). Для этого установите значение параметра RunAsDaemon, равное yes. За более подробной информацией обратитесь к документации по mrtg.
Рисунок 1. Статистика для устройства ppp0
Если вы администратор довольно большой сети уровня предприятия, возможно, более удобным решением для вас станет использование программы LAN Billing, которая разработана компанией Network Solutions.
Система LAN Billing предназначена для сбора, преобразования и выдачи информации об IP-трафике. Программа будет полезной интернет-провайдерам, которые хотят вести учет трафика их клиентов, а также директору предприятия, желающего знать, кто из его сотрудников постарался до такой степени, что счет за Интернет увеличился в 2 раза в сравнении с предыдущим месяцем. Кроме того, начальник узнает не только объем переданной и принятой сотрудником информации, а также и узлы, которые сотрудник посещал. Вполне возможно, что сотрудник занимался нужным делом, а может случиться и такое, что подчиненный выкачивал какой-нибудь фильм размером в 800 Мб, и тогда. То, что будет с этим сотрудником, нас не касается, лучше ознакомимся с основными возможностями программы:
- Подсчет трафика по нескольким подсетям.
- Поддержка конфигурации сетей, в которых применяется маскирование (masquerade).
- Детализация данных о трафике с точностью до IP-адреса потребителя и IP-адреса удаленного ресурса, который посещал потребитель за любой промежуток времени.
- Сжатие статистики для минимизации объема хранимой информации и ускорения доступа к ней со стороны управляющего клиента.
- Два клиента для доступа к статистике: веб-клиент, написанный на PHP, и Windows.
- Построение графиков загрузки интернет-канала за отчетный период, а также график распределения нагрузки по сетям и адресам.
- Сбор статистики с NetFlow-совместимых устройств, например маршрутизаторов Cisco Systems.
- Поддержка виртуальных групп (возможность присвоения группе адресов или сетей учетной записи, под полномочиями которой пользователь может просматривать статистику только о трафике своей группы адресов).
- Поддержка контроля доступа для виртуальных групп, в частности прекращение обслуживания по истечении средств на счете клиента.
- сетевого агента;
- сервера статистики;
- управляющего клиента.
Сетевой агент занимается подсчетом трафика, сервер статистики хранит таблицы, содержащие информацию о трафике, а управляющий агент управляет всем этим. Если быть предельно точным, то управляющий клиент не только управляет конфигурацией системы, а еще и создает отчеты об использованном трафике сети.
Сетевой агент может быть двух видов:
- Агент для сетевого адаптера Ethernet (для операционных систем Linux, FreeBSD, NetBSD).
- Сервер для аппаратного маршрутизатора или коммутатора Cisco, поддерживающего протокол NetFlow.
Существует несколько способов интеграции системы LAN Billing в вашу сеть. Вот четыре основных способа:
- Установка системы на Unix-маршрутизатор.
- Установка системы на Unix-маршрутизатор, выполняющий NAT/Masquerade.
- Система устанавливается в сегмент, в котором находится маршрутизатор, и информация о трафике доступна на сетевом уровне.
- Система устанавливается в сегмент, доступный по IP-протоколу (UDP) для NetFlow-совместимого устройства, осуществляющего маршрутизацию.
В первом случае мы выступаем владельцами IP-сети, то есть каждому компьютеру нашей сети назначен реальный IP-адрес. Это самый простой случай.
Второй случай подразумевает под собой наличие одного реального IP-адреса. Естественно, компьютер с настоящим IP-адресом – это маршрутизатор. Все остальные компьютеры получают доступ к Интернету через шлюз с настоящим IP-адресом. Шлюз выполняет NAT (сетевое преобразование адреса), при котором компьютеры нашей сети «думают», что они по-настоящему общаются с узлами Интернета, а последним кажется, что они общаются только с нашим шлюзом. То есть шлюз перезаписывает заголовки IP-пакетов, заменяя фиктивный IP-адрес любого узла нашей сети на свой собственный (реальный адрес) и отправляет пакет в Интернет. Когда пакет приходит обратно, он опять перезаписывает IP-адрес и отправляет его определенному компьютеру нашей сети.
В третьем случае интерфейс маршрутизатора и сервера с установленной системой LAN Billing объединены концентратором.
Мне более близок первый случай, но остановимся на втором, поскольку он более близок к реалии наших дней – не у каждого предприятия есть своя собственная IP-сеть. Программа LAN Billing поставляется в виде пакета RPM, поэтому проблем с ее установкой не возникает.
В дальнейшем будем предполагать, что реальный IP-адрес сервера 193.111.111.1, и что у нас один сегмент сети с фиктивными адресами – 192.168.0.1. Директива serverextip определяет внешний адрес сервера (реальный IP-адрес). Данную директиву нужно использовать, если вы используете NAT, в противном случае, оставьте эту директиву без изменения. Значение по умолчанию – 150.150.150.150.
Директива writemode определяет, какой режим записи данных о трафике мы хотим использовать: db или file. В первом случае мы будем использовать для хранения статистики сервер MySQL, а во втором – данные будут сохраняться в файле. Второй случай нам не интересен, поскольку мы не сможем генерировать отчеты средствами системы LAN Billing, поэтому установите значение db.
Следующая группа директив определяет параметры сервера MySQL: его адрес, имя пользователя, пароль и базу данных.
Директива LogFile определяет месторасположение файла протокола работы системы. Файл, определенный в директиве LogFile будет использоваться, если вы определили режим учета file в директиве writemode.
Директива сегмент описывает наш сегмент сети. В директиве указывается адрес и маска сети. Можно использовать несколько директив – в зависимости от количества сегментов, для которых мы хотим вести учет трафика. При указании маски сети нельзя использовать битовую нотацию (192.168.0.0/24).
С помощью директивы actuality можно указать время, на протяжении которого база данных будет хранить информацию об адресе назначения и сервисах, с которыми соединялись наши пользователи. По умолчанию – 100 часов.
Директива minter определяет время, за которое нужно объединять статистику об однотипном трафике для последующего хранения. По умолчанию – 100 секунд.
Период записи информации о трафике можно определить с помощью директивы flush. По умолчанию – 600 секунд.
Директива fdelay определяет время в секундах после регистрации последнего пакета, когда поток считается завершенным и подлежащим записи в базу данных.
Директива dumpfile задает имя файла, содержащего временную информацию о незавершенных потоках.
Директива device определяет интерфейс, на котором нужно считать трафик. Как правило, нужно считать трафик внешнего интерфейса. Например, если вы подключаетесь к Интернету через интерфейс ppp0 (выделенная линия), а к своей домашней сети через eth0, но вести нужно учет интерфейса ppp0.
Директива ignoremask указывает маску подсети, трафик которой мы будем игнорировать. Эта директива нужна, чтобы мы не считали локальный трафик. При учете пакетов на интерфейсе, подключенном к Интернету, нужно задать маску 255.255.255.255:
Директива ingnorenet определяет сеть, трафик которой должен быть проигнорирован в любом случае. Синтаксис ее такой же, как и синтаксис директивы segment. Можно использовать для нетарифицируемого трафика.
Директивы debug и debugfile относятся к отладке программы. Директивы headers и Disable пользователем (читайте – администратором) не используются. Директивы duser, dgroup используются для определения учетных записей пользователя и группы, под полномочиями которых выполняется сетевой агент Cisco. Директива dport определяет номер порта агента Cisco.
После правки файла конфигурации нужно перезапустить систему. Для этого выполните одну из команд:
killall –HUP nfbcd
killall –HUP nfbccd
Но более корректной будет команда:
Обычно сетевой агент LAN Billing запускается автоматически, но вы можете запустить его вручную с помощью команды:
Остановить агента можно командой:
Теперь можно просмотреть результат нашей работы. Управляющий клиент системы выполнен в виде веб-интерфейса. Для доступа к статистике вы можете использовать любой браузер. В поле ввода адреса браузера введите:
Мы разрабатываем ПО в области телекоммуникаций с 2001 года.
Компания «Сетевые решения» — это решения, проверенные временем.
Контакты
Режим работы
Понедельник – пятница,
с 9:00 до 18:00
Екатерина Цвилева, руководитель отдела PR и маркетинговых коммуникаций Orange BusinessServices в России и СНГ
Среди ключевых критериев в выборе биллинга для нашей компании можно отметить наличие предшествующего положительного опыта сотрудничества с потенциальным контрагентом, опыт успешного внедрения аналогичных проектов, как в России, так и за рубежом, соответствие предлагаемого решения требованиям заказчика (помимо общих требований, важны также требования к производительности, масштабируемости, надежности и составу аппаратной платформы, требования к защите информации от несанкционированного доступа, частные требования к наиболее важным подсистемам), - говорит . – Также важно учитывать планы вендора по развитию системы, численность и квалификацию персонала, который будет обслуживать предлагаемое решение. Несомненно, имеет значение и стоимость проекта внедрения, включая поставку ПО и услуги по внедрению, стоимость и условия технической поддержки за 5 лет, стоимость и условия расширения лицензий, сроки реализации проекта и условия оплаты.
4. Цели обработки персональных данных
4.1. Цель обработки персональных данных Пользователя —информирование Пользователя посредством отправки электронных писем; предоставление доступа Пользователю к сервисам, информации и/или материалам, содержащимся на веб-сайте; информирование Пользователя посредством телефонного звонка.
4.3. Обезличенные данные Пользователей, собираемые с помощью сервисов интернет-статистики, служат для сбора информации о действиях Пользователей на сайте, улучшения качества сайта и его содержания.
Читайте также: