JAVA 보안 취약점 이슈로 인해 Spring Framework 영향
2021년 12월 Log4j라는 자바 컴포넌트에서 악용하기 쉬운 취약점이 발견되었습니다
원인은 Log4j의 ldap JNDI 파서를 통한 원격 코드 실행입니다
원격 코드 실행이 되기 때문에 로그인 하든 안 하든 사용자를 해커가 원격으로 조종할 수 있는 의미가 됩니다
그렇게 되면서 자바 플랫폼을 위한 프레임워크(ex spring)를 사용하는 모든 서비스가 보안에 노출되었습니다.
자세한 내용은 아래를 참고!
https://ko.wikipedia.org/wiki/Log4Shell
API 보안
"API 보안은 사용자가 소유한 API와 사용하는 API 모두의 무결성을 보호합니다"
여기에서 무결성은 신뢰할 수 있는 서비스 제공을 위해서 완전성, 정확성, 일관성을 유지함을 보장하는 특성입니다
API가 손상되거나 해킹되면 사용자에게 신뢰할 수 없는 서비스를 제공할 뿐만 아니라 주요 데이터 보안 유출 사고의 원인이 됩니다
SOAP API와 REST API
웹 API는 SOAP(Simple Object Access Protocol)와 REST(Representational State Transfer) 의 두 종류로 분류할 수 있습니다
둘 다 HTTP를 프로토콜로 사용하고 있기 때문에 URI, HTTP 메소드, HTTP 헤더 등은 모두 동일하게 사용되지만 메시지나 제어어와 관련된 부분은 차이가 있습니다
SOAP
SOAP로 설계된 API는 엔벨로프(envelope)라는 일종의 봉투와 같은 구조 안에 헤더, 바디가 들어 있어 XML 형식으로 만들어집니다
그래서 SOAP는 XML 메시지 형식을 사용하며 HTTP 또는 SMTP를 통해 요청을 수신합니다
SOAP은 주로 복잡한 비즈니스 로직을 웹 서비스 형태로 제공하는 SOA(Service Oriented Architecture)를 구성할 때 사용합니다
SOAP 방식으로 통신하는 시스템은 잘 구조화된 SOAP 메시지를 URI를 통해 주고 받아 복잡한 제어나 처리를 하는 것이 특징입니다
REST
REST는 URI를 호출할 때 HTTP 메소드를 기반으로 CRUD 조작을 하는 것처럼 비교적 간단한 제어를 할 때 사용합니다
REST의 기원은 로이 필딩이 쓴 박사 논문 'Architecture Styles and the Design of Network-based Software Architectures'로 알려져 있습니다
이 논문에는 REST에 관한 여러 가지 특징들이 나오는데 그 특징을 잘 살린 API를 RESTful API 혹은 REST API라고 합니다
REST 아키텍처의 제약 조건을 준수하는 웹 API를 RESTful API라고 합니다
ROA
SOAP은 주로 복잡한 비즈니스 로직을 웹 서비스 형태로 제공하는 SOA를 구성할 때 사용한다고 했습니다
ROA는 Resource Oriented Architecutre, 리소스 지향 아키텍처로 REST API의 사상을 기반으로 리소스 중심적인 API를 사용하는 아키텍처를 말합니다
REST 방식의 웹 서비스에 필요한 네 가지 설계 지침은 아래와 같습니다
- 상태를 가지지 않도록 만든다
: 상태를 가지지 않으므로 구현이 쉽고 캐시를 사용할 수 있어 성능이 우수하다 - URI는 디렉터리 구조처럼 계층적으로 만든다
: URI의 가독성이 좋고 리소스의 구조를 이해하기 쉽다 - HTTP 메소드를 명시적으로 사용한다
: 리소스의 상태 변화를 HTTP 메소드를 활용하여 리소스 중심으로 처리하고
별도의 메소드를 사용하여 행위 중심으로 처리하지 않도록 한다 - 응답할 때는 XML또는 JSON을 사용한다
: 데이터 표현을 정규화해서 다른 언어나 기술 구조에서도 데이터를 활용할 수 있도록 한다
API를 행위 중심이 아닌 자원중심으로 설계할 때 반드시 필요한 고려사항입니다
결론
REST API는 JSON(JavaScript Object Notation) 파일 형식을 사용함으로써 데이터를 저장하거나 다시 패키징 할 필요가 없기 때문에
SOAP API보다 훨씬 속도가 빠릅니다
복잡한 데이터 연계가 필요한 시스템이나 전자상거래와 같은 전자 거래 관련 분야에서는 SOAP을 사용하는 것이 적절합니다
REST 방식이 확산되면서 클라우드 환경에서는 SOAP을 사용하는 빈도가 점점 줄었습니다
그렇기 때문에 기본적으로 리소스에 대한 CRUD는 REST를 사용하는 것이 사실상 표준이 되었습니다
REST API 보안 및 SOAP API 보안 비교
REST API
REST API는 TLS(Transport Layer Security) 암호화를 지원합니다.
그래서 HTTPS인 경우 웹사이트가 TLS로 보호되는지 알 수 있습니다
SOAP API
SOAP API는 웹 서비스 보안(WS Security)이라는 기본 제공 프로토콜을 사용합니다.
SOAP API는 OASIS(Organization for the Advancement of Structured Information Standards) 및 W3C(World Wide Web Consortium)라는 두 가지 국제 표준화 기구에서 정한 표준을 지원합니다
이는 XML 암호화, XML 서명 및 SAML 토큰을 결합해 인증 및 권한 부여를 확인합니다.
SOAP API는 포괄적인 보안 조치를 갖추고 있음과 동시에 더 많은 관리가 필요하기 때문에 민감한 데이터를 처리할 때 권장됩니다
Read Hat이 말하는 가장 일반적인 API 보안 모범 사례
- 토큰을 사용한다
신뢰할 수 있는 신원에 할당된 토큰을 사용해서 서비스 및 리소스에 대한 액세스를 제어하는 것
토큰에도 종류가 여러가지 있습니다 (jwt, management api, custom api, sample)
jwt의 경우 시그니처에 토큰의 정보가 신뢰할 수 있는건지 판단 할 수 있습니다 - 암호화 및 서명을 사용합니다
HTTP은 암호화 과정을 거치지 않았기 때문에 패킷을 가로 채거나 수정 할 수 있기에 보안에 취약합니다
이를 보완하기 위해 나온 것이 HTTPS이며 중간에 암호화 계층을 거쳐서 패킷을 암호화합니다
https은 암호화하기 위해 ssl나 tls를 사용합니다
암호화 및 서명을 사용하면 올바르사용자 외에 다른 누구도 내 데이터의 암호를 해제하고 수정할 수 없도록 서명을 요구합니다 - 취약점을 확인합니다
운영 체제, 네트워크, 드라이버 및 API 구성 요소를 최신 상태로 유지합니다
스니퍼를 사용하여 보안 문제를 감지하고 데이터 유출을 파악합니다
스니퍼는 네트워크 트래픽을 감시하고 분석하는 프로그램입니다 (패킷 분석기) - 할당량 및 제한을 사용합니다.
API이 올바른 사용 기록인지 추적하고 호출 빈도에 대한 할량을 설정합니다
API 호출 빈도에 대한 할당량을 설정하지 않으면 급격한 트래픽 증가와 DoS 공격을 받을 수 있기 때문입니다 - API 게이트웨이를 사용합니다.
API 게이트웨이는 주요 API 트래픽 실행 지점 역할을 합니다
안전한 게이트웨이를 이용하여 트래픽을 인증하고 API 사용 방식을 제어 및 분석할 수 있습니다
서비스에서 보안 아키텍처는 어떻게 할까?
이 부분은 [스프링 마이크로 서비스 코딩 공작소]에서 마이크로 서비스 보안 아키텍처 참고했습니다
모든 서비스 통신에 HTTPS/SSL을 사용하라
"HTTPS 및 Secure Sockets Layer(SSL)로 제공되는 암호화된 채널로만 통신해야 한다."
이 책에서는 HTTPS 및 SSL로 제공되는 암호화된 채널로만 통신해야 한다고 나와있지만
참고 링크를 보면 "SSL 버전 3.0은 Netscape가 1999년에 발표했으며
현재에는 Transport Layer Security (TLS)"로 대체되었다고 나와있습니다
TLS는 인터넷 연결을 비공개로 유지하고 서버와 서버 또는 서버와 클라이언트 간에 전송된 데이터가
암호화되어 수정되지 않았는지 확인하는 표준입니다
SSL는 클라이언트와 서버 간의 안전한 링크를 통해 송수신되는 모든 데이터를 안전하게 보장합니다
서비스 게이트웨이를 사용하여 마이크로 서비스에 접근하라
게이트웨이는 다른 네트워크로 들어가는 입구 역할을 하는 네트워크 포인트이다
서비스 게이트웨이는 모든 서비스에 시행될 수 있는 정책 시행 지점(PFP, Policy Enforcement Point)입니다
클라이언트 -> 서비스 게이트웨이 -> 서비스 순서대로 호출을 하면 서비스를 보호하고
감시하는 방식을 일관된 방식으로 유지할 수 있습니다
그래서 외부(클라이언트)에서 서버, 서비스 엔드포인트, 포트를 접근할 수 없게 되는 것입니다 (입구 컷!)
공개 API 및 비공개 API 영역을 지정하라
일반적으로 보안은 접근 계층을 구축하고 최소 권한 개념(최소한의 네트워크 접근과 권한)을 적용하는 것이라고 나와있다
그런 다음 서비스를 공개 및 비공개라는 두 개의 개별 영역으로 분리해서 최소 권한을 구현해야 합니다
공개 영역은 클라이언트로 소비되는 모든 공개 API가 포함됩니다
클라이언트가 공개 서비스에 접근하려면 서비스 게이트웨어로 보호되는 단일 경로를 거쳐 자체 인증 서비스를 거칩니다
그런 다음 공개 서비스는 비공개 영역의 인증 서비스에서 인증해야 합니다
비공개 영역은 핵심 애플리케이션의 기능 및 데이터를 보호하는 장벽 역할을 합니다
그렇기 때문에 알려진 단일 포트로만 접근할 수 있고 서비스가
실행 중인 네트워크 서브넷의 네트워크 트래픽만 허용하도록 차단되어 있어야 합니다
불필요한 네트워크 포트를 차단해서 마이크로 서비스 공격 지점을 제한하라
서비스에 필요한 포트나 인프라스트럭처에 대한 인바운드와 아웃바운드 액세스만 허용하도록
서비스가 실행 중인 운영 체제의 구성을 설정해야 합니다
이때 인바운드 포트 액세스만 관심을 두면 안 됩니다
아웃바운드를 차단하면 공격자가 서비스를 침해하더라도 데이터 유출은 막을 수 있기 때문에 중요합니다
정리
지금까지 개발을 하면서 보안에 대해 얇게 생각만 했었다 😅
Java언어 & 스프링 프레임워크가 보안 취약점을 발견하면 조치를 해주기도 하고
https 설정하고 방화벽을 잘 설정하고 이상한 ip는 차단하고 이렇게 하면 되지 않을까?로만 생각했었기 때문이다
이번 포스팅을 통해 어제보다 더 보안에 대해 알게 되길!!!
[참고]
https://www.redhat.com/ko/topics/security/api-security
https://www.aladin.co.kr/shop/wproduct.aspx?ISBN=K992838585&start=pnaver_02
https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=109486799
'IT > 기록' 카테고리의 다른 글
[Flutter] Firebase Authentication을 사용하여 구글 계정 인증하기 (0) | 2022.08.10 |
---|---|
[Flutter] Flutter 앱에 Firebase 파이어베이스 설정하기 (0) | 2022.08.08 |
gradle project에서 JMH 라이브러리를 이용해 java code 성능 측정 (0) | 2022.08.03 |
사용자 입력이 필요한 JUnit Test (0) | 2022.07.19 |
Spring Boot DevTools 사용 (0) | 2022.07.04 |