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