Маленькие компании обычно не начинают с архитектуры доступа. Они начинаются с практической проблемы: кому-то нужно работать из дома, путешествовать с ноутбуком, подключиться к Wi-Fi в отеле или получить доступ к общему ресурсу, не раскрывая при этом слишком много информации.
Именно здесь в разговор часто вступает VPN. Он знаком, понятен и полезен для многих узких задач удаленной работы и обеспечения конфиденциальности. SASE, сокращение от Secure Access Service Edge, происходит из другого места. Это более широкая модель, сочетающая в себе сетевые функции и функции безопасности, обычно предназначенная для организаций, которым необходимы средства управления с учетом идентификационных данных, централизованная политика, проверка и более зрелый способ управления распределенными пользователями и приложениями.
Таким образом, настоящий вопрос о VPN и SASE заключается не в том, «какой из них лучше?» Вопрос в следующем: какая проблема доступа на самом деле существует у вашей компании?
Краткая версия: VPN решает проблему подключения, SASE решает архитектуру доступа
VPN создает зашифрованный путь соединения между устройством пользователя и сервером или сетью VPN. Для небольшой команды этого может быть достаточно, если основной целью является простое подключение или более частный маршрут в ненадежных сетях.
SASE больше. Он объединяет элементы управления сетью и безопасностью в облачную архитектуру. В зависимости от среды обсуждения SASE могут включать такие понятия, как доступ с учетом идентификационных данных, безопасные веб-шлюзы, контроль доступа к облаку, брандмауэр как услуга, программно-определяемые сети и принципы zero-trust.
Для небольшой компании это различие имеет значение, поскольку это разные операционные модели:
- VPN обычно легче понять и развернуть для простых случаев использования.
- SASE обычно подходит компаниям, которым требуется более детальный контроль над тем, кто может получить доступ к каким приложениям, с каких устройств и при каких условиях.
- VPN может быть практичным слоем для отдельных лиц и небольших команд.
- SASE ближе к программе долгосрочного доступа и безопасности, чем к отдельному инструменту.
Если вашей компании требуется только простое зашифрованное соединение для путешествий, удаленной работы или обеспечения базовой конфиденциальности, VPN может быть подходящим выбором. Если ваша команда растет, ваши приложения разбросаны по SaaS и частным системам, а доступ к широкой сети становится неудобным, возможно, пришло время подумать не только о VPN.
Когда простого VPN может быть достаточно
Простой VPN может иметь смысл, когда шаблон доступа узок и риск легко понять.
Например, основателю, консультанту, руководителю агентства или небольшой удаленной команде может потребоваться более безопасное подключение к общедоступной сети Wi-Fi, постоянный зашифрованный маршрут во время путешествия или базовый способ подключения через сервер VPN. В этом контексте целью не является создание архитектуры безопасности предприятия. Цель состоит в том, чтобы уменьшить воздействие в распространенных ситуациях и обеспечить управляемость удаленного доступа.
VPN, скорее всего, будет достаточно, если:
- удаленный доступ нужен лишь небольшому количеству людей;
- пользователям доверяют, а роли просты;
- компания не использует много конфиденциальных внутренних приложений;
- основная потребность заключается в шифрованном подключении, а не в применении политики для каждого приложения;
- нет выделенной команды безопасности для управления сложной архитектурой;
- требования соответствия ограничены или решаются где-то еще;
- бизнес может терпеть более простую административную модель.
Именно здесь такой продукт, как VPN Unlimited by KeepSolid, может быть полезен в качестве простого варианта VPN для пользователей и небольших команд, которым требуется зашифрованное соединение VPN для повседневного подключения и сценариев обеспечения конфиденциальности.
Это не делает VPN полным ответом на все проблемы безопасности. VPN не создает автоматически управление идентификацией, проверки состояния устройства, рабочие процессы аудита, сегментацию на уровне приложения или применение политики zero-trust. Если это те проблемы, которые вам нужно решить, разговор перешел к модели более широкого доступа.
Когда проблема доступа переросла VPN
Стремление к взрослению обычно проявляется постепенно. На первых порах удаленный доступ необходим одному-двум людям. Тогда подрядчикам нужен доступ. Затем команда добавляет инструменты SaaS, частные приложения, общие панели администратора, финансовые системы, данные клиентов и личные устройства. В какой-то момент предоставление широкого доступа к сети всем, кто подключается через VPN, начинает казаться слишком грубым.
В этом случае безопасность удаленного доступа будет меньше зависеть от туннеля, а больше от контроля.
Признаки того, что вашей компании может потребоваться более широкая архитектура, включают в себя:
- разным ролям нужен доступ к разным приложениям или данным;
- подрядчики должны охватить только одну систему, а не всю сеть;
- конфиденциальные ресурсы требуют более строгого утверждения, мониторинга или сегментации;
- сотрудники используют как управляемые, так и неуправляемые устройства;
- Приложения SaaS и частные приложения являются частью повседневной работы;
- учетные записи администратора требуют более строгого обращения, чем обычные учетные записи пользователей;
- компания начинает сталкиваться с проверками безопасности клиентов или вопросами соответствия;
- Устранение неполадок доступа становится затруднительным, поскольку политики действуют во многих местах.
В этой среде вопрос больше не звучит так: «Есть ли у нас VPN?» Вопрос звучит так: «Можем ли мы принимать решения о доступе на основе пользователя, роли, ресурса, устройства и риска?»
Это территория, где архитектура SASE и идеи zero-trust становятся полезными.
Что SASE добавляет к решению
SASE — это не просто более быстрый или дорогой VPN. Это архитектурный шаблон, позволяющий сблизить сетевое подключение и средства управления безопасностью, часто с помощью облачных сервисов.
В одобренном исходном материале SASE рассматривается как способ объединения сетевых функций и функций безопасности для распределенных пользователей, удаленных мест и облачных сервисов. На практике это означает, что SASE обычно обсуждается, когда компании нужно нечто большее, чем просто зашифрованный путь. Ему необходимы политика, проверка, сегментация и централизованное управление пользователями и ресурсами.
Для небольшой компании самый полезный вывод — это не список корпоративных сокращений. Вот это:
Если все, кто подключатся, должны достичь примерно одного и того же, VPN может остаться работоспособным. Если доступ должен быть разным для каждой роли, приложения, устройства и уровня риска, мышление SASE становится более актуальным.
Это не означает, что небольшая компания должна торопиться со сложным проектом. SASE может потребовать планирования, эксплуатации, оценки поставщиков, обучения пользователей и постоянного управления. Компания, не имеющая возможности использовать эти средства контроля, может создать путаницу быстрее, чем создать безопасность.
Лучшим подходом будет рассматривать SASE как направление погашения. Поймите, для решения каких задач он предназначен, а затем решите, оправдывают ли текущие риски доступа дополнительную сложность.
Где подходит Zero Trust
Нулевое доверие часто упоминается рядом с SASE, но оно не должно брать верх в этом обсуждении. Для небольших компаний наиболее практичной частью zero trust является переход от широкого доверия к решениям, ориентированным на ресурсы.
Вместо того, чтобы спрашивать: «Этот человек в сети?» подход zero-trust задает более точные вопросы:
- Кто пользователь?
- К какому ресурсу они пытаются добраться?
- Требует ли этого их роль?
- Приемлемо ли устройство для данного ресурса?
- Стоит ли разрешить сеанс сейчас?
- Должен ли доступ быть ограничен, проверен или отозван?
В этом суть удаленного доступа zero trust: доступ не предоставляется только потому, что кто-то подключен. Он оценивается вокруг пользователя, ресурса и контекста.
Руководство NIST zero-trust здесь особенно полезно, поскольку оно описывает zero trust как архитектуру и путь миграции, а не как продукт, запускаемый одним щелчком мыши. Небольшие компании могут использовать этот подход, не делая вид, что у них уже есть полностью зрелая корпоративная программа.
Наименьшие привилегии — это практический тест
Фраза «доступ с наименьшими привилегиями» звучит технически, но идея проста: люди должны получать минимальный доступ, необходимый им для выполнения своей работы, до тех пор, пока он им нужен.
Часто это самый простой способ решить, достаточно ли VPN.
Спросите:
- Если член команды подключается через VPN, сможет ли он увидеть больше, чем ему нужно?
- Может ли подрядчик получить доступ только к одному приложению, для использования которого его наняли?
- Отделены ли системы финансов, администрирования, исходного кода или клиентских данных от обычного доступа?
- Может ли доступ быстро измениться, когда кто-то меняет роли или уходит?
- Знаете ли вы, какие учетные записи могут получить доступ к конфиденциальным ресурсам?
Если на эти вопросы легко ответить, а ваша среда небольшая, VPN может подойти. Если эти вопросы обнаружат пробелы, возможно, вашей модели удаленного доступа потребуется доработать.
Схема принятия решений для малых компаний
Используйте эту основу, прежде чем выбирать направление.
1. Составьте список ресурсов, которые нужны людям
Не начинайте с инструментов. Начните с ресурсов.
Запишите приложения, системы, файлы, панели администратора, базы данных и общие службы, к которым люди должны иметь удаленный доступ. Отделите повседневные инструменты от чувствительных систем. Простое решение VPN становится намного яснее, когда вы знаете, что на самом деле стоит за запросом доступа.
2. Сопоставьте пользователей с ролями
Компании из пяти человек, возможно, не нужна сложная ролевая структура, но ей все равно необходимы базовые границы. Владельцы, сотрудники, подрядчики, финансовые пользователи и технические администраторы обычно не должны иметь одинаковый охват.
Если роли простые и стабильные, доступа VPN-based может быть достаточно. Если роли непостоянны, временны или сильно различаются, вам может потребоваться более строгий контроль политики.
3. Проверьте, создает ли широкий доступ к сети риск, которого можно избежать.
Традиционный VPN может быть очень полезен, но широкий доступ на уровне сети может оказаться слишком широким для некоторых сред. Если подключенный пользователь может получить доступ к системам, не связанным с его работой, это проблема проектирования, а не просто проблема обучения пользователей.
Модели SASE и zero-trust пытаются уменьшить это неявное доверие, сосредоточив внимание на ресурсах и политике. Небольшим компаниям не нужно копировать корпоративную архитектуру в одночасье, но им следует заметить, когда широкий доступ больше не соответствует бизнесу.
4. Посмотрите на управление устройством
Контроль устройства меняет ответ. Компания с управляемыми ноутбуками, обязательными обновлениями и четким владением имеет другой профиль риска, чем компания, сотрудники и подрядчики которой используют личные устройства.
Если доверие к устройству имеет значение для ваших конфиденциальных приложений, базовый VPN сам по себе может не ответить на достаточное количество вопросов.
5. Будьте честны в отношении полномочий администратора
Сложные элементы управления требуют осторожности. Политике нужны владельцы. Исключения требуют рассмотрения. Пользователям нужна поддержка. Журналы и оповещения нуждаются в том, чтобы кто-то их читал.
Если ни у кого нет времени на эксплуатацию более крупной архитектуры, компании может быть лучше использовать простую, хорошо понятную структуру, пока она документирует риски и готовится к следующему этапу.
6. Отделите сегодняшние потребности от следующего этапа зрелости.
Вам не придется решать все будущие проблемы с доступом в этом месяце. Небольшая группа может использовать VPN для текущих нужд, а также подготовить более чистый список доступа, карту ролей и список конфиденциальных ресурсов.
Такая подготовка делает более поздние проекты SASE или zero-trust менее хаотичными.
Практический способ подумать о безопасном удаленном доступе
Безопасный удаленный доступ — это не одна категория продуктов с одним постоянным ответом. Это набор вариантов того, как люди получают доступ к рабочим ресурсам за пределами офиса или доверенной сети.
Для небольшой компании разумный прогресс может выглядеть так:
- Начните с необходимости доступа: кому что нужно, откуда и почему.
- Используйте VPN, когда требуется простое зашифрованное соединение или конфиденциальность для небольшой доверенной группы.
- Добавляйте более четкие правила для конфиденциальных ресурсов по мере роста команды.
- Следите за признаками того, что широкий доступ создает риск или накладные расходы на поддержку.
- Рассмотрите архитектуру SASE, когда идентификация, политика, контроль на уровне приложений, проверка и эксплуатационная зрелость становятся настоящей проблемой.
Важная часть заключается в том, чтобы не покупать сложность до того, как вы сможете ею управлять, а также избегать настройки, которая дает людям больше доступа, чем требуется для их работы.
VPN против SASE: быстрое сравнение для небольших компаний
| Вопрос | VPN может подойти, если… | Архитектура SASE может подойти, когда… |
|---|---|---|
| Основная цель | Вам необходимо зашифрованное соединение или частный маршрут для распространенных сценариев удаленной работы и поездок. | Вам нужна централизованная политика доступа для всех пользователей, приложений, местоположений и уровней риска. |
| Размер команды | Команда небольшая, а потребности в доступе одинаковы. | Команда растет, распределяется или включает в себя подрядчиков и несколько ролей. |
| Чувствительность ресурсов | Лишь немногие внутренние ресурсы являются высокочувствительными или сегментированными. | Конфиденциальные приложения, системы администрирования, данные клиентов или регулируемые рабочие процессы требуют более жесткого контроля. |
| Модель доступа | Широкий доступ приемлем для текущего уровня риска. | Пользователи должны обращаться только к определенным приложениям или ресурсам. |
| Операции | Вам нужно что-то понятное и более простое в управлении. | У вас есть возможность управлять политиками, исключениями, мониторингом и поддержкой пользователей. |
| Путь зрелости | Сейчас вы решаете узкую проблему подключения/конфиденциальности. | Вы строите долгосрочную архитектуру доступа. |
Распространенные ошибки, которых следует избегать
Рассматриваем SASE как просто «VPN, но новее»
SASE — это не просто новая этикетка VPN. Это более широкая архитектура. Если поставщик или внутренняя дискуссия звучит как прямой обмен мнениями один на один, замедлите темп и сначала определите реальные проблемы доступа.
Ожидается, что VPN выполнит любую работу по обеспечению безопасности
VPN может быть полезен, но его не следует просить заменить политику идентификации, управление устройствами, разрешения приложений, мониторинг, отстранение персонала или сегментацию конфиденциальных ресурсов.
Покупка архитектуры до того, как компания сможет ею управлять
Программы SASE требуют владения. Небольшой компании не следует применять сложную модель доступа, не зная, кто будет управлять политиками, поддерживать пользователей, проверять исключения и поддерживать актуальность настроек.
Игнорирование простого варианта использования
Некоторым командам действительно нужен простой VPN. Если текущая потребность ограничена, поверхность доступа ограничена и команда понимает настройку, VPN все равно может быть практическим выбором.
Часто задаваемые вопросы
Всегда ли SASE лучше, чем VPN?
Нет. SASE шире, чем VPN, но шире не означает автоматически лучше для каждой небольшой компании. Если вам нужно простое зашифрованное соединение для небольшой группы, VPN может быть достаточно. Если ваши потребности в доступе включают правила, учитывающие личность, контроль на уровне приложений, несколько ролей пользователей, проверку и централизованную политику, возможно, стоит оценить архитектуру SASE.
Означает ли zero trust отсутствие VPN?
Не обязательно. Нулевое доверие — это архитектурный подход, направленный на снижение неявного доверия и принятие решений о доступе к пользователям, ресурсам и контексту. Некоторые организации модернизируют доступ поэтапно. Полезный вопрос заключается не в том, существует ли VPN, а в том, ограничен ли доступ тем, что действительно нужно каждому пользователю и роли.
Стоит ли небольшой компании начинать с SASE?
Только если проблема доступа оправдывает это и компания может им управлять. Многим небольшим компаниям следует сначала документировать пользователей, ресурсы, конфиденциальные системы, контроль устройств и границы ролей. Эта работа проясняет, достаточно ли простого VPN или необходима более широкая архитектура.
В чем самый большой риск полагаться только на VPN?
Основная опасность заключается не в слове «VPN». Это слишком широкий доступ. Если подключение через VPN дает пользователям больше возможностей, чем требует их работа, компании может потребоваться лучшая сегментация, разрешения на основе ролей и контроль на уровне ресурсов.
Что нам следует сделать, прежде чем что-либо менять?
Сделайте инвентаризацию доступа. Составьте список пользователей, ролей, устройств, приложений, конфиденциальных ресурсов и текущих путей удаленного доступа. Затем решите, является ли проблема простым подключением или более широкой проблемой контроля доступа.
Итог
Решение о VPN против Sase на самом деле является решением зрелости.
Используйте VPN, когда компании требуется простое зашифрованное соединение для узкого и управляемого варианта использования. Начните думать о SASE, когда компании нужна политика идентификации, контроль на уровне приложений, проверка безопасности и более организованный способ управления доступом между пользователями, устройствами и ресурсами.
Для небольших компаний лучшим ответом обычно является тот, который соответствует текущему риску и способности команды им управлять. Сохраняйте простоту настройки, если проблема проста. Планируйте более широкую архитектуру, когда удаленный доступ становится проблемой политики, ресурсов и операций.