��️ log4j 사태 아직도?
#log4j #log4jShell
� 세 줄 요약
- log4j가 우리에게 알려준 것, 디펜던시의 복잡함
- 소프트웨어들의 의존 관계가 얼마나 복잡한지, 이제 아무도 모든 관계를 다 파악할 수 없음.
- 그래서 필요한 게 소프트웨어 재료를 투명하게 공개하고 명시하는 제도.
✔️ log4j 사태가 각 기업의 IT 관련 조직에게 준 교훈은 다음과 같다.
"현재 각종 조직 내에서 실행되고 있는 소프트웨어 코드를 그 누구도 전부 다 알고 있지 못한다."
그 이유는 소프트웨어 생태계가 각종 디펜던시들로 너무 복잡하게 얽혀있기 때문이다. 즉, 어느 부분 하나에 문제가 생기면, 줄기를 따라 연쇄적으로 발생하는 문제를 완벽히 제어할 수 있는 방법이 없다는 것이다. 그 결과가 이번 log4j 사태와 같은 것이다.
✅ 왜 이러한 문제가 발생하는 것일까?
✔️ 오픈소스 소프트웨어들을 다운로드하는 전 세계 개발자들의 수는 2020~2021년 사이 73% 증가했다. 이 오픈 소스 소프트웨어들은 기성 상품처럼 '만들어진 형태'인데, 이를 짜깁기하여 프로그램을 만들어 낸다. 이런 방식을 선호하는 이유는 '개발 시간을 줄이고, 오류를 줄일 수 있기' 때문.
✔️ 기성 상품화된 '조각 소프트웨어들'을 끼워 맞춰 프로그램을 만들다 보니, 소프트웨어가 소프트웨어에 의존하는 연쇄 망이 만들어진다. 아티클은 이를 '디펜던시의 망'이라고 말한다. 네트워크처럼 연결된 이 '디펜던시의 망' 내부에서 문제가 발생했을 때, 우리는 정확히 어디가 문제가 발생했는지 추적하기 힘들다.
✅ 소프트웨어 재료 명시 제도
✔️ 각 소프트웨어가 어떤 시스템을 적용했는지 명시돼 있지 않기 때문이다. 이 때문에 log4j 사태가 커진 것인데, 구글의 오픈 소스 통찰팀에 따르면 자바 패키지의 80%가 log4j 취약점에 영향을 받는다는 것이다. 더 큰 문제는 각 소프트웨어가 업데이트를 진행할 수 없다는 사실이다. 즉, 취약점에 각자 대비하기 어렵다.
✔️ 이에 대비하기 위해 전문가들은 '소프트웨어 재료 명시' 제도가 생기길 바란다. 소프트웨어 재료 명시 제도(SBoM)란, '마치 시장에서 식료품의 원재료와 원산지 등을 표기한 채로 유통하는 것과 비슷한 방식으로 소프트웨어가 거래되도록 하는 것'을 말한다.
✔️ 즉, 소프트웨어 내에 어떤 디펜던시를 내포하고 있는지 분명하고 투명하게 밝히는 것이다. 이렇게 되면 특정 구성 요소에서 취약점이 발견되면, 구조화된 문제만 해결하면 된다. 소프트웨어 재료 명시 제도를 주창하는 보안 업체 리버싱랩스의 수석 소프트웨어 아키텍트인 토미슬라브 페리신은 "현 소프트웨어 개발 및 유통 체제에서 '반드시' 있어야 한다'라고 말한다.
✔️ 페리신은 다만, 정형화된 틀이 없기 때문에 하나씩 나열하며 만들어 가야 하는 수동적인 환경을 자동화해야 한다는 문제점이 있다고 말한다. 이에 대해 바이든 행정부는 사이버 보안 관련 행정명령을 발표하면서 소프트웨어 개발자들이 재료들을 명시해야 한다는 내용을 담은 바 있다.
✔️ 연방 정부 기관에 판매되는 소프트웨어에 한해서였지만, 미 정부가 움직였다는 사실은 '곧' 주류가 될 가능성이 있다는 것을 의미한다. 또한, 이 안에는 '재료 명시의 최소 기준' 가이드라인이 담겨있어, 확장된다면 충분히 실현 가능성 높은 이야기가 된다.
✅ 일상과 log4j 사태
✔️ 클라우드나 보안업계에 있는 사람이라면 log4j에 대해 잘 알지 못합니다. 저 또한, 뉴스를 탐독하다 발견했기 때문에 알았지, 그 이전까지는 이게 왜 문제야라는 생각을 했습니다. log4j 취약점에 대해 간단히 생각하자면, 타인이 접근할 수 없는 '나의 창고'를 마음대로 들락날락하는 것이라 할 수 있습니다. 이 문제를 해결하기 위해 '잠금장치'만 바꾸면 될 줄 알았는데, 그게 아니었던 것입니다. 교체한 잠금장치에도 이 log4j 취약점이 내재돼 있기 때문입니다.
✔️ 주변에도 log4j에 대한 이야기를 해보지만, IT 업계에 종사하는 사람 외에는 알지 못했습니다. 사실 같이 일하는 사람들조차 알지 못했고, 스터디를 꾸준히 하는 분들만 알았습니다. 표면적으로는 아무런 영향이 없는 사태였습니다. 다만, 내면에서는 뻥! 하고 터져버릴 위험이 도사리고 있을 뿐이죠.
✔️ log4j 대한 문제를 온전히 봉합하려면 몇 년이 소요된다고 합니다. 관련된 디펜던시가 너무나 많기 때문이겠죠. 곳곳에 포진한 '그 문제'를 해결하기 위해 2021년 말에 이어 2022년 초에도 보안 담당자들은 악몽 같은 시간을 보내고 있을 것으로 보입니다.
✔️ 이번 문제를 계기로 보안을 더욱 효율적으로 할 수 있는 체계가 구축되었으면 좋겠습니다. 물론, 그 구축 작업은 비효율적일 가능성이 높기는 합니다. �
