Как работает виртуальная частная сеть (VPN)

Виртуальная частная сеть (VPN) строит зашифрованный канал между устройством сотрудника и корпоративной сетью, чтобы трафик нельзя было перехватить на пути через публичный интернет. Работает такая схема на протоколах IPsec, IKEv2 или WireGuard: они берут обычный пакет данных, упаковывают его в защищенную оболочку и гонят по незащищенным каналам. Для сотрудника все выглядит максимально просто — открыл ноутбук, подключился и работаешь с CRM или файловым сервером так, будто сидишь в офисе.

Традиционная модель подразумевает установку VPN-шлюза на физическом оборудовании внутри офисного периметра. Облачная альтернатива в виде услуги Cloud VPN переносит эту функцию в инфраструктуру провайдера. Шлюз разворачивается на виртуальных мощностях дата-центра и предоставляется компании как услуга. Далее мы разберем механику работы Cloud VPN, сравним архитектурные варианты развертывания и покажем, как интеграция с облачной платформой сокращает время запуска защищенного доступа.

Как работает VPN

В основе любой виртуальной частной сети лежит идея тоннеля. VPN создает зашифрованный канал, внутри которого трафик движется в полной изоляции от остального интернета. Технически процесс выглядит так:

• На устройстве пользователя устанавливается VPN-клиент
• Когда сотрудник нажимает кнопку «Подключиться», клиент и VPN-сервер обмениваются ключами шифрования и договариваются о параметрах защищенного канала
• После этого клиент берет каждый уходящий пакет данных, шифрует его и упаковывает в новый пакет, адресованный VPN-серверу
• Внешний наблюдатель видит только факт передачи данных от клиента к серверу, но не их содержимое
• Сервер на своей стороне расшифровывает исходные данные и направляет их в корпоративную сеть
• Ответный трафик проходит тот же путь в обратном направлении

За шифрование отвечают специализированные протоколы. Самые распространенные сегодня — IPsec, IKEv2 и WireGuard. У каждого из них своя ниша, но общая задача одна — превратить открытый текст в нечитаемый шифр на всем маршруте следования.

• IPsec работает на сетевом уровне и шифрует абсолютно весь трафик, независимо от того, какое приложение его генерирует. Это надежный, проверенный десятилетиями стандарт, но его настройка требует определенной квалификации.
• IKEv2 развивает идеи IPsec, добавляя лучшую поддержку мобильных устройств: соединение не рвется при переключении с Wi-Fi на мобильный интернет и обратно.
• WireGuard — протокол с минималистичной кодовой базой, который дает высокую скорость и простоту конфигурации.

Классический VPN vs Cloud VPN: в чем разница

Классический VPN строится вокруг физического оборудования (шлюза), расположенного в офисе компании. Сотрудники подключаются к этому шлюзу, и он пропускает их трафик в локальную сеть. Архитектура рабочая, но у нее есть ограничения:

• Пропускная способность офисного интернет-канала делится между всеми удаленными пользователями — чем их больше, тем медленнее работает каждый;
• Само железо со временем устаревает и требует замены;
• Если в офисе пропадает электричество или отваливается интернет-провайдер, удаленная команда мгновенно теряет доступ ко всем рабочим ресурсам.

Cloud VPN решает эти проблемы, вынося VPN-шлюз за пределы офиса, в облачную инфраструктуру провайдера. Шлюз работает на виртуальных машинах в дата-центре, подключенном к магистральным каналам связи с многократным резервированием. Сотрудник подключается не к офисному роутеру, а к облачному шлюзу, который уже маршрутизирует трафик в корпоративную сеть — будь то серверы в том же облаке, арендованные мощности или оставшаяся в офисе инфраструктура.

Ключевые отличия Cloud VPN от классической схемы сводятся к следующему:

• Масштабирование. Добавление новых пользователей не требует апгрейда железа. Шлюз работает на виртуальных мощностях, производительность которых наращивается в несколько кликов. Нужно больше одновременных подключений — выделили больше vCPU и оперативной памяти, и шлюз держит нагрузку без просадок.
• Отказоустойчивость. Шлюз не привязан к одной физической точке. В случае аварии в дата-центре нагрузку подхватывает резервный узел. Для пользователя это выглядит как кратковременный обрыв соединения.
• Администрирование. Настройка и обновление выполняются централизованно через веб-интерфейс или API облачного провайдера. Системный администратор управляет доступом удаленно и не привязан к офису.
• Географическая близость к пользователю. Крупные облачные провайдеры располагают дата-центрами в разных регионах, поэтому компания может разместить VPN-шлюз ближе к филиалу или распределенной команде и тем самым снизить задержки.

