log4j Log4j, 소프트웨어 개발, 델파이와 C++빌더

[Kori]

마르코 칸투 (Marco Cantu)의 The Impact of Log4j on Software Development with Delphi and C++Builder 를 번역했습니다. (원문 작성: 2021년 12월, 최종 번역: 2021년 12월 29일)

Log4j의 보안 이슈를 계기로, 이번 이슈가 일반적으로 개발자 커뮤니티에 미치는 영향과 RAD 스튜디오 개발자에게 끼치는 특정 영향에 대해 내가 생각해 본 것들이다.

인터넷이 연결되지 않은 외딴 섬에 거주하지 않는 한, Log4j 이슈가 지난 10일 동안 수많은 응용 프로그램과 인터넷 서비스에 끼친 영향에 대해 들어봤을 것이다. 이 이슈는 마인크래프트 콘솔 메시지와 관련된 치명적인 버그(마인크래프트 게임 클라이언트에 메시지를 입력하면 누군가 Minecraft 서버에서 코드를 실행할 수 있게 됨)가 우연히 발견되었고 그 원인이 Log4j라는 매우 인기 있는 Java 로깅 라이브러리를 사용하기 때문이라는 것이 밝혀지면서 큰 이슈가 되었다. 이로 인해 모든 IT 회사 뿐만 아니라 소프트웨어 응용 프로그램을 사용하는 모든 회사들은 자사의 소프트웨어, 호스팅 받고 있는 서비스, 내부 웹 사이트, 기타 여러 경우에 대해서 이 이슈의 영향을 점검해야 했다.

영향을 받는 것으로 파악된 소프트웨어 응용 프로그램의 목록(관련된 목록 사례)은 상당히 인상적이다. Java는 광고와 마케팅 활동 면에서 추진력을 잃고 있음에도 불구하고 여전히 세계에서 가장 인기 있는 언어 중 하나이며 JVM은 가장 많이 사용되는 런타임 실행 환경이라는 것이 드러났기 때문이다.

RAD 스튜디오는 네이티브 코드이며 전혀 Java에 의존하지 않는다

자, 이번 이슈가 엠바카데로와 특히 RAD 스튜디오에 일반적으로 어떤 의미일까? 한마디로 큰 의미는 없다. 델파이 또는 C++빌더로 구축된 소프트웨어는 (안드로이드 앱을 제외하면) Java를 사용하거나 Java에 의존하지 않으므로 Log4j를 사용하지 않기 때문이다. 더 일반적으로 말하자면, 델파이와 C++빌더는 네이티브로 작동되는 애플리케이션을 만들어 내기 때문에 Java, .NET, JavaScript 등 특정 실행 환경의 영향을 덜 받는다. 하지만 이번 Log4j 이슈는 실행 환경 자체가 아니라 인기있는 라이브러리가 문제된 것이다. 그리고, RAD 스튜디오 개발자 역시 다른 개발자들과 마찬가지로 외부 컴포넌트를 추가하고 써드-파티 라이브러리도 사용한다.

다시 한 번 분명히 하고 넘어가자. 웹 서버 또는 웹 서비스 역시 델파이 또는 C++빌더(일반적인 C++ 언어)로 구축한 경우라면 Log4j 이슈의 영향을 받지 않는다. 물론 ASP.NET, 파이썬 또는 PHP로 구축된 웹 응용 프로그램의 경우에도 마찬가지이다. 이 문제는 Java로 작성된 소프트웨어에만 해당되며, Java 소프트웨어는 매우 많기 때문에 크게 이슈가 된 것이다 (위에 있는 해당 목록의 링크 참조).

델파이와 C++빌더와 관련된 내용으로 돌아와서, 컴파일된 코드는 보안에 도움이 된다. 하지만 그것만으로는 충분하지 않다. 외부 라이브러리와 컴포넌트를 사용할 때는 완전히 신뢰할 수 있는 (그리고 최소한 소스 코드가 포함되어 있는) 것을 선택하는 것이 중요하다. 또한 보안에 중점을 두고 개발자가 코드를 작성하는 것 역시 중요하다. 지난 주에 언급했듯이 복사하여 붙여넣기 식 코딩은 (Log4j 문제와 직접 관련되지는 않지만) 보안이 견고한 애플리케이션 만들기와 정반대 편에 있는 코딩 스타일이다.

오픈 소스에 기여하여 보답하자

Log4j 문제를 통해 명배하게 드러난 주요 이슈가 하나 더 있다. 대기업에서 관리하는 수십억원 규모의 프로젝트 중에서도 자금 지원이 전혀 업고 개발자가 여가 시간에(정규 업무 외) 관리하는 오픈 소스에 의존하는 경우들이 있다. 그 아래에 담긴 생각 즉 오픈 소스를 사용하면 비용을 절감할 수 있고, 해당 오픈 소스 프로젝트에 굳이 시간, 자원, 자금을 되갚지 않아도 된다는 생각이 업계에서 큰 문제가 되고 있다는 점이다.

이것은 델파이와 C++빌더의 생태계에서도 마찬가지이다. 엠바카데로는 몇몇 오픈 소스 라이브러리에 대해 자금 지원과 기부를 시작했지만 우리 엠바카데로는 더 많이 해야 한다. 또한 비즈니스 응용 프로그램에서 오픈 소스 델파이 라이브러리와 도구를 상당히 많이 활용하고 있다면, 누구든지 해당 오픈 소스에 기여할 것을 권장한다 (여기에는 보안 점검 결과를 전달하는 것도 포함된다)!

당신은 직업 상 얼마나 많은 오픈-소스 프로젝트를 사용하고 있는가? 그리고 해당 프로젝트에 기부를 한 것은 언제가 마지막이었는가?

보안은 여러가지 얼굴을 하고 있다

보안에는 끝이 없다. 그리고 다각도로 접근해야한다. 아래의 각 항목이 도움될 수 있다.

• 네이티브로 컴파일되는 애플리케이션
• 런타임 실행 환경에 대한 종속성 없애기
• 보안 확인이 완료되었고 신뢰할 수 있는 타사 라이브러리 및 컴포넌트를 사용
• 당신이 활용하는 오픈-소스 프로젝트에 보답하겠다는 약속
• 코드 작성 시 보안에 중점(복사하여 붙여넣기 코딩하지 않기)
• 애플리케이션 소스 코드를 검증하는 도구를 활용
• 안전한 저장소에 소스 코드를 보관 (소스 코드 주입 방지)
• 안전한 빌드 환경 (바이너리 코드 주입 방지)
• 애플리케이션 실행 파일에 서명하기

이 글은 포괄적이지 않고, 컴파일된 코드(우리는 이것이 중요하다고 생각한다)의 편을 드는 경향이 있다. 하지만, 위에 제시된 항목과 Log4j 사태에 대한 전반적인 반응을 통해 여러분과 여러분의 회사가 보안에 대해 다시한번 생각해보고, 개발자의 역할에 대해 가치를 더 많이 부여하는 계기가 되기를 바란다. 개발자는 보안이 견고한 개발을 이루기 위한 초석이다.

Log4j가 없는 RAD 스튜디오로 행복한 코딩을 하길 바란다.