В продолжении ряда статей про Информатизацию ВУЗа предлагаю вашему вниманию статью про одну из основных задач, которую необходимо решить в ВУЗе – это предоставление пользователю доступа в сеть Интернет. Я попытаюсь разобрать необходимый стек ПО, архитектуру построения инфраструктуры и правовые аспекты. Мои статьи — это больше диалог, поэтому призываю обмениваться опытом в комментариях – делитесь опытом, давайте сделаем IT в госсекторе немного лучше…

Словарь терминов:

  • АУП – административно-управленческий персонал – все пользователи, кроме ППС.

  • ППС – профессорско-преподавательский персонал.

  • ПДн – персональные данные.

  • студень - студент))

Но на самом деле это не одна задача – а как минимум 3:

  1. Предоставление доступа в сеть Интернет пользователям АУПа и ППС.

  2. Предоставление доступа в сеть Интернет студентам в компьютерных классах для студней.

  3. Предоставление доступа в Интернет гостям ВУЗа и студентам в общежитиях и корпусах учреждения по Wi-Fi.

Но сначала рассмотрим, как решить 1 и 2 задачу….
Определимся с тем, что нужно для осуществления этой задачи – определим стек ПО.

Во-первых, необходимо хранить учетные записи пользователей и учетные записи для компьютерных классов. Для этого необходима централизованная система по управлению идентификацией пользователей: это либо AD от Microsoft, либо FreeIPA. Сейчас остановимся на первом, как на самом распространенном варианте, но здесь обязательно появится статья в рамках темы импортозамещения и перехода на какой-нибудь отечественный аналог, хотя, если я правильно понимаю, то все российские LDAP-системы реализованы на основе FreeIPA.

Мы разделяем учетки для пользователей и учетки для компьютерных классов, так как существует много отличий между ними, как при построении архитектуры, так и в законодательных аспектах, и, кроме того, зачем делать из домена помойку всех возможных учеток и всех возможных конфигураций. Я пытаюсь придерживаться принципа единственной ответственности (srp) – да, это принцип для программирования, но он будет очень полезен и для системных администраторов, так как если на один сервер возложить много функций, то это создаст целый клубок проблем, когда он выйдет из строя, поэтому один сервис – один сервер (хотя бы приближенно к этому). Плюс такого подхода заключается в том, что при выходе из строя определенного сервиса, вы затронете только один сервер (естественно виртуальный), остальное продолжит работать. Также это помогает при делегировании обязанностей сотрудникам – отдали сначала один сервис – один сервер, потом второй и т.д.

Во-вторых, нам необходим механизм документооборота, который должен реализовывать следующие бизнес-процессы:

  • сбор заявок от пользователей,

  • обработка заявок от пользователей,

  • хранение и учет заявок.

Такой функционал можно реализовать в любой системе документооборота, но лучше автоматизировать данный процесс и создать отдельную систему для автоматизации обработки заявок – но это отдельная большая тема – напишите в комментариях есть ли такие системы, какой у Вас опыт в этом вопросе?

У многих до сих пор данные бизнес-процессы реализуются через бумажные «служебки» и хранятся в специальном журнале, как в древнем Риме… Не так ли?))) Но здесь не все так просто, потому как нужно соблюдать правовые нормы при предоставлении пользователю доступа в Интернет. Если будет интересно я напишу небольшую статью на эту тему, с примером как это все можно организовать.

В-третьих, необходимо ПО – межсетевой экран (NGFW или UTM), которое бы обладало следующим функционалом:

  • предоставление доступа пользователям к сети Интернет,

  • интеграция с AD,

  • контролирование доступа пользователей к сети Интернет,

  • фильтрация контента,

  • биллинг траффика пользователя

Итак, вот логическая схема стека ПО, необходимого для организации предоставления пользователю доступа в сеть Интернет

Стек ПО
Стек ПО