Технически Cloud VPN внутри облака работает как один из компонентов виртуальной частной сети — VPC. Помимо самого шлюза, в VPC входят виртуальные серверы, базы данных и объектные хранилища, объединенные в изолированный сетевой контур. VPN-шлюз открывает в этот контур управляемый вход для сотрудников, работающих извне. Схема получается сквозной: устройство пользователя — зашифрованный тоннель — облачный шлюз — корпоративные сервисы внутри VPC — и обратно. Такая архитектура не просто защищает данные на этапе передачи, но и упрощает управление всей инфраструктурой, делая ее единой, обозримой и предсказуемой.

Что дает Cloud VPN бизнесу

Когда часть команды сидит в офисе, часть по домам, а серверы работают в облаке, классический периметр безопасности, привязанный к офисному роутеру, перестает существовать. Задача облачного VPN — создать единый защищенный контур и дать каждому сотруднику ту же степень защищенного доступа, как если бы он физически подключился к локальной сети компании, и при этом неважно, откуда идет подключение.

Отсюда вытекают конкретные задачи, которые сервис закрывает на практике:

• Безопасная передача данных через публичные сети. Когда удаленный сотрудник заходит в рабочую почту с планшета, подключенного к Wi-Fi в торговом центре, VPN-тоннель шифрует трафик и исключает возможность перехвата паролей, коммерческой информации или клиентской базы злоумышленником, сидящим в той же точке доступа.
• Разграничение прав доступа. Облачный шлюз позволяет гибко настроить, кто из сотрудников видит какие сегменты сети: разработчики подключаются к тестовым стендам, бухгалтерия — к 1С, продавцы — к CRM, а подрядчикам открыт доступ строго к одному файловому серверу без пересечения с остальной инфраструктурой.
• Централизованный контроль и аудит. Весь трафик удаленных пользователей проходит через единый шлюз, поэтому администратор видит историю подключений, может оперативно отозвать доступ уволенному сотруднику и выявить подозрительную активность на раннем этапе.

Выгода для бизнеса

Переход на облачную архитектуру меняет экономику и эксплуатацию VPN. Вместо капитальных затрат на железо появляется предсказуемая ежемесячная плата, которая меняется в зависимости от нагрузки. Подключили десять новых сотрудников — подняли тариф, летом половина ушла в отпуска — снизили. При этом компания не покупает оборудование и не думает о его замене через несколько лет.

Скорость развертывания — второй ощутимый результат. Поднять физический сервер в офисе и настроить на нем VPN-шлюз — это закупка, доставка, монтаж и часы работы системного администратора. Облачный шлюз разворачивается за несколько минут: выбрали конфигурацию, загрузили сертификаты, настроили правила межсетевого экрана. Добавление нового пользователя сводится к выпуску конфигурационного файла или сертификата, который сотрудник импортирует к себе в клиент за пару кликов.

Третий аргумент — отказоустойчивость, заложенная на уровне архитектуры. Физическое оборудование в офисе становится единой точкой отказа: скачок напряжения, авария провайдера, перегрев — и вся удаленная команда теряет доступ к рабочим инструментам. Облачный шлюз работает в кластере распределенных дата-центров с резервированием, поэтому выход из строя одного узла не обрушивает весь сервис. Для бизнеса это означает простой не на часы, а на минуты или полное его отсутствие.

Наконец, Cloud VPN упрощает соответствие отраслевым стандартам и требованиям регуляторов. Компании, работающие с персональными данными, финансовой информацией или подпадающие под PCI DSS, обязаны:

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

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

Выгода для сотрудников

Для конечного пользователя главное преимущество от внедрения Cloud VPN заключается в простоте и скорости подключения. Сотруднику не нужно разбираться в протоколах, сетевых настройках или вручную прописывать IP-адреса серверов. Процесс выглядит так:

