Estou familiarizado com ODBCs por sistema (DSNs de sistema) e ODBCs por usuário (DNSs de usuário). Quero ter ODBCs por aplicação. Desejo limitar as conexões ODBC disponíveis para um aplicativo específico, GP 2010. Tenho vários aplicativos GP instalados em um servidor de terminal (vários diretórios GP em Arquivos de Programas que armazenam vários aplicativos Dynamics.exe) e tenho vários ODBCs aos quais conectar do GP 2010.
Quero impor uma regra segundo a qual apenas aplicativos específicos do GP 2010 (Dynamics.exe) possam iniciar e conectar-se a ODBCs específicos. Em outras palavras, quero impor uma regra que crie uma relação 1:1 entre:
- um aplicativo GP 2010 (Dynamics.exe) e
- um ODBC (uma instância SQL que suporta GP)
Informações ambientais:
- Windows Server 2012 padrão de 64 bits
- SQL 2008 R2SP2
- GP 2010 SP3
O que tentei/aprendi até agora:
Tenho visto tentativas em determinados ambientes GP de usar a política de grupo para limitar os ODBCs disponíveis para usuários do Windows por meio do uso de DSNs de usuário. No entanto, tal abordagem não é útil quando um usuário do Windows tem acesso legítimo a vários aplicativos GP. Ao iniciar um aplicativo GP, eles podem selecionar qualquer ODBC disponível para o usuário do Windows.
Eu experimentei o uso do GP 2010macros de loginpara tentar resolver esse problema. No entanto, este método é inseguro e não escalável. Em primeiro lugar, assume que o nome de usuário e a senha serão conhecidos do administrador e geralmente permanecerão inalterados. Se for esse o caso, as credenciais - junto com o ODBC - podem ser incorporadas em uma macro de login (que é armazenada em texto simples em algum lugar). Mesmo assim, para serem utilizadas, as macros de login devem ser passadas para o atalho do GP 2010 que os usuários iniciam. Para poder especificar um caminho de destino genérico para cada aplicativo GP, a macro de login de cada usuário deverá ser armazenada em um local comum por usuário (por exemplo, na área de trabalho do usuário). Como isso precisa ser configurado por usuário, essa sobrecarga administrativa limita a escalabilidade.
Responder1
Não acho que você terá muita sorte em conseguir o que deseja, porque o que você está tentando fazer não combina com o funcionamento do modelo de segurança do Windows.
Os DSNs ODBC são armazenados no registro (HKEY_LOCAL_MACHINE, para DSNs de sistema, ou HKEY_CURRENT_USER, para DSNs de usuário). As permissões podem ser definidas no registro que fazem referência a entidades de segurança (usuários ou grupos), mas não ao software aplicativo de referência (uma vez que o software aplicativo não é uma entidade de segurança). Da mesma forma, as APIs utilizadas para acessar o registro não possuem funcionalidade para implementar permissões com base na aplicação que realiza o acesso. A segurança é baseada nos usuários e na associação ao grupo, não no aplicativo que estão executando.
A remoção do acesso do usuário aos DSNs ODBC não impedirá, na verdade, que os usuários acessem o banco de dados back-end se tiverem acesso. Você está apenas "ocultando" o acesso, obscurecendo o DSN, e não protegendo nada. Segurança pela obscuridade não é realmente segurança.
Não tenho experiência com Great Plains, mas como o armazenamento de back-end parece ser baseado no SQL Server, acho que o Right Way TM de limitar o acesso do usuário ao banco de dados de back-end seria a segurança do SQL Server. Um usuário acessando a instância do SQL Server que hospeda os dados do Great Plains, supondo que você esteja usando a autenticação do Windows no DSN ODBC, seria "visto" pelo SQL Server com seu contexto de usuário do Windows. Você pode criar "Logins" do SQL Server correspondentes aos usuários (ou, melhor ainda, grupos dos quais os usuários são membros) e limitar seu acesso usando a funcionalidade interna do SQL Server. Isto parece ummuitomelhor lugar para limitar o acesso do usuário, especialmente porque o próprio banco de dados irá impor o acesso.
(Não ter usado o Great Plains antes e aceitar que é possível e até provável que o software use coisas feias, como autenticação nativa do SQL Server. Se for esse o caso, você terá uma bagunça.)
Responder2
Não, mas se for tão importante, basta executar cada aplicativo em suas próprias VMs no Hyper-V.