<402,403 - 개요 및 사용자 풀>
> User 에게 Identitiy (자격 증명) 를 부여, 웹 앱과 상호작용할 수 있도록 함
> AWS 계정 외부에서 접근 (일반 유저) 하기 때문에 우리가 모르는 사람들임.
> 두가지 기능으로 정리된다
> User Pool
>> 사용자들에 대한 로그인 Sign In 기능을 제공
>> API Gateway / ALB 와의 Integration 이 매우 유용
> Cognito Identity Pool (Federated Identity)
>> 외부 유저들에게 AWS 리소스에 직접 접근할 수 있도록 일시적인 AWS Credential 을 제공하는 것
> Cognito 는 IAM 과는 다르게 외부의 유저들을 인지하기 위한 것으로, Keyword 로는 "수많은 유저", "모바일 유저", "SAML 인증" 등등이 있다
<User Pool (CUP)>
> 웹 앱 사용자들에 대한 서버리스 DB 를 만드는 방법, CUP 는 JWT 를 활용한다
> 제공하는 기능 :: 로그인 / 패스워드 초기화 / email & phone Verification / MFA / 연합 인증 (Federated Identity) : Facebook, Google, SAML 등의 로그인
>> 보안 기능: 유저의 credential 이 유출되었을 경우 이름 감지해서. 웹을 스캔해서 유출된 정보 확인 및 사용자 차단 기능, 사용자에게 알림
> CUP 는 유저에 대한 DB 를 가지고 있고, Client 들이 로그인에 성공할 때마다 JWT 를 반환한다
> 제 3자 Identity Provider (IdP라고 한다) 들과 Federation 이 가능, 소셜 로그인!
<CUP 과 AWS 의 통합>
> API Gateway / ALB 와 상호작용을 자주 함
> Gateway
>> Client 가 CUP 와 직접 인증을 주고 받고, Web Token을 사용하여 API Gateway 로 이동.
>> Gateway 는 직접 토큰을 Cognito 를 통해서 확인한다
> ALB
>> Listener & Rule 을 연동하여 CUP 과 통신을 할 수 있도록 설정 (인증에 대한 요청, JWT 반환/확인에 대한 요청)
>> 인증이 되거나 확인이 된다면 그제서야 TG 으로 이동시키는 로직으로 동작
----------------------------------------
<404 - 사용자 풀 실습>
> 생성시 User Pool 할건지 Federation 할 건지 선택 가능
> 로그인 옵션 설정 가능 (username, email, phone), PW 요구사항 설정 가능, MFA 요구할건지 설정 가능, 계정 복구 설정 가능
> 또한 설정할 DB Column 들 설정 가능 (required attribute / custom attribute - 생일, 가족, 성별 등등의 개인정보)
> 이메일을 보내야되는 상황일 시, SES/SNS 이용 or 그대로 Cognito 이용 선택 가능 (Cognito 가 무료가 매일 주어지기 때문에, 개발시에는 이게 나음)
> Hosted UI 사용할지 설정 가능 (Cognito 가 제공하는 것) > 존재한다는 것을 시험에서 물어볼 수도!, 사용하려면 URL 도 기입
> 초기 앱 클라이언트
>> Public Client : Public 앱에다가 Cognito 를 사용하는 경우?
>> Confidental Client : Client Secret 을 설정해야 하는 경우(?), Cognito API 가 Client 측이 아닌 관리 서버 측에서 요청되는 경우.
>> Other : 기타의 Case
> Hosted UI 보기를 하면 로그인 / (설정한대로) 회원가입까지 할 수 있다 (이 때 설정한 요구사항들도 적용된다)
>> 이 때, 이메일 인증까지 설정할 수 있다
> 인증/로그인을 완료하면 내가 설정한 Hosted UI Callback URL 로 이동한다 (내가 원하는 곳으로 이동시킬 수 있음, 가령, 내 website home)
> 예시로 회원가입을 해보면, Cognito User Pool 에 이동시 User name 에 추가되어 있고, email 주소 및 verified 여부까지 확인할 수 있음
>> Welcome Email 도 보낼 수도 있음 ㅋㅋㅋㅋ
>> Federation with IdP 를 하면 원하는 서비스대로 OAuth 2.0 을 연동할 수 있다 (진짜 개편하다 ㅅㅂㅋㅋㅋㅋㅋㅋ)
>> 참고로 각 서비스와는 직접 연계하여 Client ID, Client Secret 등을 가져와야 함 ㅇㅇ
> Lambda Trigger 설정
>> 사용자 풀 내에서 발생하는 일에 대해 반응할 수 있다 (람다 함수로 대응, 회원가입 시 관리자에게 이메일)
>> Trigger Type : 회원가입 / Authentication 진행 / CAPTCHA 같은 Custom Auth / Messaging 등
>>> 각 Trigger Type 이 정확히 어떤 CASE 를 말하는건지 한번 확인해보는 것도 좋을 듯! 뒤에 두개 잘 모르겠음 ㅠ
>> 각 Trgger 마다 정확한 세부 Trigger 도 설정 가능 (ex: Pre, Post SignUp, Migrate user trigger 등)
>> 마지막으로 Lambda Function 을 선택해주면 된다!
----------------------------------------
<405 - 사용자 풀 기타 (실습 이론 복습)>
> CUP 는 위와 같은 형태의 Lambda Trigger 를 수행할 수 있음, 안나온건 위에 설명 참조
> Auth Event
>> 1. 로그인 요청을 승인 / 거절 (커스터밍) 가능
>> 2. Event 를 발생시켜 로깅을 주기 위해 Post
>> 3. 토큰관리
> Sign Up
>> 2. 웰컴 메세지 가능
> Message > 사용자에게 보내는 메세지를 Customize 가능
> Token Creation > Token 에 정보 추가 및 제어
<Hosted Auth UI>
> 회원 / 인증과 관련된 UI 를 개발할 필요 없이 Cognito 가 제공해주는 것을 사용할 수 있다
> SNS 로그인 / OIDC / SAML 따위와도 아주 아주 쉽게 연동 가능
> 로고, 더 깊이는 CSS 등을 커스터마이제이션 가능
> Custom Domain 에 이 Hosted UI 를 쓰고 싶을 수도 있음
>> 어떤 지역에서 하든지 상관 없이, HTTPS 통신을 해야 하고, 이를 위한 인증서는 "ACM" 이란 곳에 있어야 하고, 리전은 반드시 "us-east-1" 이여야 한다
>> Congito Pool 이 eu-west-1 에 있다고 해도, us-east-1 에 Certi 를 둬야 한다
>> 콘솔에서 [App Integration] 섹션에서 정의할 수 있음
<Adaptive Authentication>
> 사용자가 정상적으로 로그인 하되, 조정 인증을 사용하면 수상한 로그인이 있을 경우, 로그인 차단 or MFA 를 요구할 수 있다
> 각 로그인 시도는 Cognito 로 부터 검사되는데, 이 때 risk-score(L,M,H) 가 체점된다. 악의적 공격자의 요청일 가능성에 대해 체점
> risk 가 감지되면 시도하는 유저는 MFA 따위의 추가 검증을 수행해야 할 수 있다
>> 가령, 평소 로그인 하던 지역 이외의 곳에서 로그인을 시도 (의심스러우므로, 너라는걸 검증해야 함, 다소 naive 한듯?)
> risk factor 요인으로는 - device, location, IP Address 정도가 있다
> 이 모든 것들은 당연히 CW Log 에 기록 된다 (로그인 시도, risk score, failed MFA 등)
<JWT Token 활용, Decoding>
> Header, Payload, Signature 로 구성, Base64 Encode 된 상태로 돌아다니고, 이는 네트워크 상에서 쉽게 오고갈 수 있는 형태이기 때문
> Decode 하면 내부 내용이 쭉 나옴. Payload 가 말그대로 주요 Data 가 있는 곳
> 하지만 우선 JWT 토큰을 수신하면 Signature 를 Verify 해야 Payload 의 정보를 믿을 수 있다
> 서명은 맨 밑에 있고, 알고리즘이 있다. 알고리즘으로 서명이 올바르면 Payload 정보는 믿어도 됨. 이렇게 하는 것
> 서명이 확인되면 Payload 를 사용할 수 있는데, 여기에는 주된 User Information 이 있다
>> ex: sub UUID (User ID in CUP), email, given_name, phone 등등
>> 참고로 이 sub UUID 를 사용하면 어떤 User 정보든지 recover(?) 할 수 있다고 함 (아마 Cognito 내부 DB 에서 가져오라고 추가적인 요청을 할 수 있다! 이거 아닐까 싶음)
>> 바로 위에 한말 맞음. 저기 있는 정보 혹은 그 외의 정보를 더 look up 필요하면 CUP DB 에서 sub UUID 를 통해 조회할 수 있다 (API 사용할 수 있을 듯)
----------------------------------------
<406 - ALB 와의 사용자 인증>
> ALB 로 Cognito 와 연동에 대해서 좀 더 자세히
> Authenticate User 에 대한 책임을 ALB 에게 부여할 수 있음 (앱은 신경 안써도 됨, 비즈니스 로직에 집중) - 진짜 좋은 듯 ㅋㅋ
> HTTPS Listener 를 사용해야 함 (authenticate-oidc & cognito rule 을 적용하기 위해서)
>> 로드밸런서 구성시 Listener (포트에 점유하면서 리슨 하는 곳) 를 Https Protocol 로 443 Port 에 점유시킬 수 있음
> ALB 도 다음과 같이 인증
>> IdP 이용 : OpenID Connect (OIDC) 를 준수하는 자격 증명 공급자
>> CUP 이용
>>> Social IdPs ex: AWS, FB, Google
>>> 혹은 SAML, LDAP, MS AD 와 호환되는 기업 자격 증명이 있는 경우
> Unauthenticated Request 에 대해서는 3가지 >> (default) 인증 요청을 함 / deny / allow (ex: login page 같은 경우는 인증이 불필요 하기 때문에 허용한다)
> 유저들이 GET 요청을 할 경우, ALB 는 이 HTTPS 요청에 대해 Cognito 에게 인증을 요청한다
> 인증이 완료될시 JWT Token 반환하고, 이 유저가 누구인지에 대한 정보를 다시 담아서 Original 요청과 함께 후속 백엔드에 전달한다
>> 인 앱에서 사용자 정보를 바탕으로 비즈니스 로직을 제어할 수 있다
< CUP 사용하는 경우>
> ALB 로 가서 CUP 와 Client / domain 을 연동한다 (미리 생성해둘 필요)
> JWT Token 반환이 되는 것을 확인하고, 원한다면 IdP 와 Federation 진행
> 필요한 URL Redirection / Callback 등을 지정
> CUP 할 때랑 그냥 거의 똑같이 하면 되어서, 크게 어려움은 없는 과정!
<OIDC Auth 를 사용하는 경우 - 이거 SSO 인듯 ㅋㅋㅋㅋ>
> HTTP 요청 발생시 , ALB 가 User 를 IdP 의 Auth End Point 로 Redirection 을 하게 된다
> 이 때 이 인증 하는 곳에서 Auth. Grant Code 를 전달하고, 그게 다시 ALB 로 전달됨
> ALB 는 이를 다시 Token End Point 로 전달해, 적절한 Access Token 으로 교환해서 가져옴 (여기까지 내가 아는 과정인듯, SSO 에선 두 EndPoint 를 합친 듯?)
> 그럼 이를 User Info EndPoint 에 Access Token 을 꽂아 넣고, 그러면 User Info Endpoint 에서 User Claims 정보를 전달해주게 됨
> 그제서야 ALB 는 User Claim 정보를 원래 요청과 함께 Payload 에 넣고 후속 백엔드로 전달
> 설정할 때 그래서 구성할게 좀 많음. Authorization EndPoint, Token End Point, User Info EndPoint, 연계한 곳과의 Client Id, Secret 모두 다 넣어야 함
>> 일반적으로 연동하는 IdP 쪽에서 Guide 가 있으니, 그걸 참고해서 설정에 기입하면 되긴 함
----------------------------------------
<407 - Cognito Identity Pool (Federated Identities) : IdpP 와 연계하는 것.. 근데 지금까지 한거랑 뭐 크게 다른가..? ㅇㅇ 다르네>
> 좀 어려운 부분!! 잘 이해해보자!
> CUP 랑 하는 기능이 많이 다른데 Cognito 하위 기능으로 분류된게 잘 이해 안된다고 함
> CUP 때랑 똑같이 외부 유저들이 있는거고, AWS 환경 내 리소스들에게 접근하고 싶은 것
>> DD, S3 등에 외부 유저들이 접근하려고 하는건데, 이럴 경우에는 일시적인 "AWS Credentials" 가 필요
> IAM 유저를 발급하기에는 너무 많고 안전하지도 않으므로, Cognito Identity Pool 을 이용해 AWS로의 액세스 제공
> Identity Pool 은 다음과 같은 Identity Source 를 활용할 수 있다
>> Amazon, Facebook, Google, Apple 등 제 3자 Public Providers 의 로그인
>> CUP 를 통해 로그인한 유저들
>> OIDC Providers & SAML Providers
>> 개발자들이 직접 제공 가능 - custom login server (Developer Authenticated Identities)
>> 로그인된 사용자 외에 AWS Credentials 을 발급받기 전에 사용(?) 하기 위한 Unauthenticated(guest) access 를 설정할 수 있다 (Guest Policy 설정 가능 - 그리고 guest users 에게 AWS 자격 증명 부여)
> Users 들이 위처럼 AWS Credential 를 얻었다면, AWS 서비스들을 SDK를 이용한 API 호출 혹은 API Gateway 로 접근 가능하다
> 사용들이 제공받는 Credentials 들은 Cognito 에 Define 되어 있는 IAM Policies 들을 가지고 있다
> 이후 또 나오지만, user_id 를 통해 customizing(?) 이 가능하다 (for fine-grained control)
> 웹 & 모바일 클라들에게 S3/DD 직접 접근을 주고 싶은데, 이 앱을 위한 IAM User 를 만들고 싶지 않으면, CIP 를 사용한다
> 위에서 말했듯이 어떤 방식을 사용해서 Token 을 GET 하고, 이 Token 을 사용해 CIP 로부터 AWS Credential 을 발급받는다
>> CP 는 임시 자격 증명을 받기 위해 STS 서비스와 통신한다
> CUP 와는 다른 측면이 많지만, 신분 제공 맥락에서는 비슷함
<CUP 와 CIP 를 같이 사용하면 어떤 그림?>
> 다 똑같은데,로그인 방식을 CUP 사용 하고, CUP 의 Internal DB 를 사용할 뿐
> 이 때 CUP 는 독립적으로 Federated IdP Providers 들과 연계할 수도 있다 (소셜 로그인 UI 제공 가능?)
>> 근데 이럴 바엔 그냥 CIP 랑 Federation 하는게 낫지 않낭? ㅋ
<CIP 가 어떻게 어떤 Role 을 유저에게 줄지 알 수 있을까?>
> 이 부분 살짝 뭔소린지 모르겠음. 그냥 일단 Policy 랑 Role 을 잘 모르겠음 (꽤나 심화 내용이라고 한다)
> authenticated & guest user 에게 기본 IAM Role 을 정의할 수 있다
> user ID 를 기반으로 어떤 유저에게 어떤 Role 을 줄지 Rule 을 정의할 수 있다
> IAM Policy 를 Customize 한다 - Policy Variable 사용
>> 사용자들이 그들이 원하는 리소스에만 접근할 수 있도록 setting 가능 (일부 DD, 특정 S3 등)
> IAM Credential 에 IAM Policy 가 있는 것이고, 이 IAM Credential 들은 CIP 가 STS 란 것과 상호작용해서 가져온다
> Role 은 CIP 에 대한 "Trust Policy" 를 가지고 있어야 동작한다고 함. 아래 예시를 보자
> Guest User 에게 AWS 리소스에 대한 액세스를 허용하려 함
>> 그래서 any guest user 가 S3 Bucket 내 my_picture.jpg 파일에 대해 Get Object 를 할 IAM Policy 를 만든다
>> unauthenticated user 에게 아주 제한된 접근을 제공해주는 것
> user identity 를 명시한 PREFIX 에 대한 폴더에만 접근이 가능하도록 한다 (애초에 S3를 그렇게 설계해야 하는 듯)
> 위 그림은 해당 사용자 ID를 Prefix 로 사용하는 객체들에만 접근할 수 있다 (가령, 유저별 앨범 이런거?)
>> user_id 를 통해 사용자들이 허용된 부분에만 액세스할 수 있도록 한다 (Fine-grained control)
> DD 에서도 비슷하게 사용할 수 있다
>> DD 의 Leading Key 가 사용자의 user_id 랑 corresponding 할 때, DD에서 Policy 에 명시된 Table 에 ~~ Action 을 수행할 수 있다 이런식으로 권한을 준다. (Leading Key 가 뭐야 씨부레 ㅋㅋㅋㅋㅋ ㅠㅠ)
>> row-based security 를 쉽게 적용할 수 있었다!!
----------------------------------------
<408 CIP 실습>
> Cognito 에서 CUP 가 아닌 자격 증명 풀 생성으로 (CIP) 이동
> Authenticated & Guest Access 중 어떤 것을 사용할 것인지 선택 (둘다도 가능)
> Authenticated 일시 위에서 배운 것처럼 Authentication 을 받아오는 Source 가 어딘지 선택 : Facebook, Google, CUP, Apple 등
>> 누구나 우리 풀에 접근해서 (로그인 없이) 임시 허용 Credential 을 받을 수 있게 하려면 Guest Access 도 선택!
> Authenticated Role 을 지정해야 하는데, Credential 인증 사용자가 Assume 하게 될 Role 이다
>> 나중에 더 자세히 나옴
> Guest Role 도 지정해야 한다. 이것 역시 동일함 (Guest 가 갖게 될 권한 지정)
> IdP 를 연결하는 부분 (여러가지 연동할 것 기입하거나, CUP 였으면 CUP 지정)
> 어떤 유저가 어떤 role 을 가지게 되는지에 대한 Rule 을 지정할 수 있는데, 이건 잘 이해가 안됨
> 어쨌든 사용하는 곳에서 (Client 가 어쨌든 너의 AWS 리소스에 접근해야 한다 아님?) AWS SDK 를 import 해서 사용하면 된다
> IAM 으로 이동해서 Role 로 가보면, 아까 만들었던 Guest / Authenticate Role 이 두개 있다.
> 여기서 이 Role 을 직접 수정해서 사용자들이 어떤 IAM Role 을 가지고 우리 AWS 에 접근하게 되는건지 명시를 할 수 있다
> Policy 를 추가하면서 Role 을 수정할 수 있다 (Role 이란 특정 시간동안 부여되는 것, Policy 는 정책을 가지고 있으면 계속 가지고 있다는 의미)
----------------------------------------
<409 CUP vs CIP>
> CUP 는 일단 인증을 위한 거임 (Identity Verification) = Authentication
>> "로그인" (인증) 만을 위한 Federation 이 가능한 것
>> 너의 서비스를 위한 Member DB 를 구축해주는 것
>> 로그인/회원가입에 대한 UI 제공 가능
>> Pre/Post 등 Auth 과정 중 특정 Trigger 에 대한 람다 함수 호출 연동이 가능하다
>> 로그인에 대한 검사를 진행, risk-level 을 측정하여 로그인에 대한 부가 제어도 가능 (MFA 등)
> CIP 는 인가를 위한 거임 (Access Control) = AWS 내 리소스에 대한 액세스 관리
>> 사실 잘 모르겠음. 서비스가 직접 SQS 나 S3 에 뭐시기를 하려면 AWS 액세스 권한이 필요한걸까? 지금까지 했던건 All Open 했기 때문인걸까? 그래서 사실 SDK 를 쓸 때 권한 같은거 써야 하긴 하는거려나. 그래서 그걸 CIP 로 쓸 수 있다 이런건가? 좀 헷갈림 ㅠ
>> 로그인 / 회원가입 제어만 하고 싶고 Member DB 만 있으면 된다 하면 CUP 로 충분하다
>> 하지만, 이 유저들이 AWS 환경에 (DD, S3 버킷) 접근하려 한다면, 이 작업은 CIP 로 이루어진다
>>> 사실 이게 이해가 안되는거긴 함. 서버 앱에서 접근하잖아. 유저가 직접 접근한다? 이게 무슨 경우인건지 잘 모르겠음 (지피티한테 물어보자)
>> CIP 를 써도 어쨌든 유저 로그인이 필요함 (Guest 가 아니라면)
>> 사용자가 어디에서 로그인 인증을 받던, 가져온 token 으로 "권한"을, AWS Credential 을 부여받을 수 있다는 것
>> 인증 없이 Guest 권한도 줄 수 있는데, 이 때 Policy Varaiable 을 사용해 선택적으로 권한을 mapping 해줄 수 있다 (이것도 완벽하게 이해가진 않았음 ㅋㅋ)
> CUP 와 CIP 를 같이 사용하면 Authentication & Authorization 을 한번에 사용하게 되는 것
> 위에 CUP + CIP 그림을 다시 보라
> CUP 를 통해 로그인 함 (자체 DB or Federation)
> 그러면 유저는 Token 을 받게 된다고 했음. 이 Token 을 CIP 에게 제공해서 Temporary AWS Credential 을 받는 것임
> 좀 어렵긴 했음..... 완벽한 이해보단 그냥 전체적인 개요와 외울것들만 챙기면 될듯! (GPT 랑 좀 면담하면서 이해해보는 시간이 필요하긴 할듯)
----------------------------------------
<퀴즈>
>
====================================================================================
교육 출처
- AWS Certified Developer Associate 시험 대비 강의 - Udemy
'웹 운영 > AWS' 카테고리의 다른 글
| [CDA] 섹션 29 - 고급 자격 증명 (0) | 2024.10.21 |
|---|---|
| [CDA] 섹션 28 - 기타 서버리스 : Step Functions & AppSync & Amplify (0) | 2024.10.10 |
| [CDA] 섹션 26 - 클라우드 개발 키트 (CDK) (0) | 2024.10.03 |
| [CDA] 섹션 25 - AWS 서버리스 : SAM (Serverless Application Model) (0) | 2024.09.20 |
| [CDA] 섹션 24 - AWS CICD : CodeCommit, CodePipeline, CodeBuild 및 기타 (0) | 2024.09.17 |
