O que é importante em um modelo de política para microssegmentação?

De todos os recursos a serem discutidos em uma solução de microssegmentação, a maioria dos fornecedores não começaria com o modelo de política. No entanto, em termos do resultado potencial que uma determinada solução pode criar, o modelo de política determina o que é possível. Portanto, pensar no que é necessário em um modelo de política é uma excelente preparação para tomar uma decisão de compra de alta qualidade e com baixo arrependimento. Vamos examinar cada um dos componentes importantes de um modelo de política de microssegmentação desejável.

Etiquetas multidimensionais

As políticas de microssegmentação usam rótulos para abstrair a segmentação dos dispositivos e endereços de rede subjacentes. Idealmente, esses rótulos serão “úteis e multidimensionais”. Um namespace simples de rótulos ilimitados não é útil; ele não oferece nenhum resumo ou estrutura para pendurar declarações de políticas que afetam muitas máquinas. Se você rotular cada sistema em um namespace simples, não é melhor do que apenas usar endereços IP para especificar a política. Curiosamente, embora nenhum limite deva ser colocado no número de rótulos em uma determinada dimensão política, restringir as dimensões políticas tem se mostrado útil em implantações em grande escala.

Nós humanos podemos visualizar facilmente quatro dimensões: três dimensões físicas mais o tempo, por exemplo. Mas, se os físicos estiverem corretos e vivermos em um espaço de 11 ou 13 dimensões, somente a matemática pode capturar essas dimensões. Eles são impossíveis de visualizar em nossos cérebros. Isso tem consequências práticas para a microssegmentação. Você pode programar um computador para entender e computar uma política de 11 dimensões, mas nenhum ser humano será capaz de entendê-la. Os humanos precisam ser capazes de inspecionar, auditar e entender as políticas de microssegmentação.

In our experience, four dimensions can effectively model even the largest networks on the planet for policy purposes, while still preserving our ability to understand the model. So, look for a policy model that has more than flat-tag or label space. The structure of a few dimensions works at the scale of hundreds of thousands of systems but remains easy to understand and work with. Check out this video to learn more about the power of labels.

Modelo de objetos ricos

A quality policy language will have a sufficiently rich-object model. A hyperscale enterprise data center is a complex place. It is obvious that the model must accommodate everything that needs to be protected: servers, VMs, containers, cloud instances, etc. But these protected systems are not enough to abstract all the useful policy primitives. You need to have objects for service/port mappings and IP-address ranges. Within shared servers – perhaps a server with multiple database instances – you must be able to abstract these instances from each other as distinct virtual services. Containers and container hosts should be both “first-class citizens” who appear on all visualizations and a part of policy statements. Interestingly, it is also important to add unprotected systems to the object model – especially in the early phases of deployment when more things are unprotected than protected and these systems communicate with each other. Being able to represent all flows cleanly makes it much easier to specify the desired policy. The best solutions will even be able to build policies for the unmanaged objects should you wish to have it available for export and possible implementation.

Herança

Policy inheritance is the only way to scale microsegmentation policy to cover an existing data center. If about 80 percent of the traffic flows within the data center, that implies that the existing perimeter firewall rules only cover 20 percent of the traffic. That means that the potential for five times as many rules exists within the data center as currently exist in all the firewalls! The abstractions provided by the policy model and its useful dimensionality must combine with a pure allow-list policy model. Only in this way can policy be written once to apply in many instances. Inheritance and smart policy automation around common microsegmentation policies, like application ringfencing, combine to form the only proven way to segment tens of thousands of systems successfully.

Declarativo versus imperativo

The only policy model to successfully microsegment over 100,000 workloads uses a declarative method to express segmentation desire. A declarative policy model only requires one to specify the desired outcome. An imperative policy model requires the solution to be specified exactly to create the outcome. A traditional firewall ruleset is imperative: every statement must be present in perfect order and with perfect accuracy for the desired protection to exist. This causes no end of difficulty and complexity. However, the ideal microsegmentation policy uses declarative language exclusively: “I want to ringfence the Ordering application inside my Production environment.” How that is accomplished is the business of the Policy Compute Engine behind the policy language. In this way, the policy is always easy to specify, easy to understand, and easy to develop. Given the scale of work to be done, anything else will result in failure.

Aplicação consistente

When all the necessary primitives exist, the best microsegmentation solutions will use them consistently across every area of the product. Labels aren’t just for policy authoring, but must inform visibility, policy distribution, and policy enforcement. Role-based access control (RBAC) should follow the label structure exactly so that application owners, DevOps, and others can access everything they need, but not more. Securing automated deployments in particular demands this precise delegation capability. A useful, clear, and simple label structure creates a mental model when it is consistently applied. Almost immediately, administrators intuitively understand how the solution works and can anticipate outcomes. This intuition quickly turns to speed, speed to mastery, and mastery to finished projects. Simplicity, clarity, and consistency are the solution for complex data center environments.

Abstração completa

Gosto de dizer que a automação consome metadados no café da manhã. A automação não pode prosseguir mais rápido do que pode ser abstraída. Um modelo de política bem-sucedido precisa abstrair quaisquer vestígios de endereçamento de rede e do próprio mecanismo de fiscalização. A política deve lidar apenas com o que é desejado. Dessa forma, a automação pode facilmente indicar o resultado: “A Web deve conversar com o aplicativo”. As regras necessárias para tornar isso realidade mudarão constantemente em uma nuvem dinâmica ou em um ambiente automatizado, e essa complexidade não pode ser exposta à estrutura de automação se ela for escalável. Uma política que se baseia em endereços IP, por mais bem-intencionada que seja, simplesmente não será escalável. Da mesma forma, o mecanismo de fiscalização deve estar oculto. Uma vez declarado o desejo, o mecanismo de política de microssegmentação deve descobrir a melhor maneira de implementar essa política, considerando os recursos que conhece. Dessa forma, à medida que os sistemas vão e vêm, o número de pontos de fiscalização diminuirá, assim como a base de políticas e regras. Somente uma política totalmente abstrata fornecerá aos arquitetos de DevOps e de nuvem os recursos necessários para interagir perfeitamente com a solução de microssegmentação.

Política em grande escala

Há muitos anos, a megafauna dominava a Terra. Versões gigantes de plantas e animais estavam em todos os continentes e superariam as espécies que temos hoje. Os melhores modelos de políticas incluem fatores de escala que superam as descrições simples de aplicativos individuais. A capacidade de agrupar qualquer rótulo em qualquer dimensão de política permite que políticas únicas afetem sistemas em vários data centers, ambientes ou aplicativos. Ao elaborar políticas para empresas de hiperescala, essas “megapólices” se movem com alcance, velocidade e eficiência surpreendentes para cobrir a empresa com políticas de microssegmentação.

A policy model might seem like an abstract and unimportant concept. But for a successful microsegmentation deployment, nothing could be further from the truth. The policy model determines what will and will not be possible to express and how easy or hard it will be to do so. A company can quickly change the color of their UI, but it will struggle to fix a broken or improperly designed policy model. The most proven microsegmentation policy model in the world provides full abstraction from network addressing and enforcement points though a “usefully dimensional” label model. This model is consistently carried through every function of the product. When full object models combine with inheritance and declarative models, it is possible to easily and quickly state the desire outcome and have it be true in the world. Microsegmentation succeeds at the scale of hundreds of thousands of workloads only through a mature, complete, and well-designed policy model.

A seguir, nesta série sobre perguntas sobre microssegmentação que você não sabe fazer, discutiremos o que é necessário para automatizar a política de microssegmentação.