Coders Conquer Security Infrastructure as Code 시리즈 - 신뢰할 수 없는 출처의 구성 요소 사용하기

Infrastructure as Code 시리즈가 막바지에 다다랐습니다. 그동안 여러분과 같은 개발자들의 IaC 보안 여정을 도울 수 있어 기뻤습니다.

챌린지에 참여해 보셨나요? 현재 점수는 어떻게 되나요? 시작하기 전에, 신뢰할 수 없는 출처의 구성 요소를 사용할 때 발생하는 문제점에 대해 얼마나 알고 있는지 확인해 보겠습니다.

아직 더 공부해야 할 것 같나요? 아래 내용을 읽어보세요.

오늘 집중적으로 다룰 취약점 유발 행동은 신뢰할 수 없는 출처의 코드를 사용하는 것입니다. 이는 사소해 보이지만 심각한 문제를 야기하는 관행입니다. 오픈 소스 코드와 리소스를 활용하면 많은 이점을 얻을 수 있습니다. 일반적으로 전문가들이 자신의 아이디어, 작업물, 완성된 코드를 GitHub와 같은 저장소에 공유하면, 프로그램이나 앱 개발에 어려움을 겪는 다른 이들이 이를 활용할 수 있습니다. 완성된 코드를 사용하여 프로그램 기능을 제어하면 개발자가 매번 새로운 애플리케이션을 만들 때마다 바퀴를 다시 발명할 필요가 없습니다.

하지만 신뢰할 수 없거나 검증되지 않은, 혹은 잠재적으로 위험한 출처의 코드 조각을 사용하는 것은 큰 위험을 초래합니다. 실제로 신뢰할 수 없는 출처의 코드를 사용하는 것은 보안이 잘 갖춰진 애플리케이션에 크고 작은 보안 취약점이 침투하는 가장 흔한 경로 중 하나입니다. 때로는 개발자가 실수로 취약점을 만들기도 합니다. 또한 공격자가 악의적으로 코드를 작성한 사례도 있습니다. 공격자는 피해자가 자신의 애플리케이션에 해당 코드를 삽입하도록 유도하기 위해 코드를 공유합니다.

신뢰할 수 없는 출처의 코드를 사용하는 것이 왜 위험할까요?

개발자가 바쁜 상황에서 애플리케이션을 구성해야 한다고 가정해 봅시다. 이는 까다로운 과정일 수 있습니다. 그래서 모든 가능한 구성을 일일이 고민하는 대신, 구글 검색을 통해 이미 완벽해 보이는 구성 파일을 찾습니다. 개발자는 코드를 작성한 사람에 대해 전혀 모르지만, 새로운 애플리케이션에 추가하는 것은 비교적 쉽습니다. Docker 환경에서는 다음 두 줄로 간단히 처리할 수 있습니다.

RUN cd /etc/apache2/sites-available/ && \
   wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
   9d372cfa8855a6be74bcca86efadfbbf/raw/\
   fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

이제 Docker 이미지는 타사 구성 파일을 동적으로 가져옵니다. 파일이 테스트를 거쳐 당시에는 문제가 없었다고 해도, 해당 포인터가 애플리케이션 코드에 포함되어 있다는 것은 영구적인 의존성이 존재한다는 의미입니다. 며칠, 몇 주, 혹은 몇 달 후 원작자나 코드 저장소를 해킹한 공격자에 의해 파일이 변경될 수 있습니다. 갑자기 공유 구성 파일이 애플리케이션에 의도와 전혀 다른 동작을 수행하도록 명령하여, 권한 없는 사용자에게 접근을 허용하거나 데이터를 직접 탈취하여 유출할 수도 있습니다.

공유 리소스를 더 안전하게 사용하는 방법

조직에서 외부 소스 코드 사용을 허용한다면, 안전하게 수행할 수 있는 프로세스를 마련해야 합니다. 외부 코드를 평가할 때는 공식 출처에서 보안 링크를 통해서만 구성 요소를 가져와야 합니다. 또한 외부 소스에 직접 연결하여 코드를 가져오는 방식은 통제권을 잃게 되므로 절대 피해야 합니다. 대신 승인된 코드를 보안 라이브러리로 가져와 보호된 위치에서만 사용해야 합니다. Docker 환경에서는 다음과 같이 코드를 작성해야 합니다.

COPY src/config/default-ssl.conf /etc/apache2/sites-available/

원격 타사 구성 파일에 의존하는 대신, 해당 파일의 로컬 복사본을 사용해야 합니다. 이렇게 하면 예기치 않은 악의적인 변경을 방지할 수 있습니다.

보안 코드 라이브러리 사용과 더불어, 소프트웨어 수명 주기 전반에 걸쳐 구성 요소를 지속적으로 모니터링하는 패치 관리 프로세스를 구축해야 합니다. 또한 NVD나 CVE와 같은 도구를 사용하여 모든 클라이언트 및 서버 측 구성 요소의 보안 경고를 확인해야 합니다. 마지막으로 외부 코드와 함께 포함될 수 있는 사용하지 않거나 불필요한 의존성 및 기능은 모두 제거하십시오.

이러한 단계를 따르면 개발자는 실수로 애플리케이션과 코드에 취약점을 유발하지 않으면서 외부 리소스를 더 안전하게 활용할 수 있습니다.

이 취약점에 대한 더 자세한 정보와 보안 위협으로부터 조직과 고객을 보호하는 방법은 Secure Code Warrior 블로그 페이지에서 확인하세요. 또한 Secure Code Warrior 교육 플랫폼에서 IaC 챌린지 데모를 체험하며 사이버 보안 기술을 꾸준히 연마하고 최신 상태로 유지할 수 있습니다.