[ASAC 3기 개발일지] 클라우드와 웹 - (2)

배규리·2023년 11월 6일
0
post-thumbnail

키워드

  • OAuth
  • AWS 클라우드
  • 네트워크 개요
  • OSI 7Layer
  • AWS 네트워크
  • AWS IAM

OAuth

이전 블로그에서 SSO는 연회장에 들어가기 위한 인증서만을 가져오면 됐었다.
OAuth는 그 인증서를 가지고 또 한번 내가 어떤 역할/권한이 있는지 확인하는 역할까지 수행👌

ChatGPT는 이렇게 말해준다.

서브파티 애플리케이션이 사용자의 데이터 또는 리소스에 대한 액세스 권한을 얻을 수 있는 프로토콜

아래는 OAuth의 전체적인 수행 과정을 나타내는 이미지이다.

들어가기 전에 OAuth 주체 4가지를 알고 들어가야 한다.
1. Resource Owner
2. Client(우리가 쓰는 서버)
3. Resource Server
-> Access Token을 Resource로 바꾸어 줌
4. Authorization Server
-> Authorization Token발행
-> Authorization Token을 Access Token으로 바꾸어 줌

등록

Client가 Resource Server에 자신의 서버를 등록하면
Client ID, Client Secret, Redirect URL을 반환받을 수 있다.
⇒ Redirect URL은 우리가 설정만 할 수 있는 것이고 구현하는 것은 우리의 몫이다!

Resource Owner의 승인

Resource Owner가 Resource Server에 등록되어 있는지 여부를 확인받고
되어 있지 않다면 등록 화면을,
되어 있다면 redirect URL로 돌려준다.

Resource Server의 승인

Resource Server에서 승인이 나면 다음과 같이 진행된다.
클라이언트가 얻은 사용자의 승인을 기반으로, 클라이언트는 Resource Server에 접근 권한을 요청한다.

Access Token발급

Resource Server는 Client의 요청을 승인하고, 클라이언트에게 Access Token을 발급한다.
Access Token은 클라이언트가 Resource Server에 대한 요청을 보낼 때 사용되며, 특정 범위의 권한을 나타낸다.

아래의 예시를 보자.
클라이언트에게 Access Token을 발급해주는 상황!
이때 Client는 Access Token을 가지고 있고, Resource Server입장에서는 Client의 id와 scope값을 확인하여 권한을 확인하고 해당 토근을 발급해준 것이므로, 4번에 해당되는 권한을 가지고 있음을 알 수 있다.

쉽게 말해 4라는 권한을 가지고 있다고 생각하자! 4에는 장바구니 페이지 접근 권한, 좋아요 페이지 접근 권한 등이 있겠지...?

API 호출

HTTP GET API를 호출하는 방법에는 2가지가 있다.
1. Query Parameter로 access_token의 value를 넣어주는 것
GET http://www.googleapis.com/drive/v2/files?access_token=1
2. Bearer token값을 http header에 넣어주는 것

GET /drive/v2/files HTTP/1.1  
Authorization: Bearer <access_token>
Host: www.googleapis.com/

Refresh Token

위에서 발급한 Access Token들은 전부 수명이 있다.
수명이 지나면 또 발급하고...지나면 또 발급하고 계속 하기에 불편함!
이걸 위해 Refresh Token이 있는 것!😎😎😎

Refresh Token은 Access Token의 수명이 만료되어 Resource Server로 부터 Invalid Token Error를 반환 받았을 때 Authorization Server로 전송하는 토큰이다.

해당 서버에서는 Refresh Token을 받으면 새로운 Access Token을 바로 발급해준다.

AWS 클라우드

가상 서버를 대여해준다!
물리적인 서버를 사지 않고 AWS로 부터 서버를 대여받아 사용할 수 있어졌다.
개발자 입장에서는 고마운 친구😃~

VPC: Private한 네트워크/인트라넷이지만 인터넷으로 확장될 수 있다.

가상 서버의 종류 증가

  • EC2
  • RDS
  • S3
  • ... 등등

AWS 클라우드 서비스는 2개로 나뉘어진다.
리전 서비스랑 글로벌 서비스!
우리가 사용하는건 대부분 리전 서비스긴 하지만 두 개의 대한 설명은 아래와 같다.

Region Service: Region에 국한되어 제공되는 서비스들

  • EC2 : 서비스
  • Elastic Beanstalk: 서비스 배포 및 제공
  • Lambda: 서버리스 함수 실행기

Global Service: Region에 상관없이 전역적으로 제공되어야 하는 서비스들

  • IAM: AWS 계정 권한 및 역할 관리
  • Route53: DNS Service
  • CloudFront: CDN
  • WAF: Web Application Firewall
  • Certificate Manager: HTTPS 등 관리

그렇다면 왜 굳이 분리할까?

Proximity(시간 지연/근접성), Available Service을 고려해줘야 하기 때문!

Region에 대한 정의는 아래와 같다.

물리적으로 AZ(Available Zone)의 집합
AZ는 지역별로 설치되어 있는 Data Center의 집합
ex. Korea Region에는 서울 AZ, 경기 AZ, 부산 AZ, ...이 존재

함수에 대해서도 알아보자
우리가 아는 그 함수랑 조금 다르다.
동적인 것과 정적인 것으로 우선 나눌 수 있는데 동적인 함수에는 EC2, Lambda가 있고, 정적인 함수에는 S3가 있다.

