서비스 운영 전에 Log를 남기는 작업을 했다.
서비스 운영 로그를 어떻게 누적해서 기록하고 분석에 이용할 수 있을지 고민이 필요했다.
이전 프로젝트에서는 파일로 로그를 남기곤 했다.
하지만 파일로 로그를 남기기만 하면 불편한 점이 있었다.
바로 로그를 확인하려 할 때마다 서버에 접속해서 파일을 하나씩 열어봐야했다는 것이다.
또한 레벨 별로 별도의 파일로 나누는 것말고 다른 검색 방법도 딱히 없었다.
개선 방법으로 두 가지를 생각했다.
1. 로그 분석 시스템 도입
흔히 ELK 스택으로 불리는 ElasticSearch, Kibana, Logstash에 Beats가 추가되었다.
로그를 파일로 저장하고 File beats로 Logstash로 전송 후 전처리하여 ElasticSearch에 저장... 이런 플로우를 도입할 수 있겠다고 생각했다.
2. 로그 데이터 베이스 저장
발생하는 로그를 바로 데이터 베이스에 저장하는 방법이다.
spring-boot-starter-web 의존성을 추가하게 되면 로그 라이브러리로 Sl4j, 구현체로 Logback이 추가된다.
Logback을 찾아보니 바로 DB로 로그를 저장할 수 있는 방법이 존재했다.
두 가지 모두를 시도해보는 것이 필요할 수 있겠으나,
ELK스택은 러닝커브가 2번 방법에 비해 높고 추가 서버 자원 또는 클라우드 서비스 비용 요구된다.
따라서 먼저 2번 방법을 시도해보기로했다.
이 글을 로그를 Logback의 DBAppendar를 도입하며 찾게 된 보안 취약점에 관한 글이다.
공식 문서
Chapter 4: Appenders
There is so much to tell about the Western country in that day that it is hard to know where to start. One thing sets off a hundred others. The problem is to decide which one to tell first. —JOHN STEINBECK, East of Eden Chapter 4: Appenders What is an Ap
logback.qos.ch
설정 방법을 찾아보며 공식문서에 들어가니 이런 문구를 바로 찾아볼 수 있었다.
As of logback version 1.2.8 DBAppender no longer ships with logback-classic. However, DBAppender for logback-classic is available under the following Maven coordinates: ch.qos.logback.db:logback-classic-db:1.2.11.1
최신 logback 버전에는 DBAppender를 더이상 지원하지 않고, 해당 기능을 사용하기 위해서는 이전 버전을 별도로 의존성 추가해주어야한다.
gradle에 의존성을 추가해주었다.
implementation group: 'ch.qos.logback.db', name: 'logback-classic-db', version: '1.2.11.1'
일단 구현을 하고 로그를 MySQL에 쌓는 것에 성공했다.
하지만 구현하고 나니 DBAppender가 왜 제거되었는지가 궁금했다.
이유를 찾던 중 어떤 스택오버플로우 글에서 '보안적'문제로 제거되었다고 발견했다.
조사하던 중 Log4j의 보안적 이슈에 대한 영상을 찾을 수 있었다.
21년 Log4j에 최악의 보안 사태로 꼽히는 보안 위협이 발견되었다고 한다.
JNDI를 통한 취약점으로 JNDI lookup으로 원격 코드 실행이 가능한 문제였다.
JNDI (Java Naming and Directory Interface)
Java 프로그램이 디렉토리를 통해 Java 객체 등 데이터를 찾을 수 있도록 하는 디렉토리 서비스이다.
Logback도 Log4j를 기반으로 만들어진 프레임워크이므로 비슷한 보안 이슈가 존재했다. (CVE-2021-42550)
CVE(Common Vulnerabilites and Exposures)
공개적으로 알려진 컴퓨터 보안 결함 목록
https://www.redhat.com/ko/topics/security/what-is-cve
하지만 보안적 위험에 노출되는 데에 전제조건이 있었고 전혀 해당 되지 않았다.
- 사용자가 사용중인 Logback의 버전이 1.2.9 이전 버전
- 공격자가 Logback 설정 파일(logback.xml)에 접근 및 쓰기 권한 소유
- 공격 전에 응용 프로그램의 다시 시작 혹은 scan="true" 설정을 통하여 공격자가 변조한 logback.xml 설정 파일이 시스템에 적용 출처: https://blog.alyac.co.kr/4361 [이스트시큐리티 알약 블로그:티스토리]
관련된 보안 취약점들을 찾으며 조사해보았지만
밝혀진 보안 취약점들과 DBAppender가 제외된 것의 관계는 여전히 의문으로 남아있다.
JMSAppender와 DBAppender는 다른 기능이기 때문이다.
JMS는 Java Message Service로 자바 애플리케이션 간에 비동기적으로 메시지를 교환할 수 있도록 하는 자바 표준 API
분산시스템에서 메시지를 안정적으로 처리하는데 사용된다.
공식 입장?
스택오버플로우를 더 찾아보다 공식입장을 찾을 수 있었다.
https://jira.qos.ch/browse/LOGBACK-1609
여기서 살펴볼 수 있는 내용 중 이런 것이 있었다.
Please do not realize this but the attack surface of JDBC connections is remarkably large and varied. Given our time constraints, we have not had the time to ascertain with 100% certitude that JDBC-based appenders do not pose a security risk.
We decided not to take responsibility for any eventual vulnerabilities for DBAppender at present time. This does not mean DBAppender is insecure but only that we did not have the time to perform the due diligence. Such due diligence takes time and is not always easy to get right. For any user wishing to use DBAppender, the code is available in github and would be very easy to add under the responsibility of the user. Just to be clear, DBAppender is probably as secure as similar code used by thousands of projects. The question is whether that is secure enough.
Some people may not understand this attitude. However, given our constrained resources, we have no choice but prioritize tasks and let certain tasks linger. As you can imagine, we have a lot on our plate. If you wish to influence the project roadmap, please have a look at our sponsorship options
정리하자면 '위험한 건 아닌데 100퍼센트 안전하다는 보장은 못하겠다' 였다.
JDBC 연결 관련 공격은 매우 다양해서 JDBC 기반인 DBAppender가 100% 안전하다는 것을 보장하지 못하니 DBAppender를 사용해서 발생하는 취약점에 책임을 지지않겠다는 입장이었다.
제외된 이유가 시원하게 밝혀지지가 않았다.
1.2.8 버전까지 존재하다가 JMSAppender와 함께 사라진 DBAppender라...
그렇다면 DBAppender를 계속 사용해도 될까?
현재로선 DBAppender를 사용하는 것이 굉장히 꺼려진다.
최신 업데이트를 계속 지원하지 않는 것 뿐만아니라 보안위협과 직결되어있기 때문이다.
SQL injection 공격의 가능성도 있지 않을까 한다. (뇌피셜)
따라서 꼭 ElasticSearch, Kibana를 사용하지 않더라도 파일로 저장하고 Filebeat, Logstash를 사용해서 DB에 저장할 수 있지않을까? 하는 생각이다.
DBAppender를 사용할 수 있는 DB는 한정적이고 MongoDB로의 저장을 지원하지 않는다.
Logstash는 훨씬 다양한 곳에 데이터를 보낼 수 있는 장점이 있다.
Output plugins | Logstash Reference [8.12] | Elastic
www.elastic.co
현업에 계신 개발자들께 여쭤보았을 땐
ELK 세팅이 안되어있으면 DB에 남기기도 한다, 클라우드 로그 서비스를 쓰기도 한다는 의견을 들을 수 있었다.
정말 제대로 로그를 남기고 분석하기 위해서는 ELK스택을 도입하는 것이 가장 좋아보인다.
잘못된 내용이나 더 아시는 내용이 있다면 알려주시면 감사하겠습니다!
'Programming > Java' 카테고리의 다른 글
| final 키워드 (0) | 2023.05.31 |
|---|---|
| [코딩 기초 트레이닝] java - Day 3 (0) | 2023.05.18 |
| [코딩 기초 트레이닝] java - Day 2 (0) | 2023.05.17 |
| 자바 주피터 노트북으로 실행하기! (0) | 2023.05.17 |
| [코딩기초트레이닝] java - Day 1 (0) | 2023.05.17 |
