Salte para o conteúdo principal
Voltar aos blogues

Perspectivas do sector

Concentrar-se na pessoa certa

10 de novembro de 2022

Por Jim Beno - Diretor da Experiência do Utilizador, Skyhigh Security

Enquanto empresa de segurança, os utilizadores do nosso produto trabalham normalmente na organização de Segurança da Informação (InfoSec). Mas, cada vez mais, descobrimos que as nossas funcionalidades Security Service Edge (SSE) se destinam a utilizadores fora da equipa de segurança: principalmente em Tecnologias de Informação (TI), mas também em Engenharia/Operações. Estas são as pessoas que desenvolvem e implementam aplicações na nuvem, controlam o acesso às mesmas e asseguram o desempenho da rede.

Existem pelo menos quatro grandes fluxos de trabalho ou características da SSE destinados a funções fora da organização de segurança:

  • Concessão de acesso a aplicações - À medida que as empresas transferem mais da sua infraestrutura para a nuvem pública, precisam de controlar o acesso às aplicações aí alojadas. A nossa solução Zero Trust Network Access (ZTNA) fornece-lhe esta capacidade. Gerir estas políticas de acesso e responder aos pedidos de acesso dos funcionários não é tarefa do Centro de Operações de Segurança (SOC). Esta é uma responsabilidade da TI e do Help Desk de TI.
  • Gerir a política de firewall - Com toda esta infraestrutura na nuvem pública, para garantir a segurança, as empresas precisam de controlar o acesso não só especificando "quem" pode utilizar estas aplicações, mas também o "como" - os detalhes de que protocolos, portas, dispositivos, localizações, etc.
  • Monitorização da experiência digital - Com escritórios em todo o mundo e muitas pessoas a trabalhar a partir de casa, é inevitável que alguns funcionários tenham problemas em aceder a uma aplicação ou serviço. Identificar o âmbito e a origem destes problemas pode ser um pesadelo. Quando chegam as chamadas do Help Desk de TI, a equipa de segurança não vai atender o telefone.
  • Corrigir erros de configuração e vulnerabilidades - No âmbito das TI e da engenharia, várias equipas podem estar a criar aplicações no Amazon Web Services (AWS), Google Cloud Platform (GCP) ou Microsoft Azure. A nossa função é ajudar as empresas a proteger estas aplicações, quer seja o arquiteto de TI responsável pela sua infraestrutura de nuvem, os proprietários de contas que desenvolvem e configuram as aplicações ou o pessoal DevOps / DevSecOps que as implementa. Se detectarmos uma vulnerabilidade ou uma configuração incorrecta, a equipa de segurança não tem "as chaves do castelo" para a corrigir - temos de apresentar o problema ao proprietário de TI ou de engenharia que pode fazer a alteração.

Criar Personas

Em Skyhigh Security, temos investigadores de utilizadores dedicados cuja função é compreender os clientes e gerar conhecimentos que informem os requisitos e a conceção dos produtos. Para cada nova capacidade de produto, temos de garantir que estamos a visar o utilizador certo e aprender tudo o que pudermos sobre ele: O que é que o motiva? Que tarefas desempenha? Que aplicações ou sistemas utiliza? Como é que colabora com os outros? Quais são os seus principais problemas?

Começamos por colocar estas questões aos membros da equipa interna de gestão de produtos e vendas. Muitas vezes, realizamos uma sessão de trabalho e registamos o nosso conhecimento coletivo num quadro branco virtual. Assim que soubermos quais os cargos a visar, entrevistamos os clientes e observamos a sua forma de trabalhar. Após algumas destas sessões, começarão a surgir alguns temas comuns. Em seguida, sintetizamos todos os conhecimentos criando uma personagem fictícia - uma "persona" - que se torna o ponto focal para escrever casos de utilização e design.

Apresentação do Fred e do Kawika

Ultimamente, os nossos investigadores têm estado a investigar duas novas personas responsáveis pela monitorização da experiência digital e pela política de firewall: "Fred", que trabalha no Help Desk de TI, e "Kawika", o administrador de rede. Aqui estão algumas das informações que aprendemos com esta dupla dinâmica:

  • O Kawika é responsável pelo desempenho da rede. Quando tudo está a funcionar, a vida é boa. Mas quando as coisas correm mal, tem de largar tudo e entrar em ação. Para evitar isto, quer monitorizar proactivamente as aplicações críticas na rede - não pode esperar que cheguem vários pedidos de ajuda.
  • À semelhança do SOC, as TI têm diferentes níveis para lidar com os problemas de suporte. Quando um funcionário se depara com um problema de acesso a uma aplicação, abre um bilhete que é tratado pelo help desk de TI. Isto significa que o Fred será o primeiro na fila para investigar o problema. Tem um manual para o orientar na resolução de problemas. Se lhe parecer que se trata de um problema de rede, então encaminha-o para a equipa de rede. Agora é a vez do Kawika.
  • Diagnosticar um problema de rede não é fácil. A arquitetura da rede é complexa. Ao aceder a um serviço na nuvem, o tráfego do dispositivo do funcionário viaja através de muitas redes diferentes. Existem muitas variáveis que podem afetar o desempenho, e as condições podem mudar ao longo do tempo. Para investigar estes problemas, Kawika tem de utilizar muitas ferramentas e consolas para obter as informações de que necessita.
Ficha de dados de persona para Kawika, o administrador de rede

Evitar a ambiguidade

Todos estes conhecimentos são resumidos em folhas de dados de página única que criámos para o Fred, o Kawika e os seus colegas. Também realizamos sessões de formação para apresentar as personas às equipas multifuncionais. Quando ouvimos os gestores de produto e os engenheiros referirem uma persona pelo nome, sabemos que fizemos o nosso trabalho!

Cada fluxo de design UX no Figma começa com uma prancheta que mostra a pessoa-alvo e o caso de utilização. Desta forma, todos estão na mesma página e evitamos referências ambíguas ao "administrador" ou ao "arquiteto de segurança". Se estivermos a rever o design e alguém questionar a pessoa-alvo, isso é ótimo! Essa discussão é bem-vinda. De facto, foi exatamente assim que o Fred e o Kawika surgiram.

Não há nada pior do que conceber e construir uma nova funcionalidade, apenas para descobrir, após o seu lançamento, que as suas suposições sobre o utilizador-alvo estavam erradas. Isso pode ter implicações significativas no fluxo de trabalho e exigir uma revisão completa. É muito melhor investir numa pequena pesquisa de utilizadores para validar os seus pressupostos e garantir que está no caminho certo.

Voltar aos blogues

Conteúdo relacionado

Blogues recentes

Perspectivas do sector

Substituição da VPN legada usando Skyhigh Private Access (ZTNA)

Saurav Raiguru - 8 de maio de 2024

Segurança na nuvem

Proteja os seus dados sensíveis - independentemente do local onde se encontrem

Lolita Chandra - 9 de abril de 2024