На российском рынке представлено несколько решений МЭ и вот неполный список (напишите в комментариях что используете вы):

  1. Traffic Inspector

  2. ИКС

  3. Ideco

  4. UserGate

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

Еще советую использовать только свои сервера, не идти на поводу таких решений как сторонние прокси-сервера – так как в один миг вы лишаетесь гибкости в настройке всего этого дела и открыть порт или разрешить какой-нибудь адрес может стать большой проблемой, а на своем сервере вы будете полностью контролировать весь цикл.

Опыт работы был с первыми тремя, но наш выбор пал на ИКС – по нескольким причинам:

  1. он был одним из самых дешевых решений,

  2. основан на FreeBSD (решения, устанавливаемые на Windows, не рассматриваем -  ну не серьезно, да и импортозамещение выглядит половинчатым в этом случае) и, конечно, FreeBSD это огромный плюс!!!

  3. полностью устраивал по функционалу

Хотя в самом начале это был не самый лучший продукт (но в те времена – все были в начале пути и плюс минус одного уровня, и выделить кого-то было бы ошибкой…), но надо отдать ИКСу должное за эти годы их команда действительно развивала и улучшала продукт, и он стал хорошим решением. Мы с ними работаем уже лет 6, перешли на ИКС с Microsoft Forefront. Переход был быстрым, ИКС оказался удобней и понятней. Команда ИКСа хорошо потрудилась, поэтому большой респект и можно им пожелать только удачи на просторах российского IT.

Но сразу спущу Вас с небес – идеального решения нет (во-первых, идеальность у каждого своя…) – я имею ввиду идеально работающего решения вы не найдете, поэтому постарайтесь вникнуть в продукт и понять, как он работает, так как здесь существует много нюансов. А еще больше необходимо вникнуть в законодательство, которое необходимо соблюдать. Лучше всего будет, если Вы сможете собрать свой NGFW на основе открытого ПО, а потом встав на грабли российского законодательства, выберете путь импортозамещения, поняв, как такие продукты работают внутри. Большинство решений работают как прокси, то есть ловят трафик на 80 и 443 портах и применяют к ним какие-либо правила (разрешающие либо запрещающие), но так как современные сайты сейчас – это зачастую сложные web-приложения со множеством внедренных технологий, то некоторые из них некорректно работают при использовании прокси, поэтому придется вести список исключений прокси.

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

  • техническую поддержку, которая поможет 24/7,

  • приятную систему отчетов по биллингу,

  • протестированные обновления,

  • дружелюбный веб-интерфейс,

  • все необходимые сертификаты (Минцифры, ФСТЭК и т.д.),

  • соблюдение всех российских правовых норм.

И в конце концов, вы поддерживаете развитие российского IT. И кроме того у системного администратора и так хватает "геморроя", помимо сборки NGFW из Open source с соблюдением российского законодательства, особенно списка экстремистских материалов от Минюста.

Рассмотрим вариант, когда ИКС используется в качестве явного прокси-сервера – то есть прокси прописывается в браузере в явном виде – без использования какого-либо приложения – это делается групповыми политиками – чем меньше софта на ПК пользователя ставится вручную, тем лучше и удобнее в организации работы в IT-отделах и построении инфраструктуры.

явное прописывание прокси
явное прописывание прокси

Предлагаю рассмотреть две конфигурации.

Первая реализована на принципе единственной ответственности (один сервис – один сервер). Здесь ИКС используем только в качестве прокси. Пограничный шлюз аппаратный, как и промежуточный.

Таким образом получаем разделение функционала:

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

  • Прокси отвечает только за проксированный траффик (tcp 80 и 443);

  • Промежуточный шлюз отвечает за трафик пользователей, направленный мимо прокси;

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

Дам уточнение по промежуточному шлюзу – он должен уметь создавать разрешающие и запрещающие правила на основе fqdn – то есть по url, если данного функционала нет, то вас ждет увлекательная работа по выяснению всех возможных ip, которые соответствуют url-у, который необходимо пустить мимо прокси….

