ODBCs por aplicativo

Question

Estou familiarizado com ODBCs pelo sistema (DSNs do sistema) e ODBCs pelo usuário (DNSs do usuário). Eu quero ter ODBCs por aplicativo. Eu quero limitar as conexões ODBC disponíveis para um aplicativo específico, GP 2010. Eu tenho vários aplicativos GP instalados em um servidor de terminal (vários diretórios GP dentro de arquivos de programa armazenando vários aplicativos Dynamics.exe) e eu tenho vários ODBCs para conectar do GP de 2010.

Eu quero aplicar uma regra na qual apenas aplicativos específicos do GP 2010 (Dynamics.exe) podem ser iniciados e conectados a ODBCs específicos. Em outras palavras, quero impor uma regra que crie uma relação 1: 1 entre:

1. um aplicativo do GP 2010 (Dynamics.exe) e
2. um ODBC (uma instância do SQL que suporta o GP)

Informações do ambiente:

• Windows Server 2012 Standard de 64 bits
• SQL 2008 R2 SP2
• GP 2010 SP3

O que eu tentei / aprendi até agora:

Eu tenho visto tentativas em determinados ambientes GP para usar a diretiva de grupo para limitar os ODBCs disponíveis para usuários do Windows através do uso de DSNs de usuário. No entanto, tal abordagem não é útil quando um usuário do Windows legitimamente tem acesso a vários aplicativos GP. Quando eles iniciam um aplicativo GP, eles podem selecionar qualquer ODBC disponível para o usuário do Windows.

Eu experimentei o uso do login do GP 2010 macros para tentar resolver esse problema. No entanto, esse método é inseguro e não é dimensionado. Em primeiro lugar, pressupõe que um nome de usuário e senha serão conhecidos pelo administrador e geralmente permanecerão inalterados. Se este for 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 usadas, 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 do GP, a macro de login de cada usuário terá que 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.

    

Answer 1

Eu 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.

DSNs ODBC são armazenados no registro (HKEY_LOCAL_MACHINE, para DSNs do sistema ou HKEY_CURRENT_USER, para DSNs do 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 a esse software de aplicativo de referência (já que o software de aplicativo não é uma entidade de segurança). Da mesma forma, as APIs usadas para acessar o registro não têm funcionalidade para implementar permissões com base no aplicativo que executa o acesso. A segurança é baseada nos usuários e em sua participação no grupo, não no aplicativo em que estão sendo executados.

Remover o acesso do usuário aos DSNs do ODBC não impedirá os usuários de acessar o banco de dados de back-end se eles tiverem acesso. Você está apenas "escondendo" o acesso obscurecendo o DSN, na verdade não protegendo nada. Segurança por obscuridade não é realmente segurança.

Eu não tenho experiência com o Great Plains, mas como o armazenamento de back-end parece ser baseado no SQL Server, eu acho que o Right Way ^TM de limitar o acesso do usuário ao back-end banco de dados seria a segurança do SQL Server. Um usuário que acessa a instância do SQL Server que hospeda os dados do Great Plains, supondo que você esteja usando a autenticação do Windows no ODBC DSN, seria "visto" pelo SQL Server com seu contexto de usuário do Windows. Você pode criar "Logons" 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 um lote melhor lugar para limitar o acesso do usuário, especialmente porque o próprio banco de dados irá impor o acesso.

(Não tendo usado Great Plains antes, e aceitando que é possível e até mesmo provável que o software use coisas feias como a autenticação nativa do SQL Server. Se for esse o caso, então você só tem uma bagunça.)

    

Answer 2

Não, mas se esse negócio for grande, basta executar cada aplicativo em suas próprias VMs no Hyper-V.