Web Architecture
1.1 Web Architecture Basic
웹 관련 보안 이야기를 하기 전 자주 사용하는 용어와 웹의 구조와 인증 부분에서 유의 해야하는 점에 대해 간단히 알아보도록 하자.
위 그림은 웹에서 클라이언트부터 서버까지 어떻게 통신이 이루어지는지 담고 있는 그림이다. 개발분야에서 Client Layer에서 API Layer까지는 Front-End라고 하고, 그 외 부분을 Back-End영역으로 구분하지만, 보안 분야에서는 Client Layer 부분을 Client Side 그 외 부분을 Server Side로 구분한다.
1.2 Monolithic Architecture
출처: https://camunda.com/blog/2023/08/monolith-vs-microservice-architecture-comparison/
가장 오래된 Web Architecture라고 볼 수 있는 Monolithic Architecture다. Front-End영역부터 비즈니스 로직, Data Access 계층이 하나의 App으로 결합된 형태다. 이 구조의 특징은 다음과 같다.
- 모든 기능이 하나로 통합된 배포단위
- UI, 비즈니스 로직, Data access 계층이 하나의 App으로 결합
- 모든 컴포넌트가 하나의 배포 단위로 패키징
- 하나의 프로세스로 실행
이 구조는 특정 기능만 확장하기 어렵고, 하나의 배포단위로 구성되기 때문에 기술 스택을 변경하기 어려우며, 같은 이유로 부분적 배포가 불가능해 변경 사항 발생시 전체 Application 재배포가 필요하여 현대에는 많이 사용되고 있지 않다.
1.3 MSA (Micro Services Architecture)
춡처: https://hangbok-archive.com/development/architecture/msa-concept/
현재에 많이 쓰이는 Web 서비스 구조로 주요 특징은 다음과 같다.
- 각 기능이 독립적인 서비스로 분리
- 서비스끼리 API로 통신
- 서비스 독립적 배포
이 구조의 장점으로는 하나의 서비스를 구성하는 각각의 기능 단위가 독립적인 서비스로 분리되어 확장성이 높고, CI/CD에 높은 편의성을 가지고 있다. 하지만 기능 단위로 분리하여 독립적으로 서비스를 운용하기 때문에 초기 설계가 어렵고, 시스템 복잡도가 증가한다는 단점을 가지고 있다. 또한 각 서비스에서 발생하는 트랜젝션 처리가 복잡하며 서비스 간 오버헤드 증가로 전체 서비스에 대해 성능 저하가 발생할 수 있고, 서비스 구조가 복잡하기 때문에 모니터링, 디버깅이 어렵다.
1.4 Serverless Architecture
이미지 출처: https://theburningmonk.com/2020/11/even-simple-serverless-applications-have-complex-architecture-diagrams-so-what/
클라우드 환경에서 적용할 수 있는 서비스 구조로 서버 인프라 관리에 신경 쓰지 않고 코드 작성에만 집중하도록 하는 클라우드 컴퓨팅 실행 모델이다. API Gateway, Lambda Function, DB, Storage 등으로 구성된다. 주요 특징은 다음과 같다.
- 서버 관리 없이 클라우드 제공자가 인프라 관리
- 함수단위 배포 (FaaS)
- Event-driven
- Auto Scaling
앞서 말했듯이 인프라 관리 부담이 없고, 서비스 환경에 따라 자동으로 성능을 조절하는 Auto Scaling이 지원되며, 가용성이 높다는 장점이 있지만, Cold Start Delay가 발생할 수 있고, 벤더 종속성에 대한 이슈가 있고, 상태 유지에 어려움과 같은 단점이 있다.
Cold Start Delay
Serverless 환경에서 발생하는 Cold Start 지연은 함수가 호출될 때 실행 환경(컨테이너) 이 준비되지 않아 발생하는 초기 지연 시간을 의미한다.
발생 원인은 함수가 일정 시간 동안 사용되지 않으면 클라우드 제공업체가 리소스를 회수하여 비용을 절감하기 때문이다. 발생 과정은 다음과 같다.
- 사용자가 함수를 호출
- Serverless 구조에선 코드 실행을 위한 새로운 실행환경(컨테이너)를 생성 해야함.
- 코드 다운로드, 환경 초기화, 런타임 시작과 같은 과정에서 시간 소요
Container
프로세스(명령)을 동작시키기 위해 정의 된 라이브러리를 실행할 수 있는 환경이다. 컨테이너 개념 등장 이전에는 가상 환경에서 OS를 설치하여 사용했는데, 이 설치과정에서 성능과 비용에 대한 문제가 있었다.
Container는 Host OS를 공유하며 애플리케이션과 그 실행에 필요한 모든 파일(라이브러리, 설정 등) 을 함께 묶어 격리된 공간(프로세스 격리) 을 제공하여 이 문제를 해결했다.
2. Security Basic
2.1 Web Authentication
Web 환경에서 사용자 로그인 시 보안적으로 신경 써야하는 부분과 인증에서 중요한 부분을 가볍게 짚어 보도록 하자.
먼저 요즘은 많이 없지만 로그인 시 ID or PW를 특정해서 잘못됐다고 하는 응답을 예전엔 많이 볼 수 있었다. 이러한 방식이 사용자의 편의성을 증대 시킬 수 있다고 할 수 있지만 보안 관점에서 Brute Force Attack을 받을 수 있는 취약점으로 다가온다. 따라서 위 경우에는 방화벽에서 Deny가 아닌 Drop을 하는 것이 맞다.
Deny vs Drop
Deny와 Drop은 모두 트래픽을 차단하는 기능을 하지만, 근본적인 차이는 송신자에게 응답을 보내는지 여부에 있다. Deny (또는 Reject)는 방화벽이 패킷을 차단하면서 송신자에게 거부 응답을 돌려보내는 방식이고, Drop은 방화벽이 패킷을 차단하고 어떤 응답도 보내지 않고 패킷을 버리는 방식이다.
웹 인증 방식 중 핵심 요소는 쿠키(Cookie), 세션(Session), 토큰(Token) 으로 웹 환경은 기본적으로 상태를 유지하지 않는 무상태(Stateless) 특성을 가지는 HTTP 프로토콜을 사용하기 때문에 사용자가 로그인한 상태를 지속하고 요청을 식별하기 위해 이러한 인증 방식들이 필요하다.
그러면 인증에서 근본적으로 어떤 점이 중요할까?
-
인증정보는 어떻게 처리 되는가
인증 정보는 메모리 버퍼에 저장되어 이를 기점으로 system foot print 추적한다. -
인증정보는 IP검증을 하는가
ip가 달라질 때 세션이 만료된다면 사용자 경험이 하락하기 때문에, 멀티 세션 체크를 통해 사용성을 증가시킨다.Multi Session Check
동일한 사용자 계정으로 여러 곳에서 동시에 접속했는지 확인하는 보안 절차를 의미한다. 세션을 ip단위로 발급하면 안되기 때문에 단말기 단위로 발급을 수행하게 된다.
-
인증정보 expire
로그아웃을 통해 인증 정보 만료가 되는데 멀티 세션 체크를 안하면 expire time이 갱신이 안되어 해당 계정은 좀비 상태가 되어 여러 단말기에서 사용 가능하게 될 수 있다. 또한 로그아웃 안하고 창을 닫았다면 expire signal이 안가서 즉시 세션 만료 안되는 문제가 발생할 수 있다. -
인증정보는 변조 위험이 없는가?
오래 전 사이트 경우 쿠키에 인증 관련 정보가 담겨 있어 super user로 권한 상승 가능성 있었지만 최근에는 담겨 있지 않다.
2.1.1 🍪 Cookie
쿠키는 클라이언트(브라우저) 측에 저장되는 Key-Value 형태의 작은 데이터 파일로, 서버가 클라이언트에게 응답할 때 Set-Cookie 헤더를 통해 쿠키를 전송하며, 클라이언트는 이후 해당 웹사이트에 요청할 때마다 이 쿠키를 Cookie 헤더에 담아 다시 서버로 전송하는 방식으로 동작한다.
- Session Cookie
Expires또는Max-Age옵션이 설정되지 않은 쿠키로 웹 브라우저가 종료될 때 함께 삭제된다. 로그인 상태 유지, 일시적으로 사용자 설정 저장 등 휘발성 정보에 주로 사용한다. - Persistent Cookie
Expires또는Max-Age옵션으로 만료 기간이 설정된 쿠키로, 설정된 만료 날짜/시간 또는 기간이 지나야 삭제된다. 자동 로그인, 장바구니 정보, 사용자 선호 설정 등 영구적인 정보 저장에 사용한다.
2.1.2 Session 및 Session ID
Session은 웹 서비스에서 클라이언트와 서버 간의 연결이 활성화된 상태를 의미하며, 특히 사용자가 로그인했을 때 그 상태를 서버에서 유지/관리하는 방식을 말한다. Session ID는 서버가 세션을 식별하기 위해 발급하는 Key값으로 민감 정보를 찾아오기 위한 매개체 역할을 수행한다.
- 동작 방식
1. 사용자 로그인 성공시 서버는 사용자 정보를 서버 메모리, 파일과 같은 Session Storage에 저장한다.
2. 서버는 이 정보에 접근할 수 있는 Session ID를 생성한다.
3. 세션 ID를 담은 세션 쿠키를 클라이언트(브라우저)에게 응답과 함께 전송
4. 클라이언트는 이 세션 쿠키를 저장하고, 이후 인증이 필요한 모든 요청에 세션 쿠키(세션 ID 포함)를 함께 서버로 전송
5. 서버는 요청에 포함된 세션 ID를 통해 세션 저장소에서 해당 사용자 정보를 조회하여 인증을 확인
2.1.3 Token
토큰(Token) 기반 인증은 사용자 인증 정보를 서버가 아닌 클라이언트(브라우저의 로컬 스토리지, 세션 스토리지, 또는 쿠키)에 저장하고, 요청 시마다 토큰을 HTTP 헤더에 담아 전송하는 방식으로 가장 대표적인 토큰 방식은 JWT(JSON Web Token)가 있다.
- 동작 방식
1. 사용자가 로그인에 성공하면, 서버는 사용자 인증 정보(ID, 권한 등)를 담아 암호화된 토큰을 생성하고 서명(Signature)한다.
2. 서버는 이 토큰을 클라이언트에게 응답으로 전송.
3. 클라이언트는 토큰을 저장하고, 이후 인증이 필요한 요청마다 HTTP 헤더(주로Authorization헤더)에 토큰을 담아 서버로 보낸다.
4. 서버는 토큰을 검증(Signature 확인 등)하여 유효성을 판단하고, 토큰 내부에 포함된 정보를 활용해 사용자를 식별하고 권한을 확인한다.
세션과 달리, 서버가 사용자의 상태(State)를 별도로 저장할 필요가 없어 Stateless한 특징을 가진다.
2.2 HSTS: HTTP Strict Transport Security
사이트가 HTTPS를 통해서만 접근되어야 하며 향후 HTTP를 사용하여 사이트에 접근하려는 모든 시도는 자동으로 HTTPS로 변환되어야 함을 브라우저에게 알리는 기능이다. HTTP로 접속시 MITM 공격, SSL Hijrcking 공격 등에 노출되는 것을 방지하기 위해 HTTPS로 접속을 강제한다.
- 특정 사이트 접속
- 해당 도메인에 우선 HTTP로 접속 시도
- 도메인을 파싱하여 HSTS 리스트와 비교 후 HTTPS 로 접속
- 해당 도메인이 HTTPS만을 지원하는 사이트라 가정
- 접속한적이 없는데 HTTP접속 시도 301redirect reply message로 https로 접속 시도
- server는 http reply에 hsts policy를 넣어 전송 -> 암호화 되기 전 packet인, HTTP response header field에 "Strict-Transport-Security" 필드 정보 삽입
- 브라우저는 HSTS 리스트 구성
- Server는 "Max Age", "Subdomain 적용여부", "Preloaded List에 추가여부"을 HTTP response header field에 담아 "Strict-Transport-Security" 함께 client에 전달
- 만약, Web Browser가 HTTP Protocol로 Web Server에 접속하고, HTTP Reply Message에 HSTS Policy 정보가 들어 있는 경우는 무시
용어
- max age: HSTS 리스트 내 정보 유지 기간
- Subdomain 적용 여부: 해당 도메인의 하위 도메인에도 정책을 적용할 것인지 여부
- Preloaded List 추가 여부: 자신의 도메인을 브라우저에 미리 load할건지
2.3 Side jacking
출처: https://developer.mozilla.org/ko/docs/Glossary/Session_Hijacking
비인가된 접근을 통해 victim에 session,cookie를 탈취하여 계정정보를 악용하는 공격이다. 공격 방식이 수동적이냐 능동적이냐에 따라 sidejacking, Session Hijacking으로 나뉘는데, 여기서 수동적이라는 것은 공격자가 특정 작업을 수행하지 않는다는 것이고, 능동적이라는 것은 공격자가 패킷 조작과 같은 직접적인 개입을 하는 것이다.
- sidejacking (passive)
암호화 되지 않은 세션 쿠키를 가로채어 사용자의 세션을 탈취하는 공격으로 평문으로 전송되는 쿠키를 Sniffing 하는 방법으로 암호화를 하거나 https 사용을 통해 쉽게 방지가 가능하다. - session hijacking (Active)
공격자가 패킷 조작과 같은 직접적인 개입을 함. 이 공격을 위해서 victim은 wifi외 같은 접속 환경에 있어야 한다.
1. https 웹사이트(ex google)에 접속하여 로그인을 하면 웹서버에서 해당 인증 정보를 통해 쿠키를 발급함
2. 이후 http 웹사이트에 접속하면 공격자는 해당 페이지 reply에 악성 코드를 삽입 (ex<img>를 이용하여 src에 http://mail.google.com/mail과 같은 url삽입)
3. 웹 사이트는 해당 url에 요청
4. 공격자가 삽입한 url에 접속시 쿠키 정보 받을 수 있음. 이때 http로 요청했기 때문에 평문으로 구성된 쿠키를 받음
2.4 HTTP/3
다양한 컨텐츠를 여러 기기에 신속하게 전달하기 위해 TCP의 한계(TCP HOLB)를 극복하고 최적화하는 QUIC 프로토콜을 L4에서 동직 시키기 위해 설계 된 것이다.
TCP HOLB(Head Of Line Blocking)
TCP의 패킷 순서 보장이리는 특징 때문에 먼저 보내진 패킷에 장애가 발생하면 그 뒤에 패킷들이 대기하여 전송 지연 문제
Cloud
3.1 On-Premise
Legacy라고도 불리는 On-Premise는 서버, 네트워크 장비 등으로 구성 된 시스템을 직접 운영하는 것을 의미한다. 자신의 서비스의 요구사항에 맞춰 장치 사양, 장치 등을 자유롭게 선택이 가능하다는 장점이 있지만, 유지보수에 어려움이 있고, 확장성이 떨어진다는 단점이 있다.
3.2 Cloud Service
먼저 클라우드란 인터넷을 통해 가상화된 서버의 컴퓨팅 자원을 빌려 쓰는 IT 환경을 의미하며 클라우드의 종류는 Public Cloud와 Private Cloud 두 가지로 구분한다.
Public Cloud
Cloud 사업자가 시스템을 구축, 네트워크를 통해 불특정 다수에게 서비스를 제공하는 형태이다.Private Cloud
On-Premise 환경을 포함하여 자사 전용 환경을 구축하여 클라우드를 사용하는 형태이다.
클라우드에서 지원하는 대표적인 서비스는 다음과 같다.
IaaS
클라우드 인프라를 서비스로 제공하는 형태로 가상화 된 컴퓨팅 리소스, OS 등을 사용자에게 제공한다. 대표적으로 AWS Ec2가 있다.PaaS
애플리케이션 개발 및 배포를 위한 플랫폼을 제공한다.SaaS
클라우드 애플리케이션을 서비스로 제공하는 형태로 Google Excel, ppt와 같은 것들이 있다.
3.3 Cloud 이용
일반적으로 기업이 Cloud 환경을 이용하는 방식을 아래와 같이 크게 두 가지로 나눌 수 있다.
Multi Cloud
2개 이상 public cloud 또는 private cloud로 구성된 형태이다. 여러 클라우드 사업자를 이용해 한쪽이 중단되어도 다른 한쪽이 살아 있어 가용성이 확보 된다는 장점과 하나의 클라우드 제공자에 의존하지 않기 때문에 벤더 종속을 회피할 수 있고, 그 외에도 비용 절감, 보안을 강화할 수 있다는 장점이 있다.Hybrid Cloud
Public Cloud와 On-Premise 포함 Private Cloud 조합으로 구성된 환경이다. public cloud에서 필요한 만큼 자원 확보하고 자사 환경에서도 자원을 확보하기 때문에 확장성이 높고 각 환경의 기능을 조합하여 활용할 수 있어 유연성이 높다. 또, 민감한 데이터는 Private Cloud 환경에서 운영하고 민감하지 않은 데이터는 Public Cloud에서 다룸으로서 보안이 강화된다.
3.4 Cloud 공동 책임 모델
출처: https://docs.aws.amazon.com/ko_kr/wellarchitected/latest/security-pillar/shared-responsibility.html
클라우드 공동 책임 모델 (Shared Responsibility Model)은 클라우드 컴퓨팅 환경에서 클라우드 서비스 제공자 (CSP) 와 고객이 각각 어떤 보안 및 규정 준수 영역을 책임지는지를 정의하는 개념이다. 여기서 핵심은 클라우드의 보안과 클라우드 내의 보안(Security in the Cloud)을 나누는 것이다.
-
클라우드 서비스 제공자 (CSP)의 책임
물리적 시설, 호스트 운영 체제, 가상화 계층, 네트워크 인프라 등 클라우드 서비스의 작동에 필수적인 요소의 보안을 담당한다. (예: AWS, Azure, GCP 자체의 보안) -
고객의 책임 (Security in the Cloud):
클라우드 내부에 배포한 자원(애플리케이션, 데이터) 및 그 설정에 대한 보안을 담당한다. 운영체제(OS) 패치, 애플리케이션 보안, 데이터 암호화, 네트워크 및 방화벽 구성, 접근 제어 및 권한 관리 (Identity and Access Management, IAM) 등이 포함된다.
제공되는 서비스 유형(IaaS, PaaS, SaaS)에 따라 책임의 경계는 달라지는데, IaaS 서비스와 같이 고객의 자유도가 높은 서비스일수록 고객의 책임이 커지고, SaaS와 같이 제품 형태로 제공될수록 서비스 제공자의 책임이 커진다.
4.1 Ec2 (Elastic Compute Cloud)
출처: https://nidhiashtikar.medium.com/amazon-ec2-infrastructure-as-a-service-59733b9db042
AWS EC2는 확장 가능한 컴퓨팅 리소스를 클라우드에서 제공하는 서비스로, 이는 사용자가 클라우드 환경에서 가상 서버를 생성하고 운영할 수 있게 해준다.
- 핵심 기능
클라우드에서 VM을 제공하는데, 이를 인스턴스(Instance) 라 하고, 사용자는 필요에 따라 CPU, 메모리, 스토리지 등의 사양을 선택하여 생성할 수 있다. - 특징:
- 탄력성 (Elasticity): 사용량에 따라 컴퓨팅 용량을 쉽게 늘리거나 줄일 수 있다.
- 제어: 사용자는 OS, 보안 설정, 네트워킹 등 서버 환경을 완전히 제어할 수 있다.
- 비용 효율성: 실제로 사용한 컴퓨팅 시간과 리소스에 대해서만 비용을 지불하는 종량제 모델이다.
4.2 VPC (Virtual Private Cloud)
출처: https://www.mgt-commerce.com/blog/virtual-private-cloud-aws/
VPC는 클라우드 서비스 제공자 내에 사용자 전용의 논리적으로 격리된 가상 네트워크를 생성하는 서비스로, 주요 특징은 다음과 같다.
-
격리 및 제어
사용자는 자신의 VPC 내에서 IP 주소 범위, 서브넷, 라우팅 테이블, 네트워크 게이트웨이 등을 직접 설정하여 네트워크 환경을 완벽하게 제어하고 다른 클라우드 사용자와 논리적으로 격리할 수 있다. -
보안
VPC는 네트워크 접근 제어 목록(ACL) 및 보안 그룹(Security Group) 같은 기능을 통해 인스턴스 수준과 서브넷 수준에서 강력한 보안 규칙을 적용하는 기본 구조를 제공한다. -
활용
EC2 인스턴스, 데이터베이스 등 클라우드 리소스를 이 사설 네트워크 안에 배포하여 인터넷 노출 여부나 트래픽 흐름을 정밀하게 관리하는 데 사용된다.
출처: https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/what-is-amazon-vpc.html
이와 같이 인스턴스를 하나의 vpc (인스턴스 분리 구조도 가능) 내에 구성하여 네트워크 환경을 구축할 수 있다.
4.3 Ec2 인스턴스 생성과 VPC 생성 실습
할당 받은 ip, 인스턴스, vpc 정보는 유출되면 보안적으로 문제가 되기 때문에 모두 가렸습니다.
VPC 세팅
subnet은 public, private 두 가지 생성했다. 하나는 웹 서버용, 하나는 DB 서버용으로 사용할 것이다.
IGW(Internet Gateway)는 public subnet에 연결 해주고, NGW(NAT Gateway)는 private에 연결한다.
Web Server 측 보안 그룹 설정
web server instance의 보안 그룹은 아래와 같이 세팅.(사전에 할당받은 ip사용)
ping test를 위해 icmp를 추가
DB Server 측 보안 그룹 설정
사전에 할당 받은 IP로 SSH, DB server, ICMP를 허용
Ec2 인스턴스도 위와 같이 web server, db server 두 개를 생성해준다.
현재 사용중인 pc에서 web server로 SSH 접속되는지 확인을 해준다. 만약 접속이 안된다면 인증서나 SSH 접속을 허용하고 있는지 확인할 필요가 있다.
web server에서 DB 인스턴스로 접속 되는지 확인한다. 보안 그룹 설정에서 허용했기 때문에 접속이 가능하지만 물리 머신에서 DB 인스턴스로 직접 접속은 당연히 안된다. 이를 허용하는 것은 실제 웹 서비스에서 클라이언트가 DB에 직접 접근하는 것과 같아 보안상 치명적인 문제로 이어진다.
