Системы регистрации компьютерных сетей

Содержание

Обеспечение работы системы регистрации и авторизации пользователей сети
Основы документирования сетей
L3 схема
L2 схема
Описание настроек

Обеспечение работы системы регистрации и авторизации пользователей сети

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

Авторизованный субъект доступа — субъект, которому предоставлены соответствующие права доступа к объектам системы (полномочия).

Авторизация пользователей осуществляется с использованием следующих основных механизмов реализации разграничения доступа:

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

• механизмов полномочного управления доступом, основанных на использовании меток конфиденциальности ресурсов и уровней допуска пользователей;

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

Технические средства разграничения доступа к ресурсам АС должны рассматриваться как составная часть единой системы контроля доступа субъектов:

• на контролируемую территорию;

• в отдельные здания и помещения организации;

• к элементам АС и элементам системы защиты информации (физический доступ);

• к информационным и программным ресурсам АС.

Механизмы управления доступом субъектов к объектам доступа выполняют основную роль в обеспечении внутренней безопасности компьютерных систем. Их работа строится на концепции единого диспетчера доступа. Сущность этой концепции состоит в том, что диспетчер доступа (монитор ссылок) — выступает посредником-контролером при всех обращениях субъектов к объектам.

Регистрация NPS-сервера в домене по умолчанию

1. Нажмите кнопку Пуск, выберите Администрирование и щелкните пункт Сервер сетевых политик.

2. Правой кнопкой мыши щелкните Сервер сетевых политик (локальный) и затем выберите пункт Зарегистрировать сервер в ActiveDirectory. Откроется диалоговое окно Сервер сетевых политик.

3. В диалоговом окне Сервер сетевых политик нажмите кнопку OK и затем еще раз нажмите кнопку OK.

Авторизация доступа к сети

Успешное или неудачное прохождение авторизации зависит как от свойств удаленного доступа учетных записей пользователей ActiveDirectory®, так и от политик сети, настроенных на сервере политики сети.

Политики сети позволяют предоставлять или запрещать доступ к сети пользователям или компьютерам, являющимся членами групп Windows, в то время как параметр разрешения доступа к сети в свойствах входящих вызовов учетных записей пользователей в доменных службах ActiveDirectory управляет предоставлением или блокировкой доступа к сети для отдельных пользователей. Кроме того, с помощью доменных служб ActiveDirectory можно указать, что разрешение на доступ к сети будет предоставляться на базе параметров политики сети.

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

Авторизация по пользователям

Если управление авторизацией осуществляется по пользователям, для разрешения на доступ к сети в учетной записи пользователя или компьютера устанавливается значение Разрешение доступа к узлу или Запретить доступ. При желании можно создать разные политики сети для разных типов подключений.

Например, может возникнуть необходимость создать одну политику сети для подключений по виртуальной частной сети (подключений VPN) и другую политику сети – для беспроводных подключений.

Управление авторизацией по отдельным пользователям рекомендуется только в том случае, если число находящихся под управлением учетных записей пользователей или компьютеров невелико.

Если управление авторизацией осуществляется по пользователям, базовый процесс, используемый на сервере политики сети для авторизации запроса на подключение, протекает следующим образом:

· Если сервер политики сети обнаруживает, что запрос на подключение соответствует всем условиям политики сети, он проверяет параметр разрешения на доступ к сети для данной учетной записи пользователя.

· Если параметр разрешения на доступ к сети учетной записи пользователя настроен на предоставление доступа, сервер политики сети применяет к предоставленному подключению эту политику сети и параметры подключения учетной записи пользователя.

· Если параметр разрешения на доступ к сети учетной записи пользователя настроен на запрет доступа, сервер политики сети отклоняет данный запрос на подключение.

· Если запрос на подключение не соответствует всем условиям первой политики сети, сервер политики сети переходит к проверке по следующей политике сети.

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

Авторизация по группам

Если управление авторизацией осуществляется по группам, установите для разрешения доступа к сети в учетной записи пользователя значение Управление доступом на основе политики сети NPS и создайте политики сети, соответствующие разным типам подключения и членству в группах Windows.

Например, может возникнуть необходимость создать одну политику сети для подключений удаленного доступа для сотрудников (членов группы «Сотрудники», созданной в доменных службах ActiveDirectory) и другую политику сети для подключений удаленного доступа для подрядчиков (члены группы «Подрядчики», созданной в доменных службах ActiveDirectory).

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

· Если сервер политики сети обнаруживает, что запрос на подключение соответствует всем условиям политики сети, он проверяет параметр Права доступа данной политики сети.

· Если параметр Права доступа настроен на предоставление доступа, сервер политики сети применяет к предоставленному подключению эту политику сети и параметры подключения учетной записи пользователя.

· Если параметр Права доступа настроен на запрет доступа, сервер политики сети отклоняет данный запрос на подключение.

Содержание отчета

Отчет по практической работе должен содержать следующие пункты:

— название практической работы;

— краткие теоретические сведения;

— индивидуальное задание для выполнения практической работы;

— краткое описание хода выполнения работы;

— результаты выполнения работы;

Источник

Основы документирования сетей

Сразу скажу, что на написание мини статейки об основах документирования для наших подписчиков подтолкнул курс от уже упоминавшегося на канале Netskills. Вся основная механика у них на канале:

На структурную схему наносятся принципиальные моменты дающее полное, но общее представление о том:

