[SAA] API Gateway 보안

API Gateway – Security

• 세 가지 측면이 존재
  1) IAM 권한
  2) Lambda 권한 부여자
  3) Cognito 사용자 풀

IAM Permissions

• 사용자나 역할에 API 접근 권한을 주고 싶다면 IAM 정책을 사용자나 역할에 연결하면
  API Gateway는 REST API를 호출할 때 IAM 정보를 확인
• 인프라에서 API 접근 권한을 부여할 때 아주 유용
• 이는 Sig v4 (Signature v4)로 불리며 IAM 자격 증명은 다소 복잡하지만 하나의 헤더 안에 있으며 이는 API Gateway로 보내짐
  클라이언트느느 API Gateway를 호출하는데 Sig v4를 사용하고 API Gateway가 IAM으로 하여금 정책을 증명하게 되고
  제대로 과정이 완료되면 백엔드로 가게 됨
  
  

  

• 추가 비용이 없으나 간단한 솔루션이므로 AWS 외부의 사용자에게 권한을 부여해야 한다면 IAM을 사용할 수 없음

Lambda Authorizer (formerly Custom Authorizers)

• Lambda 권한 부여자는 이전에는 사용자 지정 권한 부여자로 알려져 왔음
• 요청의 헤더로 보내지는 토큰을 유효화하는데 Amazon Lambda를 사용
• 인증 결과를 캐시에 저장할 수 있어서 요청이 들어올 때마다 Lambda 권한 부여자를 호출할 필요 없이 한 번만 하면 됨
• 결과를 캐시에 저장하는 건 한 시간이면 가능함 
• OAuth, SAML 등의 타사 인증을 쓰는 경우나 타사에서 제공된 자격 증명을 평가해야 하는 경우에 사용하며
  람다는 권한 부여 결과로 IAM 정책을 사용자에게 반환하며 IAM 정책은 사용자가 API를 호출할 수 있는지 판단
  즉, 클라이언트는 타사 토큰으로 REST API를 호출하게 되면 API Gateway가 Lambda 권한 부여자를 호출해 토큰을 넘기면
  Lambda는 IAM 정책을 반환하여 이를 모두 확인하게 되면 API Gateway가 백엔드와 소통을 하게 됨
  
  

  

  
  

Cognito User Pools

• Cognito 사용자 풀은 Cognito가 사용자 수명 주기를 전부 관리하고 API Gateway는 Cognito에서 자동으로 신원을 증명
  다른 건 실행할 필요없이 전부 대신 실행해주며 무료
• 하지만 Cognito는 인증에만 관여하고 권한 부여는 돕지 못함
  즉, 소통 중인 사용자가 실제로 본인이 맞는지만 확인해 줌
• 클라이언트가 인증하려고 Cognito 사용자 풀을 호출하게 되면 Cognito 사용자 풀은 클라이언트에게 토큰을 돌려주게 되고
  클라이언트는 API Gateway를 REST API로서 호출하고 Cognito 사용자 풀에서 받은 토큰을 넘기게 됨
  API Gateway는 Cognito 토큰이 맞는지 Cognito와 직접 소통한 후 확인하게 되면 백엔드와 소통하게 됨
  이 경우 API Gateway에 대한 제 3의 권한을 부여한다고 할 수 있음
  
  

  

• Google 로그인이나 Facebook에서 이를 지원

API Gateway – Security – Summary

• IAM
  AWS 계정에 이미 사용자나 역할이 있을 경우 사용하며
  IAM 정책을 통해 인증과 권한 부여를 관리하고 Sig v4를 이용
• Custom Authorizer
  관리하지 않는 타사 토큰이 있을 때 사용하며 어떤 IAM 정책이 반환될 지 모르므로 유동적
  만약 IAM 정책을 반환하며 Lambda 호출마다 요금을 내게 되며
  권한 부여를 위해 람다 함수로 보내는 호출 수를 제한하고자 캐싱을 사용할 경우에
  캐시가 무효화되면 람다 함수를 매번 수없이 호출해야 함
• Cognito User Pool
  사용자 풀을 직접 관리해야 하지만 사용자 지정 코드를 많이 쓸 필요가 없음
  인증 패턴은 제공하지만 권한 부여 패턴을 제공하지 않으므로 백엔드에서 반드시 권한 부여 계층을 실행해야 함