Por que unha regra de VPN non pode impedir a subida dun ficheiro
Chegar a un servizo e controlar que ficheiros saen del son dous requisitos. Pon a regra onde o ficheiro é visible: correo, aplicación ou axente de punto final.
Un equipo pequeno pide acceso remoto aos seus sistemas de traballo e, na mesma respiración, pide que certos anexos deixen de saír da empresa. As dúas peticións soan como un só cambio de VPN. Son dous requisitos con puntos de aplicación distintos, e unha regra que satisface o primeiro non fai nada polo segundo. Comeza por nomear a acción e os datos, e logo escolle o compoñente que realmente pode velos.
Unha petición, dous requisitos
O primeiro requisito trata da accesibilidade: que usuarios e dispositivos poden abrir unha conexión a que servizo. O segundo trata do comportamento unha vez que existe esa conexión: que documentos se poden adxuntar, pegar ou subir. Un túnel actúa sobre o primeiro e é cego ao segundo por deseño.
Un control a nivel de IP reenvía paquetes. Non analiza unha subida multiparte, non inspecciona un PDF nin decide se unha folla de cálculo contén números de conta. Esperar que o faga non é un erro de configuración; é un erro de categoría.
Di o requisito en voz alta con esa forma antes de buscar un produto. «Os usuarios poden chegar ao portal de ficheiros» e «os usuarios non poden subir listas de clientes ao portal de ficheiros» son frases distintas, e só a segunda describe unha política de contido.
Escolle o compoñente que pode ver o ficheiro
A aplicación ten que ocorrer onde o ficheiro é lexible. Para o correo, adoita ser a plataforma ou a pasarela de correo, que xa xestiona os anexos e pode avalialos antes da entrega. Para as subidas desde o navegador a un servizo autorizado, a propia aplicación pode ser a única parte que ve o contido. Para un portátil xestionado que copia ficheiros a medios extraíbles, un axente de punto final ve a operación.
| 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 |
Algúns paquetes comerciais de acceso remoto xuntan un axente de punto final, un control web e un módulo de prevención de perda de datos. Eses compoñentes poden aplicar políticas de contido, pero a capacidade pertence ao módulo e non ao túnel. Le o que inclúe realmente o paquete antes de prometer o resultado.
A visión xeral da prevención de perda de datos de Purview de Microsoft é un modelo útil para comparar: describe as políticas en termos de tipos de información sensible, localizacións e actividades. Ese vocabulario trata de contido e accións, non de prefixos IP.
TLS sobrevive ao túnel, así que planifícao
O cifrado da aplicación négociase entre o cliente e o servizo, e un túnel VPN transporta eses bytes sen abrilos. Por iso unha pasarela no camiño non adquire automaticamente a capacidade de clasificar un anexo, por moita parte da ruta que posúa.
Para inspeccionar contido en tránsito cómpre un compoñente que remate TLS cun certificado de confianza, o que é unha decisión arquitectónica importante coas súas propias consecuencias de privacidade e operativas. Non é unha caixa de verificación do perfil de VPN. Os clientes teñen que confiar no certificado de inspección, as aplicacións que fixan certificados romperán e o operador gaña a capacidade de ler tráfico que antes non podía. Esas son as razóns polas que esta decisión pertence a un responsable de seguridade e non a quen opera o túnel.
Por iso a resposta honesta a «pode a VPN bloquear esta subida» adoita ser non, seguida dunha alternativa concreta. A alternativa pode ser restricións a nivel de aplicación, unha regra de correo ou unha política de punto final, e cada unha ten un responsable que a pode cambiar.
Escribe a proba de aceptación antes da regra
Unha regra de contido necesita dous exemplos, non un: unha acción permitida que debe seguir funcionando e unha acción prohibida que debe deterse. Proba ambas desde as aplicacións e dispositivos do alcance, porque unha política que só funciona nun navegador non é a política que se pediu.
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/uploadO compoñente que posúe a regra debería rexeitar a primeira petición, e a segunda debería ter éxito. Se ambas teñen éxito, o control non está no camiño. Se ambas fallan, rompeches o servizo en lugar de protexelo, que é o resultado máis habitual dunha regra escrita sen un exemplo permitido.
Decide de antemán que ve o usuario, quen pode conceder unha excepción e onde un administrador confirma a decisión despois. Unha subida bloqueada sen mensaxe xera un tícket de soporte, e unha regra que ninguén pode auditar xera unha discusión. Ambas as dúas cousas se poden evitar cunha frase de documentación escrita antes de que a política entre en vigor.
Por último, mantén os dous requisitos en tíckets separados con responsables separados. Agrupalos baixo «VPN» garante que se pedirá ao equipo de rede que resolva un problema de contido e que o problema de contido se declarará resolvido cando o túnel estea levantado.