• Сотрудник получает готовый клиентский конфиг от администратора;
• Устанавливает приложение на ноутбук или смартфон;
• Входит по корпоративному логину;
• Через несколько секунд видит все рабочие ресурсы;
• Дальше все происходит автоматически: нажал кнопку подключения — и работаешь.

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

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

Виды VPN для бизнеса

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

Удаленный доступ (Client-to-Site)

Самый массовый сценарий — подключение отдельных сотрудников к корпоративной сети. На устройство пользователя устанавливается VPN-клиент, который поднимает зашифрованный тоннель до шлюза компании.

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

Ключевые особенности Client-to-Site:

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

Этот тип VPN — базовый инструмент для компаний с удаленными сотрудниками, фрилансерами на проектной работе или иногородними филиалами, у которых нет собственного офиса с выделенным каналом.

Точка-точка (Site-to-Site)

Если Client-to-Site соединяет пользователя с сетью, то Site-to-Site соединяет две сети между собой. Это постоянный зашифрованный канал между двумя статичными точками — например, между офисом в Астане и офисом в Алматы, между штаб-квартирой и дата-центром или между локальной инфраструктурой компании и ее облачной средой.

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

Основные характеристики Site-to-Site:

• Соединение постоянное. Тоннель не разрывается после завершения сессии — он работает непрерывно, пока работают оба шлюза.
• Объединяет целые подсети. Задача не в том, чтобы подключить конкретного пользователя, а в том, чтобы срастить две локальные сети в единое адресное пространство.
• Требует статичных IP-адресов. Оба шлюза должны быть доступны друг для друга по фиксированным адресам, иначе соединение не установится.

Этот тип VPN востребован в компаниях с несколькими физическими офисами для объединения телефонии, общих файловых хранилищ и внутренних порталов. Кроме этого, таким способом соединяют собственную инфраструктуру к облачным ресурсам, когда часть серверов остается на площадке заказчика, а часть переносится к провайдеру.

Облачные VPN-сервисы (Cloud VPN)

Cloud VPN объединяет возможности удаленного доступа и Site-to-Site, но шлюз при этом работает не на оборудовании заказчика, а в инфраструктуре провайдера и предоставляется как услуга с подпиской.

Как мы уже говорили, облачный VPN-сервис — это часть виртуальной частной сети (VPC), изолированного сетевого контура. VPN-шлюз становится контролируемой точкой входа в этот контур. В отличие от классического развертывания, где администратор настраивает оборудование вручную, здесь шлюз разворачивается из панели управления или через API за несколько минут.

Ключевые особенности Cloud VPN:

• Готовый сервис. Заказчик не покупает оборудование и не администрирует операционную систему шлюза — провайдер берет на себя обновления, отказоустойчивость и мониторинг доступности.
• Гибридные сценарии из коробки. Облачный шлюз одновременно обслуживает подключения удаленных сотрудников по Client-to-Site и держит постоянный тоннель Site-to-Site до офисной инфраструктуры, если компания сохранила серверы на своей площадке.
• Автоматическое масштабирование. Производительность шлюза наращивается изменением тарифа или конфигурации виртуальной машины без замены железа и выезда специалиста на площадку.
• Централизованное управление. Все настройки, сертификаты, правила файрвола и списки пользователей управляются через единый веб-интерфейс или API, доступный администратору из любой точки.

На практике компания, выбравшая Cloud VPN, получает оба сценария в одном сервисе. Удаленные сотрудники подключаются к облачному шлюзу со своих устройств через клиент — это классический Client-to-Site. А если в офисе остался сервер с 1С или файловое хранилище, облачный шлюз связывается с офисным роутером постоянным Site-to-Site-тоннелем. В результате все участники оказываются в едином адресном пространстве, хотя физически разнесены по разным городам и сетям.

Как внедрить Cloud VPN

Внедрение Cloud VPN не требует глубокой перестройки текущей инфраструктуры, но выигрыш от сервиса напрямую зависит от того, насколько осмысленно компания подойдет к подготовке. Хаотичная настройка без инвентаризации ресурсов и плана по разграничению доступа приводит к тому, что VPN работает, но пользователи жалуются на скорость, а безопасники — на уязвимости в периметре. Ниже разберем пять шагов, которые превращают внедрение в управляемый процесс.