Но для более простого примера разберем второй вариант без промежуточного шлюза, тогда промежуточным шлюзом будет выступать ИКС.

У нас будет один лес – vuz.local, и два домена:

  • vuz.local

  • classes.vuz.local;

один dhcp сервер и несколько прокси серверов:

  1. для АУПа и ППС – 192.168.200.10

  2. для компьютерных классов – 192.168.200.11

domen-01.vuz.local – 192.168.200.1 основной КД домена vuz.local (DNS).
domen-02.vuz.local – 192.168.200.2 второй КД домена vuz.local (DNS).

DHCP сервер раздает следующую динамику:
ip-адреса в диапазоне от 192.168.200.30 - 192.168.200.200
шлюз – 192.168.200.10 – ИКС будет и прокси-сервером и шлюзом
dns1: 192.168.200.1
dns2: 192.168.200.2

Рассматривать установку ИКС и интеграцию с AD здесь не буду – я подготовил ролик, в котором с нуля начал строить всю описанную инфраструктуру – создание AD, установка ИКС и интеграция с AD, да и инструкции на сайте ИКС тоже хорошего качества – изучайте там ничего сложного.

Настройку ИКС и AD с помощью групповых политик опишу в следующей статье

Давайте поговорим о тех проблемах, с которыми мы столкнулись.

Первая самая частая проблема – некоторые сайты не работают с прокси. В этом случае этот сайт вносится в исключения прокси в браузере на ПК пользователя (через групповые политики) – следовательно он теперь не будет перенаправляться на прокси-сервер – теперь он будет обрабатываться шлюзом сетевой карты компьютера и соответственно, необходимо открыть доступ к этому сайту на этом шлюзе – будь то ИКС либо какой-нибудь другой маршрутизатор.

Аналогичная проблема с некоторым софтом, который использует кроме 80 и 443 какие-нибудь другие tcp или udp порты – их тоже необходимо открывать на шлюзе. Поэтому придется вести реестр открытых сайтов и портов.

Вторая самая частая проблема – отсутствие свободного места на разделе из-за сбора статистики по пользователям. Для ее решения необходимо добавить еще один диск и настроить его в качестве раздела для статистики – в видео это показано. Но опять же возникает вопрос сколько хранить логи и на основании чего – напишите в комментариях если есть инфа по этому поводу. Мы поставили отметку в 6 месяцев и выделили под это 500ГБ, у нас 800 пользователей (100-200 онлайн) – скорее всего лучше выделить 1 Тб.  Но чтобы более-менее быстро сбекапить виртуальную машину такого размера необходимо улучшить скорость ЛВС между гипервизором и хранилищем для бекапов виртуальных машин (как вариант - можно бекапить виртуалку только с одним диском – без диска, на котором статистика).

Третья самая частая проблема – потеря контроллера домена, она происходит при выключении КД и включении ИКС до включения КД. КД выключается зачастую после отключения электроэнергии.

Мы предприняли следующее решение: необходимо чтобы КД выключался как можно реже, поэтому хостовый сервер нужно запитать от самого мощного ИБП, чтобы он выдержал как минимум часа три - это цифра взята по опыту – это максимальный срок отсутствия электроэнергии в нашем учреждении. Остальные виртуалки можно тушить после 2-3 минут после пропадания электричества. Но в любом случае всегда необходимо сначала включать AD, а уже потом всю остальную инфраструктуру.

Данная проблема может появляться из-за пропадания ЛВС – здесь зачастую это связано с неправильной архитектурой в построении сети либо с некорректной работой сетевого оборудования…

При возникновении данной проблемы необходимо повторно ввести ИКС в домен, если он сам не подцепляет домен.

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