Cколько у нас провайдеров;
Как у нас выстроена архитектура ЛВС: внешний периметр, ядро, уровень доступа;
Как обстоит дело с отказоустойчивостью. Каскад устройств, как на картинке firewall и core switch, указывает на то, что используется стек. Вот какой конкретно стек: stack wise, vss с единым control plane или vPC/MCLAG домен с раздельным control plane тут не важно. Аспекты типов стекирования отражаются на схеме L2, в таблице кабельных соединений, а особенности настроек в документе под номером 6 — “Описание настроек”.

Еще раз заостряю внимание. Структурная схема — общая информация. Стеки/кластера и связанные с этим концепции укладываем на L2 схему.

После того как у нас есть “структурка” мы готовим (требуем от подрядчика) L3 схему.

L3 схема

На L3 схеме отображаются ключевые сегменты сети: стыки access-core, core-FW, FWs (border routers) — ISPs. Если описывается корпоративная инфраструктура, то к ключевым сегментам можно отнести сегменты в которых находятся основные корпоративные ресурсы: dns, почта, NTP, VIP пользователи, гостевой и пользовательский Wi-Fi. Если описывается инфраструктура уровня ЦОД, где может быть десятки тысяч сегментов, необходимо ограничится L3 сегментами лишь стыковых соединений. Сегмент удобно изображать в виде трубы с нанесением на нее адреса подсети и соответствующего идентификатора vlan. Целесообразно указывать default gateway. Оборудование уровня L2: L2 коммутаторы, хабы, медиаконвертеры на L3 схеме не изображаются!

После того как имеется структурная схема и L3 переходим к L2 схеме.

L2 схема

L2 схема это уже про частности канального, местами физического уровня. Тут мы уже делаем акцент на типе используемого кабеля: оптика или медь, стековое соединение. Указываем номер порта, тип линка: агрегированный или нет, режим: trunk или access, id vlans в транках (можно и не указывать, так как их может быть слишком много). Конкретные перечни vlan относящихся к информационным системам клиентов, пользователей и то каким транкам они принадлежат лучше всего отражать в документе “Описание настроек”. На схеме же можно/целесообразно отразить факт наличия in-band и out-of-band менеджмента. Т.е. на наличие управляющего трафика посредством основных каналов и альтернативного варианта управления инфраструктурой посредством выделенных каналов, менеджмент коммутаторов, консольных серверов.

Traditional — два standalone коммутатора с наличием петли и работающим STP (стоит избегать таких вариантов архитектур, по возможности. Но в кампусе допускается);

StackWise Virtual-Physical/StackWise Virtual-logical — Два коммутатора представляются Access уровню как один виртуальный. Нет риска петель, не надо беспокоится о STP, нет простоя линков (must have в крупном enterprise и data center)

Вот если говорить не про проект, а про эксплуатацию действующей инфраструктуры, то существует два подхода:

Ведение такой же Exel таблицы. Просто функционально, но есть нюансы. Как правило плодится много копий и по итогу информация зачастую не 100% актуальна. Если документ ведет один человек, то это куда не шло. Если к планированию и учету IP пространства причастны >1, то целесообразно использовать специальные продукты (пункт 2).
Система централизованного учета IP пространства. Есть один бесплатный и удобный продукт под названием phpipam, лично его использую. С этим инструментом планирование и учет IP пространства циклопически упрощается (https://phpipam.net/)

Маркер — идентификатор связи (по аналогии с ключевым полем в БД). В продаже есть специальные принтера. Можно использовать ручные бобины.

Откуда (Ряд/Шкаф/Юнит)-Оборудование-Плата/порт

Куда\Откуда — транзитные (промежуточные) коммутации. Если оконечное оборудование, в нашем примере это блейд корзина HP C7000 подключается портом OA1 (On-board administrator) непосредственно к менеджмент коммутатору Cisco WS-C3750X-24 (Маркер 0051), то блоки Куда\Откуда пустые. А вот если взять маркер 0094, то связь между с7000 и коммутаторами ядра пролегает через промежуточную патч-панель и нетподиум (оптическая СКС);

Куда — собственно так же как и Откуда — Оборудование-Плата/порт. Обычно (в большинстве случаев) Откуда — оконечное оборудование: рабочее место, сервер. Куда — коммутатор. Но если связь отражает межкоммутаторное взаимодействие, кластерное взаимодействие, то слева отражается условный 1-й номер, а справа условный 2-й номер.

Тип разъема: RJ-45, MM/SM LC/MM SC и тд. и тп. По данному столбцу сразу понятно что у вас за физика оптика или медь, какой тип оптики мультимод или синглмод, какой тип оптического разьема.

Количество кусков (патчкордов) и их длина— тут все должно быть понятно.

Кто и когда проводил работы — тоже очень важный момент.

Описание настроек

Совершенно необходимы документ при проектировании/модернизации. В практике я встречал еще такой синоним как пусконаладочные карты. В целом, данные документы про настройки по шагам. В них описывается текущая настройка, какие вносятся изменения и для чего, какой результат ожидается. Когда будет этап пусконаладки если ожидаемый результат получен — успех, нет — разбираемся в чем проблема и уже только устранив которую идем дальше;

Дополнительные документы:

7. Расположение оборудование в стойках > (см. вкладку СКС-2)

Немного поддержу Netskills еще рекламкой:

Если материал понравился — лучшая помощь порекомендовать канал товарищу IT-шнику. Лишними знания не бывают)

Источник