Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[TDC 2021/03] Segurança em Microservices: Como ...

Vinicius
March 23, 2021

[TDC 2021/03] Segurança em Microservices: Como ? Onde ? Por que ?

Autenticação & Autorização
OAuth 2.0
OpenID Connect
JSON Web Token (JWT)
Red Hat Single Sign ON
API Gateway
Service Mesh

Vinicius

March 23, 2021
Tweet

More Decks by Vinicius

Other Decks in Technology

Transcript

  1. 1

  2. 2 • Assoc Principal Solution Architect Red Hat (+8) •

    Middleware Team Lead • Teacher MBA Impacta • AppDev, Cloud, Hybrid Cloud, DevOps • Microservices, Kubernetes, CloudNative • +15 anos Trabalhando com TI (EDS, Tata) • Systems Integration, Middleware, Security • Data Processing (FATEC-BS) • Business Administration (FGV) • Distributed Software Architecture (PUC MG) • Linkedin • Twitter • Github
  3. Segurança em Microservices: Como ? Onde ? Por que ?

    3 Application “A” Application “B”
  4. Segurança em Microservices: Como ? Onde ? Por que ?

    4 Application “A” Application “B”
  5. Segurança em Microservices: Como ? Onde ? Por que ?

    5 Application “A” Application “B”
  6. Segurança em Microservices: Como ? Onde ? Por que ?

    6 Application “A” Application “B” Identity
  7. Segurança em Microservices: Como ? Onde ? Por que ?

    7 Application “A” Application “B” Identity
  8. Segurança em Microservices: Como ? Onde ? Por que ?

    8 Application “A” Application “B” Identity Sync
  9. Segurança em Microservices: Como ? Onde ? Por que ?

    9 Application “A” Application “B” Identity Sync Source of Truth Inconsistencies
  10. Segurança em Microservices: Como ? Onde ? Por que ?

    10 Application “A” Application “B” Identity
  11. Segurança em Microservices: Como ? Onde ? Por que ?

    11 Application “A” Application “B” Identity “External Access” “No direct connectivity”
  12. Segurança em Microservices: Como ? Onde ? Por que ?

    12 Application “A” Application “B” Identity “External Access” “No direct connectivity”
  13. Segurança em Microservices: Como ? Onde ? Por que ?

    13 Application “A” Application “B” Identity Format ?
  14. Web UI Primariamente Aplicações WEB (ASP, PHP, Java, .NET) com

    soluções pouco interoperáveis proprietárias para cada plataforma Single Sign ON Geralmente implementando através de Cookies Dispositivos Móveis Inexistência do conceito de "Mobilidade" Redes Sociais Identidades Externas, APIs, Parceiros, Experiência Digital Segurança em Microservices: Como ? Onde ? Por que ? 14 Um pouco da nossa história... Autenticação & Autorização
  15. Segurança em Microservices: Como ? Onde ? Por que ?

    Autenticação & Autorização 15 Contexto Atual e suas Respectivas Necessidades Experiências homogêneas ao usuário independente do device Mobilidade Adoção de protocolos como OAuth/OpenID como fundações e modelos para estratégias de APIs Padrões da Indústria Inclusão de agentes externos principalmente redes sociais como catalisadores de novos clientes/parceiros Redes Sociais Legislações, Compliance Marco Cívil da Internet GLPD Privacidade
  16. Tópicos Segurança em Microservices: Como ? Onde ? Por que

    ? 16 • Autenticação & Autorização • OAuth 2.0 • OpenID Connect • JSON Web Token (JWT) • Red Hat Single Sign ON
  17. Autenticação & Autorização Autenticação 17 Quem é ... ? https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf

    https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md The process of establishing confidence in the identity of users or information systems. Authentication is the process of verifying that an individual, entity or website is who it claims to be. Authentication in the context of web applications is commonly performed by submitting a username or ID and one or more items of private information that only a given user should know.
  18. Autenticação & Autorização Autorização 18 O que pode ser feito

    ? https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf https://www.owasp.org/index.php/Category:Access_Control The right or a permission that is granted to a system entity to access a system resource. Access Control, also known as Authorization — is mediating access to resources on the basis of identity and is generally policy-driven (although the policy may be implicit)...also govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects).
  19. Tópicos RH-SSO Workshop 19 • Autenticação & Autorização • OAuth

    2.0 • OpenID Connect • JSON Web Token (JWT) • Red Hat Single Sign ON
  20. OAuth 2.0 OAuth 2.0 20 Authorization Framework..Delegated Authorization Source: https://tools.ietf.org/html/rfc6749

    The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf ▸ Papéis & Responsabilidades ▸ Fluxos, Endpoints ▸ Formato do Token! ▸ Meios para obter identidade do usuário!
  21. An entity capable of granting access to a protected resource.

    When the resource owner is a person, it is referred to as an end-user. OAuth 2.0 OAuth 2.0 21 Papéis e Responsabilidades Source: https://tools.ietf.org/html/rfc6749#section-1.1 An application making protected resource requests on behalf of the resource owner and with its authorization. Client The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. Authorization Server Resource Owner The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. Resource Server
  22. Access Token Access tokens are credentials used to access protected

    resources. An access token is a string representing an authorization issued to the client Token Type The access token type provides the client with the information required to successfully utilize the access token to make a protected resource request (along with type-specific attributes) Refresh Token Refresh tokens are credentials used to obtain access tokens. Scope The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued. OAuth 2.0 22 Access Token OAuth 2.0 Source: https://tools.ietf.org/html/rfc6749#section-1.4 https://tools.ietf.org/html/rfc6749#section-7.1 https://tools.ietf.org/html/rfc6749#section-1.5 https://tools.ietf.org/html/rfc6749#section-3.3
  23. Tópicos OpenID Connect 23 • Autenticação & Autorização • OAuth

    2.0 • OpenID Connect • JSON Web Token (JWT) • Red Hat Single Sign ON
  24. OpenID Connect OpenID Connect 24 Identity Layer sob OAuth 2.0

    Source: https://openid.net/specs/openid-connect-core-1_0.html#Introduction OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. ▸ Papéis & Responsabilidades ▸ Fluxos, Endpoints ▸ Token de Identidade ▸ Formato, Claims e Escopos
  25. Tópicos OpenID Connect 25 • Autenticação & Autorização • OAuth

    2.0 • OpenID Connect • JSON Web Token (JWT) • Red Hat Single Sign ON
  26. JSON Web Token (JWT) JSON Web Token (JWT) 26 Identity

    Layer sob OAuth 2.0 Source: https://tools.ietf.org/html/rfc7519 JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. ▸ Formato (Header, Claims, Assinatura) ▸ Criptografia ▸ Assinatura ▸ Tipos
  27. JSON Web Token (JWT) JSON Web Token (JWT) 27 Identity

    Layer sob OAuth 2.0 { "alg": "HS256", "typ": "JWT" } { "iss": "joe", "exp": 1300819380, "human": true, "over 18": true } eyJhbGciOiJIUzI1NiIsIn R5cCI6IkpXVCJ9.eyJp c3MiOiJqb2UiLCJleHAi OjEzMDA4MTkzODAsI mh1bWFuIjp0cnVlLCJv dmVyIDE4Ijp0cnVlfQ.0 LtIxMRXW0VItgVqhQ GUJCEjzWpnXptQO Wxn9wGDyW4 Header Payload JSON Web Token Hash
  28. Tópicos RH-SSO Workshop 28 • Autenticação & Autorização • OAuth

    2.0 • OpenID Connect • JSON Web Token (JWT) • Red Hat Single Sign ON
  29. RH-SSO Workshop - Red Hat Single Sign ON Red Hat

    Single Sign On 29 Identity Access Manager Source: https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.3/html-single/release_notes/index#overview RH-SSO is based on the Keycloak project, and enables you to secure your web applications by providing Web SSO capabilities based on popular standards such as OpenID Connect, OAuth 2.0, and SAML 2.0. The RH-SSO server acts as an OpenID Connect or SAML-based identity provider (IdP), allowing your enterprise user directory or third-party IdP to secure your applications via standards-based security tokens. ▸ Padrões da Indústria (OAuth, OpenID, SAML, Kerberos) ▸ Federação de Usuários ▸ Broker de Identidades ▸ Gestão de Usuários e Sessões
  30. RH-SSO Workshop - Red Hat Single Sign ON Red Hat

    Single Sign On 30 Identity Access Manager
  31. Segurança em Microservices: Como ? Onde ? Por que ?

    31 Application “A” Application “B”
  32. Segurança em Microservices: Como ? Onde ? Por que ?

    32 Application “A” Application “B” Authorization Server
  33. Segurança em Microservices: Como ? Onde ? Por que ?

    33 Application “A” Application “B” Authorization Server { “scopes”: openid profile email "family_name": "Martinez", "given_name": "Vinicius", "Name": "Vinicius Branda", "Preferred_username": "[email protected]” "sub": "Red Hat" }
  34. Segurança em Microservices: Como ? Onde ? Por que ?

    34 Application “A” Application “B” Authorization Server { “scopes”: openid profile email "family_name": "Martinez", "given_name": "Vinicius", "Name": "Vinicius Branda", "Preferred_username": "[email protected]” "sub": "Red Hat" } 200 400
  35. Segurança em Microservices: Como ? Onde ? Por que ?

    35 https://www.company.com Affiliate Website Mobile Partner Widget Internet Shipping Web plan Mobile plan Widget Customers Finance Tracking Logistics $ API Consumers API Products API Backends http://api.widget.local https://database.api/custrs https://finance.dept wss://tracking/api/v1 https://gds.log/api https://widget.company.com https://shipping.company.com Enterprise Boundary
  36. Segurança em Microservices: Como ? Onde ? Por que ?

    36 “..The API gateway might also implement security, e.g. verify that the client is authorized to perform the request” “..must use either the Client-side Discovery pattern or Server-side Discovery pattern” “..may authenticate the user and pass an Access Token containing information about the user to the services” “..will use a Circuit Breaker to invoke services”
  37. Segurança em Microservices: Como ? Onde ? Por que ?

    37 ACHIEVE FASTER API RELEASES Successful firms with an agile integration strategy release/update APIs weekly or daily, nearly three times more frequently than less successful firms. We remain concerned about business logic and process orchestration implemented in middleware, especially where it requires expert skills and tooling while creating single points of scaling and control. Vendors in the highly competitive API gateway market are continuing this trend by adding features through which they attempt to differentiate their products. This results in overambitious API gateway products whose functionality — on top of what is essentially a reverse proxy — encourages designs that continue to be difficult to test and deploy. API gateways do provide utility in dealing with some specific concerns — such as authentication and rate limiting — but any domain smarts should live in applications or services.
  38. Segurança em Microservices: Como ? Onde ? Por que ?

    39 North-South Management East-West Management Microservic e Microservic e MS 1 MS 2 MS n Microservices group A Microservic e MS 1 MS 2 MS n Microservices group B API Product Enterprise boundary External facing APIs Internal facing Microservice
  39. Use cases 40 • Manage who can access my APIs

    • Manage how they can access my APIs, configuring contracts & limits • Developers can find my services & sign up for a plan • Ability to package multiple services into one API product • Get insights on usage of my APIs API Management Managing relationships • Application performance, debugging, analytics data, incident management • Security (mTLS, RBAC) • Resiliency • Traffic routing • Infrastructure rate limiting based on multiple sources Service mesh management Advanced traffic management • Send invoices and charge developers for API usage API Management External APIs Segurança em Microservices: Como ? Onde ? Por que ?
  40. 41