BLOG

Estado de entrega de aplicativos 2016: A ascensão da identidade e do acesso a aplicativos

Miniatura de Lori MacVittie
Lori MacVittie
Publicado em 29 de fevereiro de 2016

Antigamente, havia uma relação quase de 1:1 entre portas de rede e aplicativos. Porta 53? Isso é DNS. Porta 22? Conexão SSH Porta 23? Telnet. Porta 80? Esse é o site.

Observe o singular ali. “O” site. Não é “um dos cerca de duzentos aplicativos da web entregues via HTTP”.

Essa é uma distinção importante, pois ajuda a entender a mudança do perímetro do aplicativo da borda (o firewall da rede) para algum lugar mais próximo do aplicativo, no interior do data center (essa é a ala interna para aqueles que ainda estão trabalhando na analogia do "castelo" para segurança).

aplicativos por org soad16

Nossos dados mais recentes mostram que 65% dos aplicativos entregues são baseados em HTTP. O restante inclui os suspeitos típicos: SSH, FTP, SMTP e DNS, entre outros protocolos talvez menos conhecidos. E quantas aplicações existem em uma empresa típica? Nosso Relatório de Entrega de Aplicativos de 2016 diz muito. Quase metade tem entre 1 e 200 aplicativos implantados. A outra metade? Bem, mais de 200. Um número surpreendente de 10% tem mais de 3.000 aplicativos em execução agora.

Mais da metade desses aplicativos são HTTP. Todos eles atravessando a mesma porta no defensor fiel do data center: o firewall da rede. Um firewall de rede que, muito provavelmente, não consegue diferenciar esses aplicativos. Não importa se está entregando JSON ou HTML, se é corporativo ou voltado para o consumidor, se deve ser acessado de um dispositivo móvel enquanto você está em casa ou não.

Elas são cada vez mais importantes para proteger aplicativos. Seja para entender como determinar se uma carga útil de aplicativo está comprometida ou não (JSON não é HTML, não é XML) e se o acesso deve ou não ser permitido de um determinado local ou dispositivo.

desafio de nuvem híbrida idm soad16

Esses são os tipos de perguntas com as quais os serviços de controle de acesso a aplicativos se importam (muito mais do que uma vez). Assim como outros serviços afins de aplicativos , os serviços de controle de acesso a aplicativos são cada vez mais importantes na estratégia de segurança abrangente, precisamente porque podem diferenciar entre aplicativos e aplicar as políticas apropriadas. Eles não estão apenas analisando protocolos e portas, eles estão se aprofundando em toda a conversa, avaliando uma variedade de variáveis (chamamos isso de contexto) para decidir se Bob deve realmente ter permissão para acessar aquele aplicativo altamente confidencial de sua sala de estar.

As organizações estão cientes disso, de acordo com nossa pesquisa. 87% têm 4 ou mais serviços de identidade e acesso implantados hoje. E sem surpresa (para mim, pelo menos), é a categoria de serviços de aplicativos de crescimento mais rápido em 2016, com 50% planejando implementar um deles nos próximos 12 meses. Digo sem surpresa porque o acesso aos aplicativos hoje inclui necessariamente a nuvem, onde os firewalls de rede não conseguem estender o controle sobre o acesso aos aplicativos. Mas os serviços de identidade e acesso podem.

Agora, é certamente verdade que os firewalls de rede continuam sendo o principal serviço implantado pelas organizações, e não espero que isso mude tão cedo. Eles têm e continuarão a servir como um participante significativo na estratégia de segurança de cada organização. Mas, à medida que a nuvem, os dispositivos móveis e a Internet das Coisas continuam a expandir o cenário de aplicativos que devem ser protegidos, continuaremos a ver um aumento na função e na importância do controle de acesso aos aplicativos. Não apenas porque os firewalls de rede não têm mais a visibilidade necessária para diferenciar entre aplicativos entregues pelo mesmo protocolo (HTTP), mas porque eles não são mais o único ponto de entrada para esses aplicativos quando um número significativo deles é implantado lá fora, na nuvem.

Para mais detalhes, não esqueça de pegar o relatório completo 2016 State of Application Delivery .