Há muita ênfase na abordagem de confiança zero no que diz respeito ao acesso. Olhando além da autenticação (o ato de verificar se alguém é quem diz ser), avaliar a autorização é tão importante quanto determina o que alguém pode fazer com esse acesso. As políticas devem ser escritas para explicar isso, e as políticas mais fortes são construídas sobre um modelo de autorização que é orquestrado na natureza.
Uma abordagem orquestrada e centralizada para a autorização constrói políticas dinâmicas e de controle de acesso fino (FGAC) que atendem às demandas de estratégias modernas de segurança, incluindo confiança zero. Tomar uma abordagem de confiança zero para a construção de políticas elimina a confiança absoluta da equação, validando continuamente os usuários em todas as camadas do aplicativo com base em um conjunto ou combinações de atributos coletados de múltiplas fontes (ou seja, quem, o que, onde, quando, por que, como, etc.).
O conceito de autorização não é novo, e muitas organizações construíram políticas ad-hoc no passado à medida que criaram ou adotaram novas aplicações, isoladas dentro de cada aplicativo. Uma vez criados, eles eram muitas vezes esquecidos. Mudar para uma abordagem orquestrada de autorização remove a abordagem siloed e substitui-a por uma visão centralizada e abrangente das políticas. Isso significa que as organizações não criam novas políticas do zero à medida que cada novo aplicativo é adicionado. Em vez disso, eles selecionam entre as políticas existentes, copiando e modificando conforme necessário para se beneficiar do trabalho passado. Além disso, por ser centralizada, quando uma mudança para uma política existente deve ser feita, ela pode ser feita nessa mesma abordagem “de um para muitos”, economizando tempo valioso e garantindo melhor segurança.
Uma política baseada em autorização centralizada orquestrada em uma empresa requer vários elementos-chave obtidos através do processo de modelagem de políticas. Há quatro etapas-chave para este processo.
Identificando aplicativos
O primeiro passo que uma organização precisa dar ao se mudar para esse modelo é identificar quantos aplicativos ou fontes de dados requerem uma abordagem de confiança zero. Isso é importante, pois força uma triagem de tipos de quais aplicativos e fontes de dados são os mais cruciais e devem ser os alvos iniciais para a implantação. A maioria das organizações de tamanho corporativo agora usa centenas de aplicativos. Ir de zero a sessenta em termos de aplicação de políticas a TODAS elas imediatamente não é realista. O passo de identificação é determinar quais são os mais importantes para enfrentar primeiro. Outros são adicionados ao longo do tempo e à medida que mais políticas são construídas, fazê-lo se tornará muito mais eficiente. Este primeiro passo permite uma abordagem “comece pequeno, cresça rápido”.
Determining requirements
The next step is determining what the requirements are. During this phase of the project, it is critical for security and/or identity leaders (who own this centralized process) to involve business stakeholders (application or product owners) from the start.
Os requisitos devem ser orientados pelo negócio. Agora, alguns podem apontar que a empresa pode não entender os meandros dos recursos e protocolos de soluções de gerenciamento de identidade e acesso (IAM), mas eles entendem as informações que seus acessos a aplicativos e como essas informações são impactadas pelas regulamentações de conformidade. Portanto, com base na orientação fornecida pelo negócio, os requisitos devem ser escritos em uma linguagem natural que seja facilmente compreendida tanto pela empresa quanto pela equipe de TI.
Considerando atributos
Agora que os requisitos são estabelecidos, identificar os atributos certos necessários para informar políticas e controles de autorização é o próximo passo lógico.
Por exemplo, digamos que um dos requisitos para um determinado aplicativo ou fonte de dados é que nenhum usuário fora da União Europeia (UE) possa ver informações pessoalmente identificáveis (PII) a partir de dados de clientes onde o país de origem do cliente está na UE. Imediatamente, podemos considerar alguns atributos que serão necessários para essa exigência, sendo um deles a localização física do usuário solicitando acesso ao aplicativo, e o segundo sendo o país de origem do registro que o usuário está procurando acessar. Provavelmente haveria outros atributos que poderiam ser considerados, como a função do usuário, em que dispositivo eles estão, a pontuação de risco do usuário, a hora do dia e assim por diante, mas isso lhe dá uma ideia do tipo de atributos que podem ser considerados.
Note-se que não há limite de quantos atributos uma organização pode considerar ou a complexidade de uma política em termos dos requisitos que você está tentando alcançar, então o objetivo é identificar os atributos certos (qualidade versus quantidade) para equilibrar efetivamente a segurança com o desempenho. Contexto é a consideração fundamental e que pode ser decifrado com base nos atributos avaliados. Por exemplo, considerar a localização física de um usuário juntamente com o tempo da solicitação pode fornecer uma grande quantidade de contexto que pode não ser considerado de outra forma.
Aqui está um exemplo:

Políticas de autoria
O passo final de uma abordagem centralizada e orquestrada – e onde entra em ação o conceito de confiança zero – está na autoria política. Com as três primeiras etapas concluídas, agora é hora de escrever as políticas a serem implantadas em toda a organização.
Essas políticas podem ser tão simples ou complexas quanto necessárias para alcançar objetivos organizacionais globais. Uma política segue o padrão de escrever IF, then declarações sobre o assunto, o recurso ou objeto e a ação. É importante evitar qualquer confusão aqui em torno de outras soluções IAM que possam aproveitar o controle de acesso baseado em papel (ou RBAC) como parte de seu processo de autenticação. Embora importante, o que este passo se refere é uma política que entra em vigor após a autenticação. Há muitos casos em que um usuário pode ser autenticado, mas uma política pode limitar que ação ele pode tomar ou quais informações eles podem ver. Considerando o exemplo incluído na última etapa, a política pode ser algo assim:

As políticas de autoria devem criar uma árvore de decisão que ainda possa permitir que as empresas sejam conduzidas sob as condições certas, protegendo informações confidenciais. Nesse contexto, aqui está um exemplo do que poderia ser feito para a mesma política onde a resposta a uma das perguntas é não.

A linha de fundo é que o cerne da metodologia de confiança zero é nunca confiar e sempre verificar. Ao aproveitar uma abordagem centralizada e orquestrada para os líderes de autorização, segurança e/ou identidade podem facilmente criar políticas tão complexas ou simples quanto necessário. O uso dessa abordagem garante que a organização esteja verificando quantos atributos for necessário, fornecendo o contexto correto para tomar uma decisão de acesso precisa e razoável.
FONTE: HELPNET SECURITY