Transferir como PDF, PPTX
Carregado porLuis Moraes Junior
Deck apix 2017 design & security - case cielo lio
1) O documento discute princípios de design e segurança de APIs, incluindo versão de API, REST pragmático, e se um tamanho serve a todos. 2) É debatido se as APIs devem ter um tamanho único ou serem personalizadas, com exemplos de ambas as abordagens. 3) Aspectos de segurança como autenticação, autorização, disponibilidade, privacidade e integridade são cobertos.
![[ATC2021] Distribuição de Testes em Diferentes Camadas](https://cdn.slidesharecdn.com/ss_thumbnails/atc2021-distribuicaodetestesemdiferentescamadas-211112021519-thumbnail.jpg?width=640&height=640&fit=bounds)
![PHP Experience 2016 - [Workshop] APIs bem desenhadas como base para integrações](https://cdn.slidesharecdn.com/ss_thumbnails/09h00josevahl-160331182010-thumbnail.jpg?width=640&height=640&fit=bounds)
Deck apix 2017 design & security - case cielo lio
- 1. Cielo LIO Design &Security Rafael Rocha rafael.rocha@sensedia.com +55 19 9 9649.1506 Luis Moraes luis.junior@cielo.com.br +55 19 9 98118.8160
- 4. DESIGN DE APIs info: version:0.0.1 title: My API
- 5. - API Version -Pragmatic REST - One size fits all ? Some Trends
- 6. Versão URI: https://api.cielo.com.br/order-management/v1/orders HTTP ou HTTPS Seudomínio Nome da API (opcional) Recursos e Parâmetros Outras alternativas: • Hostname (v1.api.foo.com) • Query parameter (api.foo.com/v1/bar?version=1) • Content-type header • No version Nunca quebre o cliente!! API Version na URI
- 7. Pragmatic REST - URIs sãoprojetadas com cuidado - Cada URI representa um recurso - Cada ação em um recurso é feita através do verbo HTTP - O resultado é expresso pelo status HTTP
- 8.
- 10. 200 400 500 Resultado OK Erro noCliente Erro no Servidor 201 Criado 202 Aceio 401 NãoAutorizado 405 Operação nãopermitida 413 Request muito grande 429 Muitas requisições 503 Servidor não disponível HTTP Status Code
- 11. Código Erro 200 OK 201Created 204 Empty 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 413 Request is to Large 422 Unprocessable Entity 429 Too Many Requests 500 Internal Server Error
- 12. Código Erro 200 OK 201Created 204 Empty 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 413 Request is to Large 422 Unprocessable Entity 429 Too Many Requests 500 Internal Server Error
- 13. Resource POST (create) GET (read) PUT (update, create) DELETE (delete) /ordersCria novo pedido Lista pedidos -- Apaga todos os pedidos /orders/3747 -- Mostra pedido 3747 Atualiza pedido 3747, se não existir, cria Apaga pedido 3747 HTTP Method
- 14. One size fitsall: YES or NO ?! Faz sentido ter a mesma API para todos os desenvolvedores ?
- 15. One size fitsall: YES ! Porque sim ? > Time de API pode manter o foco em apenas UMA única API, precisa e bem documentada. > Reduz os custos com treinamento dos times de desenvolvimento. > Pode suportar um conjunto abrangente de desenvolvedores, mesmo ainda com perfis desconhecidos. Mas: > Trata todos os clientes de forma generalizada, não há otimização para ninguém. > Time de API se torna uma pedra no sapato do Time de Frontend/UI.
- 16. One size fitsall: NO ! Porque não ? > Algumas diferenças comuns entre clientes: > Capacidade de Memória > Markup types diferentes (XML vs JSON vs FLAT) > Conectividade > Modelo de interação com usuário > Volume de acessos > Separar os conceitos: > Conteúdo > Formato > Entrega > Superar as diferenças de devices plugados na API
- 17. One size fitsall: YES or NO ?! > Alternativa: Porque não ter as duas opções ?
- 18. One size fitsall: YES ! - Exemplo
- 19. One size fitsall: YES ! - Exemplo
- 20. One size fitsall: NO ! - Exemplo
- 21. One size fitsall: NO ! - Exemplo
- 22. One size fitsall: NO ! - Exemplo https://desenvolvedores.cielo.com.br/
- 23.
- 24. Restricted Restritas a parceirosautorizados Open Abertas para qualquer desenvolvedor Private Uso limitado a equipes internas da empresa TIPOS DE APIs
- 25.
- 26.
- 27.
- 28. Usuários Apps Basic HTTPOAuth2 OpenID Connect Estratégias de Autenticação / Autorização App Token
- 29. Basic HTTP App Token OAuth2 OpenIDConnect ❖ Protocolo de autorização que provê acesso seguro aos resources delegado pelo dono dos dados ❖ Client App se registram com Client ID / Secret e Redirect URL ❖ São 4 tipos de “Authorization Grants” para acesso às APIs com fluxos diferentes
- 30.
- 32.
- 33. Disponibilidade ❖ Monitorar otráfego nas APIs (preferencialmente com alertas) ❖ Identificar comportamento malicioso ❖ Limitar o uso dos Apps ❖ Plugar detecção de Fraude de negócio
- 34.
- 35. Disponibilidade Client Apps APIs Rate LimitingPolicy JSON Threat Policy Payload Size Policy IP Filtering Policy … API Gateway Powered by
- 36. Payload Size: HTTP413 - Payload is too large & Rate Limit HTTP 429 - Too many requests
- 37.
- 38. ❖ Use sempreSSL/TLS ❖ Algumas situações podem requerer criptografia adicional Use algoritmos já comprovados (AES) ❖ Informações sensíveis devem ser mascaradas (Número de cartão de crédito, Tokens etc) ❖ Error Handling Não exponha detalhes do backend (sem stacktrace) Privacidade
- 39. https://api.cielo.com.br/order-management/ v1/orders { "number":"0992f1d5cee540d9a9648f4d6a9e4aa6", "reference":"PEDIDO #1234", "status":"DRAFT", "items":[ { "sku":"ede8f84a8b8645cb8e576a593c25c6ed", "name":"produto 1"........ { "transaction_type":"PAYMENT", "status": "CONFIRMED", "Terminal_number":"77102XXX", ....
- 40.
- 41. Auditoria ❖ Armazenar oslogs com as chamadas realizadas (especialmente as críticas) ❖ Cuidados especiais: ❖ Os Logs podem crescer (e muito) ❖ Logs em arquivo nem sempre são fáceis de inspecionar / buscar ❖ Dados sensíveis devem ser obfuscados
- 42.
- 43.
- 44. ❖ Reduza aSuperfície de Ataque O que não pode ser acessado nem deve ser mostrado ❖ Prevenção de XML, JSON e SQL Injection Filter Input, Escape Output Integridade
- 45. ❖ Utilize ChavesOpacas: Integridade /pedidos/W3eRK09xW45Ful /pedidos/9839920
- 46.
- 49. Luis Moraes luis.junior@cielo.com.br +55 199 98118-8160 https://desenvolvedores.cielo.com.br Obrigado!Rafael Rocha rafael.rocha@sensedia.com +55 19 9 9649-1506