МЭ должен соответствовать российскому законодательству и быть отечественным. Зачастую разворачивается аппаратное решение со ФСТЭКовским сертификатом. Но это большой вопрос, пишите в комментариях кто в теме -  нужен ли ФСТЭК или нет?

Я считаю, что виртуальная машина (не ФСТЭК) для этих целей подойдет больше – ее легче и быстрее развернуть, сбекапить, восстановить.

Немного теории о ФСТЭК…. Глаз еще не дергается??? секунду…

Класс МЭ определяется ФСТЭКом. Выбор класса МЭ для организации берется в соответствии с уровнем защищённости ПДн организации по приказу ФСТЭК №21. Уровень защищённости ПДн организации определяется политикой информационной безопасности организации, составленной по методикам ФСТЭК и ФСБ. Таким образом, можно сделать вывод, что необходимо использовать ФСТЭКовские версии межсетевых экранов. Но не спешите, давайте еще немного поразмышляем…

Требования к некриптографическим средствам защиты информации
Требования к некриптографическим средствам защиты информации

Теперь вопрос: Какой правовой акт заставляет использовать именно ФСТЭКовские версии??? Напишите в комментариях кто в теме.

Что не так со ФСТЭКовскими версиями: берется определенная версия ПО и начинается сертификация, пока сертификация закончится уже выйдет несколько новых версий и в результате потребитель получает ФСТЭКовскую, но уже старую версию ПО. Да в ней скорее всего есть какие-то отличия от НЕ ФСТЭКовской версии, хотя это дополнительная нагрузка для разработчиков – вести две ветки одного и того же ПО – ФСТЭКовскую и НЕ ФСТЭКовскую. Процесс довольно сложный и запутанный, поэтому необходимо уточнять у разработчика ПО: есть ли сертификат ФСТЭК, какая версия, когда будет свежая ФСТЭКовская версия.

Но, ВНИМАНИЕ, защищать-то нужно только персональные данные…. Получается если траффик, который будет идти через МЭ -  есть результат обработки персональных данных, то нужно это все дело защитить и использовать ФСТЭКовскую версию, а ежели нет, то зачем… то можно использовать НЕ ФСТЭКовскую версию….  Поэтому можно взять не ФСТЭКовскую версию для организации доступа в Интернет всех пользователей, а ФСТЭКовскую только для тех url, где будет производиться обработка персональных данных – то есть придется вести список исключений. Данный вариант будет дешевле.

Разделение траффика
Разделение траффика

Теперь пройдемся по законам, которые необходимо соблюдать при предоставлении доступа в сеть Интернет.

149-ФЗ «Об информации, информационных технологиях и о защите информации»

Ключевые моменты закона:

  1. Нельзя собирать и распространять информацию о жизни человека без его согласия.

  2. Все информационные технологии равнозначны — нельзя обязать компанию использовать какие-то конкретные технологии для создания информационной системы.

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

  4. Некоторую информацию распространять запрещено, например, ту, которая пропагандирует насилие или нетерпимость.

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

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

  7. Владелец заблокированного сайта может удалить незаконную информацию и сообщить об этом в Роскомнадзор — тогда его сайт разблокируют.

В рамках предоставления доступа в сеть Интернет нас интересует, то чтобы пользователь ознакомился с этим законом при оформлении заявки на доступ в сеть Интернет, расписался за ознакомление и соответственно ничего плохого не делал в сети Интернет с ПК организации – пункты 1 и 4.

Но нас еще интересует пункт 6 – необходимо блокировать ресурсы, которые находятся в реестре Роскомнадзора. Для этих целей есть сервис SkyDNS, а у ИКС есть конфигурация, включающая SkyDNS в ИКС. Но вот в чем вопрос - данный пункт скорее всего касается провайдеров и это они должны позаботиться о блокировке данного списка. Если это так, то данный пункт можно включить в договор с провайдером и ничего не включать у обычных пользователей, хотя SkyDNS лучше бы включить… Но … ЕСТЬ БОЛЬШОЕ НО)) давайте взглянем на следующий закон.

