Sus pensamientos sobre el proveedor que requiere que todos los usuarios inicien sesión en un servidor de terminal MS con el mismo nombre de usuario y contraseña


8

Tengo un proveedor que indica que no admitirán el servidor de Terminal Server Microsoft Server 2008 R2 que están instalando a menos que todos los usuarios inicien sesión con el mismo nombre de usuario y contraseña. Afirman que esto es para facilitar las cosas para los usuarios finales.

El servidor es independiente y ejecuta tanto la aplicación (EMR) como la base de datos de back-end (MySQL). Cada una de nuestras oficinas obtendrá uno de estos servidores. Mis preocupaciones son 1) seguridad y 2) posibles problemas con todos los usuarios que usan la misma cuenta de usuario. La seguridad es un problema ya que caemos bajo HIPAA y la base de datos y todos los documentos almacenados, que contienen PHI, se almacenan en el TS sin cifrar y sin ninguna ACL que limite el acceso desde la cuenta de usuario genérica. El proveedor dice que la base de datos requiere una contraseña para iniciar sesión, por lo que esta configuración es segura.

Siempre he requerido que los usuarios tengan sus propias cuentas cuando usan un servidor RDP, Citix, etc. o una granja de servidores, por lo que no tengo experiencia en el mundo real con una configuración como esta. Preguntándose qué piensan todos sobre este tipo de configuración.


12
Creo que es un desastre esperando que suceda y debes correr, no caminar, lejos de ese vendedor.
Cry Havok

2
Suena como un mal diseño y una mala orientación del vendedor.
joeqwerty

1
Espere un segundo, ¿estoy pensando correctamente que no puede tener el mismo usuario iniciando sesión en un servidor terminal, o se hará cargo de esa sesión?
Nixphoe

66
Nombres de usuario / contraseñas compartidos = cero responsabilidad por cualquier acción realizada en el servidor. Si alguien destroza todo por despecho, ¿cómo sabes quién era?
growse

2
¿Usarían los usuarios credenciales separadas para la aplicación? Si no, eso definitivamente está en contra de HIPPA. HIPPA requiere UAC, y eso sería difícil con un solo inicio de sesión. El software EMR que uso ahora y el EHR al que nos estamos cambiando están alojados en 2008 R2 sin problemas.
gtaylor85

Respuestas:


12

Si los archivos se almacenan en el nivel del sistema de archivos sin cifrado basado en el usuario y sin ACL, entonces sí, huya. Si TODOS los datos se almacenaron dentro de la base de datos, me sentiría un poco menos vacilante, pero aun así, cualquier proveedor que diga que está bien (especialmente cuando HIPPA está en la mezcla) usar IDs compartidas es sospechoso en mi libro. Si une la máquina a un dominio, no hay nada confuso desde el punto de vista del usuario final sobre el uso de su propia identificación individual. Más bien, sería más confuso para ellos tener la identificación compartida adicional.


1
... a menos que los archivos de la base de datos sean accesibles para esa cuenta de usuario compartida, en ese momento la existencia de contraseñas que controlen el acceso a la base de datos es efectivamente discutible.
Daniel Pryden

Derecha. Supuse que no serían accesibles para el usuario compartido, lo que probablemente sea un grave error dado el diseño ya pobre de esta solución ... ''
dijo el

7

De acuerdo, compartir el perfil conlleva una gran cantidad de problemas, entre los cuales se encuentra la incapacidad de tener una buena responsabilidad (o incluso CUALQUIER responsabilidad) de exactamente quién hizo exactamente qué y exactamente cuándo sucedió. Encuentre otro proveedor, uno que cumpla con los principios básicos de seguridad. Intente encontrar a alguien con una certificación SAS 70 tipo II si es posible. Garantizaré que esas organizaciones no permitirán compartir perfiles. Gracias por preguntar antes de saltar a este y lamentarlo más tarde.


3

Concurrir. Este es un desastre esperando a suceder. Si son tan poco entusiastas con algo que puedes ver (que requiere inicios de sesión compartidos), ¿qué están haciendo que no puedes ver?

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.