Spring 숙련 (클라우드, AWS 기본)

KimGwangmin·3일 전
aws내일배움캠프

[내일배움캠프 백엔드] 강의 정리

목록 보기
51/53

서버의 위치에 따른 구분

온프레미스(On-Premise)

회사가 직접 자체적인 서버를 운영하는 방식

  • 직접 서버 설치 및 관리, 네트워크 구축을 해야 함
  • 전기/냉방비 등 유지 비용 소모

클라우드

AWS, GCP, Azure 등의 업체에서 서버를 빌려 사용하는 방식

  • 수많은 서버가 이미 준비되어 있음
  • 원할 때 서버를 할당/반납할 수 있음
  • 초기 투자 비용이 작음
  • 인건비 절약, 빠른 시작, 확장 용이, 서비스 실패 시 매몰 비용 낮음

IaaS/PaaS/SaaS

IaaS (Infrastructure as a Service)

인프라(서버, 네트워크, 스토리지)만 빌린다

강의에서는 주로 이 서비스를 다룬다

  • AWS 예시: EC2

PaaS (Platform as a Service)

플랫폼(런타임, 미들웨어 포함)까지 빌린다

IaaS는 컴퓨터만 빌리고, 그 안에 필요한 건 직접 설치해주어야 함
PaaS는 필요한 플랫폼까지 구축이 되어있는 걸 빌림
(대신 요금이 더 비싼 편)

  • AWS 예시: Elastic Beanstalk
  • 업체 제공: 서버, 네트워크, 운영체제, 런타임, 오토스케일링, 로드 밸런싱 등
  • 내 담당: 애플리케이션 코드 작성 및 배포

SaaS (Software as a Service)

소프트웨어(완성된 서비스)를 빌린다

  • 업체 제공: 모든 것
  • 내 담당: 툴 사용

AWS

가장 대중적인 클라우드 서비스

기본 용어

  • Account
    • AWS 서비스 사용 기본 단위
    • 결제, 보안, 리소스 관리의 경계
    • 1인 1계정 또는 회사 당 여러 계정
  • Region
    • 지리적 영역 (서울, 버지니아 등)
    • 서울은 ap-northeaset-2
    • 리전마다 인프라, 시스템 통제권, 데이터가 완전히 독립적
  • AZ(Availability Zone)
    • 리전 안의 개별 데이터 센터
    • 서울 리전에는 4개의 AZ가 존재
    • 고가용성(High Availablity): 하나의 데이터센터에 장애가 발생해도 다른 AZ에서 서비스 유지 가능

서비스 예시

  • EC2: 가상 서버
  • RDS: 데이터베이스
  • S3: 이미지/파일 저장
  • ...

보안 책임

  • 고객 책임: 클라우드 안에서 내가 만든 것들

    • 데이터 암호화
    • IAM 사용자/권한 관리
    • 보안그룹 설정

  • AWS 책임: 클라우드 자체 인프라

    • 데이터센터 물리적 보안
    • 네트워크 인프라

사용자가 설정한 것은 사용자의 책임이다!

  • IaaS : 인프라만 빌림 -> 내가 거의 모두 관리
  • PaaS : 플랫폼까지 빌림 -> IaaS보다 AWS의 관리 범위 많음
  • SaaS : 소프트웨어까지도 빌림 -> 거의 다 AWS가 관리

Budget

클라우드 예산 안전장치 기능

  • 예산 계획 수립 및 모니터링
  • 예산 예측
  • 알림

IAM (Identity and Access Management)

누가 어떤 AWS 리소스에 무엇을 할 수 있는지를 정하고 통제하는 접근 제어 시스템

  • Who: 이 요청이 인증되었는지
  • What: 어떤 작업을 하려 하는지
  • Can: 그 작업을 할 권한이 있는지
  • 역할별로 권한을 분리해서, 필요한 권한만 부여
  • IAM은 각 계정(사람)에게만 붙지 않고, 서버에도 붙을 수 있음
    • 서버 역시 다른 서버에 접근할 때 권한이 필요하다

