Una de las características del mundo de la tecnología es que no falta la jerga; o, los acrónimos. Por suerte, si eligen los correctos, suelen ser bastante útiles.
Últimamente, se habla mucho sobre las arquitecturas “Zero-Trust” (ZT). La premisa es que no se deberá confiar en ninguna transacción de datos, independientemente de cuál sea su origen. Además, dentro de cada transacción, deberá haber una prueba de propiedad.
Los métodos de impresión tienden a ignorarse dentro de esta área de “cero confianza” (zero trust), debido probablemente a que, en un principio, la impresión era un fenómeno local que se consideraba “aislado” de los problemas de seguridad de las redes. Sin embargo, hace tiempo que la impresión forma parte del esquema de la red… aunque la ignorancia sobre seguridad se mantiene latente. En esta área, hemos observado vulnerabilidades recientes con el potencial de causar verdaderos problemas de seguridad en plataformas Windows. Confío en que organizaciones de todo el mundo hayan tomado las medidas necesarias para mitigar el riesgo de dichas vulnerabilidades, y espero que, al hacerlo, estas mismas organizaciones ahora comprendan la necesidad de hacer seguros sus entornos de impresión, así como de implementar redes de Zero Trust.
Los documentos impresos son una forma más de exponer datos. Además, una vez impresos, no hay manera de controlar los datos que hayan sido expuestos. Por lo tanto, es sumamente importante comprobar quién intenta imprimir datos, así como verificar qué datos dicha persona intenta imprimir.
Hasta hace poco, las empresas tomaban medidas para asegurar el control del dispositivo local. Por ejemplo, yo debo ingresar en mi ordenador para escribir este artículo de blog. Además, debo comunicarme con Office 365 a través de mi identidad de red corporativa para utilizar Word. Si quisiera guardar el documento en mi red corporativa, las credenciales que lo permiten se transferirían desde el login de mi ordenador, que tiene la autoridad para hacer esto, así como muchas otras cosas. No obstante, si me alejo de mi ordenador y olvido bloquear la pantalla, una persona sin escrúpulos podría acercarse, acceder a los datos en mi nombre, imprimirlos y desaparecer con el botín. En mi caso, eso no es un gran problema porque tengo muy poco acceso a información importante. Sin embargo, ¿qué ocurriría si yo fuera médico u otro tipo de proveedor de servicios sanitarios? O, ¿si tuviera acceso a información competitiva sensible? Entonces, podría ser un problema.
Impresión BYOD en un entorno de Zero Trust
Ahora bien, enmarquemos todo esto dentro de un mundo de “zero trust”. En dicho mundo, puedo (y a menudo lo hago) llevar conmigo un dispositivo que yo poseo y mantengo. Este planteamiento se conoce comúnmente como “Trae tu propio dispositivo” o BYOD. A la empresa no le preocupa mi ordenador, por lo que quizás puedo ingresar en mi PC como un administrador. En el mundo de “zero trust”, eso no importa. La idea es que los sistemas de seguridad me permitan hacer mi trabajo a través de Internet de forma que pueda trabajar igual desde mi domicilio, desde mi cafetería favorita o desde mi lugar de trabajo. Esto también significa que la conexión a Internet que me es proporcionada en mi lugar de trabajo no necesita ofrecer seguridad basada en el usuario, ya que no puedo establecer confianza simplemente por estar presente en la red.
Para hacer mi trabajo, yo ingreso en un recurso seguro, por lo general, algún tipo de sitio web cifrado o entorno de aplicación virtual. Todos los datos que fluyen a través del hilo están cifrados, por lo que conectar con el Internet abierto no representa ningún problema.
En un entorno de aplicación virtual, la impresión se suele controlar internamente o, a veces, ni siquiera se permite. La necesidad de imprimir sigue existiendo en muchas circunstancias, por lo que se requiere una verificación de tiempo de impresión. Eso se consigue permitiendo a los usuarios definir dispositivos de impresión empleando un mecanismo que está fuera del sistema operativo.
La clave es capturar la impresión en el momento de iniciarse. Una vez capturada, pueden ocurrir varias cosas. En primer lugar, Vd. puede determinar si hay una ID de usuario válida asociada con la impresión. Aquí, he pinchado “Imprimir” en mi pantalla de MS-Word y he seleccionado una impresora:
Observen que me pide que ingrese. Este es un punto clave. Incluso si estoy ingresado en el PC como un Admin, al igual que en el ejemplo anterior, debo proporcionar mis credenciales corporativas para imprimir. Vean también que esta autenticación se realiza a través de un navegador (pero de eso hablaremos más tarde). Yo añado mis credenciales corporativas e ingreso.
En este punto, he ingresado, por lo que mi ID de usuario, guy.tucker@lrs.com, está asociada con imprimir. Buen primer paso. ¿Cuál es el siguiente? Ahora, puedo ver políticas de impresión que quizás yo haya configurado para controlar muchas cosas. Algunas podrían ser cuestiones simples, tales como si la empresa está dispuesta a cubrir el coste de imprimir a color, o quizás algo más relacionado con la cuestión de si YO DEBERÍA imprimir ese documento. Estas políticas pueden interrogar al usuario, registrar el intento de imprimir, y bien bloquear la impresión o permitirle al usuario invalidar la solicitud.
Estos son solo unos pocos ejemplos; la capacidad total es mucho más amplia. Además, se puede implementar impresión segura (Secure Print). Yo he ingresado con mi identidad corporativa, por lo que ahora puedo enviar los datos a una cola de impresión personal donde se retendrán. A continuación, puedo ir a una impresora cercana, autenticar en la impresora y recuperar mis trabajos. Esto significa que el vulnerable papel (con información sensible) no permanece en la bandeja de salida de la impresora hasta mi llegada. Obviamente, esto es aún más seguro.
Los datos en reposo (trabajos que esperan en una cola para ser impresos) y los datos en movimiento (trabajos en tránsito desde el origen hasta la impresora) siempre deberán estar cifrados. El Protocolo de Impresión por Internet (IPP) facilita esta tarea utilizando los mismos métodos de cifrado que los empleados para la Red. Una vez más, nunca confiando en ello, siempre verificándolo.
Y, ¿en lo concerniente a la autenticación? Esta es un área que ha atraído mucho escrutinio durante los últimos años. En este caso, la clave es permitirle a la organización utilizar todos los métodos y factores que desee, y ejercer control desde una sola fuente. En el pasado, se emplearon métodos simples como Active Directory (AD) de Microsoft u otros métodos LDAP (Protocolo Ligero de Acceso a Directorios). Desafortunadamente, estos eran fáciles de piratear y su estructura ofrecía un cero de flexibilidad. Las empresas querían usar algo más que una ID de usuario y contraseña para ingresar; se consideró que quizás fuera necesario algún tipo de tarjeta o “dongle” asociado, o un ping de Autenticación de Múltiples Factores (MFA) a un teléfono. Otro problema derivaba de las fusiones y adquisiciones empresariales. Una empresa podía acabar con dos, tres, o veinte dominios AD diferentes donde los usuarios podían residir y quizás tener IDs duplicadas.
Entren en el mundo de Open ID Connect (OIDC)
OIDC es un mecanismo seguro basado en servicios de red que puede actuar de representante para todas estas posibilidades. Quizás su proveedor de OIDC “federe” todos los dominios. Por lo tanto, yo ingreso como guy.tucker@lrs.com, y seguidamente, el proveedor de OIDC trabaja detrás del telón para autenticar conforme al dominio AD correcto. O, quizás quiero que se exija una MFA para todos mis usuarios. Sin un proveedor de OIDC, este requisito significa que la aplicación tiene que descifrar todas estas posibilidades.
Existen normas dictadas por RFC 6749 sobre todos los métodos y atributos necesarios para tratar con un proveedor de OIDC. No obstante, he aquí el problema – ¡ninguno de los proveedores de OIDC, incluidos los que contribuyen a la norma, se adhieren estrictamente a dicha norma! Si quiero trabajar con un proveedor de OIDC, ¿cómo lo hago?
(Advertencia: acrónimos presentes – Editor)
Pues bien, la respuesta es convertirse también en proveedor de OIDC. Así, la aplicación puede permanecer en su forma básica y subcontratar el proceso de autenticación a su propio proveedor de OIDC. En el caso del software LRS, nosotros hemos creado el componente LRS/Gateway. Cuando intento imprimir, el módulo Personal Print Manager (PPM) de LRS comprobará si estoy ingresado. Si no lo estoy, utilizará el navegador por defecto a través de LRS/Gateway para realizar la autenticación. ¿Recuerdan el ejemplo anterior del navegador? Ese método se emplea porque generalmente está disponible y lo puede controlar una organización o usuario. Es mejor utilizar este bien conocido método que intentar enterrar la misma funcionalidad en la aplicación.
Si LRS/Gateway utiliza AD directamente, la información del usuario se autentica inmediatamente y el “OK” le es enviado al PPM. Dicho OK se presenta en la forma de un Token que el PPM puede utilizar para solicitudes futuras. De esta forma, cada solicitud contiene ese “permiso para imprimir” y certifica que soy la persona que manifiesto ser. Si una empresa prefiere utilizar otro proveedor, como Azure AD, Okta, Ping, iWelcome o muchos otros de este tipo, entonces LRS/Gateway desvía la autenticación a dicha fuente secundaria. No puede ser más fácil.
He aquí mi ingreso anterior, por ejemplo, como se define para Okta:
Es decir, Okta sigue las normas que la empresa haya establecido, el OK regresa a LRS/Gateway y el proceso continúa.
En ambos casos, con AD y Okta, he sido verificado, por lo que mi impresión puede utilizar esas credenciales para verificación. A partir de ahí, toda transacción de impresión posterior también podrá ser examinada para confirmar que tiene mi Token y que no se ha violado ninguna política de la empresa.
Nunca confíen, verifiquen siempre; nunca dejen de intentar salvaguardar los valiosos datos contenidos en sus documentos. No se trata simplemente de una buena teoría. Es posible hoy en día y puede ahorrarles a Vd. y a su empresa muchos dolores de cabeza.