¿Deberíamos molestarnos con el cifrado a nivel de celda para una aplicación web ASP.NET/SQL Server?

Question

¿Deberíamos molestarnos con el cifrado a nivel de celda para una aplicación web ASP.NET/SQL Server?

#1 de gowenfawr (6 votos)

4

( Publicación cruzada aquí en el consejo de un usuario en stackoverflow ...)

Tengo una pregunta de seguridad filosófica para todos. Estoy diseñando un diseño de aplicación web ASP.NET donde los datos confidenciales de diferentes organizaciones / clientes se almacenarán en una base de datos de SQL Server. La autenticación del usuario utilizará la autenticación de formularios ASP.NET.

El cifrado de la base de datos completa mediante el Cifrado transparente de la base de datos (TDE) es una tarea sencilla. Pero tengo curiosidad por si deberíamos preocuparnos por el cifrado a nivel de celda (usando algo como el Kit de herramientas de seguridad de la etiqueta de SQL Server que se encuentra en codeplex.com: etiqueta de SQL Server Kit de herramientas de seguridad ).

Si tuviéramos que realizar el cifrado a nivel de celda, podríamos asociar a cada usuario de una organización / cliente a una única cuenta de usuario de SQL que tenga la capacidad de leer / escribir datos para su organización. Por lo tanto, en caso de que una cuenta de usuario de SQL se viera comprometida, limitaría el acceso a los datos solo a esa única organización.

Pero supongamos que creamos una única cuenta de usuario / contraseña de SQL que solo está destinada a que la aplicación web se comunique de forma segura con la base de datos (no se permitirá el acceso directo a la base de datos con fines de informe). Podemos configurarlo con una contraseña suficientemente larga y generada de manera aleatoria, con esas credenciales almacenadas encriptadas en el archivo web.config.

En este punto, ¿hemos asegurado suficientemente el acceso a datos confidenciales en la base de datos (asumiendo que la aplicación limita lo que se muestra, por supuesto)?

En otras palabras, supongamos que tenemos varias cuentas de usuario de SQL con contraseñas ridículamente largas cifradas en el archivo web.config. Si una de esas cuentas de usuario de SQL estuviera comprometida, eso significaría que existe una falla de seguridad que probablemente significaría que todas las cuentas de usuario de SQL estaban comprometidas. Por lo tanto, no existe un valor agregado de seguridad realmente.

(La razón más convincente que se me ocurre para realizar el cifrado a nivel de celda por parte de usuarios de SQL específicos del cliente sería evitar que un agujero de seguridad en la aplicación web real muestre datos de otro cliente).

Espero que la pregunta tenga sentido. ¡Estar interesado en escuchar los pensamientos de otros sobre esto! Gracias de antemano.

asp.net sql-server

pregunta wolfpigeon 30.12.2013 - 21:58

fuente

1 respuesta

Lea otras preguntas en las etiquetas asp.net sql-server

¿Revocará CA un certificado a sitios web de phishing? Formas de falsificar completamente el agente de usuario del navegador y ocultar el sistema operativo a un servidor web

score 6 · Answer 1

Creo que la respuesta a su pregunta gira en torno a una visión perceptiva ligeramente diferente, es decir, ¿dónde tiene lugar el descifrado?

Las tecnologías como TDE funcionan en el nivel de la base de datos. En términos prácticos, esto a menudo significa que un DBA, o alguien que ha comprometido los privilegios apropiados, puede acceder a la estructura y los datos descifrados.

Por otra parte, el cifrado a nivel de celda, puede implementarse más comúnmente en la capa de aplicación. Lo que significa que el DBA nunca tendrá la capacidad de acceder a otra cosa que no sea un blob encriptado; la clave para descifrarlo es (debería ser) secuestrada en el nivel de la aplicación. Esto es valioso porque, tanto en el mundo de la seguridad como en el del cumplimiento, el control dual es un poderoso aliado. Los ingenieros de la aplicación pueden descifrar datos, pero solo si toman una gran cantidad de ellos de la base de datos, lo que generalmente no es sutil. Los administradores de la base de datos pueden capturar una gran cantidad de datos, generalmente de forma sutil, pero si no pueden descifrarlos, entonces se conserva el control.

Cuando estás pensando en lo que tiene sentido, debes pensar en las amenazas que te preocupan. Si solo está preocupado por los discos fríos y las cintas de copia de seguridad, TDE cubre su preocupación. Si está preocupado por los vectores de ataque en un par de aplicaciones y bases de datos en funcionamiento, TDE tiene menos sentido y es posible que desee considerar controles más detallados que separen la capacidad de descifrado del almacén de datos.

Si tiene varias aplicaciones coubicadas con diferentes claves de cifrado que permiten el acceso a blobs cifrados específicos de la aplicación en un backend compartido, entonces sí, eso puede ofrecerle más seguridad ... pero tiene los pozos en los que debe pensar . Un atacante que obtiene algún control del servidor de aplicaciones es el peor escenario estándar. Si obtienen acceso al servidor de aplicaciones, ¿puede recopilar claves de descifrado de las múltiples aplicaciones y anular la separación? Realmente no puede separar las aplicaciones con claves de cifrado si están todas en el disco, en la memoria y ejecutándose en el mismo servidor de aplicaciones, al menos no como control de seguridad. Ahí es donde querría otros controles, como servidores de aplicaciones separados, para ayudar a proteger sus datos.

Tenga en cuenta que he usado palabras de comadreja como en términos prácticos , puede ser más comúnmente , debería ser y no sutil / sutil . Soy consciente de que es posible que no esté respondiendo su pregunta directa, dadas las tecnologías que está enumerando; Estoy reformulando la pregunta en una inclinación más teórica para que puedas intentar mapear tus opciones en conceptos y trabajar desde allí.

¡Buena suerte!