Ваши мысли о продавце, требующие от всех пользователей входа на сервер MS Terminal с одинаковыми именем пользователя и паролем


8

У меня есть поставщик, который заявляет, что он не будет поддерживать установленный сервер терминалов Microsoft Server 2008 R2, если все пользователи не будут входить в систему, используя одно и то же имя пользователя и пароль. Они утверждают, что это должно облегчить жизнь конечным пользователям.

Сервер является автономным и запускает как приложение (EMR), так и базу данных сервера (MySQL). Каждый из наших офисов получит один из этих серверов. Мои опасения: 1) безопасность и 2) возможные проблемы со всеми пользователями, использующими одну и ту же учетную запись. Безопасность - это проблема, поскольку мы подпадаем под HIPAA и БД, и все хранимые документы, содержащие PHI, хранятся в TS без шифрования и без каких-либо ACL, ограничивающих доступ из общей учетной записи пользователя. Продавец говорит, что для входа в БД требуется пароль, поэтому эта настройка безопасна.

Я всегда требовал, чтобы пользователи имели свои собственные учетные записи при использовании сервера или фермы серверов RDP, Citix и т. Д., Поэтому я не имею никакого реального опыта работы с подобной установкой. Интересно, что все думают об этом типе установки.


12
Я думаю, что произойдет катастрофа, и вы должны убегать, а не уходить от этого поставщика.
Плачь Хавок

2
Похоже, плохой дизайн и плохое руководство от продавца.
Joeqwerty

1
Подождите секунду, я правильно думаю, что вы не можете иметь одного и того же пользователя, входящего на сервер терминалов, или это займет этот сеанс?
Nixphoe

6
Общие имена пользователей / пароли = ноль ответственности за любое действие, выполненное на сервере. Если кто-то все злобно выбрасывает, откуда ты знаешь, кто это был?
Growse

2
Будут ли пользователи использовать отдельные учетные данные для приложения? Если нет, то это определенно против HIPPA. HIPPA требует UAC, и это было бы сложно с одним логином. Программное обеспечение EMR, которое я сейчас использую, и EHR, на который мы переключаемся, размещены на 2008 R2 без проблем.
gtaylor85

Ответы:


12

Если файлы хранятся на уровне файловой системы без пользовательского шифрования и без списков ACL, тогда да, убегайте. Если бы ВСЕ данные были сохранены в базе данных, то я чувствовал бы себя немного менее нерешительно, но даже все же, любой поставщик, который говорит, что это нормально (особенно когда HIPPA находится в миксе), использует подозрительные идентификаторы в моей книге. Если вы присоединяете компьютер к домену, то с точки зрения конечного пользователя ничто не смущает использование его собственного индивидуального идентификатора. Скорее, было бы более запутанным для них иметь дополнительный общий идентификатор.


1
... если файлы базы данных не доступны для этой общей учетной записи пользователя, в этот момент существование каких-либо паролей, контролирующих доступ к базе данных, фактически не имеет значения.
Даниэль Приден

Правильно. Я сделал предположение, что они не будут доступны для общего пользователя, что, вероятно, является грубой ошибкой, учитывая и без того плохой дизайн этого решения ...
squillman

7

Согласитесь, с совместным использованием профиля возникает целый ряд проблем, и не в последнюю очередь это неспособность иметь хорошую ответственность (или даже ЛЮБУЮ ответственность) за то, кто именно сделал то, что и когда именно это произошло. Найдите другого поставщика, который придерживается основных принципов безопасности. Попробуйте найти кого-нибудь с сертификатом SAS 70 типа II, если это возможно. Я гарантирую, что эти организации не разрешат совместное использование профиля. Спасибо, что спросили, прежде чем прыгать в этот и сожалеть об этом позже.


3

Concur. Это катастрофа, ожидающая случиться. Если они настолько неадекватны с чем-то, что вы можете видеть (требуя общих входов в систему), что они делают, чего вы не видите?

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.