Подготовка и аудит

Сначала нужно понять, что именно вы подключаете к VPN и в каких объемах. Без этого ответить на вопрос «какой мощности нужен шлюз» не получится. Администратору или ответственному за инфраструктуру нужно провести инвентаризацию по двум направлениям.

1. Ресурсы, к которым требуется доступ

Составляется список корпоративных сервисов, с которыми будут работать удаленные сотрудники. Это могут быть:

• внутренние веб-приложения — CRM, ERP, системы документооборота;
• файловые серверы и сетевые хранилища;
• базы данных — 1С, PostgreSQL, MS SQL;
• тестовые стенды для разработчиков;
• корпоративная телефония и видеоконференции, если они развернуты на своих серверах.

Каждый сервис фиксируется с указанием IP-адресов, портов и требований к полосе пропускания. Это понадобится на этапе настройки правил файрвола и расчета нагрузки.

2. Пользователи и их профили.

Определяется количество удаленных сотрудников и их роли. Одна группа — разработчики, которым нужен доступ к Git-репозиториям и тестовым серверам. Другая — бухгалтерия, работающая только с 1С и банк-клиентом. Третья — менеджеры, которым достаточно CRM и файлового сервера. Для каждой группы настраиваются свои политики доступа.

Отдельный момент — аудит текущего интернет-канала, если в офисе остаются серверы, к которым облачный шлюз будет подключаться по Site-to-Site. Пропускной способности канала должно хватать на одновременную работу всех удаленных пользователей с учетом того, что часть трафика пойдет через тоннель.

Выбор архитектуры и провайдера

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

Расположение шлюза

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

Тип подключения офиса

Если в офисе компании остались серверы, которые пока не перенесены в облако, планируется Site-to-Site тоннель между облачным шлюзом и офисным маршрутизатором. Здесь важно убедиться, что офисный роутер поддерживает IPsec или другой выбранный протокол.

Вот по каким критериям можно выбрать облачного провайдера:

• Поддержка современных протоколов. Минимальный набор — IPsec и WireGuard. WireGuard предпочтителен для мобильных устройств и высокоскоростных подключений, IPsec — для совместимости с офисным оборудованием.
• SLA по доступности. В документе должно быть зафиксировано гарантированное время работы сервиса с четкими цифрами, а не общими формулировками.
• Инструменты мониторинга. Провайдер должен предоставлять графики нагрузки, счетчики подключений и оповещения о попытках неавторизованного входа.
• Возможность быстрого масштабирования. Проверьте, можно ли изменить конфигурацию шлюза без миграции на другую виртуальную машину — увеличением vCPU и памяти через панель управления или API.
• Интеграция с VPC. Если вы планируете развивать облачную инфраструктуру дальше, VPN-шлюз должен легко связываться с виртуальными сетями провайдера.

Интеграция и настройка

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

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

Большинство провайдеров предлагают выбрать между IPsec/IKEv2 и WireGuard протоколом. Принципиальный момент: WireGuard быстрее и проще в настройке, но некоторые корпоративные политики безопасности пока требуют использовать IPsec из-за его более долгой истории аудита. После выбора протокола настраиваются параметры шифрования и генерируются ключи.

Далее следует ключевой этап с точки зрения безопасности, настройка маршрутизации и правил файрвола. Администратор определяет:

• Какие подсети и IP-адреса доступны через VPN. Например, 10.0.1.0/24 — офисная сеть, 10.0.2.0/24 — облачная VPC.
• Какие группы пользователей имеют доступ к каким подсетям. Разработчикам открыт доступ только к тестовому сегменту, бухгалтерии — к серверу 1С, администраторам — ко всей сети.
• Какие порты и протоколы разрешены внутри тоннеля. Например, RDP для удаленного рабочего стола открыт, а SSH в продуктовую среду — только для выделенной группы инженеров.

Параллельно настраивается интеграция с корпоративной системой аутентификации — Active Directory, LDAP или облачным Identity Provider. Это избавит от необходимости заводить отдельные учетные записи специально для VPN: сотрудник использует тот же логин и пароль, что и для входа в корпоративную почту.

Подключение сотрудников и управление доступом

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

