본 내용은 2018 AWS Summit SEOUL 강연 중 박선용님의 Serverless 개발에서의 인증 완벽 가이드를 보고 정리한 내용입니다.
모바일이나 외부 서버의 애플리케이션에서 서버리스 서비스를 호출하는 경우 어떤 방식의 인가 방식이 적용될 수 있는지 살펴보고 패스워드 보안을 위한 Cognito의 SRP 지원을 자세히 살펴봅니다.
인증 (Authentication)
Server: 너의 정체가 무엇이냐 ?User: (여권 또는 신분증을 보여주면서) 나 이런 사람이야Server: 정체를 확인
인증요소
ID/Password
ID card
Security token
인가 (Authorization)
Server: 너가 이 리소스를 사용할 권한이 있어 ?
인가요소
IAM Policy
Security group
인증, 인가와 관련된 AWS 서비스
AWS Directory Service
- 쉽게
Microsoft Active Directory를 AWS 상에서 사용- 3개의 디렉토리 타입
Microsoft AD
Simple AD
AD connector
- 온프레미스 AD와 통합 가능
AWS IAM
- AWS 리소스에 접근할 수 있는 권한과 인증 컨트롤
인증: 누가 AWS 리소스를 사용할 수 있는가 ?인가: 인증 받은 사용자가 어떤 AWS 리소스에 접근할 수 있는가 ?- EC2, Lambda등의 AWS 리소스에 대한 접근 권한 제어
Amazon Cognito
모바일/웹/앱에 대한Signin,Signup,유저 관리소셜 auth와커스텀 auth지원- 여러 디바이스간의
유저 데이터 동기화 기능 제공
Amazon API Gateway
- 쉽게 Restful 웹 API 생성/조작
- API의 관리 용이
- API 리소스 접근 제어를 위해
IAM,커스텀 Auth 람다함수,Cognito 유저풀이 제공됨
애플리케이션이 실행되는 주체에 따른 인가
AWS 서비스를 이용할 때 어플리케이션이 실행되는 주체에 따라 인가를 다루는 방법에 대해서 다뤄보겠습니다.
EC2
가장 먼저 EC2 위에서 운용되는 서버의 경우 이용 가능한 표준은 해당 EC2에 Role을 붙이는 것입니다. 이는 EC2의 메타 정보에 업로드되고 해당 메타정보에 토큰값이 변경되며 EC2에서 사용된 언어에 맞는 SDK를 사용할 경우 자동으로 lookup 합니다.
온프레미스 서버
온프레미스 서버의 경우 aws configure의 secret key와 access key를 저장한다면
~/.aws에credentials파일이 생성됩니다. 만약 코드에 secret key 등을 포함하여 원격 저장소에 업로드할 경우 보안 문제가 발생하게 됩니다.
모바일
모바일의 경우 내부에 credentials 정보를 둘 수 없으므로 role, configure credentials를 사용할 수 없게 되는데 따라서 Amazon Cognito 서비스를 이용하게 됩니다.
리소스별로 api 게이트웨이를 통해서 서비스할 경우 api 게이트웨이로 다루기 편리한 인가 방식을 제공해야 됩니다. 따라서 api 게이트웨이는 3가지의 인가 방식을 제공합니다.
Amazon Cognito User Pools
아래 예시는 유저가 DynamoDB라는 리소스에 접근하는 과정을 예시로 나타낸 것입니다.
1. Authenticate
2. JWT 토큰 반환
3. API Gateway API 호출
4. 토큰 검증
5. Lambda Function 호출
6. DynamoDB 접근
Amazon Cognito Federated Identities
여기서 User Pools과 Federated Identities의 차이에 대해서 헷갈리실 수 있습니다. User Pools는 유저 데이터베이스, Federated Identities 외부 인증 제공자라고 할 수 있습니다. 즉 여러분의 인증은 인증 제공자를 통하여 받게 됩니다. 즉, 인증을 우리 데이터베이스가 아니라 외부 인증 제공자로부터 인증을 받는 것입니다.
2. Authentication AND returns JWT tokens
3. Request AWS credentials
4. Validate Id token
5. Temp AWS credentials
6. Call API Gateway resource
7. Check IAM policy
8. Invoke Lambda and Access resource
3. Custom Identity Providers
lambda가 정책을 생성하고 그것을 리턴해주는 형태가 됩니다.
1. Authenticate
2. Custom Id Token(s)
3. Call API Gateway resource
4. Check policy cache
5. Validate token
6. Generate and return user IAM policy
7. Validate IAM permissions
8. Invoke and Access resource
✅ 여기서 중요한 것은 인증과 인가를 헷갈리지 않는 것입니다.
소셜 인증제공자와의 연동
기업의 인증제공자와의 연동
NSRP와 SRP
모바일에서 Cognito를 이용해서 인가 서비스를 구축할 때 SRP와 NSRP 개념을 만나게 됩니다. SRP가 요구되는 이유는 과거에는 패스워드를 plain text로 저장하거나 MD5 등을 이용해서 비밀번호를 해쉬값으로 저장하였습니다. MD5 암호화 방식은 복호화가 불가능한 단방향므로 유저의 입장에서 역산하기 어려우므로 악의적인 사용자로부터 안정적이라고 생각할 수 있으나 이미 완성해 둔 해쉬테이블 비교 방식과 같은 리버스 룩업 테이블, 브루트포스 등으로 개인정보를 침해받을 수 있습니다.
이를 방지하기 위한 해결책으로 시스템에서 임의의 짧은 문자열 salt를 사용하여 암호화하는 방법이 있지만 브루트 포스를 지연시키는 것이지 근본적인 해결책이 아닙니다.
따라서 Secure Remote Password(SRP) Protocol이 나온것입니다.
Server➡️Client
Client➡️Server
PEACE FOR UKRAINE