436-ФЗ «О защите детей от информации, причиняющей вред их здоровью и развитию»

Вы спросите какие дети… Первокурсники, многим нет 18 лет, значит их необходимо защищать и тут уже не только блокировка сайтов из реестра Роскомнадзора, но и соблюдать следующее условие – у детей не должно быть доступа к информации, которая определена списком Минюста. Для этого существует технология, которая называется контент-фильтр – программное обеспечение для фильтрации сайтов по их содержимому, не позволяющее получить доступ к определённым сайтам или услугам сети Интернет. У ИКС он есть и фильтрация происходит по следующим наборам слов:

  • список слов с сайта Минюста,

  • список слов сайта Госнаркоконтроля

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

В результате включения этой технологии вы получаете очень странный Интернет, и Вам приходится увеличивать список открытых сайтов – потому как многие сайты будут не открываться по причине наличия там какого-нибудь запрещенного слова, даже в скрытых тегах…

Вот почему нужен отдельный домен для компьютерных классов. А вот что делать с учетками на этом домене – это еще та песня… Есть два пути.

Сложный путь – заводим учетку каждого студента (а их 10 000…), и каким-то образом создаем механизм, при котором вычисляется есть студенту 18 или нет: и в результате должен применяется контент-фильтр или нет. Так как ИКС синхронизирует пользователей AD по подразделениям, то значит на AD должно быть условно два подразделения «18 лет» и «дети». Затем у вас должны быть списки студентов, которым меньше 18 лет и скрипт, который перебором сравнивает список студентов и пользователей и при совпадении перемещает пользователя в подразделение «дети». Но если честно – это утопия и очень сложно реализуемая технология, особенно если студентов больше 10 000. Если кто сумел это сделать поделитесь в комментариях буду очень благодарен.

Проще сделать так – на каждый компьютерный класс создаем учетки по количеству компьютеров в классе: st100-01 –  st100-20. И предполагаем, что в данном компьютерном классе могут работать под этими учетками как дети, так и взрослые – и, следовательно, включаем контент фильтр для всех. Тоже самое применяется и к компьютерному классу в библиотеке.

Соблюдать это обязательно надо, ибо придет проверка и накажет ВУЗ. Я считаю, вопрос явно недоработан, и очень жду, когда законотворцы все-таки сделают что-то более удобное и понятное.

152-ФЗ «О персональных данных»

Ознакомлявшем пользователей и с этим законом, но только тех, кто работает с ПД.

187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»

Здесь нас интересует та информация, что если ВУЗ признали критической инфраструктурой (КИ), то необходимо внедрить ГосСопку – железный сервер, который будет следить за всем вашим трафиком и сообщать вам об атаках и уязвимостях. Еще та песня для отдела ИБ, но есть и польза – вас будут уведомлять об атаках в автоматическом режиме… Хотя вроде бы сейчас ГосСопку ставят многим даже тем, кого не признали КИ.

Еще одно уточнение – на всех шлюзах вам необходимо использовать в качестве ДНС – НСДИ (Национальная Система Доменных Имен) — это отечественная инфраструктура, которая дублирует действующую схему доменных имён, отвечающую за маршруты прохождения трафика. Проще говоря, согласно задумке российских властей, благодаря НСДИ отечественные ресурсы не пострадают при отключении национального сегмента интернета от глобальной Сети, тогда как у российских пользователей сохранится доступ к ним.

Вроде бы как понимал так донес… вопрос действительно не простой и за полезные комментарии буду очень благодарен – подправлю статью, использовав полезные комментарии. Думал получится коротко, но вопрос очень обширен.

P.S. (ну и немного анархии и добра - это поможет во всем этом разобраться):

Люди, добрые люди
Пусть наш мир добром
Добром прибудет!

Комментарии (1)