En general, la gente tiende a pensar que no tener elección es malo. En su libro seminal de 2009 Paradox of Choice, Barry Schwartz argumentó que tener demasiadas opciones también es malo. En algún lugar entre «ninguna» y «demasiadas», debe haber un número óptimo de opciones para la mayoría de las cosas, incluidas las posibles soluciones a un problema. Con eso en mente, echemos un vistazo a cómo Microsoft ayuda a sus clientes a resolver el problema de la confidencialidad de los documentos. Es difícil pensar en un mejor ejemplo de cómo funciona el modelo de «defensa en profundidad» en el servicio.
Cifrado en reposo y en tránsito
Comencemos con el reconocimiento de que Microsoft cifra los datos tanto en reposo como en tránsito. Por ejemplo, Microsoft usa BitLocker en sus propios centros de datos para proteger los datos almacenados y cada conexión entre servidores (o entre cliente y servidor) está protegida con TLS. Estos métodos de cifrado están destinados a proteger contra dos escenarios específicos. TLS protege contra espionaje o escenarios de hombre en el medio, donde un atacante toma el tráfico de la red. El cifrado en reposo protege contra el escenario en el que un atacante roba un volumen de disco físico de un centro de datos. Por supuesto, BitLocker (y FileVault, el equivalente de macOS) también pueden proteger los volúmenes individuales de su computadora portátil o de escritorio contra el robo, por lo que también debería usarlos en sus terminales.
“Prohibido el paso” no es suficiente
Si tenemos el cifrado aplicado para protegernos contra los espías y el robo flagrante de discos, la siguiente forma obvia de proteger la confidencialidad de los documentos es usar permisos. Para ser justos, esto es lo suficientemente bueno para la mayoría de las aplicaciones; los documentos guardados en el OneDrive de un usuario, en un sitio de SharePoint o en un buzón de correo solo serán accesibles para las personas que tengan permiso para verlos o con quienes se hayan compartido los objetos. Es razonable preguntarse por qué necesita el cifrado de documentos si es diligente en la asignación y auditoría de permisos. La respuesta corta es que los permisos funcionan para proteger contra el acceso de usuarios no autorizados; también existe el caso en el que alguien que tiene acceso privilegiado a un documento pero que no debe leerlo usa sus privilegios para hacerlo. Imagine un escenario de «administración global que salió mal», y no está demasiado lejos. Los controles de acceso y la auditoría sólida pueden ayudarlo a detectar casos en los que un usuario privilegiado busca cosas que se supone que no debe ver, pero no necesariamente lo previene. (una forma en que puede ayudar a prevenirlo es requerir una escalada de privilegios justo a tiempo a través de Azure AD Privileged Identity Management, algo de lo que hablaremos en una columna futura).
Agregar otra capa de cifrado
Suponga que desea aplicar una capa adicional de protección a sus documentos. Puede hacer esto porque quiere evitar que sus propios administradores husmeen o porque quiere una protección adicional contra el personal de Microsoft. Microsoft ya aplica lo que llaman cifrado de servicio, donde generan y administran claves criptográficas que se utilizan para proteger sus datos. El cifrado del servicio es automático y forma parte de la protección básica del servicio que Microsoft ofrece a todos los inquilinos. La mayoría de las organizaciones están lo suficientemente contentas con el cifrado de servicios básicos. De hecho, la mayoría de los administradores de inquilinos probablemente no saben que existe. Si necesita protección adicional, puede obtenerla de dos maneras: puede usar el cifrado de clave de cliente (a veces conocido como «traiga su propia clave» o «mantenga su propia clave»), o puede usar el cifrado de clave doble.
Traer su propia clave con Purview Customer Key
Comprender la clave de cliente y para qué sirve requerirá un poco de esfuerzo. Comencemos con el concepto de que existe una clave criptográfica raíz que se usa para derivar otras claves que protegen sus datos específicos. Con el cifrado de servicio normal, Microsoft tiene esta clave y usted no tiene acceso a ella. Con Clave de cliente, genera la clave y se la proporciona a Microsoft. Eso plantea una gran cantidad de preguntas interesantes, como cómo generar la clave de forma segura, dónde se almacena y qué hace Microsoft con ella. La respuesta breve es que usted mismo genera dos claves raíz, almacenando cada una de ellas en Azure Key Vault (AKV) en una suscripción de Azure independiente. Si lo desea, puede implementar módulos de almacenamiento de claves de hardware con AKV. Una vez que haya generado estas dos claves, habilite la clave de cliente (pidiéndole a Microsoft que lo haga; no puede habilitarla usted mismo) y cree políticas de cifrado de datos (DEP) que le indiquen al servicio qué claves usar para las cargas de trabajo específicas que necesita. quiere proteger.
Tenga en cuenta: esa fue la versión corta. La documentación de configuración completa es un poco más complicada.
Debido a que perder las claves raíz de su clave de cliente significa que perdería todo acceso a sus datos almacenados en el servicio, Microsoft también usa las claves que genera para crear una clave de disponibilidad, que usan en una variedad de sistemas automatizados para garantizar que operaciones como la aplicación de política de búsqueda y retención funciona correctamente. Lo más importante que debe recordar aquí es que los sistemas de Microsoft no pueden hacer nada con sus datos a menos que tengan su clave… y si les ha dado su clave, debe considerar si usar la clave de cliente realmente le brinda protección adicional. La mayoría de los clientes con los que he hablado que están interesados en Customer Key la quieren porque tienen requisitos de cumplimiento específicos que la exigen.
Problema de doble tecla
Si realmente no desea que Microsoft pueda ver sus datos, tiene suerte: puede usar el cifrado de doble clave (DKE). En una implementación de DKE, crea una etiqueta de confidencialidad de Azure Information Protection que aplica DKE solo a elementos seleccionados; Microsoft advierte que «está destinado a sus datos más confidenciales que están sujetos a los requisitos de protección más estrictos». DKE no está diseñado para todos los datos”. Cuando implementa DKE (un proceso mucho más complicado de lo que podría imaginar al principio), en realidad crea una clave que solo usted tiene, luego la publica en AKV y crea un servicio de Azure para capturar las solicitudes de cifrado. Luego, configura Microsoft 365 para conocer ese servicio.
Para usar DKE, los usuarios aplicarán manualmente la etiqueta de confidencialidad asociada con DKE en los elementos más críticos para el negocio, momento en el que se cifrarán en el dispositivo cliente mediante el servicio que publicó. Una vez que se completa el cifrado del lado del cliente, el blob cifrado se almacena como un archivo en el OneDrive del usuario, en un sitio de SharePoint, en un archivo adjunto de correo electrónico o lo que sea. Aquí está el problema con ese enfoque: debido a que el contenido está encriptado de una manera que el servicio no puede leer, muchas cosas no funcionarán. Por ejemplo, las búsquedas de exhibición de documentos electrónicos no pueden leer elementos protegidos por DKE, ni tampoco las reglas de transporte de Exchange. Esto se debe a que la clave que creó nunca está disponible para el servicio de Microsoft 365.
DKE sigue siendo una especie de función de proyecto científico: funciona, pero hay muchas limitaciones prácticas que significan que tendrá que estar preparado para hacer algunos retoques y solucionar problemas a nivel de maestro para usarlo.
Tanto DKE como BYOK requieren que los usuarios tengan una licencia de la familia de licencias E5.
¿Qué pasa si solo quiero cifrar el correo electrónico?
En esta columna, no mencioné las funciones de cifrado específicas del correo electrónico, como el cifrado de mensajes Purview o S/MIME. Estas soluciones no protegen los documentos a menos que estén adjuntos a un mensaje de correo, por lo que los dejé fuera, pero espero verlos discutidos en una columna futura.
A dónde ir desde aquí
Antes de dedicar tiempo a implementar BYOK o DKE, realmente debería dar un paso atrás y analizar desapasionadamente los beneficios de seguridad específicos que cree que le brindarán estas tecnologías. Cada función de seguridad es una compensación entre la seguridad por un lado y la conveniencia (o la capacidad de mantenimiento, el rendimiento u otros aspectos del sistema en general) por el otro. La carga administrativa adicional, el riesgo de pérdida de datos si la administración de claves es deficiente y la funcionalidad reducida disponible cuando se implementa DKE significa que estas tecnologías solo deben aplicarse cuando pueda identificar beneficios claros y significativos al hacerlo.
