O que é Shadow IT em instituições financeiras – Parte 2 – Riscos

Por que monitorar a existência do “Shadow IT”? Quais riscos inerentes sobre essa prática? Levantar riscos é um papel de antecipar efeitos danosos ou oportunidades, sendo muitas vezes necessário conhecimento multidisciplinar ou além da especialidade departamental. Exemplificando os cenários já identificados no artigo anterior (Identificação de cenários do shadow it), avaliemos seus possíveis efeitos danosos no popular ‘deu ruim’, sem a pretensão de cobrir todas as possibilidades:

Software gratuito: o validador do esquema JSON dos Dados Abertos

No também popular “Não existe almoço grátis’, uma ferramenta sem custo algum para o usuário final tem sua existência justificada por alguma finalidade lógica, pois certamente há investimentos de implementação e disponibilização embutidos a serem custeados por alguém. Os motivos nos quadrantes lícitos e de boa fé não são o problema, podendo ser estratégias de marketing ou estímulo transparente ao consumo, cuja conta pode ser debitada dos investimentos e esforços de vendas.

Já aqueles com motivações incompatíveis com a política interna da instituição financeira ou até ilícitos nessa gratuidade, tais como coleta excessiva de dados para comercialização, instalação de vírus, captura de dados do equipamento e rede, entre outros, apenas a TI terá melhores condições de avaliar a estrutura técnica de funcionamento da ferramenta.

Contratações departamentais isoladas: efeito no fluxo de informações corporativo

Considerando o uso de soluções baseadas em software disseminado por toda instituição financeira, a TI possui visão interdepartamental do efeito multiplicador de uma mudança no fluxo de informações de uma área sobre as outras. Alguns exemplos:

Softwares diferentes entre as áreas compartilhando seus dados numa esteira sequencial: existência de diferentes cronogramas e prioridades entre as áreas, incompatibilidades para integração, ausência de dados necessários para a ferramenta da área seguinte do fluxo na ferramenta da área anterior. Uma ferramenta ERP até reduziria essa última incompatibilidade, mas restrições de orçamento ou uma múltipla e assíncrona gama de relações custo x benefício oferecidas pelos diferentes fornecedores pode inviabilizar essa unificação de solução ERP.

– Área fornecedora dos dados com automatização para uma área receptora com processo manual: pode exigir a inclusão de usuários adicionais da área receptora, devendo ser considerado se houver custo por quantidade de conexões. Também a nova extração de dados da solução automatizada pode ser insuficiente para as demais áreas.

– Área fornecedora dos dados com processo manual e a área receptora com automatização: no esforço genuíno de automatizar o máximo possível, será estimulado que a entrada passe a ser por meio de integração ou que os usuários da área geradora dos dados digitem diretamente no software adquirido pela área receptora. No primeiro caso, pode exigir necessidade de adaptação no layout de importação ou no segundo caso, cadastrar usuários adicionais da outra área.

Soluções departamentais: desenvolvimento interno de sofisticadas planilhas Excel

Planilhas com recursos excessivamente sofisticados já possuem seus riscos inerentes sem necessidade de envolver conhecimento da TI por si só, tais como exigir um perfil de ‘quase programador’ além das habilidades específicas de sua área, em efeito cascata restringindo candidatos às suas vagas, além de dificuldades na manutenção dessas planilhas, numa lista que vale a pena tratar em artigo separado.

Para esse escopo de não conhecimento pela TI, exemplificamos o risco de planilhas com uso de recursos avançados tais como acesso à base de dados por ODBC: num primeiro momento de implementação, seu acesso pode estar irrestrito, funcionando corretamente e a área adotando-a em grande escala.

Com a natural evolução na governança de TI, podem ser criados mecanismos de segurança cibernética e política de restrição aos bancos de dados. Uma vez sem conhecimento de tais acessos feitos pela área para considerá-la em sua parametrização de autorizações, ao aplicar uma camada de segurança cibernética, a planilha pode deixar de funcionar no momento mais crítico. Se tais procedimentos forem, por exemplo, adotados pela matriz em escala mundial, a liberação desse acesso pode não ser solucionado de forma tão imediata, muitas vezes não por restrição técnica, mas por política institucional. Estará materializado mais um risco do ‘Shadow IT’.

Após a identificação no primeiro artigo, nesse citamos alguns riscos inerentes a esses cenários exemplificados da prática de ‘Shadow IT’, cujas possíveis ações de mitigação trataremos numa próxima oportunidade.

Esse e outros temas relacionados ao regulatório BC, melhoria contínua e controles em https://www.b3bee.com.br/site/list/publicacoes/

#instituicaofinanceira #cadoc #bc #dadosabertos #etl #controlesinternos #pdca #calendario #shadowit #gir #riscodeti #riscoinerente Yoshio Hada: sócio administrador da B3Bee Consultoria e Sistemas, licenciando sistemas às instituições financeiras nos temas de Régua de Sensibilidade ao RSAC, Dados Abertos (Demonstrações Financeiras, Relatório do Pilar 3, Relatório do GRSAC e Canais de Atendimento), CADOC’s (DLI 2062, COS 40XX, Saldos Diários 4111, 5011, ETF 80XX, DF 9011/9061, SVR 9800, DRSAC 2030, RCP 4076, Pagamentos do Varejo e Canais de Atendimento 6209), FGC405, Conversão de layouts (ETL), Calendário de Obrigações Acessórias ou Fluxos de Execução, Validação e Envio de CADOC’s

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *