[Secworkshop] Using AWS Cognito

AWS Serverless Cognito Workshop (workshops.aws)두번째 실습을 해보자!

Workshop Studio

 

먼저 제목에 나와 있듯이 이번 workshop에서는 Cognito를 이용하는것이고, Cognito가 가장 중요하다!

 

이번 workshop을 하면서 Cognito를 처음 접해보았고, Cognito 개념은 별도 정리해두었다.

AWS Cognito 서비스 개념 :: 평범한 직장인의 평범한 블로그 (tistory.com)

AWS Cognito 서비스 개념

 

Cognito는 한마디로 말하면, 사용자 인증을 하고/사용자에 맞는 서비스 권한을 부여하는 서비스이다!!

 

이번 Workshop에서는 다양한 방법의 제3자 사용자 회원가입/로그인/서비스 허용의 방법을 실습할 수 있다.

 

 

□ 실습 목적

제3 서비스를 통한 사용자 회원가입/로그인/서비스 허용 방법 서비스 구현 및 실습

 

□ 실습 준비물

 - AWS Cognito, AWS API Gateway, AWS Lambda, AWS Cloud9 IDE에 대한 서비스 이해

 1) AWS Cognito : AWS Cognito 서비스 개념 :: 평범한 직장인의 평범한 블로그 (tistory.com)

 2) AWS API Gateway : AWS API Gateway + Lambda 서비스 이론만 알아보기 :: 평범한 직장인의 평범한 블로그 (tistory.com)

 3) AWS Lambda : AWS API Gateway + Lambda 서비스 이론만 알아보기 :: 평범한 직장인의 평범한 블로그 (tistory.com)

 4) AWS Cloud9 IDE : PC에 별도의 개발 Tool 설치 없이, 브라우저를 통해 개발 환경을 제공해주는 서비스

 

□ 실습 목표 아키텍처

 총 3가지 형태의 서비스 구현을 목표로 실습을 한다.

 1) Cognito + Lambda 서비스만 사용

 2) API Gateway + Cognito + Lambda 서비스 사용

 3) Cognito + STS(Security Token Service) 서비스 사용 

실습 1 목표 아키텍처

 

□ 실습 빌드

1. 먼저 Cognito 사용자 인증을 연동한 서비스를 구현해야 한다.

 - AWS에서 실습하기 좋게 CloudFormation 템플릿을 만들어 두었다. Stack을 만들고 실행만 하면 된다.

Cloud IDE9 환경 구현

 - Stack 생성 후, 커피 한잔 마시고 Cloud9 서비스에 들어가면 아래와 같은 IDE 환경이 하나 생성되어 있다.

IDE 신규 생성

 - Open IDE를 선택하면 새로운 창이 뜨면서 개발 환경을 하나 볼 수 있다.

IED 기본 환경

 - 설정에 따라 Terminal 위치가 다를 수 있겠지만, ec2-user가 나와있는 부분에 아래 명령어를 순차적으로 입력하여

   Cognito 서비스를 연동할 임시 웹서버를 구동해보자!

git clone https://github.com/aws-samples/amazon-cognito-identity-management-workshop.git    >> AWS 실습을 위한 Git 정보를 다운로드 한다. npm install -g yarn     >> yarn 패키지를 설치한다. yarn 패키지는 npm과 유사하게 패키지를 설치하는 자바스크립트이다.    >> npm을 써도 무방하나, npm이 비해 가볍고 순차적으로 설치하는 npm을 대체하기 위해 개발된 패키지라고 보면 된다. cd ~/environment/amazon-cognito-identity-management-workshop/website/    >> Git 정보가 있는 디렉토리로 이동한다. yarn install   >> GIt에서 받은 패키지를 설치하고 yarn start   >> 설치한 패키지를 실행한다.

 - yarn start 까지 하고 나면, 아래와 같은 임시 웹서버에 접속을 할 수 있고 이제 Cognito 연동을 하기 위한 준비가 되었다.

임시 웹서버

2. AWS Cognito 사용자 Pool을 생성한다.

 - 생성하는 방법은 다음과 같다. AWS Serverless Cognito Workshop (workshops.aws)

Workshop Studio

 - 간략하게 요점만 정리하면 다음의 Cognito 사용자 Pool을 생성하는 것이다.

    → 사용자 Pool Name : WildRydes

    → 사용자 인증 방법 : 이메일, 핸드폰

    → 가입 시 입력 필드 추가 : genre(Additional Custom field)

    → 그 외 나머지 MFA, 비밀번호, Token 강도 등등은 기본값을 유지한다.

        ※ 금융권에 재직인으로서 MFA/비밀번호/Token 강도를 정하는 것이 Cognito 사용자 Pool에 가장 중요한 부분인것 같다.

             보안성심의 업무를 하다보면 각 서비스의 사용자 관리 및 계정 설정은 어떻게 유지하는지 확인하기가 매우 번거롭다.

             만약 AWS에서 서비스를 제공중이라면 Cognito 사용자 Pool 설정만 확인하면 되니 점검하는 입장에서 아주 간편할 것 같다.

 

3. 임시로 생성한 웹서비스에 Cogito 서비스를 연동한다.

 - 우리는 1. 과정에서 Cloud Formation에서 AWS Cloud9 IDE 서비스를 이용하였고, 임시 웹서버를 구현하였다.

 - Cognito 서비스를 연동하기 위한 임시 웹서버로 workshop만 잘 따라면 연동하는것은 무리없이 따라할 수 있다.

 - 연동하고 나서 /register 페이지를 들어가면 아래와 같이 회원가입 페이지를 볼 수 있고, 2. 에서 추가한 genre field가 있다.

