Я знаком с 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
- ГП 2010 SP3
Что я попробовал/узнал на данный момент:
Я видел попытки в определенных средах GP использовать групповую политику для ограничения ODBC, доступных пользователям Windows, с помощью пользовательских DSN. Однако такой подход бесполезен, когда пользователь Windows имеет законный доступ к нескольким приложениям GP. Когда они запускают приложение GP, они могут выбрать любой ODBC, доступный их пользователю Windows.
Я экспериментировал с использованием GP 2010макросы входачтобы попытаться решить эту проблему. Однако этот метод небезопасен и не масштабируется. Во-первых, он предполагает, что имя пользователя и пароль будут известны администратору и, как правило, останутся неизменными. Если это так, учетные данные — вместе с ODBC — могут быть встроены в макрос входа (который хранится где-то в виде обычного текста). Тем не менее, для использования макросы входа должны быть переданы в ярлык GP 2010, который запускают пользователи. Чтобы иметь возможность указать общий целевой путь для каждого приложения GP, макрос входа для каждого пользователя должен быть сохранен в общем для каждого пользователя месте (например, на рабочем столе их пользователя). Поскольку это должно быть настроено для каждого пользователя, эти административные издержки ограничивают масштабируемость.
решение1
Я не думаю, что вам удастся добиться желаемого, поскольку то, что вы пытаетесь сделать, не соответствует принципам работы модели безопасности Windows.
ODBC DSN хранятся в реестре (либо HKEY_LOCAL_MACHINE для системных DSN, либо HKEY_CURRENT_USER для пользовательских DSN). Разрешения могут быть установлены в реестре, который ссылается на субъектов безопасности (пользователей или группы), но не на прикладное программное обеспечение (поскольку прикладное программное обеспечение не является субъектом безопасности). Аналогично, API, используемые для доступа к реестру, не имеют функциональности для реализации разрешений на основе приложения, выполняющего доступ. Безопасность основана на пользователях и их членстве в группе, а не на приложении, которое они запускают.
Удаление доступа пользователей к ODBC DSN на самом деле не остановит пользователей от доступа к внутренней базе данных, если у них есть доступ. Вы просто "скрываете" доступ, скрывая DSN, на самом деле ничего не защищая. Безопасность через скрытность на самом деле не является безопасностью.
У меня нет опыта работы с Great Plains, но поскольку его внутреннее хранилище, похоже, основано на SQL Server, я бы подумал, что правильным способом ограничения доступа пользователей к внутренней базе данных будет безопасность SQL Server. Пользователь, обращающийся к экземпляру SQL Server, на котором размещены данные Great Plains, при условии, что вы используете аутентификацию Windows на ODBC DSN, будет «виден» SQL Server с его пользовательским контекстом Windows. Вы можете создать «логины» SQL Server, соответствующие пользователям (или, что еще лучше, группам, членами которых являются пользователи) и ограничить их доступ с помощью встроенной функциональности SQL Server. Это похоже намноголучшее место для ограничения доступа пользователей, тем более, что сама база данных будет обеспечивать доступ.
(Раньше я не пользовался Great Plains и понимаю, что возможно и даже вероятно, что программное обеспечение использует такие отвратительные вещи, как собственная аутентификация SQL Server. Если это так, то у вас просто бардак.)
решение2
Нет, но если это так важно, просто запустите каждое приложение на отдельной виртуальной машине под управлением Hyper-V.