하고 싶은 일

서버리스 시스템에서의 개인정보 보호에 대해 생각해 봅시다.

시스템에서 관리해야 하는 개인정보는 가능한 한 클라우드에 머무르고 클라이언트와 상호작용하지 않을 수 있다면 통신로에서의 유출을 방지할 수 있습니다.
또한 개인정보의 관리를 제한할 수 있다면 시스템의 대부분은 개인정보의 유출에 대해 의식하지 않고 시스템 개발을 할 수 있습니다.

이러한 요청 시스템의 경우 AWS에서는 다음과 같이 보입니다.

Cognito Identity Pool에서 사용자 관리하기.

클라이언트 ⇔ AWS 간의 통신로상은 액세스 토큰과 처리 결과만을 전달한다.

AWS 내에서 Lambda는 액세스 토큰을 받고 Cognito의 사용자 정보를 기반으로 처리합니다.

액세스 토큰을 받은 Lambda에게 액세스 토큰에 해당하는 사용자 정보에 대한 액세스 권한이 위임되며, Lambda는 Cognito의 사용자 정보를 검색하고 처리할 수 있습니다. 따라서 Lambda는 액세스 토큰을 받을 수 있어야하지만 사용자 정보에 액세스하는 역할을 부여 할 필요가 없습니다.

참고로 Lambda에서 Cognito로 HTTPS 통신할 때 어떤 정보를 교환하면 액세스 토큰과 교환하여 사용자 정보를 얻을 수 있는지 cURL, Postman, AWS CLI를 사용하여 조사했으므로 정리해 둡니다.

결론

필요한 정보는 다음과 같습니다.
- Cognito Identity Service Provider에서 발급한 액세스 토큰
- Cognito Identity Pool 지역
- 다양한 종류의 헤더 (Content-Type, X-Amz-Target)

※ 각종 간격의 헤더를 붙이지 않으면 이하의 에러가 돌아옵니다.

{"code":"BadRequest","message":"The server did not understand the operation that was requested.","type":"client"}

cURL

$ curl 'https://cognito-idp.＜リージョン＞.amazonaws.com/' -H 'Content-Type: application/x-amz-json-1.1' -H 'X-Amz-Target: AWSCognitoIdentityProviderService.GetUser' --data-binary '{"AccessToken":"＜アクセストークン＞"}'

Postman

메소드

POST

Url

https://cognito-idp.<리전>.amazonaws.com/

Authorization

Type: No Auth

Headers

Content-Type: application/x-amz-json-1.1

X-Amz-Target: AWSCognitoIdentityProviderService.GetUser

Body

{"AccessToken":"<액세스 토큰>"}

AWS CLI

$ aws cognito-idp get-user --access-token ＜アクセストークン＞

(비고)

＜リージョン＞ 는, 도쿄라면 「ap-northeast-1」입니다.

이 시스템에서는 HTTPS 통신이 필수입니다.

AWS 서비스 간 보안(ex. Lambda ⇔ Cognito)의 신뢰성은 별도로 고려해야 합니다.