EC2: 상시 띄워져 있고 CPU, Memory가 계속 상주하고 있어 자원을 많이 소모한다.
Lambda: 비 상시이며 이벤트 기반의 서버리스 컴퓨팅 서비스
S3: 비 상시이며 HTML, CSS, ...를 배포할 때 CDN을 통해 여러 Edge Location에 배포한다.

Edge Location

  • CDN의 분산된 노드
  • 사용자와 더 가까운 위치에 있는 서버
  • 캐시된 콘텐츠를 저장하고 사용자의 요청을 처리

네트워크 개요

네트워크에 대해 알아보기 전에 CIDR이라는 개념을 알고 가는 것이 좋다!
CIDR이란?
네트워크를 정의할 때 사용하는 개념으로 아래와 같이 2가지로 구성되어 있다.

  • Base IP: 사용 가능한 첫 IP
  • Subnet Mask: 위 Base IP에서 미 사용 영역

    우리는 일상에서 마스킹 테이프를 페인트칠할 때 묻지 말아야 할 영역에 미리 붙여놓는다. 여기서 마스크가 이 마스크!

연습 문제

  1. 192.168.0.0/24에서 IP Range는 어디서 어디까지고 몇개인가?
    => 24비트를 마스킹한다는 뜻으로 192.168.0.0 ~ 192.168.0.255까지 할당가능하다. 따라서 총 2^8개

  2. 192.168.0.0/16에서 IP Range는 어디서 어디까지고 몇개인가?
    => 16비트를 마스킹한다는 뜻으로 192.168.0.0 ~ 192.168.255.255까지 할당가능하다. 따라서 총 2^16개

  3. 192.168.78.123/32에서 IP Range는 어디서 어디까지고 몇개인가?
    => 32비트를 마스킹한다는 뜻인데 총 32비트이므로 IP Range는 1개, 그냥 해당 IP가 할당된 것!!

OSI 7Layer

간단하게 주요 5개층에 대해서만 알아보면 아래와 같다.

  • 7 Application Layer(응용 계층)
    관심사: HTTP Header, Method, IP, Port -> L7 Load Balancer의 역할
  • 4 Transport Layer(트랜스포트 계층)
    관심사: IP, Port -> L4 Load Balancer의 역할
  • 3 Network Layer(네트워크 계층)
    관심사: IP -> Router가 전달
  • 2 Data Link Layer(데이터링크 계층)
    관심사: MAC주소 -> Switch가 전달
  • 1 Physical Layer(물리 계층)
    그냥 광케이블, 랜선 등

AWS 네트워크

VPC(Virtual Private Cloud)
AWS에서 제공하는 가상 네트워크 환경
사용자가 정의한 네트워크 구성, 서브넷, 라우팅 및 보안 규칙 설정 가능

Subnet
VPC로 제공받은 큰 네트워크를 몇 개의 네트워크로 자른 것
즉 "서브 네트워크"
EX. 127.0.0.0/16을 127.0.1.0/24와 127.0.2.0/24로 분리

일반적으로 아래와 같이 2가지로 분류
1. Private Subnet
2. Public Subnet

IGW(Internet Gateway)
서브넷 단위 외부 IP 할당
일반적으로 Public Subnet 할당
Subnet단위로 외부에서 접근 가능하도록 열어주는 말 그대로의 Gateway
-> 밖으로 나가는 관문
-> 밖으로 나가는 사람들의 이름을 관리하는 것이 Route Table

IGW는 VPC내의 리소스가 인터넷으로 통신하기 위해 Gateway역할을 하며, Route Table은 이러한 트래픽을 관리하고 목적지를 지정하는 역할

NAT
인스턴스 단위 외부 IP 할당
Private Subnet내 EC2 서버들도 외부 접근이 가능해야 할 때가 있다.
그럴 때 NAT 사용
밖으로 나갈 EC2를 모아서 NAT Gateway에 연결 혹은 NAT instance에 연결

방화벽

  • NACL(Network ACL, Access Control List): 서브넷 단위 방화벽
    • Subnet에 적용
    • Stateless
    • Rule 등록 및 실행 규칙
      • allow rule만 등록 가능(deny rule 등록 불가)
  • SG(Security Group): 인스턴스 단위 방화벽
    • 인스턴스의 ENI(Elastic Network Interface)에 적용

    • EC2와 같은 단위 자원에 적용

      ex. WAS서버가 4대 존재하고, 동일한 방화벽 Rule을 적용하고자 할 때 1개의 SG를 생성하여 이를 여러 개의 ENI에 적용하면 된다.

    • Stateful

    • Rule 등록 및 실행 규칙

      • allow, deny rule 모두 등록 가능
      • specific한 순서로 rule을 검사

AWS IAM

권한

  • S3에 읽기 가능
  • S3에 쓰기 가능
  • ...

정책(Policy)=권한들(Actions)

  • S3에 대한 기본 조회 접근
  • S3에 대한 기본 CRUD 접근
  • S3에 대한 DML까지 조작 가능 어드민 접근

계정(User, Group, Role)=정책들+권한들

  • User: 사람
    • 어떤 사람이 컴퓨터로 AWS CLI 프로그램을 통해 외부에서 접근할 때
  • Group: User를 그룹화한 것
  • Role: 자원
    • AWS 서비스(ex. EC2)에서 AWS 서비스(ex. S3)에 접근할 때

참고 자료
https://www.youtube.com/watch?v=_mm5ks5aWQ4&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-&index=3

profile
백엔드 개발은 취미인 AI 개발자🥹

0개의 댓글