Привяжите офисный доступ к личности, а не к порту коммутатора
Сегментация, допуск и авторизация сервисов — разные задачи. Три условия решают, превосходит ли доступ на основе личности VLAN на порт.
На столе два проекта. Один держит сотрудников в VLAN на основе ролей и правит порты коммутатора, когда люди переезжают. Другой аутентифицирует сеанс и позволяет политике решать, куда можно добраться. Выбор не про современность; он про то, выполняются ли три условия в вашем здании. Если хотя бы одно не выполняется, проект на основе портов не глуп, это тот, который вы действительно можете эксплуатировать.
Три условия — это обеспеченность исполнения, качество личности и поведение при сбое.
Условие 1: могут ли устройства доступа исполнить возвращённую политику
802.1X — это связь между запрашивающей стороной на конечной точке, аутентификатором в коммутаторе или точке доступа и сервером аутентификации, доступным по RADIUS. Сервер может вернуть VLAN или другой результат политики, и RFC 3580 описывает эту сигнализацию. Коммутатор всё равно должен реализовать результат, на который вы полагаетесь.
Просите возможность, а не протокол: динамическое назначение VLAN, загружаемые ACL или перенаправление на портал регистрации.
Условие 2: авторитетен ли источник личности и быстро ли меняется
Членство в группе в каталоге помогает только если это то поле, которое бизнес уже редактирует при смене роли. Если назначение ролей живёт в таблице, которая ежемесячно копируется в группы, доступ на основе личности просто автоматизирует устаревшие данные. Проверьте и задержку, потому что новый сотрудник, который не может работать целый день, — худший результат, чем ручная смена порта. Аутентификация устройства, аутентификация пользователя и обе вместе — отдельные выборы, а принтерам нужна явная модель, а не необъяснимый обход.
Запишите сопоставление: какая группа даёт какую политику и кто может её изменить.
Условие 3: определите поведение при сбое до пилота
У каждого внедрения есть неаутентифицированное состояние и состояние недоступности сервера, и политика для обоих — решение по безопасности. Тихий откат в доверенный сегмент уничтожает проект; жёсткий сбой блокирует работу во время перерыва. Обычная середина — ограниченный сегмент с доступом только в интернет и ясный путь к службе поддержки. Проверьте откат на реальном коммутаторе или беспроводной платформе, потому что заводские значения поставщиков различаются.
Если никто не может описать откат одним предложением, проект не завершён.
Где место VPN
VPN аутентифицирует доступ через недоверенный путь, и требовать его также в офисной LAN может быть осознанным решением о доверии. Он не отменяет потребность в сопоставлении групп или в собственной авторизации файлового сервера. Он также добавляет пропускную способность шлюза, клиентское программное обеспечение и управление сеансами к операционной нагрузке.
VPN, купленный чтобы избежать правки VLAN, решил не ту проблему и добавил две новые.
Таблица и одна вещь, которую стоит сохранить
| Condition | Holds? | Design |
|---|---|---|
| Devices enforce returned policy | Yes | 802.1X with dynamic policy, stable segments |
| Devices cannot enforce it | No | Keep segments, add an application gateway |
| Identity source lags role changes | No | Fix provisioning before admission |
| No acceptable unauthenticated state | No | Restricted segment with a portal |
| Departures must lose access quickly | Yes | Dynamic disconnect plus credential revocation |
Сохраните сегменты для серверов, гостей, устройств и операционных технологий. Эти границы про трафик, а не про должности, и они переживают любую реорганизацию. Поместите права сотрудников в политику личности, где смена роли — одна правка, и используйте поддерживаемый механизм отключения, когда удаление должно быть быстрым.
Проверка проекта — это переезд стола: он должен переместить человека и его оборудование, а не перестроить его разрешения вокруг другого разъёма.