User

사람이 AWS에 접근할 때 사용하는 계정

  • 사람이 AWS를 직접 조작하는 모든 경우

    • 개발자가 AWS 콘솔에 로그인
    • 관리자가 CLI로 AWS 관리

  • 영구적인 자격증명(Credential)을 가짐(삭제 전까지 만료가 없음)

    1. 비밀번호: AWS 콘솔 로그인
    2. Access Key: API/CLI 접근
      • Access Key ID: 아이디 역할
      • Secret Access Key: 비밀번호 역할
    • 1인 1계정 원칙 권장

예시

  • kim-dev: 개발자 김씨의 계정 (개발 관련 권한)
  • lee-admin: 관리자 이씨의 계정 (관리자 권한)
  • park-front: 프론트 박씨의 계정 (읽기 권한만)
    • 보통 백엔드 혹인 인프라 담당(큰 회사의 경우)이 프론트 배포도 맡는다.

Access Key 문제

  • User 권한은 한 번 생성하면 영구적
  • Access Key(비밀번호) 유출 시 큰 사고
  • 관리 어려움

    -> 서버/자동화에서는 User 대신 Role을 사용한다!

Role

서버/서비스에게 권한을 부여할 때 사용

  • 서버/자동화 시스템이 AWS를 사용하는 모든 경우

    • EC2 서버가 S3에 파일을 업로드할 때
    • GitHub Actions가 AWS에 배포할 때

  • 임시로 빌려쓰는 권한 세트

UserRole
사람용서버/서비스용
영구 자격증명 보유(비밀번호, Access Key)자격증명 없음(필요할 때 임시 발급)
직접 로그인 가능직접 로그인 불가(권한을 빌려서 사용)
만료 없음자동 만료

Policy

어떤 작업을 허용/거부할지 정의

  • Policy를 User나 Role에 연결해서 사용
  • 해당 User/해당 Role을 가진 서버가 Policy에 따라 작업을 할 수 있게 됨

Policy 예시

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",              		  ← 허용? 거부?
      "Action": "s3:GetObject",       		  ← 어떤 동작을?
      "Resource": "arn:aws:s3:::my-bucket/*"  ← 어떤 대상에?
    }
  ]
}
  • "Effect": "Allow": Allow 이므로 허용 (거부일 경우 Deny)
  • "Action": "s3:GetObject": S3에서 Object를 가져오기
  • "Resource": "arn:aws:s3:::my-bucket/*": S3의 my-bucket/* 대상

ARN(Amazon Resource Name

  • AWS 리소스의 고유 주소
  • arn:aws:{서비스}:... 형식

자주 쓰이는 Policy

AWS에서 자주 쓰이는 Policy는 미리 만들어져 제공된다.

Policy 이름설명위험도
AdministratorAccess모든 권한🔴 매우 높음
AmazonS3FullAccessS3 전체 권한🟠 중간
AmazonS3ReadOnlyAccessS3 읽기만🟢 낮음
AmazonEC2FullAccessEC2 전체 권한🟠 중간

중요 보안 원칙

최소 권한 원칙

  • 사용자가 작업을 수행하는데 반드시 필요한 권한만 부여
  • 처음엔 아무 권한도 주지 말고, 필요에 따라 권한을 하나씩 추가
  • IAM Access Analyzer 사용, 안쓰이는 과도한 권한 식별 및 제거

루트 사용자 보호

루트 사용자는 모든 권한을 가지고 있음

  • Access Key 삭제
    • 루트 사용자의 Access Key ID, Secret Access Key는 사용하지 않기
  • 일상 업무에 루트 계정 사용 금지
    • 계정 생성, 결제 정보 수정 등 높은 권한이 필요한 특수한 경우에만 사용
profile
KimGwangmin
이전 포스트

Spring 숙련 (Lua Script)

다음 포스트

Spring 심화 (보안 그룹, VPC)

0개의 댓글