Я знаком с ODBC по системе (системные DSN) и ODBC по пользователям (пользовательские DNS). Я хочу иметь ODBC по приложениям. Я хочу ограничить ODBC-соединения, доступные для конкретного приложения, GP 2010. У меня есть несколько приложений GP, установленных на сервере терминалов (несколько каталогов GP в Program Files, в которых хранятся несколько приложений Dynamics.exe), и у меня есть несколько ODBC, к которым можно подключиться из ГП 2010.
Я хочу установить правило, согласно которому только определенные приложения GP 2010 (Dynamics.exe) могут запускаться и подключаться к определенным ODBC. Другими словами, я хочу ввести правило, которое создает соотношение 1: 1 между:
Информация об окружающей среде:
Что я пробовал / узнал до сих пор:
Я видел попытки в определенных средах GP использовать групповую политику для ограничения ODBC, доступных пользователям Windows, с помощью пользовательских DSN. Однако такой подход бесполезен, если пользователь Windows имеет законный доступ к нескольким приложениям GP. Когда они запускают приложение GP, они могут выбрать любой ODBC, доступный их пользователю Windows.
Я экспериментировал с использованием GP 2010 макросы входа чтобы попытаться решить эту проблему. Однако этот метод небезопасен и не масштабируется. Во-первых, предполагается, что имя пользователя и пароль будут известны администратору и обычно остаются неизменными. В этом случае учетные данные - вместе с ODBC - могут быть встроены в макрос входа в систему (который где-то хранится в виде обычного текста). Тем не менее, для использования макрос входа в систему должен быть передан ярлыку GP 2010, запускаемому пользователями. Чтобы можно было указать общий целевой путь для каждого приложения GP, макрос входа в систему для каждого пользователя должен быть сохранен в общем для каждого пользователя месте (например, на рабочем столе их пользователя). Поскольку это должно быть настроено для каждого пользователя, эти административные издержки ограничивают масштабируемость.
Нет, но если это так важно, просто запустите каждое приложение на своих виртуальных машинах под Hyper-V.
Я не думаю, что вам удастся получить желаемое, потому что то, что вы пытаетесь сделать, не согласуется с тем, как работает модель безопасности Windows.
DSN ODBC хранятся в реестре (HKEY_LOCAL_MACHINE для системных DSN или HKEY_CURRENT_USER для пользовательских DSN). В реестре можно установить разрешения, которые относятся к участникам безопасности (пользователям или группам), но не к эталонному прикладному программному обеспечению (поскольку прикладное программное обеспечение не является участником безопасности). Точно так же API-интерфейсы, используемые для доступа к реестру, не имеют функциональных возможностей для реализации разрешений на основе приложения, выполняющего доступ. Безопасность зависит от пользователей и их членства в группах, а не от приложения, которое они запускают.
Удаление доступа пользователей к ODBC DSN фактически не остановит пользователей от доступа к серверной базе данных, если у них есть доступ. Вы просто «скрываете» доступ, скрывая DSN, а на самом деле ничего не защищаете. Безопасность посредством неизвестности на самом деле не является безопасностью.
У меня нет опыта работы с Great Plains, но поскольку это внутреннее хранилище, похоже, основано на SQL Server, я бы подумал, что правильный путьTM ограничения доступа пользователей к серверной базе данных было бы безопасностью SQL Server. Пользователь, обращающийся к экземпляру SQL Server, на котором размещены данные Great Plains, при условии, что вы используете проверку подлинности Windows в ODBC DSN, будет "виден" SQL Server в контексте их пользователя Windows. Вы можете создать SQL Server «Имена входа», соответствующие пользователям (или, еще лучше, группам, членами которых являются пользователи), и ограничить их доступ с помощью встроенных функций SQL Server. Это похоже на много Лучшее место для ограничения доступа пользователей, тем более, что сама база данных будет обеспечивать доступ.
(Вы не использовали Great Plains раньше и признали, что это возможно и даже вероятно, что программное обеспечение использует уродливые вещи, такие как собственная аутентификация SQL Server. Если это так, то у вас просто беспорядок.)