Для каждого пользователя или группы создаются конфигурационные файлы, содержащие все необходимые параметры: адрес шлюза, ключи шифрования, назначаемый IP-адрес. При использовании IPsec вместо конфигурационных файлов могут выпускаться клиентские сертификаты. Файлы распространяются через корпоративную почту или внутренний портал с привязкой к учетной записи сотрудника.

Сотруднику остается только установить VPN-клиент, импортировать конфигурационный файл и войти под корпоративной учетной записью. Администратор через панель управления может в любой момент:

• Добавить нового пользователя. Выпустить новый сертификат или конфиг за пару минут;
• Отозвать доступ. При увольнении сотрудника сертификат отзывается, а учетная запись блокируется в Active Directory, что автоматически разрывает все активные сессии;
• Изменить права группы. Если отделу открыли доступ к новому серверу, правило файрвола обновляется централизованно, пользователям не нужно менять настройки на своих устройствах.

Мониторинг и эксплуатация

После запуска Cloud VPN основные задачи — наблюдение за состоянием сервиса и своевременное реагирование на инциденты.

Рекомендуем отслеживать:

• Количество одновременных подключений и загрузка шлюза. Чтобы вовремя заметить приближение к лимитам производительности.
• Полоса пропускания. Рост трафика может сигнализировать о том, что сотрудники начали использовать новые сервисы, и конфигурацию шлюза пора расширять.
• Попытки неавторизованного доступа. Повторяющиеся неудачные попытки входа могут указывать на подбор пароля или скомпрометированный сертификат.
• Доступность шлюза. Время отклика и аптайм, чтобы убедиться, что SLA соблюдается.

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

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

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

Заключение

Виртуальная частная сеть помогает построить защищенный канал между устройствами сотрудников и корпоративными сервисами, маскируя трафик от внешнего наблюдателя. Если классический VPN привязан к офисному оборудованию и наследует все его ограничения, то облачная модель выносит шлюз в дата-центр провайдера и превращает защищенный доступ в управляемый сервис. Компания получает зашифрованные тоннели по протоколам IPsec или WireGuard, гибкое разграничение прав, автоматическое масштабирование под растущее число пользователей и отказоустойчивость, заложенную на уровне архитектуры.

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

Частые вопросы

1. Чем Cloud VPN отличается от обычного VPN-клиента?

Классические VPN-клиенты решают задачу анонимности или обхода географических ограничений, но не подходят для корпоративной среды. У них нет централизованного управления доступом: администратор не может гибко настроить, кто из сотрудников к каким серверам подключается, и не видит историю подключений. Кроме того, публичные сервисы не дают гарантий по скорости и доступности, а их инфраструктура непрозрачна — вы не знаете, через какие узлы проходит трафик и кто имеет к нему доступ. Cloud VPN, в отличие от них, разворачивается под задачи конкретной компании, интегрируется с корпоративной системой аутентификации и предоставляет понятные метрики для мониторинга и аудита.

2. Какой протокол выбрать?

Выбор зависит от приоритетов компании и текущего парка устройств. WireGuard быстрее и проще в настройке: его кодовая база в десятки раз меньше, чем у IPsec, что снижает вероятность ошибок и упрощает аудит безопасности. Он хорошо показывает себя на мобильных устройствах и при частых переключениях между сетями. IPsec, в свою очередь, поддерживается практически любым сетевым оборудованием — от офисных роутеров до промышленных шлюзов, — и имеет более долгую историю использования в корпоративной среде.

3. Что произойдет с доступом, если облачный шлюз выйдет из строя?

Отказоустойчивость закладывается на уровне архитектуры облачного провайдера. Шлюз работает не на единственном физическом сервере, а в кластере распределенных дата-центров. При выходе из строя одного узла его нагрузку автоматически подхватывает соседний. Для пользователя это выражается в кратковременном перерыве соединения. Обычно не более нескольких минут, пока клиентское приложение переподключается к резервному шлюзу.

4. Сколько времени занимает внедрение Cloud VPN с нуля?

При продуманном подходе весь процесс, от аудита текущей инфраструктуры до полноценного запуска сервиса, укладывается в один-два рабочих дня. Основное время занимает не техническая настройка, а подготовительный этап: инвентаризация ресурсов, определение групп пользователей и их прав доступа, выбор конфигурации шлюза.