본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
안녕하세요 :)
오늘은 챌린지 40일차로, 비가 주륵주륵 오는 토요일이라 집콕을...
오늘 배울 내용은,
Part B. 스프링 시큐리티 심화
Ch 5. MSA 환경에서의 보안 설계
"01. 마이크로서비스 보안의 특징" 입니다.
오늘은 마이크로서비스 보안의 특징에 대해 알아보는 시간을 가졌다. 먼저 마이크로서비스는 하나의 큰 애플리케이션으로 구성되어 운영되던 프로젝트가 작은 규모의 여러 애플리케이션으로 쪼개져 관리되는 아키텍쳐이다. 데이터베이스 등 인프라도 각 작은 단위의 시스템에 부여되어 있다.
실리콘밸리에서 유행하는 개발 문화 중 하나는 "빠르고 빈번하게 실패하라" (Fail Fast) 로 새로운 도전, 실패 인정, 문제 해결, 재시도의 과정을 반복한다. 위 개발 문화가 정착하려면 마이크로서비스 아키텍쳐가 도입이 되어야 하며, Netflix, Amazon, Uber 등에서 이 아키텍쳐를 도입했으며, 최근에는 많은 IT 회사에서 이를 적용하고 있다.
특히 마이크로서비스에서는 보안을 중요하게 생각해야한다. 해킹, 침해 사고 등은 고객 신뢰 하락으로 이어질 수 있으며 최종적으로는 회사의 파산으로 귀결될 수도 있기 때문이다.
모놀리식 애플리케이션의 보안 동작 원리에 대해 알아보면, 모놀리식 애플리케이션 (monolithic application)은 최소한의 진입점만 가지고 있다. 진입점이라고 하는 것은 건물의 출입구로 생각하면 되며, 사용자의 요청을 허용하거나 거절하는 역할을 한다. 예를 들어, 192.168.0.1 IP 서버에서 HTTP 80 포트를 점유하고 있으면 80 포트는 진입점이 되며, 만약 HTTPS 443 포트까지 점유하고 있다면 출입문이 2개가 되는 것이다. 대부분의 모놀리식 애플리케이션은 출입문이 2-3개 정도를 가지고 있다.
요청을 서블릿 필터 (Servlet Filter) 를 활용하여 애플리케이션 수준에서 보안을 유지하는 것으로 알아보면, 추가 접근 제어 절차로는 특정 메뉴, 기능에 접근 권한이 있는지에 대한 검증 절차를 수행한다. 내부 구성요소들 (order, review 등)은 서블릿 필터에서 인증/권한을 다 확인했다고 가정을 하고 동작하기 때문에 요청의 정당성에 대해서는 고민하지 않는다. 만약 요청자가 누구인지, 어떠한 권한을 가지고 있는지에 대해 알아야 한다면 구성요소들이 공유하고 있는 웹세선을 참고한다. 요청이 애플리케이션 계층 내부로 들어오면 구성요소들 간 통신 보안에 대해서는 걱정할 필요가 없다. 모놀리식 애플리케이션에서의 보안 절차는 중앙화된 단일 지점에서 시행하며, 개별 구성요소들은 부가적인 검증 절차를 도입하지 않아도 된다. 따라서 마이크로서비스 아키텍쳐 기반 애플리케이션 보안 절차보다 간단하다는 것을 알 수 있었다.
그리고 마이크로서비스 아키텍쳐의 특성으로 인해 이 환경에서의 보안은 다루기 어려운 상황을 아래와 같이 7가지에 대해 상세하게 알아보는 시간을 가졌다.
1. 공격 노출 지점이 넓어질수록 공격 받을 위험도 증가
2. 보안 검증 지점 분리는 성능 저하를 초래
3. 배포 복잡성으로 인한 마이크로서비스 간 초기 신뢰 설정 어려움
4. 다양한 마이크로서비스 간 통신 추적의 어려움
5. 컨테이너의 불변성으로 인한 자격 증명과 접근 제어 정책 유지의 어려움
6. 마이크로서비스의 분산된 특성으로 인한 사용자 컨텍스트 공유의 어려움
7. 다중 개발 언어 지원 아키텍쳐는 개발 팀에 더 많은 보안 전문지식을 요구
내용을 모두 정리하기에는 양이 많다보니 타이틀 위주로만 정리하였고, 추후에 시간적 여력이 되어 가능하게 되면 추가 업데이트를 할 수 있도록 해야겠다.
