주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 8, 9장

이번 장에서는 보안과 리눅스 명령어와 관련된 내용이 나온다.

 

8장: 실무에서 꼭 필요한 보안 지식

• 인증(authentication) : 사용자가 누구인지 확인하는 과정
• 인가(authorization) : 사용자에게 자원에 접근할 수 있는 권한 부여

 

 

인증에 성공하면 서버는 클라이언트에 토큰을 제공한다. 여기서 토큰은 넓은 의미로 ‘신원 증명 수단’으로 이해하면 된다.

인증(Authentication)

세션 기반 (Stateful)

• 서버가 세션 ID 발급
• 실제 인증 정보는 세션 ID를 key로 한 서버 측 저장소(메모리, DB, Redis 등)에 저장
• 클라이언트는 세션 ID만 가지고 요청하고, 서버는 매 요청마다 세션 저장소를 조회해 사용자를 확인

세션 정보를 저장소에 저장하기 때문에 작지만 용량을 차지한다. (사용자가 많아지면 고려해야 함)

그리고 요청마다 저장소를 확인해야 하기 때문에, 그로 인한 레이턴시도 고려해야 한다.

 

단일 서버면 괜찮지만 서버가 여러 대이면?

 

1. 고정 세션(sticky session)

Sticky Session은 로드밸런서 환경에서 같은 사용자의 요청을 항상 같은 서버로 보내는 방식이다.

 

 

메모리에 토큰 데이터를 저장하는 경우, 고정 세션이 필요하다. 왜냐하면 서버마다 서로 다른 토큰 집합을 가지고 있어, 발급받은 토큰을 발급받았던 서버에 요청을 보내지 않으면 인증이 안되었다고 판단되기 때문이다.

 

2. 로컬 메모리가 아닌 저장소 사용

스프링 세션(Spring Session)을 사용해 DB나 Redis같은 외부 저장소에 세션 데이터를 저장할 수 있다.

 

토큰 기반 (Stateless)

우리가 알고 있는 대표적인 방식인 JWT(Json Web Token)을 이용한다.

 

장점

• 토큰만 있으면 사용자 식별 가능
• 수평 확장하기 쉽다.

단점

• 토큰의 크기가 증가 → 네트워크 트래픽 증가
• 서버에서 제어하기 힘듦(무효화 등)

토큰 보안과 관련해서

• 토큰 유효 시간
• 토큰 생성 시 클라이언트 IP와 토큰을 전송한 클라이언트 IP 비교 → IP가 다르면 비정상 접근으로 간주해 요청 처리를 거부할 수 있다. (추가로 User-Agent도 확인할 수 있다)
• Access Token과 Refresh Token 정책
  • Refresh Token → HttpOnly + Secure(HTTPS) + SameSite(CSRF)
  • Refresh Token Rotation
  • Refresh Token 저장소 관리

 

인가(Authorization)

접근 제어(Access Control) : 누가(Subject) 무엇(Resource)에 어떤 행동(Action)을 할 수 있는지 결정하는 것

 

RBAC (Role-Based Access Control)

사용자에게 직접 권한을 부여하지 않고, 역할 기반으로 권한을 관리하는 모델

 

NIST 기준 RBAC 레벨

• Flat (RBAC0)
  • User <-> Role, Role <-> Permission 매핑만 존재하는 단순한 모델
• Hierarchical (RBAC1) — 역할 계층 (Role Hierarchy) 개념 추가
  • 상위 역할이 하위 역할 권한 포함 (상속)
• Constrained (RBAC2) — 제약 조건 (Constraints) 개념 추가
  • 동시에 가질 수 없는 역할을 설정한다거나
  • 가질 수 있는 최대 역할 개수를 설정한다거나
• Symmetric (RBAC3)
  • 권한이 어떤 역할에 의해 부여되는지 확인할 수 있어야 함

 

어떻게 구현? → Spring Security로 구현 가능

• PreAuthorize
• hasRole
• hasAuthority
• RoleHierarchy
• SpEL (Spring Expression Language)
• 등등..

DB를 이용해 동적으로 역할 및 권한 관리하면서 캐시까지 붙여 사용한다.

 

ABAC (Attribute-Based Access Control)

사용자, 리소스, 행동, 환경의 속성과 정책을 기준으로 접근을 결정하는 모델

→ 누가(Subject) 무엇을(Resource) 어떻게(Action) 어떤 상황에서(Environment)

 

[RBAC]
사용자 → 역할 → 권한
"EDITOR 역할이면 글 수정 가능"

[ABAC]
속성들의 조합으로 판단
"마케팅 부서 + 매니저 + 본인 부서 문서 + 업무 시간 → 수정 가능"

 

보안

WAF (Web Application Firewall)

웹 애플리케이션 레벨(L7)에서 공격을 탐지하고 차단하는 보안 솔루션

다음과 같은 것들을 감지하고 막을 수 있다.

• SQL Injection
• XSS (Cross-Site Scripting)
• Command Injection
• Path Traversal
• DDoS / Rate Limiting

클라우드에서도 WAF를 제공한다.

• AWS WAF
• Cloudflare WAF
• Azure WAF

 

---

 

9장: 최소한 알고 있어야 할 서버 지식

 

sudoers

sudo 명령어의 권한을 정의하는 설정 파일. 어떤 사용자가 어떤 명령어를 root 권한으로 실행할 수 있는지 제어한다.

 

/etc/sudoers           # 메인 설정 파일
/etc/sudoers.d/        # 추가 설정 디렉토리

 

visudo 명령어를 통해 파일을 편집해야 한다.

• 기본 구조

사용자    호스트=(실행사용자:실행그룹)      명령어
WHO       WHERE=(RUNAS_USER:RUNAS_GROUP)   WHAT

 

기본적으로 sudo 를 통해 실행하면 비밀번호를 요구하는데, NOPASSWD: 를 붙이면 비밀번호 없이 실행된다.

 

user ALL=(ALL) NOPASSWD: ALL

 

nohup (No Hang Up)

터미널 세션이 종료되어도 프로세스가 계속 실행되도록 하는 명령어

nohup 명령어 &      # &은 백그라운드 실행 의미

nohup 으로 실행한 프로세스가 출력하는 내용은 nohup.out 에 기록되는데, 표준 출력 리다이렉션으로(>) 출력 파일을 지정할 수 있다.

 

파일 디스크립터 제한

• ulimit 명령어
• 임시 변경 : ulimit -n 숫자
• 영구 변경 : /etc/security/limits.conf 에서 설정

systemd 서비스는 위에서 설정한 값을 사용하지 않고, /etc/systemd/system.conf 나 /etc/systemd/system 디렉토리에 서비스별로 설정된 값을 사용한다.

 

한 프로세스가 가질 수 있는 파일 디스크립터 개수 제한 확인 → sysctl fs.nr_open 으로 확인하고, /etc/sysctl.conf 파일에서 변경할 수 있다.

 

lsof : 실제 프로세스가 사용 중인 파일 디스크립터 개수 확인