[정보 보안] 4. 금융보안 인프라 구축

클라우드 기초 - 클라우드 이해

 

현황

- 95% 의 보안사고가 사용자의 실수로 발생됨

 

온 프레메스

- 클라우드 사 측에서는 서비스 구축을 다 하고 테스트를 거친 후에 서비스를 배포함 (보안 위험성이 많지 않음)

- AWS -> 공동 보안 책임, 책임 영역을 확실하게 나눈뒤에 서비스 함

- 사용자측 설정 실수는 사용자 책임임, 그렇기에 클라우드에 대한 이해가 필요!!

 

클라우드 특징 (NIST def)

(** 보안 사고 위험)

- 주문형 셀프 서비스 ** 

- 광범위 네트워크 접근 **

- 빠른 탄력성 ** (빠르게 늘림 -> 추적이 안됨)

- 리소스 풀링

- 서비스 측정 

 

- 변동성: 인프라가 빨리 배포되고 빨리 사라짐

- 비가시성: 잠깐 있다가 사라짐 (책임소재 불분명)

 

 

가상화

- 하이퍼바이저: 호스트 컴퓨터에서 다수의 운영 체제를 동시에 실행하기 위한 논리적 플랫폼 (침해사고의 영역 침범 불가, 독립화)

- 도커: 애플리케이션을 신속하게 구축, 테스트 및 배포할 수 있는 소프트웨어 플랫폼 (침해사고의 영역 침범 가능, 독립화 X)

 

 

IaaS: 물리적인 부분은 클라우드 측 책임

PaaS: 런타임은 클라우드 측 책임 (내가 데이터 관리)

SaaS: 소프트웨어 설치 필요 없음 (서비스 한 사람이 테이터 관리)

 

 

보안 트렌드  - 제로 트러스트 이해

 

기존의 보안 - 성벽을 쌓는 느낌! (출입만 엄격함)

제로트러스트 - 동일하게 성벽을 쌓지만, 항상 검증하고 필요한 만큼만 권할을 부여함

 

"Never Trust, Always Verify"

"암묵적으로 믿어왔던 것들을 그냥 믿지말고 검증하자"

 

제로트러스트 기본 원칙

1. 모든 데이터와 컴퓨팅 서비스는 리소스로 간주

2. 네트워크 위치에 관계없이 모든 통신 보호

3. 기업 리소스에 대한 접근을 세션 단위로 승인

4. 동적정책으로 리소스에 대한 접근 결정

5. 모든 자산의 무결성 및 보안상태 감시/조치

6. 모든 리소스의 인증/인가를 엄격하게 점검 후 동적으로 허용

7. 자산, 네트워크, 인프라 등 현 상태에 대한 정보 수집 및 개선

 

제로트러스트 정책을 통해서 디바이스 유효성, 사용자, IP, 인증 여부 등을 확인하고 단계별 권한 부여

 

 

국내외 현황

해외 - 미국 행정부 행정명령: 2년 이내 제로트러스트 이행 전략 수립 명령, 표준 배포

        - 일본, 미국: 가이드라인 배포

국내 - 제로트러스트 포럼 (가이드라인 1.0)

 

제로 트러스트를 시작하기 힘든 이유는 사전 준비가 너무 어렵다는 것!!