Asegurar que un servicio web solo procese solicitudes de computadoras específicas

¿Qué tan preocupado está por una amenaza interna y qué nivel de inteligencia esperaría que fuera una interna? Ese es tu mayor factor. Casi cualquier mecanismo de seguridad que coloques en el disco duro de la máquina puede ser dañado si el atacante obtiene una retención o tiene demasiado acceso al disco duro. El tiempo que tomará será un factor de qué tan bien ha asegurado la unidad.

Puedo pensar en muchas maneras de hacer esto:

• Filtrado de IP (spoofable)

• configure los túneles IPSEC durante la instalación

• Autenticación basada en certificados

• Requiere autenticación VPN con algo como un generador de claves pseudoaleatorias en un token

Cualquier cosa es hackeable, dada la amenaza correcta.

Cada mecanismo tiene diferentes formas de ser atacado o comprometido. Las direcciones IP se pueden falsificar, los túneles o certificados de IP Sec pueden verse comprometidos si el atacante ingresa al disco duro o la gente hace algo tonto con los datos de seguridad de la computadora. Los tokens de generación de claves son excelentes para estar separados de la máquina, pero requieren el software COTS y pueden ser caros.

La autenticación de certificados a través de SSL autenticado por el cliente generalmente no es tan mala de configurar: los servidores web realizarán un escenario de autenticación muy simple, y debería poder restringir su servidor a una lista de clientes en los que confía según el nombre distinguido del certificado . Si usa certificados de software, significa que tendrá que instalar una clave privada separada para cada cliente. Eso significa un cierto nivel de gestión de claves diligentes. Puede cargar claves privadas en navegadores u otros almacenes de certificados con una regla para el sistema operativo que no exporte la clave privada. Parte de esto puede ser pirateado o cambiado dependiendo de los privilegios del usuario, por lo tanto, la cuestión de las amenazas internas.

Si limita su autenticación de certificado a la autenticación de cliente SSL, no tendrá que cambiar ninguna lógica de su servicio web a menos que también tenga requisitos de administración de privilegios más específicos.

En primer lugar, necesita buena administración de ID de sesión en sus servicios web .

En segundo lugar, recomendaría algo como Framework Revolver de Cookie para vincular el certificado del lado del cliente con las ID de máquinas (por ejemplo, MAC dirección de la NIC y / o número de serie de un disco duro) y direcciones IP estáticas. Sin embargo, es probable que estos se puedan falsificar con hardware virtualizado en este día y edad muy fácilmente.

Iría por algo en el que el certificado del lado del cliente se almacenara en algo como un Aladdin USB eToken (2048 bits sería bueno), pero luego pegas físicamente y de otro modo evitas la manipulación del dispositivo en una toma USB. Eso tampoco funciona bien, pero tal vez un chip TPM integrado lo haría. Pruebe TrouSerS , parece que tienen autenticación EAP-TLS basada en las identidades de TPM.

Me parece que el mejor enfoque aquí es instalar un certificado de cliente con la instalación de cliente grueso. Si desea agregar otra capa, puede hacer algo con el filtro de firewall, con el cliente actualizando una lista blanca cuando se active.

Puede hacer varias cosas que hacen que sea difícil que el usuario final extraiga el certificado. El uso de CryptoAPI de Windows y el almacén de certificados local puede dificultar la exportación de la clave privada (si no imposible) y permitir que su aplicación aproveche los CSP para pasar las solicitudes al servicio web.

Por su perfil, supongo que escribió el cliente en .NET, por lo que es probable que encuentre la mayor parte de esto en los recursos de MSDN disponibles. (Aunque aquí hay un punto de partida: enlace )

No puedo encontrar nada con respecto a si se evitó o no la exportación de la clave privada desde el almacén de certificados, no significa que no sea posible, pero si se ha hecho, es más difícil que una búsqueda de Google encontrar.