A Alice \u00e9 uma empresa de tecnologia com o prop\u00f3sito de tornar o mundo mais saud\u00e1vel. Mas, como toda empresa de tecnologia, precisa lidar com desafios comuns e decidir como vai endere\u00e7\u00e1-los. Este artigo explica um pouco dos problemas relativos a Autoriza\u00e7\u00e3o que enfrentamos, passa pelas alternativas que consideramos e mostra como a solu\u00e7\u00e3o que escolhemos resolve esses problemas (e inevitavelmente acaba criando outros).<\/p>\n
Antes de entrar nos detalhes do tema, \u00e9 importante relembrar a diferen\u00e7a entre Autentica\u00e7\u00e3o e Autoriza\u00e7\u00e3o, dois conceitos que muitas vezes andam juntos mas s\u00e3o fundamentalmente diferentes.<\/p>\n\n
Em resumo, Autentica\u00e7\u00e3o<\/strong> \u00e9 o processo de Identifica\u00e7\u00e3o de um usu\u00e1rio, que garante que ele \u00e9 quem diz ser. J\u00e1 Autoriza\u00e7\u00e3o<\/strong> \u00e9 o processo que indica se um usu\u00e1rio identificado (ou n\u00e3o) tem a permiss\u00e3o para realizar determinadas a\u00e7\u00f5es dentro do sistema.<\/p>\n\n Solu\u00e7\u00f5es e Frameworks que temos dispon\u00edveis para usar podem lidar com um ou ambos aspectos, e \u00e9 importante saber disso porque pode inviabilizar uma escolha. Voc\u00ea pode, por exemplo, ser obrigado a usar o aspecto de Autentica\u00e7\u00e3o da solu\u00e7\u00e3o para que o aspecto de Autoriza\u00e7\u00e3o funcione e, dependendo do caso (como foi na Alice), isso pode n\u00e3o ser desejado.<\/p>\n\n Temos alguns tipos diferentes de Autoriza\u00e7\u00e3o, que cobrem a maior parte das necessidades comuns dos sistemas de mercado. Aqui descrevo os principais:<\/p>\n\n Seu sistema pode ter necessidades de Autoriza\u00e7\u00e3o em qualquer um dos n\u00edveis. No caso, as regras que a Alice precisa suportar s\u00e3o RBAC em sua maioria, com alguns casos de ABAC e ReBAC. Isso significa que a solu\u00e7\u00e3o escolhida precisa tamb\u00e9m suportar esses modelos de autoriza\u00e7\u00e3o; somente RBAC n\u00e3o \u00e9 suficiente (ou envolveria muito improviso para fazer).<\/p>\n\n Sendo uma empresa de sa\u00fade, a Alice evidentemente tem muito contato com informa\u00e7\u00f5es pessoais e de sa\u00fade. Portanto, um mecanismo de Autoriza\u00e7\u00e3o \u00e9 essencial para garantir que dados n\u00e3o sejam acessados ou modificados por pessoas n\u00e3o autorizadas, sejam m\u00e9dicos, enfermeiros ou at\u00e9 o time de atendimento operacional.<\/p>\n Inicialmente optamos por manter a camada de Autoriza\u00e7\u00e3o junto \u00e0 nossa camada compartilhada de acesso a dados (Data-Layer), que j\u00e1 realiza outras atribui\u00e7\u00f5es, como tokeniza\u00e7\u00e3o dos registros, de-identifica\u00e7\u00e3o e afins. Atrav\u00e9s de uma DSL fluida, avaliamos quatro par\u00e2metros essenciais para tomar uma decis\u00e3o de Autoriza\u00e7\u00e3o:<\/p>\n Tamb\u00e9m partimos do princ\u00edpio de \u201cLeast Privilege<\/strong>\u201d, o que significa que qualquer acesso precisa necessariamente ser liberado via a escrita de Policies, ou regras de autoriza\u00e7\u00e3o, na DSL supracitada. Caso contr\u00e1rio, o acesso por padr\u00e3o \u00e9 negado. Essas regras s\u00e3o deployadas junto ao Data-Layer, e toda altera\u00e7\u00e3o das mesmas exige uma nova vers\u00e3o em produ\u00e7\u00e3o para ser efetiva e impactar os usu\u00e1rios finais.<\/p>\n\n A abordagem que inicialmente escolhemos nos permite grande liberdade na tomada de decis\u00f5es de Autoriza\u00e7\u00e3o, mas vem com os seguintes contrapontos:<\/p>\n Com esses aspectos em mente, olhamos para o mercado procurando por uma solu\u00e7\u00e3o de Autoriza\u00e7\u00e3o que suportasse as nossas necessidades, ao mesmo tempo que mitigasse a maior parte poss\u00edvel desses problemas.<\/p>\n\n Um ponto importante na hora de elencar a solu\u00e7\u00e3o: n\u00e3o t\u00ednhamos a inten\u00e7\u00e3o de mudar o mecanismo de Autentica\u00e7\u00e3o utilizado atualmente, o que significa que solu\u00e7\u00f5es que fazem a \u201cvenda casada\u201d com Autoriza\u00e7\u00e3o (por exemplo, keycloak<\/a> e aserto<\/a>) n\u00e3o resolveriam nosso problema.<\/p>\n\n Assim sendo, encontramos duas alternativas mais em linha com o que busc\u00e1vamos:<\/p>\n Ap\u00f3s uma an\u00e1lise minuciosa, preferimos seguir com o OPA, em vez do Oso Cloud, devido a alguns fatores:<\/p>\n Por outro lado, o OPA tem v\u00e1rias caracter\u00edsticas que o tornam uma boa op\u00e7\u00e3o para a gente. \u00c9 open-source, utilizado por algumas grandes empresas, flex\u00edvel e orientado \u00e0 nuvem. \u00c9 escrito em Golang, altamente perform\u00e1tico e capaz de responder a um grande volume de requests de Autoriza\u00e7\u00e3o na casa dos milissegundos \u2013 caracter\u00edstica essencial para nosso caso, pois ter\u00edamos que externalizar as chamadas de autoriza\u00e7\u00e3o, j\u00e1 pagando o custo de lat\u00eancia de rede.<\/p>\n Outra caracter\u00edstica que tornava o OPA mais atrativo era que as regras s\u00e3o escritas na linguagem Rego<\/a> , que apesar de n\u00e3o ser t\u00e3o simples \u00e9 flex\u00edvel o bastante para implementar RBAC, ABAC, ReBAC e outros tipos de controle de acesso. As regras e dados de autoriza\u00e7\u00e3o s\u00e3o alimentados no servi\u00e7o e ficam dispon\u00edveis em mem\u00f3ria, e podem ser substitu\u00eddos em tempo de execu\u00e7\u00e3o.<\/p>\n Al\u00e9m disso, o usu\u00e1rio do OPA \u00e9 quem define o formato do input (os dados de autoriza\u00e7\u00e3o relativos a um dado request) e o formato do output (quais permiss\u00f5es s\u00e3o calculadas e retornadas), ent\u00e3o ele pode ser usado em mais de um contexto.<\/p>\n\n Al\u00e9m de tudo isso, h\u00e1 um forte ecossistema<\/a> em torno do OPA, com v\u00e1rias ferramentas constru\u00eddas para facilitar sua ado\u00e7\u00e3o em escala, e at\u00e9 mesmo uma vers\u00e3o Enterprise<\/a>.<\/p>\n\n Apesar de ser um problema bastante comum no desenvolvimento de sistemas, pode ser desafiador encontrar uma solu\u00e7\u00e3o de Autoriza\u00e7\u00e3o que case bem com as suas necessidades. \u00c9 importante estudar com calma as alternativas, realizar Provas de Conceito em escopos menores e ter um bom plano de migra\u00e7\u00e3o quando j\u00e1 h\u00e1 bastante coisa constru\u00edda no esquema atual.<\/p>\n\n Esse \u00e9 o tipo de problema que faz muito sentido ser endere\u00e7ado pelo time de Plataforma,<\/strong> pois causa um grande impacto ao longo de todas as camadas de desenvolvimento, e precisa de grande apoio das lideran\u00e7as para efetivamente sair do papel.<\/p>\n\n Alice is a technology company with the mission of making the world healthier. But like any tech company, it faces common challenges and must decide how to address them. This article explains some of the authorization-related problems we encountered, explores the alternatives we considered, and shows how the solution we chose solves these problems (while inevitably creating others as well ).<\/p>\n Before diving into the details, it\u2019s important to recall the difference between Authentication and Authorization\u2014two concepts that often go together but are fundamentally different.<\/p>\n In short, Authentication<\/b> is the process of identifying a user, ensuring that they are who they claim to be. Authorization<\/b>, on the other hand, is the process of determining whether an identified (or even unidentified) user has permission to perform certain actions within the system.<\/p>\n The solutions and frameworks available may handle one or both aspects, which is important to consider when making a choice. You might, for example, be forced to use a solution\u2019s Authentication component just to make its Authorization component work. Depending on the case (as was true for Alice), this may not be desirable.<\/p>\n There are several types of Authorization, covering most of the common needs of modern systems. Here are the main ones:<\/p>\n A system may require Authorization at any of these levels. In Alice\u2019s case, most rules follow RBAC, with some cases requiring ABAC and ReBAC. This means the chosen solution must support these Authorization models\u2014RBAC alone wouldn\u2019t be sufficient (or would require excessive workarounds).<\/p>\n As a healthcare company, Alice deals extensively with personal and medical information, making a robust Authorization mechanism essential to ensure that data is accessed or modified only by authorized individuals\u2014whether doctors, nurses, or operational support teams.<\/p>\n Initially, we decided to implement Authorization within our shared Data-Layer, which already handled tasks like tokenizing records, de-identifying data, and other privacy and security measures. Using a fluid Domain Specific Language (code homebrewed for this purpose), we evaluated four key parameters to make Authorization decisions:<\/p>\n We also followed the Least Privilege<\/b> principle, meaning access must be explicitly granted via written Policies in the DSL\u2014otherwise, access is denied by default. These rules were deployed alongside the Data-Layer, requiring a new production release for any changes to take effect.<\/p>\n While this approach gave us flexibility in Authorization decisions, it also introduced some drawbacks:<\/p>\n With these challenges in mind, we looked for an Authorization solution that met our needs while mitigating as many of these issues as possible.<\/p>\n A key requirement in our search: we had no intention of changing our existing Authentication mechanism. This meant solutions that bundled Authentication and Authorization together (such as Keycloak<\/a> or Aserto<\/a>) wouldn\u2019t work for us.<\/p>\n Instead, we found two alternatives that better aligned with our needs:<\/p>\n After a thorough analysis, we decided to go with OPA instead of Oso Cloud for several reasons:<\/p>\n On the other hand, OPA has several characteristics that make it a great option for us. It is open-source, used by some large companies, flexible, and cloud-oriented. It is written in Golang, highly performant, and capable of handling a high volume of authorization requests in milliseconds\u2014an essential feature for our case since we needed to externalize authorization calls while already accounting for network latency costs.<\/p>\n Policies are written in the Rego<\/a> language, which, although not the simplest, is flexible enough to implement RBAC, ABAC, ReBAC, and other access control models. Authorization rules and data are fed into the service, stored in memory, and can be replaced at runtime.<\/p>\n OPA users define the input format (the authorization data related to a given request) and the output format (which permissions are calculated and returned), allowing it to be used in multiple contexts.<\/p>\n Beyond all this, OPA has a strong ecosystem<\/a>, with various tools built to facilitate large-scale adoption and even an Enterprise<\/a> version.<\/p>\n Despite being a common challenge in system development, finding an Authorization solution that fits your needs can be difficult. It’s crucial to carefully study alternatives, run Proofs of Concept in limited scopes, and have a solid migration plan when transitioning from an existing system.<\/p>\n This is the kind of problem that makes sense to be handled by a Platform Team<\/b>, as it impacts all layers of development and requires strong leadership support to be successfully implemented.<\/p>\n\n\n","protected":false},"excerpt":{"rendered":"Como os times de engenharia da Alice trabalharam para lidar com os problemas relativos a Autoriza\u00e7\u00e3o e como a solu\u00e7\u00e3o que escolhemos nos ajuda a resolv\u00ea-los.","protected":false},"author":1,"featured_media":236,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-225","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-alice"],"acf":[],"_links":{"self":[{"href":"https:\/\/alice.com.br\/tech\/wp-json\/wp\/v2\/posts\/225","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alice.com.br\/tech\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alice.com.br\/tech\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alice.com.br\/tech\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/alice.com.br\/tech\/wp-json\/wp\/v2\/comments?post=225"}],"version-history":[{"count":11,"href":"https:\/\/alice.com.br\/tech\/wp-json\/wp\/v2\/posts\/225\/revisions"}],"predecessor-version":[{"id":247,"href":"https:\/\/alice.com.br\/tech\/wp-json\/wp\/v2\/posts\/225\/revisions\/247"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alice.com.br\/tech\/wp-json\/wp\/v2\/media\/236"}],"wp:attachment":[{"href":"https:\/\/alice.com.br\/tech\/wp-json\/wp\/v2\/media?parent=225"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alice.com.br\/tech\/wp-json\/wp\/v2\/categories?post=225"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alice.com.br\/tech\/wp-json\/wp\/v2\/tags?post=225"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Tipos comuns de Autoriza\u00e7\u00e3o<\/h2>\n
\n
\n
\n
\n
\n
\n
Nossa abordagem original de Autoriza\u00e7\u00e3o<\/h2>\n
\n
Problemas<\/h2>\n
\n
Alternativas consideradas<\/h2>\n
\n
\n
Como o OPA endere\u00e7a nossos problemas<\/h2>\n
\n
Conclus\u00e3o<\/h2>\n
——————————————————————————————————-<\/h1>\n\n
What is Authorization? How is it Different from Authentication?<\/b><\/h2>\n
Common Types of Authorization<\/b><\/h2>\n
\n
\n
\n
\n
\n
\n
Our Initial Approach to Authorization<\/b><\/h2>\n
\n
Problems<\/b><\/h2>\n
\n
Considered Alternatives<\/b><\/h2>\n
\n
\n
How OPA Solves Our Problems<\/b><\/h2>\n
\n
Conclusion<\/b><\/h2>\n