사용자 인증을 위해 맞춤 API 게이트웨이 인증 프로그램을 사용하는 AWS Lambda/zappa에 "서버가없는 API 서버"를 사용하려고합니다. serverless AWS lambda 서비스에는 코드 컨트롤러에서 직접 발행 된 JWT 토큰을 직접 확인하는 대신 사용자 정의 권한 부여 도구를 사용할 때 상당한 보안 또는 비용 이점이 있습니까? 코드로 확인하는 것이 더 편리 할 수 있습니다.AWS API Gateway 사용자 정의 권한 부여 프로그램이 유용합니까?
업데이트 사전 요청 후크를 보내지 만 헤더 레벨 승인자가 있으므로 CORS에 사용하기가 더 쉽지만 zappa에서는 지원하지 않습니다. 또한 Swagger 업로드를 통해 Options 용 모의 API를 설정하는 것이 가능할 수 있으며, 성공하면 업데이트됩니다.
엄밀히 말하면 보안 또는 비용 이점이 있다고 생각하지 않습니다. 이점은 권한을 처리하는 단일 코드, 즉 단일 코드라는 것입니다. API 뒤에 배치 된 모든 단일 람다 함수에서 해당 인증 코드를 복제하지 않아도됩니다. 또한 인증 로직을 변경하기 위해 단일 기능을 갱신 할 수 있습니다.
승인 논리에 대해 single source of truth을 제공하고 separation of concerns을 구현할 수 있다는 관점에서 보면 응용 프로그램의 보안을 향상시킬 수 있다고 할 수 있습니다.
즉, 전체 API가 단일 람다 함수로 구성된 경우 이점은 다소 모호합니다. 제 생각에는 API 게이트웨이 맞춤 정의 인증 기가 API에 많은 Lambda 기능이 있거나 API 게이트웨이가 기존 HTTP 서버 앞에 앉아있을 때 실제로 유용하게 사용한다고 생각합니다.
@ 마크 B는 훌륭한 답변을합니다. 나는 분명히 그의 답변에서 어떤 것도 논박하지 않습니다. 그럼에도 불구하고 나는 대화에 기여하고 싶습니다.
JWT가 어디서 왔는지, 어떻게 획득, 사용 및 새로 고침되는지에 따라보다 구체적인 답을 얻을 수 있습니다. 사용자 지정 권한 부여를 사용하면 이러한 시나리오에서 의미가 있습니다
사용 사례는 인증의 몇 가지 다른 맛 뒤에 하나의 람다을 확보하려면 1
사용자의 권한 부여 프로그램이 유용 할 수 있습니다. 예를 들어, 각각 동일한 람다를 호출하지만 별개의 인증자를 사용하는 세 가지 다른 API 게이트웨이 엔드 포인트를 작성할 수 있습니다. 이것은 DRY 혜택에 대한 Mark의 관점과 관련이 있습니다.
사용 사례 2
사용자의 권한 부여 프로그램은 당신에게 인라인 사용자의 권한 부여 코드에서 IAM 권한을 구축 할 수있는 능력을 여유. 기존 IAM 역할을 호출자에게 할당하는 대신 원하는 임의의 권한 집합을 작성할 수 있습니다. 어떻게 든 (신뢰할 수없는) 사용자 입력을 사용하여 IAM 권한을 할당하면 쉽게 공격 패턴이 될 수 있습니다.
사용 사례 3
주면서 비밀을 숨기기 위해 중대하다. 예를 들어 프런트 엔드 JS 앱이 있고 클라이언트 ID 및 클라이언트 비밀번호가 필요한 OAuth 2.0 플로에 참여해야합니다. 또는 API 키가 필요한 엔드 포인트를 호출해야합니다. 분명히 이러한 비밀을 브라우저에 노출 할 수 없습니다.
이 값은 람다 함수에 특정한 encrypted and stored in environment variables 일 수 있습니다.대신 백엔드 람다를 사용하여 이러한 접근 방식을 취할 수는 있지만 승인자를 사용하는 대신 다음과 같은 이점이 있습니다.
나는 이러한 비밀의 범위를 가능한 한 엄격하게 제한 할 수 있습니다. 권한 부여 프로그램을 사용하면 내 애플리케이션에서 이러한 비밀을 알지 못하게 할 수 있습니다. 이것은 우려의 분리에 관한 마크의 관점과 관련이있다.
IAM 및 최소 권한 내 백엔드 코드가 권한이없는 자에 의해 호출 결코 극복 선호
. 이러한 이유로 저는 필자가 생성 한 거의 모든 API 게이트웨이 리소스에 대해 일부 유형의 인증자를 사용합니다. 나는 사용자 정의 승인자를 사용했지만, 내 최후의 수단입니다. 대부분의 경우 IAM 인증을받습니다. Cognito를 사용하여 임시 IAM 자격 증명에 대한 토큰을 교환합니다.
승인자가 아닌 백엔드 람다에서 권한 부여를 수행하는 경우 백엔드 람다 주변에서 IAM 계약을 정의 할 때 제한적일 수 없습니다. 이는 principle of least privilege을 위반 한 것입니다. 이는 코드 구성 및 응용 프로그램 아키텍처의 문제 만은 아닙니다. 합법적 인 보안 문제입니다. 당신은 본질적으로 당신보다 더 많은 공격 표면을 노출시키고 있습니다.
또한 백엔드가 커지면 IAM의 진정한 힘이 빛납니다. 백엔드 람다는 S3에 쓰기, 다른 Lambdas 호출, SNS 또는 SQS 게시, RDS 또는 DynamoDB 등과의 상호 작용 등이 필요할 수 있습니다. "최선의 방법"은 모든 액세스가 엄격한 IAM 정책. 내 경험상, API 게이트웨이 인증 자 (모든 유형의 사용자 정의가 아닌)를 사용하여 역할을 할당하는 것이 가장 쉬운 방법입니다.
좋은 점이 있지만, 플라스크 및 팔콘과 같은 많은 프레임 워크는 사전 요청 후크가 코드를 유지하도록 허용합니다. DRY – Serge