임시 웹서버 회원가입

 - 원래 정상적인 경우라면, 회원가입 후 회원가입 정보가 Cognito 사용자 Pool에 정보가 넘어가야 하지만,

   무슨 이유에서인지.. 아래와 같이 Unable Key 라는 팝업창과 함께 다음 과정이 진행되지 않는다 ㅜㅜ

Cognito 회원가입 연동 오류

 - 아래와 같이 앱 클라이언트를 제대로 복사하였음에도.. 진행되지 않는다 ㅜㅜ 이유를 전혀 알 수가 없다.

   그래서 이후는 이론적인 부분에 대해서만 알아보았다.

Cognito 앱 클라이언트 정보

4. Cognito 서비스를 트리거로 Lambda 서비스 호출을 지정한다.

 - 아래와 같이 사전 가입(Sign-up) 이벤트가 발생할 때, 해당 이벤트를 트리거로 삼아 Lambda 함수를 호출하도록 한다.

Cognito Lambda 연결

 - 사용자 가입에 대한 Flow는 다음과 같다.

 - 사용자가 가입 신청함 → Cognito에서 트리거 발생 Lambda 함수 호출 → sign-up Lambda 실행 → Response 전달

 - Lambda 함수를 보면 아래와 같다.

    1) event reuqest userattributes email list에서 @을 기준으로 잘라서 address 변수에 설정

    2) address 변수가 domains list에 존재하면, OK 존재하지 않으면 Fail

       즉, @gmail.com 등의 매일 도메인에 대한 Check를 하는 함수이다.

sign-up lambda

 - 이후 serverless-idm-wksp-custom-message / pre-token-gen 함수를 만든 다음에 Cognito 각 트리거에 연결을 한다.

 

여기까지가 실습1의 완전한 아키텍처를 만든 것이다.

사용자가 SignUp하면 Cognito 서비스에서 특정 이벤트를 트리거삼아 특정 Lambda를 호출하고 그 결과를 Cognito 서비스가 받아 회원가입 승인 또는 불허한다.

실습 1 목표 아키텍처

 

 

실습 2는 AWS API Gateway가 대신 전달받아서 Cognito에 전달해준다. 일종의 Proxy 같은 역할을 한다.

 - AWS API Gateway는 아래 나름대로 정리한 게시물을 참고한다.

 AWS API Gateway + Lambda 서비스 이론만 알아보기 :: 평범한 직장인의 평범한 블로그 (tistory.com)

AWS API Gateway + Lambda 서비스 이론만 알아보기

실습 2(기본) 목표 아키텍처

 

AWS API Gateway을 연동하는 것은 보안적인 측면과 확장성의 측면이 있을 수 있을 것 같다.

 

보안적인 측면으로는 API Gateway는 API에 대한 Proxy 역할로 API에 대한 인증 및 로깅 서비스를 제공해준다.

Cognito 서비스는 사용자 인증 Pool로 직접 외부에서 바로 접근할 수 있게 하는것은 Risk가 있기에 API Gateway가 Proxy의 역할로

보안성을 좀 강조한 아키텍처로 생각이 된다.

 

확장성 측면으로는 API Gateway를 사용하는 것이 파라미터나 기타 다른 lambda와 연동하기가 쉽다.

(위 API Gateway를 연동하는 사유는 순전히 나의 얄팍한 생각으로 쥐어짜본 이유이다. 아닐수도 있다...)

 

실습 2의 기타 다른 아키텍처로는 아래와 같이 구조도 있다.

실습2(심화) 아키텍처

 

위의 실습1, 실습2(기본)에서는 IAM 권한을 사용하지 않는다. 실습2(심화)에서는 API 권한이 부여되어 있다.

전체적인 Flow는 다음과 같다.

1. 사용자 AWS 서비스를 이용할 수 있도록 로그인

2. Cognito 사용자 Pool에서 확인 후, 사용자 Valid Token 전달

3. AWS API Gateway를 호출하게 되고, API Gateway의 IAM 권한 확인

   - AWS API Gateway에서 호출에 대한 인증을 IAM으로 지정할 수 있고, IAM 정책을 통해 개별 서비스 권한 부여가 가능하다.

   - 아마 API Gateway로 인입되는 API에 대해서 무분별한 서비스 호출이 되지 않도록 보안적으로 권한을 부여하는 것으로 보인다.

4. IAM 권한 확인 후, 권한이 부여 된 Lambda 함수를 호출

5. 사용자에게 Response 전달, 서비스 제공

API IAM 권한 부여

 

 

얄팍한 지식이지만, 이번 workshop을 하면서 느낀점은 지금까지 아는선에서의 Best한 아키텍처는 아래인 것 같다.

1) Cognito로 사용자 Pool 정보를 활용하여, 적절한 사용자 임을 확인하고

2) API Gateway를 통해 API 호출/전달에 대한 로깅을 하면서

3) IAM을 통해 해당 API가 특정 서비스 호출만 가능하도록 권한을 제한하는것이 좋은 방법인것 같다.

실습2(심화) 아키텍처

 

이번 workshop에서는 중간에 Cognito 연동이 제대로 안되는 바람에 좀 어설프긴하지만..

이론적인 부분에 대해서만 알아가는것도 좋은 발전이라고 생각한다.

 

실무는 클라우드 관련 직무를 맡고나서 해도 되니까.. 이상 2회차 Cognito 서비스에 대한 workshop 끝!!!