Защо правило за VPN не може да спре качването на един файл
Достъпът до услуга и контролът кои файлове излизат от нея са две отделни изисквания. Поставете правилото там, където файлът е видим: поща, приложение или агент на крайна точка.
Малък екип иска отдалечен достъп до работните си системи и в същия дъх иска определени прикачени файлове да спрат да напускат компанията. И двете молби звучат като една промяна по VPN. Това са две изисквания с различни точки за налагане и правило, което удовлетворява първото, не прави нищо за второто. Започнете с назоваване на действието и данните, после изберете компонента, който наистина може да ги види.
Една молба, две изисквания
Първото изискване е за достижимост: кои потребители и устройства могат да отворят връзка към коя услуга. Второто е за поведението след като тази връзка съществува: кои документи могат да се прикачват, поставят или качват. Тунелът работи върху първото и по замисъл е сляп за второто.
Контрол на ниво IP препраща пакети. Той не анализира качване на части, не проверява PDF и не решава дали една електронна таблица съдържа номера на сметки. Да очаквате това от него не е грешка в конфигурацията; това е категорийна грешка.
Кажете изискването на глас в тази форма, преди да търсите продукт. „Потребителите могат да достигат файловия портал“ и „потребителите не могат да качват списъци с клиенти във файловия портал“ са различни изречения и само второто описва политика за съдържание.
Изберете компонента, който вижда файла
Налагането трябва да се случва там, където файлът е четим. За електронната поща това обикновено е пощенската платформа или шлюзът, които вече обработват прикачени файлове и могат да ги оценят преди доставяне. За качвания през браузър към разрешена услуга самото приложение може да е единствената страна, която вижда съдържанието. За управляван лаптоп, който копира файлове на сменяеми носители, операцията се вижда от агент на крайна точка.
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
Някои търговски пакети за отдалечен достъп обединяват агент на крайна точка, уеб контрол и модул за предотвратяване на изтичане на данни. Тези компоненти може да налагат политика за съдържание, но способността принадлежи на модула, а не на тунелирането. Прочетете какво всъщност включва пакетът, преди да обещаете резултата.
Полезен модел за сравнение е материалът на Microsoft „Преглед на предотвратяването на изтичане на данни в Purview“ : той описва политики чрез типове чувствителна информация, местоположения и дейности. Този речник е за съдържание и действия, не за IP префикси.
TLS преживява тунела, затова планирайте това
Шифроването на приложението се договаря между клиента и услугата и тунелът VPN пренася тези байтове, без да ги отваря. Затова шлюз по пътя не придобива автоматично способност да класифицира прикачен файл, колкото и от маршрута да притежава.
За да проверявате съдържание по пътя, ви е нужен компонент, който прекратява TLS с доверен сертификат, а това е сериозно архитектурно решение със собствени последици за поверителността и експлоатацията. То не е отметка в профила на VPN. Клиентите трябва да се доверят на сертификата за проверка, приложенията, които закрепват сертификати, ще се счупят, а операторът придобива възможност да чете трафик, който преди не е могъл. Това са причините решението да принадлежи на собственик по сигурността, а не на този, който управлява тунела.
Затова честният отговор на въпроса „може ли VPN да блокира това качване“ обикновено е не, последван от конкретна алтернатива. Алтернативата може да е ограничения на ниво приложение, пощенско правило или политика за крайна точка и всяка от тях има собственик, който може да я промени.
Напишете приемливия тест преди правилото
Правилото за съдържание се нуждае от два примера, не от един: разрешено действие, което трябва да продължи да работи, и забранено действие, което трябва да бъде спряно. Тествайте и двете от приложенията и устройствата в обхвата, защото политика, която работи само в един браузър, не е политиката, която някой е поискал.
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/uploadПървата заявка трябва да бъде отказана от компонента, който притежава правилото, а втората трябва да успее. Ако и двете успеят, контролът не е на пътя. Ако и двете се провалят, сте счупили услугата, вместо да я защитите, което е по-честият резултат от правило, написано без разрешен пример.
Решете предварително какво вижда потребителят, кой може да даде изключение и къде администратор потвърждава решението след това. Блокирано качване без съобщение създава тикет в поддръжката, а правило, което никой не може да одитира, създава спор. И двете са избежими с едно изречение документация, написано преди политиката да влезе в сила.
Накрая, дръжте двете изисквания в отделни тикети с отделни собственици. Обединяването им под „VPN“ гарантира, че мрежовият екип ще бъде помолен да реши проблем със съдържание и че проблемът със съдържанието ще бъде обявен за решен, когато тунелът се вдигне.